Настройка round robin dns exchange
Обновлено: 03.07.2024
Балансировка нагрузки и отказоустойчивость Exchange Server
Суть в следующем: а можно ли использовать ip-адрес DAG в качестве основного адреса клиентских подключений? Ответ: можно, но не нужно.
Если говорить более развернуто, то технически использование адреса DAG вполне возможно и у вас даже все будет работать, но с практической точки зрения так лучше не делать, а почему именно, читайте дальше.
Как всегда начнем с солидной порции теории.
Как работает DAG?
На верхушке иерархии DAG находится сервер-держатель роли PAM (Primary Active Manager) 1 . Он определяет какие копии баз на каком сервере будут активными, а какие пассивными. Именно сервер с ролью PAM держит кворум кластера и он является единственным в группе обеспечения доступности.
Примечание: кстати, именно роль PAM принимает непосредственное участие в работе механизма Best Copy Selection.На всех оставшихся серверах вместо PAM выполняется роль SAM (Standby Active Manager), которая информирует другие локальные службы о том, какая база и где именно активна и, таким образом, трафик перенаправляется на соответствующие серверы.
Если сервер-держатель роли PAM вдруг отключается, его задачи перехватывает кто-то из серверов SAM и работа идет дальше.
Примечание: хочу чтобы вы знали, что с версии Exchange SP1 в сочетании с Windows Server 2012 R2 появилась возможность создавать DAG без ip-адреса. Такая конфигурация, как утверждают разработчики, значительно упрощает администрирование и уменьшает поверхность атаки для злоумышленников. Но это все теория, а нас интересует тот момент, что в этом случае Exchange уже сильно меньше завязан на роли Windows Failover Clustering и по сути предоставляет DAG как независимый от этой роли сервис. Для любителей экспериментов на всякий случай напомню, что администрирование 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 как адреса для клиентских подключений.
Как нужно делать
Примечание: хочу отметить, что поднять бесплатный балансировщик со связкой Linux + HAProxy/Nginx проще простого. Ещё проще сделать его отказоустойчивым, развернув на другом железе сервер-клон и подняв на них failover ip. Кстати, такое решение я подробно рассматривал в статье Простейший отказоустойчивый балансировщик layer 4.Как быть с балансировкой внешних подключений
Если у вас один сервер, на него идет один проброс с любого внешнего корпоративного ip. Все просто.
Если у вас два сервера, вы в силе сделать два проброса. Outlook отлично умеет работать с RR.1
Как быть с клиентами OWA
Тем не менее, с клиентами OWA вам в любом случае придется решать проблемы внешних подключений, ведь браузеры обычно не умеют работать с RR.
Примечание: если у вас будет два сервера, на каждый из которых идут пробросы с внешних адресов, то при выходе из строя одного сервера браузеры клиентов будут по очереди (в зависимости от выдачи сервера DNS) ломиться то на один адрес, то на другой. В тот момент, когда они попадут на проброс с неработающим сервером, отклика они не получат. Это вариант а. на рисунке ниже.
В этом случае, при выходе из строя одного сервера, OWA останется доступной для внешних клиентов.
Балансировка нагрузки Exchange 2016 г. и более поздней основе на платформе высокой доступности и устойчивости к сети Майкрософт, поставленной в Exchange 2013 г. Когда это сочетается с доступностью сторонних решений для балансировки нагрузки (как оборудования, так и программного обеспечения), существует несколько вариантов для реализации балансировки нагрузки в Exchange организации.
Используя минимальные роли сервера, Exchange 2016 и 2019 гг. обеспечивает:
упрощенное развертывание, так как на сервере почтовых ящиков устанавливаются службы клиентского доступа и роли пограничных транспортных серверов;
высокий уровень доступности за счет развертывания подсистем балансировки нагрузки для распределения клиентского трафика.
Роли сервера в Exchange Server
Сокращение числа ролей сервера в Exchange 2016 и Exchange 2019 упрощает Exchange и требования к оборудованию. Количество ролей сервера в Exchange 2016 и 2019 гг. сокращается с семи до двух: сервера почтовых ящиков и транспортного сервера Edge. Роль сервера почтовых ящиков включает службы клиентского доступа, в то время как edge Transport server обеспечивает безопасный поток почты в Exchange 2016 и Exchange 2019 года, как это было в предыдущих версиях Exchange.
В Exchange 2013 роль сервера клиентского доступа гарантировала, что когда пользователь пытался получить доступ к своему почтовому ящику, сервер проксировал запрос обратно на сервер почтовых ящиков, обслуживающий почтовый ящик этого пользователя. В связи с этим такие службы, как Outlook в Интернете (предыдущее название Outlook Web App), отрисовывались в самом почтовом ящике, избавляя от необходимости в сходстве.
Такие же функции сохраняются в Exchange 2016 и Exchange 2019 г. Если на двух серверах почтовых ящиков размещены разные почтовые ящики, при необходимости они могут проксировать трафик друг для друга. Сервер почтовых ящиков, на котором размещена активная копия почтового ящика, обслуживает пользователя, получающего доступ к нему, даже если этот пользователь подключается к другому серверу.
Подробнее об изменениях роли сервера в Exchange Server в статье, Exchange Server архитектуре.
| Роль сервера | Службы |
|---|---|
| Сервер почтовых ящиков | Использует службу EdgeSync для управления односторонней репликацией сведений о получении и конфигурации из Active Directory в экземпляр служб Active Directory облегченного доступа к каталогам на пограничном транспортном сервере. Копирует только сведения, необходимые для того, чтобы edge Transport выполняла антиспам и в течение всего потока электронной почты. |
| Пограничный транспортный сервер | Управляет потоком обработки почты в Интернет и из него с помощью: • ретранслятор почты • интеллектуальный хостинг • агенты, которые предоставляют дополнительные службы антиспама • агенты, которые применяют транспорт для управления потоком почты Не является элементом леса Active Directory. |
Подробнее о транспортной службе читайте в статье "Понимание транспортной службы на краю транспортных серверов".
Протоколы в Exchange Server
Параметры балансировки нагрузки в Exchange Server
В приведенном ниже примере на нескольких серверах в группе обеспечения доступности баз данных размещаются серверы почтовых ящиков, где работают службы клиентского доступа. Это обеспечивает высокий уровень доступности, а серверы Exchange занимают меньше места. Клиент подключается к подсистеме балансировки нагрузки, а не напрямую к серверам Exchange. Для пар балансиров нагрузки не существует требования, однако рекомендуется развертывать в кластерах для повышения устойчивости сети.
Помните, что группы обеспечения доступности баз данных используют службы кластеров Microsoft. Эти службы не могут быть включены на том же сервере, что и балансировка сетевой нагрузки (NLB) Windows. Следовательно, если используются группы обеспечения доступности баз данных, включить Windows NLB нельзя. В таком случае можно воспользоваться сторонними программами и решениями для виртуальных модулей.
Простота имеет цену, однако в этом случае круглая малиновка DNS не балансирует трафик по-настоящему, так как программным образом не существует способа убедиться, что каждый сервер получает справедливую долю трафика. Кроме того, отсутствует мониторинг уровня обслуживания, чтобы при сбойе одной службы клиенты не перенаправлялись автоматически в доступную службу. Например, если Outlook в Интернете находится в режиме сбоя, клиенты видят страницу ошибки.
Для балансировки нагрузки с помощью DNS при внешней публикации требуется больше внешних IP-адресов. Это означает, что каждому серверу Exchange в организации потребуется внешний IP-адрес.
Существуют более элегантные решения для балансировки нагрузки трафика, например оборудование, распределяющее клиентский трафик с помощью транспортного уровня 4 или прикладного уровня 7. Балансиры нагрузки отслеживают каждую Exchange клиентскую службу, и при сбое службы балансиры нагрузки могут направлять трафик на другой сервер и отбирать проблемный сервер в автономном режиме. Кроме того, некоторая степень балансировки нагрузки гарантирует, что ни одному из серверов почтовых ящиков не приходится проксировать большую часть операций клиентского доступа.
Для управления трафиком службы балансировки нагрузки могут использовать 4-й или 7-й уровень либо их сочетание. У каждого решения есть свои преимущества и недостатки.
Подсистемы балансировки нагрузки 4-го уровня работают на транспортном уровне, направляя трафик без проверки содержимого.
Так как эти подсистемы не проверяют содержимое трафика, передача занимает меньше времени. Однако для этого приходится идти на компромиссы. Подсистемам балансировки нагрузки 4-го уровня известны только IP-адрес, протокол и TCP-порт. Зная только один IP-адрес, подсистема балансировки нагрузки может наблюдать только за одной службой.
Преимущества балансировки нагрузки на уровне 4 включают следующие преимущества:
низкие требования к ресурсам (проверка содержимого не выполняется);
распределение трафика на транспортном уровне.
Подсистемы балансировки нагрузки 7-го уровня работают на прикладном уровне. Они могут проверять содержимое трафика и направлять его соответствующим образом.
Преимущества балансировки нагрузки на уровне 7 включают следующие преимущества:
требуется только один IP-адрес;
проверка содержимого и возможность направления трафика;
уведомления об отказе служб, которые можно переводить в автономный режим;
завершение SSL-запросов в подсистеме балансировки нагрузки;
распределение трафика на прикладном уровне и анализ целевого URL-адреса.
SSL-запросы должны завершаться в подсистеме балансировки нагрузки, которая будет центральным расположением для защиты от атак с использованием SSL.
Некоторые порты, для которых требуется балансировка нагрузки (например, для протоколов IMAP4 и POP3), могут даже не использоваться в организации Exchange.
Сценарии развертывания балансировки нагрузки в Exchange Server
Exchange 2016 г. обеспечивает значительную гибкость пространства имен и балансировки нагрузки. Учитывая разнообразие вариантов развертывания для подсистем балансировки нагрузки в организации Exchange от простого DNS до сложных сторонних решений 4-го и 7-го уровней, рекомендуем изучить их все, исходя из потребностей организации.
У описанных ниже сценариев есть свои преимущества и ограничения. Понимание их особенностей ключ к реализации решения, идеально подходящего для вашей организации Exchange.
Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7
Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7
Сценарий В. Одно пространство имен со сходством сеансов, уровень 7
Сценарий Г. Несколько пространств имен без сходства сеансов, уровень 4
Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7
С точки зрения балансира нагрузки в этом примере, состояние здоровья является на сервере, а не по протоколу для назначенного пространства имен. Администраторам придется выбирать, какой виртуальный каталог они хотят нацелить для зонда здоровья; Мы рекомендуем выбрать сильно используемый виртуальный каталог. Например, если большинство пользователей используют Outlook в Интернете, выберите виртуальный каталог Outlook в Интернете в зонде здоровья.
Пока ответ зонда Outlook в Интернете является здоровым, балансировка нагрузки сохраняет сервер почтового ящика назначения в пуле балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет сервер почтовых ящиков назначения из пула балансировки нагрузки для всех запросов, связанных с этим пространством имен. Это означает, что в случае сбой зонда здоровья все клиентские запросы для этого пространства имен направляются на другой сервер, независимо от протокола.
Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7
Мы рекомендуем эту конфигурацию для Exchange 2016 и Exchange 2019. Балансировщик нагрузки настроен для проверки состояния серверов почтовых ящиков назначения в пуле балансировки нагрузки, а в каждом виртуальном каталоге настроен зонд здоровья.
Например, пока ответ Outlook в Интернете для зонда здоровья является здоровым, балансировка нагрузки будет хранить сервер почтовых ящиков назначения в пуле Outlook в Интернете балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет целевой сервер почтовых ящиков из пула балансировки нагрузки для Outlook в Интернете запросов. В этом примере работоспособность проверяется для каждого протокола, то есть в случае неудачной проверки работоспособности только соответствующий клиентский протокол перенаправляется на другой сервер.
Сценарий В. Одно пространство имен со сходством сеансов, уровень 7
Однако отключение сходства сеансов приводит к снижению производительности и уровня использования. Это потому, что для более активного использования параметров сродства, балансировки нагрузки на основе файлов cookie или secure Sockets Layer (SSL) session-ID требуется больше обработки и ресурсов. Рекомендуется проверить у поставщика, как сродство сеансов влияет на масштабируемость для балансировки нагрузки.
Как и в предыдущем сценарии, пока ответ Outlook в Интернете для зонда здоровья является здоровым, балансировка нагрузки сохраняет сервер почтового ящика назначения в пуле Outlook в Интернете балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет целевой сервер почтовых ящиков из пула балансировки нагрузки для Outlook в Интернете запросов. В этом случае работоспособность проверяется для каждого протокола, то есть в случае неудачной проверки работоспособности только соответствующий клиентский протокол направляется на другой сервер.
Сценарий Г. Несколько пространств имен без сходства сеансов
Этот сценарий обеспечивает проверку состояния по протоколу, не требуя сложной логики балансировки нагрузки. Балансировка нагрузки использует слой 4 и не настроена для поддержания сродства сеанса. Конфигурация балансировки нагрузки проверяет состояние серверов почтовых ящиков назначения в пуле балансировки нагрузки. В этом параметре зонды здоровья настроены для целевого состояния каждого виртуального каталога, так как каждый виртуальный каталог имеет уникальное пространство имен. Так как он настроен для уровня 4, балансивчик нагрузки не знает, что к URL-адресу можно получить доступ, но результат такой, как если бы он знал. Так как состояние здоровья за протоколом, если зонд состояния не удается, на другой сервер направляется только пострадавший клиентский протокол.
Балансировка нагрузки и управляемость в Exchange Server
Наблюдение за доступными серверами и службами ключ к созданию сетей с высоким уровнем доступности. Поскольку некоторые решения для балансировки нагрузки не знают целевой URL-адрес или содержимое запроса, это может привести к сложности для Exchange зондов.
Exchange 2016 и Exchange 2019 г. включает встроенное решение мониторинга, известное как Managed Availability. Управляемое доступность, также известное как Active Monitoring или Local Active Monitoring, — это интеграция встроенных действий мониторинга и восстановления с платформой Exchange высокой доступности.
Служба управляемой доступности включает автономное отвечающее устройство. При вызове автономного отвечающего устройства соответствующий протокол (или сервер) удаляется из службы.
Чтобы почтовая инфраструктура Exchange функционировала должным образом, корректная конфигурация пространства имен является обязательным атрибутом. В этой статье рассмотрено создание DNS Split зоны, а также настройка URL адресов в веб-каталогах Exchange сервера. Вопросы планирования были рассмотрены в предыдущей статье:
Настройка DNS Split зоны
Задача Split DNS зоны в единообразном представлении сетевых имен узлов (FQDN) во внутренней и внешней сети. Другими словами, например, FQDN autodiscover.ait.in.ua будет доступен в частной и публичной сети, но разрешаться в разные IP адреса.
Чтобы ее создать, потребуется открыть консоль DNS и выбрать создание новой DNS зоны:
Консоль DNS Management
Откроется мастер создания новой DNS зоны:
Создание новой DNS Split зоны
Для DNS Split зоны не требуется дополнительные DNS сервера. Допускается ее создание на DNS серверах контроллеров домена Active Directory. Оставляем тип зоны Primary и место хранения в директории:
Выбор типа DNS Split зоны
Так как DNS зона будет хранится и реплицироваться средствами Active Directory, указываем соответствующие контроллеры домена (в переделах текущего домена или всего леса Active Directory) на которых она будет доступна:
Задание типа репликации DNS Split зоны
Указываем домен под который будет создана DNS Split зона.
Указание имени DNS Split зоны
Динамические обновления зоне не нужны, и их стоит отключить.
Динамические обновления DNS Split зоны
Работа мастера завершена:
Завершение создания DNS Split зоны
Создаем минимум 2 записи A указывающие на IP адрес Exchange сервера. Они будут следующие:
Для высокодоступной схемы Exchange без применения балансировщика сетевой нагрузки, необходимо повторить процес создания записей и для второго сервера Exchange. Это обеспечит работу Round robin DNS.
В случае применения балансировщиков сетевой нагрузки, созданные записи должны указывать на него.
Настройка веб-каталогов Exchange сервера
Доброго времени суток!
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)
Итак, если наша задача – построить отказоустойчивую почтовую систему на базе Exchange 2010, то единственным (приемлемым) вариантом будет использование DAG (Database Access Group).
Помимо DAG нам потребуются еще несколько серверов для обеспечения отказоустойчивости необходимых ролей Exchange. О них будет рассказано чуть позже.
В связи с поставленными передо мною целями я стал работать по следующей схеме (небольшое уточнение – канал между датацентром и офисом 30 Мб/с синхронный):
Напомню, что в Exchange 2010 элементами DAG-массива могут быть не только Mailbox-сервера, поэтому это сильно упрощает работу в сравнении с версией 2007.
Первое что я делаю – это выношу Edge Transport в DMZ средствами TMG и на том, и на другом сайте.
В DNS-записях для своего домена я прописываю 3 MX записи с различным приоритетом – одна указывает на TMG в Datacenter, другая на шлюз в Office, третья на резервный канал в офисе, который также заведен в TMG и настроен через ISP Redundancy (Failover). Это делает выполненным четвертый пункт из списка моих целей – свести к минимуму вероятность потерять входящую почту.
В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе. Единственным вариантом, при котором почта все-таки может не дойти, если интернет пропадет сразу и в датацентре, и в офисе (на двух каналах!) более чем на 30 минут.
Следующее — это обеспечить отказоустойчивость для клиентов, использующих Outlook 2010 во внутренней сети. Для этого требуется обеспечить отказоустойчивость роли Mailbox и Client Access.
На 2х Exchange-серверах с ролью Mailbox на разных сайтах создается 2 базы данных – одна активна на первом сайте, вторая активна на другом.
Для чего это нужно:
1) Распределение нагрузки, если все работает в штатном режиме.
2) В случае если сервер в датацентре выходит из строя/становится недоступен, в офисе у нас есть копия базы, которая автоматически перейдет в Active mode. Пользователи смогут продолжить работу.
3) Возможность проводить сервисное обслуживание серверов, переключая активные сервера «на горячую».
При создании DAG-кластера из GUI, Вам потребуется указать как минимум один сервер File Witness. Сервер File Witness (файловый свидетель), если говорить очень грубо, это сервер с расшаренной папкой, который будет поддерживать голоса в кворуме, в случае выхода из строя одного из Mailbox серверов. Он нужен для того, чтобы после того, как сервера, которые были некоторое время недоступны, станут Back-online, смогли синхронизировать (читай реплицировать) изменения с других членов кластера и при этом не «запутаться», что на них уже есть, а чего не хватает.
Я создал по одному File Witness серверу на каждом сайте (т.к. в случае падения интернета на одном из сайтов, для второй части Exchange-сервера становятся недоступны как Mailbox, так и File Witness сервера) для поддержания кворума. Но задача обеспечить отказоустойчивость клиентов Outlook еще не выполнена.
На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».
Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.
На NLB я настроил балансировку нагрузки между двумя серверами Exchange с ролью Client Access.
При этом эти сервера [прим. – Client Access] не являются серверами Mailbox! Настоятельно рекомендую Вам разносить данные роли по различным серверам/виртуальным серверам.
Так я выполнил первый пункт из списка своих целей – отказоустойчивость для клиентов Outlook во внутренней сети.
Небольшое дополнение – на NLB я настроил VIP-адреса (вся внутренняя подсеть), которые ВСЕГДА (за исключением, когда сервер недоступен) будут работать с Exchange в офисе – для уменьшения траффика в интернет и увеличения быстродействия. Только в случае, если 1 из серверов выходит из строя, клиенты переключаются на другой Client Access-сервер (между прочим это правило действует также и для мобильных устройств, которые подключаются к офисному Wi-Fi, т.к. на их DNS-запросы возвращаются IP-адреса из локальной сети). Для меня это было актуально, т.к. на втором сайте у меня клиентов нет.
Читайте также: