В недавно выпущенную окончательную версию Microsoft Exchange Server 2010 (RTM), как и в предшественников, входит большое количество новых функций и усовершенствований по сравнению с существующими функциями. По существу, с выходом данной версии, Exchange теперь состоит примерно из 21 миллиона строк кода.

Разработчики Exchange преследовали пять основных целей при создании Exchange 2010: помочь организациям достичь новых уровней надежности, лучшей производительности, упрощенного администрирования, улучшенной защиты систем связи и улучшенной бизнес-мобильности для пользователей. Говоря кратко, помня о глобальном экономическом кризисе, они нацелились на создание более гибкого и оптимизированного продукта, который бы снизил затраты, вязанные с запуском инфраструктуры Exchange 2010.

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

Архитектура управления

С Exchange 2007, корпорация Microsoft представила архитектуру управления на основе сред выполнения Windows PowerShell 1.0 и Microsoft .NET Framework 2.0. Как только администраторы Exchange узнали, как пользоваться оболочкой, они быстро реализовали возможности для оптимизации эффективности работы. Не удивительно, что компания Microsoft также использует Windows PowerShell (версия 2.0) и среду выполнения .NET Framework (3.5) в архитектуре управления Exchange 2010. Одним из усовершенствований Windows PowerShell 2.0, используемым в Exchange 2010, является функция удаленного взаимодействия PowerShell. Данная функция использует WS-Management (WS-Man), компонент Windows для упрощения процесса управления серверами, устройствами и приложениями внутри организации.

В Exchange 2007 командная консоль Exchange позволяла администраторам управлять всеми серверами Exchange 2007 из одного сервера управления; командлеты работали в узле/процессе самого сервера управления. Затем сервер управления устанавливал подключения к управляемым серверам Exchange через удаленный вызов процедуры (RPC). С помощью функции удаленного взаимодействия Windows PowerShell 2.0 управление становится намного проще. Функция удаленного взаимодействия предоставляет стандартные протоколы для управления серверами Exchange 2010 через брандмауэры и четко разделяет «клиентские» и «серверные» части обработки командлета. На основе этого, компонент WS-Man делает интеграцию с ОС Windows более беспроблемной, нежели Windows PowerShell 1.0.

Используете ли вы локальные средства управления Exchange или отдельный сервер управления, вы устанавливаете «удаленное» подключение при запуске консоли управления Exchange или командной консоли Exchange. Exchange 2010 подключается к локальному виртуальному каталогу Windows, созданному на веб-узле диспетчера IIS, во время установки средств управления Exchange 2010 на компьютер (см. рис. 1).

Рис. 1 Виртуальный каталог Windows PowerShell 2.0 в диспетчере IIS

При подключении консоли управления или командной консоли Exchange к виртуальному каталогу Windows, PowerShell импортируются необходимые командлеты, или, конкретнее, ссылки на эти командлеты серверной сессии (процесс, также известный под названием «пространство выполнения») в клиентскую сессию. После импорта ссылок на командлеты вы можете управлять сервером Exchange 2010 точно так же, как и серверами Exchange 2007.

При использовании командной консоли Exchange вы можете создать сессию Windows PowerShell, устанавливающую новое подключение к удаленному серверу Exchange 2010. При этом, любые команды запускаемые из консоли на локальном сервере, выполняются непосредственно на удаленном сервере Exchange 2010, к которому вы подключены.

Поскольку консоль управления Exchange строится на основе командной консоли и выполняет команды Windows PowerShell в фоновом режиме, консоль управления ведет себя аналогично командной консоли. Вы даже можете использовать консоль для подключения и управления сервером Exchange 2010 в другом лесу Exchange (см. рис. 2).

В сущности, вы не только можете добавить дополнительные организации Exchange в консоль, а также перемещать почтовые ящики между двумя организациями Exchange (см. рис. 3).

Рис. 2 Несколько лесов Exchange в консоли управления Exchange

Рис. 3 Новый мастер запросов на удаленное перемещение в Exchange 2010

Готовность «облака»
В конечном счете, вы также сможете управлять Exchange Online, одним из решений «Программных продуктов плюс службы» Microsoft, из консоли управления Exchange и командной консоли Exchange. Это станет возможным после того, как компания Microsoft обновит решение Exchange Online до Exchange 2010; в настоящий момент оно основывается на Exchange 2007. Это даст организациям возможность выбрать локальное решение, размещенную службу или сочетание обоих и управлять ими без проблем.

