Как построить катастрофоустойчивость с zVirt

• мультипасинг;
• высокая доступность ВМ (HA).

1. Мультипасинг

В первую очередь ознакомьтесь с рекомендациями производителя СХД. Если рекомендуются собственные драйверы для мультипасинга и они реализованы для zVirt, то используйте их. В нашем случае используется встроенный механизм в zVirt – MAIPU.

Для метрокластера СХД необходимо включить ALUA (Asymmetric Logical Unit Access) – ассиметричный доступ до СХД по принципу «Active-Active».

• Load balancing – баланс нагрузки ввода-вывода по всем путям.
• Asymmetric (ALUA) – хост определяет оптимальные и неоптимальные пути для операций ввода-вывода.

Если использовать режим «Asymmetric», то каждый хост будет писать на свой локальный массив. И если пропадет доступ к локальному хранилищу, то будут использоваться резервные пути до удаленного массива.

Но СХД MAIPU к такой конфигурации не готова, так как ALUA не поддерживается для MetroLUN.

Для настройки мультипасинга с СХД MAIPU на каждом хосте виртуализации применяется следующая конфигурация:

[root@znode1 ~]# cat /etc/multipath/conf.d/maipu.conf

devices {

device {

           vendor                      "Storage"

           product                     "LU"

           path_grouping_policy        multibus

           path_checker                tur

           prio                        const

           path_selector               "service-time 0"

           failback                    immediate

           no_path_retry               15

‍

}

}

2. HA (High Availability) – высокая доступность виртуальных машин. Система ведет мониторинг состояния ВМ с целью выявления сбоев ОС или физических серверов. При обнаружении сбоя ВМ автоматически перезапускаются на другом физическом сервере кластера высокой доступности.

Смоделируем сценарий отказа СХД в основном ЦОД.

1. Перед началом работ проверяем наличие путей до MetroLUN СХД со всех хостов виртуализации командой multipath -ll.

Вывод выполнения команды приведен ниже.

Из примера видим, что статусы путей – «active», «ready» и «running». Это означает, что все пути активны и готовы для передачи данных. Также видим, что каждый MetroLUN доступен по восьми путям: по четыре с каждой СХД.

2. Выполняем выключение СХД в «резервном ЦОД».

3. После выключения СХД командой multipath -ll на хостах виртуализации проверяем доступность путей до СХД.

Вывод выполнения команды multipath -ll после выключения СХД РЦОД приведен ниже.

Из примера видим, что ровно половина путей оказалась в статусах «failed», «faulty» и «running». При этом MetrLUN продолжают быть доступны хостам по оставшейся работоспособной половине путей.

4. Выполняем проверку со стороны системы виртуализации zVirt.

В логах на примере видим ошибки доступности путей.

5. Проверяем доступность LUN и ВМ со стороны системы виртуализации.

На примерах ниже видно, что все машины и виртуальные диски, которые размещены на MetroLUN, продолжают успешно функционировать на тех же хостах системы виртуализации.

‍

‍

Метрокластер СХД и zVirt HA успешно справились со своей работой. ВМ продолжают функционировать, а данные на них находятся в целости и сохранности.

Далее необходимо вернуть стенд в исходное состояние.

6. Выполняем включение СХД и снова проверяем доступность СХД хостам командой multipath -ll.

Вывод выполнения команды представлен ниже.

‍

Как видно из примера, СХД снова доступна хостам по всем восьми путям, о чем сигнализируют статусы «active», «ready, running». 

Арбитр часто устанавливают на оборудование, в котором при работе возможны downtime (время простоя). «Переживет» ли такой downtime арбитра наш метрокластер? Разбираем на следующем примере.

1. Выполняем выключение ВМ с ПО арбитра MAIPU, размещенной на третьей удаленной облачной площадке.

2. Проверяем сообщение о потери связи с арбитром в логах СХД. Сообщение в логах приведено ниже:

3. Проверяем доступность путей от хостов системы виртуализации до СХД с помощью команды multipath -ll.

Вывод выполнения команды multipath -ll после выключения арбитра приведен ниже.

‍

Как видно из примера, MetroLUN доступны хостам по всем путям, о чем сигнализируют статусы «active», «ready», «running». Со стороны системы виртуализации сообщений об ошибках не поступает. ВМ функционируют штатно, данные на них доступны. Арбитр не потерян.

4. Возвращаем стенд в исходное состояние.

5. Выполняем включение ВМ с ПО арбитра MAIPU.

После возращения связи с арбитром СХД сообщает о его доступности: Arbiter_reachable, что отображено ниже.

Смоделируем ситуацию повреждения всех каналов связи между ЦОД.

1. Выключаем порты FC-коммутаторов, к которым подсоединены линки для организации взаимодействия двух СХД MAIPU.

Арбитр метрокластера отрабатывает штатно: MetroLUN становятся доступны только с одной СХД. На примере видим соответствующие уведомления в логах СХД.

2. Со стороны хостов системы виртуализации проверяем доступность СХД с помощью команды multipath -ll.

Вывод выполнения команды multipath -ll после разрыва интерконнекта СХД приведен ниже.

‍

Как видно из примера, половина путей оказались в статусах «failed», «ghost», «running». Статус «ghost» сигнализирует о том, что пути физически существуют, но были замаскированы, в отличии от статуса «faulty» в сценарии с физическим отключением СХД по питанию.

3. Проверяем MetroLUN со стороны СХД. Как видно из примера ниже, в параметре Health Status отображается статус «Normal». Это означает, что MetroLUN функционирует штатно.

‍

‍Падение показателей IOPS или недоступность данных со стороны СХД в ходе выполнения теста не наблюдается.

4. Выполняем проверку доступности MetroLUN и ВМ со стороны системы виртуализации zVirt.

‍

‍

Как видно из примеров, все машины, виртуальные диски которых размещены на MetroLUN, продолжают успешно функционировать на тех же хостах системы виртуализации.

Этот тест является имитационным. В реальной ситуации потери каналов связи между ЦОД связь также пропадет для половины хостов кластера. Останутся доступны только те хосты, которые доступны менеджеру виртуализации Hosted Engine. ВМ, расположенные на недоступных хостах, перезапустятся на оставшихся доступными хостах кластера благодаря штатным механизмам zVirt High Availability (HA).

5. Выполняем восстановление репликационных соединений.

После восстановления репликационных соединений все пути на хостах системы виртуализации вернулись в норму. На примере ниже приведен вывод выполнения команды multipath -ll после восстановления репликационных соединений.

6. Проверяем, что все MetroLUN со стороны СХД вернулись в состояние «Синхронизированы». На примере приведен статус MetroLUN в графическом интерфейсе управления СХД.

Наш метрокластер справился и с этим случаем.