Как настроить dag exchange 2013

/AlexxHost/

Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.

четверг, 11 октября 2012 г.

Exchange 2013 — Database Availability Group (DAG), часть 1

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

ВСЕ НАПИСАННОЕ НИЖЕ ОТНОСИТСЯ К ВЕРСИИ EXCHANGE 2013 PREVIEW. К ВЫХОДУ RTM ВЕРСИИ ПРОДУКТА ВСЕ МОЖЕТ ИЗМЕНИТЬСЯ!

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

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

Database Availability Group (DAG) – это технология обеспечения отказоустойчивости баз данных почтовых ящиков, которая появилась в Exchange 2010. Основана она на создании нескольких копий одной базы (см. рис.), в результате при выходе из строя одного из серверов, базы автоматически активируются на другом (переключение занимает порядка 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;

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

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

• Database Availability Group Name – имя будущего кластера;
• Witness Server – имя сервера, который будет выполнять роль кворума в кластере;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Если по данной статье у вас ни чего не получилось сделать, также прошу прочитать вторую её часть.

Дополнительные ссылки:

Understanding Database Availability Groups —

Источник

Создание DAG кластера на серверах Mailbox Exchange

В данной статье рассматриваются сервера Exchange 2010 с ролью Mailbox (далее я буду писать mailbox сервер). Кластер DAG (Database Availability Group) строиться на серверах Exchange с данной ролью, в моем случае на данных серверах не установлены прочие роли Hub Transport, Client Access, Edge — под данные роли используются другие сервера.

Схема архитектуры следующая:

В статье рассматривается только настройка одного кластера DAG для серверов, которые располагаются в разных ЦОД (DC01 и DC02) — это необходимо для отказоустойчивости при выходе из строя одного из ЦОД (схема реализуема и в единичном DC).

1) На всех mailbox серверах необходимо подключить дополнительные сетевые диски, желательно по ISCSI (FC тоже сойдет). Все базы будут храниться на них.
Это сделано для отказоустойчивости.

2) Необходимо зайти на mailbox сервер и запустить Exchange management console из под Администратора (Run as . ).

3) Создание нового DAG кластера осуществляется командой

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MSK02-PT-HCA01 -WitnessDirectory E:\DAG1

Где используются следующие параметры:

-Name – имя DAG кластера
— WitnessServer – указывает имя сервера, который будет использоваться в качестве свидетеля кворума при четном количестве участников группы доступности. Выбранный сервер не может являться членом группы обеспечения доступности баз данных, настроенной с его использованием. Если параметрWitnessServer не указан, то будет предпринята попытка автоматического выбора в качестве следящего сервера транспортного сервера-концентратора без роли сервера почтовых ящиков, расположенного в сайте группы обеспечения доступности баз данных Служба каталогов Active Directory. Обычно используется какой-то из HCA серверов
— WitnessDirectory — указывает имя каталога на следящем сервере, который используется для хранения данных файлового ресурса-свидетеля. Каталог и файловый ресурс должны размещаться на сервере Exchange, отличном от серверов почтового ящика, которые находятся в группе доступности. Это позволяет администратору Exchange контролировать каталог. Указанный каталог не должен использоваться другими группами доступности для целей, отличных от функции следящего сервера. Если этот параметр не указан, то будет использоваться следящий каталог по умолчанию.

Создался ли кластер можно проверить командой Get-DatabaseAvailabilityGroup:

Можно увидеть, что в сети 2 кластера.
В один уже добавлено 2 сервера (он был создан ранее), во втором пока что нет добавленных серверов.

4) Далее обязательно добавить альтернативный кворум для DAG кластера. Это делается через изменения кластера:

Set-DatabaseAvailabilityGroup -Identity DAG1T -AlternateWitnessServer MSK01-PT-HCA01 -AlternateWitnessDirectory C:\DAG1W

Соответственно создастся альтернативный кворум (если основной будет недоступен) на сервере MSK01-PT-HCA01 в другом сайте.

5) Чтобы добавить сервера в кластер воспользуемся командой:

Add-DatabaseAvailabilityGroupServer -Identity DAG1T -MailboxServer MSK01-PT-MB01

Где используются ключи:

-Identity — указывает имя группы DAG, в которую добавляется сервер.
-MailboxServer — указывает имя сервера почтовых ящиков, добавляемого в группу доступности базы данных.
Для начала выберем нужный нам DAG кластер командой:
Get-DatabaseAvaialbilityGroup |?

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

