Кластер виртуализации — это не «несколько серверов с гипервизором», а целая экосистема сервисов, которая держит инфраструктуру на ногах, даже когда часть из них выходит из строя. Когда говорят «виртуализация», за этим словом стоят программно-определяемые сети, оркестрация, отказоустойчивость, контроллер кластера, диагностика и мониторинг, безопасность и изоляция. В платформе AirCloud таких сервисов около шестнадцати. Ядро KVM в этой картине — важнейший «кирпичик» и фундамент, но именно обвязка вокруг него превращает набор серверов в надёжный отказоустойчивый кластер.
В этом материале — как устроен кластер виртуализации на уровне архитектуры: из каких слоёв он состоит, что такое отказоустойчивость класса N и как считается кворум, как Event Sourcing помогает восстанавливать состояние управления и почему многие платформы «валятся» при росте нагрузки. Если нужен общий обзор платформы — он в разборе системы виртуализации.
Из чего состоит кластер виртуализации
Зрелый кластер виртуализации — это несколько слоёв, и гипервизор лишь один из них:
- Гипервизор — то, что непосредственно запускает виртуальные машины. Его задача — не мешать и стабильно держать фундамент.
- Оркестратор — управляющий слой: и интерфейс администратора, и взаимодействие с гипервизорами. В терминологии AirCloud это центральный сервер.
- Контроллер кластера — отдельный слой живучести, который продолжает работать, даже если упал весь оркестратор. Об этом ниже.
- Распределённый виртуальный свитч — сеть, управляемая софтом, а не привязанная к железу: аплинки, порт-группы, объединение каналов.
- Балансировщик нагрузки — размещает машины по узлам в режиме производительности или плотности.
- Сервисные модули — диагностика, мониторинг, безопасность, изоляция, центр обновлений и ещё около десятка служб.
Именно поэтому виртуализацию правильнее называть экосистемным продуктом: надёжность кластера определяется не «голым» гипервизором, а тем, как спроектированы управляющий слой и отказоустойчивость.
Контроллер кластера и уровни живучести
Обычно весь управляющий слой аккумулирует оркестратор — но что произойдёт, если упадёт он сам? В AirCloud за живучесть отвечает отдельная служба, работающая на уровне гипервизора: пользовательские виртуальные машины продолжают обслуживаться, даже когда центр управления временно недоступен.
Как именно контроллер обрабатывает отказ узла и коварный сценарий потери связи между половинами кластера, подробно разобрано в отдельной статье — «Отказоустойчивость виртуальных машин». Здесь же сосредоточимся на другом уровне — отказоустойчивости самого кластера управления — и на том, что отличает архитектуру зрелого кластера.
Отказоустойчивость класса N: кворум по большинству
Отказоустойчивость управляющего слоя бывает устроена по-разному: от одиночного узла управления до репликации «1+1» — основной узел и резервный — и кластеров с кворумом. Одиночный узел отказоустойчивости не даёт, а схема «1+1» требует отдельной настройки репликации базы данных и плохо расширяется.
Платформа AirCloud изначально проектировалась под отказоустойчивость класса N — кластер управления из N узлов с кворумом по большинству голосов (floor(N/2)+1). Это значит, что кластер управления сохраняет работу при потере части узлов:
- допустимо потерять меньше половины узлов: при трёх и четырёх узлах — одного, при пяти — двух;
- защиту от одновременного запуска ВМ на двух хостах обеспечивают кворум и fencing.
Если уцелел хотя бы один узел управления, конфигурацию можно восстановить из его данных. Это восстановление управления, а не непрерывная работа всей нагрузки.
Event Sourcing: история событий и восстановление управления
Хранилище состояния управляющего слоя — то, где собираются все произошедшие с системой события, — построено по принципу Event Sourcing. Про каждый ресурс, например виртуальную машину, известна вся цепочка событий: что и когда с ним происходило.
Практическая польза — по истории событий восстанавливается состояние управления, ведётся аудит изменений, а незавершённая операция возвращается к исходному состоянию. Если какая-то операция в инфраструктуре не достигла желаемого конечного состояния — например, из-за ошибки настройки, — система возвращает её к исходной точке. Это уже не раз спасало на реальных инсталляциях. Содержимое дисков и памяти виртуальных машин так не восстанавливается — его защищает резервное копирование.
> Про каждый ресурс мы знаем всю цепочку событий: что и когда с ним происходило. Если операция не дошла до конца, система возвращает её к исходному состоянию. Это много раз нас спасало.
>
> — команда разработки AirCloud
Консистентность и геораспределённый кластер
Чтобы отказоустойчивость класса N работала, все узлы кластера управления хранят события консистентно, синхронизируя их максимально экономно — минимально нагружая сеть и минимально завися от задержек. Полностью зависимость от сети убрать нельзя, но её удаётся существенно нивелировать. В результате «сломать» такой кластер целиком — нетривиальная задача.
Более того, кластер может работать геораспределённо. У платформы есть реальный опыт инсталляции с узлами в двух странах одновременно — и это работало. Для критичной инфраструктуры это означает: при размещении голосов кворума и репликации хранилища на площадках работу можно сохранить при потере одной из них.
Почему платформы «валятся» при масштабировании
Частая история: на 100 виртуальных машин или рабочих мест всё работает прекрасно, но стоит начать масштабироваться вверх — и платформа начинает сыпаться. Почему так?
Ответ — в архитектуре. В AirCloud ставка сделана на микросервисную архитектуру и микросегментацию задач. Любое изменение состояния инфраструктуры разбивается не на линейную цепочку, а на дерево микрозадач: часть из них может выполняться одновременно, а с учётом зависимостей это уже граф. Причём дерево не предопределяется заранее, а генерируется под конкретную задачу.
Смысл микросегментации — чтобы при сбое одного элемента остальное оставалось максимально целым. Есть, конечно, корневые сервисы, падение которых затронет связанные модули, но цель архитектуры — локализовать сбой, а не дать ему обрушить весь кластер при росте нагрузки. В синтетических тестах платформа держала около 5000 виртуальных машин на 25 узлах; это проверка масштабируемости управляющего слоя, а не оценка боевой нагрузки — она зависит от профиля ВМ и оборудования.
Дополнительный фактор устойчивости — отсутствие ручной возни: все действия администратора строго валидируются, а конфигурация не редактируется «руками в файле». Человеческий фактор и невалидируемые правки — частая причина аварий на больших инсталляциях.
Балансировка нагрузки
Кластер не только переживает отказы, но и работает эффективнее набора одиночных серверов. Балансировщик размещает машины по узлам в одном из двух режимов: максимум производительности — каждая машина получает свои ресурсы — или максимум плотности, когда при запуске машины размещаются плотнее, а незагруженные узлы можно перевести в гибернацию. Перенос работающих машин между узлами без остановки — живая миграция — отдельная функция: её доступность и поддерживаемые конфигурации зависят от версии AirCloud, для вашей инсталляции уточняем на демонстрации.
Гиперконвергенция: вычисления и хранение на одних узлах (SDS — в разработке)
Логичное развитие кластера — гиперконвергенция, когда вычисления и хранение объединяются на одних и тех же узлах под управлением софта, без отдельной системы хранения. Ключевой компонент такой гиперконвергентной системы — программно-определяемое хранилище.
Это самый ответственный слой: если «умирает» отдельный гипервизор, погрустит один пользователь, а если падает распределённое хранилище — простаивают все. Известны случаи, когда у крупных вендоров распределённое хранилище обрушивалось на больших инсталляциях на этапе ребалансировки после выхода узлов из строя. Поэтому в AirCloud действует принцип: функции выпускаются после испытаний под нагрузкой и при отказах, а ограничения текущей версии указываются в документации. Куда важнее функциональных требований здесь — нефункциональные, то есть поведение под нагрузкой и при отказах.
Сегодня кластер AirCloud работает с внешними промышленными хранилищами — NFS, iSCSI, Fibre Channel — с автоматическим обнаружением устройств. Собственное программно-определяемое хранилище находится в разработке и будет выводиться поэтапно: сначала на управляющие машины с более низким уровнем риска, затем на пользовательские нагрузки. Сроки мы не анонсируем, пока не уверены.
Что кластер виртуализации даёт бизнесу
Если свести к практике, грамотно спроектированный кластер виртуализации даёт:
- устойчивость класса N — кластер управления переживает отказ узлов в пределах кворума;
- живучесть управления — контроллер кластера держит машины и сервисы, даже если упал оркестратор;
- историю событий через Event Sourcing — незавершённая операция возвращается к исходному состоянию, изменения аудируются;
- предсказуемое масштабирование — микросервисы и микросегментация задач не дают сбою каскадом обрушить платформу;
- геораспределённость — при размещении голосов кворума и репликации хранилища на площадках можно сохранить работу при потере одной из них;
- экономию — балансировка в режиме плотности: в тестах — до 40% больше ВМ на том же оборудовании.
Разобраться, из чего ещё состоит зрелая платформа и как её выбирать, поможет разбор системы виртуализации. Хотите увидеть, как кластер переживает отказ узла, на живом стенде — запросите демо.