Привет, Хабр! Меня зовут Александр Гавриленко, я занимаюсь интеграциями продуктов в инфраструктурах заказчиков Orion soft. За последние 2 года количество задач, связанных с организацией устойчивой виртуальной инфраструктуры на 2 и более территориально распределенных ЦОДа (со связностью L2), значительно выросло.

Поэтому сегодня я хочу начать разговор про обеспечение катастрофоустойчивости ИТ-инфраструктуры, построенной на базе zVirt. В этой статье я расскажу про поддержку технологии метрокластера, но не в теории, а на практике. В лаборатории Orion soft был собран тестовый стенд с реально работающей схемой резервирования Active-Active. А под катом вы найдете не только полезные схемы и рекомендации, но также результаты тестирования катастрофоустойчивой конфигурации.

Давайте разберемся, как в случае аварийного восстановления инфраструктуры в РЦОД можно добиться околонулевых RTO и RPO. Нужен ли для этого специализированный софт и дополнительные лицензии?

Собираем метрокластер

Метрокластер zVirt опирается на решение Active-Active метрокластера СХД и реализуется средствами СХД. Роль гипервизора в этом решении заключается в поддержке:

• работы кластера серверов на том расстоянии, на которое удалены площадки друг от друга;

• штатного механизма zVirt HA (High Availability), когда в случае потери доступа к СХД на площадке А, в результате работы мультипасинга, продолжится работа с данными на площадке Б.

Плюсы такой технологии в том, что она не требует:

• дополнительной установки специальных пакетов;

• наличия стороннего ПО;

• покупки отдельных лицензий.

Со стороны СХД также не требуется дополнительных коннекторов и лицензий для работы с zVirt. Достаточно лицензии, активирующей функциональность метрокластера СХД.

Подготовка стенда

Наш стенд, на котором мы проверяли работу метрокластера, состоит из следующих программных и аппаратных компонентов:

• две СХД;

• четыре сервера;

• одна система виртуализации;

• коммутирующее оборудование.

СХД

Чтобы реализовать такое решение, мы выбрали две СХД MAIPU MPS5520G2 — All Flash Array. Почему MAIPU? Потому что это один из немногих вендоров, который обладает технологией метрокластера СХД и официально представлен на рынке РФ на момент нашего тестирования.

Серверы

В принципе можно выбрать любой сервер, поддерживаемый zVirt, но в нашем стенде были использованы четыре сервера Dell PowerEdge M620:

• два сервера имитируют размещение в основном ЦОД;

• два сервера — в резервном ЦОД. 

Объединяем все серверы в единый кластер и назовем его «zVirt-demo-CL1». После этого устанавливаем zVirt в режиме Self-Hosted Engine.

Настройка метрокластера

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

Для этого выполняем поиск удаленного массива на вкладке Service -> Remote Device, как показано ниже:

На добавленном массиве BOBA связь появится в меню Service – Remote Devices автоматически.

После настройки связности массивов необходимо добавить XAN-сеть для интерконнекта. В качестве протокола для интерконнекта в нашем случае используется Fc.

Укажем порты для XAN-сети:

Дожидаемся установления связи между массивами, после чего будут получены WWPN:

Действия по добавлению XAN-сети необходимо повторить для второго массива.

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

• Peer Device Online Status — Online;

• Peer Device Health Status — Normal.

Этап настройки связи между массивами успешно выполнен.

Настройка арбитра

Для установки сервера‑арбитра доступна одна из следующих рекомендуемых вендором версий операционной системы — CentOS 6.5, CentOS 7.3, CentOS 8.0.

Ниже — требования по ресурсам по для виртуальной машины арбитра:

• 4 ГБ vRAM

• 2 vCPU

• 30 GB HDD

Арбитр необходимо размещать на отдельной, относительно размещения СХД, площадке.

Устанавливаем пакет сервера-арбитра, выполняем проверку его работоспособности:

Выполним включение арбитра со стороны СХД:

На второй СХД информация о добавленном арбитре появится автоматически. 

