Высокая доступность Exchange: Database Availability Group (DAG)

Один почтовый сервер — это всегда единая точка отказа: упал диск, зависла служба, потребовалось обновление — и вся компания на время осталась без почты. Database Availability Group (DAG) в Exchange Server решает эту проблему, реплицируя базы данных почтовых ящиков между несколькими серверами и переключая нагрузку автоматически при сбое. Разворачиваем DAG на паре серверов srv-mail01 и srv-mail02 в домене itpages.lab.local.

Как работает DAG

DAG — это группа серверов Exchange (Mailbox-серверов), которые постоянно реплицируют между собой базы данных почтовых ящиков на уровне логов транзакций, похоже на то, как это устроено в SQL Server Always On. У каждой базы данных есть одна активная копия и одна или несколько пассивных на других серверах группы. Если активный сервер падает, Exchange автоматически активирует пассивную копию на другом сервере — пользователи ощущают это как кратковременный разрыв соединения, а не как полную недоступность почты.

Технически DAG опирается на кластерные механизмы Windows Failover Clustering, но управляется целиком через Exchange Management Shell — отдельно настраивать роль кластеризации вручную не нужно, Exchange сделает это сам при создании DAG.

Требования перед началом

Для DAG нужны минимум два сервера Exchange одной версии, роль Failover Clustering (устанавливается автоматически), отдельный статический IP-адрес для самой группы (если используется административная точка доступа с IP, что актуально для локальной сети без DHCP-кластерных объектов) и, что особенно важно, — witness-сервер: третья машина, не входящая в DAG, которая арбитрирует кворум при потере связи между узлами.

В нашей схеме в роли witness выступит контроллер домена srv-dc01 — часто так и делают в небольших инфраструктурах, хотя в идеале witness лучше размещать на отдельном не-Exchange и не-DC сервере, чтобы не смешивать роли.

Установка второго сервера srv-mail02

Устанавливаем srv-mail02 точно так же, как разворачивали srv-mail01 в предыдущей статье — тот же набор предварительных ролей Windows, та же версия дистрибутива Exchange, тот же путь для базы данных на отдельном диске.

.\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON `
  /Mode:Install /Roles:Mailbox `
  /TargetDir:"D:\Exchange" `
  /DbFilePath:"D:\ExchangeDB\MDB02\MDB02.edb" `
  /LogFolderPath:"D:\ExchangeDB\MDB02"

После установки проверяем, что оба сервера видят друг друга и входят в одну организацию Exchange:

Get-ExchangeServer | Format-Table Name, ServerRole, Edition

Создание Database Availability Group

Создаём саму группу, указывая witness-сервер и путь к папке-свидетелю на нём.

New-DatabaseAvailabilityGroup -Name "DAG-ITPages" `
  -WitnessServer "srv-dc01.itpages.lab.local" `
  -WitnessDirectory "C:\DAGWitness\DAG-ITPages" `
  -DatabaseAvailabilityGroupIpAddresses 192.168.10.20

Папка DAGWitness на srv-dc01 создаётся автоматически при первом использовании, но убедиться, что у компьютерных учётных записей srv-mail01$ и srv-mail02$ есть права на её создание, стоит заранее — иначе группа создастся, но witness останется недоступным.

Добавление серверов в DAG

Add-DatabaseAvailabilityGroupServer -Identity "DAG-ITPages" -MailboxServer "srv-mail01"
Add-DatabaseAvailabilityGroupServer -Identity "DAG-ITPages" -MailboxServer "srv-mail02"

На этом этапе Exchange автоматически устанавливает роль Failover Clustering на обоих серверах и настраивает кластерный сервис — вручную ничего в оснастке отказоустойчивого кластера трогать не нужно.

Get-DatabaseAvailabilityGroup -Identity "DAG-ITPages" -Status | Format-List Name, Servers, WitnessServer, WitnessShareInUse

Настройка сетей репликации

Для правильной работы DAG желательно разделить сеть клиентского доступа и сеть репликации баз данных — репликация логов транзакций создаёт заметный трафик, и смешивать его с трафиком MAPI/Outlook не стоит. Если на серверах есть вторая сетевая карта, настроенная в отдельной подсети (например, 10.10.10.0/24 для репликации), DAG обнаружит её автоматически, но стоит явно проверить и, при необходимости, скорректировать.

Get-DatabaseAvailabilityGroupNetwork -Identity "DAG-ITPages"
Set-DatabaseAvailabilityGroupNetwork -Identity "DAG-ITPages\ReplicationNetwork" -ReplicationEnabled $true
Set-DatabaseAvailabilityGroupNetwork -Identity "DAG-ITPages\MapiNetwork" -ReplicationEnabled $false

Добавление копии базы данных

Теперь берём существующую базу MDB01, созданную на srv-mail01, и добавляем её копию на srv-mail02.

Add-MailboxDatabaseCopy -Identity "MDB01" -MailboxServer "srv-mail02" -ActivationPreference 2

ActivationPreference задаёт порядок предпочтения при автоматическом переключении: значение 1 обычно у активной копии на исходном сервере, 2 — у следующей по приоритету при отказе. Если баз данных несколько, разумно распределять активные копии между серверами равномерно, а не держать все активными на одном — иначе при падении этого сервера резервный получит скачкообразную нагрузку сразу по всем базам.

Аналогично создаём вторую базу данных, изначально активную на srv-mail02, и реплицируем её обратно на srv-mail01 — так нагрузка в нормальном режиме распределяется между обоими серверами.

New-MailboxDatabase -Name "MDB02" -Server "srv-mail02" `
  -EdbFilePath "D:\ExchangeDB\MDB02\MDB02.edb" `
  -LogFolderPath "D:\ExchangeDB\MDB02"
Mount-Database -Identity "MDB02"
Add-MailboxDatabaseCopy -Identity "MDB02" -MailboxServer "srv-mail01" -ActivationPreference 2

Проверка статуса репликации

Get-MailboxDatabaseCopyStatus -Identity "MDB01" | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength

Статус Healthy и нулевые (или близкие к нулю) значения CopyQueueLength и ReplayQueueLength говорят о том, что репликация идёт вовремя и без задержек. Устойчиво растущая очередь — тревожный знак: либо не хватает пропускной способности сети репликации, либо на целевом сервере проблема с диском.

Тест переключения (switchover)

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

Move-ActiveMailboxDatabase -Identity "MDB01" -ActivateOnServer "srv-mail02"

Пользователи, чьи ящики лежат в MDB01, почувствуют секундный разрыв соединения Outlook, после чего клиент переподключится автоматически — это ожидаемое поведение и хороший повод убедиться, что весь процесс отлажен до наступления реального инцидента.

Сколько копий базы данных действительно нужно

Частый вопрос при планировании DAG — сколько копий каждой базы данных заводить. Microsoft рекомендует минимум три копии для инфраструктуры без традиционного резервного копирования (когда DAG сама является механизмом защиты от потери данных), и минимум две копии, если параллельно используется классический бэкап. В нашей схеме с двумя серверами srv-mail01 и srv-mail02 мы ограничены двумя копиями каждой базы — это обеспечивает защиту от отказа одного сервера, но не защищает от логической порчи данных без дополнительной лаг-копии или бэкапа.

Get-MailboxDatabase | ForEach-Object {
    $copies = (Get-MailboxDatabaseCopyStatus -Identity $_.Name).Count
    [PSCustomObject]@{ Database = $_.Name; CopyCount = $copies }
}

Если бюджет и инфраструктура позволяют добавить третий сервер в DAG, это заметно повышает устойчивость: кворум кластера легче поддерживать при нечётном числе узлов, а потеря одного сервера всё ещё оставляет две работающие копии каждой базы данных.

Отложенные копии (Lagged Copies)

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

Add-MailboxDatabaseCopy -Identity "MDB01" -MailboxServer "srv-mail02" `
  -ActivationPreference 3 -ReplayLagTime 1.00:00:00 -TruncationLagTime 1.00:00:00

