Проливаем свет на Exchange 2010: маршрутизация на основе версий
К этому моменту вы, возможно, видели несколько наших постов из рубрики "Проливаем свет на Exchange 2010". Если это так, то вы наверняка оценили большую работу, проделанную для того, чтобы сделать Exchange 2010 лучшей на данный момент версией Exchange. И теперь уже ваше практическое начало хочет узнать, что нужно для того, чтобы заполучить все эти новые возможности. Определенно, развертывание новой версии Exchange редко можно было причислить к простым мероприятиям.
Чтобы быть уверенным, что вы сможете начать планирование как можно раньше и знать при этом как можно больше, я хочу напомнить про требование, которое мы ввели для роли транспортного сервера, чтобы выдать качественный продукт с новыми классными возможностями. Это требование часто называют "маршрутизацией на основе версий" или просто "версионной маршрутизацией".
Что означает это требование?
Проще говоря, это требование означает, что транспортные серверы Exchange 2010 и серверы почтовых ящиков Exchange 2010 могут обмениваться сообщениями только между собой. Также это означает, что транспортные серверы Exchange 2007 и серверы почтовых ящиков Exchange 2007 могут взаимодействовать только между собой. Однако транспортный сервер может взаимодействовать (по SMTP) с транспортным сервером любой версии. Таким образом, для того, чтобы пользователь на Exchange 2007 смог отправить сообщение пользователю на расположенном в том же сайте Exchange 2010, это сообщение должно пройти через оба транспортных сервера.
Например:
Обратите внимание, что это ограничение на операции отправки и доставки сообщения в Exchange 2007 накладывает Exchange 2007 Service Pack 2. Это одна из причин того, почему Service Pack 2 нужно установить до развертывания Exchange 2010, и почему все серверы должны быть обновлены до Service Pack 2, чтобы эта возможность продолжала нормально работать. Кроме того, заметьте, что (хотя это и лежит вне темы этого поста) то же самое ограничение действует и на серверы клиентского доступа, то есть версии серверов клиентского доступа должны совпадать с версиями серверов почтовых ящиков, с которыми те взаимодействуют.
Маршрутизация почты между Exchange 2003 и Exchange 2010 не изменилась по сравнению с Exchange 2007. В Exchange 2010 мы по-прежнему используем соединитель групп маршрутизации (Routing Group Connector, RGC) между группой маршрутизации Exchange 2003 и группой маршрутизации Exchange 2007/2010. Если сейчас у вас нет Exchange 2007 и вы хотите разобраться в проблемах маршрутизации при миграции с Exchange 2003, почитайте этот пост. Кроме того, на поток сообщений между сайтами AD маршрутизация на основе версий никак не влияет (потому что он тоже использует SMTP).
Возможные стратегии миграции
В случае простой установки типа "все на одном сервере" миграция с 2007-го на 2010-й сравнительно проста (так же, как и при мирации с 2003-го на 2007-й(. Просто поднимите новый сервер и смигрируйте почтовые ящики. Во время миграции почта будет ходить между серверами, не мешая пользователям, только убедитесь, что на каждом из серверов есть обе роли.
При более сложных миграциях в целях эффективного использования оборудования вам может пригодиться метод переходящего сервера. То есть вы берете один запасной сервер и устанавливаете на нем Exchange 2010. После того, как вы перенесете почтовые ящики с 2007-го на 2010-й, вы можете использовать освободившийся сервер для миграции в других местах. Поэтому вы должныучесть это при планировании, и, возможно, предусмотреть короткий период сосуществования. Разумеется, как только все ваши пользователи перейдут на 2010-й, вам следут перевести все транспортные серверы с 2007-го на 2010-й.
Отдельное замечание насчет дублирования/отказоустойчивости: В зависимости от ваших требований и от количества пользователей вам могут потребоваться по 2 транспортных сервера каждой версии для дублирования. Конечно, если у вас развернут Exchange 2007 в кластере CCR, то роли транспортных серверов не могут быть установлены на серверах этого кластера. Однако теперяшняя замена CCR, группа готовности баз данных (Database Availability Group, DAG), позволяет роли транспортного сервера сосуществовать с ролью сервера почтовых ящиков.
Для тех из вас, у кого нет лишних серверов, особенно если существующее оборудование недозагружено, виртуализация может быть отличным решением для сокращения количества физических серверов. И лучше всего то, что физические ресурсы можно перераспределить между машинами без их переустановки, хотя для этого вам требутеся сначала развернуть среду виртуализации. Например, евы можете использовать два физических сервера, и на каждом развернуть роли транспортных серверов Exchange 2007 и Exchange 2010, обеспечивающих дублирование для обеих версий и не требующих при этом дополнительного оборудования. Разумеется, Hyper-V доступен бесплатно для тех, у кого есть Windows Server 2008 или более поздняя версия.
Откуда идет это требование?
По существу, как это часто бывает при разработке программного обеспечения, это решение является компромиссом. Но сначала немного истории.
Если вы интересуетесь такими вещами, то уже могли знать, что начиная с Exchange 2007 транспорт сообщений не использует ныне исчезнувний драйвер файловой системы Exchange для того, чтобы записывать сообщения в хранилище и извлекать их из него. Вместо этого мы используем немного похожий на MAPI особый внутренний RPC API, называемый Exchange Storage Objects (XSO). В силу разных причин XSO не является общедоступным API, как Exchange Web Services или MAPI, но его используют другие роли для того, чтобы записывать сообщения в хранилище и читать их оттуда.
Если вы еще не запутались окончательно, вы наверняка вспомните те огромные преимущества, которые несут с собой усовершенствования в хранении и вводе-выводе. Для того, чтобы реализовать их, и чтобы обеспечить готовность к будущим усовершенствованиям в хранении, потребовались некоторые изменения в структуре базы данных. Соответственно, XSO API тоже потребовалось обновить, так же как и весь код, который использовал старую версию API.
Согласно первоначальному плану Exchange 2010 нужно было размещать в отдельных от Exchange 2007 сайтах AD. Поскольку это сделало бы развертывание чрезвычайно трудным, команда транспорта решила применить концепцию "маршрутизации на основе версий". Вот зачем для серверов Exchange 2007 сейчас требуется Service Pack 2.
Заключение
Сейчас, когда вы знаете про это требование, вы можете учесть его при планировании для того, чтобы во время миграции на Exchange 2010 почта не прекращала ходить. Сообщите нам, помогла ли вам эта информации при планировании?
Кстати, это требование будет задокументировано более формально в следующих разделах справки (в момент публикации этого поста информация по этим ссылкам еще не финализирована):
Перевод: Иван Макаров