Главная Exchange/UC Exchange 2013 — Database Availability Group (DAG)
  • Exchange 2013 — Database Availability Group (DAG)

    clip_image001Обеспечение отказоустойчивости – это тот вопрос, который волнует, пожалуй, всех администраторов. В этом плане, Exchange 2013 не приготовил для нас ни каких сногсшибательных сюрпризов. В данной статье мы поговорим про отказоустойчивость баз данных почтовых ящиков, в основе которой лежит хорошо зарекомендовавший себя.

     

    Настройка Database Availability Group

    Небольшая вводная для тех, кто не работал с Exchange 2010

    Database Availability Group (DAG) – это технология обеспечения отказоустойчивости баз данных почтовых ящиков, которая появилась в Exchange 2010. Основана она на создании нескольких копий одной базы (см. рис.), в результате при выходе из строя одного из серверов, базы автоматически активируются на другом (в Exchange 2013, по заявлениям разработчиков, переключение занимает порядка 10 секунд).

    clip_image002

    Работа DAG базируется на службе Microsoft Failover Cluster, в результате чего в кластер DAG может быть добавлено до 16 серверов с ролью Mailbox, при этом каждый сервер может нести на себе лишь одну копию конкретной базы данных (т.е. вы можете создать до 16 копий каждой базы). Создать DAG можно на любой версии сервера Exchange 2010 / 2013 (Standard / Enterprise), но в силу необходимости установки службы Failover Cluster, вы можете использовать только Windows Server 2008 R2 Enterprise либо любой Windows Server 2012.

    Настройка DAG в Exchange 2013

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

    1. Установить 2 и более серверов с ролью Mailbox;

    2. Зайти в консоль управления (ЕАС), перейти в раздел Servers -> Database Availability Group;

    3. Далее нажимаем «+» и заполняем поля:

    · Database Availability Group Name – имя будущего кластера;

    · Witness Server – имя сервера, который будет выполнять роль кворума в кластере;

    Важно помнить, что сервер-свидетель не может быть одним из членов кластера и в группу локальных администраторов этого сервера должна быть включена группа Exchange Trusted Subsystem.

    · Witness Directory – папка на сервере-свидетеле, в которой будет лежать служебная информация (кворум). Можно даже не указывать, мастер создаст её сам (см. рис. 1);

    · IP адрес будущего кластера.

    Как и раньше, лучше настроить отдельно сеть под репликацию и сеть клиентского доступа, но в принципе, все может работать и через один интерфейс.

    clip_image003

    Рис. 1: Создаем DAG кластер.

    4. Если все прошло удачно, то кластер будет создан и его надо будет настроить. Для этого нажмем круглую кнопку (вторую из 2-х) и добавим в кластер новых членов.

    clip_image004

    5. Добавляем в кластер сервера Mailbox, нажимаем кнопку Save и ждем, когда мастер сам все сделает.

    А именно – установит службу Failover Cluster на выбранных серверах, соберет кластер, создаст объект в Active Directory и т.п.

    clip_image005

    Рис. 2: Настройка кластера мастером.

    6. Если все прошло удачно :), то вам останется только добавить копии баз данных на «соседние» сервера, дождаться их заполнения и всё!, можно спать спокойно! 🙂

    Для добавления копий переходим в раздел Databases, выбираем базу данных, нажимаем «кружочек», выбираем сервер на котором будет находиться копия и нажимаем Save. Стартует процесс настройки и заполнения копии базы после завершения которого вы сможете переключить активную копию на другой сервер.

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

    clip_image006

    Рис. 3: Создание копий баз данных.

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

    Get-DatabaseAvaliabilityGroup DAG01

    Get-MailboxDatabaseCopyStatus MDB2

    clip_image007

    Рис. 4: Проверка настроек кластера в EMS.

    Теория

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

    Witness-server

    Для начала ещё раз уясним, что работа DAG основана на компонентах службы Failover Cluster, следовательно, как и в любом Failover Cluster`e, в нем должен быть кворум. В качестве кворума в DAG используется папка на сервере-свидетеле (witness). Через эту папку узлы обмениваются между собой служебной информацией. В качестве сервера-свидетеля может выступать любой сервер, не входящий в группу DAG, версия Windows Server операционной системы не обязательно должна совпадать с версией операционной системы, используемой участниками группы доступности базы данных.

    Примечание: В случае организации DAG из нечетного числа участников, сервер-свидетель не используется в работе кластера, но указать его все равно придется!

    В качестве папки (Witness Directory) может выступать любая папка на сервере-свидетеле. Нужно понимать, что для успешной работы кластера все узлы должны иметь право писать в эту папку и читать из неё. Для обеспечения этой возможности вам следует в группу локальных администраторов добавить доменную группу Exchange Trusted Subsystem. (см. рис.5)

    clip_image008

    Рис. 5: Группа Exchange Trusted Subsystem.

    Во время настройки кластера вы можете самостоятельно указать папку на сервере-свидетеле, в противном случае, мастер создаст её сам (см. рис. 6)

    clip_image009

    Рис. 6: Автоматически созданная папка кворума.

    Сеть

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

    1. сеть MAPI - используется другими серверами (другими серверами Exchange 2013, серверами каталогов и т. д.) для связи с участниками группы доступности базы данных;

    2. сеть Replication - для организации репликации баз данных (доставки и заполнения журналов).

    Но поддерживается работа и в одной сети (как и было настроено выше).

    Если вы настроили больше одной сети в DAG, то на одной из сетей надо отключить возможность репликации. Для этого в свойствах DAG`a ставим галку «Configure database availability group network manually» и у нас появляется возможность редактировать настройки сетей.

    Создать новую сеть можно нажав на первый «кружочек» сверху (см. рис.7).

    clip_image010

    Рис.7: Настройка сетей в DAG.

    Имя кластера

    Когда вы указываете имя кластера, мастер автоматически пытается создать объект Компьютер в Active Directory и соответствующую запись в DNS (если этого по какой-то причине не произошло, попробуйте сделать это самостоятельно). В свойствах объекта Active Directory будет храниться некоторая служебная информация настроек кластера. (см. рис. 8)

    clip_image011

    Рис. 8: Объект кластера в AD и DNS.

    Убедиться, что нужные записи были созданы успешно, можно заглянув в консоль ADUC и найдя компьютер с именем кластера DAG. Также можно открыть консоль Failover Cluster на любой из нод DAG`a и заглянуть в раздел Cluster Core Resources. Все объекты там должны быть в состоянии Online!

    Кроме того, для проверки состояния кластера можно запустить его тест – в консоли управления Failover Cluster нажмите ссылку Validate This Cluster… и пройдите по шагам мастера. (см. рис. 9)

    clip_image012

    Рис. 9: Проверка работоспособности кластера.

    Обслуживание кластера

    Очень интересный момент заключается в том, что при выхода из строя одного из серверов и после его восстановления, активная копия базы данных в Exchange 2013 автоматически возвращается на него (если конечно до падения она была активирована там), в отличие от Exchange 2010, где базу данных можно было «вернуть» только в ручном режиме.

    Проведем тест - на рис. 10 мы инициируем процесс падения активной копии базы данных путем остановки её сервиса (про работу сервиса Information Store читайте здесь). Далее база автоматически активируется на второй ноде и продолжает там жить до тех пор, пока на первой ноде сервис Information Store не «поймет», что он был остановлен по ошибке (сервисы в Exchange 2013 имеют свойство восстанавливать (запускаться) самостоятельно, но об этом не в этот раз…), после чего сервис сам запустится и «запросит» себе базу обратно. В результате база вернется на «родную» ноду и все это происходит примерно за 10-15 минут!

    clip_image013

    Рис. 10: Возвращение базы данных на “родной” сервер.

    Замечу, что можно настроить сервер на который в случае выхода из строя текущего будут переключены базы данных (см. рис. 11).

    Из этого можно сделать вывод, что в процесс выбора лучшей копии Exchange 2010 (о котором мы говорили в статье Автоматическая активация копий базы в DAG: Best Copy Selection (BCS)) снова внесены изменения (о них поговорим как-нибудь в другой раз).

    clip_image014

    Рис. 11: Настройка приоритетного сервера для переключения баз в случае аварии.

    При этом обслуживание базы данных при помощи скрипта StartDagServerMaintenance.ps1 все также поддерживается (по крайней мере этот скрипт в папке Bin присутствует). Напомню, что при помощи скрипта StartDagServerMaintenance.ps1 можно:

    — перевести ноду в maintenance mode;

    — перераспределить базы данных по нодам, например по параметру Activetion Preferecne.

     

    Заключение

    Как обычно, самые интересные настройки производятся через командную консоль управления (EMS), так что учите PowerShell, коллеги 🙂

    Алексей Богомолов,

    Microsoft MVP: Exchange

    http://alexxhost.ru

    • Рубрика: Exchange/UC
    • Автор: Alexx
    • Дата: Среда 17 Окт 2012

Комментарии

  1. Парни, как всегда спасибо!!! Параллельно ещё десять статей читаю по этой теме, но более доходчиво тут, и есть моменты которые в остальных статьях нормально не разъясняются.

  2. А как себе будут вести почтовые сервера если кворум «улетит» ?

  3. Если в кластере теряется кворум, базы отмонтируются. Если потерян свидетель, а сервера доступны, все будет работать.

  4. Было бы здорово обновить статью в варианте создания no-ip DAG.

  5. Спасибо за статью!

    От себя добавлю:

    У меня автоматически не отработал мастер создания кластера.

    Как выяснилось, если учетные записи почтовых серверов находятся в контейнере не по умолчанию (в том же контейнере мастер добавляет учетную запись кластера), мастер вылетает с ошибками.

    Для того, чтобы пропинать его до конца, пришлось вручную сделать следующие шаги:

    1. Отключить созданную учетную запись кластера.

    2. В настройках безопасности учетной записи кластера добавить полные права доступа группе Exchange Trusted Subsystem.

    3. Подправить атрибут dNSHostName учетной записи кластера.

    Только после этого мастер завершает установку кластера и добавление в него нодов.

  6. Как именно подправить атрибут?

  7. В каких ситуациях необходимо создавать 2 и более DAG кластера?

  8. Приветсвую!

    Не пойму как определить активную базу если все базы на всех членах группы размонтированы по причине отсутствия дискового пространства?

  9. Добрый день!

    Буду рад, если поможете. Есть один сервер с Exchange 2016. Почта ходит, все ок, но нужно для высокой доступности настроить DAG. Для этого поднимаю ещё один сервер, устанавливаю exchange 2016 и что дальше? Нужно ли мне настраивать второй сервер аналогично первому? В смысле: заказывать сертификат у сервера сертификации, настраивать коннекторы, базы данных и прочее. Или все настройки автоматом «подтянуться» при создании DAG мастером? Заранее благодарю за помощь.

  10. Ваш комментарий

Опубликовать

Я не робот.