Программная репликация хорошо работает, пока у вас не появляются высоконагруженные базы или файловые хранилища. Тогда гипервизор начинает тормозить. Ему приходится одновременно обслуживать приложения и копировать данные на резервную площадку.
Мы решили эту проблему, добавив в наш zVirt управление синхронной репликацией на уровне СХД YADRO TATLIN.UNIFIED. В результате репликацией можно управлять прямо из интерфейса, настраивать автоматические планы восстановления. Производительность приложений не страдает, время восстановления сокращается до минут.
Меня зовут Стас Борисов, я архитектор в команде zVirt в Orion soft.В этой статье расскажу, чем отличается аппаратная репликация от программной, как она работает изнутри и почему наши заказчики просили добавить в решение репликацию именно на уровне СХД. Еще посмотрим, как это все настроить, начиная с репликационной пары до восстановления всей инфраструктуры.
Как выбрать тип репликации данных: простота и/или производительность
Существует два принципиально разных подхода к репликации данных — программный и аппаратный. От выбора зависит скорость работы приложений, нагрузка на серверы и ограничения системы.
Чем они отличаются, и чем именно хороша аппаратная репликация СХД?
Программная репликация выполняется на уровне гипервизоров. Гипервизор отслеживает изменения в данных ВМ и передает копии на резервные серверы. Эта задача ложится на плечи серверов виртуализации — они должны одновременно обслуживать пользователей и заниматься репликацией.
У такого подхода есть свои плюсы. Работает с любыми СХД, не требует специального оборудования. Можно использовать системы хранения, которые уже есть в инфраструктуре.
Но за универсальность приходится платить. Репликация съедает ресурсы серверов — процессор, память, сеть. При высоких нагрузках производительность критически важных приложений проседает.
Главная проблема в том, что не все приложения можно реплицировать программно. Высоконагруженные базы данных, системы с интенсивной дисковой активностью создают слишком большую нагрузку на гипервизор. В результате либо тормозят приложения, либо репликация работает нестабильно.
Аппаратная репликация переносит задачу на систему хранения данных. СХД сама отслеживает изменения блоков данных и синхронизируется с парной системой на резервной площадке. Такой подход решает ключевые проблемы программной репликации. Можно реплицировать любые приложения без оглядки на нагрузку. И высоконагруженные базы данных, и системы с интенсивной дисковой активностью работают без потери производительности. СХД изначально спроектирована для таких задач и имеет специальные ресурсы: выделенные процессоры, кэш, сетевые каналы.
Серверы виртуализации полностью освобождаются от задач репликации. Ресурсы процессора, памяти и сети остаются для основной работы. СХД справляется с репликацией эффективнее гипервизора.
Главный минус — зависимость от возможностей оборудования. Не все СХД поддерживают репликацию. Те, что поддерживают, обычно работают только с парными СХД того же производителя и модели. Это ограничивает выбор поставщиков, но обеспечивает максимальную скорость и стабильность.
Как работает каждый подход
Механизмы репликации принципиально различаются. Программная репликация использует функциональность снапшотов (моментальных снимков). Система постоянно создаёт снимки данных на основной площадке и через определенные интервалы передает накопленную дельту на резервную площадку.
Проблема в том, что высоконагруженные ВМ могут генерировать изменений больше, чем успевает передаваться. Например, база данных с интенсивной записью в табличное пространство за период репликации накопит столько изменений, что их передача займет больше времени, чем сам период.
Получается замкнутый круг, и репликация постоянно «наступает на хвост» сама себе. Один цикл репликации не успел закончиться, а уже начинается следующий, потому что передача не укладывается в отведенное время. Цикл становится бесконечным и блокирует нормальную работу приложений.
Аппаратная репликация работает совершенно по-другому. ВМ пишут данные напрямую на СХД без создания снапшотов.
Система хранения самостоятельно отслеживает все изменения на уровне блоков данных и синхронизируется с парной СХД в реальном времени. Никаких интервалов, никакого накопления дельты. Данные реплицируются по мере поступления.
Именно поэтому аппаратная репликация справляется с любыми нагрузками. СХД не ждет окончания интервала и не пытается передать гигабайты накопленных изменений за раз. Она работает постоянно, небольшими порциями, используя специально выделенные для этого ресурсы.
Но за высокую производительность приходится платить требованиями к инфраструктуре. Особенно к каналам связи между площадками. При синхронной репликации операция записи подтверждается только после попадания данных на удаленную СХД. Куда именно попадают данные, в кэш или сразу на диски, зависит от настроек или архитектуры СХД. Время отклика напрямую зависит от производительности репликационного канала.
Мы видим, что выбор типа репликации определяет архитектуру всей системы резервирования. Программная подходит для небольших нагрузок, аппаратная решает проблемы производительности, но требует специализированных СХД.
На российском рынке такого решения не было. Мы давно работаем с YADRO, знаем их платформу, поэтому решили сделать интеграцию вместе. Результат появился в релизе zVirt 4.3. Теперь разберем, как технически устроена такая репликация в связке zVirt и СХД YADRO.
Как организована репликация в zVirt с СХД
Архитектура построена на двух независимых площадках, соединенных сетью L2/L3. Каждая содержит центр данных с кластером zVirt, ВМ и системой хранения данных.
Основная площадка включает несколько узлов zVirt с работающими ВМ Hosted Engine для управления кластером и СХД в режиме чтения/записи (R/W).
Резервная площадка дублирует архитектуру — те же узлы zVirt, собственный Hosted Engine и СХД в режиме только чтения (R/O). При нормальной работе ВМ на резервной площадке неактивны.
Требования к СХД: рекомендуется использовать идентичные системы хранения (одно поколение, одинаковые версии ПО и конфигурации).
Однако некоторые СХД, включая решения YADRO, поддерживают асимметричные конфигурации для репликации данных. Например, можно развернуть:
TATLIN.UNIFIED Gen2 — на основной площадке;
TATLIN.UNIFIED Gen1 — на резервной.
Поддерживаемые СХД: в zVirt реализована поддержка YADRO TATLIN.UNIFIED Gen1/Gen2 и Huawei Dorado серий 3000, 5000, 6000.
API хранилища интегрирует zVirt с системами хранения через транспортный уровень. Платформа виртуализации получает готовый интерфейс для управления репликацией без прямой работы с СХД.
Принцип работы репликации
СХД-репликация создает копию тома на удаленной системе хранения. При активной репликации серверы могут записывать данные только в том на локальной СХД. Одновременный доступ к тому на обеих площадках исключен.
Режимы репликации:
Синхронная — подтверждение записи только после фиксации данных на обеих СХД.
RPO = 0
Для достижения высокой производительности подсистемы ввода-вывода между площадками необходимо обеспечить высокоскоростные и надежные каналы связи.
Асинхронная — подтверждение сразу после локальной записи, передача на удаленную площадку происходит независимо.
RPO > 0
Не накладывает жестких условий на каналы связи. Это компромисс между производительностью и надежностью, он подходит для сценариев, где допустима небольшая потеря данных в обмен на скорость работы.
Сценарии переключения
Плановое переключение. Используется для проведения плановых регламентных работ: модуль zVirt DR останавливает работу всех ВМ, располагаемых на реплицируемом домене хранения, отключает домен хранения, разворачивает направление репликации и активирует том на резервной площадке, после чего запускает виртуальную инфраструктуру на резервной площадке.
Аварийное переключение. Используется при отказе ключевого компонента, который не позволяет далее оказывать сервис на площадке: Модуль zVirt DR немедленно разворачивает репликацию и активирует резервный том на резервной площадке, далее запускает виртуальную инфраструктуру.
Системы хранения автоматически адаптируют режимы репликации при проблемах со связью, позволяя продолжить работу с локальными данными.
Как система восстанавливает работу при сбоях
Репликация данных — только часть задачи. Главной целью администратора остается быстро восстановить работоспособность всей виртуальной среды, когда основной сайт выходит из строя.
Модуль DR избавляет от ручной работы. Вместо разбора низкоуровневых операций администратор выбирает готовый план аварийного восстановления и запускает его. Система автоматически проверяет репликационный линк, анализирует состояние СХД и активирует домен хранения на резервной площадке.
Запуск ВМ происходит по заданным приоритетам. Можно разделить виртуальную среду на блоки — инфраструктурные сервисы, ИТ-подсистемы, бизнес-приложения — и настроить очередность их подъема. Сначала стартуют инфраструктурные подсистемы, затем высокоприоритетные бизнес-задачи. Внутри каждой группы тоже можно задать порядок. Например, сначала сервер базы данных, потом приложения.
Резервная площадка часто слабее основной. Можно заранее настроить пониженные параметры CPU и памяти. Тогда получится режим выживания вместо простоя. При L3-связности между площадками система автоматически назначает новые IP-адреса, что критично для географически удаленных площадок.
В результате получаем работающую инфраструктуру за минуты, а не за часы. От принятия решения о переключении до восстановления работоспособности проходит минимальное время.
Здесь необходимо упомянуть еще один важный момент. Модуль zVirt DR не имеет автоматического механизма переключения ресурсов на резервный сайт — решение и действия по восстановлению работоспособности выполняются администратором виртуальной инфраструктуры вручную. Защита виртуальной инфраструктуры в пределах одного сайта обеспечивается автоматически с помощью механизма High Availability (HA), а в случае нескольких сайтов — в ручном режиме с использованием модуля zVirt DR.
Про теорию я рассказал — от принципов репликации до автоматизации восстановления. Теперь покажу, как настроить это на практике: пошагово создадим репликацию между системами YADRO и настроим план аварийного восстановления в zVirt.
Что нужно настроить перед репликацией
Требования к zVirt
В zVirt нет специальных модулей для репликации — все работает через стандартное API. Нужно подготовить:
Две независимые площадки: основную и резервную с отдельными менеджерами управления.
Сетевую связь между менеджерами для REST API.
Админские права: используйте admin@internal, admin@zvirt@internalsso или создайте пользователя с ролью SuperUser.
Подключение томов: только основные тома к основной площадке, реплики НЕ подключаем.
Требования к СХД
Настройте на стороне систем хранения:
Репликационные пары между основной и резервной СХД (по документации вашей системы).
-
Доступы к томам:
Хосты основной площадки получают доступ к томам основной СХД.
Хосты резервной площадки получают доступ к томам резервной СХД.
Настраиваете доступы только для дата-центров с репликацией.
Сетевые требования
DNS с A-записями для FQDN менеджеров обеих площадок.
-
Пропускная способность:
Между СХД: от 10 Гбит/с.
Хосты и СХД: от 10 Гбит/с.
Меньшая скорость тоже работает, но медленнее.
Инициализация сервиса СХД-репликации
Настройка сервиса репликации включает пять шагов:
Подключение основной и резервной площадок zVirt.
Настройка параметров подключения к СХД.
Проверка групп репликации.
Настройка маппинга ресурсов.
Создание планов восстановления.
Важно: все операции выполняете только на резервной площадке. После настройки данные автоматически появятся на основной.
Шаг 1. Настройка подключения между площадками
Войдите в веб-интерфейс (Web-UI) портала резервной площадки с правами на управление сервисом СХД-репликации.
Откройте раздел репликации: Репликация и DR → СХД репликация.
Запустите мастер: на вкладке «Обзор» нажмите «Создать».
-
Настройте площадку 1 (основную или резервную):
Придумайте уникальное имя.
Укажите точку доступа API: https://<engine-fqdn> (FQDN менеджера управления площадки 1).
Введите имя пользователя с ролью SuperUser.
Введите пароль.
Нажмите «Далее».
-
Настройте площадку 2 по тому же принципу:
Уникальное имя.
API: https://<engine-fqdn>
Пользователь с ролью SuperUser.
Пароль.
Нажмите «Далее».
Проверьте параметры и нажмите «Сохранить».
При успешном подключении на вкладке «Обзор» увидите обе площадки со статусом «ОК» в обоих направлениях.
Теперь настраиваем подключение к парам СХД.
Шаг 2. Настройка подключения к парам СХД
Войдите в веб-интерфейс (Web-UI) портала резервной площадки с правами на управление сервисом СХД-репликации.
Откройте раздел СХД: Репликация и DR → СХД-репликация → вкладка «Обзор» → разверните «Пары СХД».
Запустите создание пары: нажмите «Создать».
-
Настройте СХД для площадки 1:
Придумайте уникальное имя подключения.
Укажите URL: https://<address>:<port> (где address — IP или FQDN СХД, port — порт подключения).
Введите имя пользователя для доступа к СХД.
Введите пароль.
Выберите вендора и модель СХД.
Нажмите «Далее».
-
Настройте СХД для площадки 2 по тому же принципу:
Уникальное имя подключения.
URL: https://<address>:<port>
Имя пользователя и пароль для СХД.
Вендор и модель.
Нажмите «Далее».
Проверьте параметры и нажмите «Сохранить».
При успешном подключении пара СХД появится в списке. Разверните ее, чтобы посмотреть направления и статус репликации.
Теперь проверяем группы репликации.
Шаг 3. Проверка групп репликации
При успешном подключении к СХД в разделе «Группы репликации» отобразятся все существующие репликационные пары на стороне СХД в соответствии с подключенными доменами хранения:
Шаг 4. Настройка сопоставления ресурсов (маппинг)
Этот шаг необязательный, но полезный. Он автоматически сопоставит ресурсы между площадками при создании планов восстановления.
Что можно сопоставить в zVirt:
Дата-центры — автоматически выберет дата-центр на резервной площадке для импорта доменов хранения.
Кластеры — автоматически выберет кластер для размещения виртуальных машин.
Сети — автоматически переключит ВМ на нужные сети резервной площадки.
Как настроить маппинг
Откройте настройки: Репликация и DR → СХД-репликация → вкладка «Обзор» → разверните «Маппинг ресурсов» → нажмите «Редактировать».
-
Настройте дата-центры:
Выберите тип ресурса «Дата-центр».
Выделите дата-центр на площадке 1, затем соответствующий на площадке 2.
Нажмите «Создать».
Повторите для всех нужных дата-центров.
-
Настройте кластеры:
Выберите тип ресурса «Кластер».
Выберите пару дата-центров из выпадающего меню.
Выделите кластер на площадке 1, затем соответствующий на площадке 2.
Нажмите «Создать».
Повторите для всех кластеров.
-
Настройте сети:
Выберите тип ресурса «Сеть».
Выберите пару дата-центров.
Выделите сеть на площадке 1, затем соответствующую на площадке 2.
Нажмите «Создать».
Повторите для всех сетей.
Проверьте результат: закройте мастер и убедитесь, что все сопоставления появились в разделе «Маппинги».
Теперь создаем планы восстановления.
Шаг 5. Создание планов восстановления
План восстановления — это шаблон, по которому восстанавливаются ВМ на резервной площадке при аварии или плановом переключении.
Что включает план:
Сопоставления дата-центров — куда импортировать реплики хранилищ.
Сопоставления кластеров — где размещать восстановленные ВМ.
Сопоставления сетей — к каким сетям подключать ВМ.
Ранги ВМ — приоритет запуска (0 — первые, 1 — вторые и так далее).
Вычислительные ресурсы — CPU, RAM для каждой ВМ.
Сетевые настройки — IP-адреса, шлюзы, DNS через cloud-init.
Важно: некоторые параметры основной площадки заполняются автоматически и недоступны для редактирования при создании. Их можно изменить позже через редактирование плана для обратного переключения.
Создание плана
Требования: настроенные пары площадок и подключения к СХД.
Откройте создание плана: Репликация и DR → СХД-репликация → вкладка «Планы восстановления» → «Создать план».
-
Задайте основные параметры:
Уникальное имя плана.
Таймаут выключения ВМ (время принудительного выключения при плановом переключении).
Нажмите «Далее».
-
Выберите источники:
Пару площадок.
Пару СХД с нужной группой репликации.
Группу репликации с нужными ВМ.
Нажмите «Далее».
-
Настройте подключение домена хранения:
Дата-центр на резервной площадке (автозаполнение при настроенном маппинге).
Тип подключения (пока только iSCSI).
Параметры подключения к хранилищу.
Нажмите «Далее».
Укажите дополнительные параметры домена (по умолчанию копируются с основной площадки) и нажмите «Далее».
Выберите ВМ для включения в план и нажмите «Далее».
Проверьте ВМ основной площадки и нажмите «Далее».
-
Настройте ВМ резервной площадки:
Нажмите на строку ВМ для редактирования.
Измените вычислительные ресурсы, ранг, кластер, сети.
Настройте ранги: по умолчанию все ВМ получают ранг 0, можно изменить через панель редактирования или массово.
Нажмите «Далее».
Проверьте все настройки и нажмите «Сохранить».
План появится в списке и готов к использованию для восстановления.
Шаг 6. Работа плана аварийного восстановления
Для демонстрации работы сервиса DR рассмотрим следующий сценарий:
Виртуальные ВМ запущены и работают на основной площадке (ОЦОД).
Отказ работы сервиса на основной площадке (ОЦОД), эмуляция выхода из строя системы хранения.
Переключение работы сервиса на резервную площадку (РЦОД), запуск плана аварийного восстановления.
Восстановление работоспособности системы хранения на основной площадке (ОЦОД).
Очистка stale-ресурсов на основной площадке (ОЦОД).
-
Выполнение обратного переключения сервисов с резервной площадки (РЦОД) на основную площадку (ОЦОД).
Состояние виртуальной инфраструктуры
Итак, виртуальные машины вместе с самим сервисом работают на площадке ОЦОД:Main-PROD-site.
Реплицируемый домен хранения, где располагаются диски ВМ защищенные репликацией СХД, находится в активном состоянии на площадке ОЦОД: Main-PROD-site.
В это время площадка РЦОД: Reserver-DRLN-site находится в горячем резерве для наших сервисов и готова при необходимости запустить защищенные ресурсы виртуальной инфраструктуры:
Состояние на площадке РЦОД:
Нет активных ВМ
Домен хранения не подключен
Note: т. к. мы еще ни разу не переключали работу сервиса на резервную площадку, то реплицируемый домен хранения отсутствует. Последующие переключения приведут к тому, что на неактивной площадке домен хранения будет находиться в открепленном состоянии.
Отказ работы сервиса на основной площадке ОЦОД: Main-PROD-site
Для демонстрации выхода из строя ключевого компонента площадки ОЦОД возьмем сценарий отказа доступности СХД на всех хостах zVirt node.
Отказ доступности системы хранения на всех хостах приводит к остановке всех «пострадавших» ВМ, диски которых принадлежат сбойной системе хранения:
Сам домен хранения перешел в состояние «Неактивный».
На данном шаге фиксируем проблему работы сервиса на площадке ОЦОД и переходим к шагу восстановления работы сервиса на удаленной площадке РЦОД.
Запуск плана аварийного восстановления
Для восстановления работоспособности виртуальной инфраструктуры необходимо войти в веб-интерфейс (Web-UI) портала резервной площадки РЦОД и запустить план аварийного восстановления.
Процесс выполнения каждого шага плана аварийного восстановления можно отслеживать в статус-баре:
Далее чуть подробнее про шаги выполнения:
Проверка. Проверка возможности запустить план аварийного восстановления на целевой площадке.
Попытка выключения ВМ на исходной площадке. Если менеджер исходной площадки доступен, выполняется проверка запущенных ВМ на исходной площадке, если ВМ присутствует и ее статус не «Выключено», то для такой ВМ выполняет Power Off, т. е. гарантированно выключаем ВМ.
Переключение направления репликации. На данном шаге выполняется проверка статуса репликационного линка, если репликация «жива», находится в состоянии SYNCHRONIZED, то выполняется штатное переключение направления репликации даже в случае выполнения аварийного сценария запуска плана восстановления, если репликация перешла в разорванное состояние, то происходит принудительная активация томов на целевой площадке.
Импорт домена хранения на целевой площадке / Активация и подключение домена хранения на целевой площадке. Самый затратный по времени шаг. Поскольку домен хранения был аварийно отключен от исходной площадки, в его метаданных сохраняется информация о подключении к хостам исходной площадки. На данном этапе выполняется проверка, чтобы ни один хост больше не работал с этим доменом хранения и не обновлял время доступа (timestamp). Для надежности такая проверка повторяется несколько раз с заданным интервалом.
После подключения и активации домена хранения на целевой площадке РЦОД: Reserver-DRLN-site выполняются шаги для каждого ранга групп ВМ, шаги с достаточно информативными наименованиями:
Определение приоритета виртуальных машин по рангам, на целевой площадке.
Импорт виртуальных машин с рангом #, на целевой площадке.
Изменение параметров виртуальных машин с рангом #, на целевой площадке.
Запуск виртуальных машин с рангом #, на целевой площадке.
В нашем плане аварийного восстановления 4 ранга.
Приведем пример запуска ВМ двух первых рангов (Ранг0/Ранг1):
На скриншоте выше представлен пример выполнения плана аварийного восстановления для рангов Ранг 0 и Ранг 1. Последовательное выполнение шагов для всех рангов обеспечит запуск всей виртуальной инфраструктуры в РЦОД:
Результат и время выполнения каждого шага отображается в статус-баре, что позволяет оперативно отслеживать ход процесса:
Зафиксируем время выполнения плана аварийного восстановления: с 23:07:01 по 23:15:21 (общее время — 8 минут 21 секунда или 500 секунд)
На данном шаге полностью восстановлена работа ВМ и сервиса на резервной площадке РЦОД. Для возвращения работы сервиса в ОЦОД переходим к следующему шагу.
Восстановление работоспособности системы хранения на основной площадке (ОЦОД)
В нашем примере для восстановления работоспособности системы хранения мы возвращаем видимость СХД на все хосты zVirt Node. В вашей инфраструктуре могут потребоваться другие действия.
Очистка stale-ресурсов на основной площадке (ОЦОД)
Поскольку было выполнено аварийное переключение на площадку РЦОД, на исходной площадке ОЦОД: Main-PROD-site остались ресурсы виртуальной инфраструктуры в неактуальном состоянии ‘stale’. Обратное переключение плана аварийного восстановления невозможно без очистки ресурсов исходной площадки ОЦОД:Main-PROD-site.
Для очистки ресурсов необходимо нажать на кнопку «Очистка ресурсов ОЦОД», действие доступно в плане аварийного восстановления.
Процедура очистки ресурсов удалит все объекты в виртуальной инфраструктуре, относящиеся к выполненному плану аварийного восстановления.
Выполнение обратного переключения сервисов с резервной площадки (РЦОД) на основную площадку (ОЦОД)
Обратное переключение — это процесс возврата работы виртуальных машин на основную площадку (ОЦОД). Оно выполняется по тому же алгоритму, что и плановое переключение ресурсов.
План успешно выполнен, и все ВМ запустились на ОЦОД.
Также зафиксируем время возвращения ресурсов с РЦОД на ОЦОД: с 01:45:56 по 01:51:16 (общее время — 5 минут и 20 секунд или 320 секунды).
Я показал общий алгоритм настройки, но детали зависят от инфраструктуры. Сетевые настройки, производительность каналов между площадками, особенности приложений — все влияет на выбор режима репликации.
У каждого свои задачи и ограничения. Интересно узнать, с чем вы сталкиваетесь на практике? Всегда есть нюансы, которые не покрывают стандартные инструкции.
Еще мы писали о том, как создать метрокластер на уровне СХД, и недавно рассказывали о результатах краш-теста нашей системы. Не останавливаемся и собираемся расширять список СХД, поддерживаемых модулем DR, дорабатывать функциональность. В планах реализовать тестовое переключение DR-планов без остановки сервисов и поддержка репликации нескольких площадок в одну. Делитесь идеями, что стоит еще добавить в приоритетном порядке.
jingvar
И какой лейтенси при включённой репликации?