Кластер виртуализации — это не «несколько серверов с гипервизором», а целая экосистема сервисов, которая держит инфраструктуру на ногах, даже когда часть из них выходит из строя. Когда говорят «виртуализация», за этим словом стоят программно-определяемые сети (SDN), программно-определяемое хранилище (SDS), оркестрация, отказоустойчивость, контроллер кластера, диагностика и мониторинг, безопасность и изоляция. В платформе Inscale таких сервисов уже шестнадцать. Ядро KVM в этой картине — важнейший «кирпичик» и фундамент, но именно обвязка вокруг него превращает набор серверов в надёжный кластер.
В этом материале — как устроен кластер виртуализации на уровне архитектуры: из каких слоёв он состоит, что такое отказоустойчивость класса N (и чем она лучше привычной схемы «1+1»), как event sourcing позволяет откатить инфраструктуру в любое прошлое состояние и почему многие платформы «валятся» при росте нагрузки. Если нужен общий обзор платформы — он в разборе российской системы виртуализации.
Из чего состоит кластер виртуализации
Зрелый кластер виртуализации — это несколько слоёв, и гипервизор лишь один из них:
- Гипервизор (ядро KVM) — то, что непосредственно запускает виртуальные машины. Его задача — не мешать и стабильно держать фундамент.
- Оркестратор (Control Plane) — управляющий слой, аналог «v-центра»: и интерфейс администратора, и взаимодействие с гипервизорами. В терминологии Inscale это внутренний host-контроллер.
- Контроллер кластера — отдельный слой живучести, рассчитанный на работу даже при отказе оркестратора (об этом ниже).
- Программно-определяемые сети (SDN) и программно-определяемое хранилище (SDS) — сеть и диски, управляемые софтом, а не привязанные к железу.
- Сервисные модули — диагностика, мониторинг, безопасность, изоляция и ещё около десятка служб.
Именно поэтому виртуализацию правильнее называть экосистемным продуктом: надёжность кластера определяется не «голым» гипервизором, а тем, как спроектированы управляющий слой и отказоустойчивость.
Контроллер кластера и уровни живучести
Обычно весь управляющий слой аккумулирует оркестратор — но что произойдёт, если упадёт он сам? В Inscale за живучесть отвечает отдельная служба (High Availability Cluster Controller), работающая на уровне гипервизора: пользовательские виртуальные машины продолжают обслуживаться, даже когда центр управления временно недоступен.
Как именно контроллер обрабатывает отказ узла и коварный сценарий Split-Brain, подробно разобрано в отдельной статье — «Отказоустойчивость виртуальных машин: как работает HA-кластер». Здесь же сосредоточимся на другом уровне — отказоустойчивости самого кластера управления, и на том, что отличает архитектуру зрелого кластера.
Отказоустойчивость класса N, а не «1+1»
На российском рынке отказоустойчивость чаще всего реализована как репликация «1+1» (active-standby) — есть основной узел и резервный — либо вовсе как одиночный узел. Часть вендоров и вовсе перекладывает устойчивость базы данных на заказчика: настрой, мол, топологию репликации сам. На практике такие конструкции (например, на голом PostgreSQL) тяжело эксплуатировать и почти невозможно спокойно расширять.
Платформа Inscale изначально проектировалась под отказоустойчивость класса N. Это значит, что для отказа кластера управления и оркестратора должно выйти из строя сразу несколько узлов:
- если связь между узлами идёт только по сети — нужно потерять N/2 узлов (с округлением вниз);
- если есть дополнительный канал кворума — N−1.
Пока жив хотя бы один узел, кластер можно восстановить из его самых актуальных персистентных данных. Это принципиально надёжнее схемы «1+1», где потеря двух узлов уже означает простой.
Event sourcing: откат в любое прошлое состояние
Любое персистентное хранилище — то, где собираются все произошедшие с системой события — сделано в формате event sourcing. Это современный подход для инфраструктурных решений: про каждый ресурс, например виртуальную машину, известна вся цепочка событий — что и когда с ним происходило.
Практическая польза — возможность откатиться в любое состояние в прошлом. Если какая-то операция в инфраструктуре не достигла желаемого конечного состояния — даже если причина в ошибке настройки заказчика или в ошибке в коде самой платформы — система возвращается в исходное состояние. По словам инженеров Inscale, это уже не раз спасало на реальных инсталляциях: и там, где не было «защиты от дурака», и там, где ошибку допустила сама команда.
Про каждую виртуальную машину мы знаем целую цепочку событий и можем откатиться в любое состояние в прошлом. Даже если причина — наша ошибка в коде, система вернётся в исходное состояние. Это много раз нас спасало.
Консистентность и геораспределённый кластер
Чтобы отказоустойчивость класса N работала, все узлы кластера управления хранят события консистентно, синхронизируя их максимально экономно — минимально нагружая сеть и минимально завися от задержек. Полностью зависимость от сети убрать нельзя, но её удаётся существенно нивелировать. В результате «сломать» такой кластер целиком — нетривиальная задача.
Более того, кластер может работать геораспределённо. У Inscale был реальный опыт инсталляции с географически разнесёнными узлами в разных городах одновременно — и это работало. Для критичной инфраструктуры это означает, что выход из строя целой площадки не обязательно обрушивает сервис.
Почему платформы «валятся» при масштабировании
Частая история: на 100 виртуальных машин или рабочих мест всё работает прекрасно, но стоит начать масштабироваться вверх — и платформа начинает сыпаться. Почему так?
Ответ — в архитектуре. В Inscale ставка сделана на микросервисную архитектуру и микросегментацию задач. Любое изменение состояния инфраструктуры (переход из состояния A в состояние B) разбивается не на линейную цепочку, а на дерево микрозадач: часть из них может выполняться одновременно, поэтому это именно дерево (а с учётом зависимостей — граф). Причём это дерево не предопределяется заранее, а генерируется под конкретную задачу.
Смысл микросегментации — чтобы при сбое одного элемента остальное оставалось максимально целым. Есть, конечно, корневые сервисы, падение которых затронет связанные модули, но цель архитектуры — локализовать сбой, а не дать ему обрушить весь кластер при росте нагрузки.
Дополнительный фактор устойчивости — отсутствие ручной возни: все действия администратора строго валидируются, а конфигурация не редактируется «руками в config.xml». Человеческий фактор и невалидируемые правки — частая причина аварий на больших инсталляциях.
Гиперконвергенция и программно-определяемое хранилище
Логичное развитие кластера — гиперконвергенция, когда вычисления и хранение объединяются на одних и тех же узлах под управлением софта, без отдельной СХД. Ключевой компонент здесь — программно-определяемое хранилище (SDS).
SDS — самый ответственный слой: если «умирает» отдельный гипервизор, погрустит один пользователь, а если падает распределённое хранилище — простаивают все. Известны случаи, когда распределённое хранилище подобного класса переставало корректно работать на больших инсталляциях на этапе ребалансировки после выхода узлов из строя. Поэтому в Inscale действует принцип: пока в продукте нет уверенности хотя бы на 95% — он не выпускается. Если функционал заявлен, он работает; куда важнее функциональных требований здесь — нефункциональные, то есть поведение под нагрузкой и при отказах.
Поэтому SDS Inscale выводит поэтапно: сначала — гибридный вариант, где железные СХД ещё используются, а на программно-определяемое хранилище переносят прежде всего управляющие виртуальные машины с более низким уровнем риска, а затем масштабируются. Полноценный выход собственного SDS планируется ориентировочно к 2027 году.
Что кластер виртуализации даёт бизнесу
Если свести к практике, грамотно спроектированный кластер виртуализации даёт:
- устойчивость класса N вместо «1+1» — кластер переживает отказ нескольких узлов;
- живучесть управления — контроллер кластера спроектирован так, чтобы удерживать ВМ и сервисы даже при отказе оркестратора;
- откат в прошлое через event sourcing — ошибки настройки или кода не оставляют систему в «полусломанном» состоянии;
- предсказуемое масштабирование — микросервисы и микросегментация задач не дают сбою каскадом обрушить платформу;
- геораспределённость — возможность пережить потерю целой площадки.
Разобраться, из чего ещё состоит зрелая платформа и как её выбирать, поможет наш разбор российской системы виртуализации, а про требования регулятора — материал про приказ ФСТЭК № 117.
