top
logo


Exchange 2013 Database Availability Group (DAG) PDF Печать E-mail
Автор: adm   
19.01.14 18:01

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

{jcomments on}

Последнее обновление 19.01.14 18:03
 
Интересная статья? Поделись ей с другими:

bottom

 

Unreal Commander PfSense по русски Яндекс.Метрика