Помните программу «Сто вопросов взрослому», где герою задают прямые и неудобные вопросы, на которые нельзя ответить отговорками? По-моему, это отличный формат и для общения с отделом разработки. Особенно когда приходится защищать перед техлидами нестандартные решения — например, миграцию вообще без использования облачного API.

В идеальном мире миграция работает как часы: контроллер подключается к платформе по API, автоматически создает сети, разворачивает машины и переносит данные. В суровой реальности крупного энтерпрайза эта схема часто рушится: целевое облако может быть «самописным» и не иметь нужных методов, либо безопасники отказываются пускать стороннее ПО в закрытый контур. Для работы в условиях таких ограничений мы используем режим Direct2Target (D2T). Это подход, при котором данные передаются напрямую на диски заранее подготовленной ВМ, полностью минуя интеграцию с управляющим слоем облака.

В теории концепция звучит изящно, но у инженеров логично возникает скепсис по поводу физики процесса. Я расшифровал техническую сессию с нашего недавнего вебинара. Вопросов под катом, конечно, не сто, но я оставил самую суть — те, что нам чаще всего задают архитекторы: как не утилизировать сеть на 100%, как «наживую» перенести PostgreSQL без потери консистентности, как пробиться через глухой NAT и что делать, если целевая ВМ не завелась.

Производительность и ограничения миграции

• D2T медленнее обычной миграции через API — есть ли разница и существенна ли она?

Короткий ответ — нет, на самой передаче данных разницы практически нет. Длинный — давайте разберём, где она в принципе могла бы возникнуть. 

И API-интеграция, и D2T используют одни и те же каналы связи и механизмы блочной передачи. Ограничения упираются только в пропускную способность сети и скорость дисков целевого облака. D2T «медленнее» с точки зрения ручного труда инженера при работе с большими объемами. Поэтому для массовых сценариев всегда рекомендуется переходить на полноценную API-интеграцию, а D2T использовать как инструмент для быстрого точечного старта на новых или закрытых площадках.

• Какие ограничения есть для пропускной способности сети и какая утилизация каналов? 

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

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

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

Да, можно. В настройках контроллера Акуры предусмотрена специальная опция для ограничения полосы пропускания (установки потолка).

Как это работает на практике:

• По умолчанию: Если не задавать лимиты, процесс репликации может утилизировать весь доступный сетевой канал на 100%, чтобы выполнить перенос максимально быстро.

• Установка потолка: Ограничение настраивается вручную. Это особенно важно в ситуациях, когда сетевой канал делится с другими рабочими процессами. Установка лимита гарантирует, что миграция не «забьет» канал полностью и не парализует работу остальной инфраструктуры.

• Возможно ли мигрировать большие ВМ (например, >4 ТБ)? 

Ограничений по размеру дисков нет, система работает на блочном уровне. Ей «неважно, какой диск» — она просто берет блоки данных на исходной стороне и пересылает их на целевую. Поэтому размер виртуальной машины и ее дисков ограничивается только возможностями инфраструктуры и облака, куда вы переезжаете, но не самой Акурой.

• Что происходит, если план миграции завершился неуспешно? Нужно ли заново создавать целевую ВМ? 

Если переключение (запуск целевой ВМ) прошло с ошибкой, точный порядок действий зависит от характера сбоя: зафиксировал ли контроллер критическую ошибку, или же машина просто не смогла загрузить операционную систему после перезагрузки. В зависимости от статуса ошибки в интерфейсе Акуры будут активны разные кнопки.

Пока автоматизация в разработке, общий алгоритм восстановления выглядит так:

1. В интерфейсе Акуры нажмите ту опцию, которая активна для вашего типа сбоя: «Отсоединить» (Detach) или «Удалить» (Delete).

2. В целевом облаке удалите испорченную ВМ-приемник. Поскольку при переключении в машину уже начали вноситься изменения (V2V-конвертация, добавление драйверов), для чистоты процесса её нужно пересоздать из исходного D2T-образа.

