Microsoft подтягивает Directory Store до Windows 2000
В своем продукте Exchange Server корпорация Microsoft всегда поддерживала концепцию службы интегрированного каталога, в котором как единое целое хранится подробная информация о почтовых ящиках, списках адресов, настройках серверов и структуре всей организации. Такой каталог гарантирует, что на всех серверах имеется самая точная информация о внесенных изменениях. Пользователи заглядывают в каталог для проверки адресов электронной почты или их поиска в глобальном списке адресов Global Address List (GAL). Но сервер Exchange 2000 Server (ранее известный как Platinum) тесно связан со службой каталога Active Directory в Windows 2000. AD берет на себя функции, которые выполняла служба Directory Store в Exchange Server версии 5.5. Сервер Exchange 2000 — первое большое приложение из комплекта Microsoft BackOffice, которое использует возможности, предоставляемые AD, и должен продемонстрировать преимущества интегрированного каталога. Эта статья посвящена новой архитектуре Exchange 2000 Server. Кроме того, я хочу уточнить некоторые термины и дать несколько советов по настройке.
Совершенно иной уровень интеграции
Каждая версия Exchange Server была интегрирована с операционной системой. Exchange Server версии 5.5 и его предшественники взаимодействовали с Windows NT по-разному: это касалось системного администрирования, аутентификации и протоколирования событий. Exchange 2000 интегрирован с Windows 2000 на более глубоком уровне, он тесно связан с единой базой AD, его надежным фундаментом. Раньше такой зависимости не наблюдалось: Exchange Server 5.5, как и более ранние его версии, мог работать с совершенно разными версиями NT.
AD предоставляет сервис службы каталога для Windows 2000 и приложений. Интегрирование операционной системы и приложений в одной службе каталога означает, что перед развертыванием Exchange 2000 нужно продумать единую схему для структуры доменов и связанное с ней пространство имен. Пространство имен реализуется через DNS. Как всегда при внедрении новой технологии, определение оптимального пути развертывания на предприятии AD и DNS займет некоторое время. Exchange 2000 предоставляет много новых возможностей, воспользоваться которыми хочется немедленно. Однако интеграция Exchange 2000 и AD несколько усложняет проводимый перед началом развертывания процесс планирования.
Архитектура каталога и базы данных
По сути дела, служба каталога Directory Store в Exchange Server и AD используют одну и ту же архитектуру.
 |
| РИСУНОК 1. Архитектура Active Directory. |
 |
