Для достижения высокого уровня готовности в системе Exchange 2010 используются группы доступности базы данных Database Availability Groups, (DAG), а группы хранения отменяются. Изменения в сфере администрирования и управления включают обновления консоли управления Exchange Management Console, а также командной консоли Exchange (Exchange Management Shell, EMS) и управление доступом на основе ролей (Role-Based Access Control, RBAC).

Многие наверняка обратили внимание на то, что, хотя продукт Microsoft Exchange Server 2007 имел кодовое название Exchange 12, следующая существенно обновленная версия его почтового сервера получила имя Exchange 14. Microsoft пропустила число 13 по той же причине, по которой многие гостиницы избегают присваивать этажу, следующему за двенадцатым, номер 13, — дурная примета! Ожидается, что Exchange 14 поступит на рынок в конце 2009 г. и получит окончательное название Microsoft Exchange Server 2010. Реализованные в Exchange 2007 архитектурные изменения в версии Exchange 2010 дополняются рядом значительных обновлений, в результате которых улучшаются рабочие характеристики продукта. По большому счету, наиболее важные изменения подразделяются на четыре категории: обновление хранилища данных, новый подход к обеспечению высокого уровня готовности, обновления в сфере управления и администрирования, а также усовершенствования операций с сообщениями.

Обновление хранилища данных

Система Exchange всегда отличалась требовательностью к подсистеме хранения данных, потому что набор операций ввода/вывода функционирующего с большой нагрузкой почтового сервера состоит не из предсказуемых последовательностей «ввод/вывод», характерных для приложений, ориентированных на базы данных, а из множества беспорядочных и небольших по объему операций ввода/вывода. Такое положение объясняется широчайшим диапазоном сообщений, с которыми приходится иметь дело серверу Exchange: от простого сообщения в одну строчку, направленного одному получателю, до многомегабайтного сообщения (включающего вложения), направляемого адресатам, перечисленным во вложенных списках. Разумеется, эти транзакции предъявляют к подсистеме ввода/вывода совершенно разные требования.

В версии Exchange 2007 Microsoft резко сократила число обменов с дисковой памятью за счет дополнительной памяти, высвободившейся при использовании 64-разрядной платформы для кэширования максимально возможного объема данных хранилища. Результатом этого процесса стало существенное сокращение операций ввода/вывода в расчете на активный почтовый ящик, кроме тех случаев, когда речь идет о крупных почтовых ящиках. Здесь сложность состоит в том, что пользователи нередко хранят в них тысячи объектов, разбросанных по сотням папок. Чем больше объектов и папок содержится в почтовом ящике, тем больший объем работы приходится выполнять хранилищу данных для организации и обслуживания индексов, которые его поддерживают. Пользователи, применяющие интегрированную с программой Microsoft Office Outlook панель поиска Windows, становятся еще менее организованными. Они не обязаны помнить, в каком месте обширной структуры папок хранится тот или иной объект, его всегда можно найти, выполнив операцию поиска.