3. Снова в Акуре удалите саму машину из системы, чтобы она вернулась в статус «Обнаружено».

4. Запустите полное резервное копирование (Full Backup) и повторите процесс миграции.

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

Репликация, базы данных и консистентность

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

Да. Хотя D2T работает на блочном уровне (диски целиком), для PostgreSQL и других СУБД у нас есть отдельное решение — файловый агент. Он работает на уровне ОС, использует нативные скрипты автоматизации и умеет готовить базу к миграции без остановки. Это гарантирует консистентность даже для высоконагруженных или шардированных систем.

• Живая репликация только ВМ? Какие варианты для PostgreSQL / СУБД? Можно ли реплицировать шардированные БД? 

Нет, живая репликация доступна не только для виртуальных машин (на блочном уровне), но и для баз данных (на файловом уровне). Для работы с СУБД (включая PostgreSQL и шардированные базы) у команды предусмотрено другое решение — отдельный файловый агент. Режим Direct2Target (D2T), о котором идет речь в статье, решает иную задачу и работает с ВМ на уровне блоков.

СУБД можно реплицировать «наживую», ее не обязательно предварительно «парковать» (останавливать) вручную. Файловый агент работает с базами данных на «нативном» уровне. В него встраиваются специальные скрипты автоматизации, которые «знают» механику работы конкретной СУБД. Эти скрипты сами корректно готовят базу к миграции (например, управляют пересылкой WAL-журналов в случае с PostgreSQL). Файловый агент можно переиспользовать для любой СУБД, если написать или адаптировать соответствующие скрипты автоматизации под ее механику.

• Какие есть требования к сетевой связности между источником, агентом и целевой площадкой? Работает ли D2T в сценариях с NAT или закрытыми сегментами сети? 

Да, режим Direct2Target (D2T) работает в сценариях с NAT и в закрытых сегментах сети. Тип сети не мешает работе D2T. Главное — точечно разрешить контроллеру и источнику доступ к целевой машине по нужному IP и портам.

Базовые требования к сетевой связности сводятся к двум основным пунктам:

• Доступность IP-адреса целевой ВМ: Главное требование — обеспечить маршрут, по которому контроллер сможет достучаться до агента-приемника (D2T-агента), запущенного внутри целевой ВМ. Если машина находится за NAT или в закрытом сегменте, ей необходимо назначить публичный IP-адрес или настроить соответствующие правила проброса (port forwarding), чтобы контроллер «видел» ее по этому IP.

• Открытые порты:

  • TCP 80: На этом порту D2T-агент внутри целевой машины слушает входящие подключения от контроллера (если они находятся в разных подсетях, нужно настроить правила firewall для пропуска этого трафика).

  • TCP 443: По этому порту осуществляется защищенная передача самих данных репликации от исходной площадки на целевую сторону. На текущий момент поток данных от исходной площадки направляется в контроллер, а не напрямую к целевой машине. Механизмы прямой передачи трафика по HTTPS между агентами и распределенная сеть принимающих узлов находятся в разработке и пока не реализованы.

•  Как обеспечивается консистентность «горячих» БД в режиме D2T?

Сам по себе Direct2Target (D2T) эту задачу не решает, так как он предназначен для переноса машин целиком на уровне дисков и решает проблему отвязки от API облака.

Для обеспечения консистентности «горячих» баз данных (без их ручной остановки) в системе предусмотрен отдельный подход — использование специализированного файлового агента. Таким образом, консистентность горячих БД обеспечивается не механизмом D2T, а переходом на использование специализированного файлового агента со скриптами под конкретную СУБД.

Вот как это работает:

• Файловый уровень вместо блочного: агент работает не с дисками целиком, а непосредственно с файлами и механикой самой СУБД (например, PostgreSQL).

• Скрипты автоматизации: в этот файловый агент инжектятся (встраиваются) специальные скрипты, которые «нативно» знают механизм работы конкретной базы данных.

