Архитектура хранилища Exchange Server

Предназначение хранилища в Exchange Server 2003

Архитектура хранилища в Exchange Server 2003 разработана для выполнения трех задач. Во-первых, это минимизация потерь продуктивности при переходе базы данных в автономный режим. В Exchange Server 2003 эта цель достигается посредством распределения пользователей по нескольким базам данных, которые могут быть смонтированы (запущены) или демонтированы (остановлены) по отдельности. Если по какой-либо причине одна база данных в группе хранилищ отключается, другие базы данных продолжают работать, что сводит к минимуму число пользователей, работа которых прерывается.

Вторая задача заключается в том, чтобы обеспечить поддержку на одном сервере большего числа пользователей, чем это практически возможно в Microsoft Exchange 5.5. Решение этой задачи достигается посредством распределения пользователей по нескольким базам данных на одном сервере. Так как базы данных в данном случае становятся меньшими по размеру, создание дополнительных баз данных позволит реализовывать на каждом сервере поддержку большего числа пользователей. Например, легче работать с шестью базами данных, в каждой из которых тысяча пользователей, чем управлять одной базой данных с шестью тысячами пользователей. Данный подход не только позволяет в отдельном порядке назначать время архивирования и восстановления и выполнять эти процедуры быстрее, но и ведет к снижению числа пользователей (с 6000 до 1000), на которых отразится повреждение одной из баз данных. Кроме этого, Exchange Server 2003 может группировать несколько баз данных в одну группу хранилищ и содержать несколько групп хранилищ на одном сервере.

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

Структура файла базы данных

Любая база данных Exchange 2003 состоит из двух файлов: файла в формате rich text (расширение .EDB), содержащего сообщения электронной почты и содержимое интерфейса Message Application Programming Interface (MAPI), и "потокового" файла с содержимым собственного формата (расширение .STM), в котором находится вся остальная информация, кроме данных MAPI. Из этого следует, что хранилище почтовых ящиков (оно называлось хранилищем частной информации в версиях Exchange 5.5 и более ранних) теперь состоит из пары файлов .EDB и .STM. Именами по умолчанию первого хранилища почтовых ящиков являются Priv1.edb и Priv1.stm (см. рис. 2.1). Аналогично, хранилище общих папок (в Exchange 5.5 оно называлось хранилищем открытой информации) теперь состоит из файлов Pub1.edb и Pub1.stm (см. рис. 2.2). Каждая база данных объединяет оба файла, и Exchange Server 2003 воспринимает эти файлы как одно целое. Когда Exchange сообщает о размере хранилища, представляется объединенный размер файла в формате rich text, файла с содержимым собственного формата и файлов журналов транзакций. Данные обоих типов хранятся в формате базы данных Extensible Storage Engine (ESE). (Речь о ESE пойдет далее в лекции.)

Файл формата rich text

Файл rich text содержит сообщения от клиентов MAPI, таких как Microsoft Outlook. Клиенты MAPI осуществляют доступ к этим сообщениям без выполнения преобразования на сервере. Файл rich text идентичен хранилищу информации Exchange 5.5. Он представляет собой файл .EDB, использующий ведение журналов транзакций, как и было в Exchange 5.5.

Преобразование содержимого по запросу

Когда клиент MAPI осуществляет попытку чтения сообщения из файла в формате rich text, преобразование не требуется, если сообщение изначально имело формат rich text или plain text (обычный текст) – обычный для клиента формат. Тем не менее, если клиент другого типа, например клиент HTTP, попытается прочесть сообщение в формате rich text или plain text, Exchange произведет преобразование сообщения в запрошенный формат. Процесс преобразования сообщения для инородных клиентов называется преобразованием по запросу.

Рис. 2.1. Вкладка Database (База данных) окна свойств хранилища почтовых ящиков

Рис. 2.2. Вкладка Database (База данных) окна свойств хранилища общих папок

При попытке клиента MAPI прочесть сообщение в формате HTML части этого сообщения могут располагаться в файле .STM. В этом случае сообщение также нужно преобразовать в пространстве памяти сервера Exchange.