Таким образом, хотя разработчики Exchange 2007 внесли в продукт существенные улучшения за счет оптимизации механизма кэширования хранилища данных, поведение пользователей несколько изменило картину, и потребовались дополнительные усилия для того, чтобы обеспечить системе Exchange возможность эффективной поддержки очень больших почтовых ящиков. Между прочим, специалисты Microsoft предварительно рассматривали вариант замены ядра системы управления хранилищем сообщений от Extensible Storage Engine (ESE) на Microsoft SQL Server. Оказалось, что такая замена требует значительных теоретических и инженерных разработок; именно поэтому в системе Exchange до сих пор используется обработчик ESE. Но исследование обнажило ряд фундаментальных проблем хранилища данных Store, включая его схему и таблицы. В результате в версию Exchange 2007 были внесены некоторые изменения с целью повышения производительности; особенно следует отметить увеличение размера страницы с 4 до 8 Кбайт и более простую процедуру выполнения транзакций ввода/вывода. К числу дальнейших усовершенствований в сфере производительности, реализованных в Exchange 2010, относятся следующие:

  • Увеличенный с 8 до 32 Кбайт размер страницы. Благодаря этому изменению на одной странице может быть размещено большее количество данных; теперь нет нужды разбрасывать по базе данных страницы, необходимые для одного объекта, включая вложения.
  • Данные заголовков для всех элементов почтовых ящиков хранятся в одной таблице базы данных — это изменение повышает эффективность базы данных, поскольку в ходе сеанса работы с клиентом она может обрабатывать одну таблицу для каждого почтового ящика, а не обращаться к разным таблицам для различных папок почтового ящика. Побочный эффект данного изменения схемы состоит в том, что в системе Exchange больше не используется хранилище единственных копий (SIS), обеспечивающее хранение всего лишь одной копии содержимого сообщения на базу данных. Почти все серверы могут работать с несколькими базами данных, так что c течением времени SIS дает все меньший выигрыш с точки зрения эффективности.
  • Вложения хранилища данных подвергаются сжатию — в Microsoft полагают, что на сжатие и восстановление вложений процессоры сервера затрачивают меньше времени, чем было бы необходимо для управления хранением очень крупных объемов несжатых данных внутри базы данных. Помимо прочего, это изменение приводит к сокращению общего размера баз данных Exchange, что, в свою очередь, позволяет с большим быстродействием выполнять такие операции, как резервное копирование.
  • Хранилище данных обновляет представления (индексы) лишь тогда, когда к ним обращаются. Клиент Outlook может создавать множество различных представлений папки на ходу (например, элементы, упорядоченные по тематике), и хранилище данных поддерживает эти представления внутри базы данных. По истечении 40 дней неиспользуемые представления удаляются, но до этого срока хранилище должно поддерживать их. Представления обновляются только при необходимости, что значительно сокращает объемы фоновой обработки.

Первоначальные результаты, полученные специалистами Microsoft при выполнении тестов производительности, указывают на то, что новое хранилище данных генерирует значительно меньшее количество операций ввода/вывода, нежели его эквивалент в системе Exchange 2007. Благодаря этому серверы поддерживают большее число почтовых ящиков, а система обеспечивает возможность использования дополнительных параметров хранения данных. Традиционно на крупных серверах почтовых ящиков применяются высокопроизводительные конфигурации средств хранения данных, такие как сети хранения данных; это позволяет обеспечивать превосходные показатели скорости выполнения операций ввода/вывода при максимальной надежности. Если Exchange 2010 будет требовать меньшего объема ресурсов для организации обмена с дисками и обеспечивать более высокую отказоустойчивость, у конструкторов систем может возникнуть стимул использовать для хранения данных не столь дорогостоящие решения, например диски Serial ATA (SATA) и Just a Bunch of Disks (JBOD). Компании, эксплуатирующие сети устройств хранения данных, могут продолжать эту практику, особенно если они сделали такой выбор потому, что управление хранением данных осуществляется в таких организациях централизованно, а не для каждого приложения отдельно. Стремление Microsoft повысить быстродействие подсистемы ввода/вывода, что способствует применению компаниями менее дорогостоящих решений в сфере хранения данных, можно только приветствовать. Но ведь до выхода Exchange 2010 на рынок код продукта еще будет меняться, поэтому нам остается только немного подождать, и мы узнаем, как оптимизировать средства хранения данных в производственных сетях.

Главное — высокий уровень доступности

В Exchange 2007 была реализована функция доставки журналов, что дало администраторам возможность реплицировать данные на локальные диски (механизм Local Continuous Replication, LCR), на другой узел кластера (механизм Cluster Continuous Replication, CCR) и на сервер, расположенный в другом центре обработки (механизм Standby Continuous Replication, SCR). Вот эту технологию доставки журналов и использует Microsoft, с тем чтобы превратить высокую доступность в основную характеристику Exchange 2010. В рамках радикального пересмотра набора функций Exchange, обеспечивающих высокую доступность, специалисты корпорации делают четыре важнейших шага.

  1. Отказ от концепции групп хранения. База данных становится той самой единицей управления, с помощью которой осуществляется планирование мер достижения высокой доступности; это разумное решение, с учетом того обстоятельства, что репликация журналов применима лишь к группам хранения, содержащим только одну базу данных.
  2. Кластеры с единым хранилищем отменяются и не поддерживаются системой Exchange 2010. Разработчики Microsoft склонны считать, что обслуживание нескольких хранилищ данных на нескольких серверах дает более высокие результаты в обеспечении высокой степени доступности, нежели попытки обновлять единственное хранилище данных.
  3. Отказ от реализации в Exchange 2010 средств локальной непрерывной репликации, так как репликация журналов на одном и том же сервере дает ограниченный выигрыш.
  4. В продукте Exchange 2010 вводятся группы доступности базы данных Database Availability Groups (DAG). Это группы из нескольких серверов (до 16), в которых часть или все базы данных выделяются для репликации на один или несколько серверов. С целью организации взаимодействия внутри групп DAG, серверы которых могут располагаться в различных местах, Microsoft использует некоторые компоненты кластеров Windows (например, периодические контрольные сообщения — heartbeats, файловые ресурсы-свидетели).