| РИСУНОК 2. Модель протоколирования транзакций, применяемая Active Directory. |
На Рисунке 2 показано, какими способами процессор базы данных фиксирует транзакции в Active Directory и в Directory Store. Есть, правда, небольшое отличие в именах файлов: в случае с AD управление транзакциями осуществляет файл lsass.exe, а не dsamain.exe, и служба каталога записывает данные в базу данных AD, ntds.dit, а не в базу Exchange Server 5.5, dir.edb. Небольшие изменения внесены в реализацию, например журнал транзакций вмещает 10 Мбайт данных вместо 5. Однако администраторам систем Exchange также полезно ознакомиться с приведенной на Рисунке 2 моделью протоколирования транзакций, поскольку такую же использует служба Information Store (IS).
При переходе к Exchange 2000 следует учесть некоторые особенности работы Exchange Server. Прежде всего необходимо защитить Directory Store настолько, насколько возможно, так как после сбоя его будет трудно восстановить. AD не похожа на SAM NT. Ее база данных намного сложнее и может вместить несколько миллионов объектов. Наилучшим способом размещения AD, по опыту работы с Exchange Server, следует признать использование массива RAID уровня 5 или уровня 0+1. При этом журналы транзакций размещаются на другом физическом томе с защитой RAID уровня 1. Необходимо ежедневно выполнять резервное копирование и иметь план восстановления после сбоя, подробно описывающий процесс «реконструкции» разрушенной базы данных AD. Если при этом остановившийся сервер является контроллером домена или Global Catalog (GC), нужно четко представлять себе, каким образом можно поскорее вернуть его в строй.
Специалисты Microsoft тщательно изучили все проблемы, с которыми сталкивались пользователи Directory Store, и внесли необходимые изменения в Active Directory, в том числе реализовали возможность поатрибутной репликации. Directory Store производит репликации пообъектно, т. е. если один из атрибутов почтового ящика меняется (например, номер телефона или контактное лицо), то реплицируется весь объект. А это означает, что при малейшем изменении объекта должны реплицироваться от 3,5 до 4 Кбайт данных. В случае же с AD, наоборот, репликации проводятся поатрибутно. В Windows 2000, при изменении одного из связанных с атрибутом объекта «пользовательский почтовый ящик», на другие серверы реплицируются только изменившиеся атрибуты. Точное количество данных зависит от типа модифицированного атрибута: для простых строковых атрибутов, например имени в адресной книге, реплицируется только 100 байт.
Поатрибутная репликация необходима в случае, когда служба Directory Store (DS) обрабатывает объекты как самой операционной системы, так и приложений. Объект «пользователь» может содержать намного больше атрибутов, чем почтовый ящик Exchange Server 5.5, и, следовательно, занимать больше места, чем отводится объекту в базе каталога, — около 6 Кбайт на объект «пользователь», имеющий почтовый ящик. Количество атрибутов, связанных с объектом, можно увеличить, модифицируя схему каталога. Например, Exchange 2000 изменяет схему AD для добавления поддержки адресов электронной почты. Дополнительные атрибуты означают, что количество данных для репликации увеличивается, и, таким образом, каждое новое приложение, устанавливаемое в системе, может настолько повысить общую нагрузку на нее, что механизм репликации «забуксует». Поатрибутная репликация позволит избежать таких ситуаций, но не поможет преодолеть другие препятствия на пути систем.
Сайты, сайты, сайты
Одни термины, описывающие структуру организации в Exchange Server, сохраняются и в Windows 2000, а значения других расширяются, отражая изменения, внесенные в Exchange 2000 для использования AD вместо Directory Store. Разработчики Microsoft построили AD на базе модели доменов с несколькими главными доменами. В отличие от NT, где заднействована только одна доступная для записи копия базы SAM, расположенная на PDC и отвечающая за все изменения (например, смену пароля), служба AD позволяет модифицировать свойства объекта на любом контроллере домена. Все контроллеры в домене имеют право на запись для любого объекта, принадлежащего домену, подобно тому, как любой сервер Exchange Server 5.5 имеет право на запись для любого объекта, принадлежащего сайту. В Windows 2000 используется понятие «сайт» (site), но под ним уже подразумевается не большой составляющий блок организации, как в Exchange Server. Сайт в Exchange Server 5.5 — вовсе не то же самое, что сайт Windows 2000 или домена Windows 2000.
Сайт в Exchange Server 5.5 определяет границу операций администрирования, маршрутизации сообщений и сети. Все серверы внутри сайта автоматически получают доступ к общему каталогу и могут посылать друг другу сообщения напрямую. Обращаясь к каталогу, серверы «узнают» обо всех доступных внешних соединениях на других серверах внутри сайта и, следовательно, могут совершать обычные операции маршрутизации. В Windows 2000 применяется общая учетная запись службы для запуска и остановки набора служб Exchange на всех серверах внутри сайта, а также набор других доступных учетных записей для администрирования. Сайт Exchange Server может охватывать несколько доменов Windows NT, но я не рекомендую делать этого. Использование нескольких доменов NT — нестандартная конфигурация, сильно зависящая от доверительных отношений. В большинстве объемных реализаций для простоты управления предпочтительнее размещать все серверы сайта в общем домене.
В большинстве случаев тот факт, что сайт Exchange Server 5.5 служит границей для сети, маршрутизации и административных операций, проблем не создает. На самом деле это и есть интегрированный подход к управлению, который большинству пользователей представляется оптимальным. Однако такой метод я бы назвал недостаточно гибким для применения в больших организациях, где за работу сети, маршрутизацию и администрирование отвечают разные группы сотрудников. Exchange 2000 не использует одну программу административного управления, как Exchange Server 5.5. Вместо этого, для разделения ответственности за выполнение разных задач между администраторами, применяются дополнительные модули (snap-in) консоли MMC.
Определение границ сайта становится почти искусством. Работоспособность сети здесь играет очень большую роль, и многие сетевые архитекторы предпочитают не помещать сервер в сайт, если тот не соединен каналом, имеющим пропускную способность более 64 Кбит/с. Все соединения между серверами в сайте устанавливаются с помощью механизма вызовов удаленных процедур (remote procedure call, RPC). Составить расписание соединений невозможно, поскольку серверы формируют автоматическую сетевую среду передачи сообщений друг другу (по схеме «каждый с каждым»). Мастер Move Server Wizard (впервые реализованный в Exchange Server 5.5 с Service Pack 2) позволяет перемещать сервер из одного сайта в другой, что может смягчить последствия неверной установки границ сайта.
Сетевая граница сайта Windows 2000 определяется границами IP-подсетей, поэтому сайт привязан к физической топологии сети. Как и в сайте Exchange Server, все контроллеры домена внутри сайта Windows 2000 взаимодействуют через RPC для репликации AD. Служба Knowledge Consistency Checker (KCC) автоматически соединяет контроллеры домена после их включения в сайт для выполнения внутри него репликации AD. KCC является реализацией одной из концепций, заложенной Exchange Server. Каждые 15 минут KCC просматривает контроллеры домена и удостоверяется, что все необходимые соединения для проведения репликации между ними существуют. Внутри сайта объекты типа «соединение» связывают контроллеры домена, формируя топологию репликации, которой управляет KCC. Детали объектов «соединение» расположены в AD. В отличие от Exchange Server, где Directory Store применяет сетевую схему репликации «каждый с каждым», KCC обеспечивает оптимальный вариант проведения репликации и уменьшает объем реплицируемых данных. Например, KCC обеспечивает связь контроллеров домена между собой (посредством объектов «соединение») только через три транзитные точки. Оптимизация репликации важна для любой системы передачи сообщений, но наиболее критична для операционной системы, зависящей от быстрой репликации данных, ведь это позволяет каталогу быть устойчивым и непротиворечивым во всей сети. Пользователи недовольны, когда смена пароля происходит медленно. Как организация в Exchange Server 5.5 может иметь несколько сайтов, каждый из которых представляет собой остров высокоскоростных сетей, так и домен Windows 2000 может состоять из нескольких сайтов, объединяющих сети c такими же характеристиками.
Просматривая сайты Windows 2000, AD определяет, какому ближайшему контроллеру направлять клиентские запросы для аутентификации. Аутентификация должна проходить как можно быстрее, поэтому направление клиента на удаленный контроллер домена не имеет смысла. Клиент Windows 2000 может запросить DNS для определения ближайшего контроллера домена или GC и затем соединиться с ним. Клиенты исследуют сайт, в который попали после первого запроса к DNS в поисках списка контроллеров домена. Далее, сравнивая IP-адрес клиента и подмножества IP-адресов сайтов Windows 2000, клиенты соединяются с первым контроллером в списке. Контроллер домена сообщает клиенту информацию о сайте, которая помещается в реестр клиента. В дальнейшем при старте клиента и запросе на аутентификацию, список контроллеров домена запрашивается у сервера DNS только для того сайта, который выполняет аутентификацию локально. DNS «узнает» контроллеры домена по специальной записи об услуге, которую Windows 2000 помещает в базу DNS при старте контроллера домена.
Домены Windows 2000
Домены Windows 2000 определяются как часть корпоративного пространства имен и могут охватывать множество сайтов. Специальные коннекторы связывают сайты между собой, как в случае Exchange Server. Windows 2000 не поддерживает соединения между сайтами по протоколу X.400, поэтому связь возможно только через RPC (подобно коннектору Exchange Server 5.5 Site) и SMTP (подобно коннектору Exchange Server 5.5 Internet Mail Service). SMTP является единственным механизмом репликации между сайтами и GC. Служба KCC обследует соединения между сайтами и автоматически создает топологию репликации, основываясь на информации о сайтах и соединениях, связывающих их.
Понятия «пространство имен» и «сетевая топология» в Windows 2000 разделены. Серверы сайта Exchange Server 5.5 делят общее пространство имен, но только для передачи сообщений. Приложения разделяют пространство имен Windows 2000, которое система использует для аутентификации, маршрутизации сообщений и для других целей (например, репликации AD).
В некоторых отношениях наличие общего пространства имен для Exchange 2000 и Windows 2000 представляется оптимальным сценарием развертывания. Например, так как мой адрес электронной почты — tony.redmond@compaq.com, я должен входить в сеть и проходить аутентификацию на контроллере домена compaq.com, используя tony.redmond в качестве имени пользователя, а адрес электронной почты — как псевдоним. На начальном этапе развертывания Windows 2000 вряд ли найдется много компаний с правильно унифицированным пространством имен. При переходе от доменов с уже существующей организацией имен или адресами электронной почты и в силу необходимости администрирования серверов на организационной или географической основе, большие корпорации будут иметь иерархическое пространство имен с несколькими уровнями. Например, администраторы могут разделить пространство имен компании по территориальному принципу, с отдельными доменами для каждого региона, типа europe. acme.com и asia.acme. com. По умолчанию в AD объект «пользователь» может иметь только один адрес электронной почты, но установка Exchange 2000 раздвигает эти границы, разрешая иметь много адресов разного типа (например, SMTP, X.400) — так, как это было в Exchange Server 5.5.
В отличие от Exchange Server 5.5 Directory Store, в котором сайт является одним из самых важных компонентов пространства имен, в Windows 2000 пространство имен определяют домены; сайт за это не отвечает. Каждый объект в Directory Store имеет уникальное определенное имя Distinguished Name (DN), которое включает в себя и имя сайта. Но в Windows 2000 домены могут состоять из нескольких сайтов, и имя сайта Windows 2000 не включается в имя DN, используемое AD для идентификации объекта. Существует еще одно отличие от Exchange Server 5.5: в Windows 2000 имеет место ситуация, при которой логическая организация каталога не зависит от топологии сети; возможно раздельное планирование каталога и сетевой топологии.
Маршрутизация из Exchange 2000 в AD
Все соединения Exchange 2000 c AD используют программный слой, называемый Directory Store Access API (DS API), располагающийся поверх LDAP. Его роль состоит в обеспечении универсального API-интерфейса для всех служб Exchange 2000, запрашивающих у AD информацию о пользователях, контактах и общие данные настройки. На каждом сервере Exchange 2000 хранится кэш, называемый Directory Access Cache, содержащий результаты недавних запросов к GC. Получение данных из этого кэша занимает намного меньше времени, чем выполнение запроса к GC, особенно для процессов IS или нового SMTP Routing Engine, поэтому Exchange 2000 всегда в первую очередь опрашивает кэш. Через реестр можно задать настройки кэша, определив, как часто Exchange Server будет освобождать кэш и какой объем данных он способен хранить. По умолчанию, кэш содержит 4 Мбайт информации не более 10 минут. Для настройки кэша на хранение, например 8 Мбайт в течение 30 минут, нужно изменить два параметра реестра. Сначала найдем параметр HKEY_ LOCAL_MACHINESYSTEM CurrentControlSet ServicesMSExchangeDSAccessInstance0 CacheTTL. Для указания периода времени 30 минут задается значение времени кэширования равным 0х1800 типа REG_DWORD. Затем перейдем к параметру HKEY_LOCAL_MACHINE SYSTEMCurrentControlSet ServicesMSExchangeDSAccess Instance0MaxMemory. Для хранения 8 Мбайт информации, устанавливаем значение размера кэша равным 8192 (в килобайтах) типа REG_DWORD.
Как и Exchange Server 5.5, Exchange 2000 опрашивает каталог при получении запроса на доступ к двум большим категориям информации: таблице поиска адресов и данным настройки. Exchange 2000 всегда пытается выбрать контроллер, способный наилучшим образом обслужить запрос. Контроллер домена легко отвечает на запросы о локальных пользователях, но только GC может проводить поиск по базе адресов электронной почты. DNS извлекает информацию о контроллерах домена локального сайта и GC, так же как клиенты опрашивают локальные контроллеры при аутентификации. Если Exchange 2000 находит в сайте несколько контроллеров GC, он использует их циклически. Для распределения нагрузки по имеющимся GC можно применять службу Windows NT Load Balancing Service (WLBS).
Global Catalog (GC)
GC представляет собой контроллер домена, который управляет копией AD, напоминающей очень известную базу Directory Store в Exchange Server 5.5. Любой контроллер домена можно преобразовать в GC, подключив поток Listener Thread к порту 3268. После этого любые изменения будут реплицироваться в GC через названный порт от каждого домена в лесу. Лес состоит из деревьев доменов, разделяющих общие настройки и схему. GC содержит доступные для записи копии всех объектов, принадлежащих домену, и доступные только для чтения копии всех объектов, принадлежащих другим доменам леса. Таким образом, GC является единственным контроллером, содержащим данные об универсальных группах, которые включают объекты любого домена. Так, при аутентификации Windows 2000 выполняет поиск по GC для создания полного security ticket клиента. Но если имеется только один домен, то все его контроллеры являются GC, и выяснить, принадлежит ли объект универсальной группе, можно на том же контроллере.
GC не реплицирует каждый атрибут объекта из других доменов. Вместо этого схема AD, которой управляет особый сервер, называемый schema master, определяет детали атрибута, подлежащие репликации из AD в GC. Исходя из принципов передачи сообщений, атрибуты, которые AD реплицирует по умолчанию, содержат всю информацию, необходимую для глобального списка адресов GAL. Такое наполнение очень важно, поскольку GC выдает GAL клиентам, соединившимся с сервером Exchange 2000. Можно снизить требования к пропускной способности, накладываемые AD для репликации GC, уменьшая количество реплицируемых AD атрибутов. Я рекомендую это делать, только если нет другого пути, кроме репликации данных по медленным каналам связи.
Только одна организация Exchange Server может существовать в лесу Windows 2000. Например, compaq.com и домены его подразделений образуют лес. AD реплицирует данные настройки (допустим, информацию о серверах) на весь лес. Объекты всех доменов леса образуют GC, но GC не содержит информацию об объектах, принадлежащих другим лесам, — даже если существует соединение с доверительными отношениями. Если требуется создать две и более организации Exchange Server, необходимо задать нужное количество лесов и доменов в них, в соответствии с желаемой инфраструктурой. Объединить или разъединить леса невозможно, поэтому следует убедиться, что каждый лес будет поддерживать соответствующую организацию Exchange Server до того, как она будет реализована.
Синхронизация каталога между лесами не происходит автоматически, для этого нужен внешний механизм типа LDAP Directory Synchronizer Utility (LDSU) от Compaq, либо написанный на заказ продукт с использованием интерфейсов Active Directory Services Interface (ADSI), или LDAP Directory Interchange Format (LDIF). Последний можно применять для экспорта/импорта информации из/в AD, как это делается с помощью файлов в формате CSV в Directory Store. Операционная система Windows 2000 предоставляет инструмент экспорта/импорта LDIF Bulk Import/Export, ldifde.exe, который можно использовать для синхронизации изменений другими LDAP-совместимыми каталогами.
А как же клиенты?
Пользовательские программы могут получить доступ к GAL по LDAP или через интерфейс Name Service Provider Interface (NSPI-интерфейс, позволяющий MAPI-клиентам получать доступ к каталогу). MAPI-клиенты, наподобие Microsoft Outlook 98 или более ранних версий, ищут Directory Store на всех серверах Exchange. Когда такие клиенты подсоединяются к серверу Exchange 2000, служба посредника Directory Store Proxy Service (работающая на каждом сервере Exchange 2000) перехватывает RPC-запросы клиентов к Directory Store и направляет их ближайшему GC. Система не производит никаких действий над пакетами, RPC-служба посредника Directory Store просто перенаправляет их в каталог. Такая невидимая для клиентов работа выполняется каждый раз, когда они соединяются с сервером Exchange 2000.
Outlook 2000 предлагает немного другое решение. Он записывает имя самого последнего GC, с которым устанавливалось соединение, в реестр системы, где это имя хранится наряду с другой информацией о профиле MAPI. Клиент Outlook 2000 способен соединиться с GC, не запрашивая компьютер Exchange 2000 о его точном адресе. Если же зарегистрированный GC в момент запуска Outlook 2000 недоступен, то клиент выдает серверу Exchange 2000 запрос на поиск другого адреса GC. Клиенты LDAP типа Outlook Express могут создавать прямые соединения с GC для доступа к GAL.
Обычно серверы Exchange 2000 проводят опрос, определяя ближайший GC, используемый при направлении и перенаправлении клиентов. Однако имеется возможность задания в реестре сервера Exchange 2000 особых GC для направления и перенаправления клиентов. Отвечают за это параметры реестра HKEY_LOCAL_ MACHINESYSTEMCurrentControlSet ServicesMSExchangeSAParametersNSPITargetServer и HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeSAParameters RFRTargetServer. Первый задает посредника для клиентов типа Outlook 98, а второй — для GC-совместимых клиентов типа Outlook 2000. В обоих случаях значением параметра является строка с именем GC сервера (например, GC-SERVER1). Можно заставить клиентов Outlook 2000 использовать процесс Directory Store Proxy для поиска GC, запретив направление на сервер Exchange 2000. Для этого устанавливается значение 0х1 типа DWORD для параметра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesMSExchangeSA ParametersNoRFRService.
Имена DN для получателей изменяются при переходе от Exchange Server 5.5 к Exchange 2000. AD может отслеживать эти изменения и выполнять разрешение старых DN имен Exchange Server, что дает пользователям возможность отвечать на старые сообщения. Это особенно важно, поскольку при переходе от Directory Store к AD изменился формат DN. Exchange Server 5.5 использует следующий формат:
/o=/cn=/cn= /cn=.
Например, DN для моего почтового ящика в Exchange Server 5.5 выглядит так:
/o=Compaq/cn=Dublin/cn=Recipients/cn=TonyR AD использует формат вида: cn=, cn=, dc=, dc=.
Таким образом, адрес моего почтового ящика в Exchange 2000 может выглядеть так:
Cn=Tony Redmond, cn=Users, dc=Compaq, dc=com.
Утилита AdsiEdit из комплекта Microsoft Windows 2000 Resource Kit позволяет просмотреть и DN объекта пользователь в AD, что показано на Экране 1.
 |