Exchange Server 2003 не выполняет автоматическое преобразование данных при записи информации в базу данных. Преобразование данных вызывается действиями клиентов, например, при запросе данных в файле rich text инородным клиентом. Этот процесс называется отложенным преобразованием содержимого. Предположим, что веб-клиент отправляет сообщение на сервер Exchange. Это сообщение сохраняется в файле собственного формата. При запросе данного сообщение через порт TCP 80 другим клиентом Exchange извлечет его из файла с содержимым собственного формата без преобразования. Однако при запросе данного сообщение клиентом Outlook этот клиент осуществляет попытку чтения информации из базы данных, формат которой не соответствует обычному для клиента формату. В этом случае Exchange преобразует сообщение в памяти сервера, после чего передает его клиенту. Сообщение не перемещается из файла с содержимым собственного формата в файл rich text, не будучи отправленным клиенту Outlook.

Если клиент Outlook вносит изменение в сообщение и затем сохраняет его, сообщение копируется из файла с содержимым собственного формата в файл rich text, после чего удаляется из файла с содержимым собственного формата. В процессе копирования обновленное сообщение преобразуется в формат rich text.

Файл с содержимым собственного формата

В Exchange 5.5 сообщения всегда записываются в базу данных в формате Microsoft Database Encapsulated Format (MDBEF). Если сообщение в отличном от MDBEF формате требуется записать в базу данных, процесс Imail преобразует его в формат MDBEF.

В Exchange Server 2003 файл с содержимым собственного формата содержит все сообщения, формат которых отличен от MAPI, в их собственном формате, включая HTTP и IMAP4. Файлы обычного содержимого могут содержать аудио-, видео-, голосовые, HTML-сообщения и данные в других форматах. Исходные данные хранятся в своем обычном формате, без сжатия или другого преобразования, такого как B-дерево. Кроме того, в файле .EDB содержится информация о проверочных суммах страниц и об использовании пространства (эти сведения позволяют ESE определить, какие страницы базы данных используются, а какие свободны).

Сообщения, доставляемые из файла с содержимым собственного формата, направляются потоком клиенту. Потоковая доставка происходит быстро благодаря присутствию компонента режима ядра Win32 ExIFS (Exchange Installable File System). (Далее приводится более подробная информация о данном компоненте.)

Любой Win32-клиент имеет возможность доступа к данным в файле с содержимым собственного формата через архитектуру блокировки сообщения сервера (SMB). Эта возможность позволяет размещать в файле с содержимым собственного формата данные любого типа, они будут доступны LAN-клиентам как обычные открытые файловые ресурсы, и к ним можно будет осуществлять доступ через стандартные протоколы типа HTTP.

Как работает потоковая доставка

На рисунке 2.3 показано, как работает потоковая доставка в Exchange Server 2003. Предположим, что клиент Post Office Protocol 3 (POP3) запрашивает сообщение из файла с содержимым собственного формата. Клиент POP3 подключается к серверу POP3 в Internet Information Services (IIS), и сервер запрашивает у процесса Store (Store.exe) объявление дескриптора сообщения внутри файла с содержимым собственного формата. Процесс Store согласует дескриптор сообщения с драйвером Exchange Installable File System (ExIFS) режима ядра. Драйвер ExIFS блокирует сообщение, создает дескриптор и возвращает дескриптор процессу Store. Следует заметить, что в процессе исходящей передачи проверочные суммы страниц не подвергаются верификации. После объявления дескриптор передается виртуальному серверу POP3 через слой epoxy в пользовательском режиме. (В параграфе "Серверы front-end/back-end" далее в лекции рассказывается о слое epoxy.) Затем виртуальный сервер POP3 выполняет команду TRANSMITFILE, представляющую собой высокопроизводительный интерфейс API, использующий для передачи файла как дескриптор, так и сокеты. Команда TRANSMITFILE передается драйверу Auxiliary Function Driver (AFD), который, по сути, играет роль Winsock, организуя потоковую передачу файла из NT Cache Manager посредством взаимодействия с драйвером ExIFS. Необходимо заметить, что потоковые данные никогда не входят в пользовательский режим, что делает данную архитектуру быстродействующей и очень надежной. Дескриптор содержит список страниц базы данных, имеющих запрашиваемую информацию. Во время фазы блокировки ESE резервирует эти страницы и передает их ExIFS.

