Posts tagged ‘striped’

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 и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

Striped Volume в Cluster-mode

Как вы уже знаете, архитектура системы хранения NetApp не позволяет, при наличии двух контроллеров, организовать один общий дисковый раздел, доступ к которому имели бы оба контроллера одновременно. Почему так было сделано, отчего, и что это дает полезного – об этом мы уже в блоге говорили, не будем отвлекаться. А сегодня я покажу, как это ограничение может быть снято при использовании Data ONTAP Cluster-mode, новой модели работы со стораджем, которая активно развивается компанией уже не первый год.

В Data ONTAP 8.x Cluster-mode вы можете использовать так называемый режим Striped Volume, при котором доступ к данным на томе может быть осуществлен параллельно с любых контроллеров кластера, в частности с двух контроллеров, составляющих HA-пару.

Для начала надо убедиться, что лицензия Striped Volume введена, что позволяет системе такой том создать.

f3240-sqltest::> license show
(system license show)
Feature Cluster SN Limit Description
————— ———– ——- ———–
Base 1-80-000011 666 Base License w/cluster size limit (nodes)
iSCSI 1-80-000011 666 iSCSI License
Striped_Volume 1-80-000011 666 Striped Volume License
FCP 1-80-000011 666 FCP License
4 entries were displayed.

Раз лицензия есть, то можно создать striped aggregate:

f3240-sqltest::> aggr create -aggregate myAggr -nodes f3240-sqltest-01,f3240-sqltest-02 -diskcount 16 -disktype SAS -raidtype raid_dp -maxraidsize 16
[Job 818] Job succeeded: DONE

Создан aggregate, распределенный (striped) на два узла кластерной системы - f3240-sqltest-01 и fas3240-sqltest-02.

Посмотреть, что получилось можно командой aggr show myAggr.

w680

Данный aggregate распределен на два узла, состоит из 16  дисков, 8 из которых на узле 01, и 8 – на узле 02. Создано также два плекса и две RAID-группы. Это означает, что такой striped aggregate состоит, по сути, из двух “обычных” aggregate. Обратите также, что Volume Style указан как striped.

Понятнее про состав striped aggregate станет после вывода команды aggr member show.

f3240-sqltest::> aggr member show
Aggregate     Size Available Used% State    #Vols Node             RAID Status
——— ——– ——— —– ——- —— —————- ————
myAggr_000 2.15TB    2.15TB    0% online       0 f3240-sqltest-01 raid_dp,normal
myAggr_001 2.15TB    2.15TB    0% online       0 f3240-sqltest-02 raid_dp,normal
2 entries were displayed.

Как видите, striped aggregate myAggr состоит из двух “мемберов”, myAggr_000 и myAggr_001, каждый на своем узле. Если бы мы создали такой aggregate на трех, четырех, и так далее узлах кластера – мы бы получили три, четыре, и так далее под-“аггрегейта”. Созданный же на таком aggregate, поверх него том (volume) и данные на нем, окажутся равномерно распределенными по доступу между несколькими узлами, и операции доступа к ним более или менее равномерно нагрузят все входящие в группу контроллеры.

20/0.136

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.