Отказоустойчивость виртуальных машин: как работает HA-кластер в российской платформе

Когда виртуализацию изучают всерьёз — например, на лабораторных в вузе — первый «взрослый» вопрос всегда один: что произойдёт с виртуальными машинами, если упадёт сервер? Именно это спросили преподаватели кафедры защищённых систем связи СПбГУТ им. Бонч-Бруевича на нашей рабочей встрече: распространяется ли отказоустойчивость на пользовательские ВМ, а не только на сам центр управления. Вопрос точный — и ответ на него отличает зрелую платформу от набора скриптов поверх гипервизора.

Что такое отказоустойчивый кластер

Отказоустойчивый кластер (High Availability, HA) — это группа серверов-узлов, объединённых так, что отказ одного из них не приводит к долгому простою виртуальных машин. При отказе узла HA автоматически перезапускает его виртуальные машины на доступных узлах. Для самих машин это перерыв в работе: активные сессии прерываются, пользователи подключаются заново после загрузки гостевой ОС. Время восстановления зависит от конфигурации и загрузки ОС.

Ключевое слово здесь — автоматически. Отказоустойчивость измеряется не наличием резервного сервера, а тем, насколько предсказуемо и без участия человека система переживает аварию. И вот здесь у разных платформ всё устроено по-разному.

Что происходит с виртуальными машинами при отказе сервера

В Inscale режим HA включается при настройке кластера и распространяется на обычные пользовательские виртуальные машины, а не только на управляющие. При отказе сервера платформа автоматически перезапускает защищённые машины на доступных узлах. Восстановление каждой машины состоит из нескольких шагов: обнаружение отказа, безопасное переключение, повторная загрузка гостевой ОС и запуск приложений.

Машины на уцелевших серверах продолжают работать. Они продолжают работать и тогда, когда временно недоступно само управление, — но для новых подключений пользователей и операций администратора управляющие сервисы должны быть доступны. Поэтому управление в Inscale тоже распределено между несколькими серверами — об этом ниже.

Если сервис должен оставаться доступным даже на время перезапуска, его экземпляры размещают в разных виртуальных машинах на независимых серверах, а репликацию и переключение настраивают на уровне приложения.

Три условия автоматического перезапуска ВМ

Чтобы перезапуск сработал, должны выполняться три условия.

1. Доступность дисков. Узел, на котором машина запустится заново, должен видеть её актуальные диски. Это даёт общее хранилище; машину на одиночном локальном диске перезапустить на другом сервере нельзя.
2. Запас ресурсов. После потери любого одного сервера оставшимся должно хватить процессора, памяти и производительности хранилища. Для одинаковых серверов обычно закладывают N+1; для разнородных проверяют размещение после отказа каждого узла. В VDI отдельно считают утренний «шторм входов», когда к рабочей нагрузке добавляется одновременная загрузка машин потерянного хоста.
3. Защита от двойного запуска. Перед аварийным запуском платформа должна убедиться, что прежний экземпляр остановлен или отрезан от общих дисков, — за это отвечает механизм изоляции (fencing).

Split-Brain: самый коварный сценарий

Худший случай в кластере — это не падение узла, а Split-Brain: ситуация, когда хосты теряют сетевую связь друг с другом, но при этом все живы и подключены к общей системе хранения. Без правильной обработки два узла могут одновременно решить, что они «главные», и запустить одну и ту же ВМ дважды — с повреждением данных на общем хранилище.

Защиту от одновременного запуска машины на двух серверах обеспечивают кворум и механизм изоляции (fencing): прежде чем запустить машину заново, платформа должна убедиться, что прежний экземпляр остановлен или отрезан от общих дисков. Это третье из условий выше, и на пилоте его проверяют отдельно: сервер оставляют работающим, отключают ему сеть управления и смотрят, что происходит с его машинами.

Для учебной среды это отличная иллюстрация того, почему отказоустойчивость — это про дисциплину принятия решений, а не про дублирование серверов.

Как восстанавливается сам слой управления

Отдельный вопрос — что происходит с центром управления. В Inscale управление распределено между служебными виртуальными машинами центрального сервера, которые размещаются на разных физических серверах; для распределённого управления нужно не менее трёх серверов. При кворуме по большинству голосов управление сохраняет работу при потере одного экземпляра из трёх или двух из пяти. Серверов-кандидатов можно выбрать больше, чем работает экземпляров: тогда при отказе сервера замена запускается на другом выбранном узле, и полный состав восстанавливается без участия администратора.

Управляющий слой хранит историю событий: по ней восстанавливается состояние управления, ведётся аудит изменений, а незавершённая операция возвращается к исходному состоянию. Содержимое дисков и памяти виртуальных машин так не восстанавливается — его защищает резервное копирование.

Подробно про устройство кластера целиком — в статье «Кластер виртуализации и гиперконвергенция».

Отказоустойчивость и катастрофоустойчивость — не одно и то же

Важно не путать два уровня защиты:

• Отказоустойчивость (HA) — защита внутри одной площадки: отказал узел — его виртуальные машины перезапускаются на соседних.
• Катастрофоустойчивость (DR) — защита от потери всей площадки: резервный ЦОД, репликация или восстановление из резервных копий.

Это разные задачи и разные механизмы, и проектируют их отдельно. О том, из каких компонентов вообще складывается такая платформа, мы подробно рассказали в разборе российской системы виртуализации, а про ядро, на котором всё это работает, — в статье про российский гипервизор на базе KVM.

Как проверить отказоустойчивость на пилоте

Программу испытаний согласуют до старта: для каждого отказа задают ожидаемый результат и время восстановления, а измеряют готовность приложения или рабочего места, а не факт «машина запущена». Минимальный набор проверок:

• отказ хоста по питанию — перезапуск машин и время до готовности рабочих мест;
• изоляция хоста — отключение сети управления при работающем сервере, проверка защиты от двойного запуска;
• отказ управляющего экземпляра и его узла — кворум, консоль, новые подключения;
• потеря пути к хранилищу, затем полная недоступность хранилища;
• отказ сетевого интерфейса и коммутатора;
• обновление платформы под рабочей нагрузкой;
• отказ хоста в момент массового входа пользователей.

Пилот должен повторять целевую архитектуру: приёмку трёхузловой схемы проводят на трёх серверах, а не на двух.

Почему это важно для бизнеса и для учёбы

Для бизнеса отказоустойчивый кластер — это прямая экономия: час простоя критичного сервиса часто стоит дороже, чем вся лицензия на платформу за год. Для вуза — это лучший учебный полигон: студенту полезно своими руками «убить» узел и увидеть, как виртуальные машины перезапускаются на других узлах, как срабатывает защита от двойного запуска и как управление сохраняет кворум.

Именно поэтому мы бесплатно даём вузам платформу для практики: отказоустойчивость нельзя понять по слайдам — её нужно ломать и чинить руками.

Если вы выбираете платформу виртуализации и для вас критичен непрерывный сервис — напишите нам: покажем на демо-стенде, как ведёт себя HA-кластер при отказе узла.