Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services

Если оглянуться назад, становится понятно, как благодаря изменениям в прошлом был заложен фундамент современных возможностей. В случае с Microsoft Exchange Server на сегодня возможны три варианта развертывания: классический внутри компании, «облачный» с использованием Microsoft Office 365 и гибридный, при котором часть инфраструктуры находится на серверах компании, а часть — в «облаке».

Такое развитие Exchange стало результатом огромной работы, проведенной за последнее десятилетие группой развертывания Exchange с целью обеспечить потребителям возможность выбора. Вспоминая проделанный путь, можно выделить семь важных областей, благодаря улучшениям в которых удалось освободить Exchange от ограничений, изначально присущих серверу электронной почты в локальной сети Windows NT. Помимо всего прочего, администраторам Exchange будет чрезвычайно важно освоить эти области в обозримом будущем.

Великолепная семерка

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

Например, существует изящный способ исправления отдельных страниц в группе обеспечения доступности баз данных (DAG). Благодаря ему банк данных обнаруживает ошибки в страницах и рассылает широковещательные запросы другим экземплярам базы данных, чтобы получить информацию, необходимую для их устранения. При этом база данных остается подключенной к сети и обслуживает пользователей.

Тем не менее, я сохраняю верность своему выбору. Мои области новаций следующие (не в порядке важности):

  1. Удаленный вызов процедур (RPC) по протоколу http.
  2. Windows PowerShell.
  3. Служба автообнаружения.
  4. Служба репликации почтовых ящиков (MRS).
  5. Мультибраузерные интерфейсы.
  6. Улучшения в хранении данных.
  7. Сервер клиентского доступа.

Поясню причины своего выбора.

#1. Удаленный вызов процедур (RPC) по протоколу HTTP: устранение сетей VPN

В начальный период существования Exchange обычным явлением при дистанционном доступе были сбои синхронизации, медленная передача данных по коммутируемым соединениям и сети VPN. Первые две проблемы удалось решить благодаря усовершенствованиям клиентской технологии, таким как фоновая частичная синхронизация (drizzle-mode), появившаяся в Microsoft Office Outlook 2003, и повсеместному распространению быстрых беспроводных каналов связи. А необходимость в организации VPN перед подключением к Exchange исчезла благодаря удаленному вызову процедур по протоколу HTTP в Exchange Server 2003.

Первоначально настройка удаленного вызова процедур по протоколу HTTP, ныне известного как Outlook Anywhere, была сложной задачей. Тот, кто проявил упорство и опубликовал необходимые общедоступные точки подключения, обнаружил, что установить соединение с Outlook не составляет труда. Более того, можно использовать общедоступный Интернет для передачи удаленных вызовов процедур Messaging API (MAPI), надежно инкапсулированных в HTTP-пакетах и образующих основу любого обмена данными между Outlook и Exchange. Администраторам понравилось, что в брандмауэре достаточно открыть только порты 80 и 443, тем более что эти порты обычно открыты для нужд других веб-приложений.

Со времени выпуска Exchange 2003 компания Microsoft постепенно совершенствовала конфигурацию и управление этим компонентом. На сегодня Outlook Anywhere — подлинное достоинство продукта. Этот компонент даже служит фундаментом как для Microsoft Business Productivity Online Standard Suite (BPOS), так и для Office 365.

Действительно, требование, чтобы каждый пользователь создавал VPN для доступа к Microsoft Exchange Online, было бы неприемлемо дорогим для многих малых и средних компаний. Оно тяготило бы и Microsoft, которой пришлось бы управлять входящими VPN-соединениями.

Outlook Anywhere обеспечивает возможность связываться через Интернет всем пользователям. Кроме того, 6 долларов в месяц — приемлемая цена для Office 365. Поэтому удаленный вызов процедур по протоколу HTTP — номер один в моем списке.

#2. PowerShell: общая платформа управления

Выбор PowerShell в качестве второго номера может показаться сомнительным. Однако появление оболочки в Exchange Server 2007 и ее последующее обновление до удаленной версии в Exchange Server 2010 принесло многочисленные преимущества. Прежде всего, PowerShell обеспечивает единообразие интерфейсов управления в Exchange. Другими словами, можно задействовать панель управления Exchange (ECP) для обновления свойств почтового ящика в Office 365 или запустить команду Set-Mailbox из PowerShell. Оба способа обеспечивают одну и ту же логику функционирования.