Важно отметить, что теперь появилась возможность репликации базы данных на несколько серверов внутри группы DAG с помощью доставки журналов; при этом все места размещения серверов DAG должны располагать достаточными сетевыми ресурсами, чтобы быстро, не допуская формирования очередей, копировать журналы. Можно сказать, что эквивалентом этому требованию сегодня является SCR. Цели репликации выбираются не на уровне сервера, а на уровне базы данных; это дает возможность реплицировать различные базы данных с сервера на другие серверы внутри группы DAG. Допустим, в Нью-Йорке имеется сервер, содержащий две базы данных. Так вот, этот сервер может реплицировать одну базу данных на сервер в Лос-Анджелесе, а другую базу — на сервер в Сиэтле. Оперативная база данных называется главной; если в работе с главной базой данных возникают проблемы, компонент, именуемый Active Manager, переключается на одну из ее копий и превращает последнюю в главную базу данных. Microsoft включает средства управления группами DAG в версию консоли Exchange Management Console (EMC), реализованную в Exchange 2010, и добавляет команды консоли Exchange Management Shell (EMS); таким образом, пользователь может управлять группами DAG посредством программы с графическим интерфейсом или с помощью командной строки.

Новый компонент Exchange 2010, именуемый RPC Client Access Layer, обновляет серверную роль Client Access, так что соединения со всеми клиентами проходят через предсказуемую точку сети. Поскольку существует возможность того, что оперативные копии баз данных будут переходить с одного сервера на другой, клиенты могут потерять ориентировку при попытке соединиться с почтовым ящиком. В версии Exchange 2007 была реализована роль Client Access, управляющая соединениями со всеми клиентами, кроме MAPI (т. е. Outlook). В версии Exchange 2010 роль Client Access определяет, на каком сервере в данный момент располагается оперативная копия почтового ящика по информации DAG, которая хранится в каталоге Active Directory (AD). Таким образом, роль Client Access может перенаправить клиенты в случаях, когда база данных переведена на другой сервер.

Затруднения возникают при работе с любым решением, обеспечивающим высокую степень доступности. К числу заслуживающих отдельного рассмотрения относятся, например, следующие проблемы: как будут взаимодействовать с группами DAG программные средства резервного копирования от независимых поставщиков и какую роль будут играть автономные резервные копии после развертывания Exchange 2010.

Введение групп доступности базы данных свидетельствует о том, что главным средством обеспечения доступности данных эксперты Microsoft склонны считать множественные копии баз данных. При наличии нескольких копий базы данных пользователь должен иметь возможность переключения на реплику базы данных в случае, если возникнут проблемы с оперативной копией. В результате важность резервных копий снижается; в первую очередь это касается копий на ленточных носителях. Разумеется, администраторам придется сталкиваться с такими проблемами, как: требования аудита, которые могут предусматривать работу с автономными защищенными резервными копиями; необходимость обеспечивать достаточные ресурсы хранения данных и пропускную способность сети для обработки нескольких реплик, а также для доставки журналов; наконец, неизбежные обновления операционных процедур, выполняемых при снятии резервных копий, восстановлении данных и в случае выхода из строя диска или сервера.

