VMware HA на двух хостах: 90 секунд и SLA 99,9% перестаёт быть фантастикой
Настроили VMware HA на кластере из двух хостов у ретейлера. При симуляции падения первого хоста виртуальные машины поднялись на втором за 90 секунд - без дорогого физического кластеринга.
VMware HA и DRS становятся стандартными функциями VMware Infrastructure 3 в 2007 году
До VMware Infrastructure 3 разговор про SLA 99,9% для малого или среднего бизнеса заканчивался примерно одинаково: «нужен физический кластер». Microsoft Cluster Services, общий SCSI или Fibre Channel, shared storage, лицензии Windows Enterprise - и всё это ради двух серверов, которые держат одно приложение. Цена вопроса отбивала желание даже начинать разговор.
VMware vSphere меняет условия задачи. HA - High Availability - теперь стандартная функция, которая входит в лицензию без доплат и не требует никакой магии с shared SCSI или специальным ПО для кластеризации. Мы попробовали это в деле у клиента-ретейлера, которому надо было поднять доступность торговой системы без капитального вложения в железо.
Что такое VMware HA и как это работает
Идея простая, хотя реализация внутри нетривиальная. Несколько хостов ESX объединяются в кластер VMware HA. Каждый хост периодически шлёт «heartbeat» соседям через служебную сеть. Если хост перестаёт отвечать - vCenter Server (тогда ещё VirtualCenter) фиксирует отказ и запускает виртуальные машины с упавшего хоста на оставшихся. Никакой живой миграции, никакой непрерывности - просто перезапуск. Но перезапуск быстрый и автоматический.
Ключевое отличие от классического кластера в том, что HA работает на уровне хоста, а не приложения. Ему всё равно, что запущено внутри виртуальной машины. Windows, Linux, 1C, база данных - без разницы. Хост упал - VM перезапустилась на другом хосте.
Стенд и задача
У клиента - два физических сервера с ESX 3.5 и общее хранилище на iSCSI. Виртуальные машины: контроллер домена, файловый сервер, торговая система на SQL Server. Критичнее всего - торговля: магазин без неё встаёт полностью.
Задача - убедиться, что при отказе одного хоста торговая система поднимется на втором без ручного вмешательства, и уложиться в разумное время восстановления.
Настройка кластера HA заняла полдня. Основные шаги:
- Объединить хосты в датацентр в VirtualCenter. Без VirtualCenter HA не работает - это менеджмент-слой, который координирует всё.
- Создать кластер HA и добавить оба хоста. В мастере кластера включается HA, задаётся политика реакции на отказ.
- Настроить admission control. Это ключевой момент: VMware не позволит включить на хостах больше VM, чем второй хост сможет поднять в случае отказа первого. Для двух хостов - резервируется 50% ресурсов на каждом.
- Выделить heartbeat-сеть. Отдельный интерфейс или VLAN для служебного трафика HA, чтобы потеря продуктивной сети не выглядела как отказ хоста.
Отдельный момент - общее хранилище на SAN. HA перезапускает VM, но сами диски виртуальных машин должны быть доступны обоим хостам. Наш multipath к iSCSI пришёлся кстати: оба хоста видят одни и те же LUN'ы.
Тест на падение
Симулировали жёсткий отказ хоста: просто выдернули питание из первого сервера без предупреждения. Никакого graceful shutdown, никаких сигналов VMware.
Что произошло:
- VirtualCenter зафиксировал отказ примерно через 15 секунд - heartbeat перестал приходить.
- Начал перезапуск виртуальных машин на втором хосте.
- Торговая система (SQL Server + приложение) поднялась и стала доступна через 90 секунд после выдёргивания питания.
Девяносто секунд - это не живая миграция VMotion, не нулевой даунтайм. Пользователи увидят разрыв соединения и скорее всего сообщение об ошибке. Но через полторы минуты система снова работает, кассы снова бьют чеки, и никто не звонит администратору с просьбой «приехать и посмотреть».
До HA сценарий выглядел иначе: сервер упал, дежурный получил алерт, разобрался что случилось, перезапустил VM руками - в лучшем случае 20-30 минут, если был на связи. В худшем - несколько часов.
Что HA не делает
Стоит честно обозначить границы. HA спасает от отказа физического хоста - но не от ошибок внутри виртуальной машины. Если Windows BSoD'нулся, SQL Server завис, приложение упало - HA не реагирует. Это уже задача мониторинга и, отдельно, VMware Fault Tolerance (которая пока только анонсирована для следующих версий и на два хоста не подходит).
Admission control в конфигурации «два хоста, резервирование 50%» означает, что суммарная нагрузка на кластер не должна превышать половины ресурсов одного хоста - иначе после отказа второй хост просто не потянет. Это реальное ограничение: нельзя набить оба хоста виртуальными машинами под завязку и надеяться на HA.
И ещё одно: перезапуск VM при отказе хоста - это холодный старт. Для приложений, которые не умеют корректно стартовать после аварийного завершения (незакрытые транзакции, залоченные файлы), могут быть нюансы. С торговой системой клиента проблем не было, но проверять это нужно заранее.
Итог
Сопровождение серверной инфраструктуры теперь включает стандартный чеклист для клиентов с ESX: если есть хотя бы два хоста и общее хранилище - настраиваем HA по умолчанию. Цена - несколько часов работы и лицензия VI3 Standard, которая у клиентов обычно уже есть.
SLA 99,9% - это примерно 8,7 часов простоя в год. При ручном восстановлении после отказа хоста одна авария может выбрать весь этот бюджет. С HA один отказ - полторы минуты. Математика простая, а разговор с клиентом про «высокую доступность» стал значительно короче.
- VMware ESXi 3.5 бесплатно: bare-metal без Service Console · 16 января 2007
- SAN с двумя контроллерами: multipath, ALUA и тест выдёргиванием питания · 15 марта 2007