пятница, 9 апреля 2010 г.

Отказоустойчивый Exchange 2010 (DAG + NLB)

UPD: Исправлен серьезный недочет в разделе организации NLB-массива.

Сегодня ни кто уже не будет спорить, что почтовая система в каждой организации является одним из самых важных и уязвимых мест. Сточки зрения бизнеса, корпоративная почта должна быть доступна в режиме 24/7, т.к. часто запоздалая отправка, либо несвоевременное получение всего одного письма может принести компании ощутимый финансовый и имиджевый урон. В связи с этим, ИТ-администраторы предпринимают всяческие меры по обеспечению отказоустойчивости почтовых серверов.

До выхода Exchange 2007 это было достаточно не простой задачей. Затем в 2007-м Exchange`е компания Microsoft изменила эту ситуацию, введя две новые функции CCR и SCR, которые, надо заметить, были весьма успешными в деле организации безаварийной работы. С выходом Exchange 2010, Microsoft пошла ещё дальше и улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Функция DAG, как и CCR, зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange.

Но обеспечить отказоустойчивость баз данных это ещё пол дела, также нужно обеспечить непрерывный доступ самих пользователей к этим базам данных. Как известно, за работу с почтовыми клиентами в Exchange отвечает CAS (Client Access Service). Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB (Network Load Balancing) кластера.

Кроме ролей Mailbox Server и Client Access Server существует ещё и роль транспортного сервера-концентратора (Hub Transport Server), как же быть с ней в плане отказоустойчивости? А с ней совсем делать ни чего не надо, достаточно установить на два или более сервера Exchange 2010 эту роль и отказоустойчивость будет обеспечена автоматически, т.к. транспортные серверы-концентраторы Exchange отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на сайте Active Directory, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующему транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему). Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2010. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт не относится к серверам, включенным в DAG группу. В случае, если Hub Transport`ы установлены на сервера MailBox, входящие в DAG, то сервера почтовых ящиков будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

Теперь перейдем от теории к практике и посмотрим, как обеспечить отказоустойчивость Exchange 2010

Для этого построим принципиальную схему организации почтовой системы предприятия:
alt
Рис.1. Принципиальная схема почтовой системы предприятия

Примечание: Настройку сервера EDGE Transport в этой статье рассматривать не будем. Так же не будем рассматривать процедуру установки Exchange серверов (это совсем не сложно), единственное, в чем хочу вас предостеречь, так это в том, что не стоит пытаться устанавливать несколько серверов одновременно (даже в тестовой среде), необходимо дождаться окончания установки одного сервера, а затем приступать к инсталляции другого, в противном случае системные ошибки неизбежны.

Перейдем к настройке Database Availability Group

Важно отметить, что в каждую DAG группу может входить до 16 серверов почтовых ящиков, таким образом, вы сможете иметь до 16 копий каждой базы (хранение более одной копии базы почтовых ящиков на каждом сервере не поддерживается, а также активной может быть только одна копия), причем нужно не забывать, что каждый Exchange 2010 Standard может поддерживать только 5 баз данных, а Enterprise версия – до 100 баз. Время переключение между базами в Exchange 2010 заметно снижено, и теперь составляет порядка 30 секунд, а если учесть тот факт, что клиенты общаются с базами данных через Client Access Servers, то они совсем не заметят этого перехода. Также в Exchange 2010 предпринята попытка отказаться от публичных папок (Public Folders), и хотя они все ещё поддерживаются, но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

Как уже говорилось выше, группы DAG в своей работе используют часть компонентов системы отказоустойчивых кластеров (Failover Clusters), таким образом, как и в классическом отказоустойчивом кластере, серверам нужно иметь по два сетевых интерфейса: один для MAPI-доступа клиентов, другой для трафика heartbeat/replication, по которому будет отслеживаться состояние узлов кластера. Хотя решения с одним сетевым интерфейсом на каждом сервере поддерживаются, но мы не будем экспериментировать и возьмем две сетевых карты, одна будет смотреть в локальную сеть предприятия и будет иметь адрес из диапазона 192.168.0.0/24, другая – в изолированную сеть с адресным пространством 192.168.1.0/24.



alt
Рис.2: Принципиальная схема Database Availability Group

