about NetApp

Я не первый раз рубликую тут переводы постов инженера NetApp – Dimitris Krekoukias, ведущего автономный, и крайне интересный блог http://recoverymonkey.org/ (другие мои переводы его постов вы можете найти в рубрике “переводы”)

После долгого молчания, Dimitris опубликовал пост, вызванный публикацией отличных результатов кластера FAS6240 в Data ONTAP 8.1.1 Cluster-mode в бенчмарке блочного (FC) доступа – SPC-1, о котором я уже написал в понедельник. Однако вопросу почему он так хорош, и насколько именно он хорош – посвящен сегодняшний перевод.

NetApp опубликовал великолепные результаты тестирования Cluster-Mode в бенчмарке SPC-1

Опубликовано June 20, 2012

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

Мы недавно выпустили ONTAP 8.1, которая, в Cluster-Mode, позволяет создать 24-узловой кластер (каждый узел которого может иметь до 8TB кэша) для задач NAS, и 4-узловой кластер для блочного доступа (FC и iSCSI).

А с выпуском ONTAP 8.1.1 (выпущенного 14 июня), мы увеличили лимит узлов для блочного доступа до 6, плюс добавили ряд дополнительных оптимизаций и возможностей. Между прочим, число узлов в кластере это пока только условный лимит официальной поддержки, это не жестко заданное ограничение.

После публикации нашего рекордного результата в бенчмарке NFS, люди спрашивали, как обстоит дело с производительностью блочного ввода-вывода в ONTAP Cluster-Mode, поэтому мы провели тестирование и опубликовали результаты бенчмарка SPC-1, используя часть той же системы, что уже была протестирована на SPEC sfs2008 NFS.

Для тех кто до сих пор думает, что NetApp не подходит для блочного доступа (это типичный FUD наших конкурентов): Это, на сегодня, лучший результат SPC-1 среди всех дисковых систем хранения, из расчета на уровень latency при достигнутом уровне IOPS (то есть возможно получить даже более высокие показатели IOPS на бОльших лимитах по latency, как я покажу далее в этом посте).

Вот ссылка на результаты и еще одна ссылка, на полную версию со всей доступной информацией.

В этом блоге я уже говорил о том, что представляет собой бенчмарк SPC-1 . Вкратце: Бенчмарк SPC-1 это общепринятый в индустрии, аудируемый, бенчмарк блочного доступа к системе хранения (по Fiber Channel) который проводит стресс-тестирование дисковой подсистемы большим объемом записей, перезаписей, локальных "хотспотов" и смешанной произвольно/последовательной, чтение-после-записи, запись-после-чтения нагрузкой. Около 60% рабочей нагрузки это операции записи. Размеры используемых в бенчмарке операций ввода-вывода различны, от маленьких до больших (таким образом IOPS в бенчмарке SPC-1 не идентичны и не могут быть сравнены напрямую с классическим тестом IOPS в full random блоками 4KB).

Если сторадж успешно работает на нагрузке SPC-1,, он, обычно, также крайне производительно работает на сложной, чувствительной к показателям latency, динамично изменяющейся нагрузке типа баз данных, в особенности OLTP. Полная спецификация для смертельно любопытных может быть найдена здесь.

Трюк с бенчмарками обычно состоит в интерпретации результатов. Сама по себе величина достигнутых IOPS, хотя и полезна, но не показывает всей картины, и того, как данный результат соотносится с реальной жзнью и реальными приложениями. Мы попытаемся помочь расшифровать результаты в этом посте.

Перед тем, как мы перейдем к анализу и сравнению результатов, несколько замечаний для неверующих:

1. В тестах NetApp не используется диски "с коротких ходом" (short-stroking), так часто любимые многими вендорами, проводящими тестирование, при котором используется только внешняя, наиболее быстродействующая часть диска, где сочетается максимальная линейная скорость и малый разбег механики коромысла жесткого диска, на чем можно показать наилучшие результаты. Вместо этого мы используем настройку параметров системы , чтобы использовать всю поверхность дисков, и не зависеть от того, насколько заполнены данными диски. Смотрите полный отчет здесь, страница 61. Для любителей распространять FUD: это эффективно "старит" состояние WAFL, приближая его к реальному состоянию реально эксплуатируемой системы. Мы также не используем оптимизацию размещения блоков путем их реаллокации.
2. Падения производительности в ходе продолжительного тестирования не наблюдалось.
3. Средняя величина latency (“All ASUs” в результатах) была плоской и оставалась ниже уровня 5ms на протяжении нескольких итераций теста, включая sustainability test в течение 10 часов (страница 28 полного отчета).
4. Не использовался дополнительный кэш, кроме того, который поставляется в базовой поставке FAS6240 (Контроллеры 6240 поставляются с Flash Cache емкостью 512GB, при максимальной возможной емкости данной модели 3TB на ноду (контроллер), то есть для работы с большими нагрузками есть еще значительный запас).
5. Это не "звездолет", построенный исключительно для завовевания победы и установления рекорда в бенчмарке. Мы использовали сравнительно немного дисков, в сравнении с конфигурациями других вендоров, и это не самая быстрая наша модель контроллера (еще есть 6280).

