Введение

Мы открываем цикл статей на тему обеспечения катастрофоустойчивости ИТ-инфраструктуры, построенной на базе zVirt.

Как спланировать виртуальную инфраструктуру, если у вас два территориально распределенных центра обработки данных (ЦОД) с L2-связностью и вам важно получить околонулевые RTO (Recovery Time Objective, целевое время восстановления) и RPO (Recovery Point Objective, целевая точка восстановления) при потере одного из них? Понадобятся ли для этого специализированный софт и дополнительные лицензии?

В этой статье рассказываем про поддержку технологии метрокластера zVirt и на примере, реализованном в нашей лаборатории, разбираем принцип его работы.

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

• работы кластера серверов на том расстоянии, на которое удалены площадки друг от друга;
• штатного механизма zVirt HA (High Availability). 

В случае потери доступа к СХД на площадке А, в результате работы мультипасинга продолжится работа с данными на площадке Б.

Технология не требует:

• дополнительной установки специальных пакетов;
• наличия стороннего ПО;
• покупки отдельных лицензий.
  
  

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

‍

Подготовка лабораторного стенда

Лабораторный стенд состоит из следующих программных и аппаратных компонентов:

• две СХД;
• четыре сервера;
• одна система виртуализации;
• коммутирующее оборудование.

‍

СХД

Чтобы реализовать решение, мы выбрали две СХД MAIPU MPS5520G2 – All Flash Array. 

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

‍

Серверы

1. Развертываем четыре сервера Dell PowerEdge M620:

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

‍

2. Объединяем все серверы в единый кластер, назовем его «zVirt-demo-CL1».

‍

Примечание: вы можете выбрать любую модель сервера из списка поддерживаемых со стороны zVirt. 

‍

Система виртуализации

Развертываем zVirt в режиме Self-Hosted Engine.

Примечание: можно выбрать любую версию zVirt. В нашем случае используется версия 3.1.1.

‍

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

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

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

‍

‍

‍

‍

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

‍

‍

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

‍

‍

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

‍

‍

‍

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

‍

‍

‍

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

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

• Peer Device Online Status – Online;
• Peer Device Health Status – Normal.

‍

‍

‍

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

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

Для установки сервера-арбитра доступна одна из следующих рекомендуемых вендором версий операционной системы:

CentOS 6.5, CentOS 7.3, CentOS 8.0.

Требования по ресурсам ПО для виртуальной машины арбитра:

• 4 ГБ vRAM;
• 2 vCPU;
• 30 GB HDD.

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

‍

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

‍

‍

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

‍

‍

‍

‍

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

‍

‍

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

Необходимо выполнить создание пулов и LUN на каждой СХД.Для создания пулов необходимо перейти в меню Storage -> Pool -> Create. Настройки пулов приведены ниже:

‍

‍

‍

‍

‍

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

‍

Переходим к созданию LUN.

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

‍

‍

‍

‍

LUN созданы:

‍

‍

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

‍

4. Презентация LUN хостам

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

‍

‍

‍

‍

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

Далее необходимо указать, какие порты будут использоваться для инициаторов хостов zVirt:

‍

‍

‍

5. Создание metro-LUN

Необходимо собрать созданные на шаге 3 LUN в Consistency Groups и собрать пары. Для этого необходимо перейти в меню Service -> Consistency Groups -> Create. Настройки групп приведены ниже:

‍

‍

‍

Через меню группы Properties необходимо выставить скорость синхронизации СХД:

‍

‍

Для настройки пар необходимо перейти в меню Service –> Dual-Active. Настройки пар приведены ниже:

‍

‍

‍

‍

‍

‍

‍

‍

Выполняем презентацию LUN хостам с двух СХД поочередно через меню Client -> I_T Connection -> Map LUN:

‍

‍

‍

‍

‍

‍

‍

MetroLUN синхронизированы и презентованы серверам по FC 8 Гбит/с. Используется перекрестное соединение: каждая СХД презентует LUN каждому серверу. 

‍

6. Создание доменов хранения со стороны системы виртуализации

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

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

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

1. Имитация полного отказа СХД основного ЦОД.
2. Имитация полного отказа арбитра метрокластера.
3. Имитация отказа каналов передачи между основным и резервным ЦОД.

‍

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

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

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 в графическом интерфейсе управления СХД.

‍

‍

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

‍

Заключение

‍

На трех примерах мы продемонстрировали, как zVirt работает с метрокластером СХД и насколько просто это настраивается на стороне системы виртуализации благодаря встроенным средствам. Этот способ обеспечения катастрофоустойчивости идеально подойдет для сценариев защиты бизнес-критичных систем в инфраструктурах на базе двух ЦОД, расположенных на небольшом удалении друг друга.

‍

‍

‍