Привет, Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что оба сценария можно применять параллельно.
При переносе виртуальных машин между облаками и частными контурами API-интеграция обычно даёт максимум автоматизации. Но как только целевых площадок становится больше одной-двух или появляется «собранная на коленке» платформа, выясняется, что у этой автоматизации есть цена. Миграция через API превращается в отдельный проект на недели разработки и тестирования. Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку. В статье про то, как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы.
Что такое Direct2Target и зачем он понадобился
Классическая облачная миграция обычно строится на интеграции с целевой платформой: через API контроллер создаёт целевую ВМ, подключает диски, настраивает сеть и дальше управляет жизненным циклом ресурсов. Это удобно и отлично ложится в корпоративную автоматизацию, но есть естественная цена: каждое новое облако = отдельная интеграция, а это недели разработки и тестирования (и потом ещё сопровождение).
Когда целевых площадок становится слишком много, возникает вопрос: как сделать миграцию предсказуемой без ожидания поддержки вендора и без разработки новой интеграции под каждую платформу?
Так в решении Хайстекс Акура мы пришли к режиму Direct2Target, при котором целевая сторона миграции разворачивается не через облачный API, а как заранее подготовленная ВМ-приёмник.
D2T при этом не заменяет существующие режимы миграции, а добавляет отдельный способ доставки и запуска облачного агента.
API или D2T: как выглядит миграция в двух режимах
Если отбросить детали, выбор простой: либо мы автоматизируем всё в один шаг из контроллера через API, либо берём на себя ручную подготовку целевой ВМ. В Акуре эти два подхода живут параллельно, и дальше я покажу, чем они отличаются на уровне действий и требований.
Интеграция через API
В стандартном сценарии Акура умеет:
автоматически создавать целевую ВМ;
управлять дисками и их подключением;
настраивать сеть;
разворачивать вспомогательную ВМ-агент (Cloud Agent), принимающую данные репликации.
Что обычно требуется от платформы:
полноценный API (compute / storage / network);
достаточные роли и права;
предсказуемая модель ресурсов;
время на разработку и поддержку интеграции (обычно 6–8 недель на новую платформу).
Плюсы: максимум автоматизации, масштабируемость, удобство для корпоративных сценариев.
Минусы: зависимость от API и наличия готовой интеграции.
Интеграция через Direct2Target
D2T использует принципиально другой подход, контроллер не создает ресурсы в целевом облаке. Целевую ВМ готовит пользователь:
из предоставленного нами готового образа;
с предустановленным агентом приёмником;
с нужным размером CPU / RAM / дисков;
в нужной сети.
После запуска приёмник регистрируется в контроллере Акуры и может быть выбран целевой машиной для миграции.
Что требуется от целевой платформы:
возможность запустить пользовательский образ ВМ;
базовая сетевая связность (IP + маршрут до контроллера);
стандартные ресурсы ВМ (CPU, RAM, диск, сеть).
Как это выглядит на практике:
Вы берёте наш образ приёмника D2T.
Запускаете ВМ в целевом облаке/площадке (задаете CPU/RAM/диски/сеть).
Приёмник поднимается и регистрируется в контроллере.
В мастере миграции выбираете этот приёмник как целевую сторону.
Запускаете перенос и дальше управляете процессом из контроллера.
Типовой путь D2T выглядит так: быстро зайти к клиенту → сделать PoC → доказать работоспособность → затем (если нужно) перейти к полноценной интеграции.
Тут легко ошибиться в интерпретации, поэтому оговорю важный нюанс: мы не “переводим контроллер в D2T-режим”. Контроллер остаётся тем же самым, меняется только то, как он видит целевую сторону. В D2T он не ходит в API целевого облака: для этой миграции контроллер общается по сети напрямую с приёмником D2T, который запущен внутри заранее подготовленной целевой ВМ. То есть вместо “контроллер → cloud API” получается “контроллер → сеть → приёмник”.
Плюсы:
1. Поддержка любых платформ. Фактически решение становится облачно-агностичным и отвязывает миграцию от конкретного облачного API и вендора. Любая среда, где можно запустить целевую ВМ (из нашего образа) и обеспечить сетевую связность с контроллером, может выступать целевой площадкой миграции, будь то публичное, частное или самописное облако.
2. Минимальные требования к инфраструктуре. Нет зависимости от API, его стабильности или полноты. Это особенно важно в закрытых, ограниченных или нестандартных средах.
3. Быстрый старт. Не нужно ждать появления официальной интеграции. D2T позволяет начать проект сразу, а при необходимости позже перейти на полностью автоматизированный режим.
4. Снижение стоимости разработки. Один универсальный образ приёмника подходит для многих сред и экономит ресурсы команды на интеграции.
5. Гибкость для заказчиков. В средах с жёсткими требованиями безопасности ручная подготовка ресурсов зачастую единственно допустимый вариант.
Минусы:
D2T — это не «волшебная кнопка» , у подхода есть ограничения, о них ниже:
требуется ручная подготовка ВМ (выше риск человеческих ошибок);
неудобно для массовых миграций;
сложнее встраивается в полностью автоматизированные корпоративные процессы;
недоступны некоторые функции, завязанные на контроль API (например, снапшоты целевой ВМ).
Поэтому D2T не заменяет классический режим, а дополняет его.
Если свести всё выше к выбору, то он звучит как дилемма: либо максимальная автоматизация через API, либо универсальность на «нестандартных» площадках. Но на практике это не взаимоисключающие варианты. В Акуре эти два режима просто живут рядом, решают разные задачи и закрывают разные условия проекта.
D2T полезен там, где API-интеграция недоступна, ограничена или не окупается по времени: подняли приёмник, обеспечили связность, начали перенос. Если позже появляется смысл в полной автоматизации (массовые миграции, корпоративные процессы), можно перейти на API-режим. В итоге получается рабочая комбинация: универсальность для сложных сред и автоматизация там, где она действительно приносит пользу.
