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

Если вы хотите прочитать предыдущие части этого цикла статей, перейдите по ссылкам:

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

Введение

В 4 части этого цикла статей мы установили доверенный SAN/UC сертификат на серверы Exchange 2010, а также настроили статические RPC порты для службы RPC Client Access и Exchange Address Book.

В этой части мы продолжим с того места, на котором остановились в предыдущей части. Мы начнем с создания массива Client Access на каждом сайте Active Directory. Затем мы включим Outlook Anywhere, а также настроим параметры поставщика Outlook, чтобы клиенты Outlook Anywhere имели возможность подключения даже после ситуации обхода отказа.

Создание массивов Client Access

Массив Client Access, как предполагает его название, представляет собой массив серверов CAS. Если говорить точнее, это массив, состоящий из всех серверов CAS сайта Active Directory, на котором создается массив. Поэтому вместо подключения к FQDN имени сервера CAS, клиент Outlook может подключиться к FQDN имени массива CAS (например, outlook.domain.com). Это позволяет обеспечить постоянное подключение клиентов Outlook, подключающихся через клиенты на базе MAPI и HTTPS (OWA, Outlook Anywhere, и т.д.), даже при сбое базы почтовых ящиков и ситуации обхода отказа.

Вот как все работает в массивах CAS. База данных почтовых ящиков Exchange 2010 имеет атрибут под названием RpcClientAccessServer. При создании новой базы почтовых ящиков на сайте Active Directory, где создан массив CAS, этот атрибут получит значение одного из серверов CAS, расположенных на соответствующем сайте AD. Для просмотра значения данного атрибута для конкретной базы почтовых ящиков нужно выполнить следующую команду:

Get-MailboxDatabase | fl Name, RpcClientAccessserver

Рисунок 1: Стандартное значение RpcClientAccessServer для базы почтовых ящиков сайта AD без массива CAS

Если массив CAS имеется на сайте AD, на котором создается новая база почтовых ящиков, атрибут RpcClientAccessServer получает значение имени FQDN массива CAS. В результате массив CAS на сервере Client Access знает, на какой сервер Mailbox и базу данных направить пользователя.

Массив CAS можно настраивать только с помощью оболочки Exchange Management Shell. Если говорить точнее, нужно использовать команду New-ClientAccessArray. Итак, для создания CAS массива на сайте AD, связанном с основным центром данных, нужно выполнить следующую команду:

New-ClientAccessArray 'Fqdn 'outlook-1.exchangeonlinet.dk' -Site 'Datacenter-1' 'Name 'outlook-1.exchangeonline.dk'

Рисунок 2: Создание нового массива CAS на основном сайте AD

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

Get-ClientAccessArray 'outlook-1.exchangeonline.dk' | fl Name,Members

Рисунок 3: Проверка принадлежности к массиву CAS

После создания массива CAS нужно создать 'A record' запись в AD DNS. Эта запись будет называться outlook-1.exchangeonline.dk и будет указывать на виртуальный IP адрес внутреннего решения балансировки нагрузки, настроенного в основном центре данных.

Итак, открываем диспетчер DNS Manager и нажимаем правой клавишей на соответствующей зоне прямого поиска. В контекстном меню выбираем 'Новый узел (New Host)' и вводим имя новой записи узла (в нашем случае 'outlook-1'), а затем указываем VIP адрес, настроенный в решении балансировки нагрузки в основном центре данных, как показано на рисунке 4.

Рисунок 4: Создание DNS записи для массива CAS в основном сайте AD

Теперь нужно повторить такие же шаги, чтобы создать и настроить массив CAS в аварийном центре данных. То есть, создаем объект массива CAS с помощью следующей команды:

New-ClientAccessArray 'Fqdn 'outlook-2.exchangeonlinet.dk' -Site 'Datacenter-2' 'Name 'outlook-2.exchangeonline.dk'

Рисунок 5: Создание нового массива CAS на аварийном сайте AD

Обратите внимание, что имя FQDN отличается, так как мы не можем использовать одинаковое FQDN имя для двух объектов массива CAS.

Теперь нужно создать DNS запись в AD DNS и заставить ее указывать на VIP адрес, используемый решением балансировки нагрузки аварийного центра данных.

Рисунок 6: Создание DNS записи для массива CAS в аварийном сайте AD

Изменение значения RpcClientAccessServer для существующих баз Mailbox

