Планирование, развертывание и тестирование решения устойчивости сайта Exchange 2010 Site-Resilient Solution для средних организаций (часть 8)

В предыдущей части этого цикла статей мы добавили 4 Exchange 2010 сервера с несколькими ролями в созданную группу DAG. После добавления участников в группу DAG мы свернули сети DAG, включили координацию доступности баз данных (DAC) и перераспределили активные копии баз данных между двумя серверами с несколькими ролями Exchange 2010, расположенными в основном центре данных.

В этой части мы завершим настройку наших четырех серверов Exchange 2010 с несколькими ролями. Если говорить точнее, мы настроим роль транспортного сервера-концентратора (Hub Transport) для получения избыточности.

Балансировка нагрузки и отказоустойчивость Hub Transport Server SMTP

В Exchange 2010 для всего почтового трафика внутри организации обеспечивается балансировка нагрузки между Hub Transport, Edge Transport и Mailbox серверами на сайте Active Directory. Это обеспечивается с помощью расширенного DNS.

Как было сказано выше, это работает для почтового трафика внутри организации между ролями серверов Exchange. Для обеспечения балансировки нагрузки трафика входящих сообщений с non-Exchange источников, таких как внешние почтовые серверы, решения блокировки спама и вирусов от сторонних производителей, любые внутренние non-Exchange почтовые серверы, внутренние LOB приложения, таких сетевых устройств как принтеры и POP или IMAP, нужно использовать решение балансировщика нагрузки или алгоритм циклического обслуживания DNS.

В этом цикле статей мы используем балансировку нагрузки на базе аппаратных средств, поскольку оно уже имеется в каждом центре данных. К тому же, так как мы используем серверы с несколькими ролями, которые являются частью группы DAG, мы не можем использовать Windows NLB, поскольку сочетание аварийного кластера Windows Failover Clustering и Windows NLB на одном сервере не поддерживается. Более того, важно обратить внимание на следующие ограничения, действующие для балансировки нагрузки с помощью Windows NLB:

• Как уже говорилось, Windows NLB не может использоваться на серверах Exchange, на которых роль транспортного сервера-концентратора и сервера почтовых ящиков установлена на одном сервере и серверы являются участниками группы DAG. Причина заключается в том, что WNLB компонент несовместим с аварийными кластерами Windows Failover Clustering. Если вы используете Exchange 2010 DAG и хотите воспользоваться WNLB, нужно, чтобы роль Hub Transport и Mailbox сервера была установлена на разных машинах. К тому же, Windows NLB будет влиять на маршрутизацию сообщений, когда участник группы DAG и роль сервера Hub Transport размещены на одном физическом сервере.
• Не рекомендуется устанавливать более восьми серверов Hub Transport в массиве, в котором балансировка нагрузки осуществляется с помощью WNLB. Если вам нужно обеспечить балансировку нагрузки для более чем 8 серверов Hub Transport, необходимо разворачивать аппаратное решение.
• Windows NLB не определяет сбои служб. Она лишь способна определять недоступность серверов по IP адресу. Это означает, что в случае отказа службы Exchange Transport, но сохранения рабочего состояния сервера служба Windows NLB не сможет определить сбой и будет направлять входящие почтовые сообщения на этот Hub Transport сервер. Удаление Hub Transport сервера с неисправной службой из пула балансировки нагрузки осуществляется вручную.
• Windows NLB конфигурация может приводить к переполнению порта, что может перегружать сеть. Причина этого заключается в том, что Windows NLB разработана так, что она одновременно доставляет все входящие клиентские пакеты на все порты коммутатора. Хотя такое поведение обеспечивает Windows NLB высокой производительностью, оно может вызывать значительную загруженность коммутатора.

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

Члены Exchange 2010 DAG с установленными ролями Hub Transport

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

Что если роль сервера Hub Transport установлена на сервер, который также является частью группы DAG? Не создаст ли это единой точки сбоя (SPoF), так как служба Microsoft Exchange Mail Submission всегда предпочитает локальные серверы Hub Transport любым другим серверам Hub Transport в сайте AD? Сначала это может показаться единой точкой отказа, так как серверы почтовых ящиков обычно предпочитают локальный сервер Hub Transport любым другим серверам Hub Transport.

Но к счастью это не так в ситуации, где сервер является частью группы DAG. Для обхода этой потенциальной SPoF группа разработчиков Exchange Product внесла изменения в продукт. Говоря точнее, если служба Exchange Mail Submission на сервере почтовых ящиков определяет, что она работает на сервере почтовых ящиков, входящем в группу DAG, она не будет отдавать предпочтение локальному серверу Hub Transport. Вместо этого она будет выполнять балансировку нагрузки между другими серверами Hub Transport в этом же сайте Active Directory. Если она не находит никаких других серверов, она обращается к локальному серверу Hub Transport.

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

