vMotion по всей ферме: первая живая миграция на iSCSI-кластере

Несколько недель назад мы перевели один из физических хостов на ESXi и посмотрели, что бесплатная версия умеет и чего не умеет. Итог был умеренно оптимистичным. Но ESXi нам сейчас не нужен - нужен полноценный ESX с vMotion. VMware движется к vSphere 4, пресс-релизы идут один за другим, а нам хочется понять, готовы ли мы к тому, чтобы гонять виртуалки между хостами без остановки.

Собрали стенд из двух физических серверов с ESX 3.5. Задача - запустить vMotion так, чтобы виртуальная машина переехала с хоста А на хост Б, пока пинг к ней не прерывался.

Shared storage как обязательное условие

vMotion без общего хранилища не работает. Это не опция, это архитектурное требование: оба хоста должны видеть одни и те же диски виртуалки. Варианта было два - Fibre Channel или iSCSI. FC - это стойки, HBA-карты и отдельный бюджет. iSCSI - это то, что у нас уже есть: нормальная IP-сеть и свободный сервер с большими дисками.

Поставили на отдельный хост открытый iSCSI-таргет (Linux + iscsitarget), создали LUN, подключили его с обоих ESX-хостов через vmkernel-интерфейсы. Проверили через Storage Adapters - оба хоста видят одно и то же хранилище. Создали VMFS-том, закинули на него тестовую виртуалку.

Следующий шаг - VMkernel с vMotion. Нужно было создать отдельный VMkernel portgroup, включить на нём флаг «Used for vMotion» и убедиться, что между хостами нормальный маршрут по этим интерфейсам. Подводный камень: нельзя использовать тот же VMkernel, что для management-трафика. Это мы прочитали в доке после первой неудавшейся попытки.

Что происходит во время миграции

Когда нажимаешь Migrate - Migrate using VMotion в vCenter, он делает несколько вещей подряд:

• Копирует состояние памяти виртуалки на целевой хост итеративно, пока машина работает.
• Доводит дельту до минимума - страницы, которые менялись во время копирования, отправляются ещё раз.
• Переключает выполнение на целевой хост, обновляет MAC-запись в сети.

Весь процесс у нас занял около 30 секунд на небольшой машине с 1 ГБ оперативной памяти. Ping терялся на один-два ответа в момент финального переключения. Технически это не «без потерь» совсем, но для большинства сервисов это незаметно.

Более тяжёлая виртуалка с активной БД мигрировала дольше - память менялась быстрее, чем успевала копироваться, и vCenter несколько раз делал дополнительные итерации. Но перебоя в работе так и не случилось.

Где было неприятно

iSCSI и jumbo frames. Мы подняли iSCSI без включения jumbo frames (MTU 9000) - просто не сразу об этом подумали. Миграция работала, но пропускная способность была заметно ниже, чем могла бы. Пришлось лезть в конфиги свитча и на оба хоста, поднимать MTU на vmkernel-интерфейсах. Порядок важен: сначала свитч, потом хосты, иначе пакеты просто дропаются без внятных сообщений в логах.

Одна подсеть для всего. Первые попытки - management, vMotion и iSCSI висели на одном физическом адаптере и в одной сети. Это работало, но нагрузка во время миграции ощутимо давила на management-канал. Разнесли трафик по отдельным vSwitch-ам - сразу стало чище.

vCenter обязателен для vMotion. На ESXi без vCenter vMotion не работает вообще. На полном ESX без vCenter тоже ничего не будет. Это важное ограничение для тех, кто думает обойтись бесплатным ESXi: managed-инфраструктура с нормальным vMotion требует лицензии и vCenter Server.

Итог этого эксперимента

Работает. Живая миграция между хостами без остановки сервисов - реальность, а не маркетинг из брошюры. Shared storage через iSCSI достаточен, чтобы это поднять без FC-инфраструктуры.

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

Следим за vSphere 4. Судя по тому, что просачивается из бета-программы, там серьёзно переработана работа с сетью и хранилищами - посмотрим, что из этого окажется полезным в production.