Сервер-свидетель¶

Сервер-свидетель (англ. witness server) — это специализированный сервер в распределённой системе управления базами данных (СУБД) или кластере, который не хранит полную копию данных, а участвует в процессе голосования для достижения консенсуса и обеспечения отказоустойчивости. Основная функция сервера-свидетеля — разрешение конфликтов при разделении сети (split-brain) и поддержание кворума (quorum) в кластерных конфигурациях, где чётное количество узлов может привести к неопределённости при голосовании.

¶Назначение и принцип работы

Сервер-свидетель используется в системах, где требуется высокая доступность (High Availability, HA) и отказоустойчивость. В типичном кластере с двумя основными узлами (например, в Microsoft SQL Server Always On Failover Cluster Instance или в PostgreSQL с Patroni) при выходе из строя одного из узлов второй должен автоматически взять на себя управление. Однако при потере связи между узлами (сетевой раздел) каждый из них может считать себя единственным работоспособным, что приводит к конфликту — «расщеплению мозга» (split-brain). Сервер-свидетель, имея только информацию о состоянии узлов и право голоса, но не храня данные, помогает определить, какой узел должен остаться активным, а какой — перейти в пассивное состояние.

В более сложных конфигурациях (например, в кластерах на основе Apache ZooKeeper, etcd или Consul) сервер-свидетель может быть частью системы распределённого консенсуса, реализующей алгоритмы, такие как Paxos или Raft. В таких системах свидетель участвует в выборах лидера и подтверждении операций записи, но не участвует в репликации данных.

¶История

Концепция сервера-свидетеля возникла в контексте развития отказоустойчивых кластерных систем в 1990-х годах. Одним из ранних коммерческих примеров стала технология Microsoft Cluster Server (MSCS), представленная в Windows NT 4.0 Enterprise Edition (1997 год). В ней для кластеров из двух узлов использовался так называемый «диск-свидетель» (quorum disk) — общий диск, который хранил информацию о состоянии кластера. Однако физический диск был единой точкой отказа. Позднее, с развитием облачных и виртуализированных сред, появилась возможность использовать «облачный свидетель» (cloud witness) — сервер-свидетель, размещённый в облачной инфраструктуре, что устранило зависимость от физического оборудования.

В 2012 году Microsoft представила функцию «Always On Availability Groups» в SQL Server 2012, где сервер-свидетель стал отдельным компонентом, не требующим общего хранилища. В последующие годы аналогичные механизмы были реализованы в других СУБД и системах управления конфигурациями.

¶Типы серверов-свидетелей

¶По способу хранения состояния

• Дисковый свидетель (Disk Witness) — использует общий диск (например, в кластерах Windows Server Failover Cluster). Диск хранит копию конфигурации кластера и используется для голосования. Недостаток: требует общего хранилища, которое может быть узким местом.
• Файловый свидетель (File Share Witness) — использует общую сетевую папку (SMB-ресурс). В этой папке хранится файл состояния кластера. Подходит для небольших кластеров, но менее надёжен при высокой задержке сети.
• Облачный свидетель (Cloud Witness) — использует облачный сервис (например, Azure Blob Storage или AWS S3). Хранит состояние кластера в виде блоба. Преимущества: отсутствие необходимости в общем хранилище, географическая распределённость, автоматическое резервирование.
• Свидетель на основе базы данных (Database Witness) — в некоторых системах (например, в SQL Server Always On Availability Groups) свидетель может быть отдельной базой данных, которая не реплицируется, но участвует в голосовании.

¶По роли в системе консенсуса

• Свидетель кворума (Quorum Witness) — участвует в голосовании для определения кворума в кластере. В кластере с чётным числом узлов (например, 2) добавление свидетеля делает общее число голосов нечётным (3), что исключает ситуацию «ничья» при разделении сети.
• Свидетель-наблюдатель (Observer Witness) — в системах распределённого консенсуса (например, в Raft) такой узел не участвует в репликации данных, но может инициировать выборы лидера и подтверждать операции записи, если он является частью большинства.
• Свидетель-арбитр (Arbiter Witness) — в некоторых NoSQL-системах (например, MongoDB) арбитр — это узел, который не хранит данные, но участвует в выборах первичного узла (primary) и разрешении конфликтов. Арбитр не требует значительных ресурсов (диск, память), так как не хранит данные.

¶Применение

¶Microsoft SQL Server Always On Availability Groups