Вводим команду добавления сервера в кластер:

Get-DatabaseAvailabilityGroup |? <$_.name -like "*DAG1T*">| Add-DatabaseAvailabilityGroupServer -MailboxServer MSK01-PT-MB01

И аналогично для MSK01-PT-MB02

Get-DatabaseAvailabilityGroup |? <$_.name -like "*DAG1T*">| Add-DatabaseAvailabilityGroupServer -MailboxServer MSK01-PT-MB02

6) Нужно создать новую базу для этого выполним команду:

New-MailboxDatabase -Name «MBX1» -EdbFilePath E:\DatabaseFiles\MBX1.edb

Где следующие ключи:

-Name – имя базы ящиков
-EdbFilePath – путь, где она будет храниться
Сервер запросит данные, на какой сервер помещать данную базу

Выберем сервер MSK01-PT-MB01

7) На сервере создаться база, необходимо смонтировать ее.

8) Далее нужно добавить копию базы на сервер MSK01-PT-MB02, командой:

Add-MailboxDatabaseCopy -Identity MBX1 -MailboxServer MSK01-PT-MB02

Необходимо проверить статус, введем команду:

Команда выведем все копии баз на всех серверах. И мы увидим следующее:

База MBX1 сортирована на MSK01-PT-MB01 и в статусе ожидания на сервере MSK01-PT-MB02.

9) Чтобы добавить в DAG кластер сервера из другого сайта – необходимо прописать сети этого сайта в настройках кластера командой:

Set-DatabaseAvailabilityGroupNetwork -Subnets 10.103.103.0/24 -ReplicationEnabled:$true

Консоль запросит ввод параметра Identity – введем имя кластера DAG1T
Аналогично добавим вторую сеть:

Set-DatabaseAvailabilityGroupNetwork -Subnets 192.168.22.0/24 -ReplicationEnabled:$true

Проверить что сети добавлены можно либо через команду:

И можно увидеть в свойствах кластера:

10) Теперь можно добавлять в DAG кластер сервера из другой подсети.

Add-DatabaseAvailabilityGroupServer -MailboxServer MSK02-PT-MB03
Add-DatabaseAvailabilityGroupServer -MailboxServer MSK02-PT-MB04

11) Далее нужно добавить копии БД на все члены DAG кластера.

Add-MailboxDatabaseCopy -MailboxServer MSK02-PT-MB04

Консоль запрашивает Identity – вводим соответствующую базу (в нашем случае MBX1) – потом аналогично с MBX2).

12) В итоге на всех серверах должно быть следующее:

MSK01-PT-MBX01 – смонтирована MBX1 и ожидание MBX2
MSK01-PT-MBX02 – ожидание MBX1 и ожидание MBX2
MSK02-PT-MBX03 – ожидание MBX1 и смонтирована MBX2
MSK02-PT-MBX04 – ожидание MBX1 и ожидание MBX2

Т.е. имеем 1 активную копию на каждом из серверов в разных ЦОД.

13) Приоритезация DAG кластера.

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

Set-MailboxDatabaseCopy -Identity MBX1\MSK01-PT-MB01 -ActivationPreference 1

Где указываются 2 параметра: 1) имя базы\имя сервера 2) стоимость, где 1 – самое высокое значение

Источник

Группы обеспечения доступности баз данных

Применяется к: Exchange Server 2013 г.

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

Группа обеспечения доступности баз данных (DAG) — это основной компонент обеспечения высокого уровня доступности сервера почтовых ящиков и устойчивости сайта, встроенный в Microsoft Exchange Server 2013. Группа обеспечения доступности баз данных — это группа серверов почтовых ящиков (до 16 серверов), которая содержит набор баз данных и обеспечивает автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные серверы и базы данных.

Группа обеспечения доступности баз данных — единый объект для репликации базы данных почтовых ящиков, переключений базы данных и сервера, отработок отказа и внутреннего компонента, который называется Active Manager. Active Manager работает на каждом сервере почтовых ящиков, управляя переключениями и отработкой отказов в группах обеспечения доступности баз данных. Дополнительные сведения о компоненте Active Manager см. в разделе Active Manager.

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

Жизненный цикл группы обеспечения доступности баз данных

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

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