Анализ

Когда мы смотрим на результаты бенчмарка, следует сфокусироваться на следующих моментах:

1. Высокий уровень установившейся производительности в IOPS (нестабильность показателей показывает на наличие проблем).
2. IOPS/диск (это показатель эффективности – 500 IOPS/drive это вдвое лучше и эффективнее, чем 250 IOPS/drive, что, как следствие, означает меньше необходимых дисков в системе, снижает ее стоимость, уменьшает физический занимаемые в датацентре объем, и так далее.)
3. Стабильно низкая latency (пики показывают наличие проблем).
4. IOPS связан и зависит от latency (Получили ли вы высокие показатели IOPS вместе с высокой latency на максимуме? Это практически используемо?)
5. Какой тип RAID использовался (RAID6? RAID10? RAID6 обеспечивает значительно лучшую защиту данных и лучшие результаты эффективности использования дискового пространства, чем зеркалирование, что ведет к снижению стоимость даже более надежного хранилища данных).
6. Какие диски использовались? Хотите ли вы покупать такие диски?
7. ??спользовался ли autotiering? Если нет, то почему нет? Разве он не помог бы в такой сложной ситуации?
8. Какое оборудование потребовалось, чтобы получить стабильную производительность (сколько дисков и контроллеров потребовалось для построения системы? Означает ли это более сложную и дорогую систему? Как это все будет управляться?)
9. Цена (некоторые вендоры указывают цену уже с учетом дисконта, в то время как другие публикуют цену в list price, так что будьте тут внимательнее).
10. Цена/IOPS (наиболее полезная метрика – но следует сравнивать цену list price с list price).

SPC-1 это бенчмарк НЕ для измерения максимума потока данных; для измерения чистого GB/s смотрите другие бенчмарки. Большинство систем не дает больше 4GB/s в этом бенчмарке, так как много операций в нем рандомные (и 4GB/s это довольно много для рандомного ввода-вывода).

Сравнение систем

В этой части мы сравним дисковые системы хранения. Предсказуемо "чистые SSD" (или RAM) системы хранения имеют, конечно, очень высокие показатели производительности, и могут подойти, если ваша задача - обеспечивать работу с небольшим объемом данных очень быстро.

Но мы сосредоточимся на задачах высоконадежных систем общего применения, которые обеспечивают одновременно и высокую производительность, и низкую latency, и большую емкость, за разумную цену, а также, одновременно, большое количество функциональных фич(снэпшоты, репликация, кэширование в flash (megacaching), thin provisioning, дедупликация, компрессия, многопротокольность, включая NAS, и так далее). Опа – оказывается никто из конкурентов не может сделать сразу все что умеет делать NetApp.

Ниже приведен список систем и ссылки на их полные отчеты тестирования SPC-1, где вы сможете найти всю необходимую информацию. Все эти системы имеют высокие результаты и относительно плоскую кривую latency.

• NetApp 6240
• IBM SVC with V7000
• IBM SVC with DS8700
• HDS VSP
• HP 3Par V800
• Huawei Symantec S8100

Также есть несколько других дисковых систем хранения, со значительными результатами по IOPS, но если мы посмотрим на их результаты sustained latency (“Sustainability – Average Response Time (ms) Distribution Data” в любом из полных отчетов) мы увидим, что общие показатели latency чересчур высоки и наблюдается значительная неравномерность, в особенности в начальной фазе, с пиками до 30ms (что крайне много), поэтому мы не взяли их в расчет.

Вот краткий перечень систем и их параметров, отсортированных в соответствии с latency. Кроме этого показана и их стоимость в ценах list price (это можно найти в полном отчете о тестировании) плюс стоимость операции $/IOPS, посчитанная исходя из list price (многие вендоры приводят в отчетах цену с уже введенной скидкой, чтобы цена выглядела пониже):

…но ведь тут показано, что некоторые системы быстрее NetApp… Как так?

Это зависит от того, насколько важен для вас показатель latency и его низкая величина (и от того, принимаете ли вы в расчет используемый тип RAID). Для подавляющего большинства нагрузок типа баз данных, низкая latency операций ввода-вывода гораздо предпочтительнее высоких показателей latency.

Вот как это увидеть:

