Процесс миграции#
Процесс миграции состоит из предварительного этапа, который представляет собой подготовку планов миграции, и самого тестирования миграции.
Доступный сценарий миграции#
Каждый из этих шагов подробно описан ниже.
Планы миграции#
Планы миграции --- это сценарии миграции, предназначенные для тестирования или итоговой миграции. Они включают в себя описание машин (количество vCPU, ОЗУ, ранг и т.д.) и сетей.
Создание плана миграции#
Чтобы создать план миграции, просто нажмите кнопку Добавить на странице клиента.
При добавлении нового плана укажите его название и содержимое плана. Название плана миграции должно быть уникальным для клиента.
Существует два режима создания или редактирования плана: основной и расширенный. Чтобы переключаться между ними, выберите соответствующую вкладку на странице "Добавить план миграции".
В основном режиме пользователь может либо вставить/ввести сетевые спецификации для отказоустойчивой машины вручную, либо выбрать сети из списка, который Акура получает непосредственно из целевого облака. Список сетей может быть получен автоматически со следующих платформ - VMware, OpenStack, Flexible Engine, AWS, Azure.
Расширенный режим позволяет указать более подробную конфигурацию в формате JSON.
Основной частью плана миграции является инструкция JSON для миграции инфраструктуры и бизнес-приложения в целевое облако. Чтобы сгенерировать план на основе всех клиентских машин, нажмите на Сгенерировать план миграции из всех машин.
Создание плана миграции для группы машин#
Можно создать план миграции для выбранных машин или на основе настроек группы, используйте Сгенерировать план миграции в меню Групповые действия
или в меню групп
В результате появится диалоговое окно для создания и редактирования плана миграции - дайте ему название (уникальное для клиента).
Создать план миграции из файла#
Данный инструмент рекомендуется использовать для уже среплицированных машин. Особенно большую эффективеность он показал на большом количестве машин, т.к. значительно экономит время создания плана. Скачайте список машин. В загруженном файле machines_list.csv ряд полей будет заполнен на основании данных репликации. Обновите информацию в поле flavor, впишите cidr сети, в котором должна подняться машина, добавьте информацию о портах, в колонки, начинающиеся с ports.
При готовности загрузите файл. Для запуска создания плана миграции нажмите Применить.
На создание плана миграции потребуется некоторое время, после чего откроется окно. Отредактируйте название плана и другие поля, если нужно. Обратите особое внимание на предупреждающий текст оранжевого цвета в верхней части окна. Он показывает потенциально опасные места, из-за которых миграция может отработать некорректно. Исправьте их на форме.
Сохраните план миграции.
Синтаксис плана миграции#
Основная часть плана миграции представляет собой инструкцию JSON для миграции инфраструктуры и бизнес-приложения в целевое облако.
Пример плана миграции:
{
"devices": {
"IIS-Demo": {
"rank": 1,
"id": "52ce9361-b282-72b6-425a-f67347c5b79a",
"scheduler_hints": {
"group": "0c1b2901-7687-470e-a82c-6f69e92d5245"
},
"ports": [
{
"name": "port_0",
"ip": "192.168.15.112",
"subnet": "main_subnet"
},
{
"name": "port_1",
"subnet": "external"
}
]
},
"rhel7.2": {
"id": "522f3448-6a56-aa45-2131-207f7dda6664",
"ports": [
{
"name": "port_0",
"ip": "192.168.15.100",
"subnet": "main_subnet"
}
],
"rank": 0,
"boot_condition": {
"delay_seconds": 120,
"type": "wait"
}
}
},
"subnets": {
"main_subnet": {
"cidr": "192.168.15.0/24",
"subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
}
}
}
Базовые теги#
devices -- содержит описание каждой машины. Необходимо перечислить все машины, которые должны быть воссозданы в cloud site:
{
"devices": {
"rhel7.2": {
"id": "522f3448-6a56-aa45-2131-207f7dda6664",
"ports": {
"port_0": {
"ip": "192.168.15.100",
"subnet": "main_subnet"
},
"scheduler_hints": {
"group": "0c1b2901-7687-470e-a82c-6f69e92d5245"
}
},
"rank": 0,
"boot_condition": {
"delay_seconds": 120,
"type": "wait"
}
}
}
}
subnets -- содержит описание сетей, которые необходимо воссоздать в целевом облаке:
{
"subnets": {
"main_subnet": {
"cidr": "192.168.15.0/24",
"subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
}
}
}
Синтаксис описания машины#
Описание машины состоит из ряда параметров, описывающих свойства машины, таких как название машины, сетевые настройки, ранг и условия загрузки машин для поддержания последовательности и согласованности процесса запуска cloud site.
{
"rhel7.2": {
"id": "522f3448-6a56-aa45-2131-207f7dda6664",
"custom_image_metadata": {
"hw_qemu_guest_agent": "no",
"os_require_quiesce": "no",
"my_os_type": "linux-custom",
"hw_disk_bus": "scsi",
"hw_scsi_model": "virtio-scsi",
"my_custom_image_tag": "linux"
},
"security_groups": [
"sg-1",
"sg-2"
],
"availability_zone": "zone-1",
"user_data": "#!/bin/bash\nrpm -e hlragent\nrm -rf /etc/hystax\n",
"ports": {
"port_0": {
"ip": "192.168.15.100",
"subnet": "main_subnet"
}
},
"rank": 0,
"scheduler_hints": {
"group": "0c1b2901-7687-470e-a82c-6f69e92d5245"
},
"boot_condition": {
"delay_seconds": 120,
"type": "wait"
}
}
}
Параметры описания машин:
| Параметр | Описание | Обязательность |
|---|---|---|
| machine_name | Базовый тег для описания машины. Имя будет использоваться для идентификации машины на cloud site. | Да |
| fix_dev_prefix | Введите префикс, если необходимо обновить названия дисков машины c ОС Linux во время P2V. Возможные значения: - ‘sd’ (для названий вида /dev/sda1), - ‘vd’ (для названий вида /dev/vda1), - ‘xvd’ (для названий вида /dev/xvda1). Названия дисков заменяются в рамках процесса P2V для Linux в следующих файлах (несуществующие файлы пропускаются): - /etc/fstab, - /boot/grub/grub.cfg (а также /grub/grub.cfg, если /boot – отдельный раздел), - /boot/grub2/grub.cfg (а также /grub2/grub.cfg, если boot – отдельный раздел). Например: { "devices": { "ds-debian10-sda": { "fix_dev_prefix": "vd", ... } } } |
Нет |
| id | Внутренний идентификатор машины (можно найти, наведя курсор мыши на название машины в списке машин на странице клиента). | Да |
| ports | Список конфигураций сетевых интерфейсов машины (может быть несколько). Интерфейсы будут добавлены в том же порядке, в котором они описаны. Описание параметров интерфейса и примера их использования приведено ниже. | Да |
| scheduler_hints | Дополнительные параметры планировщика при настройке отказоустойчивости. Параметр group позволяет указать группу серверов, в которой будут размещаться инстансы для отказоустойчивого запуска в OpenStack.Пример: "scheduler_hints": { "group": "0c1b2901-7687-470e-a82c-6f69e92d5245" } |
Нет |
| rank | Порядок, в котором будет запущена группа машин. Например, машины с рангом 2 будут запущены только после запуска всех машин с рангом 1, а те, в свою очередь, только после запуска всех машин с рангом 0. | Да |
| boot_condition | Состояние, в котором машина считается работающей. Поддерживается задержка во времени; по её истечении машина считается запущенной. Условие распространяется на весь ранг. Если есть несколько машин с задержкой по времени, ранг считается выполненным после ожидания в течение самого длительного времени. Синтаксис: "boot_condition": { "delay_seconds": number of seconds to wait, "type": "wait" } Пример: "boot_condition": { "delay_seconds": 120, "type": "wait" } |
Нет |
| flavor | Название или идентификатор существующей конфигурации в облаке. Для VMware значение указывается как vCPU-RAM, например 2-4, что означает 2 vCPU и 4 ГБ. Пример: “flavor”: “2-4” |
Да |
| config_drive | По умолчанию – false. Установите в true, если хотите использовать конфигурационный диск. Пример: "config_drive": "true" |
Нет |
| security_groups | Список групп безопасности, которые будут использоваться для машины. Это приведёт к перезаписи группы (групп) по умолчанию. | Нет |
| availability_zone | Название зоны доступности, используемой для машины. Это приведёт к перезаписи зоны доступности, указанной в настройках облака. | Нет |
| user_data | Сценарий, который будет выполнен на целевой машине. Чтобы использовать ключ “user_data”, на исходной машине должен быть установлен cloud_init, в противном случае он будет проигнорирован. | Нет |
| firmware | Параметр, который выбирает вариант загрузки для машины (Vmware, oVirt, GCP). Доступные значения - BIOS (по умолчанию) или EFI. Пример: “firmware”: “EFI” |
Нет |
| guest_id | Идентификатор гостевой операционной системы. Обратитесь к официальной документации VMware. Пример: “guest_id”: “ubuntu64Guest”. |
Нет |
| hardware_ver | Аппаратная версия виртуальной машины. Обратитесь к официальной документации VMware. Пример: “hardware_ver”: “vmx-11”. |
Нет |
| byol (только для AWS) | Если byol - false (или не установлен), то используется AWS ImportImage (AWS запускает собственную P2V). Если byol - true, то используется AWS RegisterImage, и запускается наш собственный P2V. Пример: "devices": { "sd_small_ubuntu": { "rank": 0, "byol": true, } } |
Нет |
| ntp_server (только для Windows) | Протокол, используемый Windows для синхронизации. Пример: "devices": { "im-WS2019-ntp": { "flavor": "m1.medium", "ports": [ { "name": "port_0", "subnet": "provider-subnet" } ], "id": "52eef058-012b-70dd-9271-28ee5f56d171", "rank": 0, "ntp_server": "ntp6.ntp-servers.net" }, "subnets":{ "provider-subnet": { "name": "provider-subnet", "subnet_id": "6129317f-4987-4bf3-bfd0-c0edc3bc4bba", "cidr": "172.24.1.0/24" } } } |
Нет |
| hostname (только для Windows машин в облаке OpenStack) | Новое имя хоста Windows машины. Значение поля может принимать значения: - true (по умолчанию) – использовать имя машины из плана в качестве имени хоста - false – не менять имя хоста - любая строка – установить имя хоста как указано в строке. Пример: "devices": { "ds2012test": { "id": "9f51d0de-b6cb-400e-b223-5e748cc39d01", "flavor": "m1.medium", "hostname": "my-super-long-custom-hostname", "rank": 0, "ports": [ { "name": "port_0", "subnet": "DS-internal-2" } ] } }, "subnets": { "DS-internal-2": { "name": "DS-internal-2", "subnet_id": "76377dae-4e35-4183-bafa-b06eef69249e", "cidr": "172.22.0.0/16" } } |
Нет |
| rclocal_script | Сценарий, который запустится при загрузке Linux. Пример: "rclocal_script": "#!/bin/bash\ndate > date.txt\n" |
Нет |
| copy_efi_bootloader | По умолчанию – false. Установите в true, если хотите использовать загрузчик по умолчанию. Пример: "copy_efi_bootloader": true |
Нет |
| key_name | Ключ-пара для устройства. Пример: "key_name": "yv-key" |
Нет |
| meta | Список мета-тегов машины. Для OpenStack, OpenNebula. Пример: "devices": { "rhel7.2": { ... "meta": { "Image Name": "Hystax_CATI_...", "Image ID": "f389c03b-...", "Image": "image", "Key Name": "username" } } |
Нет |
| custom_image_metadata | Задать пользовательские метаданные образа для среплицированных ВМ. Только OpenStack. Пример: "custom_image_metadata": { "hw_qemu_guest_agent": "no", "os_require_quiesce": "no", "my_os_type": "linux-custom", "hw_disk_bus": "scsi", "hw_scsi_model": "virtio-scsi", "my_custom_image_tag": "linux" }, Параметр можно задать как строку с объектом JSON: "custom_image_metadata": "hw_qemu_guest_agent=no,os_require_quiesce=no,my_os_type=linux-custom,hw_disk_bus=scsi,hw_scsi_model=virtio-scsi,yv_custom_image_tag=Linux". Также этот параметр можно задать как дополнительную опцию на этапе начальной конфигурации или при добавлении облака. Обратите внимание, что, если параметр задан и на этапе начальной конфигурации/добавления облака, и в плане миграции, то к облаку будут применены настройки плана миграции, т.к имеют приоритет выше, даже если значение представляет собой пустую строку. |
Нет |
Описание интерфейса ports имеет следующие параметры:
| Параметр | Описание | Обязательность |
|---|---|---|
| name | Название интерфейса | Да |
| ip | IP-адрес интерфейса. По умолчанию адаптеры Windows будут настроены как DHCP. Если вы хотите установить статические настройки, то используйте это поле совместно с mac. |
Нет |
| mac | MAC-адрес интерфейса. Игнорируется для облака AWS. | Нет |
| subnet | Название подсети интерфейса | Да |
| routing_allowed | Позволяет машине быть маршрутизатором (может быть “true” или “false” (по умолчанию)). Игнорируется для облака AWS. | Нет |
| floating_ip | добавляет floating_ip для порта (может быть “true” или “false” (по умолчанию)). Использование этого параметра со значением “true” ограничивает устройство наличием только одного порта. “floating_ip”: “ |
Нет |
| mtu (только для Windows) | Наибольший размер пакета, отправляемый по сети без фрагментации. Используйте этот параметр в паре с параметром mac. Пример: "devices": { "DS2012R2MULMBR": { "id": "9f51d0de-b6cb-400e-b223-5e748cc39d01", "flavor": "m1.medium", "rank": 0, "ports": [ { "name": "port_0", "ip": "172.22.8.249", "mac": "08:00:27:46:79:29", "gateway_ip": "172.22.1.2", "dns_nameservers": [ "172.22.1.2", "8.8.4.4" ], "mtu": 1511, "subnet": "DS-internal-2" } ] } }, "subnets": { "DS-internal-2": { "name": "DS-internal-2", "subnet_id": "76377dae-4e35-4183-bafa-b06eef69249e", "cidr": "172.22.0.0/16" } } |
Нет |
Примеры:
"ports": [
{
"name": "port_0",
"ip": "192.168.15.100",
"subnet": "main_subnet"
}
]
Порты, подсети, mac, ip, gateway и dns. Используйте mac, чтобы установить статический ip:
{
"devices": {
"sd_small_ubuntu": {
"rank": 0,
"ports": [
{
"name": "port_0",
"ip": "172.22.8.144",
"mac": "08:00:27:46:79:27",
"gateway_ip": "172.22.1.2",
"dns_nameservers": [
"172.22.1.2",
"172.22.1.3"
],
"subnet": "subnet_1"
}
],
"id": "5260881c-c921-f037-df78-6105f018a9c2",
"flavor": "m1.medium"
}
},
"subnets": {
"subnet_1": {
"name": "subnet_1",
"cidr": "172.22.0.0/16"
}
}
}
Пример для случая, если IP динамический:
{
"devices": {
"centos": {
"ports": [
{
"name": "port_0",
"floating_ip": true,
"subnet": "subnet_0"
}
]
<...>
}
}
}
Синтаксис описания сети#
Описание сети состоит из ряда параметров, таких как название сети, её CIDR и адреса DNS-серверов.
Пример:
{
"subnets": {
"main_subnet": {
"cidr": "192.168.15.0/24",
"subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
}
}
}
Параметры описания сети:
| Параметр | Описание | Обязательность |
|---|---|---|
| network name | Название сетевого идентификатора является базовым тегом для описания сети | Да |
| cidr | CIDR сети | Да |
| subnet_id | Существующий идентификатор подсети в целевом облаке | Да |
Warning
Указанный идентификатор подсети должен быть доступен для используемой зоны доступности.
Редактирование существующего плана миграции#
Чтобы отредактировать существующий план миграции, нажмите кнопку Изменить напротив этого плана на странице клиента.
Появится диалоговое окно, в котором можно отредактировать план миграции.
Тестировочные и итоговые миграции#
После завершения создания полных реплик выбранных машин заказчик может запустить набор тестовых миграций для оценки результатов, формирования правильных ожиданий и настройки параметров инфраструктуры.
Описание конфигурации процесса миграции.
Процесс миграции может потребовать некоторого времени: его продолжительность зависит от сложности структуры плана миграции и уровней согласованности/зависимости между компонентами бизнес-приложения. Как только все компоненты получат статус Активен, бизнес-приложение готово к процедуре, и можно протестировать или выполнить окончательную миграцию, которая приведёт к отсоединению решения Хайстекс от cloud site.
Warning
Перенаправление основного трафика на платформу AWS или KVM не является частью текущей функциональности решения и должно быть заранее согласовано с поставщиком услуг.
В целях экономии времени рекомендуется использовать упрощённый набор тестов, которые будут выполняться на cloud site, прежде чем переключать производственный трафик на новую цель.
Настройки Cloud site#
После создания cloud site можно выполнить ряд дополнительных действий для настройки среды выполнения бизнес-приложения, таких как добавление машин на cloud site, остановка/запуск машин. Описание cloud site и соответствующих настроек.
Во время тестирования миграции рекомендуется удалить избыточные cloud sites, чтобы освободить затраченные на них ресурсов.