Компания Microsoft уже сделала это возможным в некоторых образовательных учреждениях, вовлеченных в программу Live@edu Microsoft, равно как и для сотрудников Microsoft, которые разместили собственные домены в лабораториях Exchange компании Microsoft, в которых содержится более 10 миллионов почтовых ящиков.

Модель полномочий

Exchange 2010 расширяет модель полномочий на основе записи управления доступом (ACE), которая предоставлялась компанией Microsoft в Exchange 2007, чтобы включить новый слой проверки подлинности с помощью управления доступом на основе ролей (RBAC). RBAC позволяет вам определить основные или детализированные полномочия, основанные на ролях администраторов и отдельных конечных пользователей. Это означает, что вы можете подобрать свою модель полномочий в Exchange 2010 к организационной модели без каких-либо сложностей. Групп ролей, установленных в Exchange 2010 по умолчанию, должно быть достаточно для большинства организаций, хотя если захотите, можете создать нестандартные группы ролей.

Другими словами, RBAC теперь контролирует операционные и административные задачи отдельных пользователей и степень, до которой пользователи могут самостоятельно администрировать почтовые ящики, группы рассылки и так далее.

Интерфейс MAPI и доступ к каталогу среднего уровня

В Exchange 2007 сервер клиентского доступа обеспечивает конечную точку подключения для всех клиентов, за исключением Outlook (Messaging Application Programming Interface, или MAPI) и Entourage (Web-Based Distributed Authoring and Versioning, или WebDAV). Это способ требовал значительный объем обработки данных, которая выполнялась на фоновых серверах почтовых ящиков в ранних версиях Exchange 2007.

Корпорация Microsoft пошла дальше в Exchange 2010, предоставив службу клиентского доступа RPC, которая перемещает подключения MAPI и доступа к каталогу на серверы клиентского доступа среднего уровня. В результате клиенты MAPI теперь не подключаются непосредственно к почтовому серверу при входе в почтовый ящик. Вместо этого они подключаются к службе клиентского доступа RPC, которая, в свою очередь, обращается к серверам Active Directory и почтовым серверам. Для получения информации из каталога, Outlook подключается к конечной точке NSPI (Name Service Provider Interface); затем интерфейс NSPI обращается к Active Directory через драйвер Active Directory. Конечная точка NSPI заменяет компонент DSProxy, который нам знаком со времен Exchange 2007.

Отличие от клиентов Outlook Anywhere (RPC по HTTP), которые подключались к почтовому ящику в Exchange 2007, заключается в том, что эти клиенты устанавливают связь к компоненту прокси RPC на сервере клиентского доступа. Кроме того, они обращаются к MAPI через RPC непосредственно к почтовому серверу и конечной точке NSPI в Active Directory.

Служба клиентского доступа RPC имеет ряд преимуществ. Во-первых, с переходом на MAPI и подключений каталогов на роль сервера клиентского доступа, Exchange теперь имеет один общий путь, по которому можно получить доступ ко всем данным. Это не только увеличивает уровень целостности при применении бизнес-логики на клиентах, а также улучшает работу клиента во время переключений сервера или обходов отказа с помощью новой функции группы доступности базы данных (DAG) (позже остановимся на этой функции подробнее). Отключения клиентов Outlook, которые могут длиться от 30 секунд до нескольких минут (даже до 30 минут), обычны в сложных топологиях Active Directory с кластерной непрерывной репликацией Exchange 2007 (CCR).

Наконец, один общий путь, по которому можно получить доступ ко всем данным, позволяет обеспечить одновременное подключение и использование почтовых ящиков на основе почтового сервера. В Exchange 2007 почтовый сервер мог обрабатывать 64 000 подключений. По сравнению с ним в Exchange 2010 лимит дескриптора контекста RPC составляет 250 000. При возросшей степени использования серверов клиентского доступа в Exchange 2010, клиентам приходится осуществлять быстрые повторного подключения с одного сервера клиентского доступа на другой в ответ на запланированное или незапланированное время простоя. Скажем привет новому массиву клиентского доступа в Exchange 2010. Как можно понять из названия, это массив серверов клиентского доступа. Конкретнее, массив состоит из всех серверов клиентского доступа в узле Active Directory, для которого он и создан. Вместо подключения к полному доменному имени (FQDN) сервера клиентского доступа, клиент Outlook подключается к FQDN массива (например, outlook.contoso.com). Это гарантирует, что клиенты Outlook, подключающиеся через MAPI по RPC, имеют постоянную связь. Массив также присутствует в качестве атрибута в базах данных почтового сервера в узле Active Directory. Это гарантирует, что массив знает к какому почтовому серверу и базе данных должен направляться пользователь. Если вы защищаете базы данных почтовых ящиков с помощью новой функции DAG, а копия соответствующей базы данных другого узла Active Directory становится активной, сервер клиентского доступа будет обращаться непосредственно к почтовому серверу, на котором сохранена копия базы данных через RPC. Это важная деталь.

