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

Clustered Data ONTAP

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

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

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

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

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

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

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

Шаг 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.

cluster join

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

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

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

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

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

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

cluster ring show –unitname vldb

cluster ping-cluster -node v6240-1a

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

network port show

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

network port show

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

cluster date show

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

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

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

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

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