Сценарий DR между площадками для типовой инфраструктуры

Эта статья предназначена для демонстрации пошаговой настройки и отработки аварийного восстановления типовой ИТ инфраструктуры. В неё включены примеры настройки,важные примечания и экспертные рекомендации по конфигурации.

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

Для отработки сценария Disaster Recovery используется инфраструктура, приведенная на диаграмме:

Ниже приведено описание ролей ВМ, входящих в тестовый сценарий:

• VMware Edge router, с настроенным функционалом SNAT и DNAT (публикация порта 443 для сервера VPN)

• SRV-DC01 – контроллер домена Microsoft Active Directory и DNS сервер, поддерживающий прямую и обратную зоны.

• SRV -APP1C – сервер СУБД MS SQL Server и 1С:Предприятие

• SRV-FS001 – файловый сервер

• SRV-RDS001 – сервер удалённых рабочих столов

• SRV-VPN001 – SSL VPN сервер реализованный на базе продукта OpenConnect. Имеет интеграцию с Active Directory. Для шифрации соединений используется wildcard сертификат Let’s Encrypt. 

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

Для того, чтобы восстановленная в новой локации инфраструктура автоматически могла быть приведена в рабочее состояние, необходимо реализовать АБСОЛЮТНО ИДЕНТИЧНЫЕ сетевые настройки резервной площадки (сети, конфигурация VEG).

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

Примечание: в рамках реализации задачи будет выполнена настройка исходящей («Outgoing») репликации из основной площадки в резервную площадку.

ВАЖНО: на данном шаге указываются учетные данные пользователя площадки, куда будет осуществляться репликация данных. Указывать следует именно в таком формате, как продемонстрировано на скриншоте.

В вашем случае в поле user name нужно будет указать: "user name от вашей organization в Cloud Director" + @ + "organization name". В поле password - пароль от Organization в Cloud Director.

Примечание: RPO (Recovery Point Object) – значение, определяющее как часто будут передаваться данные. Может быть определено в интервале от одной минуты до 24 часов. Чем чаще передаются данные, тем выше нагрузка на используемые ресурсы, в том числе на исходной площадке. В связи с этим рекомендуется использовать оптимальный для бизнеса и инфраструктуры RPO, а не минимально доступный.

В рассматриваемом примере интервал RPO задан как «5 min».

После завершения настройки начинается процесс синхронизации данных:

ВАЖНО: обязательно необходимо дождаться полного завершения процесса синхронизации как на уровне vApp

так и и на уровне отдельных ВМ.

Итоговое состояние КАЖДОЙ ВМ в vApp должно быть подобно приведенным на скриншотах.

После завершения синхронизации целесообразно осуществить проверку параметров восстановления, чтобы гарантировать что исходные и целевые сети сопоставлены корректно, и сетевые карты на всех серверах находятся в состоянии «Connect at power on».

Контроль состояния репликации данных (как на уровне vApp, так и уровне отдельных ВМ) следует производить на вкладках «Details» и «Instances».

В корректно функционирующей репликации состояние параметров «Overall health» и «Replication state» должно быть «Green» и «Healthy» соответственно.

На вкладке «Instances» отображается время последней осуществленной репликации для каждой ВМ.

Примечание: Cloud Director Availability (vCAV) поддерживает хранение нескольких копий реплицированных данных. Данная функциональность носит наименование «Retention». В некотором роде, это является неким аналогом снапшотов. Алгоритм работы выглядит следующим образом: предположим, «RPO» определен как 1 час, и количество «Retention» определено как 3.

Таким образом, если было проведено три репликации, например, в 12:00, 13:00 и 14:00, то в 14:30 можно будет осуществить восстановление на любую из этих трех временных отметок.

Если функционал «Retention» не задействован, то хранится последняя реплика, согласно настроенному RPO.

ВАЖНО: данная функциональность может ЗНАЧИТЕЛЬНО увеличить потребление дискового пространства.

