Почему vMotion срывается на живой нагрузке
Живая миграция виртуальных машин выглядит как одна команда, но под ней — несколько параллельных потоков: копирование состояния памяти, перенос дисков, перенастройка сети и переключение на целевой хост. Пока они укладываются в отведённое окно, переезд проходит незаметно. Сбой переноса виртуальной машины начинается там, где хотя бы один поток не догоняет нагрузку.
Первая причина — рассинхрон данных. Память переносится постранично, и после старта синхронизации изменённые страницы копируются повторно, а затем ещё раз. Если приложение пишет быстрее, чем канал успевает передавать, раунд не закрывается: гипервизор перезапускает синхронизацию до предела, после чего откатывает перенос — машина остаётся на исходном хосте, а окно обслуживания уже сдвинулось.
Вторая — узкое место хранилища. Разные тома, типы разделов, размер блока и кэш дают непредсказуемую скорость: при Storage vMotion данные переливаются медленнее плана, а диски с прямым подключением перенести нельзя в принципе. Перегруженный канал между площадками добавляет своё — трафик миграции делит полосу с репликацией и резервным копированием, и расчётное время множится.
Третья — отсутствие запаса по ресурсам, из-за чего риск превращается в простой сервиса при переезде: без резерва процессора и памяти на целевом хосте, проверенной коммутации и плана отката любая заминка растягивается на часы. Разбираем, как это закрывается — от профиля нагрузки до прогона миграции на копии.
Что даёт перенос без остановки сервиса
Суть переноса без остановки сервиса в том, что работающая машина переезжает между хостами, не выключаясь: память копируется на целевой хост, изменённые страницы догоняются повторными проходами, а переключение занимает доли секунды. Соединения, попавшие в эту паузу, переподключаются по таймауту, а не рвутся ошибкой. Класс задач «выключить, перенести, включить» из плана обслуживания уходит.
Отсюда главный эффект — сокращение окна обслуживания. Обновление гипервизора, замена железа, перебалансировка нагрузки и перенос дисков между хранилищами идут на работающих системах: узел переводится в режим обслуживания, машины разъезжаются по кластеру, работы больше не требуют ночных простоев. Storage vMotion делает то же с дисками — том меняется под работающей системой, без отключения и повторной регистрации.
Снимается и класс отказов, связанных с ручным переключением. Когда перенос делают руками — остановка сервиса, отключение томов, повторное сканирование, регистрация на новом хосте, включение, правка записей балансировщика, — любая ошибка превращает плановое окно в аварию.
При живой миграции ошибиться негде: если перенос не сходится, машина остаётся на исходном хосте и продолжает обслуживать запросы. Фактическая пауза — доли секунды вместо десятков минут, а согласовывать ночные работы с бизнесом уже не нужно. Непрерывность сервиса проверяем на пилотной группе: замеряем реальную недоступность, смотрим поведение под нагрузкой и только потом переносим остальное.
Сравнение режимов: vMotion и Storage vMotion
Режим живой миграции выбирают по тому, что именно переезжает: вычислительный узел, хранилище или оба компонента сразу. В VMware vMotion работающая машина меняет хост, а её диски остаются на общем хранилище — простой измеряется секундами, а длительность зависит от связности между узлами, а не от объёма диска.
Storage vMotion решает обратную задачу: файлы виртуальной машины переезжают на другое хранилище, а сама она остаётся на текущем хосте. Время переноса здесь пропорционально объёму данных и пропускной способности между массивами.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| vMotion | Нужно снять нагрузку с узла, освободить его под обслуживание или выровнять баланс в кластере, хранилище остаётся прежним | Требуется общее хранилище, доступное обоим хостам, и совместимые наборы процессорных инструкций в границах кластера |
| Storage vMotion | Перенос хранилища виртуальных машин: смена массива, вывод старого оборудования, перекладка дисков на другой уровень | Нужны свободное место на целевом хранилище и запас пропускной способности; крупные снимки и диски в режиме прямой передачи данных удлиняют операцию |
| Оба режима подряд | Переезд на другой узел и другое хранилище одновременно, в том числе на другую площадку или в другой кластер | Самая длинная операция: требования по сети, совместимости и свободному месту складываются, нужен запас по нагрузке |
Перед выбором режима мы проверяем то, что чаще всего ломает перенос: снимки дисков, режим их подключения, типы хранилищ на обоих концах и совместимость процессоров. Это позволяет заранее отделить машины, которые переедут без остановки, от тех, что придётся переносить по отдельности.
Этапы переноса: от аудита до передачи
Порядок работ фиксирован: сначала факты, потом переключение. Этапы миграции инфраструктуры строятся так, чтобы каждый шаг давал проверяемый результат, а промежуточное состояние оставалось откатываемым — этим плановый перенос и отличается от аварийного.
- Аудит перед переносом. Инвентаризация машин, гостевых ОС, дисков, сетей и зависимостей между сервисами. Отдельно — совместимость с целевым кластером и профиль нагрузки на хранилище в часы пик: он задаёт допустимое окно работ.
- План переноса виртуальных машин. Размечаем, что уезжает живой миграцией vMotion без остановки сервиса, а что требует короткого простоя — смена формата диска, драйверов или контроллера. Фиксируем сетевые соответствия и порядок групп.
- Подготовка площадки. Хранилища, пулы, политики размещения, права, расписания репликации, резервные копии. Проверяем, хватает ли пропускной способности каналов на перелив дисков, а не только на само переключение.
- Пробный прогон. Переносим две-три копии из разных групп и снимаем контрольные замеры: время переключения, задержки ввода-вывода, загрузку хранилищ. По замерам уточняем схему и длину окна.
- Основная волна. Группы идут в заданном порядке, после каждой — проверка доступности сервисов, журналов и копий.
- Проверка после миграции. Сравниваем замеры с базовыми, источники держим выключенными, но готовыми к запуску: это и есть план отката.
- Передача. Доступы, схемы, регламент обслуживания и инструкция по возврату для дежурной смены.
Документы и схемы, которые остаются у вас
Миграция заканчивается не моментом переключения на другой хост, а комплектом документации по инфраструктуре, по которой её можно эксплуатировать и развивать без автора изменений. Ниже — то, что мы передаём вместе с доступами: список закрывает и повседневную работу, и следующую миграцию, и разбор сбоя.
- Карта зависимостей сервисов. Что с чем связано: обращения к базам, брокерам сообщений, файловым хранилищам, внешним системам. Собираем из конфигураций и сетевых журналов, а не по памяти администратора, — при переносе сразу видно, что нельзя выключать одновременно.
- Схема виртуальной инфраструктуры. Кластеры, хосты, хранилища, сегменты сети, точки отказа, запас по процессорам, памяти и дискам. По ней новый инженер разбирается в топологии за час, а не за неделю расспросов.
- Регламент переноса. Порядок миграции по шагам: что проверяем до переключения, какие показатели считаем признаком успеха, при каких условиях возвращаемся на исходный хост и сколько это занимает.
- Регламент восстановления. Целевое время и точка восстановления по каждому сервису, очерёдность подъёма, ответственные, критерий закрытия инцидента.
- Политики доступа. Роли, служебные учётные записи, права на уровне кластера, хранилища и гостевых систем, правила ротации секретов и порядок выдачи доступов новым сотрудникам.
- Инвентаризация и резервное копирование. Ресурсы каждой машины, расписание копий, места хранения, дата последней проверки восстановления из копии.
Когда новый подрядчик или ваш инженер открывает эти файлы, передача инфраструктуры не превращается в переписку с вопросами. Документы пишем под ваш контур — с реальными именами хостов, хранилищ и групп доступа, а перед сдачей проходим список вместе с командой и правим то, что осталось неочевидным.
Кейс: переезд кластера без остановки сервиса
Кластер из нескольких десятков виртуальных машин обслуживали вручную. Плановые переносы делали только в ночные окна: каждое — с остановкой сервиса на сорок-шестьдесят минут и дежурным инженером у монитора. В месяц набиралось шесть-восемь таких окон, а ошибка в порядке переноса оборачивалась тем, что часть машин поднималась с неверными сетевыми настройками и её приходилось чинить уже утром, на живых пользователях.
Что изменили
Обслуживание перевели на штатные средства VMware: работающие машины переносим между хостами на ходу через vMotion, дисковые тома мигрируем отдельно от вычислений — переезд перестал быть событием с остановкой. Порядок операций закрепили регламентом: сначала проверка совместимости на уровне процессорных наборов и драйверов, затем перенос вычислений, потом хранилища, и только после этого — вывод освободившихся хостов на обслуживание. Отдельно настроили правила распределения ресурсов, чтобы после переноса нагрузка не сваливалась на один хост.
Что стало
Ночные окна как отдельный процесс исчезли: рутинные работы идут в рабочие часы, число плановых простоев сократилось с шести-восьми в месяц до нуля, а освободившееся время дежурных ушло на развитие инфраструктуры. Время возврата к работе после сбоя хоста сократилось с нескольких часов ручного разбора до десятков минут — машины поднимаются на резервном узле по заранее прописанному сценарию. Миграция кластера теперь занимает один рабочий день вместо череды ночных смен, и сервис при этом ни разу не выключался.
Что делать, если vMotion не проходит на текущем хранилище
Чаще всего живая миграция отваливается не из-за сбоя гипервизора, а из-за отсутствия общей опорной точки между сторонами. Проверяют четыре вещи: видит ли одно хранилище оба кластера, совпадают ли типы томов, сведены ли возможности процессоров к общему набору, нет ли открытых снапшотов и проброшенных устройств. Любая из деталей блокирует перенос ещё до старта, а ошибка показывает лишь следствие.
Если хосты в одном кластере, а менять нужно носитель, а не вычислительный узел, это задача Storage vMotion: диски переезжают между хранилищами на ходу, без остановки гостевой системы. Ограничение одно — пропускная способность канала между массивами: при слабой полке переносы уходят в очередь и обрываются по таймауту.
Когда общей точки нет совсем — разные кластеры, площадки, отсутствие общего тома — обходятся без перестройки инфраструктуры. Хранилище-«мост», доступное обеим сторонам, позволяет переносить тома по частям: сначала базу, снятым снапшотом, затем дельту, а цепочку собирают уже на приёмнике. Число одновременных переносов ограничивают вручную, иначе канал репликации забивается.
Если и это не проходит, работает гостевой уровень: репликация средствами самой системы или холодный перенос — машину гасят, копируют тома, поднимают на новом месте. Холодный путь предсказуем и в часы пик оказывается быстрее, чем борьба с таймаутами.
На VMware и совместимых платформах мы сначала снимаем карту совместимости: кому какие тома видны, какие наборы инструкций совпадают, где узкое место канала. Так перенос укладывается в окно обслуживания без перестройки хранилища целиком.
Частые сомнения перед живой миграцией
Перед живой миграцией vMotion всплывает один и тот же набор сомнений: что будет с сервисом при обрыве переноса, придётся ли гасить машины, как поведут себя базы под нагрузкой. Ниже — разбор возражений, с которыми к нам приходят чаще всего, включая кластеры с общим хранилищем и давно не обновлявшиеся системы.
Что будет, если перенос оборвётся на середине?
Машина остаётся на исходном хосте: до завершения переноса состояние фиксируется точкой возврата, и при обрыве связи гостевые системы продолжают работать там, где работали. Возврат проверяем на тестовой группе до вывода остальных.
Обязательно ли гасить виртуальные машины?
Нет. При живой миграции память и состояние процессора переносятся на ход, а короткая недоступность возможна только в момент переключения. Её длительность мы измеряем заранее, а не обещаем на словах.
Как переносятся базы данных и кластеры?
Узлы переносим по одному, следя за кворумом и репликацией: кластер должен сохранять большинство голосов на каждом шаге. Базы с интенсивной записью переводим в щадящий режим синхронизации и переносим последними.
Что делать с устаревшими платформами?
Гостевые системы на старых ветках часто не поддерживают живой перенос — их обновляем или пересобираем заранее. Это удлиняет подготовку, но убирает класс отказов, который иначе всплыл бы во время работ.
Обсудим ваш сценарий переноса
Чтобы заказать перенос виртуальных машин, не нужен формальный документ — достаточно того, что уже есть у администраторов: выгрузки из инвентаря, схем сетей, переписки по окнам обслуживания. По этому набору мы собираем план волн и говорим, где переключение пройдёт без остановки сервиса, а где потребуется окно.
- Состав парка: количество машин, операционные системы, объём и тип дисков, снимки, шаблоны, машины с общими дисками кластера.
- Схема площадок: адресация, сегментация сетей, правила маршрутизации между контурами, доступность хранилищ с обеих сторон.
- Требования к доступности по каждому сервису: допустимая длительность простоя, часы, когда переключение запрещено, периоды пиковой нагрузки.
- Критичные сервисы и связи между машинами: что поднимается первым, что держит блокировки и общие тома, где порядок запуска жёсткий.
- Текущие настройки кластера и хранения: типы хранилищ, политики размещения, ограничения на число одновременных задач.
- Условия отката: до какого момента можно вернуться на исходную площадку и хватит ли там ресурсов, пока идёт миграция кластера.
Чего-то из списка может не быть — это нормально, часть данных снимаем сами на обследовании. Опишите задачу и пришлите то, что есть: вернёмся с оценкой, разбивкой на волны, точками проверки после каждой и сценариями отката. Так перенос инфраструктуры под ключ получает измеримые критерии приёмки, а не обещание «сделаем аккуратно». Обсудим миграцию на конкретных цифрах вашего парка.