На интерфейсе для Heartbeat`ов можно отключить такие компоненты сетевого взаимодействия, как TCP/IPv6, Client for Microsoft Network, File and Printer Sharing и даже QoS. Затем надо проверить что локальный сетевой интерфейс находится первым в списке порядка привязки, для этого пойдем в меню Advanced (Дополнительно) > Advanced Settings (Дополнительные параметры) и посмотрим в раздел Connections.

Что касается организации хранилищ для баз данных почтовых ящиков, то теперь вам не придется приобретать высокоскоростные, а, следовательно, и дорогие жесткие диски. В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA 7200! Фактически, вы можете размещать активную копию базы данных на одном SATA диске, а все остальные копии вместе – на другом, и ни каких проблема с производительность дисковой подсистемы у вас быть не должно. Правда тут надо заметить, что вместе с улучшениями в организации работы с жесткими дисками, у Exchange 2010 ещё более возрос аппетит к оперативной памяти сервера и теперь, Microsoft говорит, что !каждую роль! Exchange 2010 необходимо обеспечить 4 Гб оперативной памяти. Возможно это и некоторое преувеличение, но практика покажет, как дела обстоят на самом деле.

Для функционирования DAG, кроме самих серверов Exchange 2010 необходим ещё один сервер, не входящий в группу DAG, он будет выполнять роль сервера-свидетеля, это что-то вроде кворума в классическом отказоустойчивом кластере и именно с помощью него отслеживается состояние серверов, входящих в DAG. Для организации сервера-свидетеля подойдет любой сервер в сайте Active Directory, даже без установленного Exchange 2010, единственным условием его функционирования является то, что в группу его локальных администраторов должна входить доменная группа Exchange Trusted Subsystem.

altРис.3: Доменная группа Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.
 
Итак, все подготовительные работы завершены, теперь давайте создадим новую DAG-группу. Для этого перейдем в раздел Organization Configuration (DAG находится именно на уровне организации), откроем вкладку Database Availability Groups и в меню Действия выберем New Database Availability Group… Откроется мастер конфигурирования DAG:
 
alt
Рис.4: Мастер настройки DAG

Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:

altРис.5: Добавление серверов в группу DAG

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

Примечание: Если что-то пошло не так и кластер не собрался, то часто бывает трудно оценить проблему по тексту ошибки, выданному Exchange`м, в такой ситуации может помочь функция проверки узлов кластера в Диспетчере отказоустойчивости кластеров, которая дает гораздо больше информации по присутствующим проблемам:

altРис.6: Проверка кластера.

Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5

Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:

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

Если вам не нравится GUI, то можно это сделать с помощью командлета:

Add-MailboxDatabaseCopy -Identity MDB2 -MailboxServer Server3 -ActivationPreference 2

Создать копию базы данных с временем задержки воспроизведения и временем задержки усечения можно только из командной консоли Exchange (здесь 10 и 15 минут соответственно):

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 00:10:00 -TruncationLagTime 00:15:00 -ActivationPreference 2

Таким образом, мы получаем несколько копий исходной базы данных, расположенные на разных серверах и в разных хранилищах. Чтобы активировать одну из копий, нужно нажать на ней правой кнопкой мыши и из выпадающего меню выбрать Activate Database Copy, после чего в открывшемся окне решить стоит ли перезаписывать параметры базы и нажать ОК, далее база данных будет автоматически смонтирована на другом сервере и её состояние измениться с Healthy на Mounted:

alt
Рис.8: Переключение баз почтовых ящиков.

Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…

altРис.9: Обновление копии базы данных почтовых ящиков.

Перейдем к настройке массива серверов CAS

Принципиальная схема взаимодействия серверов в массиве будет выглядеть следующим образом:
imageРис.10: Принципиальная схема взаимодействия серверов в CAS массиве.

Смысл в том, что клиенты, вместо подключения непосредственно к CAS серверу, будут подключаться к FQDN CAS-массива и при «падении» одного из серверов клиентские запросы возьмет на себя другой.

Т.к. массив CAS используется только клиентами Outlook MAPI, то для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, необходимо решить, что именно у вас будет выполнять роль балансировщика сетевой нагрузки (NLB). Microsoft рекомендует использовать для этих целей внешние аппаратные устройства, но если у вас таковых нет, то служба Windows Network Load Balancing вполне подойдет. Здесь нужно иметь в виду, что службы Windows NLB и Failover Cluster на одном сервере не живут!

Для работы WNLB (как и других систем балансировки), необходимо иметь на DNS сервере запись, указывающую на виртуальный IP-адрес этой системы:

altРис.11: Настройка DNS сервера.

Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.

