Что такое dag exchange
DAG (Database Availability Group) — позволяет обеспечить отказоустойчивость Баз Данных почтовых ящиков. Суть его работы заключается в том, что создаются копии базы и при выходе из строя одного сервера база автоматически активируется на другом.
Впервые DAG появился в Exchange 2010, а в Exchange 2013 он получил некоторые улучшения.
Итак, рассмотрим схему нашей инфраструктуры. Она очень простая.
У нас есть Контроллер Домена (без него никуда) и два сервера Exchange 2013, на которых установлены обе роли Exchange – Mailbox и Client Access.
Также хочу обратить внимание, что у нас есть отдельная сеть для репликации — 172.16.0.0/24.
Итак, начинаем подготовку.
Так как работа DAG реализована на службе Microsoft Failover Cluster, нам нужен свидетель (witness). В нашем случае это будет Контроллер Домена, у вас это может быть любой рядовой сервер. На сервере-свидетеле в группу локальных администраторов нам нужно добавить группу Exchange Trusted Subsystem. (Если у Вас в роли свидетеля выступает еще один сервер Exchange, то этого делать не нужно).
Так как на Контроллере Домена локальных групп нет, то я добавляю в доменную группу Administrators.
Потом идем в Active Directory Users and Computers и создаем объект типа «Компьютер» с именем нашего будущего DAG и задисейблим его.
Потом открываем свойства этого объекта и на вкладке «Безопасность» даем права полного доступа первому члену группы DAG.
Теперь займемся сетью.
У каждого Exchange сервера по 2 сетевых адаптера. Первый смотри в общую сеть (LAN). Тут обычные настройки, дополнительно ничего делать не нужно.
Второй — в изолированную (HB), которая будет использоваться для репликации. Вот тут есть некоторые доработки.
Шлюз и DNS не указываем — они не нужны. Так же снимаем галочку Register this connection’s address in DNS.
И снимаем галочки с Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks.
Устанавливаем LAN на первое место.
Еще нужно на сервере свидетеле создать каталог, который будем указывать при создании DAG. У меня это папка DAG—Witness в корне диска C: на контроллере домена.
Теперь можно создавать DAG. Идем в консоль управления Exchange (ECP), заходим Servers => Database Availability Groups, и жмем +.
Заполняем все поля. И жмем Save.
Теперь добавляем сервера в группу
Когда мастер успешно закончит свою работу мы сможем увидеть, что членами групп являются наши два сервера, и так же есть 2 сети, одна их которых для репликации.
Это так же можно увидеть, если открыть стандартную оснастку Failover Cluster Manager и зайти в раздел Network и Nodes
Теперь можно добавлять копии БД. Заходим Servers => Database, нажимаем три точки, чтобы увидеть доп. меню и в нем выбираем Add database copy
В мастере выбираем, на какой сервер будем реплицировать. У меня выбор не большой.
Нажимаем Save и ждем окончания процесса создании копии базы.
Аналогичным способом добавляем и остальные базы.
В результате увидим следующую картину: список баз, на каком сервере база сейчас активна, и на каких серверах есть копия.
Есть еще возможность сделать копию базы с задержкой в несколько дней (от 1 до 14 дней).
При необходимости можно активировать базу на другом сервере в ручном режиме (для выполнения каких-либо плановых работ на сервере).
На этом все. Теперь админу можно спать спокойней.
Напоследок некоторые заметки:
Создание 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 тоже сойдет). Все базы будут храниться на них.
Это сделано для отказоустойчивости.
3) Создание нового DAG кластера осуществляется командой
-Name – имя DAG кластера
— WitnessServer – указывает имя сервера, который будет использоваться в качестве свидетеля кворума при четном количестве участников группы доступности. Выбранный сервер не может являться членом группы обеспечения доступности баз данных, настроенной с его использованием. Если параметрWitnessServer не указан, то будет предпринята попытка автоматического выбора в качестве следящего сервера транспортного сервера-концентратора без роли сервера почтовых ящиков, расположенного в сайте группы обеспечения доступности баз данных Служба каталогов Active Directory. Обычно используется какой-то из HCA серверов
— WitnessDirectory — указывает имя каталога на следящем сервере, который используется для хранения данных файлового ресурса-свидетеля. Каталог и файловый ресурс должны размещаться на сервере Exchange, отличном от серверов почтового ящика, которые находятся в группе доступности. Это позволяет администратору Exchange контролировать каталог. Указанный каталог не должен использоваться другими группами доступности для целей, отличных от функции следящего сервера. Если этот параметр не указан, то будет использоваться следящий каталог по умолчанию.
Создался ли кластер можно проверить командой Get-DatabaseAvailabilityGroup:
Можно увидеть, что в сети 2 кластера.
В один уже добавлено 2 сервера (он был создан ранее), во втором пока что нет добавленных серверов.
4) Далее обязательно добавить альтернативный кворум для DAG кластера. Это делается через изменения кластера:
5) Чтобы добавить сервера в кластер воспользуемся командой:
-Identity — указывает имя группы DAG, в которую добавляется сервер.
-MailboxServer — указывает имя сервера почтовых ящиков, добавляемого в группу доступности базы данных.
Для начала выберем нужный нам DAG кластер командой:
Get-DatabaseAvaialbilityGroup |?
Консоль выдаст кластер, соответствующий запросу. Соответственно можно будет не вводить параметр –Identity (обязательный).
Вводим команду добавления сервера в кластер:
И аналогично для MSK01-PT-MB02
6) Нужно создать новую базу для этого выполним команду:
Где следующие ключи:
-Name – имя базы ящиков
-EdbFilePath – путь, где она будет храниться
Сервер запросит данные, на какой сервер помещать данную базу
Выберем сервер MSK01-PT-MB01
7) На сервере создаться база, необходимо смонтировать ее.
8) Далее нужно добавить копию базы на сервер MSK01-PT-MB02, командой:
Необходимо проверить статус, введем команду:
Команда выведем все копии баз на всех серверах. И мы увидим следующее:
База MBX1 сортирована на MSK01-PT-MB01 и в статусе ожидания на сервере MSK01-PT-MB02.
9) Чтобы добавить в DAG кластер сервера из другого сайта – необходимо прописать сети этого сайта в настройках кластера командой:
Консоль запросит ввод параметра Identity – введем имя кластера DAG1T
Аналогично добавим вторую сеть:
Проверить что сети добавлены можно либо через команду:
И можно увидеть в свойствах кластера:
10) Теперь можно добавлять в DAG кластер сервера из другой подсети.
11) Далее нужно добавить копии БД на все члены DAG кластера.
Консоль запрашивает 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 кластера.
Для того чтобы сделать приоритет для активации копий баз данных, необходимо ввести следующую команду:
Режим координации активации центра обработки данных в Exchange Server
Режим координации активации центра данных DAC (Datacenter Activation Coordination) — это свойство группы доступности базы данных DAG (Database Availability Group). Режим DAC отключен по умолчанию и должен включаться для всех групп обеспечения доступности базы данных (DAG), в которых используется непрерывная репликация. Необходимо отключить режим DAC для групп DAG, использующих режим сторонней репликации, если обратное не указано сторонним поставщиком.
Режим DAC используется для управления подключением баз данных при запуске групп DAG. Это средство позволяет предотвратить разделение вычислительных мощностей на уровне баз данных при смене центра обработки данных. Разделение вычислительных мощностей — это состояние, которое приводит к тому, что база данных подключается в качестве активной копии к двум членам одной группы DAG, которые не могут связаться друг с другом. Этого можно избежать с помощью режима DAC, так как этот режим требует, чтобы члены групп DAG получали разрешение на подключение баз данных.
Например, когда основной центр обработки данных содержит двух членов группы DAG и следящий сервер, а второй центр содержит двух других членов группы DAG, группа DAG не находится в режиме DAC. Когда основной центр обработки данных теряет питание, вы активируете DAG во втором центре. Когда питание основного центра восстанавливается, члены группы DAG в основном центре обработки данных, обладающие кворумом до перебоя питания, будут запущены и подключены к базам данных. Так как основной центр обработки данных был восстановлен без сетевого подключения ко второму центру, а группа DAG не находилась в режиме DAC, в активных базах данных группы DAG произошло разделение вычислительных мощностей.
Как работает режим DAC
Режим DAC включает протокол DACP (Datacenter Activation Coordination Protocol). В режиме DAC члены группы DAG не будут автоматически подключать базы данных, даже если обладают кворумом. Вместо этого с помощью DACP определяется текущее состояние группы DAG и необходимость подключения баз данных с помощью диспетчера Active Manager.
Режим DAC можно представить как уровень приложения кворума для подключения баз данных. Чтобы понять назначение протокола DACP и принцип его работы, важно изучить основной сценарий, для работы с которым предназначен этот протокол. Рассмотрим сценарий для двух центров обработки данных, описанный выше. Предположим, что в основном центре произошел полный сбой питания. В этом случае нарушается работа всех серверов и глобальной сети, поэтому организация принимает решение активировать резервный центр обработки данных. Почти во всех таких сценариях восстановления, когда возобновляется питание основного центра обработки данных, подключение к глобальной сети обычно восстанавливается не сразу. Это означает, что члены группы DAG в основном центре подключаются к питанию, но они не могут установить связь с членами DAG в активированном резервном центре обработки данных. Основной центр обработки данных должен всегда содержать большинство участников кворума DAG, что означает: когда возобновляется питание, даже если отсутствует подключение глобальной сети к членам DAG в резервном центре обработки данных, члены DAG в основном центре имеют большинство и, как результат, кворум. Это представляет собой проблему, так как при наличии кворума эти серверы могут подключаться к своим базам данных, что будет приводить к расхождению с текущими активными базами данных, которые теперь подключены в активированном резервном центре обработки данных.
Протокол DACP был создан для решения этой проблемы. Диспетчер Active Manager хранит бит в памяти (0 либо 1), который указывает, разрешено ли группе DAG подключать локальные базы данных, которые назначены в качестве активных на сервере. Когда группа DAG работает в режиме DAC, при каждом запуске диспетчера Active Manager задается значение 0, которое означает, что ей не разрешено подключать базы данных. Так как сервер находится в режиме DAC, он должен установить связь со всеми известными ему другими участниками DAG, чтобы сообщить другому участнику DAG о том, можно ли подключать локальные базы данных, которые назначены в качестве активных. Ответ поступает в форме битового параметра для других диспетчеров Active Manager в группе DAG. Если другой сервер отвечает, что бит равен 1, то это означает, что серверам разрешено подключаться к базам данных, поэтому при запуске сервера для бита устанавливается значение 1 и подключаются его базы данных.
Но при восстановлении после сбоя питания основного центра данных, когда серверы восстанавливаются, но подключение к глобальной сети не восстановлено, все участники DAG в основном центре получают нулевое значение бита DACP; поэтому ни один из серверов, начинающих архивацию в восстановленном основном центре, не подключит базы данных, так как ни один из них не может установить связь с участником DAG, имеющим значение бита DAG, равное 1.
Режим DAC для DAG с двумя участниками
Группы DAG с двумя членами наследуют ограничения, которые предотвращают обеспечение полной защиты от синдрома разделенности на уровне приложения только битом DACP. В группах DAG только с двумя членами режим DAC также использует время загрузки следящего сервера группы для определения возможности подключения баз данных при запуске. Время загрузки следящего сервера сравнивается со временем, когда бит DACP имел значение 1.
Если время установки бита DACP предшествует времени загрузки следящего сервера, система предполагает, что член группы DAG и следящий сервер были перезагружены одновременно (возможно, из-за отключения питания основного центра обработки данных), и члену группы DAG не разрешается подключать базы данных.
Если время установки бита DACP значительно предшествует времени загрузки следящего сервера, система предполагает, что член группы DAG был перезагружен по другой причине (возможно, из-за запланированного отключения для обслуживания или в результате сбоя системы или отключения питания на сервере группы DAG), и члену группы DAG разрешается подключить базы данных.
Так как время загрузки следящего сервера используется для определения возможности подключения участником группы DAG своих активных баз данных при запуске, следящий сервер и единственного участника группы DAG нельзя перезагружать одновременно. В противном случае участник группы обеспечения доступности баз данных может остаться в состоянии, в котором он не сможет подключать базы данных при запуске. В этом случае необходимо запустить командлет Restore-DatabaseAvailabilityGroup в группе обеспечения доступности баз данных. При этом будет переустановлен бит DACP, что позволит члену группы DAG подключить базы данных.
Другие преимущества режима DAC
Помимо защиты от синдрома разделенности на уровне приложения режим DAC позволяет использовать встроенные командлеты для устойчивости сайтов для переключения центра обработки данных. например:
Выполнение переключения центра обработки данных для daGs, которые не в режиме DAC, включает использование сочетания Exchange и средств управления кластерами. Дополнительные сведения см. в переключениях Центра обработки данных.
Включение режима DAC
Режим DAC можно включить только в командной консоли Exchange. В частности, для включения режима DAC можно использовать командлет Set-DatabaseAvailabilityGroup, как это проиллюстрировано в следующем примере.
В предыдущем примере режим DAC включается для группы обеспечения доступности баз данных DAG2.
Балансировка нагрузки и отказоустойчивость Exchange Server
Ответ прост и банален — никаких. Именно поэтому в интернете встречается так много разных подходов и «лайфхаков» на этот счет и зачастую в ход идут уж очень сомнительные решения. Одно из них совсем недавно довелось обсуждать на форумах technet в интересном топике.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Балансировка нагрузки и отказоустойчивость Exchange Server
Суть в следующем: а можно ли использовать ip-адрес DAG в качестве основного адреса клиентских подключений? Ответ: можно, но не нужно.
Если говорить более развернуто, то технически использование адреса DAG вполне возможно и у вас даже все будет работать, но с практической точки зрения так лучше не делать, а почему именно, читайте дальше.
Как всегда начнем с солидной порции теории.
Как работает DAG?
На верхушке иерархии DAG находится сервер-держатель роли PAM (Primary Active Manager) 1 . Он определяет какие копии баз на каком сервере будут активными, а какие пассивными. Именно сервер с ролью PAM держит кворум кластера и он является единственным в группе обеспечения доступности.
На всех оставшихся серверах вместо PAM выполняется роль SAM (Standby Active Manager), которая информирует другие локальные службы о том, какая база и где именно активна и, таким образом, трафик перенаправляется на соответствующие серверы.
Если сервер-держатель роли PAM вдруг отключается, его задачи перехватывает кто-то из серверов SAM и работа идет дальше.
При создании кластера DAG вам нужно указать его ip-адрес и именно он будет являться единой административной точкой подключения (Administrative Access Point — AAP), к которой будет привязано сетевое имя кластера (которое полностью идентично имени самого кластера, которое вы указываете при создании DAG).
Ну и, разумеется, этот ip-адрес держит хост, на котором выполняется роль PAM. То есть, вы можете пинговать этот адрес, подключаться к нему и выполнять любые другие операции, доступные для самого обычного адреса, привязанного к серверу.
Именно этот адрес так и тянутся руки использовать в качестве точки подключения для клиентов.
Почему так делать не надо
Ну а теперь рассмотрим основные причины.
Причина №1: Распределение нагрузки
Это наиболее очевидный момент из всех. Поскольку адрес DAG может находиться только на одном сервере, то и логично предположить, что все клиентские подключения будет обслуживать единственный сервер. Все остальные эксчи, сколько бы их ни было, будут частично или полностью простаивать.
Эта ситуация не столь драматична для пары серверов в DAG, но все становится иначе, когда речь идет о четырех+ серверах (когда в архитектуру решения изначально не заложено, что всю нагрузку гипотетически способен выдержать один сервер).
Причина №2: Переключение между серверами
После переезда DAG ip на другой сервер, лавина клиентов хлынет за ним и далеко не факт, что у них не будет проблем с подключением. В этом случае даже не столь важно разные подсети у двух серверов или нет.
Причина №3: Разные подсети на серверах
Чтобы разобрать эту ситуацию, нужно пояснить один нюанс: дело в том, что часто встречаются инфраструктуры, в которых серверы Exchange размещены в разных подсетях, например разнесены между датацентрами. В таком случае сервер из подсети А не сможет назначить себе адрес из подсети сервера В (да даже если бы смог, толку от этого было бы все равно мало). Для устранения такой проблемы вы добавляете несколько адресов в объект DAG и они назначаются в зависимости от того, какой сервер держит кворум.
В итоге у вас получается постоянно меняющаяся А-запись ресурса кластера и проблемы с устаревшим кэшем клиентов.
Да, переезд ip DAG на другой сервер может быть не частым событием, но приятного вы будете испытывать мало.
Причина №4: DAG ip может уйти в offline
Есть упоминания 2 о том, что DAG может уйти в offline, но сами серверы Exchange будут работать нормально. Это поведение я не тестировал, поэтому представляю вам как есть.
Причина №5: Решение не поддерживается
Действительно, нигде в официальных мануалах вы не найдете никаких упоминаний об использовании DAG ip как адреса для клиентских подключений.
Отсюда вытекает один неприятный вывод — возиться и разгребать последствия вашего архитектурного решения придется вам самим, а окружающие смогут помочь лишь советом переделать все по-человечески и будут правы.
Как нужно делать
Суть этой статьи — рассказать как делать не нужно, но все же я не могу оставить вас на произвол судьбы и не направить на истинный путь. Поэтому сейчас коротко о best practice без углубления в технические нюансы.
Самое простое и понятное решение балансировки клиентов — использование всем известного Round Robin. Оно и работает отлично, и Outlook поддерживает из коробки.
Решение для крупных контор — платные аппаратные/программные балансировщики, желательно в отказоустойчивой конфигурации.
Как быть с балансировкой внешних подключений
Если у вас один сервер, на него идет один проброс с любого внешнего корпоративного ip. Все просто.
Если у вас два сервера, вы в силе сделать два проброса. Outlook отлично умеет работать с RR.1
Как быть с клиентами OWA
Тем не менее, с клиентами OWA вам в любом случае придется решать проблемы внешних подключений, ведь браузеры обычно не умеют работать с RR.
Единственный вариант — использование отказоустойчивого балансировщика (вариант b. на рисунке выше), о котором я упоминал выше.
В этом случае, при выходе из строя одного сервера, OWA останется доступной для внешних клиентов.