Компания Microsoft сделала новый шаг по повышению доступности почтовой системы в Exchange 2007. Высокая доступность (HA — High Availiability) делится на доступность почтовых ящиков, серверов клиентского доступа и доступность транспорта.
В последнее время мне пришлось участвовать в нескольких проектах по Exchange 2007, где высокой доступности всех компонентов системы уделялось большое внимание. Мне бы хотелось поделиться соображениями по этому поводу.
Так за счет чего собственно обеспечивается доступность транспорта (SMTP) и какие возможны сценарии?
1. Отправка почты получателю в том же сайте. В Exchange 2003 сообщение обрабатывалось внутри сервера. В Exchange 2007 даже если почта отправляется получателю, чей ящик находится на том же сервере и даже в той же базе почтовых ящиков, почта все равно пройдет через транспортный сервер (Hub Transport). Для чего это нужно?. Во первых это позволяет единообразно применять политики ко всем сообщениям в организации. Во вторых, это снижает нагрузку на сервер почтовых ящиков (Mailbox).
В этом сценарии будет использован любой доступный транcпортный сервер сайта (однако если роли HUB и Mailbox расположены на одном сервере, будет выбран именно он)
2. Отправка почты получателю в другом сайте. Здесь также транспортный сервер сайта отправителя будет использовать любой доступный транспортный сервер сайта получателя
Более того, в сценариях 1 и 2 обеспечивается не только отказоустойчивость, но и балансировка нагрузки, так как по умолчанию сервера Exchange распределяют нагрузку на транспортные сервера, расположенные в одном сайте. Сервер транспорта выбирается по принципу Round Robin. Если он недоступен, соединение устанавливается со следующим сервером и так далее.
3. Отправка почты в интернет. Здесь все зависит от настройки соединителей отправки (Send Connectors). При корректной настройке каждый транспортный сервер сможет отправлять почту в интернет через любой сервер Edge или напрямую в интернет. Здесь балансировка и отказоустойчивость достигается за счет указания более чем одного транспортного сервера в качестве источника в соединителе отправки. При планировании следует помнить, что сервер Edge можно подписать только на один сайт Active Directory. Однако возможно использование серверов Edge и без подписки. Здесь написано как настроить коннекторы, если не используется EdgeSync
4. Получение почты из интернет. MX можно использовать по-разному
- Использовать mx записи с разным весом. В этом случае обеспечивается необходимая отказоустойчивость, так как при выходе из строя одного сервера Edge, почта будет приниматься другим. Однако о распределении нагрузки в этом случае говорить не приходится
- Использовать MX записи с одинаковым весом и Round Robin. В этом случае мы получаем распределение нагрузки. А как быть в случае, если один из серверов выйдет из строя? Ничего страшного, в отличие от https клиентов, smtp сессии очень короткие. Кроме того (ведь мы говорим о других серверах, а не о pop3/imap клиентах) smtp сервер будет пытаться доставить почту, используя все mx записи в соотвествии с их приоритетом. Это решение является так называемым best practice, и более того, Microsoft у себя использует именно такую схему.
Есть некоторые аспекты, которые не охвачены этой схемой
1. POP3/IMAP клиенты. Как быть с ними? Ведь для отправки в явном виде должен быть указан транспортный сервер, и ни о каких mx записях речь идти не может.
2. Слишком много серверов. HA — это всегда удорожание системы. Вы не забыли, что нам нужно обеспечить доступность и других компонентов системы — клиентский доступ, сервера почтовых ящиков?
Отличные новости — с выходом SP1 для Exchange 2007 поддерживается NLB для транспортных серверов Exchange. Это позволяет разместить транспорт и клиентский доступ на одном NLB кластере, сэкономив при этом на аппаратном обеспечении. Кроме того, решается проблема с pop3/imap клиентами. На форумах технет частенько возникали вопросы по этому поводу. Теперь это не только возможно, но и поддерживается
Что насчет NLB для серверов Edge? Поддерживается ли для них NLB? Я не нашел никакого официального подтверждения или опровержения. Но вот что мне ответил на это
NLB in general is supported, although may need to work with the vendor on any issues that reproduce only when the load balancer is present. If you choose Windows Load Balancing, be aware that as with anything, there are challenges associated with it, and it is critical to understand all layers before deploying. Like any networking technology, WLBS is not simply a checkbox that you check to enable.
My personal opinion is that NLB for SMTP only makes sense in a few corner cases (usually a large scale POP/IMAP hosting environment like that of a national ISP or something – and even then, I’d say port 587, not port 25; this is only because I’m not confident every desktop client would handle it gracefully). This does not mean that you can’t use NLB, it simply means that there is little or no return and only risk and complexity. I have personally worked 4 issues with NLB and Exchange 2007 that were all caused by NLB, not by Exchange. In every case, if they had used our recommendation, they would have met their requirements but possibly had fewer issues.
The only NLB configurations I would not personally support are:
· NLB of Hub port 25 or Edge internal receive connector
· Any performance issues related to WLBS configured without dedicated NICs
Думаю переводить не следует, все и так понятно. Использовать NLB или нет — решать вам. Если кто то уже использует NLB для smtp — напишите пожалуйста ваши комментарии. Были ли у вас проблемы связанные с использованием этой технологии для балансировки SMTP ?
Полезные ссылки
Deployment Options for Hub Transport Servers
Load Balancing and Fault Tolerance for Transport Servers
Deployment Options for Edge Transport Servers
Network Load Balancing Technical Reference
Похожие посты:
- Microsoft Transporter Suite – утилита для миграции с POP3/IMAP4/Lotus Domino на Exchange Server 2007
- Exchange. Глобальные проблемы. Эпизод1. SMTP rerouting
- Exchange 2007, Outlook Express и 587 порт. Проблемы?
- Вопросы для интервью на позицию администратора Exchange 2007/2010
- Правила именования серверов Exchange 2007