Вы можете использовать балансировку сетевой нагрузки Windows (WNLB) совместно с массивом клиентского доступа до тех пор, пока не будет установлена роль почтового сервера или защита с помощью функции DAG. Конечно же, вы также можете использовать массив клиентского доступа совместно с внешними средствами балансировки сетевой нагрузки. Но помните, что массив предназначен только для клиентов Outlook RPC; вы также можете использовать обычную балансировку WNLB или внешнюю балансировку сетевой нагрузки для таких служб, как Outlook Web Access, Autodiscover, Exchange ActiveSync и службы доступности.

Оптимизация хранилища

С использованием 64-разрядной архитектуры и уменьшением операций ввода/вывода в секунду (до 70 процентов в Exchange 2007) была создана наиболее эффективная среда хранения, нежели в его предшественниках. В Exchange 2010 корпорация Microsoft сосредоточила свои попытки по оптимизации хранения на предоставлении больших (более 10Гб), быстрых почтовых ящиков, вместо использования дешевых хранилищ.

В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA (также известные, как диски второго уровня). Да, я говорю о дисках 7200 SATA, которые стоят на ваших рабочих станциях. Если вы используете функцию DAG для обеспечения высокого уровня доступности и имеете три или более копий баз данных, вы можете использовать, скажем, один диск 7200 RPM для хранения копии базы данных и соответствующих потоков журнала. Другими словами, вам больше не придется использовать небольшие и быстрые диски в RAID. Вместо этого вы можете хранить ваши базы данных на больших и медленных дисках в конфигурации JBOD.

Корпорация Microsoft добилась таких значительных успехов повышения производительности систем хранения в основном благодаря основным изменениям в схеме хранения. По сути, разработчики Exchange 2010 хотели перейти от использования большого количества случайных, небольших операций ввода/вывода к меньшему количеству последовательных, объемных операций ввода/вывода. Переход со случайных операций на последовательные операции требовал значительных изменений в архитектуре таблицы системы хранения.

В Exchange 2007 и ранее каждая база данных имела таблицу почтовых ящиков (со всеми почтовыми ящиками базы данных), таблицу папок (со всеми почтовыми папками для всех почтовых ящиков, находящихся в базе данных), таблицу сообщений (с сообщениями), таблицу вложений (со всеми вложениями для почтовых ящиков, находящихся в базе данных) и таблицу сообщений/папок (представления папок для всех почтовых ящиков, находящихся в базе данных). В данной архитектуре, которая не претерпела значительных изменений со времен Exchange 4.0, много случайных операций ввода/вывода применялись в базе данных. Одним из преимуществ данной архитектуры было использование хранилища единственной копии (SIS), в которой хранилась одна копия сообщения, — большое преимущество при использовании сравнительно небольших дисков. Но сейчас, когда мы имеем в распоряжении диски SAS размером 500 Гб и диски SATA размером 2 Тб, использование данной архитектуры не имеет смысла.

В Exchange 2010, все данные почтового ящика сохраняется в таблицах в непосредственной близости друг к другу, в базе данных. На самом деле, у каждого почтового ящика имеется собственная папка, заголовок сообщения, тело и таблицы представления. Поэтому, хранилище SIS в базах данных Exchange больше не используется. Как следствие удаления SIS из Exchange, база данных увеличивается примерно на 20 процентов. Для решения данной проблемы разработчики Exchange сжали базы данных (в частности, заголовки сообщений и текстовые или HTML-документы). Назначив собственный набор таблиц почтовому ящику, операции ввода/вывода, выполняемые в базе данных, в большинстве своем, носят последовательный характер.

Среди других изменений следует отметить следующие: пространство для баз данных выделяется непрерывно; непрерывность базы данных поддерживается в течение определенного времени; размер страницы базы данных теперь составляет 32Кб, а не 8; и была усовершенствована возможность асинхронного чтения. Группа разработчиков Exchange также значительно повысила эффективность кэша, изменив глубину контрольной точки до 100 Мб для обеспечения настроек высокой доступности с помощью сжатия и установления приоритета кэша базы данных.

В результате всех изменений в Exchange 2010 вы можете ожидать сокращение количества операций ввода/вывода до 70 процентов по сравнению с Exchange 2007. Теперь это называется оптимизацией ESE.