Переход на NetApp Clustered Data ONTAP

Clustered Data ONTAP

Давно зарекомендовавшие себя системы хранения NetApp являются по большей части воплощением идеи Software-defined Storage, когда практически вся функциональная начинка устройства лежит внутри собственной операционной системы, такой как Data ONTAP. Компания NetApp продолжает развитие DOT, что дает возможность заказчикам строить горизонтально масштабируемый кластер из набора отдельных контроллеров (до 24).

Почему в последнее время многие организации делают выбор в пользу программно реализуемого Data ONTAP? Объяснение простое: такое решение ничуть не хуже аппаратного по показателям производительности и надежности, даже в определенной степени имеет преимущества, заключающиеся в гибко расширяемой функциональности, что достигается простым обновлением операционной системы.

Общая схема Clustered Data ONTAP

Рисунок 1. Общая схема Clustered Data ONTAP

Суть Clustered Data ONTAP заключается в том, что узлы СХД объединяются в кластер, образуя пул физических ресурсов, доступных для приложений, узлов SAN и клиентов NAS.

Немного о версиях

Если вернуться к истокам ОС Data ONTAP версии 8, компания NetApp в самом начале пути погналась за двумя зайцами, стремясь покрыть потребности клиентов, не готовых к переходу на полностью обновленную архитектуру и ОС, и клиентов, готовых использовать решение для построения многоузловых кластерных систем. Именно поэтому в дистрибутиве Data ONTAP 8.х была реализована поддержка 7.х., что позволяло при установке выбирать классическую ОС Data ONTAP 7-mode или же кластерную, известную как Clustered Data ONTAP (которую еще называют С-mode или Cluster-mode). Поскольку NetApp более не планирует развивать Data ONTAP 7-mode, безусловно, фокус внимания будет направлен на развитие кластерной, облачной реализации. Тем более что в уже вышедшем мартовском релизе Clustered Data ONTAP v 8.3 полностью отказались от 7-mode.

Особенности Clustered Data ONTAP

Чтобы понять, как живет Data ONTAP в кластерном режиме, следует немного абстрагироваться и представить работу гипервизора систем серверной виртуализации, в котором создаются не привычные всем нам виртуальные машины, а так называемые виртуальные системы хранения с данными, известные как SVM (Storage Virtual Machines). Ранее этот термин носил название VServers, что крайне смущало своей неясностью широкую публику и порождало массу различных обсуждений.

SVM (Storage Virtual Machine) — это виртуальная система хранения, которая размещается на одном или нескольких контроллерах кластера Data ONTAP.

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

Очень выгодной особенностью решений NetApp для IaaS-провайдеров, обслуживающих, как правило, немалый парк клиентов, является реализация концепции виртуализации кластеров и многопользовательской среды. Для представления особенностей Clustered Data ONTAP копнем немного в сторону устройства самого кластера.

С точки зрения «физики», кластер — это контроллеры СХД с подключенными дисковыми полками, наличием сетевых адаптеров и кластерной сети (интерконнектов между всеми контроллерами через 10 Гбит Ethernet-коммутаторы). Всё вместе представляет собой пул физических ресурсов, способных виртуализироваться в качестве логических ресурсов кластера, обеспечивая доступ к данным. За счет абстракции и виртуализации физических ресурсов в логические мы получаем гибкость, возможность использования многопользовательской среды, мобильность объектов и по факту бесперебойную работу.

Что побудило нас перейти на Clustered Data ONTAP и как это происходило?

В какой-то момент стало понятно, что размещаться на контроллерах NetApp v6240 под операционной системой Data ONTAP 7-mode не совсем актуально. Как говорится, королевство маловато, разгуляться негде. Решили докупить новое оборудование из линейки FAS, ведь, как известно, оно отличается высокой эффективностью хранения данных с возможностью создания «снэпшотов» без снижения производительности. В числе прочего нас интересовала возможность эффективной блочной дедупликации и кеширования на SSD. Из предлагаемых на рынке унифицированных горизонтально масштабируемых СХД остановились на золотой середине NetApp FAS 8040, руководствуясь соотношением цены, качества и конечного результата. Для перспектив перехода на кластер развернули Clustered Data ONTAP 8.2.2.