Группа обеспечения доступности баз данных создается с помощью командлета New-DatabaseAvailabilityGroup. Изначально группа обеспечения доступности баз данных создается как пустой объект в Active Directory. Этот объект каталога используется для хранения необходимых сведений о группе обеспечения доступности баз данных, например сведений о членстве сервера и некоторых параметров конфигурации групп обеспечения доступности баз данных. При добавлении первого сервера в группу доступности баз данных для нее автоматически создается отказоустойчивый кластер. Этот отказоустойчивый кластер используется исключительно для группы обеспечения доступности баз данных; кластер должен быть выделен для этой группы. Поддержка этого кластера для любых других целей не поддерживается.

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

При создании каждая группа обеспечения доступности баз данных получает уникальное имя, а также один или несколько статических IP-адресов, настраивается для использования протокола DHCP или создается без точки административного доступа кластера. Группы обеспечения доступности баз данных без точки административного доступа кластера можно создать на серверах, на которых используется Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии под управлением Windows Server 2012 R2 Standard или Datacenter Edition. Группы обеспечения доступности баз данных без точки административного доступа кластера обладают следующими характеристиками:

кластеру или группе обеспечения доступности баз данных не назначается IP-адрес, поэтому в группе основных ресурсов кластера отсутствует ресурс «IP-адрес»;

кластеру не назначается сетевое имя, поэтому в группе основных ресурсов кластера отсутствует ресурс «Сетевое имя»;

имя кластера/группы обеспечения доступности баз данных не зарегистрировано в DNS, оно неразрешимо в сети;

в Active Directory не создается объект имени кластера (CNO);

управлять кластером с помощью средства управления отказоустойчивым кластером нельзя. Управлять им нужно с помощью Windows PowerShell, а командлеты Windows PowerShell должны выполняться в отношении отдельных элементов кластера;

В этом примере показано, как использовать командную консоль для создания группы обеспечения доступности баз данных с точкой административного доступа кластера, которая будет иметь три сервера. Два сервера (EX1 и EX2) находятся в одной подсети (10.0.0.0), а третий сервер (EX3) расположен в другой подсети (192.168.0.0).

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

При добавлении сервера EX1 в группу обеспечения доступности баз данных создается кластер для группы DAG1. В ходе создания кластера командлет Add-DatabaseAvailabilityGroupServer получает IP-адреса, настроенные для серверов группы обеспечения доступности баз данных, и игнорирует те из них, которые не соответствуют ни одной подсети, указанной на сервере EX1. В первом примере выше для группы DAG1 создается кластер с IP-адресом 10.0.0.5, а адрес 192.168.0.5 — игнорируется. Во втором примере выше значение параметра DatabaseAvailabilityGroupIPAddresses вызывает задачу создания отказоустойчивого кластера для группы обеспечения доступности баз данных, у которой нет административной точки доступа. Таким образом, в группе основных ресурсов кластера создается кластер с ресурсом «IP-адрес» или «Сетевое имя».

Затем добавляется сервер EX2 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. IP-адреса кластера не изменяются, поскольку серверы EX2 и EX1 находятся в одной подсети.

Затем добавляется сервер EX3 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. Поскольку на сервере EX3 присутствует подсеть, соответствующая IP-адресу 192.168.0.5, IP-адрес 192.168.0.5 добавляется в качестве ресурса IP-адреса в кластерной группе. Дополнительно для каждого ресурса IP-адреса автоматически настраивается зависимость OR для ресурса сетевого имени. При перемещении группы основных ресурсов кластера на сервер EX3 кластер будет использовать адрес 192.168.0.5.

При переводе ресурса сетевого имени в оперативный режим средство отказоустойчивости кластеров Windows регистрирует IP-адреса кластера в службе DNS для групп обеспечения доступности баз данных с точками административного доступа кластера. Кроме того, когда к кластеру добавляется EX1, в Active Directory создается объект имени кластера (CNO). Для функций DAG сетевое имя, IP-адрес (IP-адреса) и CNO кластера не используются. Администраторам и конечным пользователям нет необходимости обращаться или подключаться к кластеру/имени группы обеспечения доступности баз данных или IP-адресу. Некоторые сторонние приложения подключаются к точке административного доступа кластера для выполнения задач управления, таких как резервное копирование или мониторинг. Если вы не используете сторонние приложения, которые требуют точки административного доступа кластера, и ваш DAG работает Exchange 2013 sp1 или более поздней Windows Server 2012 R2, то мы рекомендуем создать DAG без точки административного доступа. Такой подход упрощает настройку DAG, устраняет необходимость в одном или нескольких IP-адресах и сокращает площадь атаки DAG.

