В этой статье мы поговорим о подключении iSCSI для настройки серверов mailbox, группах доступности DAG, массиве CAS array, и создадим NLB кластер.
Продолжаем настраивать наш почтовый сервер. В предыдущих статьях мы подняли тестовый стенд Hyper-v, и установили на него Windows server 2008 и Exchange 2010. Сегодня приступим к настройке.
Рекомендую для понимания работы exchange server, ролей и взаимодействия между ними, посмотреть следующий постер: Exchange 2010 Poster
Давайте протестируем, как работает наш сервер, зайдем с виртуальной машины с Windows 7 на веб интерфейс, и попробуем настроить outlook.
Создание нового почтового ящика
Для начала создадим в домене нового пользователя. Открываем оснастку users and comptuters, создадим (по желанию) новый organization unit (OU), например users test и в нём создадим пользователя Ivan Ivanov. Как видите, значок OU отличается от обычного контейнера внешним видом. Основное отличие контейнера OU от обычного контейнера – возможность привязывать к нему групповые политики.
Переходим в exchange management console, recipient configuration, mailbox, new mailbox.
Выбираем user mailbox, existing users и видим нашего нового пользователя.
Alias оставляем предложенный (или придумываем свой) и ниже можем выбрать базу, куда положить ящик, а также задать различные политики.
У exchange 2010 работает механизм автоматического распределения по базам – automatic mailbox distribution, если база явно не указана. Так что если вы создали, например, базу archive, то нужно её исключить из распределения следующим командлетом:
Set-MailboxDatabase -identity "archive" IsExcludedFromProvisioning $True
Если Вы хотите создать ящик из командной строки, командлет будет такой:
Enable-Mailbox -Identity test\iivanov -Database Database01
Проверяем OWA и ECP
Теперь из нашей пользовательской машины на Windows 7 (которую мы завели в домен) пытаемся зайти на веб-интерфейс по адресу https://cas1.test.ru/owa, настройки же для интерфейса пользователя OWA (outlook web access) и интерфейса администратора ECP (exchange control panel) можно посмотреть на вкладке server configuration – client access, должно работать по умолчанию.
При заходе на https://cas1.test.ru/owa мы видим ошибку сертификата, так как своего центра сертификации (CA – certification authority) у нас пока нет.
Что бы браузер не ругался на сертификат, можно добавить его в доверенные корневые центры сертификации.
Теперь у нас всё хорошо. Пробуем отправить сообщение пользователю iivanov, как видим, он появился у нас в адресной книге.
Пробуем послать тестовое письмо, заходим в ящик под аккаунтом пользователя iivanov@test.ru и удостоверяемся что письмо дошло.
Отлично, тут всё работает. Теперь проверим outlook. Он тоже может ругаться на сертификат, если подключается через cas2. Просто добавляем и его в доверенные корневые центры сертификации.
Важный момент – обязательно должен быть прописан шлюз в сетевых настройках, иначе outlook откажется подключаться. В нашем случае подключение прошло успешно.
Как outlook определяет, к какому CAS подключаться? При создание сервера CAS в AD прописывается SCP – service connection point. Outlook запрашивает SCP, выбирает те, которые находятся в одном сайте с ним, и выбирает по параметру WhenCreated – то есть по дате создания, выбирая самый старый. Если он не доступен – то идёт дальше по списку. Данное утверждение справедливо для службы autodiscover.
Сам же outlook выбирает в качестве сервера, client access тот, который прописан в атрибуте RPCClientAccessServer базы данных пользователя. Сведения о базе данных и сервере mailbox, на котором она лежит, берутся из AD. Поэтому и нужно создавать массив CAS array, тогда вместо одного сервера CAS в атрибуте будет прописан FQDN массива.
Для просмотра всех параметров с помощью powershell, можно сделать выборку командлетом Get-ClientAccessServer.
Get-ClientAccessServer | fl
Для выборки нужных полей и удобочитаемости, используем параметр fl (он же Format-List) или ft (он же Format-Table), например Name, OutlookAnywhereEnabled, WhenCreated, WhenChanged, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope.
Get-ClientAccessServer | fl Name,OutlookAnywhereEnabled,WhenCreated,WhenChanged,AutoDiscoverServiceInternalUri,AutoDiscoverSiteScope
Политика паролей
По умолчанию у нас установлена политика сложных паролей (Password must meet complexity requirements), что бы не придумывать каждому тестовому пользователю восьмизначный разнорегистровый пароль, давайте её отредактируем.
Заходим в оснастку group policy managment, выбираем политику password policy, и ставим параметр Password must meet complexity requirements в значение disabled.
Я еще установил минимальную длину пароля (Minimum password lenght) в 4 символа.
После этого можно задать пользователю пароль 1234. Обновить политику можно командой gpupdate /force.
Подключаем Database по iSCSI
Давайте теперь представим, что базы у нас будут лежать на хранилище, или на другом сервере под управлением windows 2008r2, в котором у нас есть некий большой дисковый массив RAID, и который называется database.
Немного терминологии.
iSCSI Target (таргет) – это сервер предоставляющий доступ к своим дискам.
iSCSI Initiator (инициатор) – это клиент, который подключается к iSCSI Target.
LUN (logical unit number) – номер объекта, внутри таргета. А проще говоря, логический диск, презентуемый инициатору.
IQN (iSCSI qualified name) – полное имя участника, состоит из: год и месяц когда был зарегистрирован домен, имя домена в обратно порядке, произвольное имя.
iqn.”year-mo”.”reversed_domain_name”:”unique_name”
По умолчанию, роль цели не входит в комплект windows server 2008R2, поэтому скачиваем её отсюда.
Если нужно залить в виртуалку с нашего хоста, воспользуемся командлетом
Copy-VMFile -Name database_server -SourcePath C:\iscsiTargetqfe6.exe -DestinationPath C:\ -CreateFullPath -FileSource Host
-Name это имя виртуальной машины hyper-v
-SourcePath место куда скачали файл
-DestinationPath место куда положить файл на виртуалке,
-CreateFullPath создать путь, если его нет
-FileSource тип источника
Устанавливаем программу, и запускаем.
Создаём цель (target)
Даём название цели и описание
Теперь нам нужно задать разрешения для инициаторов и вписать IQN.
Сделать это можно довольно просто.
Заходим на наш сервер инициатор, переходим в панель управления, и запускаем соответствующую программу – initiator iSCSI, при первом запуске она запустит свою службу.
В окне configuration мы найдём IQN нашего сервера.
Но что бы не копировать его можно сделать проще. Переходим на вкладку Targets, вводим в поле target адрес нашего сервера цели, и нажимаем quick connect.
Теперь переходим на сервер database, нажимаем кнопочку Browse, и видим IQN тех серверов, которые пытались подключится.
Переходим в devices, и создаём виртуальный диск.
Выбираем, какой цели презентуем данный диск.
С таргетом закончили. Переходим на сервер инициатор, открываем Microsoft iSCSI initiator, targets, quick connect к серверу target.
Готово, диск подключился. Проверяем в оснастке управления дисками.
Инициализируем и размечаем диск, теперь на нём можно создавать базы exchange.
Собираем кластер DAG
Давайте теперь займёмся отказоустойчивостью наших баз. Философия DAG, или же Database Availability Group заключается в хранении копии базы данных на соседних серверах mailbox. Допустим, у нас 4 сервера почтовых ящиков, на каждом по 1 почтовой базе. При включении этих серверов в группу DAG, На каждом сервере будет одна активная база, и 3 копии пассивных баз, с трех других серверов. Избыточность вполне достаточная.
Причем в случае отказа одного из серверов, переключените на другую базу произойдет прозрачно для пользователя.
В группу DAG может входить до 16 серверов mailbox, поэтому при определённой избыточности, можно не заботится об отказоустойчивых дисковых массивах, а установить сервера на то, что имеется в наличии. Но естественно копий в данной случае чем больше – тем лучше.
Для начала добавим дополнительные сетевые интерфейсы на наши сервера mailbox, через них мы настроим трафик репликации DAG.
Настраиваем интерфейсы в отдельной сети. В моём случае это 192.168.200.0\24
Настроим у mailbox1 – 192.168.200.1, у mailbox2 – 192.168.200.2
И немного изменим настройки сетевых карт, которые мы назовём DAG.
Уберём лишние галочки.
Уберём галочку Register this connection’s addresses in DNS, не нужно нам повторно регистрировать сервер с другим IP.
Теперь нажмём кнопку ALT, увидим такое меню, и зайдём в “Advanced settings”.
Поставим DAG второй сетевой картой, а нашу основную первой. Это нужно что бы трафик по умолчанию шёл через основную сетевую карту.
Теперь нам надо выбрать кто будет сервером свидетелем или witness server. Это может быть любой сервер не входящий в члены DAG. В группу его локальных администраторов должна входить группа Exchange Trusted Subsystem, что бы иметь доступ к папке.
Сервер нужен при четном количество участников кластера. Если вдруг сервера теряют связь между собой, то они обращаются к серверу свидетелю, что бы определить кому из них собственно продолжать работать с активными базами, а кому с пассивными, что бы не произошли коллизии, когда оба сервера работают с одной базой. У нас сервером witness выступит сервер database.
Также можно создать альтернативный witness сервер, на случай отказа текущего, командлет:
Set-DatabaseAvailabilityGroup -Identity dag_name -AlternateWitnessServer server_name -AlternateWitnessDirectory C:\DAG1
Кому интересно, командлет создания кластера:
New-DatabaseAvailabilityGroup -Name DAG -WitnessServer database -WitnessDirectory C:\DAG
У меня при создании кластера получилась следующая ошибка: “The Exchange Trusted Subsystem is not a member of the local Administrators group”
Решилась она добавлением сервера в группу Exchange Trusted Subsystem.
Теперь нам нужно отредактировать нашу группу, и добавить туда сервера mailbox.
Поначалу тоже не “подожглось”, ошибки были следующие:
“Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-ExchangeServer -UseWIA $true -SuppressError $true’.”
“A server-side database availability group administrative operation failed. Error: The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error 0x6f7 (The stub received bad data)”
Мне помогло прописать шлюз на сетевых интерфейсах (не DAG), и установить вручную на серверах mailbox службу Failover Clustering, после этого кластер собрался.
Теперь выключим репликацию по пользовательской сети 192.168.100.0
Проверим создание кластера командлетом:
Get-DatabaseAvailabilityGroup
И статус сетей репликации:
Get-DatabaseAvailabilityGroupNetwork
Также DAG должен получить IP адрес, если у нас включен DHCP. В DNS о зарегистрируется по именем кластера. Посмотреть IP можно в настройках failover cluster manager.
Зайдём на сервер mailbox, откроем оснастку failover clustering, и запустим проверку кластера – validate this cluster, на выходе получим отчет всех параметров в html.
Теперь добавим базы для репликации на другие серверы.
В нашем случае я добавил базу database1 на сервер mailbox2 и базу database2 на сервер mailbox1
Командлет для проверки:
Get-MailboxServer | Get-MailboxDatabaseCopyStatus
Можно проверить работу кластера отключив один сервер. Отключим database2. Как видим, failover сработал, база переключилась со 2-го на первый сервер.
Собираем CAS array и NLB
Теперь осталось закончить собирать отказоустойчивую систему. Базы мы защитили от сбоя, теперь соберём в отказоустойчивый кластер CAS серверы.
Оба сервера мы добавим в балансировщик wNLB для балансировки нагрузки, и соберём массив CAS array, FQDN имя которого будет указывать на IP адрес wNLB.
Для начала добавим на CAS еще по одному сетевому адаптеру. Для нормальной работы wNLB на виртуальной машине Hyper-v необходимо включить статический MAC (дабы он не менялся в процессе работы, потому что это критично для балансировщика) и включим спуфинг MAC адресов, то есть подмену.
Сразу после добавления адаптера MAC пустой, поэтому просто включите и выключите виртуалку.
С сетевыми адаптерами проделаем такие же манипуляции, как при создании DAG, пропишем вручную IP, снимем лишние галочки с протоколов, галочку регистрации в DNS, и поставим интерфейс NLB вторым в списке привязки.
Теперь создадим в DNS запись, которая будет указывать на виртуальный IP нашего балансировщика.
Устанавливаем компонент network load balancing.
Создаём новый кластер.
Указываем имя первого сервера – cas1.
Следующее окно без изменений.
Теперь вписываем IP адрес, который мы ранее зарезервировали в DNS под именем mail.test.ru.
Вписываем имя нашего будущего кластера, режим работы одноадресный (Unicast), при работы в WMvare multicast.
Теперь нужно настроить порты, если не хотите – можно оставить как есть, по умолчанию слушаем все.
- TCP 25 – Отправка почты по SMTP
- TCP 80 – Перенаправление HTTP > HTTPS в IIS
- TCP 110 – Получение почты по POP3
- TCP 143 – Подключение по IMAP4
- TCP 443 — Outlook Anywhere, Exchange ActiveSync и Outlook Web App
- TCP 135 – MAPI RPC для подключения клиентов
- TCP 1024-65535 – MAPI RPC (Динамический диапазон RPC) для подключения клиентов
- TCP 993 – Secure IMAP
- TCP 995 – Secure POP
Для портов 993 и 995 Affinity устанавливаем None.
Filtering mode – режим фильтрации трафика. Multiple host – трафик будет распределяться между узлами трафика.
Affinity – определяет привязку клиента к определенному узлу кластера.
None – без привязки,
Single – привязка по IP, в течении сеанса все соединения будут направляться на один узел.
Network – привязка по подсети, когда клиент устанавливает соединение все клиенты из этой подсети подключаются к одному узлу.
Настраиваем второй узел кластера – cas2. Выбираем add host to cluster.
Выбираем CAS2, в следующем окне выставляем priority 2.
Получаем законченный кластер, с именем mail.test.ru и ip 192.168.100.100
Теперь соберем массив CAS, для этого используем командлет:
New-ClientAccessArray -FQDN “mail.test.ru” –Site “test”
Не забывайте что я переименовал сайт, в котором находится exchange, по умолчанию у Вас будет “Default-First-Site-Name”
Теперь осталось подключить к массиву базы данных почтовых ящиков:
Get-MailboxDatabase | Set-MailboxDatabase –RpcClientAccessServer mail
Теперь проверяем, запустим outlook, и проверим куда он подключается.
Как видим, всё работает так как должно, для подключения используется общий адрес.
В следующей статье мы настроим EDGE сервер, TMG, и работу почты с внешним доменом.
Если у Вас есть вопросы, задавайте их на форуме, или ниже в комментариях.
Годная статья. Информация раскрыта, что надо, в т.ч. и некоторые моменты, которые не относятся к Exchange, например настройка сетевых адаптеров и настройка виртуальных коммутаторов в Hyper-V.
Около двух лет назад сам разворачивал CAS Array + DAG, столкнулся с некоторыми моментами, как раз с Hyper-V, тогда эта статья мне бы очень пригодилась, но пришлось отчаянно читать Technet и гайды по NLB.
Жду следующую часть.
Спасибо.
Спасибо за отзыв. Да, большинство статей в интернете описывает настройку шаблонно, без объяснения значения настроек, я стараюсь максимально понятно описать, за что отвечают те или иные настройки, что бы можно было настроить не просто “что бы работало”, а работало так как нужно, в зависимости от среды и текущих требований. Следующая статья скоро появится.
Предложу небольшое дополнение.
При создании массива CAS в ваш массив попадут все серверы Exchange 2010 в этом сайте AD, на которых настроена роль CAS.
Да, в выводе командлета “New-ClientAccessArray -FQDN “mail.test.ru” –Site “test”” мы видим поле members, в котором указаны наши сервера Client access.
Посмотреть все существующие CAS Arrays можно с помощью командлета
Get-ClientAccessArray.