Почему не остановились на более поздней версии Clustered Data ONTAP?

В общем, на тот момент ОС Clustered Data ONTAP 8.2.3 P2 еще не была доступной, чего уж говорить про 8.3, которая вышла относительно недавно и ставить которую в продакшен-среде без массовой обкатки и устранения багов совсем нежелательно. Выбрали в некой степени стабильную версию, проверенную на практике.

Сразу хочется отметить несколько важных фактов:

Важный факт 1: в 7-mode объединять контроллеры (HA «ноды» кластера) не представляется возможным, и это минус.

Важный факт 2: переход с 7-mode в Cluster-mode происходит только с форматированием дисков, потому что не реализована так называемая data-in-place миграция. И это снова минус, поскольку все данные наших клиентов нужно забэкапить, имеющийся сторадж «убить», разобрать, переконфигурировать, создать заново в кластерном режиме и вернуть на место все данные.

Решением исходной задачи было копирование всех наших клиентов (все тома) на кластерную NetApp FAS 8040 без простоя, незаметно.

Копирование томов с NetApp v6240 на новое железо FAS 8040

Рисунок 2. Копирование томов с NetApp v6240 на новое железо FAS 8040

Затем начали вводить NetApp v6240 в эксплуатацию на кластерной ОС. Для начала добавили железку в инфраструктуру, отформатировали, установили ОС Clustered Data ONTAP 8.2.2, ввели в кластер и, конечно же, протестировали. Но если бы все получалось так быстро и лаконично, было бы совсем неинтересно. Предлагаем рассмотреть детали.

Подключение «нод» NetApp v6240 к кластеру

С каждым узлом кластера мы проделали ряд предварительных шагов конфигурации.

Шаг 1. Подключили порт node-mgmt для управления «нодой».

Шаг 2. Выделили 2 порта 10G с ролью cluster.

Шаг 3. Выделили 2 порта 10G с ролью data.

Шаг 4. Подключили порт 1G с ролью data для cluster_mgmt LIF (по факту получили 100 Mb, так как были включены в свитч 100 Mb). Поскольку это всего лишь управление, такой показатель не совсем критичен и будет задействован только для переноса кластерного интерфейса управления во время обслуживаний и failover’ов. Роль LIF cluster_mgmt оставили по умолчанию на порту fas8040.

Вывод параметров конфигурации узлов кластера

Рисунок 3. Вывод параметров конфигурации узлов кластера

Теперь, когда каждый «участник» приведен в боевую готовность, самое время выполнить сборку кластера. Для этого подключились к каждой «ноде» v6240 и выполнили команду:

cluster join

После успешного присоединения к кластеру и принятия необходимых настроек смотрим его состояние. Для этого используем команду cluster show. Результат показывает, что 4 узла входят в состав кластера.

Просмотр состояния узлов кластера

Рисунок 4. Просмотр состояния узлов кластера

После вышеописанных шагов произвели настройку времени, даты, временной зоны, сообщений Autosupport, нотификаций и т. д.

Проверка кластера в кворуме

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

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

Когда кластер находится в кворуме, большинство участников являются «здоровыми» и могут взаимодействовать друг с другом. Когда же кворум потерян, кластер неспособен выполнять обычные кластерные операции. Только один набор узлов может иметь кворум в любой момент времени, потому что все «ноды» совместно разделяют единую картину данных. Если бы двум невзаимосвязанным узлам разрешалось изменять данные расходящимися путями, невозможно было бы выполнить согласование единого представления. Каждый узел кластера участвует в голосовании, в котором избирается «нод мастер», а оставшиеся узлы считаются вторичными. Когда кворум сформирован, он поддерживается постоянным голосованием. Если «мастер-нод» переходит в режим офлайн, происходит выбор нового «мастер-нода» из участников, оставшихся онлайн.

Необходимо убедиться, что все узлы кластера участвуют в процессе репликации базы данных кворума (RDB) и все replication ring находятся в кворуме.

Для этого запустили команду:

cluster ring show –unitname vldb