altРис.12: Создание нового кластера NLB.

В открывшемся мастере введем имя первого узла кластера и укажем локальный сетевой интерфейс. В следующем окне менять ни чего не нужно. Далее, добавим IP-адрес нашего кластера и укажем маску. Затем нужно настроить параметры кластера:
altРис.13: Настройка параметров кластера.

Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!

Подробнее про принцип работы NLB можно посмотреть здесь.
Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!

Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с Microsoft Hyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.

altРис.14: Настройка сетевых интерфейсов в Hyper-V

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

  • TCP/135 – для работы CAS-массива (убедитесь, что в Filtering Mode свойство Affinity включено в Single);
  • TCP/1024-65535 – диапазон RPC портов для MAPI-клиентов и CAS (если у вас не указаны статические порты);
  • TCP/443 - для Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
  • TCP/993 – для Secure IMAP (Affinity включено в None);
  • TCP/995 – для Secure POP (Affinity включено в None);
  • TCP/80 – для внутреннего IIS перенаправления (HTTP > HTTPS).
Далее нажимаем Готово и добавляем ещё один узел к кластеру, нажав на созданном кластере правой кнопкой мыши и выбрав пункт Добавить узел к кластеру. У нового узла значение приоритета выставляем в 2 и все остальные параметры оставляем по-умолчанию.

Теперь осталось только собрать сам CAS массив.

Для этой цели воспользуемся командлетом New-ClientAccessArray:

New-ClientAccessArray -FQDN “mail.test-mail.local” –Site “Default-First-Site-Name”

И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:

Set-MailboxDatabase -RpcClientAccessServer “mail.test-mail.local”

altРис.15: Создание CAS массива.
 
Проверить результат можно командлетом Get-MilboxDatabase.
На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.
altРис.16: Настройка MS Outlook.

Использование аппаратного балансировщика сетевой нагрузки (NLB).

