Database Availability Groups

Database Availability Groups (DAG) — это технология отказоустойчивости и репликации почтовых баз данных на уровне серверов, реализованная в платформе Microsoft Exchange Server, начиная с версии 2010. DAG представляет собой группу из двух и более серверов Exchange (роль Mailbox), которые совместно обеспечивают высокую доступность (High Availability, HA) и аварийное восстановление (Site Resilience) почтовых ящиков пользователей за счёт непрерывной репликации баз данных на уровне журналов транзакций.

История и развитие

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

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

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

DAG базируется на технологии Windows Failover Clustering, но использует её только для координации и мониторинга, а не для общего хранилища данных. Каждый сервер в DAG хранит свои копии баз данных локально (на собственных дисках). Репликация данных между серверами осуществляется асинхронно на уровне журналов транзакций (log shipping).

Основные компоненты

• Узел DAG (DAG Member) — сервер Exchange с ролью Mailbox, входящий в группу.
• Копия базы данных (Database Copy) — дубликат активной базы данных, хранящийся на другом сервере DAG. Каждая база данных может иметь до 16 копий (включая активную).
• Активная копия (Active Copy) — копия базы данных, которая в данный момент обслуживает запросы пользователей (чтение/запись).
• Пассивная копия (Passive Copy) — копия, которая синхронизируется с активной, но не обслуживает запросы.
• Свидетеля (Witness Server) — внешний сервер (не входящий в DAG), используемый для достижения кворума при чётном количестве узлов. Обычно это файловый сервер или сервер с ролью Client Access в Exchange.

Процесс репликации

1. Транзакции, выполняемые на активной копии базы данных, записываются в журнал транзакций (transaction log).
2. Файлы журналов (log files) асинхронно копируются на серверы с пассивными копиями той же базы данных.
3. На пассивных серверах журналы применяются к копии базы данных (replay), поддерживая её в актуальном состоянии.
4. Репликация может быть как синхронной (Seeding), так и асинхронной (Incremental). В режиме синхронной репликации транзакция считается завершённой только после подтверждения записи на всех целевых серверах.

Автоматическое переключение (AutoFailover)

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

• Потеря связи с сервером (heartbeat timeout).
• Сбой службы хранения (Information Store).
• Ошибка диска или файловой системы.
• Потеря кворума кластера.

Переключение происходит в течение нескольких секунд (обычно 30–120 секунд) и не требует вмешательства администратора.

Классификация и типы DAG

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

По географическому расположению

• Локальный DAG (Local DAG) — все серверы находятся в одном дата-центре или на одной площадке. Обеспечивает отказоустойчивость на уровне серверов, но не защищает от аварии всего центра.
• Распределённый DAG (Multi-site DAG) — серверы размещены в нескольких географически удалённых дата-центрах (site resilience). Позволяет пережить полный выход из строя одного центра. Требует настройки сети с низкой задержкой (обычно не более 5–10 мс) и высокой пропускной способностью.

По количеству копий

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

По режиму репликации

• Синхронная репликация (Synchronous Replication) — транзакция считается завершённой только после записи на всех целевых серверах. Обеспечивает нулевую потерю данных (RPO=0), но увеличивает задержки записи.
• Асинхронная репликация (Asynchronous Replication) — транзакция завершается сразу после записи на активном сервере. Снижает задержки, но допускает потерю данных при сбое (RPO > 0).

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

DAG является основным механизмом обеспечения высокой доступности в корпоративных средах Exchange. Она используется организациями любого масштаба — от средних компаний (2–4 сервера) до крупных предприятий (десятки серверов, распределённые по континентам).

Основные сценарии использования

• Отказоустойчивость на уровне сервера — выход из строя одного сервера не приводит к простою почтовой службы.
• Плановое обслуживание — администратор может перевести активные копии на другой сервер без прерывания работы пользователей (database mobility).
• Аварийное восстановление — при катастрофе в одном дата-центре почтовая система продолжает работу из другого центра.
• Балансировка нагрузки — активные копии баз данных могут быть распределены между серверами для равномерной загрузки.

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

• Простота управления — DAG настраивается через графический интерфейс Exchange Admin Center или PowerShell.
• Автоматизация — переключение происходит без участия администратора.
• Экономия — не требуется дорогостоящее общее хранилище (SAN), используются локальные диски.
• Масштабируемость — до 16 серверов в одной группе и до 16 копий базы данных.

Недостатки

• Сложность сети — требует высокоскоростной и надёжной сети между серверами (особенно для синхронной репликации).
• Потребление ресурсов — репликация создаёт дополнительную нагрузку на процессор, память и сеть.
• Ограничение на количество копий — на практике более 4–6 копий редко оправданы из-за роста сложности и затрат.
• Зависимость от Windows Failover Clustering — ошибки в кластерной службе могут привести к сбоям DAG.

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

Типовая конфигурация для среднего предприятия

• 2 сервера Exchange в локальном DAG.
• 2 копии каждой базы данных (активная на первом сервере, пассивная на втором).
• Синхронная репликация для критичных баз, асинхронная для менее важных.
• Свидетель (Witness Server) — файловый сервер в той же сети.

Конфигурация для крупного предприятия с двумя дата-центрами

• 4 сервера Exchange: 2 в основном центре (Site A), 2 в резервном (Site B).
• 4 копии каждой базы данных: активная и одна пассивная в Site A, две пассивные в Site B.
• Асинхронная репликация между центрами, синхронная внутри центра.
• Свидетель — сервер в третьем, нейтральном центре (для кворума).

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

Несмотря на широкое распространение, DAG имеет ряд критических замечаний:

• Сложность настройки сети — для распределённых DAG требуется низкая задержка (менее 5 мс) и высокая пропускная способность, что не всегда достижимо в глобальных сетях.
• Управление кворумом — при чётном количестве серверов требуется внешний свидетель, который может стать единой точкой отказа.
• Производительность — синхронная репликация может снижать производительность записи на 10–30% в зависимости от нагрузки и сети.
• Ограниченная поддержка в облаке — в Exchange Online (Microsoft 365) DAG не используется напрямую; Microsoft использует собственную архитектуру высокой доступности.

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

• Название «Database Availability Group» было выбрано, чтобы подчеркнуть отличие от классических кластеров — DAG фокусируется на доступности баз данных, а не серверов.
• В Exchange 2010 максимальное количество серверов в DAG составляло 16, но на практике Microsoft рекомендовала не более 8.
• В Exchange 2013 была добавлена возможность автоматического восстановления повреждённых копий баз данных (AutoReseed).
• DAG может работать без единого общего хранилища, что делает его экономически эффективным по сравнению с SAN-кластерами.

Источники

• Microsoft Docs: «Database Availability Groups» (Exchange Server 2016/2019)
• Microsoft TechNet: «Understanding Database Availability Groups»
• Книга: «Microsoft Exchange Server 2016: Inside Out» (Tony Redmond, Paul Cunningham)
• Книга: «Exchange Server 2010: Administrator's Pocket Consultant» (William R. Stanek)
• Статья: «High Availability and Site Resilience in Exchange Server» (Microsoft, 2015)