В SQL Server сервер-свидетель используется для обеспечения автоматического переключения при отказе (automatic failover) в режиме синхронной репликации. В конфигурации с двумя репликами (одна основная, одна вторичная) добавление свидетеля позволяет автоматически определить, какая реплика должна стать основной при потере связи. Свидетель может быть третьей репликой (с ручным управлением) или отдельным экземпляром SQL Server, не участвующим в репликации данных.

¶Windows Server Failover Cluster

В кластерах Windows Server сервер-свидетель (дисковый, файловый или облачный) используется для хранения копии конфигурации кластера и голосования. В Windows Server 2012 и новее появилась поддержка облачного свидетеля (Azure Witness), что упростило развёртывание отказоустойчивых кластеров в гибридных средах.

¶PostgreSQL с Patroni

В системе управления кластером PostgreSQL Patroni (на основе etcd или ZooKeeper) сервер-свидетель может быть реализован как отдельный узел etcd, который не хранит данные PostgreSQL, но участвует в выборах лидера. Это позволяет избежать split-brain при отказе одного из узлов etcd.

¶Apache ZooKeeper и etcd

В этих системах распределённой координации сервер-свидетель (observer) — это узел, который не участвует в голосовании, но получает и обрабатывает запросы на чтение. Такие узлы используются для масштабирования чтения без увеличения задержек записи. В ZooKeeper наблюдатели (observers) не являются частью кворума, но могут быть добавлены для повышения производительности.

¶MongoDB

В MongoDB арбитр (arbiter) — это узел репликационного набора, который не хранит данные, но участвует в выборах первичного узла. Арбитр используется в конфигурациях с чётным числом узлов данных (например, 2 узла данных + 1 арбитр). Арбитр не требует большого объёма дискового пространства и памяти, что делает его дешёвым решением для обеспечения отказоустойчивости.

¶Преимущества и недостатки

¶Преимущества

• Предотвращение split-brain: сервер-свидетель позволяет однозначно определить активный узел при разделении сети, что критически важно для целостности данных.
• Экономия ресурсов: свидетель не хранит данные, поэтому не требует значительных дисковых ресурсов и может быть развёрнут на маломощном оборудовании или в облаке.
• Гибкость: возможность использования облачного свидетеля упрощает развёртывание в гибридных и облачных средах, не требуя общего хранилища.
• Простота настройки: в большинстве систем (SQL Server, Windows Cluster) добавление свидетеля — это стандартная операция, не требующая сложной конфигурации.

¶Недостатки

• Дополнительная точка отказа: хотя свидетель сам по себе отказоустойчив (например, облачный), его недоступность может привести к потере возможности автоматического переключения. В некоторых конфигурациях отсутствие свидетеля делает кластер неработоспособным при отказе одного узла.
• Зависимость от сети: для работы свидетеля требуется стабильное сетевое соединение. Высокая задержка или потеря связи могут привести к некорректной работе кластера.
• Ограниченная функциональность: свидетель не участвует в репликации данных, поэтому не может быть использован для балансировки нагрузки чтения или восстановления данных.
• Сложность в распределённых системах: в системах с несколькими свидетелями (например, в ZooKeeper) требуется правильная настройка кворума, иначе возможны конфликты.

¶Критика и альтернативы

Некоторые специалисты критикуют использование сервера-свидетеля как избыточное усложнение, особенно в небольших кластерах. Вместо свидетеля можно использовать конфигурацию с тремя узлами данных (нечётное число), что решает проблему кворума без дополнительного компонента. Однако в средах с ограниченными ресурсами или в облачных развёртываниях свидетель остаётся популярным решением.

В современных распределённых системах (например, в CockroachDB, TiDB) используется алгоритм Raft, где все узлы равноправны и участвуют в голосовании, но могут быть настроены как «ненаблюдатели» (non-voting learners), которые не влияют на кворум. Это альтернатива классическому свидетелю, но с более сложной логикой.

¶Источники

• Microsoft Docs. «Failover Clustering: Quorum and Witness». Windows Server documentation.
• Microsoft Docs. «Always On Availability Groups: Automatic Failover and Witness». SQL Server documentation.
• MongoDB Documentation. «Replica Set Arbiter».
• Apache ZooKeeper Documentation. «Observers».
• Patroni Documentation. «High Availability for PostgreSQL».
• Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media. — Глава 8: «Distributed Consensus».
• Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann. — Раздел о кворумах и свидетелях.