В этой статье мы подробно и на понятных инженерных метафорах разберем, почему разработчики сделали ставку на Event Storing вместо классического SQL и как микро-кворум на базе K3s обеспечивает отказоустойчивость управляющего центра «в лоб».
При проектировании любой отказоустойчивой ИТ-инфраструктуры самый критический узел — это сама панель управления (Control Plane), тот самый «вицентр», который координирует работу всех хостов, сетей и хранилищ. Если падает физический сервер с пользовательской виртуалкой — это локальная авария. Но если «сходит с ума» или теряет базу данных центральный сервер управления — парализует всю систему целиком.
Исторически индустрия привыкла полагаться на классические реляционные базы данных (SQL-like). vCenter от VMware, равно как и многие его open-source преемники, годами хранили конфигурации, состояния и логику кластера в реляционных таблицах.
Однако при создании нашей enterprise-платформы мы пошли принципиально иным путем, отказавшись от традиционного SQL в пользу архитектуры Event Storing и микро-кворумов под управлением K3s. Давайте разберем, зачем это было сделано и как это решает проблему отказоустойчивости «в лоб».
Проблема SQL в распределенных системах
Почему классические базы данных — не лучший выбор для динамического кластера виртуализации? В реляционной СУБД состояние системы фиксируется в виде «среза» данных в таблицах здесь и сейчас. Когда у вас 3 хоста — проблем нет. Когда хостов становится 30, а виртуальных машин — сотни, интенсивность изменений возрастает лавинообразно.
При попытке сделать управляющий центр распределенным (чтобы несколько инстансов админки работали одновременно), классическая база данных упирается в проблемы синхронизации реплик. Возникают задержки блокировок, риски рассинхронизации и тяжелые накладные расходы на поддержание целостности таблиц. Если в момент записи конфигурации моргнет сеть между репликами базы, администратор рискует получить «битую» базу данных, восстанавливать которую придется из ночных бэкапов.
Философия Event Storing: система как хроника событий
Вместо того чтобы хранить текущий статичный «снимок» настроек, база данных нашей платформы построена на принципе Event Storing (хранилище событий).
Система не перезаписывает строчки в таблицах. Вместо этого она ведет непрерывную, неизменяемую хронику абсолютно всех событий (логов изменений), происходящих в кластере: «добавлен диск», «изменен VLAN на порту», «виртуальная машина переехала на Хост-02».
Текущее состояние кластера в любой момент времени — это просто результат последовательного воспроизведения этой цепочки событий от начала и до конца. Что это дает архитектуре виртуализации?
1. Мгновенная и безопасная синхронизация. Новым инстансам панели управления не нужно скачивать тяжелые дампы таблиц и сверять строки. Им достаточно «дочитать» цепочку событий из общего лога до актуального момента.
2. Иммунитет к сбоям. Лог событий невозможно повредить незавершенной транзакцией. Если в процессе записи произошел сбой, поврежденное событие просто отбрасывается, а система остается в гарантированно стабильной предыдущей точке.
3. Уникальные фичи управления. Такая модель открывает дорогу к продвинутому аудиту изменений, мгновенным снимкам конфигураций и более гибкому управлению логическими сущностями.
Отказоустойчивость «в лоб» через K3s-кворум
Как эта база данных и сам управляющий центр выживают при физической гибели серверов? Механизм отказоустойчивости здесь реализован максимально прозрачно и эффективно.
Мы разделяем физические ресурсы кластера и логические инстансы панели управления. Представьте большой кластер, в котором работают, например, 15 физических хостов. Держать 15 одновременно работающих серверов управления избыточно — это бессмысленный расход процессорной мощности и оперативной памяти.
Администратор в интерфейсе платформы указывает, на каких узлах разрешено запускать виртуальные машины центрального сервера (Control Plane) — например, на всех трех базовых хостах. При этом система позволяет четко задать количество одновременно активных инстансов. Для небольшого или среднего кластера оптимальная цифра — 3 независимых инстанса.
Для управления этим микро-кластером внутри платформы развернут облегченный Kubernetes-кворум — K3s. Он выполняет роль строгого арбитра:
· Три инстанса панели управления живут своей жизнью внутри кластера, постоянно синхронизируя лог событий Event Storing с лидером кворума.
· Если один из физических хостов под управляющей виртуалкой внезапно «умирает» (выключили питание, сгорела сетевая карта), K3s-кворум мгновенно фиксирует потерю инстанса.
· Система автоматически отправляет команду на поднятие нового, четвертого инстанса на любом другом выжившем хосте кластера.
· Вновь поднятая управляющая машина за секунды считывает актуальный хвост событий Event Storing, синхронизируется с лидером, и стабильность панели управления полностью восстанавливается.
При этом для администратора, работающего в админке, этот процесс проходит практически бесшовно — службы продолжают функционировать, а бразды правления не теряются ни на секунду.
Итог
Отказ от тяжелого наследия классических SQL-баз данных в пользу связки Event Storing и легкого K3s-кворума позволил нам создать по-настоящему живучий Control Plane. Панель управления нашей платформы не боится внезапных обрывов связи, не требует ручной сборки развалившихся баз данных и автоматически регенерирует свои узлы при любых аппаратных катастрофах.
«Серый кардинал кластера: что делает служба HA Controller, когда падает Control Plane или ЦОД ловит Split-Brain»? Там мы заглянем еще глубже в инфраструктурные аварии. https://dzen.ru/a/aieXyxr4RiOJv-5f