Создание пулов и LUN

Чтобы все работало, необходимо выполнить создание пулов и metro-LUN на каждой СХД.

Для создания пулов переходим в меню Storage → Pool → Create. Настройки, которые нужно сделать, показаны на скриншотах ниже:

На второй СХД необходимо создать идентичный по характеристикам пул.

Создаем metro-LUN

Всего создадим по 3 LUN на каждом массиве в меню Storage → LUN → Create. Настройки LUN приведены на скриншотах ниже:

LUN созданы:

На второй СХД необходимо создать 3 идентичных по характеристикам LUN.

Презентуем LUN хостам

После выполнения процедуры зонинга на коммутаторах необходимо дать имена инициаторам в меню Client – I_T Connection и указать, какая ОС будет использоваться. Для zVirt Node выбираем профиль Linux.

На второй СХД проводим аналогичную процедуру. После этого необходимо указать, какие порты будут использоваться для инициаторов хостов zVirt:

Создаем metro-LUN

1. На MetroLUN VM_BIBA средствами системы виртуализации zVirt создаем домен хранения DATA, в котором будут разворачиваться 10 тестовых ВМ;

2. На отдельных виртуальных ресурсах (вне кластера zVirt, участвующего в тестировании) развертываем сервер-арбитр метрокластера.

Процесс работы zVirt с метрокластером

Итак, для поддержки метрокластера СХД нам важны:

• мультипасинг;

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

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

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

Для метрокластера СХД необходимо включить ALUA (Asymmetric Logical Unit Access) — это ассиметричный доступ до СХД по принципу Active-Active. Для этого на стороне СХД выполняется настройка подключения хостов при помощи опции Host Access Mode. Значения могут быть следующими:

• 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 или высокая доступность виртуальных машин. 

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

Для успешного использования метрокластера для нас важны две настройки HA:

• В свойствах HA виртуальной машины, размещаемой на метрокластере, параметр HA должен быть true;

• Целевой домен хранения для аренды ВМ (Target Storage Domain for VM Lease) — должен быть выбран домен хранения, соответствующий MetroLUN. Данный параметр поможет избежать split-brain ситуации. К примеру, для случаев, если хост, на котором запущена ВМ, перестал быть доступным, но связь с доменом хранения не нарушена.

Следующий за ним параметр «Действие (Resume Behavior)» при этом автоматически переключится в «Принудительно завершить (Kill)» — этот вариант рекомендуется для виртуальных машин с признаком высокой доступности, чтобы Менеджер управления мог перезапустить их на другом хосте, где нет ошибки ввода-вывода хранилища.

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

А теперь самое интересное — тестирование отказоустойчивости в разных сценариях: 

• Имитации полного отказа СХД основного ЦОД;

• Имитации полного отказа арбитра метрокластера;

• Имитации отказа каналов передачи между основным и резервным ЦОД.

Имитация полного отказа СХД основного ЦОД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имитация полного отказа арбитра метрокластера

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

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

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

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

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

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

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

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

Имитация отказа каналов передачи между основным и резервным ЦОДами

Представим, что Datacenter Interconnect не имеет дублирования. Это значит, что мы не защищены от повреждения всех кабелей между ЦОДами. Проверим, что будет, если перерубить один их них.

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

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

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

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

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

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

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

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

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

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

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

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

К счастью, наш метрокластер справился и с этим случаем. 

Заключение

На трех примерах мы продемонстрировали, как zVirt работает с метрокластером СХД. Я думаю, вы убедились в том, насколько просто это настраивается на стороне системы виртуализации благодаря встроенным средствам и сможете повторить подобные конфигурации прямо по этой статье (не забудьте сложить ее в закладочку).

Такой способ обеспечения катастрофоустойчивости идеально подойдет для сценариев защиты бизнес-критичных систем в инфраструктурах на базе двух ЦОД, расположенных на небольшом удалении друг друга. А другие способы создания катастрофоустойчивых систем на базе zVirt — в следующих сериях ?