Перейти к содержанию

Процесс миграции#

Процесс миграции состоит из следующих этапов: подготовка плана миграции, настройка и запуск Cloud Site, проверка доступности и работоспособности сервисов на запущенных виртуальных машинах, а также завершение работы и отсоединение / удаление Cloud Site.

Проводите тестирование Cloud Site в рамках доступных сценариев миграции ниже. Оно помогает выявить ошибки в конфигурации, сетевых настройках и зависимостях, а также повышает уверенность в доступности сервисов. В результате снижаются риски простоев и потери данных.

Доступные сценарии миграции. Тестовые и итоговые миграции#

Основной сценарий миграции#

Основной сценарий миграции применяется, когда исходная ВМ обнаружена в Акуре и для неё выполнена хотя бы одна полная репликация (репликация машин).

Процесс миграции включает следующие шаги:

  1. Создайте или обновите план миграции, описав целевую конфигурацию машин и сетей.

  2. Запустите создание Cloud Site, выбрав один из вариантов:

    • кнопка Запустить на вкладке Планы миграции
    • пункт Мигрировать в левом меню навигации

  3. Проверьте ВМ Cloud Site и убедитесь в:

    • доступности сервисов
    • работоспособности нагрузок
    • сетевой связности
    • зависимостях приложений

    Подробнее — в разделе Тестовые и итоговые миграции.

  4. При необходимости доработайте план миграции и повторите процесс миграции.

  5. Для итоговой миграции отсоедините Cloud Site от Акуры, чтобы перенесённые ВМ остались в целевом облаке без компонентов Акуры.

  6. Подключите перенесённые ВМ к целевой инфраструктуре и введите нагрузки в эксплуатацию:

    • настройка сети
    • включение мониторинга
    • восстановление интеграций и зависимостей

Сценарий миграции Direct2Target#

Сценарий Direct2Target (D2T) выполняет репликацию без использования API целевого облака. Подробнее об архитектуре — в разделе Схема миграции Direct2Target.

Процесс миграции Direct2Target включает следующие этапы:

  1. Настройте целевое облако Direct2Target.

  2. Добавьте или настройте клиента.

  3. Настройте исходное облако и установите агент репликации.

  4. На странице клиента скачайте образ D2T-агента.

  5. В целевом облаке разверните на основе скачанного образа ВМ и запустите её.

    Note

    Конфигурация целевой ВМ (CPU, ОЗУ, диски и сетевые параметры) должна совпадать с исходной машиной. Назначьте целевой ВМ публичный IP-адрес.

  6. В меню Действия машины выберите Изменить настройки репликации и укажите публичный IP-адрес целевой ВМ в поле IP-адрес D2T облачного агента.

  7. Запустите репликацию для выполнения первой полной репликации на целевые диски.

  8. Создайте или измените план миграции, чтобы определить параметры миграции. Обратите особое внимание на параметр firmware, который определяет, будет ли целевая виртуальная машина использовать прошивку BIOS или EFI. Описание этого и других параметров см. в разделе Синтаксис плана миграции.

  9. Запустите процесс создания Cloud Site, выбрав один из вариантов:

    • кнопка Запустить на вкладке Планы миграции
    • пункт Мигрировать в левом меню навигации

  10. Проверьте ВМ Cloud Site и убедитесь в:

    • доступности сервисов
    • работоспособности нагрузок
    • сетевой связности
    • зависимостях приложений

  11. Отсоедините Cloud Site от Акуры, чтобы перенесённые ВМ остались в целевом облаке без компонентов Акуры.

  12. Подключите перенесённые ВМ к целевой инфраструктуре и введите нагрузки в эксплуатацию:

    • настройте сети
    • включите мониторинг
    • восстановите интеграции и зависимости

Тестовые и итоговые миграции#

После завершения первой полной репликации настоятельно рекомендуем выполнить одну или несколько тестовых миграций перед итоговой миграцией.

Тестовые миграции помогают проверить:

  • доступность ВМ
  • работоспособность приложений
  • сетевую конфигурацию
  • оркестрацию и зависимости между сервисами

Процесс тестовой миграции совпадает с основным сценарием миграции с дополнительными рекомендациями:

  1. Перед запуском миграции создайте или обновите набор тестов для проверки перенесённых нагрузок.

    Note

    Подготовка набора тестов — общая ответственность заказчика и поставщика услуг по миграции.

  2. Запустите набор тестов на ВМ активного Cloud Site.

  3. Проанализируйте результаты тестов и при необходимости обновите:

    • планы миграции
    • конфигурацию инфраструктуры
    • сетевые настройки
    • процедуры тестирования

  4. По завершении тестирования удалите Cloud Site.

  5. Повторяйте процесс миграции, пока результаты тестов не будут соответствовать требованиям к миграции.

Тестовая миграция отличается от итоговой тем, что после успешной итоговой миграции Cloud Site необходимо отсоединить от Акуры, а не удалить.

