Кластер виртуализации и гиперконвергенция: как устроены управление, кворум и отказоустойчивость

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

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

Из чего состоит кластер виртуализации

Зрелый кластер виртуализации — это несколько слоёв, и гипервизор лишь один из них:

• Гипервизор — KVM/QEMU с доработками команды: то, что непосредственно запускает виртуальные машины.
• Центральный сервер (оркестратор) — управляющий слой: интерфейс администратора, API и все команды к серверам. В Inscale он работает в нескольких служебных виртуальных машинах на разных серверах.
• Host-контроллер — службы на каждом сервере, отвечающие за низкоуровневую работу с виртуализацией: запуск машин, диски, сеть, диагностика.
• Сеть — распределённый коммутатор, uplink-интерфейсы и группы портов с VLAN, которыми управляет платформа.
• Хранилища — внешние системы хранения, подключённые по NFS, iSCSI или Fibre Channel.
• Сервисные модули — балансировка, мониторинг, резервное копирование, разграничение доступа, диагностика.

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

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

Отказоустойчивость кластера — не одно свойство, а четыре независимых механизма, и у каждого свой сценарий отказа и восстановления:

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

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

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

Перезапуск пользовательских машин при отказе сервера — отдельный механизм (HA). Как он работает, какие три условия для него нужны и как обрабатывается Split-Brain, разобрано в статье «Отказоустойчивость виртуальных машин: как работает HA-кластер». Здесь сосредоточимся на отказоустойчивости самого управления.

Кворум: сколько отказов переживёт управление

На российском рынке отказоустойчивость управления чаще всего реализована как репликация «1+1» (active-standby) — основной узел и резервный — либо как одиночный узел. Часть вендоров перекладывает устойчивость базы данных управления на заказчика: настрой топологию репликации сам. Такие конструкции тяжело эксплуатировать и расширять.

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

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

Если кворум всё же потерян, управление восстанавливают по отдельной процедуре — из резервной копии конфигурации. На пилоте её стоит пройти заранее.

Event sourcing: что даёт история событий

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

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

Содержимое дисков и памяти виртуальных машин история событий не восстанавливает — за это отвечает резервное копирование.

Консистентность и кластер на нескольких площадках

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

Центральный сервер Inscale можно распределить между несколькими площадками. Здесь стоит сразу разделить два сценария: полную потерю площадки и разрыв связи между площадками при работающем оборудовании. В обоих случаях должно быть понятно, какая часть системы продолжает принимать изменения и как после восстановления связи возвращается согласованное состояние; для схемы с большинством голосов отдельно рассчитывают размещение голосующих участников. В программу пилота для такого кластера включают задержку и потери пакетов, отказ каждой площадки и переподключение пользователей.

Почему платформы «валятся» при масштабировании

Частая история: на 100 виртуальных машин или рабочих мест всё работает прекрасно, но стоит начать масштабироваться вверх — и платформа начинает сыпаться. Почему так?

Ответ — в архитектуре. В Inscale ставка сделана на микросервисную архитектуру и микросегментацию задач. Любое изменение состояния инфраструктуры (переход из состояния A в состояние B) разбивается не на линейную цепочку, а на дерево микрозадач: часть из них может выполняться одновременно, поэтому это именно дерево (а с учётом зависимостей — граф). Причём это дерево не предопределяется заранее, а генерируется под конкретную задачу.

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

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

Гиперконвергенция и программно-определяемое хранилище

Гиперконвергенция — это подход, при котором вычисления и хранение объединяются на одних и тех же серверах под управлением софта, без отдельной системы хранения. Ключевой компонент здесь — программно-определяемое хранилище (SDS).

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

Сегодня Inscale работает с внешними хранилищами: они подключаются по NFS, iSCSI и Fibre Channel. Собственное программно-определяемое хранилище — в разработке. Начать работу можно и без общего хранилища, на одном сервере с локальными дисками, но перезапуск машин на другом сервере при отказе требует общего хранилища.

Что ещё нужно кластеру: хранилище, сеть, обновления

• Общее хранилище. NFS v3/v4, iSCSI или Fibre Channel. Для iSCSI используется кластерная файловая система OCFS2; число подключаемых узлов задаётся при создании хранилища — с запасом под рост кластера.
• Сеть. Не менее двух сетевых интерфейсов на сервере. Сети управления, хранения и пользовательского трафика разделяют, для хранения — по возможности физически.
• Обновления. Идут по шагам — подготовка, установка пакетов, проверка переключения, переход на новую версию — по выбранным серверам или массовой задачей. При проблеме задача ставится на паузу и показывает узел, который требует внимания.
• Наблюдение. Мониторинг кластера и ресурсов — в консоли платформы; метрики можно передавать в Zabbix, Prometheus и Grafana.

Что кластер виртуализации даёт бизнесу

Если свести к практике, грамотно спроектированный кластер виртуализации даёт:

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

Разобраться, из чего ещё состоит зрелая платформа и как её выбирать, поможет наш разбор российской системы виртуализации, а про требования регулятора — материал про приказ ФСТЭК № 117.