Однако основной причиной выбора этого компонента стало появление удаленной оболочки PowerShell, с помощью которой можно управлять Exchange Online без входа на серверы Exchange. Очевидно, Microsoft не могла позволить тысячам потребителей Office 365 обращаться к транспортному серверу или серверу почтовых ящиков. Но с помощью удаленной оболочки PowerShell администраторы домена могут подключаться через Интернет и удостоверять свои учетные данные для специализированных сеансов, содержащих строго определенный набор разрешенных для запуска команд. А поскольку PowerShell объединяет все способы одной логикой, пользователь может подключиться, запустив командную консоль Exchange (EMS), через ECP или консоль управления Exchange (EMC) на основе консоли управления Microsoft (MMC). В любом случае результат одинаков. Поэтому PowerShell — пункт номер два.

#3. Автообнаружение: задача пользователя облегчается

Компания Microsoft представила службу Autodiscover в Exchange 2007 как решение вечной проблемы: пользователям трудно настроить параметры Outlook, необходимые для подключения к Exchange. Основная трудность в том, что имена серверов, понятные администраторам, совершенно не воспринимаются пользователями. Очевидно, рядовым пользователям трудно копировать такие имена, как EXSERVER1 или MBXHUB-LONDON.

Специалисты Microsoft пришли к выводу, что проблему можно решить, организовав обмен данными между компьютерами с целью выяснить местонахождение почтового ящика пользователя. Именно это делает служба автообнаружения по таким указателям, как точка подключения службы (SCP) в Active Directory (AD). На основе полученной информации об Exchange определяется текущее местоположение почтового ящика. Конечно, AD доступна только за брандмауэром, но служба автообнаружения может получить нужные данные с использованием URL-адресов, опубликованных в Интернете. Этот метод закладывает фундамент для простого подключения к Exchange Online в BPOS и Office 365. Без службы автообнаружения администраторам пришлось бы решать гораздо более сложную и затратную задачу, настраивая пользовательские компьютеры на подключение к «облаку».

Служба автообнаружения успешно работает только с двумя клиентами: Outlook 2010 и Outlook 2007. Информация, возвращаемая службой клиенту, была расширена. Теперь служба автообнаружения может собрать данные об альтернативных почтовых ящиках, которые должен открыть Outlook (то есть почтовых ящиках, к которым пользователю предоставлен полный доступ), и URL-адреса, сопоставляющие службы Exchange, такие как точка распространения автономной адресной книги (OAB), веб-службы Exchange, единая система обмена сообщениями и т.д. Exchange передает всю эту информацию в виде XML-данных в Outlook. Информация обновляется через каждые 15 минут, чтобы своевременно учитывались любые изменения.

В режиме проверки автоконфигурации электронной почты можно более глубоко заглянуть в информацию, собранную службой автообнаружения. Чтобы перейти в этот режим, нажмите клавишу CTRL и щелкните правой кнопкой мыши пиктограмму Outlook в панели задач. Из меню выберите пункт Test E-mail AutoConfiguration. Снимите флажки Use Guessmart и Secure Guessmart Authentication, введите адрес электронной почты и нажмите кнопку Test. Происходит тот же процесс, который используется программой Outlook при первом заполнении пользовательского профиля. Перейдите на вкладку XML, чтобы увидеть данные, возвращаемые Exchange.

Как показано на приведенном экране, эти данные содержат такие подробности, как имя сервера и URL-адреса, необходимые для подключения к веб-службам Exchange (EwsUrl) и ECP (EcpUrl). В этом примере было выполнено подключение к почтовому ящику Office 365, поэтому результаты получены от Office 365.

 

Результаты выполнения теста автообнаружения
Экран. Результаты выполнения теста автообнаружения

Следует отметить, что наличие службы автообнаружения — одна из причин, по которым Microsoft не поддерживает подключение клиентов Outlook 2003 к Office 365. В Outlook 2003 можно настроить вручную все параметры сервера для подключения к «облачному» почтовому ящику, однако автоматическая природа обновлений профиля службой автообнаружения в Outlook 2010 и Outlook 2007 обеспечивает простое перемещение почтовых ящиков между серверами. Компания Microsoft постоянно добавляет серверы в процессе развития инфраструктуры Office 365, а затем выравнивает рабочую нагрузку между доступными серверами, перемещая почтовые ящики между базами данных. Если подключены клиенты Outlook 2003, пользователям необходимо знать, что делать в случае перемещения почтовых ящиков. Результаты могут доставить много хлопот службе поддержки. Благодаря ограничению совместимости с версиями устраняется потенциальная проблема поддержки, а пользователи получают дополнительный стимул для перехода к программам, в которых реализованы передовые серверные функции (например, MailTips). Таким образом, это беспроигрышная ситуация для Microsoft.

Благодаря службе автообнаружения администраторам Office 365 приходится реже помогать пользователям. Она будет третьим номером.

#4. Служба репликации почтовых ящиков: плавное, безупречное перемещение