1. Выберите один из приведенных выше линков на полные отчеты Допустим это будет 3Par, так как он показывает одновременно и высокие показатели производительности, и высокие значения latency.
2. Найдем в отчете главу под названием "Response Time – Throughput Curve". Например это страница 13 в отчете по системе 3Par.
3. Проследим, как latency резко растет при повышении загрузки системы.

Например посмотрим на кривую 3Par:

Заметьте то, как latency резко растет после некоей точки.

Теперь сравним с результатом NetApp (страница 13):

Отметьте, что результат NetApp не просто имеет хорошие показатели latency, но, что еще более важно, latency остается хорошей и растет исключительно медленно по мере увеличения нагрузки на систему.

Вот почему колонка“SPC-1 IOPS around 3ms” была добавлена в таблицу. Фактически это ответ на вопрос что бы было, если бы уровень latency был в тесте одинаков для всех протестированных систем?

Когда вы примете эту позицию, вы увидите, что система 3Par фактически медленнее, чем NetApp, если сравнить их на одинаково низком желаемом уровне latency.

Вы можете взять точные показатели latency из графика на странице 13, у NetApp таблица выглядит так (озаглавлено "Response Time – Throughput Data"):

Действительно, при сравнении результатов мы видим, что только IBM SVC (с кучей стораджей V7000 за ним) оказывается быстрее NetApp при столь же хороших показателях latency. Что плавно подводит нас к следующей главе…

Сколько железа обеспечивает такую производительность?

Почти любая инженерная задача может быть решена, если дать приложению достаточное количество необходимого оборудования. Результат IBM это как раз хороший пример того, как можно получить хороший результат собрав вместе большую кучу дорогостоящего железа:

• 8 SVC контроллеров (virtualization engines) плюс…
• …16 отдельных систем V7000…
• …каждая состоящая из еще 2 контроллеров SVC и 2 контроллеров RAID
• 1920 дисков 146GB 15K RPM (не так-то просто такие купить нынче, не так ли?)
• ??того 40 контроллеров SVC (8 больших и 32 поменьше), 32 RAID-контроллера, и все это битком наполнено дисками.

Даже отставив в сторону вопрос того, как это все управляется, сколько это потребляет электричества и как размещается, понятно, что это довольно большая система. Я даже не пытался посчитать, сколько тут процессоров и ядер работают параллельно, уверен, их много.

Сравним эту кухню с вариантом конфигурации NetApp:

• 6 контроллеров в одном кластере
• 432 диска 450GB 15K RPM (самый распространенный и массовый наш диск по состоянию на июнь 2012).

Вопросы (с удовольствие увижу ответы на них от других вендоров):

1. Что произойдет при использовании RAID6 у других вендоров? NetApp всегда тестирует системы с использованием своей версии RAID6 (RAID-DP). RAID6 значительно надежнее, чем зеркалирование, особенно в больших пулах (не говоря уже о более эффективном использовании пространства дисков). Большинство клиентов не хотят покупать большую систему в конфигурации только-RAID10… (пользователи - задавайте вопросы вашим вендорам. Тут нет никакого волшебства – ручаюсь, у них есть внутренние результаты для RAID6, попросите показать их вам).
2. Autotiering это одна из самых раскрученных сегодня фич, с признаками того, что это достижение, превосходящее изобретение пенициллина, или даже колеса, а может даже и огня… Однако никто из дисковых массивов не рассматривает использование SSD для autotiering (IBM опубликовала однажды результат – не впечатляет, делайте выводы). Это при том, что бенчмарк, по своей спецификации активно создающий "горячие точки" (hotspots) нагрузки, должен бы быть здесь идеальным кандидатом для демонстрации эффективности…
3. Почему EMC и Dell не желают публиковать результаты SPC-1? (Они оба, кстати, члены SPC, Storage Performance Council). Только два этих вендора, из крупных игроков на рынке, кто еще не опубликовали свои результаты. EMC ранее говорила, что SPC-1 это нереалистичный тест – ну, типа только ваше приложение с вашими данными на вашем сторадже может показать по-настоящему реальные результаты. Это так, однако SPC-1 это общепринятый индустрией стандартный бенчмарк для блочного доступа произвольного характера, и отличная "лакмусовая бумажка".
4. Для системы, которая регулярно позиционируется для нагрузки Tier-1, IBM XIV, результаты бенчмарков, увы, отсутствуют также, даже для самой новой ее Gen3. Неужели IBM стесняется показать свои результаты SPC-1 для этой системы?
5. Наконец – некоторые наши конкуренты продолжают утверждать, что NetApp, дескать, это "не настоящий SAN", что это, якобы "эмуляция SAN", и так далее. Что бы это все ни значило на самом деле – может быть подход NetApp, с такой "эмуляцией" оказывается, по факту, лучше?… Максимальная write latency в этом тесте составила 1.91ms для в основном записываемой нагрузки!

