ADG Оставить заявку
Блог Инфраструктура 5 мин чтения

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.

Что произошло:

  1. VirtualCenter зафиксировал отказ примерно через 15 секунд - heartbeat перестал приходить.
  2. Начал перезапуск виртуальных машин на втором хосте.
  3. Торговая система (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 один отказ - полторы минуты. Математика простая, а разговор с клиентом про «высокую доступность» стал значительно короче.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.