| ЭКРАН 1. Просмотр свойств объекта «пользователь AD» с помощью утилиты AdsiEdit. |
Сайт Exchange Server 5.5 часто использует возможности просмотра типа Address Book Views (ABV) или контейнеры для структурирования разбиения GAL на разделы. AD поддерживает подобную функцию с помощью списков Address List, соответствующих предопределенным запросам LDAP, которые периодически выполняет процесс Exchange Server Attendant.
 |
| ЭКРАН 2. Применение запроса LDAP для построения Global Address List. |
Администрирование и маршрутизация
Сайт Windows 2000 определяет сетевую топологию. Exchange Server 5.5 объединяет администрирование и маршрутизацию, в то время как Exchange 2000 разделяет эти задачи по группам администрирования и маршрутизации, разбивая задачи администрирования на удобные исполнительские блоки. Хотя и теперь можно делегировать одному или нескольким пользователям права на выполнение всех административных задач на сервере Exchange. Кроме того, появилась возможность назначать ответственных лиц для выполнения разных обязанностей на более низких уровнях.
Принадлежность к группам администраторов позволяет управлять одним или несколькими серверами. Можно задавать определенные политики, обязывающие администраторов следовать правилам, или дать им возможность управлять серверами по своему усмотрению. Группы маршрутизации задают топологию передачи сообщений и способ обмена сообщениями между серверами Exchange. Как и в сайте Exchange Server 5.5, все серверы из группы маршрутизации автоматически соединяются между собой и передают сообщения напрямую один другому. Для объединения групп маршрутизации можно использовать коннекторы групп маршрутизации, SMTP или X.400. Коннекторы групп маршрутизации также применяют SMTP, разница между ними и коннекторами SMTP заключается в способе обращения к AD. Коннекторы групп маршрутизации пересылают сообщения, основываясь на данных настройки Exchange Server, хранимых в AD; коннекторы SMTP обращаются к DNS для нахождения SMTP серверов. Запись DNS может содержаться и в AD, и на DNS-сервере UNIX.
Exchange 2000 при установке первого сервера создает в AD стандартные группы администрирования и маршрутизации; все серверы входят в эти группы до тех пор, пока не будут созданы новые.
 |