IIS тоже осуществляет запись в файл с содержимым в собственном формате. ExIFS представляет файл с содержимым в собственном формате для IIS в виде нескольких виртуальных файлов. Если IIS требуется выполнить запись в такой файл (например, входящее сообщение содержит вложение в виде рисунка), ExIFS создает виртуальные файлы, в которые выполняется запись. Затем ExIFS передает эти данные потоком в файл с содержимым в собственном формате и передает список страниц процессу Store. ESE фиксирует страницы посредством занесения информации в журналы транзакций. Проверочные суммы страниц сохраняются в файле rich text, чтобы в файле с содержимым собственного формата присутствовали только сами данные.

Рис. 2.3. Архитектура потоковой передачи файла с содержимым в собственном формате

ExIFS при необходимости запрашивает у ESE пространство базы данных и отводит в нем место для новых сообщений, что обеспечивает более быстрое выполнение записи.

Единое хранилище сообщений

Базы данных Exchange 2003 по-прежнему поддерживают функцию Single-Instance Message Store (SIS), действие которой заключается в том, что сообщение, отправленное нескольким получателям, сохраняется только один раз, пока все получатели находятся в одной и той же базе данных. SIS не поддерживается, если почтовый ящик перемещен в другую базу данных, даже если он по-прежнему находится в той же группе хранилищ. Более того, SIS не охватывает несколько баз данных в одной группе хранилищ.

Приведем пример работы SIS. Джон, администратор Exchange в компании с названием Trains by Dave, Inc. (разумеется, компания вымышлена), создал две группы хранилищ, каждая из которых состоит из четырех баз данных. Каждая группа содержит два хранилища почтовых ящиков и два хранилища общих папок. Мэри, пользователь сети Джона, отправляет сообщение размером 1 Мб в группу распространения из 40 получателей, причем все они находятся в первой группе хранилищ. 30 из них размещены в первом хранилище почтовых ящиков, а остальные 10 – во втором хранилище почтовых ящиков.

Без SIS сообщение было бы скопировано 42 раза (40 копий для 40 пользователей плюс одна копия для журнала транзакции плюс одна копия в папке Sent Items [Отправленные] в папке отправителя), что потребовало бы 42 Мб свободного места на диске для сохранения сообщения. Однако, как показано на рис. 2.4, с помощью SIS можно обойтись лишь тремя копиями сообщения: одна – в базе данных первого хранилища почтовых ящиков, вторая – в базе данных второго хранилища почтовых ящиков и третья – временная копия в журнале транзакций. Следовательно, отправка данного сообщения 40 получателям требует лишь 3 Мб свободного места на диске, что позволяет сэкономить 38 Мб пространства.

Рис. 2.4. Схема работы функции единого хранилища сообщений Single-Instance Message Store

Группы хранилищ и множество баз данных

Группа хранилищ состоит из объектов в памяти системы учета транзакций Extensible Storage Engine (ESE) (о ней речь пойдет далее в лекции), набора журналов транзакций и соответствующих им баз данных в группе. Объект ESE управляется процессом Store.exe, который работает как единый процесс. Каждая группа хранилищ содержит до пяти баз данных; на каждом сервере располагается до 4 групп хранилищ, то есть всего на одном сервере может находиться максимум 20 баз данных. Любую базу данных можно либо смонтировать (запустить), либо демонтировать (остановить). Несмотря на то что поврежденную базу данных нельзя смонтировать, она не сможет остановить работу процесса Store.exe или запуск или остановку других хранилищ группы. (В Exchange Server 2003 есть новая функция восстановления после сбоев Recovery Storage Group [Восстановление группы хранилищ]. Разговор о ней пойдет в лекции 8 "Функциональность, безопасность и поддержка Exchange Server 2003".)

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

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

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