Привет, Хабр! Меня зовут Александр Гавриленко, я занимаюсь интеграциями продуктов в инфраструктурах заказчиков 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
-
На MetroLUN VM_BIBA средствами системы виртуализации zVirt создаем домен хранения DATA, в котором будут разворачиваться 10 тестовых ВМ;
-
На отдельных виртуальных ресурсах (вне кластера zVirt, участвующего в тестировании) развертываем сервер-арбитр метрокластера.
Процесс работы zVirt с метрокластером
Итак, для поддержки метрокластера СХД нам важны:
-
мультипасинг;
-
высокая доступность ВМ (HA).
-
Мультипасинг
Чтобы все работало, в первую очередь нужно ознакомиться с рекомендациями производителя СХД. Например, если рекомендуются собственные драйверы для мультипасинга, и они реализованы для 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
}
}
-
HA или высокая доступность виртуальных машин.
Суть в том, что система ведет мониторинг состояния ВМ с целью выявления сбоев ОС или физических серверов. При обнаружении сбоя ВМ автоматически перезапускаются на другом физическом сервере кластера высокой доступности.
Для успешного использования метрокластера для нас важны две настройки HA:
-
В свойствах HA виртуальной машины, размещаемой на метрокластере, параметр HA должен быть true;
-
Целевой домен хранения для аренды ВМ (Target Storage Domain for VM Lease) — должен быть выбран домен хранения, соответствующий MetroLUN. Данный параметр поможет избежать split-brain ситуации. К примеру, для случаев, если хост, на котором запущена ВМ, перестал быть доступным, но связь с доменом хранения не нарушена.
Следующий за ним параметр «Действие (Resume Behavior)» при этом автоматически переключится в «Принудительно завершить (Kill)» — этот вариант рекомендуется для виртуальных машин с признаком высокой доступности, чтобы Менеджер управления мог перезапустить их на другом хосте, где нет ошибки ввода-вывода хранилища.
Тестирование отказоустойчивости
А теперь самое интересное — тестирование отказоустойчивости в разных сценариях:
-
Имитации полного отказа СХД основного ЦОД;
-
Имитации полного отказа арбитра метрокластера;
-
Имитации отказа каналов передачи между основным и резервным ЦОД.
Имитация полного отказа СХД основного ЦОД
Представим, что администратор выключил не тот массив или пролил на него кофе. Или массив затопили соседи сверху.
-
Перед началом работ проверяем наличие путей до MetroLUN СХД со всех хостов виртуализации командой multipath -ll.
Статусы путей — active, ready и running. Это означает, что все пути активны и готовы для передачи данных. Также видим, что каждый MetroLUN доступен по восьми путям: по четыре с каждой СХД
-
Выполняем выключение СХД в резервном ЦОД
-
После выключения СХД командой multipath -ll на хостах виртуализации проверяем доступность путей до СХД
На скриншоте видно, что ровно половина путей оказалась в статусах «failed», «faulty» и «running». При этом MetroLUN продолжают быть доступны хостам по оставшейся работоспособной половине путей;
-
Выполняем проверку со стороны системы виртуализации zVirt.
В логах видны ошибки доступности путей
-
Проверяем доступность LUN и ВМ со стороны системы виртуализации.
На скриншотах видно, что все машины и виртуальные диски, которые размещены на MetroLUN, продолжают успешно функционировать на тех же хостах системы виртуализации.
Метрокластер СХД и zVirt HA успешно справились со своей работой. ВМ продолжают функционировать на благо бизнеса, а данные на них находятся в целости и сохранности.
Далее необходимо вернуть стенд в исходное состояние.
-
Выполняем включение СХД и снова проверяем доступность СХД хостам командой multipath -ll.
СХД снова доступна хостам по всем восьми путям, о чем сигнализируют статусы «active», «ready», «running». А значит, можем перейти к следующему примеру.
Имитация полного отказа арбитра метрокластера
Арбитр часто устанавливают на оборудование, в котором при работе возможны downtime. Переживет ли такой downtime арбитра наш метрокластер?
-
Выполняем выключение ВМ с ПО арбитра MAIPU, размещенной на третьей удаленной облачной площадке
-
Проверяем сообщение о потери связи с арбитром в логах СХД
-
Проверяем доступность путей от хостов системы виртуализации до СХД с помощью команды multipath -ll
Как видно на скриншоте, MetroLUN доступны хостам по всем путям, о чем сигнализируют статусы «active», «ready», «running». Со стороны системы виртуализации не получаем каких-либо сообщений об ошибках. ВМ функционируют штатно, данные на них доступны. Арбитр не потерян.
4. Возвращаем стенд в исходное состояние
5. Выполняем включение ВМ с ПО арбитра MAIPU.
После возвращения связи с арбитром СХД сообщает о его доступности: Arbiter_reachable
Имитация отказа каналов передачи между основным и резервным ЦОДами
Представим, что Datacenter Interconnect не имеет дублирования. Это значит, что мы не защищены от повреждения всех кабелей между ЦОДами. Проверим, что будет, если перерубить один их них.
-
Выключаем порты FC-коммутаторов, к которым подсоединены линки для организации взаимодействия двух СХД MAIPU.
Арбитр метрокластера отрабатывает штатно: MetroLUN становятся доступны только с одной СХД.
2. Со стороны хостов системы виртуализации проверяем доступность СХД с помощью команды multipath -ll.
Как результат, половина путей оказались в статусах «failed», «ghost», «running». Статус «ghost» сигнализирует о том, что пути физически существуют, но были замаскированы, в отличии от статуса «faulty» в сценарии с физическим отключением СХД по питанию.
3. Проверяем MetroLUN со стороны СХД. Как видно на скриншоте, в параметре Health Status отображается статус «Normal». Это означает, MetroLUN функционирует штатно.
Падение показателей IOPS или недоступность данных со стороны СХД в ходе выполнения теста не наблюдается.
-
Выполняем проверку доступности MetroLUN и ВМ со стороны системы виртуализации zVirt
Все машины, виртуальные диски которых размещены на MetroLUN, продолжают успешно функционировать на тех же хостах системы виртуализации.
Нужно, конечно, понимать, что наш тест является имитационным. В реальной ситуации, когда потеряны каналы связи между ЦОДами, связь также пропадет с половиной хостов кластера. Останутся доступны хосты, размещенные на одной площадке с менеджером виртуализации Hosted Engine. ВМ, расположенные на недоступных хостах, благодаря штатным механизмам zVirt HA, перезапустятся на оставшихся доступных хостах кластера.
-
Выполняем восстановление репликационных соединений.
После восстановления репликационных соединений все пути на хостах системы виртуализации вернулись в норму.
-
Проверяем, что все MetroLUN со стороны СХД вернулись в состояние «Синхронизированы».
К счастью, наш метрокластер справился и с этим случаем.
Заключение
На трех примерах мы продемонстрировали, как zVirt работает с метрокластером СХД. Я думаю, вы убедились в том, насколько просто это настраивается на стороне системы виртуализации благодаря встроенным средствам и сможете повторить подобные конфигурации прямо по этой статье (не забудьте сложить ее в закладочку).
Такой способ обеспечения катастрофоустойчивости идеально подойдет для сценариев защиты бизнес-критичных систем в инфраструктурах на базе двух ЦОД, расположенных на небольшом удалении друг друга. А другие способы создания катастрофоустойчивых систем на базе zVirt — в следующих сериях 🙂
ссылка на оригинал статьи https://habr.com/ru/articles/828182/
Добавить комментарий