Сейчас самое время изменить значение свойства RpcClientAccessServer для всех существующих баз данных почтовых ящиков во всех центрах данных на FQDN имя, указанное для объектов CAS массива соответствующих сайтов AD. Например, чтобы изменить это значение для базы данных под названием 'MDB01' в основном центре данных, используем следующую команду:

Set-MailboxDatabase MDB01 ' RpcClientAccessServer outlook-1.exchangeonline.dk

Рисунок 7: Изменение RpcClientAccessServer значения для базы данных Mailbox

Теперь, при настройке нового профиля Outlook конечная точка MAPI будет преобразовываться в 'outlook-1.exchangeonline.dk', как показано на рисунке 8.

Рисунок 8: Конечная точка подключения для профиля Outlook после привязки базы Mailbox к массиву CAS

Если открыть окно состояния подключения ('Connection Status') после запуска Outlook, вы увидите, что 'Directory' и 'Mail' используют 'outlook-1.exchangeonline.dk' в качестве конечной точки подключения (рисунок 9).

Рисунок 9: Конечная тока подключения для 'Directory' и 'Mail' в окне состояния подключений Outlook

Включение Outlook Anywhere

Поскольку наши пользователи Exchange 2010 должны подключаться к своим почтовым ящикам из внешней сети (например, из интернет) с помощью Outlook, нам нужно включить Outlook Anywhere.

Так как все четыре сервера Exchange 2010 с несколькими ролями считаются серверами с подключением к интернету, нам нужно включить Outlook Anywhere на всех этих серверах. Это можно сделать в консоли управления Exchange Management Console или с помощью команды Enable-OutlookAnywhere в оболочке Exchange Management Shell. Поскольку нам нужно включить этот компонент на всех четырех серверах, давайте воспользуемся командой Enable-OutlookAnywhere. В основном центре данных нам нужно выполнить следующую команду на каждом сервере (нужно указать соответствующее имя сервера):

Enable-OutlookAnywhere 'Server E14EX01 'ExternalHostname 'mail.exchangeonline.dk' 'DefaultAuthenticationMethod 'Basic' 'SSLOffloading $false

Рисунок 10: Включение Outlook Anywhere

В аварийном центре данных нужно выполнить следующую команду на каждом сервере (нужно указать соответствующее имя сервера):

Enable-OutlookAnywhere 'Server E14EX02 'ExternalHostname 'failover.exchangeonline.dk' 'DefaultAuthenticationMethod 'Basic' 'SSLOffloading $false

Настройка глобальных параметров поставщика Outlook

Поскольку мы установили один UC/SAN сертификат на серверах Exchange 2010 в обоих центрах данных, основное имя сертификата (mail.exchangeonline.dk) будет одинаковым для обоих центров данных. Это означает, что в случае обхода отказа на аварийный центр данных основное имя сертификата (mail.exchangeonline.dk) и внешнее имя узла, настроенное для Outlook Anywhere (failover.exchangeonline.dk), не будет совпадать. Поскольку клиент Outlook, подключающийся через Outlook Anywhere, ожидает, что основное имя сертификата и внешнее имя узла для Outlook Anywhere будет совпадать при подключении, подключение Outlook Anywhere клиента будет невозможным в ситуации обхода отказа на аварийный центр данных.

Рисунок 11: Стандартные параметры Exchange Proxy в основном центре данных

Возможно, кто-то спросит: «А почему бы не купить UC/SAN сертификат для аварийного центра данных, у которого основное имя будет failover.exchangeonline.dk»? Можно исправить проблему и таким способом, но знаете, что? Это вовсе не обязательно. Проблему можно исправить и другими средствами.

Нам лишь нужно настроить 'msstd' значение так, чтобы оно было одинаковым на обоих центрах данных. Для этого используем команду 'Set-OutlookProvider' с параметром 'CertPrincipalName'.

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

Set-OutlookProvider EXPR 'CertPrincipalName msstd:mail.exchangeonline.dk

Рисунок 12: Глобальная настройка основного имени сертификата с помощью команды Set-OutlookProvider

Это означает, что настройки прокси для клиентов Outlook, подключающихся к аварийному центру данных при обходе отказа, будут обновляться (с помощью Autodiscover) теми настройками, которые показаны на рисунке 13.

Рисунок 13: Настройки прокси Exchange аварийного центра данных в параметрах поставщика Outlook

На этом завершаем 5 часть данного цикла статей.

Если вы хотите прочитать предыдущие части этого цикла статей, перейдите по ссылкам:

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