??тоговые мысли

В накануне опубликованном результате бенчмарка SPC-1, NetApp показала вновь, что Data ONTAP в Cluster-Mode это высокопроизводительная и масштабируемая система, одинаково подходящая как для SAN, так и для NAS задач. Суммируя все вышесказанное, можно сказать, что ONTAP Cluster-Mode:

• Позволяет строить высокопроизводительные и динамически-масштабируемые кластеры хранения для FC, iSCSI, NFS и CIFS.
• Демонстрирует низкую latency при высокой производительности.
• Предлагает исключительно хорошее соотношение price/performance.
• Позволяет доступ к данным одной ноды с любых других нод.
• Перемещает данные между нодами, не прерывая работы с ними (включая CIFS, что ранее не было практически невозможно).
• Поддерживает традиционные для NetApp возможности (оптимизацию процессов записи, взаимодействие с приложениями, снэпшоты, дедупликацию, компрессию, репликацию, thin provisioning, и кэширование во flash (megacaching).
• Может работать на в точности тех же самых контроллерах FAS, что и в 7-mode, что защищает инвестиции.
• Может виртуализовывать системы хранения, расположенные за ними.

??сточник <http://recoverymonkey.org/2012/06/20/netapp-posts-great-cluster-mode-spc-1-result/>

Несмотря на то, что современные модные тенденции в софтостроении требуют выпускать новую мажорную версию при списке whatsnew: [*] исправлена грамматическая ошибка в панели About программы, NetApp все же следует классической модели именования  изменения версий. Однако иногда эта консервативность, на мой взгляд, бывает даже чрезмерна, так, напрмер, между Data ONTAP 8.1 и 8.1.1 в функцональность были добавлены весьма существенные, важные и интересные штуки (про одну из них – Flash Pool мы уже говорили ранее). Так, например, это фича, под названием Infinite Volume. Не то чтобы это была сверхнужная для каждого возможность, но тема любопытная, и, возможно, читателям будет интересно узнать, чем же там занимаются, за закрытыми дверями отдела разработки Data ONTAP, и в какую сторону идет направление работ.

Infinite Volume – это новая возможность для кластерных систем (под Cluster-mode) NetApp, позволяющая строить очень большие тома, с доступом по NFS v3. На сегодня лимит для Infinite Volume это 20PB и 2 миллиарда файлов в одном “томе”, то есть в одном маунте (экспорте) NFS, на 10-нодовом кластере. Разумеется эти файлы распределены по множеству томов и aggregates нод кластера, но монтируются они при этом через одну точку монтирования. Таким образом, например, 200 томов по 100TB каждый, по 20 томов на каждой из 10 нод кластерной системы, будут смонтированы на сервера по единственному пути cluster:/vol/infivolume/, а не в виде 200 экспортов, на каждом из множества frontend-серверов системы, как это бы пришлось делать в “классическом” варианте.

Infinite Volume, как вы понимаете, это достаточно специализированное решение, ориентрованное на задачи секвентального чтения больших файлов, и сравнительно редкой их записи. Мне видится, что это задача похожа на что-то типа Youtube, или сходного функционала онлайнового файлового или видеохранилища, что-то такое, где себя сейчас хорошо чувствует EMC Isilon. Infinite Volume занимает нишу, в настоящий момент незакрытого в продуктах компании участка, разделяющего задачи систем E-series (бывших LSI/Engenio) и решений на его базе, подобных NetApp FMV solution и прочих StorNext с одной стороны, и “классических” FAS в Cluster-mode с другой.

??так, в постах о том, как работает Cluster-mode я уже упоминал то, как работает доступ к данным на кластере. А сейчас давайте рассмотрим подробнее процесс создания LUN-а на кластере, для обычного блочного подключения его с хост-сервера Windows.

Несмотря на то, что System Manager 2.0 уже умеет работать с системами в Cluster-mode, мы посмотрим на то, как создаются объекты хранения данных Data ONTAP 8.1 Cluster-mode из консоли. Это нагляднее и проще заскриншотить.

Создадим Vserver. В предыдущем посте я рассказывал что это и зачем нужно в Cluster-mode. А вот как он создается.

Создадим Vserver под названием MyVserver на aggregate с именем aggr1:

Допустим, мы хотим обращаться к данным, хранимым на MyVserver по протоколу FCP, для версии 8.1 у нас уже есть возможность работать с данными в Cluster-mode по блочным протоколам. Для этого, включим для Vserver протокол FCP (и проверим его включение):

Target Name это физическое имя (nodename) соответствующего контроллера.

Далее нам нужно создать так называемый LIF – Logical Interface, о котором я уже также упоминал в посте ранее. LIF – это логический интерфейс, который динамически мапится на физический интерфейс того или иного узла кластера, на котором работает Vserver, и через который обеспечивается ввод-вывод данных. Создадим и посмотрим на то, что у нас получилось.

Network Address/Mask эквивалентен физическому WWPN у порта контроллера.

Создадим igroup – специальную группу, в которую включим нужные нам сервера, чтобы ограничить доступ и видимость LUN-ов только необходимыми серверами. Для этого нам понадобится знать имена WWPN тех портов серверов, которых мы назначим в группу, именно по WWPN и будем определять, наш сервер это или нет.

Создадим группу MyIGroup и включим туда FCP WWPN initiator-ов с соответствующих портов.

Наконец, создадим том FlexVol под названием MyVol:

Теперь создадим LUN по имени MyLUN на этом томе:

Смапим LUN соответствующей igroup

А теперь подключаем созданный LUN обычным образом на сервер Windows, с помощью стандартной оснастки Disk Management.

Готово. У нас на сервере подключен LUN по FCP, расположенный в кластере контроллеров NetApp под управлением Data ONTAP 8.1 Cluster-mode.

За основу поста взят пост из блога специалиста NetApp “Pseudo Benchmark”, из которого я позаимствовал скриншоты.

Также как и в Data ONTAP 7-mode, в Cluster-mode с версии 8.1 есть снэпшоты. Сохранились все привычные пользователям NetApp команды snap reserve, snap sched, snap list, но добавилось несколько новых команд и возможностей.

Также добавились некоторые дополнительные опции в некоторых командах

Также есть изменения и в способе задания распсания снэпшотов. Если раньше это делалось командой snap sched, указывалост имя тома и задавались интервалы в формате cron, то новый механизм использует политики (policy), которые управляются командами add-schedule, modify-schedule и remove-schedule. Для создания же новой политики взятия снэпшотов воспользуйтесь командой snap policy create.

??так, в прошлом посте этой темы я вкратце остановился на предыстории Data ONTAP 8.x Cluster-mode.

Еще в прошлом году я перестал в этом блоге называть “классическую” структуру из двух контроллеров в системах хранения NetApp “кластером”, с тем, чтобы вам было проще “переключиться”. Пару контроллеров под управлением Data ONTAP 7.x и Data ONTAP 8.x 7-mode следует правильно называть HA-pair (HA – High Availability), HA-парой, или, в крайнем случае, HA-кластером, ясно отделяя это от “кластера” в 8.x Cluster-mode. Словом “кластер” у NetApp теперь называется совсем иная структура. Дабы не путаться, буду следовать этому правилу именования и я.

В настоящий момент можно построить кластер, работающий как NAS-сервер (NFS или CIFS) из 24 узлов-контроллеров (nodes), то есть из 12 HA-пар контроллеров.

В версии Data ONTAP 8.1 появлась также поддержка блочных протоколов (iSCSI, FC, FCoE). Однако при использовании блочных протоколов (только их одних, или в комбинации с NAS) максимальный размер кластера на сегодня поддерживается в размере четырех нод, или двух HA-пар. Эта величина, как я думаю, будет расти, как только будет все отлажено и обеспечена надежность, все же 8.1 это первая версия с такой функциональностью, но пока – имейте это ввиду. Связано это, прежде всего, с тем, что файловые протоколы, такие как NFS или CIFS, по сути, полностью управляются и контролируются на стороне стораджа, и проще обеспечить все необходимые процедуры работы и синхронизацию процессов между узлами кластера.

Прежде всего, следует осознать разницу, между понятиями Global Filesystem и Global Namespace.  Data ONTAP 8.1 Cluster-mode это Global Namespace, но НЕ Global Filesystem.
Global Namespace позволяет вам видеть кластер и его пространство, как совокупность нодов его составляющих, как единую “сущность”, целостное пространство, вне зависимости от того где и как хранятся ваши данные. Однако с точки зрения хранения, каждый нод-контроллер, по-прежнему оперирует данными, хранящимися на его aggregates и томах. Один единственный файл не может располагаться более чем на одном aggregate/ноде-контроллере. Также он не может мигрировать, распределяясь частью на одном, частью на другом ноде-контроллере.

Это, как мне кажется, очень важно понимать, поэтому на этом я так заостряюсь.

Безусловно, устройства, реализующие Global Filesystem, имеют в этом месте меньше ограничений (например EMC Isilon с его OneFS это как раз Global Filesystem), однако, в нашем мире, как вы помните, ничего не дается бесплатно, и реализация Global Filesystem влечет за собой ряд весьма неприятных побочных негативных эффектов, в первую очередь для производтельности. Isilon весьма хорош, но он хорош на определенных типах рабочей нагрузки (преимущественно последовательном доступе). Насколько в вашем конкретном случае важна возможность хранить огромного размера файл(ы), превосходящие по размерам емкость дисков, подключенных к одному контроллеру, и распределенные на несколько узлов кластера, и готовы ли вы за такую возможность заплатить ухудшением характеристик рандомного доступа к ним – решать вам. На сегодня на рынке имеется как тот, так и другой вариант.

Преимущество же в производительности довольно убедительно показал NetApp в недавнем тестировании SPECsfs2008 на протоколе NFS, где 24-нодовая система FAS6240 под управлением Data ONTAP 8.1, почти в полтора раза превзошла 140-нодовую систему EMC Isilon S200.

При этом, следует отметить, что, в случае NetApp, тестировался worst case, “наихудший случай” то есть только 1/24 часть всех операций шла на контроллер-owner, 23 из каждых 24 операций шли через “неродные” контроллеры, через cluster network, и не использовались никакие существующие у NetApp средства оптимизации, такие как, например, Load Sharing Mirrors (RO-копии) на “неродных” узлах кластера, которые, безусловно, увеличат производительность в реальной жизни.

Напомню, что тест SPECsfs2008 это классический и авторитетный тест, имитрирующий усредненный типовой файловый доступ по протоколам NFS (и CIFS), сгенерированной смесью операций соответствующего протокола, и там, понятное дело, много операций с метаданными и, преимущественно, рандомный доступ.

??так – Data ONTAP 8.1 Cluster-mode это Global Storage Namespace, но НЕ Global Storage Filesystem. Несмотря на то, что вы видите кластер как единую сущность, отдельный файл, на нем хранимый не может превышать емкость аггрегейта одного контроллера. Однако вы можете получать доступ к данным этого файла через любой из контроллеров кластера. В этом заключается разница между Global Filesystem и Global Namespace.

Второй момент, на котором мне хочется подробнее остановится, это то, как именно строится кластер физически.

Несмотря на то, что, формально, “единицей измерения” размера кластера является одна нода, представляющая собой один физический контроллер, ноды эти всегда включены в HA-пары. По этой причине количество нодов в кластере NetApp Data ONTAP 8.x Cluster-mode всегда четное. Таким образом обеспечивается надежность и высокая доступность (High Availability) ноды, тем же методом, как это делалось для контроллеров в 7.x.

Поэтому вы не можете сделать 5- или 15-нодовый кластер, а 4-, 6- или 16-нодовый можете.

Третий момент, который мне бы хотелось подробнее осветить, есть то, что в настоящий момент NetApp предъявляет довольно строгие требования к оборудованию для реализации кластерных коммуникаций. Для построения Cluster network, то есть внутренней сети самого кластера, в настоящий момент поддерживаются только две модели 10-Gigabit коммутаторов, это Cisco Nexus 5010 (20 портов, кластер до 12/18 нодов) и Cisco Nexus 5020 (40 портов, кластер более 18 нодов), их продает NetApp со своими партномерами, в составе общей квотации такой системы. Причем использовать эти коммутаторы можно только под задачи внутренней кластерной сети, совмещать их с другими задачами, например для подключения в них клиентской сети – нельзя. Даже если там еще остались порты.

Однако есть и хорошая новость. Сейчас NetApp и Cisco, в качестве time-limited promotion, при заказе cluster-mode стораджа у NetApp, отдает необходимое инфраструктурное оборудование за символическую цену 1$ за Cisco Nexus для Cluster network и Cisco Catalyst 2960 для Cluster management network, плюс необходимые SFP и кабеля. При этом цена на систему Data ONTAP 8.1 Cluster-mode из двух нодов, для промоушна, уравнена с ценой аналогичной конфигурации 7-mode, а инфраструктурная часть придет по цене 5$, за пять девайсов (два Nexus 5010, два Catalyst 2960, сет кабелей), плюс сервисные платежи.

Прежде чем у вас как следуют загорятся глаза и затрясутся руки “купить Нексус 5010 за один бакс”, я бы хотел отдельной строкой уточнить, что это предложение действует только для покупки системы cluster-mode, и, по условиям покупки, не может использоваться ни для чего другого.

Купленную по промоушну систему на две ноды можно расширить до 12 нодов (6 HA-pair) докупая только SFP и кабеля.

Структура cluster-mode кластера такова (на рисунке, для примера, показана двухузловая система):

В качестве коммутаторов клиентской сети можно использовать любые коммутаторы, Ethernet или FC, в зависимости от потребностей пользователя.

В качестве коммутаторов Cluster network switch могут использоваться только Cisco Nexus 5010 (для кластеров с числом нод до 12/18) или 5020 (для большего числа нод).

В качестве Cluster Management Switch NetApp рекомендует Cisco Catalyst 2960, но, в настоящее время, не обязывает покупать именно эту модель, при необходимости использовать имеющуюся у клиента иную модель, это может быть оформлено через заведение PVR, специального запроса на проверку и аппрув конфигурации у NetApp. NB: SMARTnet для такого свитча – обязателен!

Cluster Network это выделенная только под эту задачу сеть 10Gb Ethernet. Единственное исключение – FAS2040, которая может использоваться в Cluster-mode с использованием Gigabit Ethernet, но не рекомендуется ее использование с другими контроллерами. Обратите внимание, что даже для 2040 и ее Gigabit Ethernet, другие коммутаторы, кроме Nexus 5010/5020, не поддерживаются!

Ноды кластера могут быть различными по модели. Вы можете объединить в единый кластер любые контроллеры, для которых объявлена совместимость с cluster-mode (с единственным исключением в виде FAS2040, использование которого с контроллерами другого типа не рекомендуется (хотя и возможно), по вышеописанной причине отсутствия портов 10G)

Вы также можете объединить в кластер и системы с дисками различных типов, например вы можете построить систему с дисками SAS, SATA и SSD в рамках одного единого кластера, и организовывать миграцию данных между разными колнтроллерами-нодами и дисками разных типов.

Далее кратко и бегло:

Какие контроллеры в настоящее время поддерживаются для работы в Cluster-mode?

FAS/V62×0, FAS60×0, FAS/V32×0, FAS31×0, FAS3070, FAS3040, FAS2240, и FAS2040.
Для 2040 есть ограничения, связанные с отсутствием 10G Ethernet, для 3040 и 3070 ограничено максимальное количество нодов в использующих их кластеров. Помните, что для работы Cluster-mode нужна пара портов 10G Ethernet и несколько дополнительных портов для сетевых интерфейсов cluster management и сети собственно доступа к данных с клиентов.

Какие возможности “традиционной” Data ONTAP 7-mode поддерживаются, и какие – не поддерживаются?

Поддерживаются:

• Доступ к данным по:
  • файловым протоколам (NFSv3, NFSv4, NFSv4.1/pNFS, CIFS(SMB1.0), SMB2.0 и SMB2.1), c размером кластера до 24 нодов.
  • по блочным протоколам (iSCSI, FC, FCoE), с размером кластера до 4 нодов (кроме FAS2040, FAS3040/3070 и FAS6030/6070, для них SAN в cluster-mode не поддерживается) .
• Репликация SnapMirror – только асинхронная и только Volume SnapMirror. Репликация совместима только между системами Cluster-mode.
• Снэпшоты
• Компрессия и дедупликация
• FlexClone
• NDMP

Не поддерживаются:

• Синхронный SnapMirror, Qtree SnapMirror (сами qtree как объект иерархии поддерживаются), SnapMirror между системами 7-mode и cluster-mode
• SyncMirror
• Metrocluster
• SnapVault
• SnapLock
• IPv6

Каковы основные преимущества и цели системы Cluster-mode?

• Балансировка и масштабирование для больших нагрузок
• Непрерывающее работу наращивание производительности и миграция данных
• Единая, с точки зрения управления и администрирования “сущность” – кластер нодов.
• Поддержка привычных средств и фич NetApp – RAID-DP, FlexClone, Snapshots, SnapMirror Async, дедупликация, компрессия.

Что такое Vserver?

Оставайтес с нами, об этом – в следующих постах :)

