Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Репликация и аварийное восстановление виртуальных машин

1. Общие сведения

Репликация и аварийное восстановление (Disaster Recovery, DR) — это сервис, предназначенный для обеспечения непрерывности работы бизнес-приложений и их восстановления в случае аварийных ситуаций. Этот сервис помогает пользователям планировать, тестировать и запускать процессы восстановления виртуальных машин (ВМ) между основным и резервным центрами обработки данных (ЦОД). Таким образом, он позволяет минимизировать риски простоя и потери данных, обеспечивая высокую доступность и надежность критически важных для бизнеса приложений.

Основные причины использования сервисов репликации и аварийного восстановления:

Обеспечение непрерывности бизнеса

В случае сбоев в работе основной инфраструктуры (например, отказ оборудования, аварии) сервис репликации позволяет быстро восстановить работу виртуальных машин на резервных площадках. Это особенно важно для критически важных приложений и сервисов, которые не могут позволить себе длительные простои.

Защита данных

Репликация данных между основным и резервным ЦОД обеспечивает сохранность информации в случае потери или повреждения данных на основной площадке.

Снижение времени восстановления (RTO)

Быстрое восстановление виртуальных машин после аварии или сбоя критически важно для поддержания непрерывности работы бизнеса. Сервис репликации позволяет сократить время восстановления (RTO) до минимально возможного, что особенно важно для высоконагруженных систем.

Улучшение отказоустойчивости

Репликация и аварийное восстановление обеспечивают высокую степень отказоустойчивости, так как позволяют мгновенно переключаться на резервные копии виртуальных машин в случае сбоя основной системы. Это снижает риск простоев и увеличивает общую надежность инфраструктуры.

zVirt версии 4.3 предоставляет два решения для репликации и DR:

  • Агентская репликация (репликация на уровне гипервизора). При репликации виртуальных машин на уровне гипервизора создается вспомогательная виртуальная машина с установленным агентом, которая имеет доступ к дисковой подсистеме гипервизора и может читать и передавать данные снимков виртуальных машин. Вспомогательные ВМ (агенты) должны быть развернуты на источнике (основной ЦОД) и приёмнике репликации (резервный ЦОД).

  • СХД-репликация. При репликации на уровне системы хранения данных (СХД) не требуются вспомогательные ВМ. Репликация осуществляется на уровне СХД между основной и резервной площадками и прозрачна для платформы виртуализации.

2. Глоссарий

Термин Определение

Общие понятия

ОЦОД

Основная площадка, из которой выполняется репликация в РЦОД

РЦОД

Резервная площадка, на которую выполняется репликация. При запуске планов восстановления на ней запускаются реплицированные виртуальные машины.

Репликация

Механизм синхронизации данных, связанных с виртуальными машинами, между ОЦОД и РЦОД.

Группа репликации

Набор виртуальных машин, объединенных в группу, для которой настроены параметры репликации.

План восстановления

Шаблон, в котором описана последовательность восстановления виртуальных машин из реплик в РЦОД.

Реплика виртуальной машины

Копия виртуальной машины на системе хранения, находящейся на одной из площадок (основной или резервной).

Агентская репликация

Агент-отправитель

Виртуальная машина(ы), которая развертывается в ОЦОД (на уровне всей инсталляции/центра данных/кластера/хоста и выполняет репликацию ВМ в РЦОД)

Агент-приемник

Виртуальная машина(ы), которая развертывается в РЦОД и работает с реплицированными данными ВМ в РЦОД

Группа восстановления

Группа ВМ, восстанавливаемых в РЦОД. Состав группы формируется при создании плана восстановления

Контроллер репликации

ВМ, развернутая в РЦОД, которая управляет процессами репликации

Снимок

Функция, которая позволяет администратору создавать точки восстановления операционной системы, приложений и данных ВМ на определенный момент времени

Общий диск

Общий (shared) диск, который может быть подключен к нескольким ВМ

Ранг

Приоритет запуска ВМ. ВМ с рангом «0» запускаются первыми, затем запускаются ВМ с рангом «1» и так далее

СХД-репликация

LUN (Logical unit number)

Адрес диска или дискового устройства в сетях хранения.

Домен хранения

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

Репликационная пара

Пара LUN, реплицируемых между СХД.

Аварийное восстановление

Процесс запуска виртуальных машин в РЦОД в случае аварии в ОЦОД с переключением или разрывом репликации между СХД.

Плановое перемещение

Процесс переноса виртуальных машин в РЦОД в плановом режиме после выключения виртуальных машин в ОЦОД и изменения направления репликации.

Обратное перемещение

Процесс переноса виртуальных машин с РЦОД в ОЦОД, выполняемый после планового перемещения или аварийного восстановления.

Очистка ресурсов в ОЦОД

Процесс приведения ресурсов в ОЦОД (виртуальные машины, центры данных, домены хранения, кластеры) в состояние, позволяющее выполнить обратное перемещение из РЦОД в ОЦОД.

Инициализация плана восстановления

Процесс перевода плана восстановления в статус готовности к выполнению.

3. Агентская репликация

3.1. Архитектура и основные компоненты

Решение состоит из следующих компонентов:

  • Контроллер репликации zVirt. Отвечает за конфигурацию, запуск репликации и восстановление, управляет агентами. Контроллер репликации размещается как виртуальная машина в РЦОД.

  • Агент-отправитель. Отвечает за создание снимков состояния реплицируемых ВМ и их передачу в РЦОД. Агент-отправитель размещается как виртуальная машина в ОЦОД.

  • Агент-приемник. Отвечает за запись данных реплицируемых ВМ в РЦОД. Агент-приемник размещается как виртуальная машина в РЦОД.

  • Две независимые площадки zVirt. Каждая из площадок управляется своим Менеджером управления. каждая площадка подключена к собственной СХД.