Обрати внимание: лаг-копия не заменяет обычную резервную копию и не должна быть единственной дополнительной копией базы — это защита от отдельного класса проблем, дополняющая, а не подменяющая полноценный бэкап.

Резервное копирование баз данных внутри DAG

DAG сама по себе не заменяет резервное копирование — она защищает от отказа оборудования, но не от логической порчи данных, случайного удаления почтового ящика или требования регуляторов хранить архивные копии за пределами продуктивной среды. Резервное копирование в среде с DAG выполняется через VSS-совместимое решение (Windows Server Backup или сторонний продукт с плагином для Exchange), которое умеет создавать snapshot непосредственно с пассивной копии базы, не создавая лишнюю нагрузку на активную.

wbadmin start backup -backuptarget:D:\Backups -include:D:\ExchangeDB\MDB01 -vssFull -quiet

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

Datacenter Activation Coordination (DAC)

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

Set-DatabaseAvailabilityGroup -Identity "DAG-ITPages" -DatacenterActivationMode DagOnly

Обслуживание сервера в составе DAG без простоя

Одно из главных практических преимуществ DAG — возможность обновлять и перезагружать серверы по очереди, не останавливая почту целиком. Перед плановым обслуживанием srv-mail01 переводим его в режим обслуживания, что аккуратно перемещает все активные базы на srv-mail02.

Set-ServerComponentState -Identity "srv-mail01" -Component ServerWideOffline -State InActive -Requester Maintenance
Get-MailboxDatabaseCopyStatus -Server "srv-mail01"

Дожидаемся, пока команда Get-MailboxDatabaseCopyStatus покажет, что на srv-mail01 не осталось активных копий (все базы переехали на srv-mail02), после чего можно спокойно устанавливать обновления и перезагружать сервер. После завершения работ возвращаем сервер в строй в обратном порядке.

Set-ServerComponentState -Identity "srv-mail01" -Component ServerWideOffline -State Active -Requester Maintenance

Мониторинг здоровья DAG

Test-ReplicationHealth -Identity "srv-mail01"
Get-DatabaseAvailabilityGroup -Status | Select-Object -ExpandProperty PrimaryActiveManager

Test-ReplicationHealth — комплексная проверка, охватывающая состояние кластерного сервиса, кворум, сетевые подключения и реальную репликацию баз данных. Полезно включить её регулярный запуск в систему мониторинга и получать алерт при любом отклонении от Healthy по любому из проверяемых пунктов.

Частые ошибки и как их избежать

• Witness-сервер размещён на одном из серверов DAG. Witness обязан быть независимым от обоих узлов — иначе при падении именно этого сервера кворум развалится вместе с ним, и DAG не сможет определить, какая копия базы актуальна.
• Не разделены сети клиентского доступа и репликации. При большом объёме почты репликация логов транзакций конкурирует за полосу с трафиком Outlook, что приводит к задержкам доставки писем в час пик. Выделяй отдельную сеть или хотя бы VLAN для репликации.
• ActivationPreference не настроен осознанно. Если оставить значения по умолчанию без планирования, при отказе одного сервера все базы могут активироваться на другом одновременно, создавая перегрузку именно тогда, когда сервер и так работает в аварийном режиме.

Автор — Команда IT-Pages