В настоящее время все больше и больше клиентов задумываются о создании различных решений аварийного восстановления для повышения отказоустойчивости своих сервисов.
Это хорошая тенденция, и существует большое количество различных продуктов для решения этой проблемы.
Их условно можно разделить на несколько групп в зависимости от уровня инфраструктуры, на которой они функционируют. Некоторые из них находятся на уровне приложения, другие — на уровне виртуальной машины, а некоторые могут работать на уровне системы хранения.
Многие продукты удачно сочетают в себе возможность работы на разных уровнях.
Этот обзор посвящен Huawei OceanStor BCManager, который позволяет управлять решениями по аварийному восстановлению, используя возможности систем хранения данных Huawei. Эксперты OnCloud по облачным сервисам Onlanta постоянно совершенствуют услуги для наших клиентов.
Не так давно в нашей публичной части облака появились новые массивы Huawei Dorado V6, о которых я рассказывал в предыдущей статье.
«Обзор и тестирование Huawei Dorado 5000V6» .
Мы решили рассмотреть, какие возможности гранулярной репликации виртуальных машин предлагает OceanStor BCManager, работающий совместно с системами хранения данных Huawei. 
Можно выделить следующие основные преимущества репликации данных на уровне хранилища:
- снижение нагрузки на продуктивные ВМ и среду виртуализации,
- возможность использовать сеть SAN или выделенную сеть для репликации вместо сети передачи данных.
Как и в случае с резервным копированием, необходимо иметь согласованную копию нашей виртуальной машины, и этого можно добиться с помощью моментального снимка виртуальной машины.
Но снимки гипервизора — довольно опасная вещь.
И VMware, и Hyper-V — к ним много вопросов, и в первую очередь к медлительности.
Чтобы минимизировать их время жизни и, соответственно, влияние на производительную ВМ при работе со снимком, поможет вторичный снимок на уровне системы хранения данных, на основе которого затем происходит репликация на вторую площадку.
Это пример из документации Veeam, но в данном случае механизм будет аналогичный.
Мы сокращаем срок службы моментального снимка VMware. 
В данном случае совершенно не важно, сколько изменений произошло с момента последней репликации и сколько времени займет репликация данных — мы будем работать со снимком хранилища.
Помимо времени жизни снапшота при репликации, есть еще один момент, который вызывает проблемы, если мы делаем репликацию с использованием снапшотов гипервизора — сохранение.
Retention — когда у нас на DR-сайте есть цепочка снапшотов, и при каждом проходе репликации необходимо удалять первый снапшот в этой цепочке.
Не все продукты позволяют это сделать, что может стать достаточно большой проблемой, с которой я уже сталкивался в своей практике.
Если репликация настроена раз в час, это займет около 20 минут. При этом размер снапшотов достаточно велик, а удаление первой точки цепочки занимает больше времени, чем сама репликация, потому что снапшоты VMware работают с каким-то очень низким приоритетом.
Скорость их работы зависит не столько от системы хранения, сколько от узла, удаляющего снапшот. Даже техподдержка VMware не может ответить, как с этим бороться.
BCManager поддерживает различные гипервизоры и приложения.
Но сегодня я разберу только одну часть, касающуюся репликации виртуальных машин VMware, потому что.
Именно для этого случая я рассматриваю это решение.
У нас есть три варианта репликации виртуальных машин:
- синхронный - RPO = 0 минут,
- асинхронный с постоянством на уровне Луны - РПО 1-15 минут,
- асинхронный с согласованностью на уровне виртуальной машины — RPO 15< minutes.
Настраиваем гиперрепликацию между массивами
1. На массиве, на который будем делать репликацию, нужно создать пользователя с правами администратора удаленного устройства.2. Далее переходим в «Защита данных» > «Удаленные устройства» и добавляем массив, в который будем реплицировать через «Добавить удаленное устройство».
3. Выбрать тип соединения, через которое будет работать репликация FC или Ethernet (при использовании Ethernet следует предварительно создать дополнительные логические порты) и указать один из интерфейсов, который будет использоваться для репликации и IP-адрес удаленной системы хранения данных, а также логин и пароль, которые мы создали на шаге 1. В случае подключения по FC, при условии правильной настройки зонирования, наша СХД уже будет видеть удаленную СХД.
Также потребуется выбрать одну из ссылок FC для репликации и ввести логин и пароль из шага 1. 4. После того, как соединение будет установлено, удаленный массив будет виден в нашей основной системе, и мы сможем добавить остальные ссылки, которые будут участвовать в репликации.
5. Далее нам необходимо создать Группы Защиты, в которые будут входить несколько лун, которые будут реплицироваться, или создать просто реплицируемую пару лун.
Перейдите в «Защита данных» > «LUN» > «Пары удаленной репликации» и нажмите «Создать», выберите нужный нам LUN и нажмите «Далее».
6. Задайте настройки реплицируемой пары.
Два основных параметра:
- Режим репликации – синхронная или асинхронная лунная репликация,
- Создание пары — массив самостоятельно создаст луны на второй СХД, либо мы укажем на какую луну реплицировать, если мы ее создали заранее.
7. После завершения настройки и инициализации мы увидим статус нашей реплицированной пары лун.
Добавьте массивы и vCenter с обоих сайтов в BCManager.
1. Для начала вам необходимо создать сами сайты в разделе Ресурсы -> Создать сайт. Здесь мы просто даем им имена.
2. Для каждого сайта необходимо создать минимум одну систему хранения и один хост. 
3. Следующий этап — создание Защищенной группы, в которую войдут ВМ, которые мы собираемся защищать.
- Заходим в Защита -> Создать.
- Выбираем тип защищаемого объекта, в моем случае — VMware.
- Мы выбираем, какой из наших сайтов будет продуктивным (Production Site).
- Платформа повышения производительности vCenter.
- Тип защиты — Репликация на основе массива.
- Теперь у нас есть доступ к реплицированным лунам и виртуальным машинам на них.
- Нажимаем «Далее», и на следующей странице создаем политику репликации.
При синхронной репликации достаточно политики по умолчанию, но при асинхронной реплике необходимо настроить расписание.
На вкладке «Политика репликации» вы можете настроить ограничения пропускной способности для определенных интервалов времени.
После этого наша политика готова.
Нажмите ОК.
в следующем окне - Далее проверяем параметры и задаем имя.
Мы настроили репликацию на самом массиве и создали политику для нашей тестовой машины.
В разделе Защита вы можете убедиться, что она работает. 
А если вы зайдете на главную страницу BCManager, то увидите анимацию репликации данных между сайтами.
Но вернемся к нашей задаче.
План ДР создан, и теперь логично было бы его проверить.
Мы уже убедились, что реплика работает, теперь нужно протестировать план восстановления.
Он создается автоматически и находится в разделе «Использование» > «Восстановление данных».
Нажмите «Тест» и укажите, на каком сайте будет выполняться тестовое восстановление.
На вкладке Test Network нужно сопоставить сеть производственного кластера с сетью тестового кластера для нашей ВМ.
По окончании процесса откройте вкладку «Записи выполнения» и увидите, что план аварийного восстановления запустил ВМ менее чем за 5 минут. В моем случае дольше всего потребовалась настройка хранилищ данных на резервной площадке.
Давайте посмотрим на ВМ со стороны VMware. 
А на нашем снимке луна видна со стороны системы хранения, сопоставленной с тестовым кластером.
Дополнительно можно зайти в ВМ, проверить, что на ней работают службы, целостность данных и все в порядке.
Мы убедились, что ДР работает. Что дальше? Необходимо очистить площадку DR с тестовой машины, так как в текущем состоянии мы не сможем запустить план DR. В разделе «Использование» > «Восстановление данных» плана восстановления нажмите «Дополнительно» > «Очистить».
Давайте теперь проведем боевую миграцию.
Давайте проанализируем этот процесс на основе плановой миграции.
Во-первых, он выполняет больше действий по сравнению с отказоустойчивым, во-вторых, из-за этого работает немного дольше, и для нас важно понимать время RTO. Снова возвращаемся в раздел Использование > Восстановление данных и выполняем Плановую миграцию.
Мы уже вводили данные о том, на каком сайте делать аварийное восстановление, когда тестировали наш план — BCManager запомнил эти данные и предложит их по умолчанию.
Итак, весь процесс переключения занял чуть меньше 6 минут. 
На процесс переключения больше всего влияет количество хостов в кластере, как исходных, так и целевых.
В крупных кластерах с большим количеством доступных датасторов время переключения может составлять до часа.
Последнее действие, которое необходимо сделать после Плановой миграции, — это Reprotection — развертывание реплики хранилища в обратном направлении, поскольку продуктивная ВМ переехала в другой дата-центр.
Теперь немного о грустном, где бы мы были без него?
- Dorado V6 в настоящее время не поддерживает технологию HyperVault, поэтому на сайте аварийного восстановления хранится только одна копия данных.
Представим себе простую ситуацию — мы делаем репликацию раз в час, а ночью приходит вымогатель и отключает данные на одном из серверов.
Утром это обнаруживает администратор, и ему остается только восстановить сервер из резервной копии, потому что.
Мы уже реплицировали М вместе с зашифрованными файлами на вторую систему.
Если бы HyperVault поддерживался, то мы могли бы хранить на DR-системе цепочку лунных снимков в течение нескольких часов (ну, например, 12) и иметь возможность запускать сервис на DR-сайте до тех пор, пока файлы не будут повреждены.
Поддержка HyperVault ожидается в будущих версиях прошивки, ориентировочно в конце 2021 года.
- Если говорить о процессе тестирования плана DR, то здесь тоже есть нюанс.
Процесс тестирования лишь предполагает автоматический запуск ВМ на площадке DR, но при этом мы не имеем возможности проверить что-либо внутри ВМ (запустился ли критический для нас сервис, целостность данных внутри, и т. д.).
Подводя итог, могу сказать, что продукт однозначно нужен, но еще есть куда дорабатывать, чтобы снизить RTO, ведь показатель RPO для репликации на уровне хранилища уже может быть достаточно низким.
Я буду внимательно следить за развитием продукта, а также надеюсь на появление поддержки HyperVault в системах Dorado V6. Теги: #Хранение данных #Системное администрирование #Хранилище данных #Huawei #lanit #онланта #обзор #Huawei OceanStor BCManager
-
Красивый Дата-Центр От Mac Pro
19 Oct, 24 -
Невангер
19 Oct, 24 -
Мы Все Живем В Симуляциях
19 Oct, 24 -
Алгоритмы? Нет, Я Не Знаю
19 Oct, 24 -
Не Называй Себя Вествудом!
19 Oct, 24 -
Роботы Не Отдыхают
19 Oct, 24 -
Виджет «Данет»
19 Oct, 24
