Помогая нашим клиентам проводить аварийное восстановление или миграцию с помощью продукта vCAV, мы даже не предполагали, насколько сложным иногда может оказаться этот процесс. Особенно много проблем возникает у новичков, у которых раньше не было опыта с vCAV. Но есть и хорошая новость — всего этого можно легко избежать, если заранее продумать детали и составить грамотный план переезда. В этом посте знакомим с особенностями инструмента VMware Cloud Availability и даем чек-лист по настройке всего процесса.
Такой простой vCAV
Сегодня речь пойдет о работе с VMware Cloud Availability (vCAV). Этот продукт помогает организовать Disaster Recovery (DR) и миграцию в рамках нескольких площадок облачного провайдера или переехать/восстановиться в облако сервис-провайдера с on-premise площадок. vCAV работает на основе механизма vSphere Replication, он встроен в панель Cloud Director, что позволяет клиентам публичных облаков самостоятельно управлять DR и миграцией своих виртуальных машин из привычного интерфейса.
vCloud Availability (vCAV) предоставляет возможности репликации и отработки отказа для рабочих нагрузок в Cloud Director как на уровне ВМ так и на уровне vApp. В зависимости от типа установки обеспечивает восстановление для облаков и локальных сред.
Инсталляции vСAV делится на два вида: провайдерский и on-premise.
VMware vCloud Availability для провайдеров обеспечивает:
Организацию репликации Заказчиков, подключенных к вашему сервис-провайдеру.
Отслеживание трафика каждой репликации с построением графика.
VMware vCloud Availability On-Premises обеспечивает:
Управление репликацией и мониторинг репликаций с on-premises площадки на облачный сайт и обратно.
Восстановление после сбоя, восстановленное в облачных рабочих нагрузках, на on-premises сайте.
Миграцию защищённых виртуальных машин с облачного сайта обратно на on-premises площадку.
Self-service protection and failover для каждой ВМ.
Сразу стоит уточнить, что клиенты часто путают опции миграции ВМ и их репликации. Самое важно их отличие — миграция ВМ для провайдера является бесплатной, в отличие от репликации. Это нужно сразу учитывать, планируя переезд.
vCAV – это ПО, которое помогает проводить миграцию и репликацию по одинаковому алгоритму – путем создания репликации машины на удаленную площадку. Отличие миграции от репликации в том, что репликация более функциональная. Например, параметр RPO — время синхронизации, изменяемый только при репликации, при миграции он же неизменяемый — 24 часа. Репликация как правило используется для DR — аварийного восстановления, с максимально низким возможным RPO.
Примеры использования:
Многие клиенты имеют большую гиперконвергентную инфраструктуру с частью мощностей на стороне облачного провайдера и частью на своих собственных инсталляциях vCenter. С помощью данного продукта можно мобильно управлять своими ИТ-ресурсами, мигрируя виртуальные машины между облачным провайдером и своим оборудованием. Например, для обновления физических серверов на своей стороне или тестирования какого-либо нового сервиса, для которого нет места на своих ресурсах.
Вторым распространённым применение может быть DR, заказчик хочет проработать план аварийного восстановления на случай падения своей инфраструктуры. Для решения этой задачи он может воспользоваться продуктом vCav и среплицировать все свои критические ВМ в облако провайдера с любым необходимым RPO и быть уверенным, что его инфраструктура под защитой.
vCav является удобным инструментом для миграции между площадками облачного провайдера, с ним для миграции не потребуется помощь инженеров из технической поддержки, процесс миграции заказчик может организовать сам.
Это самые распространённые кейсы, которые могут быть реализованы через vCav.
Несколько рекомендаций для on-prem решения
В большинстве случаев клиенты используют on-premises инсталляции vCloud availability для миграции своих ресурсов. vCloud availability является обычным аплаенсом VMware на базе Photon OS, который будет необходимо установить, как виртуальную машину в vCenter. vCloud Availability должен иметь доступ до других продуктов VMware в соответствии со схемой на рисунке ниже:
При дефолтных настройках для трафика репликаций на хостах виртуализации используется vmk-интерфейс, отвечающий за менеджмент. Мы крайне рекомендуем создавать отдельную сеть для репликаций и регулировать на ней скорость в зависимости от возможностей инфраструктуры. Новая сеть добавляется на все esxi-хосты в инфраструктуре с тэгами vSphere Replication и vSphere Replication NFC.
Планируем миграцию с помощью vCAV
Настройка сетевой связности
Первый этап для успешного выполнения миграций — организация сетевой связанности между площадками. Как правило, практически любую сеть можно спокойно растянуть между различными дата-центрами облачного провайдера, с этим, к сожалению, сможет помочь только техническая поддержка. Чтобы не было казусов и дополнительного простоя во время миграции, рекомендуем проверить корректность сетевой связанности до начала миграции тестовыми машинами.
Также vCav поддерживает и конфигурацию L2 VPN туннелей, организованных через NSX Edge, более подробно можно посмотреть тут: https://www.youtube.com/watch?v=f3elf0w14X8
Составление плана миграции / DR плана
После того, как мы настроили сетевую связность и протестировали её, можем переходить к планированию. Необходимо будет составить план переезда и определить последовательность переключения ВМ. Стоит учитывать, что при миграции через vCav простой для одной машины будет составлять максимум 10 мин, в большинстве случае даже меньше.
После того, как мы определились с последовательностью миграции, перейдём к созданию репликаций.
Работа с репликациями
В рамках тестов возьмём одну очень простую задачу – нам необходимо смигрировать 4 ВМ – DB01, DB02, APP01 и APP02 из VDC1 в VDC2 на новые более производительные ресурсы сервис провайдера, все предыдущие пункты уже выполнены.
Давайте рассмотрим более подробно процесс создания репликации:
Переходим на портал vCloud Availability из панели управление Cloud Director:
Заходим в Incoming Replication или Outgoing Replication (в нашем кейсе это не важно) и создаем новую миграцию:
Выбираем ВМ или целый vAPP, который необходимо смигрировать, и площадку, куда будем мигрировать (в рамках нашего кейса площадка остается неизменной - vCav):
При выборе сторонней площадки (cloud site) будет необходимо авторизоваться на ней, введя логин и пароль от тенанта в ней. Логин должен быть в формате: имя пользователя@название тенанта, например admin@testvcav, где testvcav - имя тенанта. В конфигурации On-premises дополнительная авторизация не требуется, vCav On-premise подключается непосредственно к тенанту, и вы сможете увидеть его в списке доступных сайтов.
Выбираем дисковую политику, на которой будут располагаться наши репликации:
Обратите внимание, что располагать разные диски одной виртуальной машины на разных политиках нельзя ввиду ограничений ПО.
Задаем настройки для будущих репликаций:
Delay start synchronization – задаем время начала первой синхронизации. Exclude disks – исключаем ненужные диски реплицируемых ВМ. Configure Seed VMs – используем старые копии виртуальных машин на целевом сайте, чтобы уменьшить время выполнения первичной синхронизации.
Все настройки заданы, нажимаем Finish, репликации начинают конфигурироваться:
Репликации сконфигурированы, теперь осталось ждать окончание первой синхронизации. После окончания первой синхронизации должна появится точка восстановления Latest Instance и статус репликации должен изменится на Healthy. После окончания первой синхронизации виртуальная машина будет готова к переключению.
Чтобы минимизировать простой при миграции, перейдём к настройкам сетей, которые будут подключены к ВМ в новом vdc. Переходим в all actions – network settings, и задаем все необходимые настройки для тестовой и боевой репликации.
Обратите внимание, что редактирование настроек сетей при миграции между cloud сайтами доступно только при выборе vAPP, также vCav не меняет настройки сетей внутри OS ВМ, только со стороны Сloud director.
Последний рекомендуемый шаг перед боевым переключением — выполнить тестовую миграцию, чтобы проверить, что все настройки выполнены корректно. Тестовое восстановление никак не влияет на продуктивную ВМ. ВМ, которая получилась в рамках теста, нельзя использовать как боевую, поскольку после удаления репликации сама машина также удалится, тест — это лишь проверка. Настройки для теста можно оставить дефолтные, при проверке и включении тестовых ВМ будьте внимательны - в сети можно получить дублирующиеся IP.
Recovery State – Test Image Ready означает то, что тест прошел успешно и проблем со стороны vCav нет, в новом vdc мы видим 4-е новых созданных ВМ с созданными под них контейнерами vApp:
Проверяем гостевые ОС - ошибок в них не наблюдаем. Наш тест прошёл успешно, удаляем созданные после него машины через панель vCav: all actions – test clean up:
Все этапы выполнены, мы согласовали время простоя с бизнесом и готовы к боевому переключение. Выбираем наши виртуальные машины и нажимаем — all action — Migrate:
Задаем настройки для восстановления:
Consolidate VM Disks — включение этого параметра объединит все экземпляры в один восстановленный диск. Это может улучшить скорость восстановления виртуальной машины, мы обычно рекомендуем использовать данный маркер.
Network Settings — выбираем, какие настройки сети будут у восстановленных машин, так как мы их настраивали заранее, выбираем — Apply preconfigured network settings on migrate.
Проверяем, что всё корректно и нажимаем Finish:
После нажатия Finish исходная ВМ будет выключена «мягко» (shut down guest OS) и пойдёт процесс создания новой ВМ из файлов репликации.
Важно, что при отсутствии на ВМ VMware tools выключение будет «жестким», поэтому перед миграцией мы рекомендуем выключать ВМ самостоятельно из гостевой OS во избежание проблем.
После того, как задача на миграцию закончится (у нас это заняло 2 минуты), репликация перейдёт в статус failover, а в новом vdc появится точные копии наших оригинальных ВМ.
Теперь осталось проверить новую машину, если всё хорошо, то миграцию можно считать успешно завершенной. Репликацию со статусом Failover нужно будет удалить. В случае проблем с новой ВМ у нас остается точная копия машины в старом vdc, которую мы можем запустить в любое время.
Как мы видим процесс довольно прост, но проблемы могут всё равно возникнуть на каком-либо из этапов.
Несколько советов, которые помогут избежать проблем при работе с vCAV
Совет 1
Часто клиенты сталкиваются с ошибками при работе с vApp во время миграции. Как мы ранее обсуждали в примере, на репликации после планирования переезда лучше ставить все ВМ сразу, если, конечно, скорость позволяет, поскольку первая синхронизация может идти довольно долго. Но процесс переключения же может серьезно замедлится, так как кратковременный простой согласовывается для каждой ВМ индивидуально.
При переключении vCAV создаёт новый Vapp, куда будет помещать новые виртуальные машины, его трогать не нужно, ВМ оттуда до конца миграции также лучше не перемещать. Если вы после переезда одной ВМ, например, переименуете vAPP, где она находится, то последующие ВМ в него переехать не смогут, появится ошибка о том, что vCAV не смог найти необходимый контейнер в Cloud director, куда нужно поместить машину. В итоге мы получим картину с репликацией с ошибкой и ВМ, которая смогла переехать только в vCenter. Это легко решается путём импорта ВМ в Сloud director, но для этого потребуется помощь поддержки сервис-провайдера.
Совет 2
vCAV автоматически реплицирует только включенные виртуальные машины, для репликаций выключенных машин необходимо в ручном режиме выполнить первую синхронизацию, путём нажатия – all actions – Sync:
Совет 3
При конфигурации vcloud availability on-prem вы не можете получить сертификат "Could not find SSL/X509 certificate from...". Прежде чем писать гневные отзывы провайдеру о том, что его ПО не работает, проверьте, что сам appliance сертификат видит через базовые команды openssl s_client -showcerts -connect …, возможно ваша группа информационной безопасности запрещает подключатся к внешним сайтам по определенным портам. Для решения стоит просто поправить access list на оборудование ИБ.
Совет 4
Когда вы планируете переезд, обязательно дожидайтесь, когда первая синхронизация ВМ пройдёт, должен появится Latest Instance (пункт 5 в примере). Если вы создадите репликацию и сразу выполните Migrate, то задача зависнет и по истечение 10-15 мин отвалится по тайм ауту, по итогу вы получите выключенную ВМ и сломанную реплику, в данном случае реплику придётся пересоздавать.
Совет 5
При DR следите за репликациями или же попросите провайдера настроить их мониторинг, например, при увеличение диска ВМ, которая стоит на репликации напрямую через vCenter репликация может поломаться и придётся её пересоздавать.
Совет 6
Если вы наблюдаете крайне низкую скорость репликации при большом канале, предназначенном для репликаций, стоит попробовать попросить провайдера (для клиента данная функция недоступна) отключить компрессию на репликации ваших ВМ, в некоторых кейсах отключение компрессии может сильно увеличить скорость репликации. Но будьте внимательны — отключение компрессии увеличит сетевой трафик между source и destination площадками, дополнительного сжатия данных не будет.
Совет 7
Если вы заметили ошибки при создание репликации некоторых ВМ – unexpected error, при этом часть ВМ успешно встало на реплику, не торопитесь создавать тикет у вендоров или сервис провайдера. Для начала стоит проверить, имеют ли диски виртуальных машин формат vmdk, если нет, то их нужно будет переименовать через vmkfstools по этой инструкции — https://kb.vmware.com/s/article/1029513. Мы уже на своей практике встречались с подобным. Перед работами с дисками лучше иметь полный backup машины.
Обратите внимание, что в редких случаях может наблюдаться проблема низкой производительности ВМ, которая находится на постоянной репликации.
Чек-лист действий при подобных проблемах
В некоторых случаях бывает такое, что во время повторных синхронизаций наблюдаются проблемы с производительностью ВМ, например, плохо работают диски или есть какие-либо ошибки в ОС, которые мешают корректной работе. Все подобные кейсы решаются — у нас ещё не было патовых ситуаций, когда мы бы приняли решение отказаться от продукта vCav. Для решения проблем стоит попробовать данные шаги:
Проверяем, что на ВМ стоят последние VMware tools, а именно версии – 11360 (такая версия была последней на момент написания статьи). У нас был реальный кейс, когда обновление VMware tools до последний версии помогло клиенту избавится от проблем с машиной, которая стояла на постоянной репликации в рамках DR проекта. У VMware есть kb на эту тему: https://kb.vmware.com/s/article/80130?lang=en_US.
На ВМ с OS Windows наблюдались множественные ошибки в логах: Reset to device, \Device\RaidPort0, was issued. В связи с чем ВМ испытывала фризы во время появления алерта. После обновления VMware tools на версию 11360 проблема так и осталась, поддержка VMware предложила следующии команды и они помогли клиенту решить проблему:
Using a registry editor, change this key to 1 — HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\DisableDeleteNotificationUse this PowerCLI command — fsutil behavior set DisableDeleteNotify 1
Официальная kb также присутствует: https://kb.vmware.com/s/article/2150591
На репликациях проверить - all actions - replication settings не включена ли опция Activate quiescing, некоторые ВМ при включенной паузе могут «подвисать» во время повторной синхронизации.
Выводы
При миграции с помощью такого инструмента как vCAV все не так просто, как кажется с первого взгляда. Однако, пользуясь советами из этого поста, можно избежать трудностей, о которых мы рассказали выше.