• Правильная «парковка» (Quiescing): именно эти скрипты отвечают за то, чтобы «наживую» подготовить СУБД к репликации — правильно ее «запарковать» (перевести в консистентное состояние) и управлять специфическими процессами (например, пересылкой WAL-журналов), пока идет перенос.

• Нужно ли «парковать» СУБД перед миграцией? 

Нет, вручную «парковать» (останавливать) СУБД не обязательно, если использовать правильный инструмент. Вместо ручной остановки системы можно использовать автоматизацию на уровне файлового агента, который сделает всё необходимое «наживую».

1. Для «живой» репликации используется специальный файловый агент (отличное от D2T решение).

2. Скрипты автоматизации: В этот агент встроены скрипты, которые «нативно» знают механику конкретной СУБД (например, PostgreSQL).

3. Консистентность на лету: Эти скрипты сами готовят базу к миграции и обеспечивают её консистентность прямо в процессе работы (например, через управление WAL-журналами).

Сети, закрытые контуры и почему нам достаточно одного IP

• Сети нужно заводить заранее? 

Да. В режиме Direct2Target (D2T) вы самостоятельно подготавливаете целевую ВМ-приемник до начала миграции. Следовательно, сетевую связность для этой машины (выбор нужной сети, настройка маршрутов) также необходимо обеспечить заранее.

• Есть ли функционал автоматической настройки сетей на целевой площадке?

На данный момент — нет. Конкретно в подходе D2T контроллер не ходит в API облака и не создает сети или правила доступа автоматически. В текущей версии D2T-агента пользователю нужно вручную выполнить нужные настройки на стороне облака: например, навесить публичный IP-адрес или настроить правила firewall (Security Groups), чтобы контроллер Акуры смог достучаться до агента.

В будущих релизах частичная автоматизация будет добавлена.

• Поддерживается ли EVPN / VxLAN? 

Агенту Direct2Target не важна базовая сетевая технология, используемая в вашем облаке (будь то обычные VLAN, NAT, VPN, EVPN или VxLAN). Главное и единственное требование со стороны Акуры — наличие базовой маршрутизации (IP-связности). Если ваша сеть (включая оверлеи типа VxLAN) настроена так, что пакеты от контроллера доходят до IP-адреса целевой ВМ, то репликация будет успешно работать.

В подключении D2T-облака в контроллере задаются только имя и блочное хранилище по умолчанию. Никаких точек подключения, портов или учетных данных. В настройках самой репликации единственный сетевой параметр на целевую сторону — IP адрес d2t агента на целевой ВМ. Всё остальное — EVPN/VxLAN/SG/route-таблицы — заказчик делает руками на стороне платформы.

• Можно ли шифровать данные миграции?

Передача данных идет по стандарту HTTPS (порт 443). Трафик шифруется in-transit на всем пути от источника до целевого приемника. Дополнительное шифрование «внутри» агента не требуется, так как данные на нем не хранятся, а сразу пишутся на целевые диски.

• Есть ли у вас схема сетевых потоков в документации?

Да. Схема с архитектурой и всеми сетевыми потоками доступна в официальной документации.

Архитектура и работа агента

• Возможен ли безагентский режим? 

Да, возможен. Безагентский подход применим для исходной стороны миграции (площадки, откуда вы забираете машины). Данные можно забирать напрямую на уровне гипервизора. Это значит, что вам не нужно «погружаться в каждую машину» и устанавливать агенты внутрь гостевой операционной системы каждой конкретной ВМ, которую вы планируете перенести.

• Что происходит при ошибке в конфигурации целевой ВМ?

  1. Автоматическая проверка: поскольку в режиме D2T целевая машина создается вручную, контроллер проводит базовую валидацию, чтобы исключить риск сбоя. Эта проверка работает по принципу достаточности:

• Проверка вычислительных ресурсов: жесткой сверки с параметрами исходной машины здесь нет. На этапе передачи данных целевой машине достаточно иметь лишь тот объем оперативной памяти, который нужен для стабильной работы принимающего агента. Выставить рабочие значения вычислительных мощностей можно уже после завершения миграции и перезагрузки системы на новой площадке.

