Microsoft Way

Миграция с Exchange 2007 на версию 2010

Крайне подробная документация по установке нового продукта и миграции с предыдущих версий содержится на сайте technet.
И я крайне рекомендую тщательнейшим образом перечитать всю документацию размещенную там перед тем, как браться за настройку и управление продуктом в производственном окружении.
Ниже даже не обзор особенностей новой версии почтового сервера, а скорее, соображения о специфических действиях для миграции на нее и сравнении конфигураций.

По сравнению с 2007 версией, для создания отказоустойчивых конфигураций произошло два долгожданных шага вперед:

1. Отказ от необходимости создания кластера на уровне ОС. И я бы даже сказал, что производитель очень навязчиво декларирует данный факт. Кстати, да. Учитывая требования к оборудованию (а точнее, к системе хранения данных) для создания кластерных конфигураций на базе server 2008, лично для меня подобная необходимость была бы достаточно неприятна.
2. Возможность размещения любых дополнительных ролей Exchange на любой из нод отказоустойчивого почтового хранилища.

Но дело в том, что на самом деле отказоустойчивый кластер создается. Просто не на уровне операционной системы. А размещение на хранилище дополнительных ролей вовсе на так однозначно. Что все это значит? Рассмотрим дальше.

Итак, какова могла быть возможная конфигурация для отказоустойчивой почтовой системы на базе Exchange 2007:

1. На два сервера объединенные в кластер была установлена роль mailbox store. При этом один из серверов мог быть заведомо слабее, т.к. выполнял исключительно функцию аварийного резерва.
2. Роли транспортного сервера и сервера клиентского доступа были установлены на единственный сервер, защищенный от аппаратных сбоев путем помещения внутри отказоустойчивой виртуальной машины.
3. Для защиты от вирусов и спама, был установлен отдельный релей на базе свободного ПО. Данное решение значительно снижает нагрузку на транспортный сервер Exchange, не требуя при этом дополнительных лицензий для сервера с ролью Edge Transport.
4. Для защиты от DDoS атаки на сервер клиентского доступа, данный сервер был опубликован через ISA сервер. Что, кстати, дополнительно значительно снижает нагрузку за счет кэширования и возможности отключения шифрования между внутренним интерфейсом ISA и интерфейсом CAS сервера (разумеется, нешифрованный трафик между серверами категорически рекомендуется передавать исключительно через выделенный VLAN).

А теперь, что нас ждет при переходе с вышеуказанной конфигурации на Exchange 2010:

1. Абсолютно все подключения теперь будут проходить через CAS сервер. Что автоматически означает необходимость его существенной производительности.
2. Размещение дополнительных ролей на одном из серверов хранилища почтовых ящиков — это замечательно (особенно, когда есть запас производительности). Но необходимо хорошо себе представлять тот факт, что в этом случае необходимо размещение тех же самых ролей на любом другом сервере и создания NLB кластеров для получения отказоустойчивости. Надеюсь, как работает NLB unicast и в чем особенность NLB multicast при доступе к нему через роутер, все хорошо понимают и недоразумений при настройке ни у кого возникать не будет 😉
3. Поскольку, как я уже отметил, отказоустойчивый кластер на самом деле создается, честь и хвала тому, что сможет на тех же самых нодах поднять NLB. Да, признаю, в предыдущем пункте я именно издевался, разглагольствуя о режимах работы NLB
4. Да, есть одна особенность: при двух серверах с ролью транспорта, почта между двумя ящиками одной почтовой базы всегда будет доставляться через второй сервер транспорта — это особенность новой архитектуры и ее необходимо иметь в виду. Транспорт совершит локальную доставку только в случае недоступности стороннего партнера, и что-то мне подсказывает, что доступность проверяется отнюдь не запросом к smtp порту, а обычным icmp. Надеюсь, система контроля статуса критических сервисов всех серверов настроена у всех?
5. Резервное копирование и удобство восстановления лучше даже не упоминать, если совершенно случайно нигде не завалялось лицензии на DPM (Data Protection Manager). Впрочем, возможность создания «отсроченной» (lagged database) копии средствами самого Exchange, несомненно, существенно снимает ряд проблем.