Группы обеспечения доступа к базам данных также настраиваются для использования следящего сервера и следящего каталога. Следящий сервер и следящий каталог либо автоматически настраиваются системой, либо настраиваются администратором вручную. В приведенных выше примерах выполняется настройка EX4 (сервера, который не входит и не будет входить в DAG) в качестве следящего сервера DAG.

По умолчанию группа обеспечения доступности баз данных предназначена для использования встроенной функции непрерывной репликации для репликации баз данных почтовых ящиков между серверами в группе обеспечения доступности баз данных. Если в Exchange 2013 г. используется репликация сторонних данных, поддерживающая API репликации третьих сторон, необходимо создать DAG в режиме репликации сторонних пользователей с помощью комлета New-DatabaseAvailabilityGroup с параметром ThirdPartyReplication. После включения этот режим нельзя отключить.

После создания группы обеспечения доступности баз данных можно добавить серверы почтовых ящиков. После добавления в группу обеспечения доступности баз данных первого сервера для группы создается кластер. Группы обеспечения доступности баз данных используют функции, предоставляемые технологией отказоустойчивой кластеризации Windows: пульс кластера, сети кластера и база данных кластера (для хранения изменяющихся данных, например изменений состояния базы данных с активного на пассивное или наоборот либо с подключенного состояния на отключенное и наоборот). По мере добавления в группу обеспечения доступности баз данных серверы присоединяются к базовому кластеру, система Exchange автоматически настраивает модель кворума кластера, и серверы добавляются в объект группы обеспечения доступности баз данных в Active Directory.

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

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

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

Модели кворума группы обеспечения доступности баз данных

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

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

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

Действуя в качестве тай-брейка: ресурс свидетеля кворума используется в DAG с 10-м числом участников, чтобы избежать сценариев синдрома синдрома разделенного мозга и убедиться, что только одна коллекция участников в DAG считается официальной. Если для кворума нужен сервер-свидетель, любой член группы обеспечения доступности может связаться с сервером-свидетелем и поместить блокировку SMB на файл witness.log этого сервера. Член группы обеспечения доступности, который блокирует сервер-свидетель (называется блокирующим узлом) сохраняет дополнительный голос для кворума. Члены группы обеспечения доступности баз данных, поддерживающие связь с блокирующим узлом, представляют собой большинство и тем самым поддерживают кворум. Любые члены группы обеспечения доступности баз данных, которые не могут связаться с блокирующим узлом, являются меньшинством и теряют кворум.

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

Группы доступности баз данных с четным количеством членом используют режим кворума большинства узлов и общих файловых ресурсов, в котором разрешением конфликтов занимается внешний сервер-свидетель. В этом режиме кворума каждый член группы обеспечения доступности баз данных получает один голос. Кроме того, используется следящий сервер для предоставления одному члену группы взвешенный голос (то есть он получает два голоса вместо одного). Данные кворума кластера сохраняются по умолчанию на системном диске каждого члена группы обеспечения доступности баз данных и поддерживается в согласованном состоянии на всех дисках. Однако копия данных кворума не сохраняется на следящем сервере. Файл на следящем сервере используется для отслеживания того, какой член имеет наиболее обновленную копию данных, но сам следящий сервер не имеет копию данных кворума кластера. В этом режиме большинство голосующих членов (члены группы обеспечения доступности и сервер-свидетель) должны находиться в рабочем состоянии и поддерживать связь друг с другом для обеспечения кворума. Если большинство голосующих не может связаться друг с другом, кластер группы обеспечения доступности теряет кворум и группа обеспечения доступности баз данных будет нуждаться во вмешательстве администратора, чтобы снова стать работоспособной.

Группы обеспечения доступности баз данных с нечетных количеством членов используют режим кворума большинства узлов. В этом режиме каждый член получает голос, локальный системный диск каждого члена используется для хранения данных кворума кластера. При изменении конфигурации группы обеспечения доступности это изменение отражается на всех дисках. Изменение считается вступившим в силу и согласованным, если был внесено на дисках половины членов (с округлением в сторону понижения) плюс один. Например, в группе обеспечения доступности баз данных с пятью членами изменение должно быть внесено на двух членах плюс один, то есть на трех членах.

