В наше время всё больше заказчиков задумываются о строительстве различных DR-решений для повышения отказоустойчивости их служб и сервисов. Это хорошая тенденция, и различных продуктов для решения этой задачи большое количество. Их условно можно разделить на несколько групп в зависимости от того, на каком уровне инфраструктуры они работают. Какие-то - на уровне приложений, другие - на уровне виртуальных машин, а какие-то - могут работать на уровне СХД. Многие из продуктов удачно сочетают возможность работы на разных уровнях. Этот обзор посвящен Huawei OceanStor BCManager, который позволяет управлять DR-решениями, используя при этом возможности систем хранения Huawei.

Эксперты облачного направления OnCloud компании «Онланта» постоянно совершенствуют сервисы для наших заказчиков. Не так давно в нашей публичной части облака появились новые массивы Huawei Dorado V6, о которых я рассказывал в предыдущей статье «Обзор и тестирование Huawei Dorado 5000V6». Мы решили рассмотреть, какие возможности для гранулярной репликации виртуальных машин предлагает OceanStor BCManager, который работает в связке с системами хранения Huawei.

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

• снижение нагрузки на продуктивную VM и среду виртуализации,

• возможность использования SAN-сети или выделенной сети для репликации, вместо Data-сети.

Так почему же стоит делать DR на уровне лунов СХД? Конечно же, наиболее важным я считаю именно снижение нагрузки на среду виртуализации и продуктивные VM. Как и при резервном копировании, необходимо иметь консистентную копию нашей виртуальной машины, а добиться этого можно при помощи снепшота VM. Но снепшоты гипервизоров - вещь довольно опасная. Что VMware, что Hyper-V - вопросов к ним много, и в первую очередь к медлительности. Для того, чтобы минимизировать их время жизни и, соответственно, влияние на продуктивную VM во время работы со снепшотом, поможет второстепенный снепшот на уровне системы хранения данных, на основе которого уже потом и происходит репликация на вторую площадку.

Это пример из документации Veeam, но для данного случая механизм будет аналогичный. Мы снижаем срок жизни снепшота VMware.

В данном случае совершенно не важно, какой сколько изменений произошло с момента последней репликации и сколько времени займёт репликация данных - мы будем работать со снепшотом СХД.

Помимо времени жизни снепшота во время репликации есть ещё один момент, вызывающий проблемы, если мы делаем репликацию при помощи снепшотов гипервизора - ретеншн. Ретеншн - когда на DR-площадке у нас есть цепочка снепшотов, и при каждом прохождении репликации необходимо удалять первый снепшот в этой цепочке. Не все продукты позволяют это делать, что бывает довольно большой проблемой, с которой я уже сталкивался в своей практике. Когда настроена репликация раз в час, она занимает минут 20. При этом размер снепшотов достаточно большой, и удаление первой точки в цепочке занимает больше времени, чем сама репликация, т.к. снепшоты VMware работают с каким-то очень низким приоритетом. Их скорость работы зависит не столько от СХД, сколько от ноды, которая выполняет удаление снепшота. Даже техническая поддержка VMware не может ответить, как с этим бороться.

BCManager поддерживает различные гипервизоры и приложения

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

Нам доступно три варианта репликации виртуальных машин:

• синхронная - RPO = 0 минут,

• асинхронная с консиcтентностью на уровне луна - RPO 1-15 минут,

• асинхронная с конcиcтентностью на уровне VM - RPO 15< минут.

Для того, чтобы BCManager мог управлять DR'ом, предварительно необходимо сделать следующее.

Настроить HyperReplication между массивами

1. На массиве, на который мы будем делать репликацию, необходимо создать пользователя с правами Remote device administrator.

2. Далее мы идём в Data Protection > Remote Devices и добавляем массив, на который будем делать репликацию через Add Remote Device.

3. Выбираем тип соединения, через которое будет работать репликация FC или Ethernet (в случае использования Ethernet предварительно стоит создать дополнительные логические порты) и указываем один из интерфейсов, который будет использовать для репликации и IP-адрес удалённой СХД, а также логин и пароль, которые мы создали в п. 1.

В случае соединения по FC, при условии корректно настроенного зонинга, наша СХД уже будет видеть удалённую СХД. Нужно будет также выбрать один из FC-линков для репликации и ввести логин и пароль из п. 1.

4. После установки соединения удалённый массив будет виден на нашей основной системе, и мы сможем добавить остальные линки, которые будут участвовать в репликации.

5. Далее нам необходимо создать Protection Groups, в которую будет входить несколько лунов, которые будут реплицироваться, или создать просто реплицируемую пару лунов. Идём в Data Protection > LUNs > Remote Replication Pairs и нажимаем Create, выбираем нужный нам лун и нажимаем Next.

6. Задаём настройки для реплицируемой пары. 

Два основных параметра:

• Raplication Mode - синхронная или асинхронная репликация луна,

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

  Также указываем дополнительные параметры синхронизации.

7. По окончании настройки и инициализации мы увидим статус нашей реплицируемой пары лунов.

