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
Для этого построим принципиальную схему организации почтовой системы предприятия: 
Рис.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.
Рис.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.
Рис.3: Доменная группа Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.
Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:
Рис.5: Добавление серверов в группу DAGПосле нажатия кнопки Manage будет произведена настройка и конфигурирование выбранных серверов, в частности, на них будут установлены необходимые составляющие компонента Диспетчер отказоустойчивости кластеров и сконфигурирован сам кластер.
Примечание: Если что-то пошло не так и кластер не собрался, то часто бывает трудно оценить проблему по тексту ошибки, выданному Exchange`м, в такой ситуации может помочь функция проверки узлов кластера в Диспетчере отказоустойчивости кластеров, которая дает гораздо больше информации по присутствующим проблемам:
Рис.6: Проверка кластера.Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:
New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5
Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:
Рис.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:
Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…
Рис.9: Обновление копии базы данных почтовых ящиков.Перейдем к настройке массива серверов CAS
Принципиальная схема взаимодействия серверов в массиве будет выглядеть следующим образом:
Рис.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-адрес этой системы:
Рис.11: Настройка DNS сервера.Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.
Рис.12: Создание нового кластера NLB.
Рис.13: Настройка параметров кластера.Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!
Подробнее про принцип работы NLB можно посмотреть здесь.
Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!
Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с Microsoft Hyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.
Рис.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).
Теперь осталось только собрать сам CAS массив.
Для этой цели воспользуемся командлетом New-ClientAccessArray:
New-ClientAccessArray -FQDN “mail.test-mail.local” –Site “Default-First-Site-Name”
И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:
Set-MailboxDatabase -RpcClientAccessServer “mail.test-mail.local”
Рис.15: Создание CAS массива.На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.
Рис.16: Настройка MS Outlook.Использование аппаратного балансировщика сетевой нагрузки (NLB).
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
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.local/Microsoft-Server-Activesync -BasicAuthentication $True
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -InternalUrl https://mail.domain.local/oab
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -InternalUrl https://mail.domain.local/ews/exchange.asmx
Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.local/unifiedmessaging/service.asmx
Можно настроить сразу 2 адреса – внешний и внутренний:
Autodiscover Service
Set-ClientAccessServer –Identity <Server Name> -AutoDiscoverServiceInternalUri: https://mail.domain.local/Autodiscover/Autodiscover.xml
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -ExternalURL https://mail.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True
Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -ExternalURL https://mail.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -ExternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -ExternalUrl https://mail.domain.com/oab;
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -ExternalUrl https://mail.domain.com/ews/exchange.asmx
Статьи для подробного изучения:
- Рассмотрение групп доступности баз данных Exchange 2010 (цикл статей) - http://www.oszone.net/9512/Exchange_Server_2010
- Новая служба RPC Client Access Service в Exchange 2010 (цикл статей) - http://www.oszone.net/9512/Exchange_Server_2010
- Rus - http://technet.microsoft.com/ru-ru/library/dd351078.aspx
- Eng - http://technet.microsoft.com/en-us/library/dd351078.aspx
Сообщения
71 комментарий:
Алексей, добрый день. NLB сервер который вы конфигурируете в этой статье, это некий новый сервер? Или это настраивается на одном из существующих в рамках данного тестового стенда (mailbox, cas, и т.д.)?
NLB массив формируется/настраивается из 2-х уже существующих CAS серверов в рамках лабораторного стенда.
Алексей, добрый день. Очень понравилась ваша статья и вэб-каст. Очень подробно и понятно, но, тем не менее, у меня есть 3 вопроса:
1) Считается ли лучшей практикой разнесение ролей СЕРВЕР ПОЧТОВЫЙ ЯЩИКОВ и CAS+HUB на 2 разных сервера? Вопрос возник потому, что Microsoft пишет, что для обеспечения полной отказоустойчивости всех сервисов и данных достаточно 2-х серверов (я имею ввиду оборудование). Послушав ваш вэб-каст, я узнал о том, что NLB-кластер не может быть сделан из тех серверов, на которых установлена роль СЕРВЕР ПОЧТОВЫХ ЯЩИКОВ. Получается, что нужно минимум 4 сервера.
2) Как вы бы рекомендовали поступить с бэкапом баз данных? Чем лучше делать? Как распологать?
3) Как правильно подойти к вопросу выбора дискового хранилища? Я собираюсь приобрести SAN-хранилище, но не могу понять, как правильно посчитать объем, необходимый для хранения баз.
С уважением, Кобзарев Д. В.
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?
С уважением, Кобзарев Д. В.
Если сервера в разных сайтах, то это совсем другая тема! Про разнесение серверов по сайтам почитайте вот тут - 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?
С уважением, Кобзарев Д. В.
для HUB`a не нужен NLB, если в сайте установлено более одного HUB`a, то отказоустойчивость этой роли будет организована автоматически вынутренними механизмами сервера Exchange. Так что HUB можно совместить с любой другой ролью.
Добрый день, Алексей!
Спасибо за вашу статью и вэб-каст. Очень интересно и познавательно. Однако вот какой вопрос возник :) Вы утверждаете, что если не поднимать DAG на серверах с ролью Mailbox, то при отправке почты сервер будет искать HUB Role который находиться на локальной машине, даже если он отключен. Как в таком случае поступать, если роли планируется разнести на 3 разных сервера, т.е. каждой роли по серверу (HUB, CAS, Mailbox)? Объединять HUB+Mailbox и делать из них DAG? Или есть какое то более изящное решение, типа объяснения/настройки Mailbox Role, что HUB это другой сервер и используй его.
Заранее спасибо,
Антон
Нет, здесь не все так категорично, возможно я немного не правильно выразился. Имеется ввиду, что если Mailbox не в DAG-группе, то он будет преимущественно обращаться к локальному HUB`y, если же в DAG`e - то преимущественно к удаленному.
Это не означает, что если локальный не отвечает или его нет вовсе, то он не будет искать его где-то ещё. Информация о то где находятся HUB`ы хранится в базе AD, следовательно Mailbox будет перебирать их все, пока не найдет один работающий в сайте.
PS Скоро будет готов ещё один веб-каст по материалам прошедшей встречи МСР-клуба, там как раз эта тема поднимается ещё раз немного подробнее.
Добрый день, Алексей!
Подскажите как в группе DAG настроить CAS если не соединять их в массив?
Александр
Александр, что вы имеете ввиду под словом "как"? Нужно установить роль CAS на один из узлов массива DAG и все! Либо установить несколько CAS-ов, но при этом распределить по ним различные сервисы, например MAPI-клиенты будут подключаться к одному серверу, а OWA-клиенты в другому, все остальные к третьему и т.п.
"Александр, что вы имеете ввиду под словом "как"? Нужно установить роль CAS на один из узлов массива DAG и все!"
Для реализации "отказоустойчивости" :) я поставил на оба Exchange сервера роль CAS но как правильно этим пользоваться я не могу разобраться, подскажите Алексей пожалуйста как правильно реализовать мой замысел?
Спасибо за ответы!
Александр.
>Для реализации "отказоустойчивости" :)
Для реализации отказоустойчивости вам надо CAS-ы объединить в массив (CAS-array), но для полноценной работы массива (не только MAPI клиенты, но и все другие) вам необходимо использовать сетевую балансировку (NLB), соответственно надо взять "железный" балансировщик, либо воспользоваться службой Windows NLB, но тут проблема в том, что WNLB совместно с Failover Cluster`ом не живет, а FC нужен для работы DAG.
Мораль - если у вас нет аппаратного NLB, то вам придется роли Mailbox и CAS разносить по разным серверам Exchange.
Интересно, а можно ли как в старом добром exchange2007 сделать простую репликацию базы данных?
То есть не лепить огород из нескольких серверов, а просто тупо сделать так, чтобы одновременно файлы базы реплицировались на другой раздел этого же сервера? Чтобы для начала защититься хотябы от физического краха носителя. Просто пока нет возможности купить второй сервер и лицензии к нему, да и организация небольшая, всего 50 ящиков, одного сервера для всех ролей вполне хватает. Но хотябы базу защитить хочется.
А динамические диски Вам не помогут защититься от "физического краха" носителя?
1. Защитить базу проще всего при помощи бэкапа.
2. А про динамические диски можно чуть подробнее?
Алексей спасибо за пост.
Скажи что будет когда перезагрузить сервер свидетель в работающей среде ДАГ.
Как сервера себя поведут в этом случаи ?
И что будет когда перезагрузить один из серверов из группы ДАГ. ?
Если оба сервера в даге работают нормально, то свидетель можно ребутать без проблем. А вот если свидетель будет выключен в тот момент, когда упадет сервер с активной базой, вот тогда кластер упадет полностью, т.е. база на другой ноде не активируется!
Спасибо.
А что произойдет когда я ребутну сервер с автивной базой данных? В теории база должна будет завестись на втором сервере .
Но что произойдет когда первый сервер поднимится после ребута, база обратно станет активной на нем? Или придется руками переключать.
Это зависит от того настроен ли предпочтительный владелец в свойствах кластера.
А где именно это настраивается? И как правильно выставить владельца ? Какой сервер назначать владельцем?
Нашел. Там оба сервера выделены как владельцы.
Как тогда они поступят при :
"А что произойдет когда я ребутну сервер с автивной базой данных? В теории база должна будет завестись на втором сервере .
Но что произойдет когда первый сервер поднимится после ребута, база обратно станет активной на нем? Или придется руками переключать. "
Предпочтительны владелец настраивается в свойствах копии базы.
Ага. Если предпочтительный сервер БД1 есть сервер 1, то при его ребуте база переключится на сервер2 , и после того как сервер поднимется после ребута она автоматически переключится на сервер1 обратно ?
Да, в этом случае, в течении нескольких минут база должна вернуться.
Распределил все базы данных по на 2 сервера поровну , назначил предпочтительных владельцев.
После перезагрузки сервера базы переключились на другой сервер , но после возвращения сервере с перезагрузки бази не переключаются обратно .
То же самое происходит при переключении через Switchover.
Так должно быть ?
Алесей, здравствуйте.
Перерыл гору материалов, но так и не нашел точный ответ: при развертывании DAG в домене с 2-мя сайтами, нужен ли сервер-свидетель в каждом сайте?
Не совсем понятно зачем вы ноды Exch`a разносите по разным сайтам. Вы строите катастрофоустойчивое решение?
Если нет, то не важно в каком сайте у вас будет свидетель.
PS Он все равно будет только один.
Алексей, как корректно собрать кластер из отказоустойчивых Edge серверов?
нужно ли на edge сервера устанавливать роль NLB или Failover Cluster?
Нет, ни чего не нужно устанавливать. Просто делаете две Edge подписки + для входящей почты устанавливаете 2 МХ записи с одинаковыми приоритетами.
а мы дали CAS тот же ip, что и у DAG, и работают оба кластера на 2-х серверах.Но остались сомнения,не грозит ли это какими-нибудь непрмятностями.
Нет, это официально не поддерживаемая Microsoft-ом, но рабочая конфигурация. Проблем быть не должно.
как быть с запросом на сертификат на "mail.test-mail.local” ?
А какие именно проблемы с запросом сертификата?
Есть две машины delta и Sigma они в массиве Alpha(у Вас это mail.test-mail.local)у них при подключении к Оутлуку ругается на alpha.хххх.хх что Имя сертификата не допустимо или не соответствует имени сайта"
будет ли статься по созданию DAG-кластеров на основе hyperv? пока, к сожалению, не получается поднять(( основные проблемы - не вводится второй нод, отваливается кластерное имя и еще по мелочам...
Статья написана на базе тестового стенда, который собран на хосте Hyper-V, т.е. по факту, это и есть DAG кластер на виртуалках Hyper-V.
Имелось ввиду DAG на узлах Hyper-V включенных в Failover Cluster и, соответственно, использующих Cluster Shared Volumes.
для балансировки сетевой нагрузки нужен отдельный сервер или настраивается на одном из сереверов которые в CAS ??
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}
Смущает предупреждение
Почему смущает? Это говорит о том, что у вас свойство 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?
У вас здесь ошибка:
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
И снова ошибка:
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.local/Microsoft-Server-Activesync -BasicAuthentication $True
Правильный параметр не -BasicAuthentication, а -BasicAuthEnabled
Спасибо за поправку.
Алексей, "разжуйте" :), плиз, следующую ситуацию:
Есть основной сервер Ex2010. Поставил второй. Хочу настроить отказоустойчивость, т.е. при выходе из строя основного сервера, второй продолжал обслуживать клиентов, отпралял почту и содержал базу с первого. Я так, понимаю, нужно настроить DAG и CAS. В качестве балансировщика планирую nginx на виртуалках(в heartbeat).
Как мне правильнее и безболезненнее это сделать?
Особенно касаемо сертификатов и доступа клиентов извне и изнутри.
DAG собираете штатно, и также создаете CAS array, только Windows Load BAlancer не настраиваете, т.к. у вас будет сторонний. После чего публикацию веб-служб настраиваете на FQDN CAS Array`a. В сертификатах должны быть те имена, по которым к Exch`y обращаются клиенты по 443-му порту.
т.е. я создаю сертификат для CAS типа mail.domain.com и autodiscover.domain.com, что делать с сертификатами для не веб? (smtp).
Можно использовать внутренний PKI или нужны все-таки белые сертификаты итого понадобится 3?
На сам сервер вы можете поставить сертификат локального СА и включить плюсом туда имя сервера, чтобы 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 серверов?
Да, нужно на всех выполнить.
Алексей, еще раз здравствуйте. А не могли бы объяснить, для чего это нужно сделать?
Ситуация, как я вижу: клиент обращается в АД за списком SCP, в котором указан один единственный SCP железного балансировщика. Уже в настройках балансировщика задается список серверов с autodiscover.
Ну, т.е. клиент всегда общается с серверами через балансировщик.
Да, а что вас смущает в этом решении? Просто обычно в SCP прописан первый CAS сервер в организации, соответственно эту настройку лучше переписать на массив.
Алексей, спасибо за статью!
Не так давно мигрировали с 2007 exchange на 2010.
Столкнулся с проблемой, есть cas array(балансировщик аппаратный), есть приложение использующее ews, url ews приложение получает через autodiscover (internal url).
При удалении SPN с 2007 сервера и добавление на 2010, приложение не может авторизоваться на ews, 401 ошибка The target principal name is incorrect
Попробуйте посмотреть в сторону корректной настройки 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 и посмотрите будет ли работать вообще.
еще по поводу работы 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. Соответственно при падении сервера на который настроен клиент теряется весь смысл кластера.
Подскажите, почему имя кластера подменяется именем одного из серверов и как от этого избавиться ?
Для базы данных в которой лежит ящик надо прописать корректное имя в параметр 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
У Вас Client Asscess array настроен? Get-ClientAccessArrayч то говорит по поводу имени?
вообще ничего не отвечает:
......
ПОДРОБНО: Подключение к dag1.domain
ПОДРОБНО: Подключен к dag1.dmain
[PS] C:\Windows\system32>Get-ClientAccessArray
[PS] C:\Windows\system32>
настраивал даг не я, подозревают, что ClientAccessArray не создавался
Надо создать из 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, чтобы оба сервера представлялись одним именем ?
Мне кажется, лучше поменять HELO\EHLO в настройках Send\Receive Connector`ов на одно общее имя. Не забывайте про сертификат, привязанный к службе SMTP.
Отправить комментарий