Проверка работоспособности кластера

Результат команды cluster ring show

Рисунок 5. Результат команды cluster ring show

Проверка сетевого подключения

Дальше нужно было убедиться, что сам кластер, интерфейс управления кластером и интерфейс управления узлами настроены верно. Поскольку в кластере более одного узла, необходимо выполнить поочередный пинг каждого узла. Ниже приводим фрагменты полученных результатов.

cluster ping-cluster -node v6240-1a

Результат команды cluster ping

Рисунок 6. Результат команды cluster ping

Полученные значения показывают, что сетевые параметры участников кластера сконфигурированы корректно.

Проверка портов

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

network port show

Результат команды network port show

Рисунок 7. Результат команды network port show

Полученные результаты показывают, что и тут все хорошо.

Проверка конфигурации высокой доступности

Помимо уже проделанных шагов, запустили команду:

network port show

Команда позволяет проверить, что функция отказоустойчивости включена для каждой пары HA. Результат отображен на рисунке 8.

Результат команды storage failover show

Рисунок 8. Результат команды storage failover show

Тестирование отказоустойчивости

Ну и, конечно же, протестировали отказоустойчивость кластера. Не нам вам рассказывать, что это выполнять обязательно. Если кластер состоит более чем из одной «ноды», необходимо проверить, что если какой-либо из узлов станет недоступным, работоспособность кластера не будет потеряна. Это достигается за счет функционирования других «работоспособных» участников. В нашем случае каждая из «нод» готова выполнить перехват в случае failover-а, что продемонстрировано на рисунке ниже.
Тестирование отказоустойчивости кластера

Рисунок 9. Тестирование отказоустойчивости кластера

Проверка системного времени

Синхронизация времени позволяет убедиться в идентичности настройки временных параметров каждого участника кластера, что поможет предотвратить возможные проблемы с CIFS и аутентификацией Kerberos. Для этого в сетевом окружении должен присутствовать NTP-сервер. Для отображения информации о текущей дате, времени и временной зоны каждого узла кластера мы запустили команду:

cluster date show

Результат показывает, что все корректно.

Результат выполнения команды cluster date show

Рисунок 10. Результат выполнения команды cluster date show

Прочие шаги и проверка доступности

После успешных тестов можно было расширяться, следуя общему принципу горизонтального масштабирования.

Для тех, кто не знаком с принципом «горизонтального масштабирования» поясним, что вместо наращивания до предела монолитной СХД, мы получаем кластер из узлов хранения. Они-то и работают как единое целое. Добавив в кластер новую HA-пару, вы можете планировать общий объем дискового пространства и производительность, что позволяет по мере необходимости выполнять последовательное расширение кластера.

Из свободных дисков NetApp v6240 создали агрегат, благодаря чему появилось свободное дисковое пространство, которое мы можем выдавать под нужды vSphere (формировать новые клиентские «датасторы») путем создания новых SVM. Именно через эту сущность происходит доступ всех клиентов к данным. В пределах одного кластера можно создавать до нескольких сотен таких экземпляров SVM. Каждая сущность SVM должна содержать как минимум один том и логический интерфейс.

Создали SVM, data LIF и обязательно failover-group для этого LIF, иначе при падении «домашнего» интерфейса LIF’а он будет мигрироваться по system-defined.

Пример создания нового SVM

Рисунок 11. Пример создания нового SVM

System-defined failover groups представляют собой группы отказоустойчивости для автоматического управления отказоустойчивыми LIF-таргетами, являются группами по умолчанию для data LIF в кластере

Затем создали том и выдали его на vSphere имеющемуся хосту.
Пример созданного тома в имеющемся SVM

Рисунок 12. Пример созданного тома в имеющемся SVM

Дальше выполнили проверку доступности «датасторы» для хоста в зависимости от различных условий:
  • во время takeover/giveback «ноды»;
  • во время manual миграции data LIF’а;
  • во время failover LIF’а (отработка LIF failover group);
  • во время онлайн-миграции тома на агрегат другой «ноды».

Итоги тестирования нас порадовали: сбоев сервисов НЕ было обнаружено!

Поделиться в социальных сетях