Exchange 2013 вышел: две роли вместо пяти и вопрос без ответа про Edge Transport

Exchange 2013 вышел в GA 13 октября, и мы уже третью неделю гоняем его в лабораторной среде. Первая реакция была примерно такой: «стало меньше», и это оказалось комплиментом.

Что изменилось архитектурно

В Exchange 2010 было пять серверных ролей: Mailbox, Client Access, Hub Transport, Unified Messaging и Edge Transport. Для небольшой организации это выглядело как избыточность, а для крупной - как постоянные вопросы «на каком сервере что включать и почему».

В Exchange 2013 ролей осталось две: Mailbox и Client Access Server (CAS). Все транспортные функции, которые в 2010 жили на отдельном Hub Transport, теперь интегрированы в роль Mailbox. Unified Messaging тоже переехал туда. CAS стал чисто прокси-слоем: принимает протокольные подключения (HTTPS, ActiveSync, IMAP, POP) и проксирует их на Mailbox.

На практике это означает, что типовая топология для среднего клиента теперь выглядит как один-два сервера вместо трёх-четырёх. DAG (Database Availability Group) никуда не делась - высокая доступность на уровне баз данных работает так же, через Windows Failover Clustering.

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

Куда делся Edge Transport - и это не мелочь

Вот здесь у нас возникла пауза. В Exchange 2010 роль Edge Transport жила в DMZ: принимала почту снаружи, прогоняла через антиспам-фильтры, применяла правила транспорта и только потом передавала на Hub Transport внутри периметра. Изящная схема - Exchange-сервер во внутренней сети вообще не смотрел в интернет напрямую.

В Exchange 2013 роли Edge Transport нет. По крайней мере, в этом релизе. Microsoft пишет, что для фильтрации входящей почты рекомендуется использовать либо сторонние шлюзы, либо Exchange Online Protection (EOP) - облачный антиспам-сервис. Для тех, кто не собирается в облако, вариант с Exchange 2010 Edge Transport в DMZ совместим с Exchange 2013 Mailbox - гибридный транспорт поддерживается.

Мы прошлись по нескольким сценариям, которые сейчас актуальны для наших клиентов:

• Шлюз из Exchange 2010 Edge в DMZ. Оставляем 2010 Edge Transport как есть, он принимает почту снаружи и передаёт на новые серверы 2013. Работает, Microsoft это поддерживает. Минус - остаётся живой сервер 2010, который нужно патчить.
• Сторонний SMTP-шлюз. Sophos, Symantec, Barracuda - всё это умеет принимать почту и передавать дальше. Клиентам, у которых антиспам-шлюз уже был (а у многих был), миграция Exchange вообще не затрагивает этот слой.
• Exchange Online Protection. Подписка, MX-запись переключается на Microsoft, они фильтруют и передают на ваш Exchange. Для тех, кто готов пустить трафик через Microsoft - приемлемо. Для регуляторно чувствительных клиентов - отдельный разговор про хранение данных.

Мы склоняемся к тому, что для большинства случаев вариант с имеющимся шлюзом - самый чистый. Не потому что облако плохо, а потому что вводить новую зависимость в ходе миграции Exchange - лишний риск.

Как мы строим план миграции

Exchange 2013 поддерживает сосуществование с Exchange 2010 - оба сервера могут жить в одной организации, пока идёт перенос ящиков. Это стандартный подход Microsoft для cross-version migration.

Примерная последовательность, которую мы отрабатываем в лабе:

1. Установка Exchange 2013 (Mailbox + CAS) в существующую Exchange 2010 Organization.
2. Настройка CAS namespace: certificates, virtual directories, autodiscover - Exchange 2013 CAS должен обслуживать все протоколы с единым пространством имён.
3. Перемещение тестовых ящиков командлетом New-MoveRequest - их теперь называют mailbox moves, логика та же.
4. Проверка клиентского опыта: Outlook 2010/2013, OWA, ActiveSync. Exchange 2013 CAS умеет проксировать подключения обратно на 2010 Mailbox, если ящик ещё не перенесён.
5. Поэтапный перенос production-ящиков.
6. Вывод серверов 2010 из строя после переноса последнего ящика и публичных папок.

Публичные папки, кстати, переработали полностью - теперь они хранятся в специальных mailbox'ах, а не в отдельной базе. Для клиентов, активно использующих Public Folders, это отдельная история, к которой мы ещё вернёмся.

Где мы сейчас

В лаборатории миграция с Exchange 2010 на 2013 прошла без сюрпризов в части переноса ящиков. Основное время ушло на namespace и сертификаты - как обычно. Edge Transport вопрос решили через существующий шлюз у тестового клиента, что сняло проблему.

В рамках управляемой поддержки первую боевую миграцию планируем в декабре - когда пройдёт чуть больше времени с релиза и появятся первые Cumulative Update'ы. Запускать GA-версию Exchange в production на следующий день после релиза - это уже не смелость, а что-то другое.

Windows Server 2012, на котором Exchange 2013 обязателен, мы уже разбирали в августовском посте про GA-релиз. Там же - заметки про Storage Spaces и дедупликацию, которые теперь дополнительно мотивируют переходить на новую ОС под Exchange.