Если у вас есть в наличии аппаратный NLB, то, несомненно, лучше использовать именно его, но при этом придется вручную сконфигурировать адреса таких служб, как OWA (Outlook Web App), ECP (Exchange Control Panel), Exchange ActiveSync (EAS) и Outlook Anywhere (OA) на работу с FQDN этого балансировщика. Настройка внутренних URL`ов делается при помощи следующих команд:
 
Outlook Web App (OWA)
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.local/OWA

Exchange Control Panel (ECP)
Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://mail.domain.local/ECP -FormsAuthentication $True -BasicAuthentication $True
Exchange ActiveSync
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.local/Microsoft-Server-Activesync -BasicAuthentication $True
Offline Address Book (OAB)
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -InternalUrl https://mail.domain.local/oab 
Exchange Web Services (EWS)
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -InternalUrl https://mail.domain.local/ews/exchange.asmx 
Unified Messaging (UM)
Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.local/unifiedmessaging/service.asmx 

Можно настроить сразу 2 адреса – внешний и внутренний:
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.local/OWA -ExternalURL https://mail.domain.local/OWA -FormsAuthentication $True -BasicAuthentication $True

Autodiscover Service
Set-ClientAccessServer –Identity <Server Name> -AutoDiscoverServiceInternalUri: https://mail.domain.local/Autodiscover/Autodiscover.xml
 
Также придется сконфигурировать внешний адрес для доступа к сервисам CAS из сети Интернет, это можно сделать через графическую консоль управления - Server Configuration - Client Access - Configure External Client Access Domain, либо с помощью команд:
Outlook Web App (OWA)
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -ExternalURL https://mail.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True
Exchange Control Panel (ECP)
Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -ExternalURL https://mail.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True
Exchange ActiveSync (EAS)
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -ExternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True
Offline Address Book (OAB)
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -ExternalUrl https://mail.domain.com/oab;
Exchange Web Services (EWS)
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -ExternalUrl https://mail.domain.com/ews/exchange.asmx

Статьи для подробного изучения:

Генрик Валзер:
Управление базами данных почтовых ящиков:
Управление копиями баз данных почтовых ящиков:

71 комментарий:

b01d комментирует...

Алексей, добрый день. NLB сервер который вы конфигурируете в этой статье, это некий новый сервер? Или это настраивается на одном из существующих в рамках данного тестового стенда (mailbox, cas, и т.д.)?

Алексей Богомолов (Alexx) комментирует...

NLB массив формируется/настраивается из 2-х уже существующих CAS серверов в рамках лабораторного стенда.

Кобзарев Д. В. комментирует...

Алексей, добрый день. Очень понравилась ваша статья и вэб-каст. Очень подробно и понятно, но, тем не менее, у меня есть 3 вопроса:
1) Считается ли лучшей практикой разнесение ролей СЕРВЕР ПОЧТОВЫЙ ЯЩИКОВ и CAS+HUB на 2 разных сервера? Вопрос возник потому, что Microsoft пишет, что для обеспечения полной отказоустойчивости всех сервисов и данных достаточно 2-х серверов (я имею ввиду оборудование). Послушав ваш вэб-каст, я узнал о том, что NLB-кластер не может быть сделан из тех серверов, на которых установлена роль СЕРВЕР ПОЧТОВЫХ ЯЩИКОВ. Получается, что нужно минимум 4 сервера.
2) Как вы бы рекомендовали поступить с бэкапом баз данных? Чем лучше делать? Как распологать?
3) Как правильно подойти к вопросу выбора дискового хранилища? Я собираюсь приобрести SAN-хранилище, но не могу понять, как правильно посчитать объем, необходимый для хранения баз.

С уважением, Кобзарев Д. В.

Алексей Богомолов (Alexx) комментирует...

1) Вообще для высоконагруженных систем лучшей практикой считается 1 сервер = 1 роль, но это достаточно накладно, посему встречается редко. NLB-кластер не может быть сделан из серверов на которых установлена ролько Mailbox, только в том случае, если сервера Mailbox объединены в DAG-группу, т.к. DAG использует часть компонентов службы Failover Cluster, а NLB совместно с Failover Cluster на одном сервере установить не получиться.
>Microsoft пишет, что для обеспечения полной отказоустойчивости всех сервисов и данных достаточно 2-х серверов
Совершенно верно, но в этом случае вам придется приобретать аппаратный балансировщик сетевой нагрузки (NLB) вместо программного Windows NLB. Это будет правильнее и возможно дешевле.
2) Бэкап не плохо делает встроенное средство Windows Server Backup, также можно по смотреть в сторону Data Protection Manager, но он является платным, хотя и не очень дорогим.
3)Что касается хранилища, то тут действует принцип - "места много не бывает".
Вообще нужно примерно прикинуть какие квоты у вас будут для почтовых ящиков пользователей и умножить это число на количество пользователей, далее решить сколько будет копий баз данных в DAG-е + незабыть про бэкапы баз. Вот так можно и получить примерную оценку необходимого места.

Кобзарев Д. В. комментирует...

Алексей, спасибо за комментарий.
А как быть с CAS+HUB серверами, которые будут находиться в разных сайтах? (между ними оптоволокно, 30 км, пинг 1 мс)
Можно ли сервера так расположеные помещать в WNLB-массив?
Также, насчета аппаратного NLB:
Если у меня 2 сервера с ролями MB+HUB+CAS, которые будут находиться в разных сайтах (между ними оптоволокно, 30 км, пинг 1 мс), как в таком случае располагать HNLB?

С уважением, Кобзарев Д. В.

Алексей Богомолов (Alexx) комментирует...

Если сервера в разных сайтах, то это совсем другая тема! Про разнесение серверов по сайтам почитайте вот тут - http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/designing-site-resilient-exchange-2010-solution-part1.html
там 2 части.

Кобзарев Д. В. комментирует...

Спасибо за статью, прочитал...
Я так понимаю, что роли CAS и HUB мне тоже придется разносить, так как каждый из серверов будет подключаться к своему HNLB.
Или же все-таки можно совместить HUB+CAS и подключить их к одному HNLB?

С уважением, Кобзарев Д. В.

Алексей Богомолов (Alexx) комментирует...

для HUB`a не нужен NLB, если в сайте установлено более одного HUB`a, то отказоустойчивость этой роли будет организована автоматически вынутренними механизмами сервера Exchange. Так что HUB можно совместить с любой другой ролью.

Анонимный комментирует...

Добрый день, Алексей!
Спасибо за вашу статью и вэб-каст. Очень интересно и познавательно. Однако вот какой вопрос возник :) Вы утверждаете, что если не поднимать DAG на серверах с ролью Mailbox, то при отправке почты сервер будет искать HUB Role который находиться на локальной машине, даже если он отключен. Как в таком случае поступать, если роли планируется разнести на 3 разных сервера, т.е. каждой роли по серверу (HUB, CAS, Mailbox)? Объединять HUB+Mailbox и делать из них DAG? Или есть какое то более изящное решение, типа объяснения/настройки Mailbox Role, что HUB это другой сервер и используй его.

Заранее спасибо,
Антон

Алексей Богомолов (Alexx) комментирует...

Нет, здесь не все так категорично, возможно я немного не правильно выразился. Имеется ввиду, что если Mailbox не в DAG-группе, то он будет преимущественно обращаться к локальному HUB`y, если же в DAG`e - то преимущественно к удаленному.
Это не означает, что если локальный не отвечает или его нет вовсе, то он не будет искать его где-то ещё. Информация о то где находятся HUB`ы хранится в базе AD, следовательно Mailbox будет перебирать их все, пока не найдет один работающий в сайте.
PS Скоро будет готов ещё один веб-каст по материалам прошедшей встречи МСР-клуба, там как раз эта тема поднимается ещё раз немного подробнее.

