Описание решения#
Хайстекс Акура - это решение для аварийного восстановления и резервного копирования бизнес-приложений и ИТ-инфраструктуры в случае чрезвычайной ситуации или для миграции между облаками.
Процесс аварийного восстановления состоит из первоначальной репликации компонентов бизнес-приложений (машин), элементов инфраструктуры в резервный центр обработки данных и последующего запуска failover продуктивной среды из одной из точек восстановления. Запуск failover происходит на резервной площадке, при запуске восстанавливается исходная ИТ-инфраструктура, включающая все прежние/исходные элементы.
Резервное копирование отличается от сценария аварийного восстановления используемым хранилищем - в отличие от блочного хранилища, используемого при аварийном восстановлении, для сценария резервного копирования используется более эффективное для долговременного хранения объектное хранилище.
Репликация доступна для ресурсов, работающих на VMware, Hyper-V, OpenStack, Cloud.ru, VK Cloud, Yandex Cloud, K2 Cloud, KeyStack, KeyVirt, а также для физических машин.
Архитектура#
Решение состоит из серверной и клиентской частей. Серверная часть содержит компоненты, которые устанавливаются на резервном DC и отвечают за извлечение изменений с клиентских устройств, их дедупликацию, хранение данных и failover в случае сбоя. Серверная часть также включает в себя хранилище - хранилище объектов, расположенное в резервном центре обработки данных, где сохраняются полные и инкрементные репликации клиентских машин.
Что касается клиентской части, то она включает в себя агенты, установленные на VMware vSphere/oVirt/OpenStack для репликации машин на облачной платформе, или агенты для Windows/Linux, установленные на гостевых операционных системах для репликации других типов облачных платформ и физических машин.
Агент 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/OpenStack нет необходимости устанавливать агенты 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.
Подключение к хранилищу
Требования к подключению зависят от выбранного типа хранилища.
- При использовании объектного или файлового хранилища контроллер должен иметь сетевой доступ к хранилищу, поскольку оно находится за пределами целевой облачной платформы.
- При использовании блочного хранилища дополнительное сетевое подключение контроллера не требуется, поскольку данные репликации сохраняются непосредственно в целевой облачной платформе.
Схема резервного копирования PostgreSQL#
Резервное копирование PostgreSQL в Акуре сочетает возможности встроенных средств резервного копирования PostgreSQL с централизованной оркестрацией и управлением хранилищем, которые предоставляет Акура.
Warning
Резервное копирование PostgreSQL требует пользовательской реализации логики резервного копирования и восстановления. Перед включением защиты убедитесь, что сценарии резервного копирования и восстановления правильно настроены и протестированы в вашей среде. Некорректная конфигурация может привести к созданию неполных резервных копий, невозможности успешного восстановления или даже к повреждению исходной виртуальной машины.
Important
Перед настройкой резервного копирования убедитесь, что база данных подготовлена к выполнению операций резервного копирования и что у используемой учетной записи имеются необходимые разрешения.
-
На исходной системе операции резервного копирования и восстановления выполняются с использованием встроенных средств PostgreSQL. Сценарии автоматизации резервного копирования и восстановления работают совместно с агентом резервного копирования PostgreSQL Акуры. Эти поддерживаемые пользователем сценарии содержат специфичную для базы данных логику подготовки, выполнения и проверки операций резервного копирования и восстановления.
-
Акура предоставляет шесть примеров сценариев: четыре для резервного копирования и два для восстановления. По умолчанию эти сценарии не выполняют никаких действий — вся логика резервного копирования и восстановления в них закомментирована. Сценарии служат шаблонами и содержат комментарии, рекомендации и примеры использования встроенных средств PostgreSQL, таких как
pg_dump,pg_basebackupи архивирование WAL. Перед включением защиты изучите и адаптируйте сценарии в соответствии с требованиями вашей среды PostgreSQL. -
Агент резервного копирования PostgreSQL может собирать и передавать контроллеру Акуры файлы резервных копий и архивированные журналы WAL. Контроллер централизованно управляет процессами резервного копирования и восстановления, применяет политики и расписания, отслеживает состояние заданий и координирует операции с хранилищем.
-
Данные резервного копирования хранятся и управляются средствами Акуры. При восстановлении Акура извлекает необходимые файлы резервных копий из хранилища и координирует процесс восстановления.
-
Файлы резервных копий доступны для скачивания в виде файлов и каталогов. Текущее ограничение: восстановление резервных копий на уровне файлов поддерживается только на исходную машину, с которой была создана резервная копия.
Перенос и хранение данных#
Процесс репликации передает данные из исходной среды в выбранное хранилище целевой облачной платформы. В зависимости от выбранного типа хранилища данные репликации сохраняются либо в блочном хранилище внутри целевой облачной платформы, либо во внешнем объектном или файловом хранилище.
Акура поддерживает следующие типы хранилищ:
- Блочное хранилище — рекомендуется для сценариев аварийного восстановления и миграции.
- Объектное хранилище — рекомендуется для сценариев резервного копирования.
- Файловое хранилище — рекомендуется для сценариев резервного копирования.
Репликация данных#
Репликация начинается после того, как машина с запущенным репликационным агентом зарегистрирована в панели управления Акуры и для нее включена репликация.
Репликационный агент передает данные репликации контроллеру Хайстекс Акуры, который управляет процессом репликации в соответствии с настроенным расписанием.
Дальнейший поток данных зависит от выбранного типа хранилища.
Блочное хранилище
Контроллер передает данные репликации облачному агенту, который записывает их в блочное хранилище целевой облачной платформы. При последующих циклах репликации передаются только измененные блоки данных, а точки восстановления создаются в соответствии с заданной политикой.
Объектное или файловое хранилище
Контроллер записывает данные репликации непосредственно во внешнее настроенное хранилище. Целевая облачная платформа не участвует в хранении данных репликации.
Note
Для целевых сред VMware и oVirt облачный агент необходимо развернуть вручную. Для всех остальных поддерживаемых облачных платформ он создается контроллером автоматически.
Хранение данных#
Выбранный тип хранилища определяет, как хранятся данные репликации и как выполняется их восстановление.
Блочное хранилище
Данные репликации хранятся в виде томов и снимков в целевой облачной платформе. Точки восстановления становятся сразу доступны для восстановления машин, что позволяет свести время восстановления к минимуму. Этот тип хранилища рекомендуется для сценариев аварийного восстановления и миграции, где приоритетом является быстрое восстановление.
Объектное и файловое хранилище
Данные репликации хранятся во внешнем объектном (например, S3-совместимом или Azure Blob) либо файловом хранилище (NFS или SMB/CIFS). Эти типы хранилищ оптимизированы для долгосрочного хранения резервных копий и эффективного использования дискового пространства благодаря таким возможностям, как дедупликация. Они хорошо подходят для сценариев резервного копирования, однако восстановление обычно занимает больше времени, поскольку данные необходимо сначала восстановить в целевую облачную платформу.
Восстановление данных#
Процесс восстановления также зависит от выбранного типа хранилища.
Блочное хранилище
Восстановление полностью выполняется в целевой облачной платформе. Контроллер создает том восстановления на основе выбранной точки восстановления, создает виртуальную машину, подключает к ней том восстановления и завершает процесс восстановления машины.
Поскольку тома восстановления уже находятся в целевой облачной платформе, виртуальные машины обычно можно восстановить в течение нескольких минут.
Объектное и файловое хранилище
Восстановление начинается с копирования выбранной точки восстановления из внешнего хранилища в том восстановления в целевой облачной платформе. После создания тома восстановления дальнейший процесс аналогичен восстановлению из блочного хранилища: том восстановления подключается к новой виртуальной машине, после чего она запускается.
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 – отправка логов в Акуру |
| Агент Failback VMware | Разрешения хоста: Failback в Vmware | tcp/443 – связь с хостом vSphere tcp/udp/902 – связь с хостами ESXi udp/12201- отправка логов в Акуру |
| Агент Failback Flexible Engine | Разрешения хоста: Failback в Flexible Engine | tcp/443 – отправка данных в Акуру udp/12201 – отправка логов в Акуру Порты для связи с облачным API, например tcp/5000 для keystone |
| Агент Failback OpenStack | Разрешения хоста: Failback в OpenStack | tcp/443 – отправка данных в Акуру udp/12201 – отправка логов в Акуру Порты для связи с облачным API, например tcp/5000 для keystone |
| Failback для других облаков | Для других облаков failback выполняется в форме оперативной обратной миграции рабочих нагрузок в исходную среду. Внутренние агенты репликации устанавливаются непосредственно на отказоустойчивые машины. |
Матрица совместимости Акуры и поддерживаемые системы#
Матрица развертывания агентов репликации#
Платформы и агенты репликации Акуры, доступные к развертыванию на них:
| Исходная платформа | Поддерживаемые версии / Примечания | Тип агента | Метод распространения |
|---|---|---|---|
| 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 |
|---|---|---|---|
| Тест | 15 | 1 | 8 / 16 GB / 200 Гб SSD |
| Единичный заказчик | 50 | 1 | 16 / 32 GB / 200 Гб SSD |
| Единичный заказчик | 150 | 3 | 16 / 32 GB / 200 Гб SSD |
| Единичный заказчик | 250 | 3 | 24 / 48 GB / 300 Гб SSD |
| Предоставление сервиса | 500 | 3 | 32 / 64 GB / 300 Гб SSD |
| Предоставление сервиса | 1000 | 5 | 32 / 64 GB / 300 Гб SSD |
Ограничения Хайстекс Акура#
- Виртуальные машины с дисками, задействованными в совместном использовании шины SCSI, не поддерживаются, поскольку VMware не поддерживает снапшот таких виртуальных машин.
- Виртуальные диски 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.