Обычный кластер объединяет несколько серверов ради общего ресурса — вычислительной мощности, дискового пространства или распределения запросов. HA-кластер (High Availability, высокая доступность) решает другую задачу: он следит за состоянием узлов и при отказе одного из них автоматически перезапускает нагрузку на живом сервере. Разница не в количестве машин, а в наличии механизма контроля состояния, кворума и автоматического переключения. Проще говоря, обычный кластер масштабирует, HA-кластер — страхует.
Что именно добавляет приставка HA
В обычном кластере отказ узла означает, что часть сервисов просто пропадает: администратор узнаёт об этом из мониторинга и поднимает виртуальные машины вручную. В HA-кластере за это отвечает набор служб.
- Heartbeat — постоянный обмен сигналами между узлами по выделенной сети. Пропали сигналы — узел считается подозрительным.
- Кворум — правило большинства, которое не даёт двум половинам кластера одновременно объявить себя главной. Классический сценарий split-brain, когда обе части поднимают одни и те же ВМ и портят данные на общем хранилище, блокируется именно кворумом.
- Fencing / STONITH — принудительная изоляция или обесточивание сбойного узла через IPMI, чтобы он гарантированно не писал на диски.
- Общее хранилище — без него перезапуск ВМ на другом узле невозможен: диск должен быть виден всем участникам кластера.
Обычный кластер может обходиться без любого из этих элементов. HA-кластер без них — не HA, а иллюзия отказоустойчивости.
Как отличаются требования к инфраструктуре
Здесь и кроется главная причина, почему не все кластеры делают отказоустойчивыми: HA дороже и жёстче по требованиям.
Общее хранилище — обязательное условие. Обычно это SAN-массив по протоколам iSCSI или Fibre Channel либо распределённая файловая система вроде CephFS. Локальные диски узлов для HA не подходят: при падении сервера вместе с ним исчезает и диск виртуальной машины.
Второе требование — минимум три узла. На двух узлах кворум неполноценен, и приходится добавлять свидетеля (witness) или внешний арбитр. Третье — отдельная сеть под heartbeat, желательно продублированная, чтобы обрыв одного патч-корда не выглядел как отказ целого сервера.
Ключевое различие формулируется одной фразой: обычный кластер отвечает на вопрос «как обработать больше», HA-кластер — на вопрос «что произойдёт, когда узел умрёт». Это разные инженерные задачи, и решать их одними и теми же средствами не выйдет.
Живая миграция — это HA или нет
Частая путаница. Живая миграция (live migration) переносит работающую ВМ с одного узла на другой без остановки — но она плановая. Её используют перед обновлением прошивки или для разгрузки перегруженного хоста, часто в связке с автоматической балансировкой нагрузки. HA срабатывает в аварийном сценарии: узел уже недоступен, состояние памяти потеряно, ВМ поднимается заново с диска на общем хранилище.
На практике обе функции идут в комплекте. Например, в отечественных решениях класса платформа управления виртуальной инфраструктурой заявлены одновременно High Availability, живая миграция, автоматическая балансировка и поддержка аппаратных СХД — включая отказоустойчивые конфигурации Unbreakable cluster. Подробнее можно узнать на сайте разработчика.
Сравнение по ключевым параметрам
| Параметр | Обычный кластер | HA-кластер |
|---|---|---|
| Минимум узлов | 2 | 3 (либо 2 + арбитр) |
| Реакция на отказ узла | Ручная | Автоматический перезапуск ВМ |
| Общее хранилище | Не обязательно | Обязательно (iSCSI, Fibre Channel, SAN, CephFS) |
| Отдельная сеть heartbeat | Не требуется | Требуется, желательно с резервированием |
| Механизм fencing | Отсутствует | Обязателен |
| Потеря состояния ОЗУ при аварии | — | Да, ВМ стартует заново |
Значения по числу узлов — ориентир для типовых конфигураций; конкретный вендор может задавать свои минимумы.
Что делать, если HA не нужен, а доступность повысить хочется
Не каждой системе требуется полноценный HA-кластер с fencing и SAN. Иногда дешевле и надёжнее выстроить отказоустойчивость на уровне самого приложения: репликация СУБД с автоматическим переключением, несколько экземпляров сервиса за балансировщиком, микросервисная архитектура, где рост нагрузки на один компонент не роняет остальные. Такой подход не требует общего хранилища и переживает отказ целой площадки.
HA на уровне гипервизора выигрывает там, где приложение кластеризовать нельзя: устаревшее ПО, монолитная учётная система, инфраструктурные сервисы. Часто, но не всегда, оба уровня комбинируют: HA — для инфраструктурных ВМ, репликация — для баз данных. Отдельная область применения отказоустойчивых кластеров — VDI, где падение одного хоста иначе оставило бы без рабочих мест десятки сотрудников.
Частые вопросы
Сколько времени длится простой при срабатывании HA?
От момента фиксации отказа до готовности ВМ проходит время на подтверждение сбоя, fencing и загрузку гостевой ОС. Это не мгновенное переключение, а перезапуск — секунды на срабатывание плюс обычное время старта операционной системы и сервисов.
Можно ли собрать HA-кластер из двух серверов?
Технически да, но нужен третий арбитр (witness-узел или диск-свидетель) для кворума. Без него кластер из двух машин при обрыве связи рискует уйти в split-brain и повредить данные.
Теряются ли данные при аварийном переключении?
Данные на общем хранилище сохраняются, теряется содержимое оперативной памяти и несохранённые транзакции. Виртуальная машина стартует так, как будто ей выключили питание, поэтому файловым системам и СУБД нужен корректный журнал.
Подходит ли HA-кластер для импортозамещения?
Да, если платформа виртуализации внесена в единый реестр российских программ для ЭВМ и баз данных и работает с сертифицированной отечественной ОС — например, с Astra Linux. Это стандартное требование для государственных заказчиков и объектов КИИ.
Зачем HA, если есть резервные копии?
Бэкап восстанавливает данные, но не непрерывность работы: развёртывание из копии занимает от минут до часов. HA закрывает короткие аварии отдельных узлов, резервное копирование — потерю данных и логические ошибки. Это дополняющие друг друга механизмы, а не альтернативы.