Hyper-V R2: Live Migration без SAN оказался маркетингом для кластера

Microsoft выпустила бету Windows Server 2008 R2 с Hyper-V R2 на борту. Главная заявленная фича - Live Migration, то есть перенос работающей виртуальной машины между хостами без остановки. До этого в первом Hyper-V миграция только через Quick Migration: машину останавливают, сохраняют состояние, переносят, запускают. Несколько минут простоя - норма.

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

Что такое Live Migration в R2

Механика, если коротко: Hyper-V R2 итеративно копирует страницы памяти работающей виртуалки на целевой хост, пока машина продолжает работать. Когда дельта становится достаточно маленькой, делается финальное переключение - виртуалка переезжает. Пинг прерывается на долю секунды. Это принципиально другое по сравнению с Quick Migration.

Похоже на то, что VMware делает через vMotion, который мы тестировали месяц назад. Логика та же.

Что нужно для работы

Вот здесь начинается главная неприятность.

Live Migration в Hyper-V R2 требует:

• Failover Cluster - оба хоста должны быть узлами Windows-кластера. Без кластера Live Migration не работает вообще, нет никакого standalone-режима.
• Общее хранилище - виртуальные диски должны лежать на ресурсе, который видят оба хоста. SAN через Fibre Channel или iSCSI-таргет.
• Одинаковый процессорный vendor - Intel-to-Intel или AMD-to-AMD, иначе кластер не даст мигрировать из-за несовместимости инструкций.

Требования к сети тоже есть: минимум один выделенный адаптер под live migration трафик рекомендуется вынести отдельно, иначе во время миграции он давит на основной канал.

Как это выглядит на практике

На стенде подняли два хоста с Windows Server 2008 R2 Beta, развернули Failover Cluster, подключили iSCSI-хранилище через программный инициатор. Виртуалка на общем хранилище - Hyper-V Manager показывает опцию Live Migrate.

Сам процесс работает. Запустили тестовую машину с Windows 2003, начали непрерывный пинг с третьей машины - переезд прошёл без потери пакетов. Ровно как написано в документации.

Тяжёлую машину с базой данных гнать не стали - бета всё-таки. Но механика работает.

Где упирается небольшой клиент

Кластер из двух хостов с общим iSCSI-хранилищем - это не дёшево. Проблема не в лицензиях Hyper-V (он включён в Windows Server, это плюс), а в железе.

Для iSCSI нужно выделенное хранилище: либо железный iSCSI-таргет приличного уровня, либо отдельный сервер под хранение с нормальными дисками и RAID-контроллером. Бюджетный вариант на старом железе риски только множит - хранилище становится единой точкой отказа, и если оно падает, падает весь кластер.

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

У VMware та же история с vMotion: без лицензии и vCenter он недоступен, а для кластера нужно shared storage. Принципиального отличия в требованиях нет. Разница в том, что экосистема VMware богаче по инструментам - Hyper-V R2 пока только догоняет.

Что изменилось по сравнению с первым Hyper-V

Несколько минут неизбежного простоя при Quick Migration исчезли. Для клиентов, у которых уже есть кластерная инфраструктура и общее хранилище, это ощутимое улучшение: обслуживание хостов, балансировка нагрузки, эвакуация при проблемах - всё это можно делать без окна обслуживания.

Hyper-V R2 также задекларировал поддержку виртуалок с несколькими vCPU - до 4 на машину в этой версии. В первом Hyper-V максимум был один процессор, и это серьёзно ограничивало виртуализацию нагрузок типа 1С или SQL Server. Проверим в деталях, когда будет финальный релиз.

Итог

Live Migration в Hyper-V R2 - не маркетинг в том смысле, что он реально работает. Маркетинг в том, что заголовки читаются как «Live Migration без общего хранилища», а мелким шрифтом написано «нет, с общим хранилищем, просто без FC, можно iSCSI». Это разные вещи.

Для клиентов с нормальной кластерной инфраструктурой - хорошая новость. Для небольшого клиента с двумя серверами и без бюджета на SAN - ничего принципиально не изменилось. Инфраструктура, которую мы ведём в рамках managed-сопровождения, у большинства таких клиентов пока будет работать на Quick Migration или на одном хосте без миграции вообще.

Финальный релиз Server 2008 R2 ждём осенью - посмотрим, что изменится за это время в документации и ограничениях.