Создание SMTP пространств имен в DNS

Первым шагом на пути обеспечения балансировки нагрузки трафика входящих сообщений является создание SMTP пространства имен, которое будет использоваться в DNS. Если вы используете DNS, интегрированную в Active Directory, нужно открыть диспетчер DNS Manager на контроллере домена и включить ‘Расширенный (Advanced)’ в меню ‘Вид (View)’. Теперь разворачиваем ‘Зоны прямого поиска (Forward Lookup Zones)’ и нажимаем правой клавишей на той зоне, в которой нужно создать пространство имен SMTP. В контекстном меню выбираем ‘New Host (A)‘.

Вводим нужное пространство имен. В нашем примере это будет ‘smtp’. Теперь вводим VIP, который будет использоваться виртуальной службой SMTP на решении балансировщика нагрузки в основном центре данных. В этом примере я использую тот же VIP, который использовал для виртуальных служб CAS. Наконец, выставляем значение ‘Time to live (TTL)’ на 5 минут. В результате срок действия DNS кэша истекает в течение соответствующего времени, если/когда нам нужно направить запись на VIP, связанный с виртуальной службой SMTP решения балансировки нагрузки в аварийном центре данных.

Нажимаем ‘Добавить узел (Add Host)’ и выходим из диспетчера DNS Manager.

Рисунок 1: Добавление пространства имен SMTP в DNS

Создание виртуальной SMTP службы на решении балансировщика нагрузки

Следующим шагом будет создание виртуальной SMTP службы на решении балансировщика нагрузки в каждом центре данных. Я не буду подробно расписывать этот процесс, поскольку он будет отличаться в зависимости от того, какое решение балансировки нагрузки используется в вашей инфраструктуре. В этой тестовой среде виртуальная служба показана на рисунке 2 (основной центр данных) и рисунке 3 (аварийный центр данных).

Обратите внимание, что виртуальная SMTP служба ‘отключена (down)’. Также обратите внимание, что IP адреса целевых серверов (реальных серверов) отличаются от адресов, на которые указывают другие виртуальные службы. Служба не работает, поскольку эти IP адреса еще не добавлены в серверы Exchange 2010, а это означает, что балансировщики нагрузки не принимают никаких ответов при выполнении проверок работоспособности порта 25.

Рисунок 2: Создание виртуальной службы SMTP в балансировке нагрузки основного центра данных

Рисунок 3: Создание виртуальной службы SMTP в балансировке нагрузки аварийного центра данных

Добавление дополнительного IP адреса на каждый сервер Exchange 2010

Теперь пришло время добавить дополнительный IP адрес на каждый из четырех серверов Exchange 2010. Для этого открываем ‘Сетевые подключения’ на каждом сервере. Здесь открываем страницу свойств для каждого сетевого интерфейса PROD, после чего открываем свойства ‘Интернет протокола версии 4 (TPC/IPv4)’.

Рисунок 4: Свойства сетевого интерфейса PROD

Нажимаем ‘Дополнительно (Advanced)’ и выбираем ‘Добавить (add)’.

Рисунок 5: Нажимаем кнопку ‘Дополнительно’ на странице свойств TPC/IPv4

Вводим IP адрес, используемый в качестве целевого IP адреса на балансировщике нагрузки и дважды жмем ‘OK’.

Рисунок 6: Добавление дополнительного IP адреса в интерфейс PROD

Изменение соединителя получения по умолчанию

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

Для доступа к стандартному соединителю получения открываем консоль управления EMC и разворачиваем ‘Конфигурацию сервера (Server Configuration)’. В конфигурации сервера выбираем ‘Hub Transport’. Теперь нажимаем на первом сервере в списке, содержащемся в открывшемся окне. В разделе ‘Соединителей получения (Receive Connectors)’ в рабочей панели переходим в свойства соединителя получения по умолчанию (в нашем примере это ‘Default EX01’).

Рисунок 7: Открытие страницы свойств соединителя получения по умолчанию

Переходим в закладку ‘Сеть (Network)’ и открываем страницу редактирования ‘Всех доступных адресов (All Available IPv4))’.

Рисунок 8: Страница свойств соединителя получения по умолчанию