Еще одна потенциальная проблема — настройка серверов Client Access. В системе Exchange 2007 почти вся рабочая нагрузка Client Access генерируется при работе клиентов (включая Outlook Anywhere) в Internet. В среде Exchange 2010 с введением компонента RPC Client Access Layer сервер Client Access получает более серьезную рабочую нагрузку, и некоторые используемые ныне серверы Client Access не обеспечивают достаточной мощности для работы с новыми нагрузками.

Усовершенствованные средства управления и администрирования

Корпорация Microsoft внесла в средства управления Exchange большое число усовершенствований, и можно с уверенностью сказать, что сочетание консолей EMC и EMS в Exchange 2007 дает большинству администраторов возможность выполнять свою работу быстро и эффективно. В версии Exchange 2010 оба компонента модернизированы. Они оснащаются новыми функциями и обеспечивают совместимость с оболочкой PowerShell 2.0, которая базируется на платформе .NET Framework 3.5. В среде PowerShell 2.0 реализованы средства дистанционного управления; администратор может подключиться к удаленному серверу Exchange и выполнять на нем команды так же легко, как на локальном сервере. Появились новые команды для таких средств, как группы доступности базы данных. Кроме того, обновлены некоторые более старые команды; например, команда Move-Mailbox теперь может использоваться с переключателем -online, позволяющим перемещать почтовые ящики даже в ситуациях, когда пользователи работают в оперативном режиме.

В механизм управления Exchange 2010 внесено два важных изменения: управление доступом на основе ролей, role-based access control (RBAC), и облегченная Web-консоль для выполнения ограниченного набора операций. RBAC обеспечивает связь необходимых разрешений с ролью, что дает возможность наделенному этой ролью лицу успешно выполнять свою работу. Нам уже приходилось иметь дело с концепциями ролей и связанными с ними разрешениями (вспомним об администраторе получателей Exchange), однако Exchange 2010 дает возможность определять специализированные роли для конкретной организации, определять задачи, выполняемые этими ролями, и связывать разрешения, чтобы те, кому назначена роль, могли выполнять свою работу. К примеру, администратор может создать роль сотрудника службы поддержки с необходимыми разрешениями для создания почтового ящика, переустановки паролей и выполнения других задач, а затем назначить эту роль пользователям, которые занимаются подобными задачами. Если вы назначаете роль пользователям, они автоматически наследуют соответствующие разрешения. Если роль отзывается, теряются и разрешения.

Принципиальное отличие в данном случае состоит в том, что разрешения ассоциируются не с объектами AD, такими как серверы и почтовые ящики, а с задачами. Так, если вы принимаете решение, что та или иная роль должна обеспечивать управление почтовыми ящиками, эта роль незаметно для пользователей наследует разрешения, необходимые для выполнения указанной задачи. Это обстоятельство в сочетании с возможностью определять набор объектов, с которыми роль будет работать, — например, только почтовые ящики, размещенные на определенных серверах, или только почтовые ящики, расположенные в Германии, — формирует логический и универсальный подход к распределенному управлению, который может получить широкое распространение в средних и крупных организациях. С точки зрения менее масштабных организаций управление доступом на основе ролей не столь привлекательно: в штате таких организаций часто числятся лишь один-два специалиста по ИТ, так что перераспределение рабочей нагрузки не представляется возможным.

В комплект поставки Exchange всегда входила консоль управления, и эта консоль обеспечивает возможность выполнения задач, которые часто решаются сотрудниками службы поддержки, например создание новых почтовых ящиков или редактирование свойств почтовых ящиков, а также задач, которые вы, возможно, сочтете нецелесообразным решать с помощью службы поддержки, скажем, создание новых правил транспорта. В Exchange 2010 появляется средство управления Exchange Control Panel (ECP), интерфейс для Web, позволяющий администраторам предоставлять отдельным сотрудникам возможность выполнения конкретных задач управления с помощью RBAC. Администраторы относительно небольших сетей, по всей вероятности, воспримут ECP без особого энтузиазма, но этот интерфейс имеет все шансы получить широкое распространение в сетях класса предприятия.

Усовершенствования в области журналирования сообщений

