Striped Volume – необходимые дополнения

Вчерашний пост про striped volume вызвал заметную реакцию. Не секрет, что ситуация с использованием концепции share nothing в NetApp FAS, и необходимостью разбивать диски между двумя контроллерами, это давний butthurt головная боль пользователей NetApp, особенно младших его систем. Да, действительно, когда дисков всего 12, допустим, то очень обидно отдавать половину на RAID и spare, по отдельности на каждый из пары контроллеров. Это не является существенной проблемой для людей, у которых дисков шкафы, сотни хостов, подключенных к системе, и так далее. В таких системах нет особенной необходимости для создания единого ресурса хранения, обычно в них LUN-ов и дисковых шар куда больше чем один. Но сомнение зудит. Все умеют, а нетапп не умеет, значит это проблема NetApp.

И вот, кажется, что NetApp услышал наши молитвы, вот оно, в точности то, что нужно. Все не так просто, погодите. И мне стоит сразу дополнить вчерашний пост рядом фактов, которые являются не просто ложкой дегтя, но порядочным таким ведерком его.

Во-первых, давайте разберемся, что в реальной жизни дает striped volume, какие недостатки имеет, и как те же самые задачи можно решить иным путем, то есть, как можно уже сейчас, без использования striped volume, достичь всего того, что он позволяет делать.

Striped Volume позволяет:

  1. Потенциально может помочь увеличить производительность дискового ресурса, особенно если он такой на системе один, и не может быть распределен своими частями между контроллерами естественным образом.
  2. Обеспечивает равномерную загрузку несущих его нодов.
  3. Позволяет делать cross-bound ресурсы, например очень большие файловые шары (для LUN это, как правило, не столь важно, так как они сами по себе ограничены, например 2TB в MBR-LUN, или же  64TB VMFS5.

Это так, как я уже упомянул выше, прежде всего в случае, когда такой ресурс (том, LUN, сетевая шара) ровно один. Однако в реальной жизни очень редко когда сторадж несет на себе ровно один LUN, датастор, файловую шару. Обычно, в моей практике, таких ресурсов десяток, и не один. И, в общем, проблема “одного дискового ресурса” на мой взгляд довольно надумана. Вручную, на маленьких системах, или с помощью имеющихся средств, типа Data Motion и OnCommand Balance, для больших, это сравнительно несложно сделать.

Проблема Cross-bound ресурсов сложнее, но тоже, на мой взгляд, довольно “бумажная”. В свое время, во времена ONTAP GX, когда контроллеры были не чета нынешним, ограничения на объем хранения на одном контроллере дествительно иногда создавали проблемы, и требовали найти пути выхода. Сегодняшние контроллеры часто имеют лимиты по объемам, превышающий реально эксплуатируемые, и, что немаловажно, имеющий смысл эксплуатировать на данном контроллере. Я очень редко вижу ситуацию, когда владелец контроллера NetApp добивает его дисками “под крышку”, до его лимита по объемам. Это просто довольно таки недальновидно с точки зрения производительности системы в целом.

Итак, какие же есть “подводные камни” для Striped Volume, и какие ограничения с ним связаны.

Во-первых, как мне уже тут указали “за кадром”, это в настоящий момент фича “положенная на холд”, она не развивается и скорее всего будет выпилена вовсе. Почему – ниже.

Во-вторых, striped volume есть объективное ограничение для самой идеи scaled-out архитектуры. например он требует, чтобы все контроллеры в кластере, по крайней мере в пределах striped volume) были однотипны (одинаковые контроллеры было требованием в GX, но это уже не так в Clustered ONTAP, и именно это направление, по моим наблюдениям, активно развивается компанией). Представьте себе, что striped volume оказался на двух узлах кластера: FAS6240 и FAS2240. Что будет с производительностью такого тома?

Соответственно использование striped volume естественным образом убивает возможность миграции тома между узлами кластера, крайне важной и нужной фичи Clustered ONTAP. Как результат, это делает невозможность миграцию такого тома в пределах кластера, например если вам нужно выполнить обслуживание или отключение одного из кластеров, содержащих striped volume. Соответственно это потенциально понижает общую availability кластерной системы в целом.

Наконец, люди, пользовавшиеся striped volume отмечали странное поведение и глюки, в особенности в области производительности, а так как, см. выше, эта фича явно идет в разрез с основным движением Clustered ONTAP в компании, то, вероятнее всего, эта фича будет вскоре просто убрана как таковая, и уж точно доделывать и вылавливать баги из нее не будут.

И последнее, задача сверхбольших томов в  настоящее время решается с помощью Infinite Volume, и не требует поддержки striped volume.

Таким образом, несмотря на то, что фича striped volume в Data ONTAP Cluster-mode и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

