Вчерашний пост про striped volume вызвал заметную реакцию. Не секрет, что ситуация с использованием концепции share nothing в NetApp FAS, и необходимостью разбивать диски между двумя контроллерами, это давний butthurt головная боль пользователей NetApp, особенно младших его систем. Да, действительно, когда дисков всего 12, допустим, то очень обидно отдавать половину на RAID и spare, по отдельности на каждый из пары контроллеров. Это не является существенной проблемой для людей, у которых дисков шкафы, сотни хостов, подключенных к системе, и так далее. В таких системах нет особенной необходимости для создания единого ресурса хранения, обычно в них LUN-ов и дисковых шар куда больше чем один. Но сомнение зудит. Все умеют, а нетапп не умеет, значит это проблема NetApp.
?? вот, кажется, что NetApp услышал наши молитвы, вот оно, в точности то, что нужно. Все не так просто, погодите. ?? мне стоит сразу дополнить вчерашний пост рядом фактов, которые являются не просто ложкой дегтя, но порядочным таким ведерком его.
Во-первых, давайте разберемся, что в реальной жизни дает striped volume, какие недостатки имеет, и как те же самые задачи можно решить иным путем, то есть, как можно уже сейчас, без использования striped volume, достичь всего того, что он позволяет делать.
Striped Volume позволяет:
- Потенциально может помочь увеличить производительность дискового ресурса, особенно если он такой на системе один, и не может быть распределен своими частями между контроллерами естественным образом.
- Обеспечивает равномерную загрузку несущих его нодов.
- Позволяет делать 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 и имеется, использовать ее в реальной жизни, иначе, как если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.