Как правило, при резервировании большого количества виртуальных машин важным фактором является контроль последовательность запуска ВМ.

ВАЖНО: настройка последовательности восстановления осуществляется на той площадке, куда будет осуществляться восстановление.

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

Для настройки необходимо перейти в пункт «Recovery plans» и выбрать «New recovery plan» и задать имя.

Далее нужно определить шаги восстановления:

В рассматриваемом примере план восстановления подразумевает несколько шагов:

• Step1 – старт контроллера домена. После данного шага необходимо перед выполнением следующего обеспечить задержку в 5 минут, чтобы гарантировать запуск всех необходимых служб Active Directory и предотвратить возможные ошибки при старте рядовых членов домена.

• Step 2 – старт остальных серверов.

Ниже приведена последовательность настройки шагов восстановления:

ВАЖНО: параметр «Wait specific amount of time after failover completes» определяет задержку перед началом следующего шага.

ВАЖНО: если не все ВМ, входящие в vApp входят в Recovery Plan, добавлены в план восстановления, то может возникнуть ошибка, аналогичная приведенной на скриншоте:

Для устранения ошибки необходимо добавить все ВМ, входящие в vApp в план восстановления.

Ниже приведено итоговое состояние настроенного плана восстановления.

В качестве имитации отказа площадки выключаем vApp в локации «MOW».

Для выполнения disaster recovery необходимо в резервной локации запускае настроенный ранее «Recovery plan».

ВАЖНО: необходимо дождать полного выполнения плана восстановления. Все ВМ в итоге должны находится в состоянии «Failed-Over».

В результате выполнения восстановления в vDC должны в состоянии «Power on» появится vAPP и все входящие в него ВМ.

После восстановления инфраструктуры можно продолжать работу в штатном режиме.

ВАЖНО: следует иметь ввиду, что после выполнения процедуры «Failover» репликация данных останавливается, и система переходит в состояние «Failed-over».

После восстановления инфраструктуры на резервной площадке возможны два

сценария:

• Сценарий 1: Использование резервной площадки в качестве основной

• Сценарий 2: Перенос инфраструктуры обратно на основную площадку.

Если используется «Сценарий 1», то в этом случае необходимо настроить исходную площадку в качестве резервной. Наиболее простой способ – использование реверсной репликации данных.

ВАЖНО: при выполнении обратной (reverse) репликации, все исходные объекты в основной локации будут удалены, и вместо них скопированы данные с запасной площадки!

В результате будет инициирован процесс синхронизации данных и направление репликации на запасной площадке будет изменено с «Incoming» на «Outgoing». 

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

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

• Удалить vApp в исходной локации.

ВАЖНО: vApp обязательно должен быть удален, иначе в основной площадке будет создан новый vAPP с аналогичным названием и суффиксом «(1)», в котором будут размещены скопированные обратно объекты.

• Создать задание миграции из резервной площадки на основную.

• Осуществить миграцию и удалить vApp из резервной площадки.

• Настроить задание репликации из основной площадки в резервную.

Фактически, такого рода тестирование представляет собой частичный Disaster Recovery без возврата на основную площадку. Реализация подразумевает выполнение следующих шагов:

• Выполнить Recovery plan на запасной площадке. В результате будут восстановлены данные, c задержкой, согласно используемой политике RPO.

ВАЖНО: так как vApp в основной площадке не выключался, то исходная инфраструктура продолжит функционировать в штатном режиме, параллельно с инфраструктурой, восстановленной на запасной площадке. Так как площадки изолированны друг от друга, то такой сценарий является безопасным с точки зрения целостности данных.

• Подключиться к запасной площадке и проверить работоспособность восстановленной инфраструктуры.

• Выполнить удаление восстановленных данных и Recovery plan на запасной площадке.

• Удалить созданное ранее задание репликации данных на основной площадке.

• Создать заново задание репликации данных на основной площадке.

• Создать заново Recovery Plan на запасной площадке