На странице изменения привязки соединителя получения (‘Edit Receive connector Binding’) выбираем опцию указания IP адреса (‘Specify and IP address:’) и вводим основной IP адрес, присвоенный сетевому интерфейсу PROD (не тот IP адрес, который мы добавили в предыдущем абзаце). Дважды нажимаем ‘OK’ для выхода со страницы свойств соединителя получения по умолчанию.

Рисунок 9: Изменения привязок соединителя получения

Обязательно повторите вышеописанные шаги на всех четырех серверах Exchange 2010. Обязательно используйте уникальный IP адрес (подсети, к которой принадлежит сервер) для каждого сервера.

Создание соединителя получения SMTP для балансировки нагрузки

Теперь мы можем создать новый соединитель получения на каждом сервере Exchange 2010. Этот соединитель получения будет использоваться специально для балансировки нагрузки почтового трафика, приходящего с non-Exchange источников.

Для создания нового соединителя получения нажмите правой клавишей мыши на первом сервере Exchange 2010 и выберите опцию создания нового соединителя получения (‘New Receive Connector’) в контекстном меню (рисунок 10).

Рисунок 10: Выбор опции ‘New Receive Connector’ в контекстном меню

На приветственной странице назовите соединитель таким именем, которое позволит его легко определить, а затем нажмите ‘Далее’.

Увеличить

Рисунок 11: Создание нового соединителя получения для балансировки нагрузки почтового трафика с non-Exchange источников

На странице ‘Параметры локальной сети (Local Network Settings)’ нажмите ‘Изменить (Edit)’ и укажите новый IP, который вы добавили на сервере в разделе ‘Добавления дополнительных IP адресов на каждом сервере Exchange 2010‘. Если вам нужен такой SMTP баннер на всех серверах, как smtp.exchangeonline.dk, укажите его здесь. Нажмите ‘Далее’.

Увеличить

Рисунок 12: Назначение нового IP адреса соединителю получения

На странице ‘Параметров удаленной сети (Remote Network settings)’ оставьте все настройки по умолчанию (если только не хотите ограничить источники предоставления сообщений для этого соединителя) и нажмите ‘Далее’.

Увеличить

Рисунок 13: Параметры удаленной сети

На странице сводки конфигурации (‘Configuration Summary’) нажмите ‘Новый (New)’, чтобы создать новый соединитель получения.

Увеличить

Рисунок 14: Сводка конфигурации нового соединителя получения

Теперь откройте страницу свойств нового соединителя получения и выберите закладку ‘Групп разрешений (Permissions Groups)’. Если вы хотите разрешить использование соединителя источниками, не проходящими проверку подлинности, нужно отметить опцию ‘Анонимные пользователи (Anonymous users)’.

Рисунок 15: Включение ‘Анонимных пользователей’ на новом соединителе получения

Нажмите ‘OK’, чтобы закрыть страницу свойств.

Обязательно выполните эти шаги на всех четырех серверах Exchange 2010.

Создание соединителя отправки

Если вы еще не создали соединитель отправки, его нужно создать в организации Exchange 2010. Для этого откройте консоль EMC и разверните ‘Конфигурацию организации (Organization Configuration)’. Нажмите на Hub Transport и перейдите в закладку соединителя отправки ‘(Send Connector)’. Запустите мастер создания нового соединителя отправки. На приветственной странице мастера задайте имя соединителю типа ‘To Internet (Primary Datacenter)’ и обязательно выберите ‘Custom’ в раскрывающемся меню. Затем нажмите ‘Далее’.

Увеличить

Рисунок 16: Создание соединителя отправки

На странице ‘Адресного пространства (Address space)’ добавьте адресное пространство SMTP с адресом ‘*’ и нажмите ‘Далее’.

Увеличить

Рисунок 17: Страница адресного пространства

На странице ‘Настройки сети (Network settings)’ оставьте умолчания, если только вам не нужно направить исходящие сообщения через промежуточный узел. Нажмите ‘Далее’.

Увеличить

Рисунок 18: Страница настроек сети

На странице ‘Сервера источника (Source Server)’ добавьте два сервера Exchange 2010, расположенных в основном центре данных в качестве серверов источника и нажмите ‘Далее’.

Увеличить

Рисунок 19: Страница сервера источника

На странице сводки конфигурации нажмите New для создания соединителя отправки.

Увеличить

Рисунок 20: Страница сводки конфигурации

Повторите вышеописанные шаги для создания соединителей отправки. Обязательно используйте имя ‘To Internet (Failover Datacenter’) и добавьте два сервера аварийного центра данных в качестве серверов источника.

Рисунок 21: Соединители отправки

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