13 комментариев

  1. Киселев Сергей:

    Да, функционал имеется, но воспользоваться им вам не удастся никак, никто не продаст такую лицензию для новых систем, неважно гомогенный кластер или гетерогенный.
    По слухам, у NetApp что-то может быть подобное - распределение агрегата между контроллерами - но технически этот функционал будет реализован по другому, думаю годика через два что-то увидим )))
    Что касается необходимости рспределять дисковые ресурсы между контроллерами - есть явный успешный пример - Isilon.

  2. Vitaly Filatov:

    Очень интересно прозвучали комментарии про “выпиливание” фич у NetApp. Т.е. это уже не первый предполагаемый случай? У меня например есть совсем свежий пример “выпиливания”. В версии Data ONTAP 8.1 7-Mode и старше перестала поддерживаться команда ups, в результате чего мониторинг бесперебойников питающих контроллеры был “вырезан” и управление поведением MetroCluster при отключении питания, возложили на пользователей систем NetApp. Из за этого до сих пор сижу на 8.0.4,а не на 8.1.2, хотя в последней есть несколько нужных мне фич. Вырезание ups это тоже генеральная линия, или временные неудобства?

  3. Киселев Сергей:

    Isilon это как раз отличный пример, ага. Сторадж, который создан, по сути, для одного единственного вида нагрузки - секвентального чтения большими блоками, и только на нем хорошо и работает (и весьма посредственно на всех остальных, что, кстати, хорошо демонстрирует на тестах SPECsfs). Так что - да, отличный пример того, почему это не нужно делать. :)

  4. Vitaly Filatov:

    Логика в действиях производителя присутствует: непрофильные функций убираются в пользу профильных. Хранилка должна хорошо хранить данные, а не мониторить UPS. Для этих целей есть специализированный софт, который можно научить давать команды хранилке.

    ИМХО, большинство производителей Enterprise оборудования сейчас двигаются по генеральной линии максимального упрощения и “вылизывания” ключевых набортных функций в пользу внешнего управления.

  5. *в пользу внешнего управления

    Читать как: и передают прочие задачи на внешнее управление.

  6. Vitaly Filatov:

    Alexey Marushchenko:
    Позвольте, какая же это непрофильная функция? Обеспечение высокой доступности, при штатной ситуации отключения питания, является непрофильной функцией? Т.е. если я покупал Symetra LX для того что бы обеспечить данный функционал (т.к. поддерживается ограниченное количество UPS), то это деньги выброшенные на ветер. Меня никто не предупреждал, что в будущем этот функционал перестанет поддерживаться. Кстати это был один из критериев выбора СХД, пусть далеко не первый, но достаточно существенный при построении катастрофоустойчивых конфигураций на базе NetApp. Это нонсенс, что СХД не может корректно отследить отключение питания на одном из контроллеров, без привлечения дополнительных средств.

  7. Vitaly Filatov:

    Я думаю причина там та же, что и в случае выпиливания FilerView. Он не укладывается в “кластерную парадигму”, которая вот уже совсем скоро будет главной, а не “дополнительным и редко используемым режимом”.
    Хотя, конечно, с узкочастной “сисадминской” позиции и мне кажется этот подход неправильным. Но… Доктор сказал “в морг” :)

  8. Vitaly Filatov:

    romx:
    На последней конференции NetApp в 2012 году я слышал, что кластерное направление теперь является приоритетным, но так же слышал, что в Data ONTAP 8.2 или чуть более поздней версии, для кластерных конфигураций будет реализован аналог технологии MetroCluster в 7-Mode, для реализации кластерных катастрофоустойчивых решений, с названием технологии еще не определились. Если эти “официальные слухи” верны, то удаление команды управления контроллерами при пропадании питания выглядит как минимум странно. К тому же аналогия с FilerView, не совсем корректная, т.к. вместо него была представлена другая аналогичная оснастка в виде System Manager и его дальнейших инкарнаций, а замены функционалу команды ups пока что то не видно…

  9. Олег:

    “Как результат, это делает невозможность миграцию такого тома в пределах кластера, например если вам нужно выполнить обслуживание или отключение одного из кластеров, содержащих striped volume.”
    то есть при offline одного контроллера из кластера не будет файловера на второй? и потеряется доступ к striped volume? накроются данные на нем?

    кстати, у NetApp снепшот консистентной группы возможен только если все LU из этой группы на одном aggregate? или и на разных aggregate? на разных кластерах?

  10. Odna Ptichka:

    Диагноз правильный :
    “Я думаю причина там та же, что и в случае выпиливания FilerView. ”
    Объяснение не совсем:
    FilerView + ups - работали на java. “Выпилили” в первую очередь java, что, наверное, хорошо. То что замену, для ups не включили плохо.
    В оправдание ссылаются, что по отчетам автосапорта свойство было крайне редко используемое на практике. Но понятно, что вам от этого не легче.

  11. Odna Ptichka:

    Олег :
    “кстати, у NetApp снепшот консистентной группы возможен только если все LU из этой группы на одном aggregate? или и на разных aggregate? на разных кластерах?

    В кластерном ONTAP ( c 8.2RC1)
    - Тома на одном агрегате - да
    - Тома на разных агрегатах - да
    - Тома на разных узлах (разных D-Blade) - да

    Команды подается в рамках vServer:

    node::>* volume snapshot create -vserver vs0 -volume vol1,vol2,vol3,vol4,vol5,vol6 -snapshot cg_snap_1

  12. Дмитрий:

    Вот как раз сейчас для моих нужд это была б отличная функция. Ибо мне и нужно - файловая единая шара на порядка 80 Тб для многих дизайнеров и 2-х рендер ферм. И иметь равномерно нагруженные HA-ноды для меня - хорошо.

  13. bbk:

    Похоже именно эта проблема с младшими моделями дошла до верхушки нетапа.
    Как вы помните с появлением фичи ARL в C-Mode обязательно иметь _root_Aggregate_ на контроллер. Так в младших (новых) сериях 25хх разрешили использовать технологию позволяющую иметь один выделенный root Agregate на HA пару. В старших моделях это не поддерживается.
    Похоже теперь это называется “disk slicing”. http://www.4-traders.com/NETAPP-INC-4889/news/NetApp-Inc–Patent-Issued-for-Creating-Logical-Disk-Drives-for-Raid-Subsystems-17729826/

Оставить комментарий

20/0.144

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.