Есть/будет ли FlexPod под Cluster-mode?

Пока – нет, но, возможно, будет.

Какие диски и полки поддерживаются?

Все, любые существующие на сегодня в продаже (не поддерживается интерфейсный модуль ESH2 и еще более старые).

Можно ли включать в кластер системы V-series и сторонние стораджи через них?

Да, можно V3200/6200 c EMC DMX4, CX4 и HP EVA. Остальные, может быть, через PVR. Однако даже для перечисленных систем нужна полка с дисками NetApp для хранения root volume.

Каков максимальный размер aggregate?

• 2040/3040/3070 – 50TiB
• 2240 – 60TiB
• 3210/3140 – 75TiB
• 6030/6040/3270/3170 – 105TiB
• 6070/6080/6210/6240/6280 – 162TiB

Каков максимальный размер тома?

Как максимальный размер 64-bit aggregate в 7-mode для соответствующих контроллеров

Каково максимальное расстояние “разноса” нодов кластера?

Максимальное допустимое расстояние от ноды до коммутатора cluster network – 300 метров.
Расстояние между redundant коммутаторами cluster network – 300 метров.
Расстояние между двумя нодами в HA-паре – то же, что и для 7-mode.

FlashCache поддерживается?

Да!

Есть ли non-disruptive upgrade для систем 7-Mode?