Анонимный комментирует...

Добрый день, Алексей!
Подскажите как в группе DAG настроить CAS если не соединять их в массив?

Александр

Алексей Богомолов (Alexx) комментирует...

Александр, что вы имеете ввиду под словом "как"? Нужно установить роль CAS на один из узлов массива DAG и все! Либо установить несколько CAS-ов, но при этом распределить по ним различные сервисы, например MAPI-клиенты будут подключаться к одному серверу, а OWA-клиенты в другому, все остальные к третьему и т.п.

Анонимный комментирует...

"Александр, что вы имеете ввиду под словом "как"? Нужно установить роль CAS на один из узлов массива DAG и все!"
Для реализации "отказоустойчивости" :) я поставил на оба Exchange сервера роль CAS но как правильно этим пользоваться я не могу разобраться, подскажите Алексей пожалуйста как правильно реализовать мой замысел?

Спасибо за ответы!
Александр.

Алексей Богомолов (Alexx) комментирует...

>Для реализации "отказоустойчивости" :)
Для реализации отказоустойчивости вам надо CAS-ы объединить в массив (CAS-array), но для полноценной работы массива (не только MAPI клиенты, но и все другие) вам необходимо использовать сетевую балансировку (NLB), соответственно надо взять "железный" балансировщик, либо воспользоваться службой Windows NLB, но тут проблема в том, что WNLB совместно с Failover Cluster`ом не живет, а FC нужен для работы DAG.
Мораль - если у вас нет аппаратного NLB, то вам придется роли Mailbox и CAS разносить по разным серверам Exchange.

Анонимный комментирует...

Интересно, а можно ли как в старом добром exchange2007 сделать простую репликацию базы данных?
То есть не лепить огород из нескольких серверов, а просто тупо сделать так, чтобы одновременно файлы базы реплицировались на другой раздел этого же сервера? Чтобы для начала защититься хотябы от физического краха носителя. Просто пока нет возможности купить второй сервер и лицензии к нему, да и организация небольшая, всего 50 ящиков, одного сервера для всех ролей вполне хватает. Но хотябы базу защитить хочется.

Анонимный комментирует...

А динамические диски Вам не помогут защититься от "физического краха" носителя?

Алексей Богомолов (Alexx) комментирует...

1. Защитить базу проще всего при помощи бэкапа.
2. А про динамические диски можно чуть подробнее?

Анонимный комментирует...

Алексей спасибо за пост.

Скажи что будет когда перезагрузить сервер свидетель в работающей среде ДАГ.

Как сервера себя поведут в этом случаи ?

И что будет когда перезагрузить один из серверов из группы ДАГ. ?

Алексей Богомолов (Alexx) комментирует...

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

Анонимный комментирует...

Спасибо.
А что произойдет когда я ребутну сервер с автивной базой данных? В теории база должна будет завестись на втором сервере .
Но что произойдет когда первый сервер поднимится после ребута, база обратно станет активной на нем? Или придется руками переключать.

Алексей Богомолов (Alexx) комментирует...

Это зависит от того настроен ли предпочтительный владелец в свойствах кластера.

Анонимный комментирует...

А где именно это настраивается? И как правильно выставить владельца ? Какой сервер назначать владельцем?

андрей комментирует...

Нашел. Там оба сервера выделены как владельцы.
Как тогда они поступят при :
"А что произойдет когда я ребутну сервер с автивной базой данных? В теории база должна будет завестись на втором сервере .
Но что произойдет когда первый сервер поднимится после ребута, база обратно станет активной на нем? Или придется руками переключать. "

Алексей Богомолов (Alexx) комментирует...

Предпочтительны владелец настраивается в свойствах копии базы.

андрей комментирует...

Ага. Если предпочтительный сервер БД1 есть сервер 1, то при его ребуте база переключится на сервер2 , и после того как сервер поднимется после ребута она автоматически переключится на сервер1 обратно ?

Алексей Богомолов (Alexx) комментирует...

Да, в этом случае, в течении нескольких минут база должна вернуться.

андрей комментирует...

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

Анонимный комментирует...

Алесей, здравствуйте.
Перерыл гору материалов, но так и не нашел точный ответ: при развертывании DAG в домене с 2-мя сайтами, нужен ли сервер-свидетель в каждом сайте?

Алексей Богомолов (Alexx) комментирует...

Не совсем понятно зачем вы ноды Exch`a разносите по разным сайтам. Вы строите катастрофоустойчивое решение?
Если нет, то не важно в каком сайте у вас будет свидетель.
PS Он все равно будет только один.