| ЭКРАН 3. Вид консоли MMC Exchange System Manager. |
При желании можно разместить все серверы организации в одной группе маршрутизации и в одной группе администрирования, что будет эквивалентно установке всех серверов в один сайт Exchange Server 5.5. Такой вариант не очень удобен, за исключением случаев небольших установок Exchange Server 5.5, где полоса пропускания сети позволяет это сделать. Вероятнее всего, организация Exchange 2000 будет состоять из нескольких групп администрирования и маршрутизации. Логично было бы создать вначале группы администрирования и маршрутизации для каждого существующего сайта Exchange Server 5.5, которые по мере развертывания Exchange 2000 вольются в новую структуру.
Очевидно, что, пока не сформируется инфраструктура Exchange 2000 и пока администраторы не переведут все серверы Exchange Server 5.5 на новую версию, будет существовать смешанная структура Exchange 2000 и Exchange Server 5.5. Как и в случае со смешанной структурой Windows 2000, смешанная структура Exchange 2000 имеет ограничения. Прежде всего, это невозможность создания нескольких групп администрирования и маршрутизации, пока не будет переведен на новую версию последний сервер Exchange Server 5.5 и не образуется истинная организация Exchange 2000.
Разделение труда
По замыслу разработчиков Microsoft различные компоненты системы передачи сообщений можно разместить на разных компьютерах. Exchange 2000 поддерживает концепцию построения виртуального сервера, состоящего из систем управления доступом для клиентов и систем хранения. Такой сервер является ключевым элементом в создании сервера Exchange, способного поддерживать десятки тысяч почтовых ящиков на одном сервере, но при этом не стоит преуменьшать роль изменений, вводимых AD. Для AD не требуется запуска Directory Store на каждом сервере Exchange, вместо этого несколько серверов Exchange 2000 могут делить доступ к контроллерам AD или GC.
Такое усовершенствование экономит силы и время администраторов. Некоторые серверы Exchange сейчас выполняют лишнюю работу по репликации информации каталога между серверами. Появляется возможность возложить все обязанности по репликации на небольшое число выделенных серверов и снизить таким образом сетевой трафик, генерируемый Directory Store. Например, сайт Exchange Server 5.5, состоящий из шести крупных серверов с почтовыми ящиками и двух серверов, обслуживающих внешние каналы, будет иметь восемь копий Directory Store. Внутренняя репликация автоматически обновляет каждую копию. При наличии Exchange 2000 один или два контроллера домена (или GC) могут выполнять всю эту работу и обеспечивать тот же уровень обслуживания для клиентов и служб Exchange. Удаление шести копий Directory Store существенно снижает сетевой трафик и уменьшает количество дисковой памяти для хранения данных.
В процессе планирования установки Exchange 2000 прежде всего нужно определить, сколько же GC использовать и на каких почтовых серверах их размещать. По опыту работы могу сказать, что, по крайней мере, один GC следует размещать там же, где располагаются серверы Exchange 2000. Размещение двух GC обеспечивает большую гибкость — если, конечно, можно позволить себе такую роскошь, как дополнительный трафик, вызываемый репликацией. В Exchange 2000 для доступа к GC могут использоваться и дополнительные каналы глобальной сети; клиенты MAPI обычно располагаются близко к серверам Exchange и ожидают быстрого локального доступа к GAL. Другой компонент Exchange Server, Routing Engine, нуждается в доступе к GC для проверки адресов электронной почты, поэтому GC можно смело назвать ключевым компонентом Exchange 2000. Необходимость в дополнительных контроллерах GC будет зависеть от типа линии передачи и скорости сетевых соединений (а также от опыта работы с Exchange 2000 и AD). Размещать слишком много GC, как и серверов Exchange, в одном сайте так же плохо, как и слишком мало, из-за наличия трафика, вызываемого репликацией.
Развивая схему
Exchange 2000 является первым приложением, которое расширяет схему AD, добавляя атрибуты, связанные с получением почты (пользователи, контакты, группы) и информацию о настройке сервера Exchange (группы администрирования и маршрутизации). Например, Exchange 2000 добавляет объекту «пользователь» атрибуты хранения, где указывается хранилище IS, в котором расположен почтовый ящик пользователя, и различные квоты, налагаемые на этот ящик. Расширение схемы происходит при первой установке сервера Exchange 2000 в лесу. В процессе установки Exchange 2000 производятся изменения на контроллере — мастере схемы, которые заносятся в контейнер конфигурации AD. В дальнейшем настройки реплицируются на другие контроллеры домена. Третья бета-версия Exchange 2000 производит порядка 800 изменений в схеме, поэтому имеет смысл выполнить первую установку на контроллере — мастере схемы, или как можно ближе к нему.
 |