К сожалению – нет. Только через полную разборку-сборку.

Есть ли non-disruptive expand или reduce для кластера новыми нодами?

Да.

Можно ли слить вместе два кластера?

В настоящий момент нет, только через копирование, разборку второго и добавление его нод.

Нужен ли коммутатор для Cluster network в случае использования всего двух нод в кластере?

Да, все равно нужен даже для всего двух нод.

Работают-ли на Cluster-mode системах дедупликация, компрессия, thin provisioning, снэпшоты?

Да, все это работает.

Каким образом можно управлять кластером в Cluster-mode?

• GUI: NetApp System Manager 2.0
• CLI: SSH к кластеру, ноде или Vserver
• OnCommand 5.0
• NetApp Management SDK

FilerView (web-интерфейс, встроенный в контроллер) начиная с 8.1 не поддерживается.

Должен ли я управлять каждой нодой в отдельности?

Нет, кластер управляется как целостная сущность, без разделения на ноды. Каждая нода, при включении в кластер, получает и наследует глобальные настройки данного кластера.

Как обеспечивается антивирусная защита хранимых данных для кластера?

Тадааам! Теперь у Data ONTAP есть встроенный в OS движок антивирусного контроля и защиты. В настоящий момент лицензированы продукты Sophos и McAfee

Больше о работе и управлении в кластере – в следующем посте этой серии.