По-прежнему в моде почтовые ящики очень больших размеров. Трудно сказать почему, ведь подавляющему большинству пользователей требуется очень много времени, чтобы заполнить почтовый ящик на 25 Гбайт. Как бы то ни было, с появлением больших почтовых ящиков задача их перемещения значительно усложнилась.

До выпуска Exchange 2010 администраторам приходилось просить пользователей выйти из системы, прежде чем можно было приступить к перемещению почтовых ящиков. Перемещение происходило в реальном времени, и любые действия были невозможны, пока почтовый ящик не достигал места назначения. Если в ходе переноса возникали неполадки, процесс приходилось начинать заново. Такое решение, хотя и работоспособное, неэффективно, если почтовые ящики требуется перемещать с серверов внутри компании в «облако» или наоборот. Как отмечалось ранее, Microsoft приходится работать в условиях почти беспрерывных перемещений почтовых ящиков, чтобы сбалансировать базы данных в процессе построения инфраструктуры Office 365.

Решением стала служба MRS в Exchange 2010. Отныне перемещение почтовых ящиков происходит в фоновом режиме, с частыми проверками и достаточно интеллектуальным механизмом, чтобы распознать затруднения на принимающем сервере. Перемещения нельзя выполнять по расписанию (недостаток, который компания Microsoft наверняка устранит в будущем), но можно автоматически приостанавливать. В этом случае копируется начальный моментальный снимок содержимого почтового ящика в фоновом режиме, а затем наступает пауза. Администратор может проверить отчет о перемещении почтового ящика и продолжить действие, если все обстоит благополучно. Затем служба MRS делает новый моментальный снимок исходного почтового ящика и выполняет добавочную синхронизацию перед переключением указателей в AD, чтобы направить пользователя в новое место.

Главное достоинство службы MRS — чрезвычайно успешное перемещение почтовых ящиков между лесами AD, с серверов внутри компании в «облако», и между версиями Exchange (начиная с Exchange 2003). Без этой службы трудно представить, как удастся справиться с переводом миллионов почтовых ящиков в Office 365; объем ручной работы, связанной с настройкой и управлением движением почтовых ящиков через Интернет, будет колоссальным. Вместо этого многие компании используют метод автоматической приостановки для перемещения почтовых ящиков в фоновом режиме, за 30 дней до окончательного перевода пользователя в среду Office 365.

Возможности службы MRS не ограничиваются только перемещением почтовых ящиков. Компания Microsoft расширила ее функции управлением такими задачами, как импорт и экспорт данных почтовых ящиков из файлов личных папок (PST) и запросы восстановления почтовых ящиков. В силу ключевой роли службы MRS в управлении почтовыми ящиками она стала номером четыре в моем списке.

#5. Поддержка нескольких браузеров

Ни одна достойная «облачная» служба не обойдется без поддержки браузеров. В Exchange применение браузеров началось с 1997 года, когда вместе с Exchange 5.0 была поставлена первая версия Outlook Web Access (OWA), впоследствии переименованная в Outlook Web App (но по-прежнему OWA). Надо признать, что первая версия OWA была не очень удачной. Однако после 1997 года был достигнут значительный прогресс в интерфейсах, стандартах и функциях браузера.

В настоящее время OWA располагает отличным многофункциональным интерфейсом пользователя, заметно превосходящим конкурентов, в частности Google Gmail. OWA просто подключается как к размещаемым внутри компании, так и к «облачным» версиям Exchange, и успешно работает на Internet Explorer (IE), Google Chrome, Mozilla Firefox и Apple Safari. Другие браузеры совместимы с базовой версией OWA, очень полезной, несмотря на отсутствие некоторых функций полноценной версии.

Не менее важной стала эволюция интерфейсов управления на основе браузера. В Exchange 2010 появилась панель управления ECP; она быстро превратилась в источник недоразумений для администраторов, так как некоторые задачи, такие как поиск методом обнаружения или обслуживание политики устройств ActiveSync, можно выполнить только через ECP. В основной командной консоли Exchange нет и следа этих задач. Не менее досадно, что некоторые задачи, например управление группой обеспечения доступности баз данных (DAG), отображаются только в консоли EMC. Так, управлять DAG можно только через EMC, в которой есть и другие удобные функции, в частности для выполнения сложных задач (например, управление сертификатами) на основе мастера или показа исходного текста PowerShell, задействованного в ходе решения задачи.

Однако важно понять, что панель управления ECP представлена лишь первой редакцией. Управление на основе веб — критически важный элемент эволюции Exchange Online в рамках Office 365. Можно предположить, что со временем в панели ECP будет появляться все больше административных задач, до тех пор, пока необходимость в двух консолях управления не отпадет. Когда-нибудь Microsoft удалит консоль EMC из Exchange, оставив нам один клиент управления на основе браузера, в котором, как мы надеемся, будет вся функциональность EMC, необходимая администраторам.