Основу механизма журналирования сообщений специалисты Microsoft заложили в версии Exchange 2007, где были реализованы функция управления записями сообщений, messaging records management (MRM), а также правила транспорта и правила ведения журнала. К сожалению, некоторые аспекты MRM оказались недоработанными и сложными в развертывании, это касается, например, требования публиковать определения классификации сообщений с помощью файлов XML на каждом клиенте Outlook. С другой стороны, правила транспорта были долгожданным нововведением, избавляющим от необходимости писать код для выполнения специальных операций по обработке сообщений, а правила ведения журналов позволили системе Exchange эффективно захватывать сообщения. Введение этих правил стало возможным благодаря архитектурным изменениям, внесенным специалистами Microsoft в транспортную систему; эти изменения обеспечивают прохождение всеми сообщениями (включая сообщения, направленные локальному адресату) через центральный транспортный сервер. Таким образом, центральный транспортный сервер является единственным местом, где сообщения могут быть исследованы и обработаны.

Microsoft развивает технологию MRM, добавляя новые функции и осуществляя тонкую настройку. Так, в ECP определена новая роль управления записями, позволяющая уполномоченным лицам выполнять поиск почтовых сообщений. Для предотвращения злоупотреблений со стороны пользователей будет осуществляться мониторинг такого рода операций поиска средствами аудита. Архивирование выполняется с большей степенью детализации; администратор может принять решение об архивировании сообщений, удовлетворяющих определенным условиям, — в противоположность тому, как это делается сегодня: архивируются все материалы, направленные из почтовых ящиков указанной базы данных или определенным пользователям. Так, администратор может архивировать сообщения, только если отправитель и получатель работают в разных отделах или если оба они находятся в Австрии.

Кроме того, в Exchange 2007 появились управляемые папки, каждая из которых может иметь только ей назначенное время хранения. Но, как оказалось, пользователи не сумели разобраться с управляемыми папками, и теперь Microsoft реализует другой подход, предполагающий использование тэгов в качестве основы для хранения сообщений. Администраторы могут задать набор тэгов, таких как Important («важно»), Long-term archive («долгосрочное хранение») или Do not delete («не удалять»). Каждый тэг имеет собственную политику хранения, например Never delete these messages (эти сообщения не подлежат удалению). Когда пользователи применяют тэги к сообщениям, Exchange задействует соответствующую политику хранения в процессе проверки почтовых ящиков агентами управления. Пока слишком рано делать выводы относительно того, будут ли тэги более эффективной основой механизма хранения сообщений, чем управляемые папки.

Наряду с этим Exchange 2010 включает в себя новые политики MRM. Благодаря им администраторы могут наделять пользователей возможностью архивировать сообщения, не перемещая их в файл личных папок (PST). С точки зрения администраторов, файлы PST крайне неудобны: их трудно резервировать и восстанавливать, неудобно проверять на наличие сообщений электронной почты; иначе говоря, это весьма полезное изменение.

Будущее клиентов Exchange

В Microsoft уже давно стало традицией выпускать новую версию клиента Outlook одновременно с новой версией Exchange. Exchange 2010 — часть волны Office 14, поэтому Microsoft обновит приложения Outlook, Outlook Web Access и Pocket Outlook (на клиентах Windows Mobile 7.0); они будут дополнены новыми функциями, станут удобнее в эксплуатации и обретут совместимость с архитектурными изменениями, внесенными в Exchange 2010, включая некоторые усовершенствования в сфере быстродействия внутри Outlook, позволяющие удовлетворить требованиям очень больших (свыше 2 Гбайт) почтовых ящиков. В конце концов, нет смысла наделять систему Exchange способностью поддерживать очень крупные почтовые ящики, если главный клиент этой системы с трудом справляется с обработкой подобных почтовых ящиков (а именно так и обстоят дела сегодня).

Главная особенность пользовательского интерфейса клиента — это упор на представления «Разговор», в которых можно с большей эффективностью, чем это делается сегодня, обрабатывать полные наборы сообщений, составляющих текстовый диалог. MailTips, небольшие сообщения в виде всплывающих подсказок, предупредят пользователей о том, что выполнять то или иное действие, возможно, не имеет смысла. Допустим, вы собираетесь использовать функцию Reply to All в сообщении, которое включает 3000 получателей. В других случаях подсказки известят пользователей о том, что адресаты не смогут получить сообщения из-за того, что их почтовый ящик переполнен или они вышли из офиса и не смогут ответить на сообщение. MailTips и представления «Разговор» будет поддерживать также Web-клиент Outlook.

