dag exchange что это
Установка Database Availability Group в Exchange 2010
В Microsoft Exchange Server 2010 появилась новая технология обеспечения высокой доступности под названием группы высокой доступности — Database Availability Group (DAG). В этой статье мы познакомимся с тем, как работаеттехнология Database Availability Group в Exchange Server 2010, а также опишем процесс установки и настройки DAG на Exchange Server 2010 SP1 и Windows Server 2008 R2.
Обзор Database Availability Group в Exchange Server 2010
Группа высокой доступности (Database Availability Group), это группа, состоящая из нескольких серверов Exchange Server 2010 (максимальное количество серверов в группе 16), на которых установлена роль Mailbox server. Каждый из серверов-членов группы DAG способен поддерживать активную или пассивную копию почтовой базы, расположенной на других серверах группы.
Например, Database Availability Group может состоять из 3 серверов Exchange 2010, каждый их которых содержит одну почтовую базу, в этом случае любой из серверов DAG хранит активную или пассивную копию каждой из трех почтовых баз, обслуживаемых этими серверами.
Технология Database Availability Group в Exchange 2010 является развитием технологии кластеров Windows (Windows Failover Clustering). Однако, в отличии от классических кластеров Exchange, которые могут находиться в активном/пассивном состоянии, и в которых кластерная группа целиком должна переезжать на альтернативную ноду, в Exchange 2010 DAG, любая база данных может функционировать на любом сервере—члене DAG независимо от других почтовых баз.
Это означает, что любой из почтовых серверов группы DAG в любой момент временем может содержать все, некоторые или же не содержать совсем активных копий почтовых баз. Эта возможность имеет следующие преимущества перед ранее используемой кластерной моделью обеспечения отказоустойчивости:
Понятие кворума в Database Availability Group
Т.к. технология DAG основывается на технологии Windows Failover Cluster, то концепция кворума (quorum) используется и в ней. Если вы не знакомы с понятием кворума, то упрощенно – это процесс голосования, в котором для принятия того или иного решения нужно иметь большинства голосов.
Для кластера это означает, что для принятия решения в процессе голосования должно участвовать нечетное число членов. Применительно к Exchange 2010 DAG это означает, что в группе DAG из двух серверов с ролью Mailbox (или же любого другого четного числа вплоть до 16), ни один сервер не сможет на основании большинства голосов определить нужно или нет сделать текущую копию базы данных активной.
Поэтому для достижения кворума в группе DAG с четным числом серверов, в качестве еще одного из участника голосования, используют еще один сервер в этом же сайте, как файловый ресурс – свидетель (File Share Witness). Обычно эту функцию назначают на сервер с ролью Hub Transport, хотя, в принципе, это может быть любой другой сервер с ОС Windows 2008.
Репликация баз в Exchange Server 2010 DAG
Между членами группы DAG в Exchange Server 2010 репликация почтовых баз может осуществляться двумя способами.
В Exchange Server 2010 RTM используется файловая модель репликации. В этом режиме каждый транзакционный лог пишется и закрывается по достижению размера 1 Мб, после чего он копируется на каждый из членов группы DAG, содержащего копию этой базы почтовых ящиков. Члены группы DAG ставят полученный файл в очередь воспроизведения, после чего они воспроизводят действия, содержащиеся в транзакционном логе на собственной пассивной копии базы данных.
Файловый режим репликации работает неплохо, однако есть очевидный недостаток, заключающийся в том, что любые транзакционные логи, которые не будут доставлены на другие сервера группы DAG, будут потеряны, если выйдет из строя сервер с активной копией почтовой базы. В этом случае один из серверов DAG сможет сделать свою копию почтовой базы активной и затем запросить повторную отправку отсутствующих писем у сервера с ролью Hub Transport.
В Exchange Server 2010 SP1 файловая модель репликации используется для осуществления синхронизации копий почтовых баз данных между собой (например, в процессе первоначальной синхронизации, когда создается новая копия базы данных). После осуществления синхронизации члены DAG будут переключиться в режим блочной репликации (“block mode”). В блочном режиме репликации каждая транзакция записывается в буфер на активном сервере и отправляется в буфер логов на другие сервера DAG с пассивной копией базы.
Примечание. Базы общих папок (Public Folder), хотя и могут находится на почтовых серверах членах DAG, но они не будут реплицироваться механизмами репликации DAG. Для обеспечения отказоустойчивости баз данных общих папок необходимо воспользоваться функцией репликации общих папок (Public Folder replication).
Установка DAG в Exchange Server 2010
В этом разделе мы опишем процедуру настройки в Exchange 2010 Database Availability Group на Windows Server 2008 R2.
В данном руководстве мы основываемся на том, что в нашем распоряжении имеются следующие сервера Exchange.
Каждый из почтовых серверов имеет собственную почтовую базу.
Т.к. каждый почтовый сервер имеет два сетевых интерфейса, важно удостовериться, что вторичный интерфейс на регистрирует себя в DNS. Для этого откройте свойства сетевого интерфейса (TCP/IPv4), нажать кнопку Advanced, перейти на вкладку DNS и снять галку Register this connection’s address in DNS.
Создаем Database Availability Group
На почтовом сервер откроем консоль Exchange Management Console. Перейдем в раздел Organization Config->Mailbox и в правой панели выберем New Database Availability Group.
В появившемся окне мастера создания группы высокой доступности нужно указать имя группы DAG (поле name), указать сервер-свидетель (Witness server), и также указать каталог, который будет использовать сервер-свидетель.
Для создания новой группы Database Availability Group нажмем кнопку New, для окончания работы мастера нажмем кнопку Finish.
Добавляем сервера в Database Availability Group
Щелкнем правой кнопкой по только что созданной DAG и выберем пункт «Manage Database Availability Group Membership».
Нажмем кнопку Add и выберем все почтовые сервера, которые будут включены в эту группу обеспечения высокой доступности.
После нажмем кнопку Manage, в результате чего на всех добавленных серверах запустится установка и настройка службы Windows Failover Clustering, которая продлится 5-10 минут.
Настройка сети в Database Availability Group
Щелкнем правой кнопкой по только что созданной группе DAG и выберем Properties.
На вкладке IP Addresses, нужно задать статический IP адрес группу Database Availability Group.
Появится сообщение, что Database Availability Group автоматически настроит подсети для всех сетей, к которым подключены сетевые интерфейсы серверов-членов DAG.
Настраиваем копии потовых баз в DAG
После настройки Database Availability Group и ее сетей, можно добавить копии потовых баз на членах группы DAG.
В консоли Exchange Management Console перейдите в Organization Config->Mailbox и выберите вкладку Database Management. Щелкните правой кнопкой по почтовой базе и выберите Add Mailbox Database Copy.
Нажмем кнопку Browse и выберем почтовые сервера Exchange, на которых мы хотим разместить копию базы данных.
Нажмите Add и Finish.
После чего начнется создание реплики активной базы данных на выбранных серверах DAG. В зависимости от размера почтовой базы процесс репликации может занять некоторое время..
Повторите указанные действия для всех баз данных, для которых вы хотите создать пассивные копии.
Вот и все! Настройка Database Availability Group в Exchange Server 2010 Database закончена!
Создание группы доступности базы данных в Exchange Server
Группа доступности базы данных (DAG) — это набор до 16 Microsoft Exchange Server серверов почтовых ящиков, которые обеспечивают автоматическое восстановление уровня базы данных из базы данных, сервера или сбоя сети. Если почтовый сервер добавлен в группу доступности базы данных, он вместе с другими серверами в группе доступности базы данных обеспечивает автоматическое восстановление на уровне базы данных после ошибок базы данных, сервера или сети.
На всех серверах в группе обеспечения доступности баз данных должна быть установлена одна и та же версия Exchange. Вы не можете смешивать Exchange 2013 и Exchange серверов в том же DAG.
Сведения о других задачах управления, связанных с группами доступности базы данных, см. Ознакомьтесь с управлением группами доступности баз данных.
Что нужно знать перед началом работы
Предполагаемое время для завершения: 1 минута.
Сведения о том, как открыть Центр администрирования Exchange, см. в статье Центр администрирования Exchange в Exchange Server. Сведения о том, как открыть командную консоль Exchange, см. в статье Запуск командной консоли Exchange.
Запись «Группы обеспечения доступности баз данных» Для выполнения этих процедур необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в статье в разделе Разрешения высокого уровня доступности и устойчивости сайта.
При создании группы обеспечения доступности баз данных с серверов почтовых ящиков, работающих под управлением Windows Server 2012, необходимо подготовить объект имени кластера (CNO) для группы доступности базы данных, прежде чем добавлять участников. Если вы создаете DAG без точки административного доступа с серверами почтовых ящиков с Windows Server 2012 R2, то не нужно предварительно этап CNO для DAG. Подробные действия см. в предварительной стадии объекта кластерного имени для группы доступности баз данных.
При создании группы доступности базы данных необходимо указать ее уникальное имя, состоящее из не более 15 символов. Помимо предоставления имени DAG, необходимо также назначить один или несколько IP-адресов (IPv4 или IPv4 и IPv6) для DAG, если только вы не создаете DAG Windows Server 2012 R2 без точки административного доступа и не назначаете никаких IP-адресов DAG. В противном случае назначаемые IP-адреса на уровне каждой подсети должны быть предназначены для сети MAPI и быть доступны для использования. Если вы указываете один или несколько IPv4-адресов, а система настроена на использование протокола IPv6, будет предпринята попытка автоматически назначить для группы обеспечения доступности баз данных один или несколько IPv6-адресов.
При создании DAG необходимо указать сервер свидетелей и каталог свидетелей. Рекомендуется использовать сервер Exchange с службами клиентского доступа. Это дает возможность администратору Exchange располагать сведениями о доступности слежения, а также обеспечить наличие всех разрешений безопасности, необходимых для использования следящего сервера.
Доступны следующие сочетания параметров и вариантов поведения:
Пользователь может указать имя для группы доступности базы данных, для используемого следящего сервера, а также для каталога, созданного и открытого для совместного доступа на следящем сервере.
Можно указать имя для группы обеспечения доступности баз данных и используемого следящего сервера, а поле Следящий каталог оставить пустым. В этом сценарии система создаст на указанном следящем сервере следящий каталог по умолчанию.
Примечание. Если сервер свидетелей, который вы указываете, не является сервером Exchange в организации, необходимо добавить группу универсальной безопасности Exchange доверенных подсистем в локализованную группу администраторов на сервере свидетелей. Эти разрешения безопасности необходимы для создания каталога и файлового ресурса на следящем сервере в приложении Exchange. Если эти разрешения не настроены, будет возвращена следующая ошибка.
Error: An error occurred during discovery of the database availability group topology. Error: An error occurred while attempting a cluster operation. Error: Cluster API «AddClusterNode() (MaxPercentage=12) failed with 0x80070005. Error: Access is denied.»
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.
Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующим ссылкам: Exchange Server, Exchange Online или Exchange Online Protection.
Использование Центра администрирования Exchange для создания группы обеспечения доступности баз данных
В центре администрирования Exchange последовательно выберите пункты Серверы > Группы обеспечения доступности баз данных.
На странице Создание группы обеспечения доступности баз данных укажите приведенные ниже сведения о группе обеспечения доступности базы данных.
Имя группы доступности базы данных. Используйте это поле, чтобы ввести допустимое и уникальное имя для DAG до 15 символов. Имя эквивалентно имени компьютера, и с таким именем в Active Directory будет создан соответствующий CNO. Этим именем будет называться как группа обеспечения доступности базы данных, так и базовый кластер.
Сервер свидетелей. Используйте это поле, чтобы указать сервер свидетелей для DAG.
Примечание. Для сервера-свидетеля необходимо использовать либо имя хозяина, либо полное доменное имя (FQDN). Использование IP-адреса или подстановочного имени не поддерживается. Кроме того, следящий сервер не может входить в группу обеспечения доступности баз данных.
Каталог свидетелей. Используйте это поле для введите путь к каталогу на сервере свидетелей, который будет использоваться для хранения данных свидетелей. Если каталог не существует, он будет создан системой на следящем сервере. Если оставить это поле пустым, на сервере свидетелей будет создан каталог по умолчанию (%SystemDrive%\DAGFileShareWitnesses \
Нажмите кнопку Сохранить, чтобы создать группу обеспечения доступности баз данных.
Используйте Exchange для создания группы доступности баз данных
В следующем примере создается DAG с именем DAG1, который настроен на использование сервера свидетелей FILESRV1 и локального каталога C:\DAG1. DAG1 также использует протокол DHCP для IP-адресов группы.
В этом примере создается группа обеспечения доступности баз данных DAG3. В группе DAG3 используется следящий сервер MBX2 и локальный каталог C:\DAG3. Группе DAG3 присвоено несколько статических IP-адресов, так как участники группы обеспечения доступности баз данных используют различные подсети сети MAPI.
В этом примере создается группа обеспечения доступности баз данных с именем DAG5 без административной точки доступа (доступно только в группах обеспечения доступности баз данных с Windows Server 2012 R2). Кроме того, для группы обеспечения доступности баз данных в качестве следящего сервера будет использован сервер клиентского доступа MBX4; также будет создан следящий каталог по умолчанию.
Как проверить, что все получилось?
Чтобы убедиться, что группа обеспечения доступности баз данных создана успешно, выполните одно из приведенных ниже действий.
В Центре администрирования Exchange последовательно выберите пункты Серверы > Группы обеспечения доступности баз данных. Отобразится новая группа обеспечения доступности баз данных.
В командной Exchange для проверки создания DAG и отображения сведений о свойстве DAG запустите следующую команду.
Exchange 2013 – Database Availability Group (DAG)
Обеспечение отказоустойчивости – это тот вопрос, который волнует, пожалуй, всех администраторов. В этом плане, Exchange 2013 не приготовил для нас ни каких сногсшибательных сюрпризов. В данной статье мы поговорим про отказоустойчивость баз данных почтовых ящиков, в основе которой лежит хорошо зарекомендовавший себя.
Настройка Database Availability Group
Небольшая вводная для тех, кто не работал с Exchange 2010
Database Availability Group (DAG) – это технология обеспечения отказоустойчивости баз данных почтовых ящиков, которая появилась в Exchange 2010. Основана она на создании нескольких копий одной базы (см. рис.), в результате при выходе из строя одного из серверов, базы автоматически активируются на другом (в Exchange 2013, по заявлениям разработчиков, переключение занимает порядка 10 секунд).
Работа 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;
3. Далее нажимаем «+» и заполняем поля:
· Database Availability Group Name – имя будущего кластера;
· Witness Server – имя сервера, который будет выполнять роль кворума в кластере;
Важно помнить, что сервер-свидетель не может быть одним из членов кластера и в группу локальных администраторов этого сервера должна быть включена группа Exchange Trusted Subsystem.
· Witness Directory – папка на сервере-свидетеле, в которой будет лежать служебная информация (кворум). Можно даже не указывать, мастер создаст её сам (см. рис. 1);
· IP адрес будущего кластера.
Как и раньше, лучше настроить отдельно сеть под репликацию и сеть клиентского доступа, но в принципе, все может работать и через один интерфейс.
Рис. 1: Создаем DAG кластер.
4. Если все прошло удачно, то кластер будет создан и его надо будет настроить. Для этого нажмем круглую кнопку (вторую из 2-х) и добавим в кластер новых членов.
5. Добавляем в кластер сервера Mailbox, нажимаем кнопку Save и ждем, когда мастер сам все сделает.
А именно – установит службу Failover Cluster на выбранных серверах, соберет кластер, создаст объект в Active Directory и т.п.
Рис. 2: Настройка кластера мастером.
6. Если все прошло удачно :), то вам останется только добавить копии баз данных на «соседние» сервера, дождаться их заполнения и всё!, можно спать спокойно! 🙂
Для добавления копий переходим в раздел Databases, выбираем базу данных, нажимаем «кружочек», выбираем сервер на котором будет находиться копия и нажимаем Save. Стартует процесс настройки и заполнения копии базы после завершения которого вы сможете переключить активную копию на другой сервер.
Важно помнить, что копия базы располагается по тому же пути на диске, что и оригинал. Проще говоря, если у вас на первом сервере базы лежат на диске D:, то надо позаботиться о том, чтобы на втором сервере диск D: также присутствовал.
Рис. 3: Создание копий баз данных.
Чтобы ещё раз убедиться, что у вас все создалось правильно и хорошо работает можно воспользоваться командлетами:
Рис. 4: Проверка настроек кластера в EMS.
Теория
Практика показывает, что просто нажимать кнопки в консоли управления не достаточно, необходимо все же хоть немного понимать что происходит и как это работает. В связи с этим далее мы поговорим чуть подробнее про условия, которые должны быть соблюдены для того, чтобы все заработало.
Witness-server
Для начала ещё раз уясним, что работа DAG основана на компонентах службы Failover Cluster, следовательно, как и в любом Failover Cluster`e, в нем должен быть кворум. В качестве кворума в DAG используется папка на сервере-свидетеле (witness). Через эту папку узлы обмениваются между собой служебной информацией. В качестве сервера-свидетеля может выступать любой сервер, не входящий в группу DAG, версия Windows Server операционной системы не обязательно должна совпадать с версией операционной системы, используемой участниками группы доступности базы данных.
Примечание: В случае организации DAG из нечетного числа участников, сервер-свидетель не используется в работе кластера, но указать его все равно придется!
В качестве папки (Witness Directory) может выступать любая папка на сервере-свидетеле. Нужно понимать, что для успешной работы кластера все узлы должны иметь право писать в эту папку и читать из неё. Для обеспечения этой возможности вам следует в группу локальных администраторов добавить доменную группу Exchange Trusted Subsystem. (см. рис.5)
Рис. 5: Группа Exchange Trusted Subsystem.
Во время настройки кластера вы можете самостоятельно указать папку на сервере-свидетеле, в противном случае, мастер создаст её сам (см. рис. 6)
Рис. 6: Автоматически созданная папка кворума.
Что касается сети, то здесь ни чего с версии Exchange 2010 не изменилось – желательно, чтобы каждая группа доступности базы данных имела две сети:
1. сеть MAPI – используется другими серверами (другими серверами Exchange 2013, серверами каталогов и т. д.) для связи с участниками группы доступности базы данных;
2. сеть Replication – для организации репликации баз данных (доставки и заполнения журналов).
Но поддерживается работа и в одной сети (как и было настроено выше).
Если вы настроили больше одной сети в DAG, то на одной из сетей надо отключить возможность репликации. Для этого в свойствах DAG`a ставим галку «Configure database availability group network manually» и у нас появляется возможность редактировать настройки сетей.
Создать новую сеть можно нажав на первый «кружочек» сверху (см. рис.7).
Рис.7: Настройка сетей в DAG.
Имя кластера
Когда вы указываете имя кластера, мастер автоматически пытается создать объект Компьютер в Active Directory и соответствующую запись в DNS (если этого по какой-то причине не произошло, попробуйте сделать это самостоятельно). В свойствах объекта Active Directory будет храниться некоторая служебная информация настроек кластера. (см. рис. 8)
Рис. 8: Объект кластера в AD и DNS.
Убедиться, что нужные записи были созданы успешно, можно заглянув в консоль ADUC и найдя компьютер с именем кластера DAG. Также можно открыть консоль Failover Cluster на любой из нод DAG`a и заглянуть в раздел Cluster Core Resources. Все объекты там должны быть в состоянии Online!
Кроме того, для проверки состояния кластера можно запустить его тест – в консоли управления Failover Cluster нажмите ссылку Validate This Cluster… и пройдите по шагам мастера. (см. рис. 9)
Рис. 9: Проверка работоспособности кластера.
Обслуживание кластера
Очень интересный момент заключается в том, что при выхода из строя одного из серверов и после его восстановления, активная копия базы данных в Exchange 2013 автоматически возвращается на него (если конечно до падения она была активирована там), в отличие от Exchange 2010, где базу данных можно было «вернуть» только в ручном режиме.
Проведем тест – на рис. 10 мы инициируем процесс падения активной копии базы данных путем остановки её сервиса (про работу сервиса Information Store читайте здесь). Далее база автоматически активируется на второй ноде и продолжает там жить до тех пор, пока на первой ноде сервис Information Store не «поймет», что он был остановлен по ошибке (сервисы в Exchange 2013 имеют свойство восстанавливать (запускаться) самостоятельно, но об этом не в этот раз…), после чего сервис сам запустится и «запросит» себе базу обратно. В результате база вернется на «родную» ноду и все это происходит примерно за 10-15 минут!
Рис. 10: Возвращение базы данных на “родной” сервер.
Замечу, что можно настроить сервер на который в случае выхода из строя текущего будут переключены базы данных (см. рис. 11).
Из этого можно сделать вывод, что в процесс выбора лучшей копии Exchange 2010 (о котором мы говорили в статье Автоматическая активация копий базы в DAG: Best Copy Selection (BCS)) снова внесены изменения (о них поговорим как-нибудь в другой раз).
Рис. 11: Настройка приоритетного сервера для переключения баз в случае аварии.
При этом обслуживание базы данных при помощи скрипта StartDagServerMaintenance.ps1 все также поддерживается (по крайней мере этот скрипт в папке Bin присутствует). Напомню, что при помощи скрипта StartDagServerMaintenance.ps1 можно:
– перевести ноду в maintenance mode;
– перераспределить базы данных по нодам, например по параметру Activetion Preferecne.
Заключение
Как обычно, самые интересные настройки производятся через командную консоль управления (EMS), так что учите PowerShell, коллеги 🙂