Панель управления ECP уже поддерживает тот же круг браузеров, что и OWA, а с выходом Exchange 2010 Service Pack 1 (SP1) выполнять административные задачи из ECP смогли пользователи, не имеющие доступа к электронной почте. Признавая ключевую роль комбинации OWA/ECP как для пользователей, так и для администраторов (сегодня и в будущих «облачных» службах), я отвел ей пятое место в списке.

#6. Хранение данных: байты дешево и сердито

Самым затратным компонентом при развертывании Exchange 2003 было хранилище данных. Отчасти это объяснялось стоимостью одного гигабайта памяти в 2003-2005 годах, но более весомым фактором был характер операций ввода-вывода Exchange. Скажем прямо: требования Exchange 2003 к операциям ввода-вывода были очень высокими. Единственным способом добиться приемлемой производительности было развертывание дорогостоящего хранилища с необходимой производительностью для обслуживания нужного числа почтовых ящиков. Часто приходилось применять хранилища SAN (дорогостоящие как при покупке, так и в эксплуатации для Exchange).

Компания Microsoft внесла изменения в хранилище данных в Exchange 2007, чтобы улучшить работу операций ввода-вывода продукта. Попытка увенчалась успехом. Фундаментальные изменения произошли в Exchange 2010: впервые начиная с Exchange Server 4.0 произошло изменение схемы базы данных. Сделано и много других обновлений, чтобы снизить требования к вводу-выводу и запускать Exchange на недорогих массивах DAS и «просто группах дисков» (Just a Bunch of Disks — JBOD). В результате требование к производительности ввода-вывода в одну операцию в секунду (IOPS) на почтовый ящик в Exchange 2003 снизилось до 0,1 IOPS в настоящее время. Кроме того, Exchange 2010 может обрабатывать огромные почтовые ящики, содержащие сотни тысяч элементов (это было бы выше возможностей Exchange 2003).

Если бы инженеры Microsoft не предприняли усилий к резкому повышению производительности базы данных, существование почтовых ящиков на 25 Гбайт было бы невозможно в любых конфигурациях, кроме самых простых киосков Office 365, а конкурировать с Gmail было бы бесполезно. По этим причинам совершенствованию хранилища данных присвоен шестой номер.

#7. Сервер клиентского доступа: черный ящик Exchange

Роль сервера клиентского доступа впервые появилась в Exchange 2007 как общая конечная точка для Интернет-протоколов. Затем она была расширена до уровня клиентского доступа удаленного вызова процедур в Exchange 2010 и стала конечной точкой для клиентов MAPI. На сервере клиентского доступа Exchange 2010 также размещается служба MRS, поэтому ему принадлежит важная роль в перемещении почтовых ящиков.

Переход от сервера почтовых ящиков к серверу клиентского доступа — вот причина важности этого компонента, на мой взгляд. Без сервера клиентского доступа не удалось бы разорвать связь между почтовым ящиком и сервером, существовавшую до появления Exchange 2010. Высокая доступность, достигнутая благодаря группам DAG, также была бы невозможна, так как не удалось бы быстро и легко переключать базы данных между серверами. Без групп DAG компании Microsoft вряд ли удалось бы развернуть Exchange Online с многочисленными экземплярами базы данных в географически разделенных центрах обработки данных. Компания не смогла бы предоставить соглашение об уровне обслуживания 99,9 % с финансовым обеспечением, существующее для Office 365.

Есть и другие достоинства. Сервер клиентского доступа — ключ к эффективному управлению входящими клиентскими соединениями. Администраторам внутри компании будет известно о взаимодействии между брандмауэрами, балансировщиками нагрузки и сервером клиентского доступа при управлении клиентами HTTP, MAPI, IMAP4, POP3 и ActiveSync. Благодаря важным изменениям в Windows Server 2008 R2 и Exchange 2010 — в частности, возможности объединить отдельные серверы клиентского доступа в массивы и лучшей обработке идентификаторов сеансов — серверы эффективнее обслуживают намного больше соединений. Это очень важно, учитывая, что в будущем Office 365 предстоит управлять десятками миллионов клиентов. Поэтому последнее место в моем списке досталось серверу клиентского доступа.

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

Что дальше?

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

Я не уверен, что инженеры до конца продумали, как эти компоненты будут согласованы друг с другом, когда проектировали каждый отдельный компонент, но счастливый случай привел нас к существующему положению вещей. Уверен, что разработка не окончена, и по мере приближения 20-летия Exchange в 2016 году мы станем свидетелями огромных изменений в продукте. Если мы повторим подобный обзор в будущем, вероятно, некоторые компоненты сохранят свое место в списке. Вопрос в том, какие новые компоненты появятся в следующие четыре или пять лет.