• Проверка дисковой подсистемы: здесь контроллер проверяет конфигурацию строже, но также по принципу минимальной достаточности. Количество дисков должно быть не меньше, чем на источнике, а размер каждого целевого диска не должен уступать исходному. Целевая конфигурация может быть больше исходной (диски могут быть объемнее) — миграция пройдет успешно.

  2. Уведомление об ошибке: если обнаружено несоответствие, контроллер сообщит об этом пользователю.

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

Таким образом, несмотря на наличие «человеческого фактора» при ручной подготовке ВМ в режиме Direct2Target, программные проверки под капотом минимизируют риск поломки процесса.

• Где хранится резервная копия перед миграцией? Что происходит с резервной копией после миграции?

В режиме D2T данные не сохраняются в каком-то промежуточном хранилище контроллера. Они передаются напрямую на целевую площадку. Резервная копия фактически представляет собой данные, записанные на целевые диски той самой виртуальной машины-заготовки, которую вы создали вручную. Данные с исходной стороны (например, из VMware) «льются» через сеть и записываются агентом-приемником сразу на подготовленные диски в целевом облаке. Таким образом, к моменту завершения репликации актуальное состояние машины уже находится на дисках целевой ВМ.

Когда вы убедились, что машина успешно переехала и работает, выполняется процедура отсоединения миграции (Detach). После этого:

1. Удаление метаданных: Акура «забывает» об этой машине и удаляет всю служебную информацию о ней из своей базы.

2. Очистка точек восстановления: все промежуточные точки восстановления (снапшоты), созданные в процессе репликации, удаляются.

3. Автономия ВМ: сама виртуальная машина в целевом облаке остается нетронутой. Она продолжает работать, живет своей жизнью, и Акура больше никак ею не управляет и ничего о ней не знает.

После успешного завершения (Detach) все временные данные репликации зачищаются, а целевая ВМ становится основной и независимой.

Совместимость и поддержка инфраструктуры

• Есть ли поддержка GPU? Что со специфическими устройствами?

Да, поддержка специфических устройств, включая GPU, есть. В рамках подхода Direct2Target (D2T) этот вопрос решается максимально гибко, потому что подготовка «железа» полностью делегируется пользователю и возможностям целевого облака.

Так как в режиме D2T вы создаете целевую виртуальную машину-заготовку вручную, вы можете добавить к ней любые адаптеры и устройства, которые предоставляет ваш целевой облачный провайдер. Это могут быть GPU (видеокарты), специфические звуковые карты или особые сетевые адаптеры.

Акура никак не ограничивает выбор железа. Вы полностью там выбираете любую конфигурацию машины и запускаете её. 

Если целевая платформа (гипервизор или облако) физически располагает нужными GPU и позволяет назначить их на виртуальную машину, вы просто выбираете этот инстанс при ручном создании ВМ.

Здесь стоит сделать важное техническое уточнение. В процессе V2V-конвертации система устанавливает только стандартный (базовый) набор драйверов — ровно тот минимум, который необходим для успешной загрузки операционной системы на новой площадке. Драйверы под специфическое оборудование автоматически не добавляются.

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

Сценарии использования D2T

Во всех случаях D2T выступает не как замена полноценной автоматизации, а как универсальный инструмент разблокировки проектов, которые могут упираться в инфраструктурные или бюрократические барьеры.

• Запуск пилотных проектов (PoC): быстрый тест облака для клиента без ожидания 6–8 недель на разработку интеграции.

• Редкие и «самописные» облака: D2T делает процесс независимым от платформы, нужен только доступ к сети и возможность развернуть образ.

• Жесткий Compliance: спасает в изолированных контурах, где безопасники запрещают стороннему ПО доступ к API платформы.

• Нестабильный API вендора: обход ограничений, если API формально есть, но работает некорректно и не отдает нужные ресурсы.

• Точечные миграции: перенос пары тяжелых серверов, ради которых инвестировать время в разработку глубокой интеграции с API просто нерентабельно.