Среда Exchange 2010

Microsoft планирует поставлять потребителям только 64-разрядную версию Exchange 2010, но, возможно, будет выпущена и 32-разрядная тестовая версия. Разумеется, теперь, когда в арсенале корпорации появилось средство виртуализации Hyper-V, можно ожидать, что Exchange 2010 будет достойным кандидатом для установки в сетях виртуализации, хотя и с обычными оговорками: роли, такие, как Client Access и Hub Transport, больше подходят для виртуализации, чем высокопроизводительные серверы почтовых ящиков. Серверы объединенных коммуникаций по-прежнему мало подходят для систем виртуализации: для работы с голосовой почтой требуются средства обработки аудиоданных. Поскольку технология виртуализации получает все более широкое распространение, рекомендуем читателям следить за новостями Microsoft о поддержке их любимых приложений.

Продукт Exchange 2010 несовместим с системой Windows Server 2003, поэтому вам придется развертывать его в среде Windows Server 2008. Как обычно, для его функционирования необходимо будет установить и другие программные компоненты — такие, как последняя версия .NET Framework и некоторые обновления схемы для AD. По состоянию на сегодня служба AD, к которой обращается Exchange 2010, не обязательно должна размещаться на Server 2008, но вам нужно позаботиться о том, чтобы лес функционировал по меньшей мере в режиме Windows 2003 и чтобы в каждом домене, поддерживающем сервер Exchange 2010, было не менее одного сервера глобального каталога, работающего под управлением Windows 2003 SP2. Exchange 2010 не поддерживает контроллеры доменов, предназначенные только для чтения.

Внутри организации Exchange администраторы могут использовать серверы Exchange 2010 в сочетании с серверами Exchange 2007 SP1 или более новых версий и с серверами Exchange 2003 SP2 или более новых версий, однако поддержка более ранних версий Exchange не предусмотрена. Как и в случае с Exchange 2007, вы не сможете обновлять существующую версию Exchange до уровня нового выпуска; вам придется развертывать новые серверы с системой Exchange 2010 и далее с помощью средства Move Mailbox переводить пользователей на новые серверы. Детали рекомендаций по развертыванию пока еще прорабатываются, но я думаю, что предложения будут такие: сначала развертывать серверы с ролями Hub Transport (и Edge Transport), а также Client Access, а затем уже заниматься серверами почтовых ящиков.

Впереди много работы

В версию Exchange 2010 внесено множество других изменений. Общедоступные папки остаются, но некоторые интерфейсы API (такие, как CDOEX, WebDAV и ExOLEDB) заменяются Web-службами Exchange. Технология объединенных коммуникаций обретает новые функции, например индикатор ожидающих сообщений и персональный автосекретарь, который может изменять правила, как отвечать на поступающие вызовы. Можно предположить, что Microsoft обеспечит более прочную связь Exchange с Office Communications Server и его службой управления правами Windows, Rights Management Services, что приведет к более тесной интеграции различных компонентов разработанной корпорацией стратегии информационного сотрудничества.

Специалистам Microsoft, заинтересованным в том, чтобы пакет Exchange 2010 стал стандартным продуктом, предстоит еще большая работа, однако, судя по бета-версиям, можно заключить, что новый выпуск будет оснащен целым рядом интересных функций. Как всегда в таких случаях, к тому времени, когда Microsoft поставит пакет на рынок в окончательном виде, положение может измениться — например, функции, не оправдавшие ожиданий по своему назначению или качеству, могут быть убраны. Однако с учетом того обстоятельства, что Exchange 2010 не является продуктом нового поколения, каким была система Exchange 2007 по отношению к Exchange 2003, я предполагаю, что большинство функций, реализованных в распространяемых сегодня сборках, сохранится и в окончательной версии. В совокупности изменения в новой версии воплощают напряженный труд большой группы разработчиков, так что, вполне возможно, в предстоящие месяцы вам придется активно заниматься изучением нововведений, реализованных в Exchange 2010.