Кворум кластера

Кворум кластера — это механизм, обеспечивающий согласованность данных и предотвращающий «расщепление мозга» (split-brain) в отказоустойчивых кластерных системах. Кворум определяет минимальное количество участников кластера (узлов), которое должно быть доступно и активно для того, чтобы кластер мог продолжать работу, принимать решения и обслуживать запросы. Без достижения кворума кластер переходит в неработоспособное состояние или блокирует операции записи, чтобы избежать повреждения данных.

Принцип работы

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

Математическая основа

Кворум обычно определяется как N/2 + 1, где N — общее количество узлов в кластере. Например, в кластере из трёх узлов кворум составляет 2 узла. Если один узел выходит из строя, оставшиеся два всё ещё могут сформировать кворум и продолжить работу. Если выходят из строя два узла, оставшийся один не может достичь кворума, и кластер останавливается. Для кластера из пяти узлов кворум — 3 узла, и он может пережить потерю двух узлов.

Роль свидетеля (witness)

В некоторых системах, особенно в кластерах с чётным числом узлов (например, два узла), используется дополнительный компонент — свидетель (witness). Свидетель — это легковесный процесс или ресурс (например, файл на общем диске, облачная служба или отдельный сервер), который не хранит данные, но участвует в голосовании. Его задача — добавить один голос, чтобы избежать ситуации, когда два узла имеют равное количество голосов (2 против 2) и не могут определить, кто из них должен взять управление. В кластере из двух узлов со свидетелем кворум составляет 2 голоса (один узел + свидетель), и потеря одного узла не приводит к остановке кластера, так как оставшийся узел вместе со свидетелем образует кворум.

Типы кворумов

В зависимости от архитектуры кластера и используемого программного обеспечения, кворум может быть реализован различными способами:

Кворум на основе голосования (Voting Quorum)

Каждый узел и свидетель имеют один голос. Решение принимается, если за него отдано более половины голосов от общего числа участников голосования. Этот тип используется в кластерных менеджерах, таких как Pacemaker и Microsoft Failover Cluster.

Кворум на основе диска (Disk Quorum)

Используется общий диск (например, SCSI-диск или раздел на SAN), который выступает в роли арбитра. Узел, который первым захватил этот диск, получает право управлять кластером. Остальные узлы, не имеющие доступа к диску, считаются неактивными. Этот метод менее гибок, так как диск является единой точкой отказа.

Кворум на основе консенсуса (Consensus Quorum)

Применяется в распределённых системах, использующих алгоритмы консенсуса, такие как Raft или Paxos. В таких системах кворум — это не просто количество узлов, а набор узлов, который должен подтвердить операцию (например, запись в лог). Обычно требуется большинство (N/2 + 1) для коммита. Этот подход лежит в основе многих современных распределённых баз данных (например, etcd, Consul, Apache ZooKeeper).

Кворум с динамическим изменением (Dynamic Quorum)

Современные кластерные системы, такие как Windows Server Failover Cluster (начиная с Windows Server 2012) и некоторые реализации на основе Pacemaker, могут динамически изменять размер кворума при изменении количества узлов. Если узел выходит из строя, кворум пересчитывается на основе оставшихся узлов, что позволяет кластеру выживать при последовательных отказах большего числа узлов, чем это было бы возможно при статическом кворуме.

Применение

Кворум кластера используется в широком спектре отказоустойчивых систем:

• Базы данных: PostgreSQL (с использованием Patroni и etcd), MySQL (с Group Replication), Microsoft SQL Server (Always On Availability Groups).
• Файловые системы: GlusterFS, Ceph.
• Виртуализация: VMware vSphere (High Availability), Microsoft Hyper-V (Failover Cluster).
• Контейнерные оркестраторы: Kubernetes (etcd для хранения состояния кластера).
• Кластерные менеджеры: Pacemaker, Corosync, Keepalived.

Проблемы и ограничения

• Потеря кворума: Если количество доступных узлов падает ниже кворума, кластер останавливается. Это может произойти при каскадных отказах или сетевых проблемах, разделяющих кластер на несколько изолированных групп.
• Задержки: В распределённых системах с кворумом на основе консенсуса каждый запрос на запись требует подтверждения от большинства узлов, что увеличивает задержки по сравнению с системами без кворума.
• Сложность настройки: Неправильная конфигурация кворума (например, отсутствие свидетеля в двухузловом кластере) может привести к неработоспособности системы при отказе одного узла.
• Зависимость от свидетеля: Если свидетель становится недоступным, кластер с чётным числом узлов может потерять способность формировать кворум.

Примеры реализации

Pacemaker + Corosync

В кластерах на основе Pacemaker и Corosync кворум реализуется через механизм голосования. Каждый узел имеет один голос. Для работы кластера необходимо, чтобы количество активных узлов превышало половину от общего числа узлов. Если кворум потерян, Pacemaker переводит кластер в состояние «остановлен» и не запускает ресурсы.

etcd (Raft)

etcd — это распределённое хранилище ключ-значение, используемое в Kubernetes. Оно использует алгоритм Raft, где кворум для записи составляет N/2 + 1. Например, в кластере из 5 узлов для записи требуется подтверждение от 3 узлов. Если кворум потерян, etcd блокирует операции записи, но может продолжать читать данные.

Microsoft Failover Cluster

В Windows Server Failover Cluster кворум может быть настроен на основе голосования узлов и свидетеля (диска, файловой доли или облачного свидетеля). Система динамически пересчитывает кворум при изменении состава кластера. Если кворум не достигнут, кластер останавливается.

Источники

1. Microsoft Docs. «Understanding Quorum in a Failover Cluster». Windows Server documentation.
2. Ongaro, D., Ousterhout, J. «In Search of an Understandable Consensus Algorithm (Extended Version)». Stanford University, 2014.
3. Red Hat. «Pacemaker Explained: Quorum and Cluster Resources». Red Hat Customer Portal.
4. CoreOS. «etcd Documentation: Raft Consensus Algorithm». etcd.io.
5. Vaughn, R. «Cluster Quorum and Split-Brain Scenarios». Linux Journal, 2015.