Распределённая группа доступности

Распределённая группа доступности (Distributed Availability Group, DAG) — это технология обеспечения высокой доступности и отказоустойчивости почтовых серверов на платформе Microsoft Exchange Server, начиная с версии 2010. DAG представляет собой группу из нескольких серверов Exchange (до 16), работающих совместно для автоматического восстановления работоспособности почтовой службы при сбоях оборудования, программного обеспечения или сети. В основе DAG лежит механизм репликации баз данных почтовых ящиков на уровне базы данных, а не на уровне файловой системы, что позволяет обеспечить непрерывность работы и минимизировать время простоя.

История

Технология DAG была впервые представлена корпорацией Microsoft в 2009 году в составе Exchange Server 2010. До этого в Exchange Server 2007 для обеспечения отказоустойчивости использовались кластеры непрерывной репликации (Cluster Continuous Replication, CCR) и кластеры локальной непрерывной репликации (Local Continuous Replication, LCR), которые были сложнее в настройке и управлении. DAG пришла на смену этим решениям, упростив архитектуру и снизив требования к аппаратному обеспечению.

В Exchange Server 2013 и 2016 технология DAG была значительно улучшена: добавлена поддержка до 16 узлов, улучшена система автоматического переключения при сбоях (failover), оптимизирована репликация данных. В Exchange Server 2019 DAG остаётся ключевым компонентом для построения отказоустойчивых почтовых систем, хотя сама платформа Exchange Server 2019 является последней версией в линейке локальных серверов (Microsoft переходит на облачную модель Exchange Online).

Архитектура и принцип работы

Компоненты DAG

DAG состоит из следующих ключевых элементов:

• Узлы (серверы) — физические или виртуальные серверы под управлением Windows Server с установленной ролью Mailbox server в Exchange Server. Максимальное количество узлов — 16.
• Базы данных почтовых ящиков — каждая база данных может иметь несколько копий (до 16), распределённых по разным узлам DAG. Одна копия является активной, остальные — пассивными.
• Свидетели (Witness) — для обеспечения кворума при чётном количестве узлов используется внешний сервер-свидетель (обычно файловый сервер) или облачный свидетель (Azure Witness). Свидетель участвует в голосовании при определении работоспособности группы.
• Сеть репликации — выделенная сеть (или несколько сетей) для передачи данных между узлами. Рекомендуется использовать отдельные сетевые адаптеры для трафика репликации и клиентского доступа.

Репликация данных

Репликация в DAG осуществляется на уровне базы данных (database-level replication). При внесении изменений в активную копию базы данных (например, при получении нового письма) сервер записывает транзакцию в журнал транзакций (log file). Затем эта транзакция асинхронно или синхронно передаётся на пассивные копии. В случае синхронной репликации подтверждение записи на пассивную копию ожидается до завершения операции на активной, что гарантирует нулевую потерю данных (zero data loss) при сбое. При асинхронной репликации допускается небольшая задержка, но снижается нагрузка на сеть.

Автоматическое переключение при сбоях (Failover)

При обнаружении сбоя (отказ сервера, потеря связи, сбой диска) DAG автоматически активирует пассивную копию базы данных на другом узле. Процесс включает:

1. Мониторинг состояния узлов и баз данных с помощью службы контроля работоспособности (Health Monitoring).
2. При обнаружении сбоя система инициирует переключение (failover) — пассивная копия становится активной.
3. Клиенты (Outlook, OWA, мобильные устройства) автоматически перенаправляются на новый активный сервер через балансировщик нагрузки или службу автообнаружения (Autodiscover).

Время переключения обычно составляет от 30 секунд до нескольких минут в зависимости от размера базы данных и скорости сети.

Классификация и виды

DAG классифицируется по нескольким признакам:

• По количеству узлов: от 2 до 16 серверов. Наиболее распространённые конфигурации — 2, 4 или 8 узлов.
• По типу репликации: синхронная (для критичных систем с требованиями нулевой потери данных) и асинхронная (для снижения нагрузки на сеть).
• По географическому расположению: локальная (все серверы в одном центре обработки данных) и географически распределённая (серверы в разных дата-центрах, соединённых через WAN). В последнем случае требуется настройка сети с низкой задержкой и высокой пропускной способностью.
• По наличию свидетеля: с внешним свидетелем (файловый сервер) или без него (при нечётном количестве узлов свидетель не требуется, так как кворум обеспечивается самими узлами).

Применение и значение

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

• Обеспечение непрерывности бизнеса — почтовая система остаётся доступной при сбоях оборудования, плановых обслуживаниях или авариях.
• Минимизация времени простоя — автоматическое переключение при сбоях происходит без участия администратора.
• Защита данных — репликация баз данных предотвращает потерю писем при отказе дисков или серверов.
• Географическая отказоустойчивость — возможность размещения копий баз данных в разных городах для защиты от региональных катастроф.

В России технология DAG используется в государственных информационных системах, например, в системах электронного документооборота и почтовых сервисах федеральных органов власти, где требования к надёжности и отказоустойчивости регламентируются нормативными актами (например, 152-ФЗ «О персональных данных»).

Примеры конфигураций

Пример 1: DAG из 2 узлов с внешним свидетелем

• Два сервера Exchange в одном ЦОД.
• Файловый сервер-свидетель (Witness) для обеспечения кворума.
• Синхронная репликация всех баз данных.
• При сбое одного сервера второй автоматически берёт на себя все активные копии.

Пример 2: Географически распределённый DAG из 4 узлов

• Два сервера в Москве, два — в Санкт-Петербурге.
• Сеть между ЦОД с задержкой менее 5 мс.
• Асинхронная репликация между городами, синхронная — внутри каждого ЦОД.
• Свидетель — облачный сервис Azure Witness.

Критика и ограничения

Несмотря на широкое распространение, технология DAG имеет ряд недостатков:

• Сложность настройки и обслуживания — требуется квалифицированный персонал, знающий архитектуру Exchange и Windows Server.
• Высокие требования к сети — для синхронной репликации необходима стабильная сеть с низкой задержкой (менее 10 мс) и высокой пропускной способностью. В географически распределённых конфигурациях это может быть дорого.
• Ограничение на количество узлов — максимум 16 серверов, что может быть недостаточно для очень крупных организаций.
• Зависимость от свидетеля — при чётном количестве узлов отказ свидетеля может привести к потере кворума и остановке DAG.
• Отсутствие встроенной балансировки нагрузки — DAG не распределяет клиентские запросы; для этого требуется внешний балансировщик (например, Windows NLB или аппаратный балансировщик).

Интересные факты

• Технология DAG была разработана на основе опыта работы с кластерами Windows Server Failover Clustering (WSFC), но адаптирована для работы с базами данных Exchange.
• В Exchange Server 2010 DAG поддерживала только 16 узлов, но в реальных проектах редко использовалось более 8.
• С переходом Microsoft на облачную модель Exchange Online (часть Microsoft 365) локальные DAG постепенно теряют актуальность, однако многие российские организации продолжают использовать их из-за требований к локализации данных.
• В России существуют аналогичные решения на базе отечественного ПО (например, CommuniGate Pro или RuPost), которые также реализуют механизмы отказоустойчивости, схожие с DAG.

Источники

• Microsoft Docs: Exchange Server DAG (Distributed Availability Groups) — официальная документация Microsoft.
• «Exchange Server 2016: архитектура и управление» — книга К. Майерса, 2017.
• «Высокая доступность в Exchange Server 2019» — статья в журнале «Системный администратор», № 4, 2020.
• Нормативные документы: 152-ФЗ «О персональных данных», требования к отказоустойчивости государственных информационных систем.