Когда виртуализацию изучают всерьёз, первый «взрослый» вопрос всегда один: что произойдёт с виртуальными машинами, если упадёт сервер? Распространяется ли отказоустойчивость на пользовательские машины — или только на сам центр управления? Вопрос точный, и ответ на него отличает зрелую платформу от набора скриптов поверх гипервизора.
Что такое отказоустойчивость виртуальных машин
Отказоустойчивость (High Availability, HA) — это свойство инфраструктуры, при котором выход из строя одного физического сервера не останавливает работу виртуальных машин. Машины с упавшего узла автоматически перезапускаются на оставшихся живых хостах. Перезапуск означает перерыв: ВМ загружается заново, активные сессии и несохранённые данные теряются, пользователи подключаются заново. Время восстановления зависит от конфигурации, загрузки ОС и приложений.
Ключевое слово здесь — автоматически. Отказоустойчивость измеряется не наличием резервного сервера, а тем, насколько быстро и без участия человека система переживает аварию. И вот здесь у разных платформ всё устроено по-разному.
Для полноценной защиты нужны минимум три сервера — так работает кворум, — общее хранилище и запас ресурсов на оставшихся узлах, чтобы принять машины отказавшего. Начать можно и с одного узла с локальными дисками, но это стенд, а не отказоустойчивая инфраструктура.
Служба, которая держит машины живыми
В AirCloud за живучесть отвечает отдельная служба — контроллер отказоустойчивости. В команде её в шутку называют «серым кардиналом»: она не на виду, но именно она принимает решения в момент аварии.
> Это сервис, который живёт на уровне гипервизора. В случае аварии, пока недоступен основной орган управления, он берёт на себя запуск виртуальных машин, их работу и подключение к ним — чтобы система продолжала функционировать.
>
> — команда разработки AirCloud
Принципиальный момент: контроллер работает на уровне гипервизора, а не в слое управления. Поэтому отказоустойчивость распространяется на обычные пользовательские машины, а не только на управляющую. Даже если центральный сервер временно недоступен, виртуальные машины продолжают запускаться и обслуживаться — за это отвечает независимая служба ближе к железу.
Split-brain: самый коварный сценарий
Худший случай — это не падение узла, а split-brain: ситуация, когда хосты теряют сетевую связь друг с другом, но при этом все живы и подключены к общей системе хранения. Без правильной обработки два узла могут одновременно решить, что они «главные», и запустить одну и ту же машину дважды — с гарантированным повреждением данных на общем хранилище.
Контроллер AirCloud рассчитан именно на этот сценарий: ВМ перезапускается только на стороне, сохранившей кворум, а изолированный узел права запускать её не получает — за это отвечают кворум и fencing, исключая конфликт за общий диск. Отказоустойчивость — это про дисциплину принятия решений, а не про дублирование серверов.
Как восстанавливается сам слой управления
Отдельный вопрос — что происходит с центром управления после аварии. В AirCloud восстановление держится на архитектуре Event Sourcing: состояние управляющего слоя восстанавливается из журнала событий; когда узлы возвращаются и кворум восстановлен, они синхронизируются автоматически — без ручной сборки развалившихся баз данных.
Это снимает классическую боль администратора: после аварии не нужно вручную «склеивать» рассинхронизированные базы и поднимать управление по инструкции на тридцать страниц. Система пересобирает себя сама. Как устроена отказоустойчивость класса N на уровне всего управляющего слоя — в статье про кластер виртуализации.
Что бывает с обновлениями
Ещё один источник простоев — само обновление платформы. В AirCloud обновление идёт многоэтапно, по серверам, с проверкой на каждом шаге. Если шаг не прошёл — обновление узла откатывается к предыдущей версии; процедура и ограничения отката описаны в документации.
Отказоустойчивость и катастрофоустойчивость — не одно и то же
Важно не путать два уровня защиты:
- Отказоустойчивость (HA) — защита внутри одной площадки: упал узел — машины перезапустились на соседнем. Это то, что обеспечивает контроллер.
- Катастрофоустойчивость (DR) — защита от потери всей площадки: репликация хранилища на резервный дата-центр в другом городе — средствами СХД или платформы, что определяется при проектировании, — и растянутая единая сеть. У AirCloud есть опыт растянутых инсталляций на два дата-центра.
Зрелая платформа закрывает оба уровня. И ни один из них не отменяет резервное копирование: отказоустойчивость спасает от падения железа, но не от удалённого по ошибке файла или шифровальщика.
Отказоустойчивость и живая миграция
Их тоже часто смешивают. Отказоустойчивость — это аварийный автоматический перезапуск при внезапном отказе. Живая миграция — плановый перенос работающей машины, когда администратор сам решает, когда и куда. Разные задачи, разные механизмы.
Что это даёт бизнесу
Для бизнеса отказоустойчивость — прямая экономия: час простоя критичного сервиса часто стоит дороже, чем вся лицензия на платформу за год. Проверять её стоит не по слайдам, а руками: вывести узел из строя на стенде и увидеть, как машины перезапускаются на других узлах, как обрабатывается split-brain и как узлы синхронизируются после восстановления кворума.
Из чего вообще складывается такая платформа — в разборе системы виртуализации. Если для вас критичен непрерывный сервис — напишите нам: покажем на живом стенде, как платформа ведёт себя при отказе узла.