Кворум собирается большинством голосующих членов, которые могут поддерживать связь друг с другом. Рассмотрим группу обеспечения доступности баз данных, состоящую из четырех членов. Так как эта группа имеет четное количество членов, внешний следящий сервер используется для предоставления одному из членов кластера пятого голоса для разрешения конфликтов. Чтобы обеспечить большинство голосующих (и, следовательно, наличие кворума), хотя бы три голосующих члена должны поддерживать связь друг с другом. В любое время не более двух голосующих члена может находиться в автономном режиме, не влияя на работу службы и доступа к данным. Если три и более голосующих члена находятся в автономном режиме, группа обеспечения доступности баз данных теряет кворум, служба и данные перестают быть доступными до устранения проблемы.

Использование группы обеспечения доступности баз данных для обеспечения высокого уровня доступности

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

Группа обеспечения доступности баз данных с пятью членами

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

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

Изначально все базы данных и серверы находятся в работоспособном состоянии. Необходимо установить определенные обновления операционной системы на EX2, поэтому переведите сервер в режим обслуживания. Это вызовет переключение сервера, в результате которого копия базы данных DB4 будет активирована на другом сервере почтовых ящиков. Переключение сервера служит для перемещения всех активных копий базы данных почтовых ящиков с текущего сервера на один или несколько других серверов почтовых ящиков в группе обеспечения доступности баз данных, чтобы подготовить текущий сервер к запланированному отключению. В этом примере активной является только одна база данных почтовых ящиков на сервере EX2 (DB4), поэтому перемещается только одна копия базы данных почтовых ящиков.

Группа обеспечения доступности баз данных с сервером, переведенным в автономный режим для обслуживания

При выполнении обслуживание сервера EX2 на сервере EX3 происходит аппаратный сбой и сервер переходит в автономный режим. До перехода в автономный режим на сервере EX3 размещалась активная копия базы данных DB2. Чтобы восстановить сервер после сбоя, система автоматически активирует копию базы данных DB2, размещенную на сервере EX1, в течение 30 сек. Это процесс показан на следующем рисунке.

Группа доступности базы данных с сервером в автономном режиме для обслуживания и неисправным сервером

После завершения запланированного обслуживания для EX2 переведите сервер из режима обслуживания в оперативный режим. После запуска сервера EX2 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB1, DB4 и DB5, размещенные на сервере EX2, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.

Группа обеспечения доступности баз данных с восстановленным сервером, синхронизирующим копии баз данных

После сбоя на сервере EX3 аппаратный компонент был заменен на новый, а сервер EX3 переведен в оперативный режим. После запуска сервера EX3 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB2, DB3 и DB4, размещенные на сервере EX3, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.

Группа обеспечения доступности баз данных с исправленным сервером, синхронизирующим копии баз данных

Использование группы обеспечения доступности баз данных для обеспечения устойчивости сайта

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

Группа обеспечения доступности базы данных, расширенная на два сайта Active Directory

В этом примере пассивная копия каждой активной базы данных в центре данных Редмонда хранится на сервере EX6 в центре данных Дублина. Однако существует множество других примеров конфигураций групп обеспечения доступности баз данных, обеспечивающих отказоустойчивость на уровне сайта. Например:

Вместо размещения только пассивных копий баз данных сервер EX6 может содержать все активные копии или сочетание активных и пассивных копий.

В дополнение к серверу EX6 несколько членов группы обеспечения доступности баз данных могут быть развернуты в центре данных Дублина, что обеспечит защиту от дополнительных сбоев. Подобная конфигурация также обеспечивает дополнительные ресурсы, так что если в центре данных Редмонда произойдет неполадка, центр данных в Дублине сможет обслуживать большее количество пользователей.

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

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

В предыдущем примере большинство голосующих членов размещено в центре данных Редмонда. Если центр данных в Дублине содержит активные базы данных почтовых ящиков и поддерживает собственных пользователей, неполадки с подключением WAN может привести к перебою в службе обмена сообщениями для пользователей центра данных в Дублине. При разрыве подключения WAN только члены группы обеспечения доступности баз данных в центре данных Редмонда сохраняют кворум и продолжают предоставлять службу обмена сообщениями.

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

Источник