Процесс миграции требует времени. Его продолжительность зависит от:

  • сложности плана миграции
  • уровней оркестрации
  • зависимостей между компонентами приложения

Когда все компоненты переходят в состояние Active, перенесённое бизнес-приложение готово к работе.

Warning

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

Для сокращения простоев рекомендуем выполнять упрощённый набор проверок на Cloud Site перед переключением производственного трафика на целевую среду.

Планы миграции#

Планы миграции --- это сценарии миграции, предназначенные для тестирования или итоговой миграции. Они включают в себя описание машин (количество vCPU, ОЗУ, ранг и т.д.) и сетей.

Создание плана миграции#

Чтобы создать план миграции, просто нажмите кнопку Добавить на странице клиента.

dr knopka dobavit planmigracii

При добавлении нового плана укажите его название и содержимое плана. Название плана миграции должно быть уникальным для клиента.

Существует два режима создания или редактирования плана: основной и расширенный. Чтобы переключаться между ними, выберите соответствующую вкладку на странице "Добавить план миграции".

В основном режиме пользователь может либо вставить/ввести сетевые спецификации для отказоустойчивой машины вручную, либо выбрать сети из списка, который Акура получает непосредственно из целевого облака. Список сетей может быть получен автоматически со следующих платформ - VMware, OpenStack, Flexible Engine, AWS, Azure.

dr osnovnoj rezhim

Расширенный режим позволяет указать более подробную конфигурацию в формате JSON.

dr dobavit planmigracii dialog

Основной частью плана миграции является инструкция JSON для миграции инфраструктуры и бизнес-приложения в целевое облако. Чтобы сгенерировать план на основе всех клиентских машин, нажмите на Сгенерировать план миграции из всех машин.

Создание плана миграции для группы машин#

Можно создать план миграции для выбранных машин или на основе настроек группы, используйте Сгенерировать план миграции в меню Групповые действия

cp dejstviya s mashinami sgenerirovat plan

или в меню групп

cp sgenerirovat plan dlya gruppy

В результате появится диалоговое окно для создания и редактирования плана миграции - дайте ему название (уникальное для клиента).

dr dobavit planmigracii dialog

Создать план миграции из файла#

Данный инструмент рекомендуется использовать для уже среплицированных машин. Особенно большую эффективеность он показал на большом количестве машин, т.к. значительно экономит время создания плана. Скачайте список машин. В загруженном файле machines_list.csv ряд полей будет заполнен на основании данных репликации. Обновите информацию в поле flavor, впишите cidr сети, в котором должна подняться машина, добавьте информацию о портах, в колонки, начинающиеся с ports.

При готовности загрузите файл. Для запуска создания плана миграции нажмите Применить.

cp sozdat plan iz fajla

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

cp redaktirovat plan iz fajla

Сохраните план миграции.

Синтаксис плана миграции#

Основная часть плана миграции представляет собой инструкцию 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"
        }
    }
}

Параметры описания машин:

Table 1: Параметры описания машин.
Параметр Описание Обязательность
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 и KubeVirt значение указывается как 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, Direct2Target). Доступные значения - BIOS (по умолчанию), EFI или EFI_SB (только для oVirt).
- Используйте BIOS для операционных систем, установленных в режиме BIOS, включая устаревшие версии Windows (например, Windows 7 и Windows Server 2008 R2) и более ранние дистрибутивы Linux.
- Используйте EFI для операционных систем, установленных в режиме UEFI, включая Windows 10, Windows 11, Windows Server 2016 и более поздние версии, а также большинство современных дистрибутивов Linux.
- Используйте EFI_SB только при восстановлении в среду oVirt, где требуется UEFI с включенным Secure Boot.

Выбранный тип микропрограммы должен соответствовать режиму установки операционной системы и конфигурации загрузчика. В противном случае восстановленная машина может не загрузиться.
Пример:
"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 имеет следующие параметры:

Table 2: Описание интерфейса 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”: “” назначит целевой машине определённый внешний IP-адрес (только для Openstack, Huawei). Нет
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"
        }
    }
}

Параметры описания сети:

Table 3: Параметры описания сети.
Параметр Описание Обязательность
network name Название сетевого идентификатора является базовым тегом для описания сети Да
cidr CIDR сети Да
subnet_id Существующий идентификатор подсети в целевом облаке Да

Warning

Указанный идентификатор подсети должен быть доступен для используемой зоны доступности.

Редактирование существующего плана миграции#

Чтобы отредактировать существующий план миграции, нажмите кнопку Изменить напротив этого плана на странице клиента.

dr knopka izmenit plan migracii

Появится диалоговое окно, в котором можно отредактировать план миграции.

dr izmenit plan migracii dialog

Связь с поддержкой: support@hystax-team.ru | Условия использования | © Copyright 2026 | ООО Хайстекс | All rights reserved