Описание решения#
Хайстекс Акура Live Migration - это решение для миграции бизнес-приложений и ИТ-инфраструктуры между облаками.
Процесс миграции состоит из первоначальной репликации компонентов бизнес-приложений (машин), элементов инфраструктуры в целевую среду с последующим запуском перенесённых рабочих нагрузок.
Репликация доступна для ресурсов, работающих на VMware, Hyper-V, OpenStack, Cloud.ru, VK Cloud, Yandex Cloud, K2 Cloud, KeyStack, KeyVirt, а также для физических машин.
Начиная с версии 4.5, Хайстекс Акура также предоставляет Direct2Target (D2T) — функцию миграции, позволяющую реплицировать и переносить виртуальные машины напрямую в целевое облако без зависимости от API целевой платформы. Для переноса данных используется образ D2T, с установленным облачным агентом, который записывает данные непосредственно на целевые диски. После переключения миграции (cutover) на восстановленной машине автоматически запускается процесс подготовки к эксплуатации. Подробнее — в разделе Схема миграции Direct2Target.
Архитектура#
Решение состоит из серверной и клиентской частей. Серверная часть содержит компоненты, которые развёртываются на AWS из AMI или на платформе KVM из предоставленного образа и отвечают за извлечение изменений с клиентских устройств, их дедупликацию, хранение данных и запуск миграций.
Что касается клиентской части, то она включает в себя агенты, установленные на VMware vSphere/oVirt/OpenStack для репликации машин на облачной платформе, или агенты для Windows/Linux, установленные на гостевых операционных системах для репликации других типов облачных платформ и физических машин.
Клиент для VMware (агент VMware) — машина Linux, поставляемая в виде файла OVA, которая развертывается на каждом хосте или кластере ESXi и реплицирует машины на этих хостах или кластерах. Стандартные инструменты VMware используются для обнаружения изменений и получения дельт на виртуальных машинах (API отслеживания измененных блоков), что, в свою очередь, побуждает инструменты операционных систем (quiesce) сохранять согласованность данных внутри реплик. Каждый экземпляр агента должен иметь не менее 2 ЦП и 4 ГБ ОЗУ и должен быть развернут на каждом хосте или кластере ESXi, содержащем машины, предназначенные для репликации.
Note
Настройка уровня обнаружения в настройках конфигурации облака влияет на то, что будет обнаруживать агент: хост или кластер ESXi.
Агент oVirt - машина Linux, поставляемая в виде файла RAW, которая развёртывается на основном центре данных и реплицирует машины находящиеся на нем.
Агент OpenStack - машина Linux, поставляемая в виде файла RAW, которая развёртывается на основном центре данных и реплицирует машины находящиеся на нем.
Linux-агент — демон Linux, устанавливаемый на гостевой ОС в случае репликации машин в публичных облаках, таких как AWS, Microsoft Azure или Google Cloud, а также Hyper-V, KVM, OpenStack или физических машинах с операционными системами Linux. Доступен для загрузки и последующей установки на гостевую операционную систему в виде архива deb или rpm.
Агент Windows - служба Windows, устанавливаемая на гостевой ОС в случае репликации машин в публичных облаках, таких как Microsoft Azure или Google Cloud, а также Hyper-V, KVM, OpenStack или физических машинах с операционными системами Windows. Поставляется в виде ZIP-файла с MSI и конфигурационным файлом для установки в гостевой операционной системе.
Warning
В случае репликации инфраструктуры VMware/oVirt нет необходимости устанавливать агенты Windows/Linux на каждой машине. Просто установите агента VMware на каждый хост ESXi vSphere.
Сетевая схема решения#
Процесс репликации включает три основных компонента:
- репликационный агент — собирает данные репликации в исходной среде.
- контроллер Хайстекс Акура — управляет процессом репликации и взаимодействует с целевой облачной платформой.
- облачный агент — принимает данные репликации в целевой среде и записывает их в целевое хранилище.
Репликационный агент разворачивается в исходной среде. Он загружается через веб-интерфейс Акуры и может быть развернут одним из следующих способов:
- внутренний репликационный агент — устанавливается как служба на каждой исходной машине.
- внешний репликационный агент — используется для исходных сред VMware, oVirt и OpenStack. Загружается в виде образа OVA или RAW и разворачивается как отдельная виртуальная машина на гипервизоре заказчика.
После установки и запуска репликационного агента исходная машина автоматически обнаруживается в панели управления Акуры и становится доступной для репликации.
Репликационный агент:
- подключается к контроллеру Акуры по TCP-порту 443;
- отправляет журналы по UDP-порту 12201.
Для работы репликационного агента не требуется доступ в Интернет, если он может установить сетевое соединение с контроллером Акуры.
Облачный агент принимает данные репликации от контроллера и записывает их в целевое хранилище.
Для большинства поддерживаемых целевых облачных платформ контроллер автоматически создает отдельный облачный агент для каждого клиента.
Для целевых сред VMware и oVirt облачный агент загружается со страницы пользователя и разворачивается вручную. Он взаимодействует непосредственно с целевым гипервизором.
Облачный агент:
- принимает данные репликации по TCP-порту 80;
- записывает данные репликации в целевое хранилище;
- для целевых сред VMware передает данные репликации целевому гипервизору по TCP-порту 902 и UDP-порту 902.
Контроллер Хайстекс Акура координирует процесс репликации и взаимодействует с инфраструктурой целевой облачной платформы.
Контроллер:
- взаимодействует с API поддерживаемых облачных платформ, используя порты, предусмотренные соответствующим облачным провайдером;
- взаимодействует с VMware vSphere по TCP-порту 443;
- взаимодействует с VMware vCloud Director по TCP-порту 443.
При использовании VMware и контроллер, и облачный агент взаимодействуют с VMware vSphere по TCP-порту 443.
Подключение к хранилищу
Требования к подключению зависят от выбранного типа хранилища.
- При использовании объектного или файлового хранилища контроллер должен иметь сетевой доступ к хранилищу, поскольку оно находится за пределами целевой облачной платформы.
- При использовании блочного хранилища дополнительное сетевое подключение контроллера не требуется, поскольку данные репликации сохраняются непосредственно в целевой облачной платформе.
Схема миграции Direct2Target#
- На исходной платформе агенты репликации (внутренние агенты на виртуальных машинах или внешний агент для VMware/oVirt/OpenStack) передают данные репликации в сеть.
- Данные и метаданные передаются с исходной площадки на контроллер Хайстекс Акура (порты TCP/443 и UDP/12201).
- На целевой платформе виртуальная машина, развернутая из образа D2T (предварительно загруженного со страницы клиента), запускает облачный агент, который получает реплицируемые данные и записывает их непосредственно на целевые диски.
- Во время репликации контроллер Хайстекс Акура управляет развернутым облачным D2T-агентом (порт TCP/443).
- После переключения миграции (cutover) восстановленная машина автоматически подготавливается к эксплуатации. D2T-агент удаляется, сторонние компоненты очищаются, а машина загружается из восстановленной операционной системы.
Для выполнения этого процесса требуются следующие действия вручную:
- Загрузите образ D2T со страницы клиента и разверните из него целевую виртуальную машину.
- Настройте целевую виртуальную машину и ее конфигурацию дисков.
- Настройте восстанавливаемую машину в панели управления Акуры для использования развернутого D2T-агента, а затем запустите репликацию.
Important
- Каждой мигрируемой виртуальной машине требуется отдельная целевая ВМ развернутая из образа D2T.
- Конфигурация дисков целевой машины должна соответствовать конфигурации исходной машины: количество дисков должно совпадать, а размер каждого целевого диска должен быть не меньше соответствующего исходного диска.
- После отсоединения смигрированной виртуальной машины от Акуры она перестает управляться продуктом. Все дальнейшие операции по ее управлению выполняются вне Акуры.
- Не перезагружайте целевую виртуальную машину c D2T-агентом и не перезапускайте службы D2T-агента во время репликации, между циклами репликации или между операциями восстановления.
Перенос и хранение данных#
Процесс репликации передает данные из исходной среды в выбранное хранилище целевой облачной платформы. Поток данных зависит от конфигурации хранилища, выбранной для репликации.
Акура поддерживает следующие варианты хранения данных:
- Блочное хранилище облака — рекомендуется для сценариев миграции и аварийного восстановления.
- Особая конфигурация (для экспертов) — позволяет хранить данные репликации в хранилище, управляемом заказчиком.
Репликация данных#
Репликация начинается после того, как машина с запущенным репликационным агентом зарегистрирована в панели управления Акуры и для нее включена репликация.
Репликационный агент передает данные репликации контроллеру Хайстекс Акуры, который координирует процесс репликации в соответствии с настроенным расписанием.
Дальнейший поток данных зависит от выбранной конфигурации хранилища.
Блочное хранилище облака
Контроллер передает данные репликации облачному агенту, который записывает их в блочное хранилище целевой облачной платформы. При последующих циклах репликации передаются только измененные блоки данных, а точки восстановления создаются в соответствии с настроенной политикой.
Note
Для целевых сред VMware и oVirt облачный агент необходимо развернуть вручную. Для всех остальных поддерживаемых облачных платформ он создается контроллером автоматически.
Особая конфигурация (для экспертов)
При использовании пользовательского хранилища контроллер передает данные репликации в настроенное хранилище. Целевая облачная платформа не участвует в хранении данных репликации.
Расписание репликации настраивается администратором в панели управления Акуры.
Хранение данных#
Выбранная конфигурация хранилища определяет, где хранятся данные репликации и как они используются в процессе миграции.
Блочное хранилище облака
Данные репликации хранятся в виде томов и снимков непосредственно в целевой облачной платформе. Снимки используются как точки восстановления, на основе которых создаются виртуальные машины при миграции.
Поскольку данные репликации уже находятся в целевой облачной платформе, этот вариант позволяет сократить время миграции и рекомендуется для сценариев, где важен быстрый запуск виртуальных машин в целевой среде.
Особая конфигурация (для экспертов)
Данные репликации хранятся в хранилище, настроенном заказчиком. Тип хранилища определяет способ хранения данных, доступные возможности и срок их хранения.
При миграции данные выбранной точки восстановления сначала переносятся из настроенного хранилища в целевую облачную платформу, поэтому процесс может занимать больше времени по сравнению с использованием блочного хранилища облака.
Миграция данных#
Процесс миграции зависит от выбранной конфигурации хранилища.
Блочное хранилище облака
Миграция полностью выполняется в целевой облачной платформе. Контроллер создает том восстановления на основе выбранной точки восстановления, создает виртуальную машину, подключает к ней том восстановления и завершает процесс миграции.
Поскольку данные репликации уже находятся в целевой облачной платформе, миграция виртуальных машин обычно занимает несколько минут.
Особая конфигурация (для экспертов)
Миграция начинается с восстановления данных выбранной точки восстановления из настроенного хранилища в том восстановления в целевой облачной платформе. После создания тома восстановления дальнейший процесс аналогичен миграции при использовании Блочного хранилища облака: создается новая виртуальная машина, к ней подключается том восстановления, после чего виртуальная машина запускается.
Note
Время миграции зависит от выбранной конфигурации хранилища, объема реплицируемых данных и сложности защищаемой машины.
Требования к развёртыванию#
| Компонент Хайстекс Акура | Системные требования | Требования к сети (разрешить трафик в/из следующих портов) |
|---|---|---|
| Хайстекс Акура (контроллер): разворачивается из образа, предоставленного Хайстекс | 8 виртуальных ЦП Оперативная память: 16 ГБ Дисковое пространство: 200 ГБ SSD |
Входящий - tcp/443 Входящий - tcp/4443 Входящий - udp/12201 Исходящий - tcp/443 Исходящий - tcp/80 (к облачному агенту Хайстекс) |
| Облачный агент (VMware): загружается из панели управления Акуры и разворачивается из шаблона OVA | 2 ЦП Оперативная память: 4 ГБ |
Входящий - tcp/80 Исходящий - tcp/udp 902 (к хосту ESXi) Исходящий - tcp/443 (к vCenter и хосту ESXi) |
| Облачный агент (oVirt): загружается из панели управления Акуры и разворачивается из RAW диска | 2 ЦП Оперативная память: 4 ГБ Дисковое пространство 20 ГБ |
Входящий – tcp/80 Исходящий – tcp/443, udp/12201 |
| Облачный агент (все другие поддерживаемые облачные платформы): Автоматически разворачивается в целевом проекте | 2 ЦП Оперативная память: 4 ГБ Дисковое пространство 20 ГБ |
Входящий – tcp/80 Исходящий – tcp/443, udp/12201 |
| Агент репликации Windows (внутренний): загружается из панели управления Акуры | Оперативная память: 2 ГБ ЦП: x64 Дисковое пространство: 100 МБ требуется для установки продукта и не менее 15% свободного места на диске для создания снапшотов VSS Microsoft .NET Framework 4.0 |
tcp/443 – отправка данных в Акуру udp/12201 – отправка логов в Акуру |
| Агент репликации Linux (внутренний): загружается из панели управления Акуры | Оперативная память: 500 МБ Дисковое пространство: 100 МБ требуется для установки продукта и не менее 15% свободного места на диске для создания снапшотов |
tcp/443 – отправка данных в Акуру udp/12201 – отправка логов в Акуру |
| Агент репликации VMware (внешний): загружается из панели управления Акуры | 2 ЦП Оперативная память: 4 ГБ Существует несколько разрешений хоста, которые требуются агенту репликации VMware для работы. |
Исходный хост – tcp/443 Хост vSphere – tcp/443 Хост(ы) ESXi – tcp/udp/902 udp/12201 – отправка логов в Акуру |
| Агент репликации oVirt (внешний): загружается из панели управления Акуры | 2 ЦП Оперативная память: 4 ГБ Дисковое пространство: 20 Гб |
Исходный хост – tcp/443 udp/12201 – отправка логов в Акуру |
| Агент репликации OpenStack (внешний): загружается из панели управления Акуры | 2 ЦП Оперативная память: 4 ГБ Дисковое пространство: 20 Гб |
Исходный хост – tcp/443 udp/12201 – отправка логов в Акуру |
Матрица совместимости Акуры и поддерживаемые системы#
Матрица развертывания агентов репликации#
Платформы и агенты репликации Акуры, доступные к развертыванию на них:
| Исходная платформа | Поддерживаемые версии / Примечания | Тип агента | Метод распространения |
|---|---|---|---|
| VMware ESXi / vRealize / vSphere | ESXi 6.0.0 U3+ (кроме ESXi 6.7 Build 8169922), 7+, 8+ | HVRAgent (внешний для Vmware) HWRAgent / HLRAgent (внутренний для Windows/Linux) |
OVA-шаблон ВМ (внешняя репликация) MSI-установщик / .deb, .rpm |
| OpenStack | Mitaka+ | HOVRAgent (внешний для OpenStack с Ceph как Cinder backend) HWRAgent / HLRAgent (внутренний для Windows/Linux) |
RAW MSI-установщик / .deb, .rpm |
| oVirt | — | HOVRAgent (внешний для oVirt) HWRAgent / HLRAgent (внутренний для Windows/Linux) |
RAW MSI-установщик / .deb, .rpm |
| Другие виртуализационные платформы / облака | — | HWRAgent / HLRAgent (внутренний для Windows/Linux) | MSI-установщик / .deb, .rpm |
| Физические серверы (Bare Metal) | — | HWRAgent / HLRAgent (внутренний для Windows/Linux) | MSI-установщик / .deb, .rpm |
Совместимость внутренних агентов с ОС
| Агент | Совместимые ОС |
|---|---|
| HWRAgent – Репликационный агент Хайстекс для Windows | Windows 2008R2 и новее (x64) |
| HLRAgent – Репликационный агент Хайстекс для Linux | AlmaLinux 8.4, 8.5, 8.6 ALT Linux 9, 10, 10.2 CentOS 6.5+, 7.1+, 8.0+, 9.0+ Debian 7, 8, 9, 10, 11, 12, 13 Oracle Linux 6.10, 7.9, 8.10, 9.5 RHEL 6.5+, 7.1+, 8.0+, 9.0+, 9.7, 10.0, 10.1 SLES 15 SP6 Ubuntu 14.04, 16.04, 18.04, 20.04, 22.04, 24.04, 25.10, 26.04 |
Поддержка ядер Linux для Linux-агента#
Note
Диапазоны версий указывают на самые ранние и самые поздние поддерживаемые сборки в каждом семействе ядер. Не каждая промежуточная сборка обязательно поддерживается. Чтобы проверить, поддерживается ли ваша версия ядра Linux, см. Список поддерживаемых версий.
RHEL/CentOS
| Семейство ядер | Поддерживаемые версии |
|---|---|
| 2.6.32-x | 2.6.32-220…2.6.32-754 |
| 3.10.0-x | 3.10.0-123…3.10.0-1160 |
| 4.18.0-x | 4.18.0-80…4.18.0-553 |
| 5.14.0-x | 5.14.0-70…5.14.0-611 |
| 6.12.0-x | 6.12.0-55…6.12.0-124 |
Ubuntu/Debian
| Семейство ядер | Поддерживаемые версии |
|---|---|
| 3.2.x | 3.2.0-4 |
| 3.13.0-x | 3.13.0-24…3.13.0-170 |
| 3.16.0-x | 3.16.0-4…3.16.0-77 |
| 4.2.0-x | 4.2.0-18…4.2.0-42 |
| 4.4.0-x | 4.4.0-21…4.4.0-210 |
| 4.15.0-x | 4.15.0-20…4.15.0-213 |
| 4.18.0-x | 4.18.0-13…4.18.0-25 |
| 5.0.0-x | 5.0.0-15…5.0.0-37 |
| 5.3.0-x | 5.3.0-19…5.3.0-64 |
| 5.4.0-x | 5.4.0-26…5.4.0-216 |
| 5.8.0-x | 5.8.0-23…5.8.0-63 |
| 5.10.0-x | 5.10.0-1…5.10.0-39 (включая варианты -cloud) |
| 5.15.0-x | 5.15.0-25…5.15.0-176 |
| 6.1.0-x | 6.1.0-1…6.1.0-44 (включая варианты -cloud) |
| 6.8.0-x | 6.8.0-31…6.8.0-110 |
| 6.12.x | 6.12.31…6.12.74 |
| 7.0.0-x | 7.0.0-14 |
ОС поддерживаемые P2V / V2V#
В этом разделе перечислены проверенные операционные системы, поддерживаемые модулем P2V/V2V Акура. Наиболее вероятно, другие ОС также могут работать, однако тестирования на них нашей командой не проводились.
| Семейство ОС | Поддерживаемые версии |
|---|---|
| AlmaLinux | 8.4, 8.5, 8.6 |
| ALT Linux | 9, 10, 10.2 |
| Astra Linux | CE 2.12, SE 1.6, SE 1.7.6, SE 1.8.1 |
| Debian | 7, 8, 9, 10, 11, 12, 13 |
| Oracle Linux | 6.10, 7.9, 8.10, 9.5 |
| Red OS | 7.3, 8 |
| RHEL / CentOS | 6.5+, 7.1+, 8.0+, 9.0+, RHEL 9.7, RHEL 10.0, RHEL 10.1 |
| SLES | 11, 12, 15 SP6 |
| Ubuntu | 14.04, 16.04, 18.04, 20.04, 22.04, 24.04, 25.10, 26.04 |
| Windows Desktop | Windows 7, 8, 8.1, 10, 11 |
| Windows Server | 2008 R2, 2012, 2012 R2, 2016, 2019, 2022, 2025 |
Поддерживаемые платформы и приложения#
Платформы:
VK Cloud, Yandex Cloud, K2 Cloud, Cloud.ru, Базис.Cloud, OpenStack, VMware, oVirt, OpenNebula, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Alibaba Cloud, Hyper-V, Nutanix, KeyStack, KeyVirt, физические машины.
Приложения:
Microsoft Active Directory, PostgreSQL, Postgres Pro, NGINX, Red Hat Jboss Enterprise, IBM WebSphere, Apache, VMware vSphere, MySQL, MongoDB, Hadoop, Spark и другие.
Рекомендуемые конфигурации#
При разворачивании Хайстекс Акура для миграции конфигурация зависит от общего количества машин, желаемого количества одновременно реплицируемых машин и типа установки - для теста, для одного проекта по миграции, для предоставления сервиса.
Примеры типичных конфигураций:
| Тип установки | Общее количество / количество одновременно реплицируемых машин | Количество нод | Конфигурация каждой ноды: ядра CPU / RAM / Disk |
|---|---|---|---|
| Тест | 50 / 5 | 1 | 8 / 16 GB / 200 Гб SSD |
| Единичный проект | 150 / 20 | 1 | 12 / 24 GB / 200 Гб SSD |
| Единичный проект | 350 / 40 | 1 | 16 / 32 GB / 200 Гб SSD |
| Единичный проект | 1000 / 100 | 1 | 24 / 48 GB / 300 Гб SSD |
| Предоставление сервиса | 1000 / 100 | 3 | 16 / 32 GB / 300 Гб SSD |
| Предоставление сервиса | 3000 / 200 | 3 | 24 / 48 GB / 300 Гб SSD |
Рекомендуемые высокопроизводительные конфигурации#
Note
Эти рекомендации актуальны при миграции большого числа виртуальных машин, включая ВМ большого размера (более 10 ТБ).
1. Убедитесь, что настройки соответствуют требованиям:
Note
Таблица актуальна только для внешнего агента VMware.
| Тип установка | Общее количество / количество одновременно реплицируемых машин | Количество нод | Конфигурация каждой ноды: ядра CPU / RAM / Disk | Ресурсы для агента | Количество копий сервиса |
|---|---|---|---|---|---|
| Единичный проект | 1000 / 100 | 1 | 24 / 128 GB / 300 GB SSD | 16 ядер, 32 GB RAM | auth – 10 restapi – 12 acp – 3 receiver – 12 keeper – 5 |
| Предоставление сервиса | 1000 / 100 | 3 | 24 / 128 GB / 300 GB SSD | 16 ядер, 32 GB RAM | auth – 15 restapi – 18 acp – 5 receiver – 18 keeper – 8 |
2. Установите и используйте режим HotAdd для переноса данных.
Ограничения Хайстекс Акура#
- Виртуальные машины с дисками, задействованными в совместном использовании шины SCSI, не поддерживаются, поскольку VMware не поддерживает снапшот таких виртуальных машин.
- Машины Linux со статическими IP-адресами сохранят исходные сетевые настройки.
- Виртуальные диски RDM в режиме физической совместимости, независимые диски и диски, подключенные через гостевой инициатор iSCSI, не поддерживаются. Сетевые ресурсы и точки подключения, предназначенные для сторонних устройств хранения данных, также пропускаются, поскольку эти тома/диски не отображаются в файле конфигурации виртуальной машины.
- Бесплатный ESXi не поддерживается. Хайстекс Акура использует API-интерфейсы vSphere и vStorage, которые отключены VMware в бесплатном ESXi.
- Агент репликации Хайстекс для Windows поддерживает файловые системы NTFS, ReFS.
- Агент репликации Хайстекс для Windows преобразует динамические диски в базовые во время миграции.
- Агент репликации Хайстекс для Linux поддерживает репликацию машин с количеством дисков до 64.
- Агент репликации Хайстекс для Linux не поддерживает установку и эксплуатацию на системах с включённым Secure Boot.
- Серверы Windows с включенной функцией реплики хранилища не поддерживаются.
- Сети с динамическими портами не поддерживаются.
- Активный ЗПС и МКЦ не поддерживаются.
- Также из-за отсутствия подписи не поддерживаются из коробки конфигурации с Secure Boot и параметром ядра module.sig_enforce=1
- Виртуальные машины, использующие mdraid в качестве корневой файловой системы, поддерживаются с ограничениями. Возможности восстановления и миграции P2V/V2V для них ограничены. Для RHEL, CentOS и аналогичных операционных систем необходимые драйверы должны быть вручную добавлены в dracut на исходной виртуальной машине перед репликацией / миграцией. Скрипты
rclocal_scriptиfix_dev_prefix, указанные в плане миграции, не выполняются. - При P2V-миграции преобразование режима загрузки BIOS в UEFI не поддерживается. Значение параметра
firmware, указанное в плане миграции, должно соответствовать режиму загрузки исходной машины.
Ограничения AWS#
Хайстекс Акура использует механизм импорта образа для запуска реплицированных машин на AWS, поэтому применяются все ограничения "Импорт Образа". Для получения более подробной информации обратитесь к официальной документации AWS.
Ограничения MS Azure#
- SSH-ключ не может быть прикреплен к ВМ, поскольку они создаются из томов.
- MAC-адрес не может быть установлен для сетевой карты.
- Каждая ВМ будет иметь дополнительный том временного хранилища. Размер объёма зависит от конфигурации. Более подробную информацию можно получить здесь: https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/
- По умолчанию для ВМ не будут назначены группы безопасности. Обратитесь к разделу Планы миграции и используйте ключ "security_group" в планах миграции.
- Миграция CentOS 6.2 не поддерживается. Обратитесь к https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros для получения более подробной информации.
Ограничения KubeVirt#
-
Встроенная сеть Kubernetes - единственный доступный вариант сетевого взаимодействия. Она используется для облачного агента и может быть использована для мигрированных виртуальных машин при указании значения
podв качествеID подсетив плане миграции. -
Задание IP-адреса порта в плане миграции не применяется.
-
Механизм обнаружение подсетей в плане миграции не возвращает значения CIDR.
-
Машина остаётся заблокированной до тех пор, пока восстановление не будет удалено или отключено.
-
При удалении восстановления следующая репликация будет выполняться полностью.
Ограничения VMware#
- Максимальное количество точек восстановления, сохранённых для одной машины, равно 29.
- Репликация и failover одной и той же машины не могут быть запущены одновременно, поскольку оба процесса работают с одной и той же машиной на целевой стороне.
Лицензирование реплицированных машин на AWS#
Согласно требованиям AWS, машины, работающие под управлением Red Hat Enterprise Linux (RHEL), должны иметь лицензии Cloud Access (BYOL) для копирования в AWS, в то время как машины с Windows будут использовать лицензирование AWS. Для получения дополнительной информации, пожалуйста, обратитесь к официальному руководству AWS.