| ЭКРАН 4. Просмотр свойств контейнера AD. |
На Экране 4 показаны свойства контейнера AD, содержащие детали настройки сервера Exchange. Каждый объект в AD имеет DN-имя. Контейнер с именем domain/configuration/services/microsoft exchange содержит несколько других контейнеров, где хранится подробная информация о группах маршрутизации и администрирования, списках адресов и коннекторах. Этот контейнер реплицируется по всем контроллерам леса, что позволяет всем серверам Exchange в организации иметь доступ к информации в нем. Похожая информация в Exchange Server 5.5 хранится в контейнере Directory Store.
Подсоединение Exchange Server 5.5 к AD
Соединить Exchange Server 5.5 и AD можно с помощью Active Directory Connector (ADC). ADC — одно- или двунаправленный соединитель, использующий протокол LDAP для синхронизации Exchange Server 5.5 Directory Store и AD. Каждый сайт Exchange Server 5.5 подсоединяется к AD с помощью отдельного «соглашения о соединении». Данное соглашение конкретизирует детали для репликации объектов по указанному соединению, тип соединения, метод аутентификации серверов и те серверы, которые будут поддерживать соединение.
 |
| ЭКРАН 5. Настройка ADC. |
На Экране 5 показано, что соединение LDAP использует порт 389. Этот порт можно задействовать, когда ADC и Exchange Server 5.5 работают на разных серверах. Однако если они расположены на одном сервере, номер порта LDAP нужно поменять. При запуске Windows 2000 номер 389 назначается стандартному порту LDAP, поэтому Exchange Server 5.5 приходится использовать другой порт. Это можно сделать в программе администрирования Exchange Server 5.5, на закладке Protocols свойств сервера.
ADC обычно работает по расписанию, возможно, раз в день. После синхронизации почтовые ящики Exchange Server 5.5 появляются в AD как объекты-получатели почты, а их владельцы — в списке контактов. В свою очередь в Directory Store пользователи Windows 2000 появляются в списке адресатов. В Exchange 2000 соединитель будет также базироваться на реализации LDAP; предусмотрена возможность синхронизации с адресной книгой Lotus Notes. Данное описание ADC довольно схематично, в следующей статье я надеюсь более подробно охарактеризовать его работу.
ADC может взаимодействовать только с Exchange Server 5.5, поскольку полагается на способность производить запись в Directory Store. Протокол LDAP версии 1.0, реализованный в Exchange Server 5.0, не предоставляет доступ для записи, а Exchange Server версии 4.0 и вовсе не поддерживает LDAP. Однако необходимости в модернизации всех серверов до версии 5.5 для использования ADC нет. В каждом сайте Exchange Server необходим только один сервер версии 5.5, который будет выступать в качестве моста синхронизации с AD.
Как часть подготовки к переходу на Windows 2000 и Exchange 2000, модернизация серверов версий 4.0 и 5.0 до 5.5 (с учетом последнего комплекта исправлений service pack) все равно потребуется. Ведь для плавной модернизации сервера почты до Exchange 2000 нужен установленный Exchange Server 5.5 и компьютер с Windows 2000.
Изучив концепции, лежащие в основе Directory Store и имея опыт работы с Exchange Server, можно подступиться к AD. Службу Directory Store иногда называют AD версии 0.9. Естественно, AD намного лучше, быстрее и удобнее, чем Directory Store. Служба AD построена на прочном фундаменте опыта, приобретенного специалистами корпорации при работе над каталогом Exchange Server начиная с 1996 года.
Но даже тем, кто имеет опыт использования Exchange Server, соединение Exchange 2000 и AD дает много пищи для размышлений. Измененная терминология, соединение Exchange Server 5.5 с Exchange 2000, создание новой модели администрирования, оптимизация работы среды Exchange 2000 до и после его установки — все эти задачи сложны даже для опытных администраторов. Лучше всего, конечно, пройти обучение на специальных курсах, но, если такой возможности нет, стоит взяться за изучение Windows 2000, AD и их интеграции с Exchange 2000 до того, как наступит время решать конкретные задачи.
Рисунок Стива Лионса