Классическая бытовая дилемма: после ужина в раковине лежат две тарелки. Загружать посудомойку кажется избыточным оверхедом — быстрее сполоснуть руками. Но если вы только что приняли званный ужин на 10+ персон, ручная мойка уже покажется более утомительной.
В инфраструктурных задачах этот «парадокс посудомойки» преследует нас постоянно. Когда нужно мигрировать пару виртуальных машин, инженеру проще и быстрее сделать всё руками, чем настраивать сложные паплайны. Но сегодня, на фоне массового импортозамещения, смены гипервизоров (привет, VMware!) и курса на построение гибридных сред, масштаб задач изменился. В условиях миграции сотен ВМ привычка полагаться на ручной труд становится непозволительной роскошью.
В идеальном мире миграция — это «черный ящик»: нажал кнопку, и всё переехало. Но в условиях фрагментированного отечественного рынка виртуализации мы сталкиваемся с разной степенью зрелости API. Под катом попробуем разобраться, как устроены решения для миграции и какие функции берет на себя агент на стороне-приемнике.
Дисклеймер: речь пойдет не об агентной или безагентной миграции. Это разделение довольно условно, поскольку агент репликации де-факто есть всегда, вопрос лишь в том, устанавливается ли он на уровне ОС или на уровне гипервизора.
Архитектурно всё начинается стандартно: контроллер управляет процессом, агенты отслеживают изменения на источнике. Разница возникает в том, как эти данные приземляются в облаке. В API-сценарии контроллер работает как оркестратор: он взаимодействует с агентами на источнике, которые передают данные в приемник, приемник тоже является частью контроллера и все процессы, которые происходят в нем, незаметны для администратора. Приемник получает данные и передает их автоматически поднимаемому облачному агенту. Облачный агент записывает данные в том-реплики хранилища. Таким образом, создаются снапшоты или точки восстановления, из которых далее можно будет по кнопке поднять новую машину.
В режиме D2T (direct to target - так мы называем метод универсального агента в Хайстекс Акура) приемником становится за��анее поднятая в целевом облаке виртуальная машина, которая взаимодействует через контроллер с агентами репликации. Минусом такого сценария является то, что в случае сбоя восстановления у клиента не будет точек восстановления и придется начинать заново весь процесс, начиная с репликации. Преимущество же в том, что режим служит «универсальным адаптером» для любых нестандартных кейсов.
Контроллер vs. Человек
Контроллеру для работы нужны лишь права, человеку – квалификация. При универсальном подходе контроллер больше не делает магию за вас, клиент сам отвечает за настройки доступа к сети, загрузку образов, уровень ресурсов и тп. Если в API-интеграции достаточно просто прав доступа, то «ручной» режим требует от инженера глубокой экспертизы в управлении конкретным облаком. Экономика здесь должна учитывать стоимость заранее поднятой болванки и риски человеческого фактора при ошибочной конфигурации.
Казалось бы, если API-подход (наша «посудомойка») так хорош, зачем вообще оставлять возможность ручного метода? Проблема в том, что «классическая» миграция нуждается в глубокой нативной интеграции. Чтобы контроллер мог сам создать ВМ и подключить диски, разработчик должен написать и протестировать драйвер под конкретное облако. Это недели исследований и разработки. А российский рынок сегодня – это десятки платформ, от банального OpenStack до суровых кастомных форков KVM и закрытых контуров.
Цифры против страхов: прагматичный подход к выбору
Выбор между автоматизацией и ручным трудом должен опираться на расчет рисков и стоимости простоя, а не на и��люзию, что «интеграция – это слишком сложно». Сложно – восстанавливать упавший прод руками в три часа ночи. Это как с той самой посудомойкой: после большого ужина гораздо приятнее доверить гору тарелок машине, чем стоять часами у раковины с губкой. Возможно, в вопросах миграции стоит придерживаться той же логики. Тем более, у ручного подхода есть свои риски и о них ниже:
Финансовые: за ресурсы «болванки» (CPU/RAM) вы платите с первой минуты потребления.
Человеческий фактор: ошибка в конфиге на старте всплывает только на финише.
Сложность масштабирования: в случае миграции большого количества виртуалок можно, конечно, скриптовать массовое поднятие машин, но это может стать узким горлышком
Отсутствие права на ошибку: помним, что точки восстановления в D2T не хранятся , если что-то пойдет не так, репликацию придется повторять с самого начала Равно как и в случае необходимости отката прода на исходную точку (failback) придется делать не автоматом, а заново поднимая вручную всех агентов.
Что выбрать? Чек-лист
Как понять, окупается ли настройка API-интеграции в вашем конкретном случае? Чтобы уйти от субъективных ощущений к фактам, я составила пошаговый алгоритм оценки проекта. Миграция не терпит сослагательного наклонения. Решение должно опираться на аудит текущей инфраструктуры и требования бизнеса, а не на страх перед сложностью настройки.
1. Оценка ландшафта миграции
Снимаем метрики не только по «железу», но и по бизнесу.
Объем: количество ВМ, приложений, баз данных, объема данных.
Критичность: RPO/RTO для каждого сервиса.
Окна простоя: согласованные окна обслуживания (когда и на сколько можно остановить прод).
2. Определение целевой платформы
Анализируем, куда едем.
Тип облака (Public/Private) и гипервизор.
Наличие открытого API и документации.
Совместимость вашего инструмента миграции (Migration Tool) с этой платформой «из коробки».
3. Экономика миграции (сравнение TCO)
Считаем честно два сценария.
API сценарий: стоимость лицензий ПО + время DevOps на настройку интеграции (если требуется интеграция с новой платформой).
Универсальный сценарий: ПО+ФОТ инженеров (часы на рутину) + OpEx за аренду «болванок» на всё время репликации + оценка финансовых рисков при простое/сбое.
4. Когда автоматизация безальтернативна?
Если вы ответили «ДА» хотя бы на один пункт из списка ниже — вам нужен API-метод (при условии его технической доступности):
Требуется регулярное перемещение между площадками , а не разовая акция. Например, мультиклауд подход.
Миграция уровня Enterprise (десятки и сотни ВМ).
Требуется консистентный перенос БД.
Миграция идет в зрелое публичное облако (там стабильный API, грех им не воспользоваться).
Стоимость часа простоя бизнеса превышает затраты на настройку автоматизации.
В итоге всё сводится к объему задач. Переносить вручную кластер на сотню виртуалок – долго, дорого и опасно. Инвестируйте время в настройку API-интеграции. Это тот случай, когда пару часов «на чтение мануалов» и настройку доступов сэкономят команде неделю бессонных ночей при переезд.