arch agent
Рисунок 1. Архитектура сервиса агентской репликации и DR.

На схеме:

  • ВМ 1 и ВМ 2 — защищаемые ВМ, расположенные на платформе zVirt в ОЦОД.

  • Реплика ВМ 1 и ВМ 2 — ВМ, создаваемые контроллером репликации в РЦОД на платформе zVirt для защиты ВМ 1 и ВМ 2.

  • zVirt Engine (Менеджер управления) и узел виртуализации zVirt — независимые платформы виртуализации zVirt, размещаемые в ОЦОД и РЦОД. Каждый Менеджер управляет гипервизорами только в рамках своего ЦОД. Платформы виртуализации в ОЦОД и РЦОД не имеют общего хранилища и могут не иметь растянутой L2-сети.

На схеме не отображены порты служебных сервисов. Информацию об используемых портах см. в требованиях к компонентам руководства по использованию сервиса Агентской репликации и DR.

3.2. Принцип работы

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

Сетевое взаимодействие реплицируемой ВМ с агентами или контроллером репликации не требуется.

Возможно масштабирование количества агентов-отправителей для увеличения пропускной способности репликации ВМ.

Контроллер репликации zVirt располагается в РЦОД. Взаимодействие агентов-отправителей с контроллером может осуществляться как с трансляцией адресов (используется параметр «Публичный IP-адрес контроллера репликации» у контроллера), так и напрямую с использованием маршрутизации. Контроллер обращается к API zVirt Engine для управления репликами ВМ, а также передает реплицируемые данные через агент-приемник. Контроллер выполняет функции хранения данных о настроенных группах репликации, планах восстановления, о состоянии репликации ВМ, запускает и управляет репликациями и планами восстановления.

Горизонтальное масштабирование функций контроллера между несколькими ВМ не поддерживается.

На стадии репликации ВМ с ОЦОД на РЦОД происходит поблочное копирование дисков. На стадии переключения ВМ подготавливается ВМ в РЦОД (добавление сетевых интерфейсов, назначение вычислительных ресурсов согласно плану восстановления) и запуск ВМ с cloud-init конфигурацией.

Требуется предварительная настройка сервиса гостевой ОС ВМ.

4. СХД-репликация

4.1. Архитектура и основные компоненты

Решение состоит из следующих компонентов:

  • Поддерживаемые модели СХД.

  • Две независимые площадки zVirt. Каждая из площадок управляется своим Менеджером управления. каждая площадка подключена к собственной СХД.

arch stor
Рисунок 2. Архитектура сервиса СХД-репликации и DR.

4.2. Принцип работы

СХД-репликация - это механизм создания "клона" тома на удаленной СХД. При активной репликации серверы (клиенты) могут писать только в том на локальной СХД, для активации тома на удаленной площадке требуется провести некоторые операции с репликацией и томом.

Репликация не подразумевает одновременный доступ к тому на локальной и удаленной площадке, а также автоматического переключения тома на работу на удаленной площадке.

На уровне СХД возможны следующие типы репликации:

  • Синхронная репликация - при записи данных сервер получит подтверждение только после того, как удаленная СХД подтвердила факт записи.

  • Асинхронная репликация - при записи данных сервер получит подтверждение в момент, как только локальная СХД выполнила запись. Запись на удаленную СХД может быть отложена или выполняться сразу.

Асинхронная репликация может выполняться:

  • Постоянно - локальная СХД при получении блока на запись начинает запись локально и отправляет запрос на удаленную СХД.

  • По расписанию - локальная СХД при получении блока на запись начинает запись локально и выполняет запись на удаленную площадку только в настроенное время. Обычно периодичность выполнения операции составляет от 5 минут до 24 часов. Для сохранения разницы данных между локальной и удаленной копией тома используется механизм снимков: локальная СХД создает снимок тома, синхронизирует его с удалённой площадкой, через назначенный период времени создает еще один снимок, синхронизирует его и т.д.

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

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

  1. Создание пары СХД (локальная СХД - удаленная СХД). Выполняется на одной из двух СХД, происходит аутентификация/авторизация между СХД, обмен служебными данными.

  2. Создание тома на локальной СХД.

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

  4. Создание разрешающих правил доступа хостов к тому на локальной СХД.

После настройки репликации хосты имеют доступ в режиме RW (чтение/запись) к тому на локальной СХД, репликация находится в активном состоянии. Том на удаленной площадке или находится в неактивном состоянии, или презентован только в режиме RO (только чтение).

СХД поддерживают следующие варианты переключений:

  • Штатное переключение - локальная СХД работает и доступна. Может использоваться для проведения плановых работ на локальной СХД или для тестирования плана восстановления.

  • Аварийное переключение - локальная СХД недоступна для удаленной СХД, но при этом может еще работать.

Штатное переключение состоит из следующих шагов:

  1. Остановка записи на том (выполняется на уровне платформы zVirt).

  2. Отключение доступа к тому (демонтирование или перевод тома в режим RO).

  3. Выполнение репликации данных, которые не успели отреплицироваться (в случае асинхронной репликации).

  4. Остановка/разворот репликации.

  5. Перевод тома на удаленной площадке в режим RW.

  6. Монтирование тома хостам на удаленной площадке (при необходимости в зависимости от СХД).

Аварийное переключение состоит из следующих шагов:

  1. Остановка/разворот репликации.

  2. Перевод тома на удаленной площадке в режим RW.

  3. Монтирование тома хостам на удаленной площадке (при необходимости в зависимости от СХД)

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