Доброго времени суток!
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)
Итак, если наша задача – построить отказоустойчивую почтовую систему на базе Exchange 2010, то единственным (приемлемым) вариантом будет использование DAG (Database Access Group).
Помимо DAG нам потребуются еще несколько серверов для обеспечения отказоустойчивости необходимых ролей Exchange. О них будет рассказано чуть позже.
Мне требовалось достичь следующих целей:
• Отказоустойчивость для клиентов использующих Outlook во внутренней сети
• Частичную отказоустойчивость для клиентов использующих Outlook через RPC over HTTPS из Интернета
• Частичную отказоустойчивость для клиентов ActiveSync
• Свести к минимуму вероятность потерять входящую (из Интернета) почту
В связи с поставленными передо мною целями я стал работать по следующей схеме (небольшое уточнение – канал между датацентром и офисом 30 Мб/с синхронный):
Напомню, что в Exchange 2010 элементами DAG-массива могут быть не только Mailbox-сервера, поэтому это сильно упрощает работу в сравнении с версией 2007.
Первое что я делаю – это выношу Edge Transport в DMZ средствами TMG и на том, и на другом сайте.
В DNS-записях для своего домена я прописываю 3 MX записи с различным приоритетом – одна указывает на TMG в Datacenter, другая на шлюз в Office, третья на резервный канал в офисе, который также заведен в TMG и настроен через ISP Redundancy (Failover). Это делает выполненным четвертый пункт из списка моих целей – свести к минимуму вероятность потерять входящую почту.
В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе. Единственным вариантом, при котором почта все-таки может не дойти, если интернет пропадет сразу и в датацентре, и в офисе (на двух каналах!) более чем на 30 минут.
Следующее — это обеспечить отказоустойчивость для клиентов, использующих Outlook 2010 во внутренней сети. Для этого требуется обеспечить отказоустойчивость роли Mailbox и Client Access.
На 2х Exchange-серверах с ролью Mailbox на разных сайтах создается 2 базы данных – одна активна на первом сайте, вторая активна на другом.
Для чего это нужно:
1) Распределение нагрузки, если все работает в штатном режиме.
2) В случае если сервер в датацентре выходит из строя/становится недоступен, в офисе у нас есть копия базы, которая автоматически перейдет в Active mode. Пользователи смогут продолжить работу.
3) Возможность проводить сервисное обслуживание серверов, переключая активные сервера «на горячую».
При создании DAG-кластера из GUI, Вам потребуется указать как минимум один сервер File Witness. Сервер File Witness (файловый свидетель), если говорить очень грубо, это сервер с расшаренной папкой, который будет поддерживать голоса в кворуме, в случае выхода из строя одного из Mailbox серверов. Он нужен для того, чтобы после того, как сервера, которые были некоторое время недоступны, станут Back-online, смогли синхронизировать (читай реплицировать) изменения с других членов кластера и при этом не «запутаться», что на них уже есть, а чего не хватает.
Я создал по одному File Witness серверу на каждом сайте (т.к. в случае падения интернета на одном из сайтов, для второй части Exchange-сервера становятся недоступны как Mailbox, так и File Witness сервера) для поддержания кворума. Но задача обеспечить отказоустойчивость клиентов Outlook еще не выполнена.
На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».
Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.
На NLB я настроил балансировку нагрузки между двумя серверами Exchange с ролью Client Access.
При этом эти сервера [прим. – Client Access] не являются серверами Mailbox! Настоятельно рекомендую Вам разносить данные роли по различным серверам/виртуальным серверам.
Теперь для клиентов Outlook сервером (который мы указываем при настройке учетной записи) является сервер NLB. Для того, чтобы обеспечить еще большую отказоустойчивость (на случай выхода из строя одного из NLB-серверов), я создал в домене 2 DNS-записи типа A с одинаковыми именами (exchange.contoso.com к примеру), каждая из которых ссылается на различные NLB-сервера.
При этом благодаря технологии DNS Round Robin в случае выхода из строя 1 из NLB серверов около 50% клиентов будут работоспособны. Безусловно, тут также вступает в дело DNS-кэш, однако об этом и о Round Robin Вы можете отдельно прочитать в базе знаний Microsoft.
Так я выполнил первый пункт из списка своих целей – отказоустойчивость для клиентов Outlook во внутренней сети.
Небольшое дополнение – на NLB я настроил VIP-адреса (вся внутренняя подсеть), которые ВСЕГДА (за исключением, когда сервер недоступен) будут работать с Exchange в офисе – для уменьшения траффика в интернет и увеличения быстродействия. Только в случае, если 1 из серверов выходит из строя, клиенты переключаются на другой Client Access-сервер (между прочим это правило действует также и для мобильных устройств, которые подключаются к офисному Wi-Fi, т.к. на их DNS-запросы возвращаются IP-адреса из локальной сети). Для меня это было актуально, т.к. на втором сайте у меня клиентов нет.
Осталось еще 2 пункта, которые относятся к клиентам вне локальной сети. Тут все очень просто – в публичных записях DNS для своего домена я опять указываю две (на этот раз две, для того, чтобы сэкономить траффик на резервном канале в офисе) записи типа A, которые ссылаются на внешний IP Forefront TMG в датацентре и на соотв. IP-адрес в офисе. Службы Autodiscover активны и там, и там.
И опять благодаря технологии DNS Round Robin обеспечивается частичная отказоустойчивость клиентов ActiveSync и RPC over HTTPS.
P.S. Буду рад Вашим вопросам и конструктивной критике.
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)
Итак, если наша задача – построить отказоустойчивую почтовую систему на базе Exchange 2010, то единственным (приемлемым) вариантом будет использование DAG (Database Access Group).
Помимо DAG нам потребуются еще несколько серверов для обеспечения отказоустойчивости необходимых ролей Exchange. О них будет рассказано чуть позже.
Мне требовалось достичь следующих целей:
• Отказоустойчивость для клиентов использующих Outlook во внутренней сети
• Частичную отказоустойчивость для клиентов использующих Outlook через RPC over HTTPS из Интернета
• Частичную отказоустойчивость для клиентов ActiveSync
• Свести к минимуму вероятность потерять входящую (из Интернета) почту
В связи с поставленными передо мною целями я стал работать по следующей схеме (небольшое уточнение – канал между датацентром и офисом 30 Мб/с синхронный):
Напомню, что в Exchange 2010 элементами DAG-массива могут быть не только Mailbox-сервера, поэтому это сильно упрощает работу в сравнении с версией 2007.
Первое что я делаю – это выношу Edge Transport в DMZ средствами TMG и на том, и на другом сайте.
В DNS-записях для своего домена я прописываю 3 MX записи с различным приоритетом – одна указывает на TMG в Datacenter, другая на шлюз в Office, третья на резервный канал в офисе, который также заведен в TMG и настроен через ISP Redundancy (Failover). Это делает выполненным четвертый пункт из списка моих целей – свести к минимуму вероятность потерять входящую почту.
В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе. Единственным вариантом, при котором почта все-таки может не дойти, если интернет пропадет сразу и в датацентре, и в офисе (на двух каналах!) более чем на 30 минут.
Следующее — это обеспечить отказоустойчивость для клиентов, использующих Outlook 2010 во внутренней сети. Для этого требуется обеспечить отказоустойчивость роли Mailbox и Client Access.
На 2х Exchange-серверах с ролью Mailbox на разных сайтах создается 2 базы данных – одна активна на первом сайте, вторая активна на другом.
Для чего это нужно:
1) Распределение нагрузки, если все работает в штатном режиме.
2) В случае если сервер в датацентре выходит из строя/становится недоступен, в офисе у нас есть копия базы, которая автоматически перейдет в Active mode. Пользователи смогут продолжить работу.
3) Возможность проводить сервисное обслуживание серверов, переключая активные сервера «на горячую».
При создании DAG-кластера из GUI, Вам потребуется указать как минимум один сервер File Witness. Сервер File Witness (файловый свидетель), если говорить очень грубо, это сервер с расшаренной папкой, который будет поддерживать голоса в кворуме, в случае выхода из строя одного из Mailbox серверов. Он нужен для того, чтобы после того, как сервера, которые были некоторое время недоступны, станут Back-online, смогли синхронизировать (читай реплицировать) изменения с других членов кластера и при этом не «запутаться», что на них уже есть, а чего не хватает.
Я создал по одному File Witness серверу на каждом сайте (т.к. в случае падения интернета на одном из сайтов, для второй части Exchange-сервера становятся недоступны как Mailbox, так и File Witness сервера) для поддержания кворума. Но задача обеспечить отказоустойчивость клиентов Outlook еще не выполнена.
На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».
Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.
На NLB я настроил балансировку нагрузки между двумя серверами Exchange с ролью Client Access.
При этом эти сервера [прим. – Client Access] не являются серверами Mailbox! Настоятельно рекомендую Вам разносить данные роли по различным серверам/виртуальным серверам.
Теперь для клиентов Outlook сервером (который мы указываем при настройке учетной записи) является сервер NLB. Для того, чтобы обеспечить еще большую отказоустойчивость (на случай выхода из строя одного из NLB-серверов), я создал в домене 2 DNS-записи типа A с одинаковыми именами (exchange.contoso.com к примеру), каждая из которых ссылается на различные NLB-сервера.
При этом благодаря технологии DNS Round Robin в случае выхода из строя 1 из NLB серверов около 50% клиентов будут работоспособны. Безусловно, тут также вступает в дело DNS-кэш, однако об этом и о Round Robin Вы можете отдельно прочитать в базе знаний Microsoft.
Так я выполнил первый пункт из списка своих целей – отказоустойчивость для клиентов Outlook во внутренней сети.
Небольшое дополнение – на NLB я настроил VIP-адреса (вся внутренняя подсеть), которые ВСЕГДА (за исключением, когда сервер недоступен) будут работать с Exchange в офисе – для уменьшения траффика в интернет и увеличения быстродействия. Только в случае, если 1 из серверов выходит из строя, клиенты переключаются на другой Client Access-сервер (между прочим это правило действует также и для мобильных устройств, которые подключаются к офисному Wi-Fi, т.к. на их DNS-запросы возвращаются IP-адреса из локальной сети). Для меня это было актуально, т.к. на втором сайте у меня клиентов нет.
Осталось еще 2 пункта, которые относятся к клиентам вне локальной сети. Тут все очень просто – в публичных записях DNS для своего домена я опять указываю две (на этот раз две, для того, чтобы сэкономить траффик на резервном канале в офисе) записи типа A, которые ссылаются на внешний IP Forefront TMG в датацентре и на соотв. IP-адрес в офисе. Службы Autodiscover активны и там, и там.
И опять благодаря технологии DNS Round Robin обеспечивается частичная отказоустойчивость клиентов ActiveSync и RPC over HTTPS.
P.S. Буду рад Вашим вопросам и конструктивной критике.