Анонимный комментирует...

Алексей, как корректно собрать кластер из отказоустойчивых Edge серверов?

Анонимный комментирует...

нужно ли на edge сервера устанавливать роль NLB или Failover Cluster?

Алексей Богомолов (Alexx) комментирует...

Нет, ни чего не нужно устанавливать. Просто делаете две Edge подписки + для входящей почты устанавливаете 2 МХ записи с одинаковыми приоритетами.

Анонимный комментирует...

а мы дали CAS тот же ip, что и у DAG, и работают оба кластера на 2-х серверах.Но остались сомнения,не грозит ли это какими-нибудь непрмятностями.

Алексей Богомолов (Alexx) комментирует...

Нет, это официально не поддерживаемая Microsoft-ом, но рабочая конфигурация. Проблем быть не должно.

Анонимный комментирует...

как быть с запросом на сертификат на "mail.test-mail.local” ?

Алексей Богомолов (Alexx) комментирует...

А какие именно проблемы с запросом сертификата?

Анонимный комментирует...

Есть две машины delta и Sigma они в массиве Alpha(у Вас это mail.test-mail.local)у них при подключении к Оутлуку ругается на alpha.хххх.хх что Имя сертификата не допустимо или не соответствует имени сайта"

roma2000 комментирует...

будет ли статься по созданию DAG-кластеров на основе hyperv? пока, к сожалению, не получается поднять(( основные проблемы - не вводится второй нод, отваливается кластерное имя и еще по мелочам...

Алексей Богомолов (Alexx) комментирует...

Статья написана на базе тестового стенда, который собран на хосте Hyper-V, т.е. по факту, это и есть DAG кластер на виртуалках Hyper-V.

roma2000 комментирует...

Имелось ввиду DAG на узлах Hyper-V включенных в Failover Cluster и, соответственно, использующих Cluster Shared Volumes.

Анонимный комментирует...

для балансировки сетевой нагрузки нужен отдельный сервер или настраивается на одном из сереверов которые в CAS ??

Алексей Богомолов (Alexx) комментирует...

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

Анонимный комментирует...

get-mailboxdatabase | Set-MailboxDatabase -RpcClientAccessServer "mail.xxx.ru"
ПРЕДУПРЕЖДЕНИЕ: Команда выполнена успешно, но параметры 'DatabaseEXC2' не были изменены.
ПРЕДУПРЕЖДЕНИЕ: Команда выполнена успешно, но параметры 'DatabaseEXC1' не были изменены.
get-mailboxdatabase



Name Server Recovery ReplicationType
---- ------ -------- ---------------
DatabaseEXC2 S-EXC2 False Remote
DatabaseEXC1 S-EXC1 False Remote

Get-ClientAccessArray

Name Site Fqdn Members
---- ---- ---- -------
mail Default-First-Sit... mail.xxx.ru {S-EXC2, S-EXC1}

Смущает предупреждение

Алексей Богомолов (Alexx) комментирует...

Почему смущает? Это говорит о том, что у вас свойство RpcClientAccessServer уже было выставлено в mail.xxx.ru.
Попробуйте проверить выполнив
get-mailboxdatabase | fl name,RpcClientAccessServer

Анонимный комментирует...

А что может быть за косяк?
есть 3 сервера в CAS если первый из них вырубаешь, в аутлуке вылетает окно авторизации, приходится перезапускать аутлук или это так работает ?

Анонимный комментирует...

Здравствуйте! У меня сейчас стоит два сервера одинаковой конфигурации(Xeon 2.4 x 2, 24 Гб оперативки). Они объединены в DAG, т.е. по три роли на каждом из серверов. Общий объем баз порядка 700 Гб на примерно 1500 пользователей. Хочется перенести роли CAS на другие сервера(виртуальные) для создания отказоустойчивости роли CAS. Так вот вопрос - как безболезненно можно это сделать, с наименьшим простоем для пользователей? Могу ли я на 2-х виртуалках установить по роли CAS(как при этом поведет себя уже работающий Exchange), потом объединить их в NLB кластер и после этого просто допустим поменять IP адреса на серверах для сопоставления с MX записями ? И какие ресурсы нужно отдать под роли CAS при таких условиях, можно ли добавить виртуалки прямо на существующих серверах Exchange, допустим по одной на каждой из нод DAG?

Rublin комментирует...

У вас здесь ошибка:
Exchange Control Panel (ECP)
Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://mail.domain.local/ECP -FormsAuthentication $True -BasicAuthentication $True

Нужно Set-ECPVirtualDirectory

Rublin комментирует...

И снова ошибка:
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.local/Microsoft-Server-Activesync -BasicAuthentication $True
Правильный параметр не -BasicAuthentication, а -BasicAuthEnabled

Алексей Богомолов (Alexx) комментирует...

Спасибо за поправку.

Анонимный комментирует...

Алексей, "разжуйте" :), плиз, следующую ситуацию:
Есть основной сервер Ex2010. Поставил второй. Хочу настроить отказоустойчивость, т.е. при выходе из строя основного сервера, второй продолжал обслуживать клиентов, отпралял почту и содержал базу с первого. Я так, понимаю, нужно настроить DAG и CAS. В качестве балансировщика планирую nginx на виртуалках(в heartbeat).
Как мне правильнее и безболезненнее это сделать?
Особенно касаемо сертификатов и доступа клиентов извне и изнутри.

Алексей Богомолов (Alexx) комментирует...

DAG собираете штатно, и также создаете CAS array, только Windows Load BAlancer не настраиваете, т.к. у вас будет сторонний. После чего публикацию веб-служб настраиваете на FQDN CAS Array`a. В сертификатах должны быть те имена, по которым к Exch`y обращаются клиенты по 443-му порту.

Анонимный комментирует...

т.е. я создаю сертификат для CAS типа mail.domain.com и autodiscover.domain.com, что делать с сертификатами для не веб? (smtp).
Можно использовать внутренний PKI или нужны все-таки белые сертификаты итого понадобится 3?

Алексей Богомолов (Alexx) комментирует...

На сам сервер вы можете поставить сертификат локального СА и включить плюсом туда имя сервера, чтобы SMTP через TLS работал (у вас же на ресив коннекторах наверняка локальные имена в HELO\EHLO). А вот во внешку публиковать надо только веб службы и имен mail.domain.com и autodiscover.domain.com достаточно.

Анонимный комментирует...

Алексей, добрый день.

Проясните момент в части аппаратного балансировщика. Используем F5 BIG-IP.

Интересует настройка Autodiscover, операцию
Set-ClientAccessServer –Identity -AutoDiscoverServiceInternalUri: https://mail.domain.local/Autodiscover/Autodiscover.xml

нужно выполнять на каждом из CAS серверов?

Алексей Богомолов (Alexx) комментирует...

Да, нужно на всех выполнить.

Анонимный комментирует...

Алексей, еще раз здравствуйте. А не могли бы объяснить, для чего это нужно сделать?

Ситуация, как я вижу: клиент обращается в АД за списком SCP, в котором указан один единственный SCP железного балансировщика. Уже в настройках балансировщика задается список серверов с autodiscover.

Ну, т.е. клиент всегда общается с серверами через балансировщик.

Алексей Богомолов (Alexx) комментирует...

Да, а что вас смущает в этом решении? Просто обычно в SCP прописан первый CAS сервер в организации, соответственно эту настройку лучше переписать на массив.

Леонид Мокрушин комментирует...

Алексей, спасибо за статью!
Не так давно мигрировали с 2007 exchange на 2010.
Столкнулся с проблемой, есть cas array(балансировщик аппаратный), есть приложение использующее ews, url ews приложение получает через autodiscover (internal url).
При удалении SPN с 2007 сервера и добавление на 2010, приложение не может авторизоваться на ews, 401 ошибка The target principal name is incorrect

Алексей Богомолов (Alexx) комментирует...

Попробуйте посмотреть в сторону корректной настройки Kerberos для CAS array (http://blogs.technet.com/b/kpapadak/archive/2011/03/13/setting-up-kerberos-with-a-client-access-server-array.aspx)
Или пропишите для EWS URL конкретного CAS-a и посмотрите будет ли работать вообще.

Chit Bit комментирует...

еще по поводу работы CAS array в среде VMWare ESX: кроме включения режима Multicast(многоадресный) в настройках самого NLB, нужно еще прописать в сетевом оборудовании arp-запись с ip-адресом и мак-адресом самого NLB. (я столкнулся с этой проблемой при миграции Exchange с Hyper-V на ESX - перестал работать доступ к owa снаружи, а внутри - работало).

Павел Попов комментирует...

Алексей, подскажите...
Имеем настроенный рабочий кластер с именем mail.domain. В него включены два сервера dag1.domain и dag2.domain. Реплицированы базы, отказоустойчивость работает корректно.
Проблема в том, что при настройке клиентских Outlook, когда указываем в качестве сервера имя кластера mail.domain, имя пользователя или почтовый ящик, при нажатии кнопки "Проверить имя" вместо имени кластера подставляется имя одного из серверов dag1.domain или dag2.domain, после чего клиент нормально работает. Имхо это неправильно, т.к. клиент использует имя конкретного сервра, а не имя кластера mail.domain. Соответственно при падении сервера на который настроен клиент теряется весь смысл кластера.
Подскажите, почему имя кластера подменяется именем одного из серверов и как от этого избавиться ?

Алексей Богомолов (Alexx) комментирует...

Для базы данных в которой лежит ящик надо прописать корректное имя в параметр rpcclientaccessserver
set-mailboxdatabase ... -rpcclientaccessserver mail.domain...

Павел Попов комментирует...
Этот комментарий был удален автором.
Павел Попов комментирует...

Алексей, так не получается:

Не удалось найти Exchange server "mail.domain". Убедитесь, что имя сервера введено правильно.
строка:1 знак:1
+ <<<< Set-MailboxDatabase "Mailbox Database 0427332342" -RpcClientAccessServer mail.domain
+ CategoryInfo : NotSpecified: (:) [], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : D00DF02A

Может быть сначала надо сделать:
New-ClientAccessArray –Name “name of CAS array” –Fqdn

Алексей Богомолов (Alexx) комментирует...

У Вас Client Asscess array настроен? Get-ClientAccessArrayч то говорит по поводу имени?

Павел Попов комментирует...

вообще ничего не отвечает:
......
ПОДРОБНО: Подключение к dag1.domain
ПОДРОБНО: Подключен к dag1.dmain
[PS] C:\Windows\system32>Get-ClientAccessArray
[PS] C:\Windows\system32>

Павел Попов комментирует...

настраивал даг не я, подозревают, что ClientAccessArray не создавался

Алексей Богомолов (Alexx) комментирует...

Надо создать из 2-х CAS серверов CASarray и прописать его имя в rpcclientaccessserver для всех баз

Анонимный комментирует...

Здравствуйте, Алексей. Хочу обеспечить отказоустойчивость Exchange 2010 указанным способом. Для этого есть мощный сервер с дисками большого объема. Но проблема в том, что сервер Exchange 2010 уже существует и работает на другом железе, все 3 роли на 1 сервере. Размер базы достаточно большой - 1 Тб. Как лучше провести миграцию? Сначала мигрировать CAS, потом Hub, а базу перенести на DAG в последнюю очередь? Спасибо. С уважением, Игорь.

Павел Попов комментирует...

Алексей, подскажите как правильно сделать... Все те же 2 сервера exchange 2010 с именами dag1.domain и dag2.domain. Сейчас имеют белые ip и соответственно каждый свои MX и PTR записи в DNS. Хотим убрать их за NAT. Для принимающих от нас почту серверов будут видны под одним ip. Как правильно прописать записи PTR? Ведь не может один ip разрешаться в два разных имени. Или лучше настроить ответы HELO/EHLO, чтобы оба сервера представлялись одним именем ?

Алексей Богомолов (Alexx) комментирует...

Мне кажется, лучше поменять HELO\EHLO в настройках Send\Receive Connector`ов на одно общее имя. Не забывайте про сертификат, привязанный к службе SMTP.

Отправить комментарий