Этот год для компании NetApp станет, без сомнения, “годом cluster-mode”. Наконец-то этот режим “дозрел” до широкого рынка, и в этом году, я надеюсь, мы увидим активность во внедрении именно этой, до сих пор для массового пользователя остававшейся в тени, но весьма многообещающей возможности систем хранения NetApp.

Для начала же несколько слов о том, что такое Data ONTAP Cluster-mode, и чем он отличается от привычного Data ONTAP 7-mode в HA-кластере.

Еще в 2003 году NetApp купила стартап Spinnaker, занимавшийся разработками в области кластерных файловых систем и системы Global Namespace, и несколько лет спустя выпустила на рынок специальную OS, под названием Data ONTAP 10. Это была специальная OS для систем NetApp, позволявшая строить многоузловые кластеры хранения данных. К сожалению, она имела множество ограничений, в частности, работала только как NFS-сервер, и не имела множества важных и привычных возможностей “классической” Data ONTAP 7.x, поэтому особой популярности не завоевала, была дорогой, ограниченной, требовавшей значительных специальных знаний для запуска и использования, и, в результате, ее использование было ограничено рынком высокопроизводительных файловых серверов для HPC (High-performance Computing) и систем хранения научной и аудио-видео информации. Общее число клиентов в мире, использовавших Data ONTAP 10, не превышало пары сотен.