Добавить в BCManager массивы и vCenter с обеих площадок в BCManager

1. Сначала необходимо создать сами площадки в разделе Resources -> Create Site. Здесь просто задаём им имена.

2. Для каждой площадки нужно создать хотя бы одну СХД и один хост.

3. Следующий этап - создание Protected Group, в которую будут входить VM, которые мы собираемся защищать.

• Переходим в Protection -> Create.

• Выбираем тип защищаемой сущности, в моём случае - VMware.

• Выбираем, какая из площадок является у нас продуктивной (Production Site).

• vCenter продуктивной площадки.

• Тип защиты - Array-based Replication.

• Теперь нам доступны для выбора реплицируемые луны, и VM на них.

• Нажимаем Next, и на следующей странице создаем политику репликации. При синхронной репликации достаточно политики по умолчанию, а вот в случае с асинхронной репликой необходимо настроить расписание. На вкладке Replication Policy можно настроить ограничение пропускной полосы для определённых временных интервалов. После этого наша политика готова.

  Нажимаем OK. следующем окне - Next,  проверяем параметры и задаём имя.

Мы настроили репликацию на самом массиве, создали политику для нашей тестовой машины. В разделе Protection можно убедиться, что она работает.

А если перейти на главную страницу BCManager, вы увидите анимацию репликации данных между площадками.

Но вернёмся к нашей задаче. DR-план создан, и теперь будет логично его проверить. Мы уже убедились, что реплика проходит, теперь нужно протестировать план восстановления. Он создается автоматически и находится в разделе Utilization > Data Restore.

Нажимаем Test и указываем, на какой площадке будет произведено тестовое восстановление.

На вкладке Test Network необходимо сопоставить сеть продуктивного кластера с сетью в тестовом кластере для нашей VM. По окончании процесса открываем вкладку Execution Records и видим, что DR-план запустил VM менее, чем за 5 минут. В моём случае дольше всего заняло конфигурирование датасторов на резервной площадке.

Посмотрим на VM со стороны VMware.

И на наш снепшот луна со стороны СХД, примапленый к тестовому кластеру.

Дополнительно можно зайти в VM, проверить, что сервисы на ней работают, данные консистентны и всё в порядке. Мы убедились, что DR отработал. Что дальше? Необходимо очистить DR-площадку от тестовой машины, т.к. в текущем состоянии мы не сможем запустить DR-план. В разделе Utilization > Data Restore у плана восстановления нажимаем More > Clear. 

Давайте теперь проведём боевую миграцию. Разберём этот процесс на основе Planned migration. Во-первых, он выполняет больше действий по сравнению с аварийным переключением, во-вторых, работает из-за этого чуть дольше, а для нас важно понять время RTO. Мы снова возвращаемся в раздел Utilization > Data Restore и выполняем Planned migration. Мы уже вводили данные о том, на какую площадку делать DR, когда тестировали наш план, - BCManager запомнил эти данные и предложит их по-умолчанию.

Итак, весь процесс переключения занял чуть менее 6 минут.

На процесс переключения больше всего влияет количество хостов в кластере, как в исходном, так и в целевом. В больших кластерах, с большим количеством имеющихся датасторов, время переключения может составить и час.

Последнее действие, которое нужно сделать после Planned migration, это Reprotection - разворачивание реплики СХД в обратную сторону, т.к. продуктивная VM переехала в другой ЦОД.

Теперь немного о грустном, куда же без этого?

• Dorado V6 на текущий момент не поддерживает технологию HyperVault, поэтому на DR-площадке хранится только одна копия данных. Представим простую ситуацию - мы делаем репликацию раз в час, ночью приходит шифровальщик и выводит из строя данные на каком-то из серверов. Утром это обнаруживает администратор, и всё, что ему остаётся, - восстанавливать сервер из резервной копии, т.к. на вторую систему мы уже среплицировали М вместе с зашифрованными файлами. Если бы поддерживался HyperVault, то мы могли бы на DR-системе хранить цепочку снепшотов луна за несколько часов (ну, например, 12) и имели бы возможность запустить на DR-площадке сервис до момента порчи файлов. Поддержка HyperVault предполагается в будущих версиях прошивки, ориентировочно - в конце 2021 года.

• Говоря о процессе тестирования DR-плана, здесь тоже есть нюанс. Процесс тестирования предполагает только автоматический запуск VМ на DR-площадке, но при этом у нас нет возможности проверить что-либо внутри VМ (запустился ли критичный для нас сервис, консистентность данных внутри и т.д.).

Я обнаружил, что интерфейс BCManager корректно работает только в FireFox - в свежих версиях Chrome не работают некоторые кнопки (например, кнопка Next при создании Protected Group).

Подводя итог, могу сказать, что продукт однозначно нужный, но пока ещё есть, что улучшать, чтобы снизить RTO, т.к. показатель RPO при репликации на уровне СХД и так может быть достаточно низкий. Буду внимательно следить за развитием продукта, а также надеяться на появление поддержки HyperVault в системах Dorado V6.