Тестируем переезд ВМ через Hystax и уходим от ручных настроек сети26.08.2021 13:01

Hystax — подходящее решение для миграции, если нужно перенести ВМ с Linux или Windows между разными платформами: VMware, OpenStack, AWS и так далее. C его помощью можно переехать на любую из этих платформ даже с bare-metal. Мы уже не раз использовали Hystax для переезда наших клиентов с VMware в OpenStack. Также Hystax можно использовать для послеаварийного восстановления (DR).

Несколько месяцев назад один из клиентов обратился к нам с задачей переезда с OpenStack на VMware. Потом клиент передумал, но мы все равно провели пару тестов с миграцией и аварийным восстановлением на VMware. Выяснилось, что без знания особенностей Hystax можно внезапно закопаться в ручных настройках сети. Для DR это фатально, так как ручная настройка сразу увеличивает RTO. Но и для миграции настройка вручную не очень хороша. Без опыта с Hystax можно неверно спланировать работу, не уложиться в технологическое окно и нарушить сроки переезда.

В статье расскажу, где настройки могут не подняться автоматически и как с этим бороться. Показывать буду на версии Hystax DR 3.7.1701.

Как работает решение

Подробный обзор решения на Хабре уже делали, например, тут. Напомню лишь пару моментов по архитектуре.

Для перемещения ВМ в Hystax используются агенты репликации (Hystax Replication Agent). Агент ставится внутрь ОС и после запуска видит хост-источник (ОС). Для каждой ОС написаны свои агенты репликации: отдельно для Windows и Linux. Для VMware написан специальный агент, который видит все ВМ на хосте с запущенным агентом.
В целевом облаке устанавливается контроллер Hystax Acura. Он забирает данные ВМ от агента репликации.
Также в целевом облаке есть еще один агент — Hystax Cloud Agent. Он получает данные от контроллера и создает реплики ВМ в соответствии с заданными настройками. Тут тоже разные агенты: отдельно для VMware и для остальных платформ. Общая схема без привязки к платформам выглядит так:

Если с помощью Hystax мы планируем DR, то у нас появляется еще и режим failback: чтобы вернуться обратно на основную инфраструктуру, восстановленную после аварии. Для такого переезда нужен отдельный Failback Agent. Он устанавливается в то облако, куда мы планируем вернуться. Их три вида: VMware, OpenStack и Flexible Engine. По сути схема остается та же, просто вместо cloud-агента — failback-агент. Но в начале можно и запутаться в разных агентах.

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

В моих тестовых примерах мы переезжаем на VMware. Поэтому схема такая:

Сценариев тестирования было два:

сначала рассмотрел миграцию клиента из OpenStack в VMware, поскольку у нас еще не было опыта переезда в этом направлении;
затем решил проверить и послеаварийное восстановление. DR между разными платформами встречается не так часто, поэтому в первую очередь тестировал переезд с VMware на VMware. Потом смоделировал ситуацию DR с любой другой платформы на VMware.

Как тестировали

Миграция c OpenStack на VMware. Для первого эксперимента взял стенд с OpenStack в роли клиентской стороны и стенд с VMware в роли провайдерского целевого облака.

На стенде с OpenStack у нас была ВМ на CentOS. Важно: для переезда на VMware в ОС должен быть установлен VMware Tools, иначе машина просто не стартует.

На стенде с VMware мы развернули:

ВМ с контроллером Hystax Acura Controller, с 8 vCPU, 16 GB оперативной памяти и 200 GB диска;
ВМ с облачным агентом для VMware, c 2 vCPUs, 4 GB оперативной памяти и 53 GB диска;
настроили SMTP-сервер c авторизацией;
настроили DNS;
настроили сети по схеме выше.

C клиентской точки зрения, миграция на VMware выглядит так: клиент устанавливает в исходную инфраструктуру агент репликации для своей ОС. Затем выбирает параметры переезда ВМ:

приоритеты для ВМ: в какой последовательности будут переезжать машины;
параметры vCPU и RAM: сколько выделить ядер процессора и памяти;
настройки сети: адреса, подсети, маски;
доп. параметры: группы безопасности, зоны доступности, загрузка с BIOS или EFI и т.д.

В реальном кейсе миграции параметры переезда настроили бы наши инженеры. Настройки довольно гибкие, можно использовать формат JSON. В выбранный час X по команде Run Migration Hystax берет эти настройки и копирует ВМ по такой схеме:

cоздает на удаленной площадке новую «голую» ВМ, для нее в файле VMX задаются количество процессоров, памяти;
конвертирует жесткий диск с исходного сервера, при этом по сути клонируются только данные с диска. На основе диска целевой ОС создается файл VMDK;
подключает этот диск к новой ВМ.