Следующим шагом NetApp, стала попытка объединить, “слить” две эти OS в одну. Однако объявленное в 2008 году “слияние” оказалось в значительной степени “фиктивным”, просто из одного дистрибутива OS, получившей название Data ONTAP 8.x стало возможным установить две OS: либо в режиме 7-mode, то есть “классической” Data ONTAP, либо в режиме, получившем название “Cluster-mode”, и явившемся развитием Data ONTAP 10. К сожалению это были, как я сказал выше, просто две OS, ставившихся из одного дистрибутива, и только. В Cluster-mode не появились привычные возможности Data ONTAP Classic, и по-прежнему это были две несовместимые OS, не имевшие возможности миграции данных или взаимодействия, полностью отличавшихся по структурам хранения данных и работе с ними.

Вследствие этого, имеющиеся пара сотен клиентов DOT10 были переведены на 8.x Cluster-mode, а основная масса пользователей систем NetApp по прежнему продолжала пользоваться “7-mode”. Значительным барьером, кроме функциональных ограничений, была и цена, а также сложность реализации.

Однако работы продолжались, и, постепенно, в 8.x Cluster-mode стали появляться привычные для 7-mode возможности, такие как репликация, блочная дедупликация, а также, что более всего важно, работа с блочными протоколами – FC, iSCSI и FCoE. Напомню, что, до версии 8.1, Cluster-mode была чисто “файловым хранилищем”, работающем по протоколам NFS и CIFS, что устраивало не всех.

Тем временем, как NetApp “переваривала” наследство Spinnaker, на рынке стали появляться конкуренты в данной области, так активно стал продаваться (и в итоге продался целиком EMC) продукт компании Isilon, а растущий интерес к “облачным” IT-системам естественным образом стал “локомотивом” развития и “облаков” хранения - многоузловых кластеров.

??так, начиная с версии Data ONTAP 8.1 версия Cluster-mode стала уметь работать с блочными SAN-протоколами, стала уметь асинхронную репликацию и снэпшоты, привычные для Data ONTAP Classic, дедупликацию и компрессию, наконец, были снижены цены, и использование Cluster-mode стало несколько более доступным для пользователей.

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