Hyper-V R2 Live Migration без SAN: живая миграция на iSCSI-хранилище

Неделю назад мы впервые провели живую миграцию работающей виртуальной машины между двумя Hyper-V-хостами без единой секунды даунтайма. Сама по себе операция не сенсация - VMotion у VMware уже несколько лет. Сенсация в другом: сделали это на iSCSI-хранилище, без Fibre Channel SAN, и без лицензий на vSphere Enterprise.

Как это устроено в Hyper-V R2

Microsoft добавила Live Migration в Hyper-V R2 вместе с Windows Server 2008 R2, и построена она на двух механизмах: Failover Clustering и Cluster Shared Volumes (CSV). CSV - ключевое отличие от того, как это было в первой версии Hyper-V. Раньше один LUN мог принадлежать только одному узлу кластера; теперь CSV позволяет нескольким хостам одновременно читать и писать в один том. Именно это делает возможным «горячий» перенос VM: память копируется на целевой хост, пока исходный продолжает обслуживать VM, и в момент переключения диск уже виден обоим.

iSCSI здесь работает как общее хранилище - тот же смысл, что у Fibre Channel SAN, только дешевле в разы. Требования к сети у iSCSI в кластерной конфигурации есть: отдельный сегмент под хранилищный трафик, желательно выделенные сетевые карты. У нас это был гигабитный коммутатор, вынесенный в отдельный VLAN, - бюджетно, но достаточно.

Что и как настраивали

Клиент - небольшая производственная компания, на сопровождении уже год. Два физических сервера, оба под Windows Server 2008 R2 Datacenter, iSCSI-таргет на NAS-устройстве Synology. До R2 кластер использовался только для HA: при падении одного хоста VM перезапускалась на втором. Не живая миграция - холодная, с перезагрузкой VM и несколькими минутами недоступности.

Апгрейд до R2 открыл CSV. Процедура включения в нашем случае выглядела так:

• Обновление кластерных ролей - через Failover Cluster Manager, Add Disk to CSV. Том, который раньше был «просто» кластерным диском, переходит в режим Cluster Shared Volume.
• Настройка сети под Live Migration - в свойствах кластера указывается, какие сети можно использовать для миграционного трафика. Мы выделили отдельный интерфейс, чтобы не конкурировать с production-трафиком.
• Проверка через Validate - мастер валидации кластера проходится по всем компонентам; без чистого прохождения идти дальше не имеет смысла.

Само по себе это несколько часов работы, включая проверки и перезапуски. Ничего экстраординарного.

Первая миграция

Решили проверить в боевых условиях - не на тестовых VM, а на реальном файловом сервере клиента, который работает в рабочее время. Специально не предупреждали пользователей: хотели посмотреть, заметят ли.

Запустили переезд VM со второго хоста на первый через Failover Cluster Manager - правой кнопкой, «Move Virtual Machine». Процесс занял около двух минут: сначала копируется содержимое памяти, потом краткий момент переключения, потом VM продолжает работу уже на первом хосте.

Пользователи не заметили. Не «почти не заметили», а именно не заметили - никто не написал в поддержку, не перезвонил. Один коллега в это время держал открытое RDP-подключение к серверу - говорит, слегка притормозило на секунду, думал сеть. Файловые шары не отвалились, сессии не прервались.

Для сравнения: предыдущая схема с холодной миграцией давала 3-5 минут даунтайма, и каждый раз был звонок - «у нас сеть пропала».

Что стоит иметь в виду

CSV со своими особенностями: том монтируется через специальную точку в C:\ClusterStorage\, а не как обычный диск. Антивирусы иногда пытаются сканировать эти пути и создают проблемы - пришлось добавлять исключения. Дефрагментацию CSV Microsoft рекомендует отключать; собственная оптимизация у CSV есть, но она работает иначе.

Сеть - реально критичное место. Гигабит для iSCSI-хранилищного трафика плюс Live Migration - это совместный ресурс. При миграции «тяжёлой» VM с большим объёмом RAM трафик заметный. У клиента VM была небольшой, проблем не было; с многогигабайтными VM на одном интерфейсе могло бы быть веселее.

iSCSI-таргет на NAS - решение рабочее, но NAS должен поддерживать нормальные IOPS под несколько хостов одновременно. В нашем случае Synology справлялся, но нагрузка у клиента умеренная.

Почему это интересно именно сейчас

До R2 живая миграция на Hyper-V была недоступна в принципе - только холодная. Теперь она есть, и порог входа резко упал: Fibre Channel SAN с его стоимостью и сложностью инфраструктуры не обязателен. iSCSI - это коммутатор, NAS и прямые руки при настройке.

Для клиентов, у которых нет бюджета на Fibre Channel, но есть потребность в высокой доступности без перерывов - вариант стал реальным. Конкретно этот клиент теперь может планировать обслуживание хостов по очереди, не договариваясь с пользователями о «технологическом окне». Это практически.

Сравнивать с VMotion пока нет смысла: VMware в этом классе задач дольше, и инструментарий богаче. Но мы говорим о другом ценовом сегменте и другой точке входа. Посмотрим, как R2 будет себя вести под реальной нагрузкой несколько месяцев - тогда будут более предметные выводы.