После миграции всех ВМ остается отключиться от сервера Hystax.

DR на VMware. Здесь почти все то же самое, только на стороне клиента не Linux, а две ВМ c Windows Server 2016 и Windows Server 2019. В ОС тоже обязательно установил VMware Tools. При их установке в одном из тестов смоделировал ситуацию, что исходный сервер находится не на VMware, а где-то еще.

Если Hystax используется для DR, то в настройках можно гибко управлять частотой репликации. Можно указать репликацию каждые N минут или задать опцию Continuous Replication. В этом случае создание новой реплики будет стартовать после завершения предыдущего задания на репликацию.

Клиенту мы можем предоставить интерфейс для самостоятельного управления репликацией и восстановлением. В Hystax есть разделение ролей, для клиентов выдается роль пользователей.

Что происходило с сетью при переезде

Миграция c OpenStack на VMware. Итак, в первом тесте исходная ВМ на CentOS.

После установки создаем план миграции. Так выглядит графический интерфейс для указания параметров плана:

Так выглядит JSON-файл, который доступен на вкладке Expert:

{
  "devices": {
    "centos.local": {
      "flavor": "1-2",
      "ports": [
        {
          "name": "port_0",
          "ip": "192.0.2.24",
          "subnet": "direct-hystax-dr-vlan-2020"
        }
      ],
      "rank": 0,
      "id": "53c5f1b9-c51a-0b66-36e8-1f4bdebaa771"
    }
  },
  "subnets": {
    "direct-hystax-dr-vlan-2020": {
      "name": "direct-hystax-dr-vlan-2020",
      "subnet_id": "direct-hystax-dr-vlan-2020",
      "cidr": "192.0.2.0/24"
    }
  }
}

Здесь flavor указывает на параметры vCPU и RAM, rank — на приоритеты. C сетевыми параметрами все понятно. По этим и другим параметрам есть подробные описания в документации.

После запуска агент репликации сам определяет версию ОС как Red Hat-подобную:

ОС можно указать и вручную, но автоматическое определение ускоряет процесс. Заодно агент сразу узнает сетевой интерфейс ENS160. Если не менять имена сетевых адаптеров при миграции, все конфигурационные файлы переезжают на новую ВМ. Моя тестовая ВМ поднялась после миграции и увидела сеть.

В итоге с переездом в одну сторону все прошло без проблем.

DR на VMware. Здесь показываю результаты для разных версий Windows Server.

Создаем DR-план. Во время создания Hystax видит созданные раньше сети и прописывает IP, маску, подсеть. Все как в прошлый раз.

Можем выбрать сеть из выпадающего списка.

Сохраняем настройки, запускаем и идем в Cloud Director проверять созданную машину. Сетевых карт там не видно:

То же самое нам говорит vSphere:

Заодно заметим, что Windows Server 2016 и 2019 определяются как 2008 R2.

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

Подразумевается, что для решения этой задачи у нас должен быть DHCP-сервер. По умолчанию в Windows сетевые адаптеры выставлены на работу с DHCP:

Но и при наличии DHCP у нас после переезда поменяются MAC-адреса.

Можно зайти внутрь ОС и прописать MAC вручную, но при DR этого хочется избежать. Сначала я решил проверить вариант с DHCP-cервером и обойти ручную настройку с помощью расширенных параметров.

Вариант решения 1: привязка к IP на DHCP

Создадим план переезда и проверим, можно ли назначить MAC на сетевой интерфейс. В инструкции на сайте Hystax предлагается назначить MAC в JSON-файле на вкладке Expert.

Но вот что получается:

Если мы хотим использовать DHCP, остается 2 варианта: назначить MAC«и на ВМ скриптом или собрать созданные MAC«и и настроить DHCP по ним. Для миграции этот вариант вполне может подойти, главное не забыть заложить на это время, особенно если виртуалок много. Для DR поищем еще вариант.

Вариант решения 2: Guest Customization OS

Решил воспользоваться настройкой Guest Customization OS в Cloud Director. Эту настройку нужно указать до аварийного восстановления. При отсутствии DHCP IP-адрес будет назначен из статического пула.

1) Делаем первую реплику. Настраиваем параметры репликации:

Запускаем репликацию по кнопке Start Protection. В интерфейсе Hystax увидим прогресс-бар создания реплики, ждем:

2) Идем в Cloud Director, находим созданную ВМ и включаем Guest Customization:

3) Включаем ВМ из интерфейса Hystax по кнопке Run Recovery:

4) Из интерфейса Cloud Director запускаем Reset для нашей ВМ:

После этого настройки из JSON-файла применятся, а сети поднимутся:

При таком решении послеаварийное восстановление не затянется, что важно для DR.

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