Предназначение хранилища в Exchange Server 2003
Архитектура хранилища в Exchange Server 2003 разработана для выполнения трех задач. Во-первых, это минимизация потерь продуктивности при переходе базы данных в автономный режим. В Exchange Server 2003 эта цель достигается посредством распределения пользователей по нескольким базам данных, которые могут быть смонтированы (запущены) или демонтированы (остановлены) по отдельности. Если по какой-либо причине одна база данных в группе хранилищ отключается, другие базы данных продолжают работать, что сводит к минимуму число пользователей, работа которых прерывается.
Вторая задача заключается в том, чтобы обеспечить поддержку на одном сервере большего числа пользователей, чем это практически возможно в Microsoft Exchange 5.5. Решение этой задачи достигается посредством распределения пользователей по нескольким базам данных на одном сервере. Так как базы данных в данном случае становятся меньшими по размеру, создание дополнительных баз данных позволит реализовывать на каждом сервере поддержку большего числа пользователей. Например, легче работать с шестью базами данных, в каждой из которых тысяча пользователей, чем управлять одной базой данных с шестью тысячами пользователей. Данный подход не только позволяет в отдельном порядке назначать время архивирования и восстановления и выполнять эти процедуры быстрее, но и ведет к снижению числа пользователей (с 6000 до 1000), на которых отразится повреждение одной из баз данных. Кроме этого, Exchange Server 2003 может группировать несколько баз данных в одну группу хранилищ и содержать
несколько групп хранилищ на одном сервере.
Достижение третьей цели – улучшение восстанавливаемости после сбоев – было одной из главных задач группы разработки, и данная цель также достигнута посредством распределения пользователей по базам данных, что позволяет восстанавливать отдельные базы данных во время работы других баз данных. Результатом этого нововведения стало сокращение периодов отключения и повышение производительности работы пользователей, так как переключение базы данных в автономный режим теперь оказывает влияние на работу лишь определенной группы пользователей в организации, а не всех ее сотрудников.
Структура файла базы данных
Любая база данных Exchange 2003 состоит из двух файлов: файла в формате ). Аналогично, хранилище общих папок (в 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.2) Вкладка Database (База данных) окна свойств хранилища почтовых ящиков(рис 2.1) Вкладка 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".)
Наличие нескольких баз данных в нескольких группах хранилищ обеспечивает прекрасную гибкость управления пользователями и базами данных. Например, можно группировать пользователей по подразделениям или расположению и создавать их учетные записи в общей базе данных.
Помимо этого можно осуществлять контроль над соотношением пользователь/база данных, чтобы при росте компании поддерживать определенный размер баз данных и просто создавать дополнительные базы данных для новых пользователей, когда в этом возникнет необходимость.
Кроме того, базы данных являются масштабируемыми, поэтому одна база данных может содержать от одного почтового ящика (теоретически) до неограниченного числа ящиков. Тем не менее, не рекомендуется допускать такие крайности, и в действительности предельное количество почтовых ящиков в базе данных зависит от таких факторов, как емкость аппаратных устройств или количество времени, необходимое для архивации или восстановления баз данных. Архивацию баз данных можно назначать индивидуально для каждой или осуществлять несколько процедур архивации в нескольких базах данных на несколько ленточных носителей одновременно. Эта возможность позволяет сократить время, необходимое для архивации баз данных.
Восстановление данных и журналы транзакций
Три из десяти вопросов, получаемых технической поддержкой Microsoft, связаны с ESE и восстановлением данных. В данном разделе обсуждается роль журналов транзакций и рассказывается о том, как они используются при восстановлении баз данных после сбоев. Здесь также рассказывается о причинах, вызывающих сбои в работе баз данных, и приводятся некоторые распространенные сообщения об ошибках, появляющиеся при сбоях. В лекции 8 "Функциональность, безопасность и поддержка Exchange Server 2003" приводится пошаговое описание процесса восстановления базы данных.
Extensible Storage Engine
Extensible Storage Engine представляет собой систему ведения журналов транзакций, обеспечивающую целостность данных и их сохранность в случае системных сбоев или неполадок в работе носителей. Разработка ESE велась согласно четырем критериям. Первым из них являлся вопрос, что произойдет в случае сбоя. Каждая новая разработка должна была улучшить восстанавливаемость при возникновении неполадок. Вторым критерием было уменьшение числа операций ввода/вывода, производимых ESE, и для достижения этой цели было сделано все возможное. Три операции ввода/вывода выполняются быстрее, чем четыре, а четыре – быстрее, чем пять. Даже если достижение этой цели подразумевает добавление в операцию ввода/вывода дополнительных вычислений, исключение одной операции ввода/вывода значительно улучшает производительность. Третьим критерием при разработке машины базы данных было обеспечение наивысшего уровня самонастраиваемости. Наконец, предусматривалось ее функционирование
в течение времени, максимально приближенного к 24 часам в сутки и 7 дням в неделю. Достижению последней цели способствует обеспечение работы с базой данных в режиме онлайн.
Как работает ESE
Основная функция ESE заключается в управлении транзакциями. ESE выполняет проверку целостности базы с помощью четырех тестов, называемых тестами ACID.
Atomiс (Элементарность). Должны быть завершены либо все операции, выполняющиеся в транзакции, либо не будет завершена ни одна из них.
Consistent (Консистентность). Транзакция должна начинаться в базе данных в консистентном (неизмененном и работоспособном) состоянии и оставлять базу данных после своего завершения в таком же состоянии.
Isolated (Изолированность). Изменения не видны до тех пор, пока не завершатся все операции транзакции. По завершении выполнения всех операций, если база данных находится в консистентном состоянии, транзакция считается фиксированной.
Durable (Стойкость). Фиксированные транзакции сохраняются даже в том случае, если в системе возникают ощутимые проблемы, такие как полный отказ системы.
Примечание. Свойство стойкости проявляется при системных сбоях, возникающих в процессе выполнения операций. Если некоторые операции были завершены перед сбоем в системе (например, электронная почта удалена из папки Inbox [Входящие] и скопирована в папку Private [Личное], но счетчик элементов в каждой папке не обновлен), то после загрузки компьютера при своем запуске процесс Store.exe обнаружит, что база данных находится в неконсистентном состоянии, и произведет откат операций. Эта мера предосторожности обеспечивает невозможность утери сообщения при перемещении, а также отсутствие дубля сообщения после перезагрузки. ESE обеспечивает тот факт, что база данных после перезагрузки компьютера находится в том же самом состоянии, в котором она находилась непосредственно перед началом выполнения операций.
Пример из практики.Что происходит при внесении изменения в страницу базы данных
Предположим, что важное сообщение электронной почты перемещается из папки Inbox (Входящие) в частную папку с именем Private (Личное). Для осуществления этой транзакции должны быть выполнены следующие операции:
добавление сообщения электронной почты в папку Private (Личное);
удаление сообщения электронной почты из папки Inbox (Входящие);
обновление информации о каждой папке для корректного отображения числа элементов в папках;
фиксирование транзакции во временном файле журнала транзакции.
Так как эти операции выполняются в одной и той же транзакции, Exchange либо выполняет их все, либо не выполняет ни одной. Это и есть тест Atomic (Элементарность). Операция фиксирования не может осуществляться до тех пор, пока не будут успешно выполнены все операции. После фиксирования транзакции тест Isolated (Изолированность) считается пройденным. База данных остается в консистентном состоянии, поэтому тест Consistent (Консистентность) также считается пройденным. Таким образом, после фиксирования транзакции в базе данных изменения будут сохранены даже в случае возникновения сбоя. Это обстоятельство отвечает требованиям теста Durable (Стойкость).
Каким образом осуществляется хранение данных. В файле базы данных ESE данные распределены по 4-килобайтным секциям, называемым страницами. Информация считывается из базы данных ESE и загружается в память в виде страницы. Каждая страница содержит определения данных, сами данные, индексы, проверочные суммы, флаги, временные штампы и другую информацию B-дерева. Страницам в базе данных присваиваются последовательные номера для улучшения производительности. Страницы содержат либо непосредственные данные, либо указатели на другие страницы, содержащие данные. Эти указатели формируют структуру B-дерева, и редко встречается дерево, содержащее больше трех или четырех уровней. Следовательно, структура B-дерева широка, но неглубока.
. Для ознакомления с краткими сведениями о структуре B-дерева посетите страницу http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci508442,00.html. И, как известно, с помощью системы Google можно получить дополнительные источники информации, введя строку поиска "B-tree".
Транзакция – это последовательность изменений, вносимых в страницу базы данных. Каждое изменение называется операцией. После выполнения полного набора операций над объектом базы данных транзакция считается завершенной.
Примечание. База данных ESE содержит до 232 (4 292 967 296) страниц. Принимая в расчет 4 Кб на каждую страницу, база данных ESE занимает объем 16 терабайт (4 292 967 296 х 4096 = 17 583 994 044 416 байт) данных. На практике размер базы данных ограничен пространством, обеспечиваемым аппаратными устройствами, методами архивации и восстановления, а не структурой ESE.
Когда страница впервые считывается с диска и сохраняется в памяти, она называется "чистой". Как только страница подвергается изменению посредством выполнения над ней какой-либо операции, она становится "измененной". Измененные страницы доступны для дальнейшей модификации, и такая страница может претерпеть несколько изменений перед записью на диск. Число изменений, вносимых в страницу, не связано с тем, когда страница будет записана на диск. Это действие определяется другими количественными мерами, о которых речь пойдет далее в лекции.
Операции в процессе своего выполнения записываются в хранилище версий. Хранилище версий содержит перечень всех изменений, внесенных в страницу, но еще не зафиксированных. Если питание сервера прервется перед фиксированием последовательности операций, то в процессе отката (отмены) ESE незавершенных операций будет произведено обращение к хранилищу версий. Хранилище версий является виртуальным хранилищем, поэтому на жестком диске нет базы данных с именем Version Store. Хранилище версий располагается в оперативной памяти и действительно содержит версии одной и той же страницы, считанной с диска в память. На рисунке 2.5 приведена наглядная демонстрация этого процесса.
Для непосредственного фиксирования транзакции операции должны записываться в буфер журнала транзакций перед записью в журналы транзакций на диске. ESE использует "упреждающую" регистрацию данных в журнале, т.е. перед внесением изменения в базу данных ESE записывает в файле журнала, какие действия она будет выполнять. Данные записываются в кэшированную версию журнала в области буфера журнала, в страницу в памяти вносятся изменения, и между этими двумя записями устанавливается связь. Перед тем как изменения страницы будут записаны на диск, изменение, записанное в буфере журнала, сначала должно быть записано в файл журнала на диске.
Совет. Одна операция может требовать столько времени для выполнения или быть такой обширной, что в хранилище версий понадобится записать несколько сотен мегабайт данных. Такое может случиться, если операция заключается в индексировании большой таблицы или записи очень большого файла в базу данных. Так как хранилище версий отслеживает все изменения, внесенные в базу данных с момента начала самой старой транзакции, может возникнуть ошибка "-1069 error(JET_errVersionStoreOutOfMemory)". Если это произошло, попробуйте переместить базы данных и хранилища на другой диск с большим объемом свободного пространства, а также рассмотрите вопрос об увеличении объема оперативной памяти компьютера.
(рис 2.5) Метод обработки транзакций ESEЗачастую кэшированные версии изменений страниц не записываются на диск сразу. Это не является проблемой, так как информация записывается в файлы журналов. Если изменения в памяти будут утеряны, при запуске ESE файлы журнала будут считаны вновь (этот процесс обсуждается более подробно далее в лекции), и транзакции будут записаны на диск. Более того, отсутствие немедленной записи кэшированной информации в базу данных увеличивает производительность. Представьте себе ситуацию, в которой страница загружается из памяти и затем подвергается изменению. Если в скором времени после этого ее вновь потребуется изменить, ее не нужно повторно считывать с диска, так как она уже находится в памяти. Таким образом, изменения базы данных могут быть "пакетными", что увеличит производительность.
Файлы базы данных. База данных представляет собой комбинацию файлов .EDB и .STM, хранимых на жестком диске. По существу, все транзакции записываются в один из этих файлов. Тем не менее, перед записью на диск для страницы вычисляется проверочная сумма, после чего эта сумма записывается в страницу вместе с остальными данными. При считывании страницы с диска проверочная сумма вычисляется повторно, и номер страницы проверяется для обеспечения его соответствия номеру запрошенной страницы. Если вычислить проверочную сумму не удается, или если в номере страницы присутствует несоответствие, генерируется сообщение об ошибке "-1018". Эта ошибка означает, что данные, записанные на диск, не являются данными, считанными ESE с диска в оперативную память.
Примечание. Начиная с пакета обновления Service Pack 2 (SP2) в Exchange Server 5.5 и по сей день, в Exchange Server 2003 ESE осуществляет 16 попыток чтения данных перед генерированием ошибки -1018, что уменьшает вероятность возникновения неполадки вследствие какого-либо кратковременного события. Следовательно, возникновение ошибки -1018 означает, что ESE, прежде чем отобразить уведомление об ошибке, многократно повторила попытку чтения данных.
ESE и управление памятью. Перед загрузкой страницы в память ESE должна зарезервировать в памяти область для использования ее в своих целях. Динамическое отведение буфера (DBA) является процессом увеличения размера кэша буфера базы данных перед тем, как возникает надобность в использовании памяти. Достаточно большое число администраторов Exchange пришли к выводу, что Exchange занимает на серверах всю память. Эта ситуация является умышленной, и хотя она не обязательно должна приводить к использованию всей памяти, память, отводимая для Exchange, не является недоступной для других системных процессов. Если процессам требуется дополнительная память, Exchange освободит память для их эффективной работы. Это происходит непосредственно во время работы, и методы, используемые ESE, не являются настраиваемыми.
В Exchange 4 и 5.0 размер кэша устанавливался компонентом Performance Optimizer (Оптимизатор производительности). В Exchange 5.5 этот процесс стал динамическим: ESE исследует систему и настраивает размер кэша базы данных по мере необходимости. Для выяснения объема памяти, резервируемого процессом Store, следует использовать счетчик производительности Cache Size (Размер кэш-памяти).
Теперь самое время выделить общие цели, для достижения которых предназначен процесс DBA. Их знание и понимание поможет легко ответить на любые вопросы относительно управления памятью в Exchange Server 2003. Целями создания DBA являются:
достижение максимального уровня производительности системы. Процесс Store использует общее значение активности страничной организации памяти и ввода/вывода, а также другие факторы для определения количества оперативной памяти, отводимой для буфера базы данных. Данная цель в действительности сфокусирована на общей производительности системы. Ускорение работы Exchange бесполезно, если операционная система постоянно выполняет работу со страницами памяти;
максимизация использования памяти. Неиспользуемая системная память – это потерянные деньги. ESE отводит для себя столько памяти, сколько это возможно, без негативного влияния на другие приложения. Если запускается другое приложение, требующее дополнительного объема памяти, ESE освобождает память для обеспечения эффективной работы этого приложения.
Не стоит беспокоиться, если вы увидите, что в Task Manager (Диспетчер задач) от 1 Гб оперативной памяти системы осталось только 200 Мб, и процесс Store использует все 800 Мб. Недостатка в памяти нет, и процесс Store.exe не содержит утечку памяти. Это лишь означает, что функция DBA машины ESE отвела дополнительный объем оперативной памяти для увеличения производительности системы. На рисунках 2.6 и 2.7 показано, как это выглядит в программе Task Manager (Диспетчер задач). На рисунке 2.6 видно, что процессы Store.exe и Mad.exe используют больший объем памяти, чем большинство других процессов. Это изображение сохранено с экрана сервера, который не был загружен работой, а процесс Store.exe по-прежнему находился на первом месте в списке по уровню использования памяти. На рисунке 2.7 видно, что доступный объем системной памяти
равен лишь 49 176 Кб. Обратите внимание на область Physical Memory (K) (Физическая память, Кб), а именно на значение Available (Доступно).
(рис 2.7) Вкладка Processes (Процессы) в Диспетчере задач Windows, отображающая объем памяти, отведенный для процессов Store.exe и Mad.exe(рис 2.6) Вкладка Performance (Производительность) в Диспетчере задач Windows, отображающая уровень использования памяти и ее свободный объемФайлы журналов транзакций. Теоретически файл журнала транзакции может постоянно увеличиваться. Однако если его размер увеличится до такой степени, что займет очень много пространства на диске, то это сделает работу с ним крайне затруднительной. По этой причине журнал разбивается на поколения, т.е. на несколько файлов, каждый из которых имеет размер 5 Мб и представляет собой определенное поколение. Поколению файла журнала присваивается имя EdbXXXXX.log, где XXXXX представляет собой последовательно увеличивающееся шестнадцатеричное число.
Файл Edb.log представляет собой самое первое поколение. Когда он заполняется, ему присваивается имя со следующим шестнадцатеричным номером. При этом создается временный файл журнала Edbtemp.log для регистрации транзакций, пока не будет создан новый файл Edb.log.
Каждый файл журнала состоит из двух частей – заголовка и данных. Заголовок содержит жестко запрограммированные пути к соответствующим базам данных. В Exchange Server 2003 несколько баз данных могут использовать один и тот же файл журнала, так как файлы журналов обслуживают всю группу хранилищ. С точки зрения администрирования данный подход упрощает процесс восстановления. Независимо от того, какая база данных в группе хранилищ подвергается восстановлению, будет происходить обращение к одним и тем же файлам журналам рассматриваемой группы. Заголовок также содержит подпись, сверенную с подписью базы данных. Это предотвращает сопоставление файла журнала другой базе данных с идентичным именем.
Можно осуществлять разгрузку информации заголовка файла журнала с помощью команды ESEUTIL /ML (см. рис 2.8). В процессе разгрузки отображается номер поколения, пути базы данных и подписи. Часть файла журнала с данными содержит данные о транзакциях, например BeginTransaction (Начало транзакции), Commit (Фиксирование) и Rollback (Откат). Большая часть файла содержит низкоуровневые физические изменения базы данных. Иными словами, эти записи можно интерпретировать следующим образом: "Данная информация была добавлена в эту страницу в такое-то место".
(рис 2.8) Разгрузка заголовка с помощью команды ESEUTIL /MLИзменение базы данных состоит из нескольких этапов. Во-первых, страница считывается в кэш базы данных, после чего обновляется временной штамп этой страницы. Временной штамп инкрементируется для каждой базы данных по отдельности. После этого создается запись журнала с констатацией того, какие действия будут произведены в базе данных. Это происходит в буфере кэш-памяти журнала. Затем страница подвергается изменению, и между этими двумя записями устанавливается связь, не позволяющая записать страницу на диск без предварительного переноса на диск записи файла журнала. Данный этап гарантирует запись изменения базы данных в файл журнала перед обновлением базы данных на диске.
Таким образом, существует разумная концепция кэширования обратной записи, реализуемая на диске с файлом журнала. По существу, кэширование обратной записи подразумевает под собой процесс, в ходе которого оборудование передает обратно в ESE отчеты об успешной записи на диск, даже если информация находится в буфере диска контроллера, и ее непосредственная запись на диск отложена на более позднее время. Кэширование обратной связи, несмотря на улучшение производительности, может прерывать процесс ESE записи изменений в файл журнала перед их занесением в базу данных. При неполадках в работе контроллера или диска может возникнуть ситуация, когда страница будет записана на диск, но не зарегистрирована в файле журнала, что приведет к повреждению базы данных.
Повторное считывание файлов журнала при восстановлении. После восстановления базы данных журналы повторно считываются при запуске процесса Store.exe. Повторное считывание журналов и последующий откат операций являются составными частями "запуска" процесса Store; эта процедура часто называется процессом восстановления. Повторное считывание журналов транзакций представляет собой первую часть процесса восстановления и занимает большую часть времени, необходимого для запуска процесса Store.exe.
Повторное считывание файлов журналов транзакций заключается в том, что для каждой записи журнала считывается страница, соответствующая записи, и временной штамп на этой странице сравнивается с временным штампом записи журнала, ссылающейся на эту страницу. Если временным штампом записи журнала является 12, а страницы, считываемой из базы данных – 11, ESE определяет, что изменение, зафиксированное в файле журнала, не было записано на диск, и запись журнала заносится в базу данных. Однако если значение временного штампа страницы на диске больше или равно временному штампу записи журнала, ESE не записывает эту запись журнала на диск и переходит к следующей записи в журнале.
Во второй, завершающей, фазе процесса восстановления происходит откат всех незафиксированных операций: если передана часть сообщения электронной почты, то его передача отменяется, если сообщение удалено, оно восстанавливается. Этот процесс называется физическим повторением и логической отменой. Восстановление происходит при каждом запуске процесса Store.exe. Если остановить и запустить процесс Store пять раз, то процесс восстановления также будет выполнен пять раз.
Несмотря на то что процесс восстановления выполняет действия с файлами журналов и не затрагивает базы данных, в случае перемещения баз данных восстановление не будет функционировать, так как закодированный в заголовке файла журнала путь к базе данных уже не будет указывать на базу данных. По окончании восстановления выполнение процесса будет казаться успешным, однако при попытке использования соответствующей базы данных сгенерируется сообщение об ошибке с идентификатором события 9519 из журнала приложения MSExchangeIS, предупреждающее об ошибке запуска базы данных (см. рис 2.9).
(рис 2.9) Сообщение об ошибке, возникшей при запуске базы данныхЕсли возвратить базу данных в место расположение, указанное в заголовке файла журнала, а затем запустить процесс Store, процесс восстановления вернет базу данных в консистентное рабочее состояние.
Файл контрольной точки. Файл контрольной точки оптимизирует процесс восстановления. Он фиксирует информацию о том, какие записи в файлах журналов уже записывались на диск. Если все записи файлов журналов записаны на диск, то в процессе восстановления не потребуется их повторного считывания. Файл контрольной точки может сократить время восстановления, сообщая ESE о том, какие записи файла журнала нужно считать повторно, и какие не требуют повторного считывания.
Иногда ускорить процесс восстановления баз данных помогает использование циклического ведения журналов. При этом происходит удаление файлов журналов, более старых, нежели текущее местонахождение контрольной точки. Недостаток циклического ведения журналов заключается в том, что теряется возможность восстановления работоспособности системы с повтором всех завершенных транзакций, записанных на архивный накопитель. Если некоторые файлы журналов удалены в рамках циклического ведения журналов после проведения последней полной архивации, можно произвести восстановление только с использованием последнего полного архива. Однако при наличии всех старых файлов журналов восстановление с помощью последнего полного архива базы данных с резервного накопителя позволит произвести полное восстановление вплоть до момента сбоя, так как все файлы журналов смогут быть повторно считаны и записаны в восстановленную базу данных. Следует помнить, что
для осуществления полного восстановления база данных должна находиться в том же физическом состоянии, в котором она находилась в момент записи файлов журналов. Физически поврежденную базу данных восстановить нельзя.
Внимание! Никогда, никогда, никогда не удаляйте файлы журналов! Предположим, файл журнала 9 содержит команду добавления новой страницы в определенное место базы данных. Файл журнала 10 содержит команду удаления этой страницы. Теперь предположим, что администратор удаляет файл журнала 9, возможно, по причине того, что этот файл слишком устарел, и удаляет файл контрольной точки. После этого администратор решает перезагрузить систему по каким-либо иным причинам. При запуске процесса Store.exe ESE автоматически переходит в режим восстановления. Не обнаружив файла контрольной точки, ESE не сможет сделать ничего, кроме повторного считывания всех файлов журналов. При повторном считывании файла журнала 10 команда удаления будет выполнена на соответствующей странице, и ее содержимое будет уничтожено. ESE не известно о том, что имела место более ранняя команда добавления новой страницы в это расположение базы данных,
так как файл журнала 9 удален. Таким образом, база данных станет поврежденной. Ни при каких обстоятельствах не удаляйте файлы журналов! Более того, имейте в виду, что кэширование обратной записи может вызвать удаление файлов журналов. Рекомендуется отключить кэширование обратной записи и никогда не удалять файлы журналов и файл контрольной точки.
Занесение в базу данных записей журнала. Как уже упоминалось ранее, измененные страницы в памяти и фиксированные транзакции в области буфера журнала не записываются на диск немедленно. Фиксированные транзакции в файле журнала транзакций копируются в базу данных при возникновении одного из следующих условий:
контрольная точка находится слишком далеко в прежнем файле журнала. Если число фиксированных транзакций в файлах журналов достигает определенного порогового значения, ESE сбрасывает эти изменения на диск;
число свободных страниц в памяти стало слишком мало, что, возможно, сказывается на производительности системы. В этом случае фиксированные транзакции в памяти сбрасываются на диск, чтобы освободить страницы в памяти для использования системой;
другая служба запрашивает дополнительный объем памяти, и ESE требуется освободить некоторое количество памяти, занимаемой ESE в данный момент. ESE сбрасывает страницы из памяти в базу данных, после чего обновляет файл контрольной точки;
служба базы данных отключается. В этом случае все обновленные страницы в памяти копируются в файл базы данных.
Имейте в виду, что страницы не копируются из памяти в каком-либо определенном порядке и могут не копироваться все сразу. Случайный порядок копирования страниц на диск означает, что при сбое в системе во время записи страниц на диск файл базы данных может содержать лишь части фиксированной транзакции, обновленные непосредственно в файле. В этом случае при запуске процесса Store транзакция будет повторно считана из файлов журнала транзакций, и обновление базы данных будет произведено полностью.
Монтируемая файловая система
В Exchange 2000 Server ExIFS была смонтирована по умолчанию и являлась рекомендуемым методом управления данными пользователей. Как известно, файловая система Installable File System (Монтируемая файловая система) позволяла пользователям размещать документы любого типа в файле с содержимым в собственном формате (потоковом файле), после чего осуществлять к ним доступ почти из любого клиента, независимо от того, является ли он браузером, клиентом MAPI или приложением Microsoft Internet Explorer.
Однако Microsoft отказалась от использования IFS для управления данными и файлами. В Exchange Server 2003 файловая система IFS не смонтирована по умолчанию. Если нужно смонтировать IFS для представления баз данных в качестве виртуальной файловой системы, необходимо включить устройство M: с помощью следующего параметра реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS\parameters
Параметр: DriveLetter
Тип: String
Значение: M
Следует использовать устройство M: только для получения доступа к данным файла в формате, отличном от MAPI. Не следует открывать доступ к фрагментам устройства M: для доступа пользователей блока серверных сообщений (SMB). Рекомендуется использовать клиент Web Folder для доступа к данным в хранилищах при работе с приложениями типа Microsoft Word вместо использования устройства M: и доступа SMB.
или http://wwwacs.gantep.edu.tr/foldoc/foldoc.cgi?Server+Message+Block. По существу, блоки серверных сообщений представляют собой команды, передаваемые клиентом серверу для запроса файловых операций, таких как копирование, создание каталога и удаление. Будучи во многом похожими на протокол передачи почты SMTP (Simple Mail Transport Protocol), использующий архитектуру "запрос-ответ", команды SMB представляют собой последовательности запросов, исходящих от клиентов, и ответов, получаемых от сервера. Число и тип команд, используемых между клиентом и сервером, определяются в процессе прямого согласования при выполнении трехстороннего рукопожатия TCP, когда между клиентом и сервером устанавливается сеанс связи.
Чтобы лучше разобраться в процессе трехстороннего рукопожатия TCP, обратитесь к книге "Протоколы и службы TCP/IP в Microsoft Windows Server 2003. Справочник администратора" (издательство "Эком").
Клиент Web Folder
Как уже говорилось ранее, доступ к информации, находящейся в файле с содержимым в собственном формате, можно осуществлять через интернет с использованием протокола HTTP. Это осуществляется посредством присвоения каждому объекту в файле уникального URL, позволяющего осуществлять доступ к объекту из браузера, посредством чего стороннее приложение может напрямую запрашивать в хранилище Exchange получение данных как из почтовых ящиков, так и из общих папок.
WebDAV (Web Development Authoring and Versioning) представляет собой расширение протокола HTTP и является стандартизированным протоколом, построенным на основе HTTP 1.1. Он поддерживает более сложную структуру команд, в которую входят новые команды COPY и MOVE, управляющие отдельными объектами на веб-сервере. Кроме этого, данный протокол позволяет осуществлять доступ чтения/записи к информационному хранилищу через HTTP с использованием браузера в качестве клиента. Он поддерживает реляционные базы данных, слабоструктурированные базы данных (такие как базы данных Exchange) и стандартные файловые системы. Более того, клиенты WebDAV могут быть синхронизированы с хранилищами серверной части через интернет посредством репликации, что позволяет эффективно осуществлять онлайн-доступ и работать с данными в автономном режиме. Эта возможность позволяет, например, публиковать ежечасное обновление текущих данных об инвентаризации для
общенационального информирования продавцов. Каждый продавец сможет ознакомиться с этими данными через интернет, ввести заказы и комментарии и обеспечивать наличие финансовой информации на сайте-клиенте, пока будет возможен доступ в интернет.
WebDAV работает с содержимым любого типа, поэтому пользователи могут использовать WebDAV для коллективной работы над текстовым документом, электронной таблицей или изображением. Практически все содержимое файла можно изменить при помощи WebDAV. WebDAV делает интернет, с точки зрения клиента, записываемым носителем информации. Microsoft Internet Explorer 5 и Microsoft Office 2000 (и новее) совместимы с WebDAV. Ниже приведены некоторые возможности WebDAV.
Защита от записи (блокировка файла). Пользователи могут записывать, редактировать и сохранять общие документы без перезаписи результатов работы другого пользователя, независимо от того, какую программу или службу интернета он использует. Это ключевая возможность, обеспечивающая совместную работу.
Управление пространством имен. У пользователей есть возможность удобно управлять файлами и каталогами интернета, включая операции перемещения и копирования файлов. Этот процесс аналогичен тому, как осуществляется управление файлами в Explorer.
Доступ к свойствам (метаданным). Пользователи могут производить индексацию и поиск метаданных о документе, таких как имя автора, авторские права, дата публикации или ключевые слова, с целью нахождения и получения соответствующих документов. (Для получения более подробной информации обратитесь к параграфу "Индексация" далее в лекции.)
Веб-папки позволяют клиентам осуществлять доступ к веб-серверу аналогично тому, как осуществляется работа с файловым сервером. Exchange Server 2003 позволяет клиенту осуществлять доступ к каталогам и элементам в информационном хранилище как к файловому серверу и осуществлять управление данными в веб-папке так, как если бы это был файловый сервер. Общие папки в Exchange Server 2003 также представляются в виде веб-папок. Клиент Web Folder входит в комплект поставки операционных систем Microsoft Windows 2000 Professional и Microsoft Windows XP. Чтобы создать веб-папку ресурса в хранилище Exchange, воспользуйтесь мастером добавления в сетевое окружение (Add Network Place Wizard) в папке My Network Places (Мое сетевое окружение) и введите что-либо из следующего:
расположение каталога на сервере с помощью адреса UNC (Universal Naming Convention), например, \\имя_сервера\имя_каталога ;
адрес URL, такой как http://www.microsoft.com;
сайт FTP с использованием следующего синтаксиса: ftp://ftp.microsoft.com.
После создания веб-папки клиент Web Folder можно использовать для доступа к информации из приложения, программы Windows Explorer (Проводник Windows) или из других утилит клиентской части.
Переход от IFS к клиенту Web Folder является большим шагом вперед, который избавляет от необходимости использовать SMB для работы с интернет-технологиями при управлении и оперировании информацией, в частности, файлами данных. Более того, если у читателя появится возможность ознакомиться со службой Windows SharePoint Services от Microsoft, он обнаружит, что управление файлами теперь базируется на архитектуре базы данных, а не на архитектуре файлового сервера. Этот шаг является частью общей стратегии отказа от использования того, что мы привыкли называть технологиями, основывающимися на локальной сети, и перехода к работе с технологиями, базирующимися на веб-службах. Такой переход действительно осуществляется в настоящее время, и новые принципы работы представлены почти в каждой новой платформе, выпускаемой Microsoft.
Что произойдет, если при использовании Exchange 2000 Server очень большое количество документов будет "сброшено" в общие папки, доступ к которым пользователи осуществляют через IFS? В Exchange Server 2003 можно оставить эти документы в общих папках и, если это действительно нужно, смонтировать IFS и использовать SMB для получения документов. Однако следует иметь в виду, что наступит такой момент, когда все данные будут находиться в базе данных, аналогичной SQL. Система Web Storage System, как известно, уступит место следующей большой базе данных, которая будет построена на базе SQL. Может оказаться полезным произвести в данный момент планирование этого предстоящего изменения.
Общие папки
В Exchange Server 2003 управление общими папками осуществляется аналогично тому, как это реализовано в Exchange 2000 Server. Данный подход включает в себя следующие особенности.
Администрирование общих папок осуществляется через оснастку MMC Exchange Folders (Папки Exchange).
Деревья общих папок гораздо более масштабируемы и гибки. Теперь можно создавать деревья папок по географическому местоположению, подразделениям организации или выполняемым функциям. В следующем параграфе приводится более подробное обсуждение этой возможности.
Общие папки интегрированы с Active Directory, поэтому записи электронной почты позволяют отправлять сообщения в общие папки вместо их непосредственной публикации в общей папке.
Общие папки в целях безопасности работают с пользователями и группами из службы каталогов Active Directory.
Доступ к общей папке через интернет теперь является более прямым и простым. В Exchange 2003 можно открыть содержимое общей папки с помощью обычного адреса URL.
В общих папках предусмотрена полнотекстовая индексация. Клиенты Outlook автоматически используют этот новый индекс при выполнении поиска или расширенного поиска.
По умолчанию включены направления. Направления общей папки позволяют клиентам получать доступ к любой папке в организации, так как теперь направления между группами маршрутизации включены по умолчанию.
Общие папки можно создавать при помощи оснастки Exchange Folders (Папки Exchange). Больше нет необходимости в использовании Outlook для создания общей папки, хотя данная возможность по-прежнему предусмотрена.
Множество деревьев общих папок
В Exchange Server 2003 можно с различными целями создавать большое число деревьев общих папок. Предположим, что группа сотрудников, работающих над одним проектом, состоит из трех внутренних клиентов сети, двух пользователей компании, находящихся в удаленных расположениях, и трех консультантов, не входящих в штат организации. Можно создать для этих пользователей дерево общих папок, отдельно от дерева общих папок по умолчанию (см. рис 2.10).
(рис 2.10) Множество деревьев общих папокКаждое дерево общих папок содержит данные в одном хранилище общих папок на каждом сервере. Можно осуществить репликацию определенных папок в дереве на каждый сервер организации, на котором имеется хранилище общих папок, ассоциированное с этим деревом общих папок. Стандартное дерево общих папок доступно через протоколы MAPI, IMAP4, Network News Transfer Protocol (NNTP) и HTTP. Дополнительные деревья общих папок доступны только клиентам HTTP и NNTP.
Доступ клиентов к хранилищам Exchange 2003
Клиент Exchange 2003 может осуществлять доступ к хранилищу Exchange несколькими способами. Доступ к информационному хранилищу выполняется через POP3, NNTP, IMAP4, HTTP, SMTP, посредством объявления свойств, с помощью обычных адресов URL и WebDAV.
Хранилище данных, в частности, поддерживает работу с MAPI, что обеспечивает возможность отправки и получения пользователями электронной почты. Хранилище также предоставляет URL каждого находящегося в нем элемента. Каждый раз при создании в хранилище сообщения или файла Exchange создает для этого объекта уникальный URL. Например, доступ к папке Inbox (Входящие) пользователя можно осуществить посредством следующего URL: File://./BackOfficeStorage/имя_сервера.имя_домена.com/mbx/имя_пользователя/inbox/имя_документа.
Индексирование
Процесс информационного хранилища создает и использует в работе индексы полей общего ключа для ускорения просмотра и поиска документов, находящихся в хранилище. Индекс позволяет пользователям Outlook упростить поиск элементов. При использовании полнотекстового индексирования индекс создается перед операцией поиска, производимой клиентом, что обеспечивает ускорение процедур поиска. В полнотекстовое индексирование могут быть включены текстовые вложения. Каждое хранилище информации можно проиндексировать в индивидуальном порядке для повышения гибкости.
Объявление свойств позволяет производить расширенный поиск по любым свойствам документов, таким как автор, число строк или тема документа (см. рис 2.11). При сохранении хранилищем Exchange документа в файле поддерживаемого типа свойства документа автоматически считываются и объявляются в информационном документе. Следовательно, свойства становятся частью записи документа в базе данных. Это позволяет осуществлять поиск документов по их свойствам.
Индекс состоит из слов, а не из символов. Это означает, что если пользователь осуществляет поиск по слову "admin", то в результатах поиска будут приведены только документы, содержащие слово "admin". Слово "administrator" не будет соответствовать данному критерию поиска. Можно индексировать как сообщения, так и вложения. Двоичные вложения и свойства документа не индексируются. Не все типы файлов можно проиндексировать; по умолчанию индексируются только следующие типы документов:
документы Word ( *.doc );
документы Excel ( *.xls );
документы PowerPoint ( *.ppt );
документы HTML ( *.html, *.htm, *.asp );
текстовые файлы ( *.txt );
встроенные сообщения MIME ( *.eml )
(рис 2.11) Расширенный поиск документа по его свойствам, объявленным в информационном хранилищеИндексация осуществляется службой Microsoft Search. Для создания, обновления и удаления индекса должны быть запущены служба информационного хранилища и служба поиска. В зависимости от размера хранилища выполнение полного индексирования может занять несколько часов. Следовательно, лучше проводить эту процедуру в то время, когда использование сервера сведено к минимуму. Помните, что процедура индексирования занимает около 20 процентов дискового пространства базы данных. Кроме того, нельзя осуществлять архивацию отдельных индексов; их архивация выполняется на уровне сервера. Наконец, несмотря на то что в базе данных может находиться несколько вхождений сообщения, каждое сообщение индексируется только один раз. Однократное индексирование сообщений обеспечивает меньший размер индексов, что укоряет создание последних.
Процесс индексирования
Microsoft Search создает начальный индекс посредством покатологовой обработки всего хранилища. Процесс Search определяет и регистрирует текст, по которому может осуществляться поиск. В это время наблюдается высокий уровень использования процессора; в зависимости от размера хранилища данный процесс длится несколько часов.
После создания индекса любое изменение, вносимое в папку в хранилище, вызывает событие синхронизации для уведомления службы Microsoft Search о внесенном изменении. В зависимости от настройки службы Search, она будет либо ожидать назначенного времени для генерирования индекса, чтобы индексировать внесенное изменение, либо обновит индекс через небольшой интервал времени после внесения изменения.
Обновление индекса
Интервал времени перед немедленным (автоматическим) обновлением индекса зависит от текущего уровня загрузки сервера. Этот параметр настраивается на вкладке Full-Text Indexing (Полнотекстовое индексирование) окна свойств информационного хранилища (см. рис 2.12).
Назначенные обновления позволяют осуществлять тщательный контроль за тем, когда происходит обновление индекса. Преимущество назначения обновления индекса заключается в том, что оно может быть запланировано на время, когда нагрузка на сервер незначительна из-за относительно небольшого числа пользователей, осуществляющих к нему доступ. Недостатком такого подхода является то, что индекс может стать "просроченным" в рамках одного дня. Тем не менее, это не является большим минусом, так как большинство пользователей осуществляют поиск документов, полученных и индексированных ранее, чем в течение последних 24 часов перед операцией поиска. Следует попытаться настроить выполнение обновления, по крайней мере, один раз в течение каждого дня.
Архитектура поиска
Если требуется реализовать возможность полнотекстового поиска во всей организации, следует рассмотреть вариант с установкой клиентов обмена сообщениями. Только онлайн-клиенты MAPI и IMAP4 имеют возможность осуществлять полнотекстовый поиск на сервере. Клиенты POP3 и WebDAV не предоставляют такой возможности.
Exchange Server 2003 выполняет операции поиска двух типов. Первым из них является полнотекстовый запрос индекса, созданного службой Microsoft Search, вторым – запрос, основанных на свойствах документов, не доступных в полнотекстовом индексе.
(рис 2.12) Вкладка Full-Text Indexing (Полнотекстовое индексирование) окна свойств хранилища общих папокКогда пользователь осуществляет поиск в клиенте Outlook посредством выбора команды ).
(рис 2.13) Диалоговое окно Advanced Find (Расширенный поиск) в Outlook 2003После указания пользователем нужных значений запрос отправляется обработчику запросов Query Processor, определяющему способ выполнения поиска. Если поиск основан как на строке символов, так и на переменной определенного свойства, Query Processor разделяет запрос на две части. Предположим, что запрос охватывает все документы, размер которых превышает 5 Мб, и что в поле темы присутствуют слова "building plan". Query Processor разделяет этот запрос и дает службе Microsoft Search указание сгенерировать список документов, содержащих в поле темы слова "building plan". Затем вычисляется размер каждого документа, возвращенного службой Search, для выявления документов, чей размер превышает 5 Мб, и генерируется новый перечень документов, соответствующих обоим критериям.
Наконец, Exchange Server 2003 налагает ограничения на остальные документы, чтобы клиент не получил документы, на просмотр которых у него нет полномочий. После принятия мер безопасности результаты, соответствующие критериям поиска, возвращаются клиенту.
Файлы сбора данных
Файлы сбора данных создаются при каждой процедуре индексирования. Они по умолчанию располагаются в каталоге ExchangeServer_<имя_сервера>\Gatherlogs и оканчиваются расширением .GTHR. Эти текстовые файлы можно использовать для выявления каждого документа и сообщения, которое не было успешно индексировано. Например, если документу присвоено имя с расширением, соответствующим поддерживаемому типу файлов, однако рассматриваемый файл в действительности представляет собой иной тип файлов, компонент индексирования "зависает", операция индексирования не выполняется, в файл сбора данных записывается URL документа (см. рис 2.14), после чего осуществляется переход к следующему сообщению или документу.
(рис 2.14) URL в файле сбора данныхВ дополнение к URL в файл сбора данных может быть записана тема или имя файла. Для расшифровки номера ошибки следует использовать утилиту Gthrlog.vbs в каталоге \Program Files\Common Files\System\MsSearch\Bin. Синтаксис команды, запускающей эту утилиту, таков:
Gthrlog <имя_файла>
где ).
(рис 2.15) Диалоговое окно со строкой из файла сбора данных
Перемещение индекса по достижении им слишком большого размера
Если каталоги стали настолько большими, что не хватает свободного места на диске, можно переместить индекс на другой сервер. Для этого необходимо остановить службу Search и использовать утилиту Catutil.exe, расположенную в папке Program Files\Common Files\System\MSSearch\Bin. Для получения справки относительно работы с данной утилитой введите в командной строке команду Catutil Movecat /?.
Серверы front-end/back-end
Между архитектурой хранилищ Exchange и протоколами доступа интернета есть слой Exchange Interprocess Communication Layer (EXIPC) (Межпроцессный коммуникационный слой Exchange), или слой epoxy, представляющий собой эффективную асинхронную открытую область в памяти, которая используется процессом Store.exe и протоколами IIS для чтения и записи. Этот слой очередей позволяет очень быстро осуществлять обмен информацией между протоколами IIS, выполняющимися в процессе Inetinfo.exe, и процессом Store.exe. Слой epoxy использует общую память для установления связи между этими процессами и является оптимальным для коммуникации малых пакетов.
Для отслеживания присоединения, подключения и использования очередей слоя epoxy Exchange Server 2003 использует программу Central Queue Manager (Центральный диспетчер очередей). Этот диспетчер отвечает, кроме того, за отсоединение и очистку очереди в случае возникновения фатальной ошибки в другом процессе. Так как транспортные протоколы и хранилище информации разделены, мы можем применить архитектуру front-end/back-end, которая сделает возможным выполнение других протоколов интернета на иных серверах, нежели те, на которых функционируют хранилище и базы данных. Главным преимуществом этого подхода является возможность расширить Exchange на любую нужную установленную базу. Для обеспечения выполнения Exchange Server 2003 роли front-end-сервера нужно просто отметить опцию на вкладке General (Общие) окна свойств сервера Exchange в оснастке Exchange System (см. рис 2.16).
(рис 2.16) Включение на сервере функции front-end-сервераЕсли функция не включена, библиотеки DLL протоколов, такие как Pop3be.dll, Imap4be.dll и Httpbe.dll, загружаются в память. Если на сервере включена функция front-end-сервера, эти протоколы выгружаются, и в память загружаются специальные front-end-библиотеки DLL, такие как Pop3fe.dll, Imap4fe.dll и Httpfe.dll. Для обеспечения равномерного распределения нагрузки между запросами клиентов на front-end-серверах необходимо использовать круговую схему DNS (в которой несколько IP-адресов присваиваются одному имени узла), программу распределения сетевой нагрузки Network Load Balancing (NLB) или иное стороннее программное обеспечение.
Заключение
В лекции рассказывалось об архитектуре хранилищ, используемой в Exchange Server 2003. Говорилось о том, что процесс Store.exe может осуществлять управление множеством баз данных на одном сервере, и что базы данных поделены на хранилища, каждое из которых содержит до пяти баз данных. Были оговорены некоторые моменты, связанные с новой архитектурой общих папок, WebDAV, индексированием, файловой системой ExIFS и серверами front-end/back-end. В следующей лекции рассказывается об архитектуре маршрутизации сообщений в Exchange Server 2003 и приводится описание того, каким образом сообщения передаются между серверами.
Предназначение хранилища в Exchange Server 2003
Архитектура хранилища в Exchange Server 2003 разработана для выполнения трех задач. Во-первых, это минимизация потерь продуктивности при переходе базы данных в автономный режим. В Exchange Server 2003 эта цель достигается посредством распределения пользователей по нескольким базам данных, которые могут быть смонтированы (запущены) или демонтированы (остановлены) по отдельности. Если по какой-либо причине одна база данных в группе хранилищ отключается, другие базы данных продолжают работать, что сводит к минимуму число пользователей, работа которых прерывается.
Вторая задача заключается в том, чтобы обеспечить поддержку на одном сервере большего числа пользователей, чем это практически возможно в Microsoft Exchange 5.5. Решение этой задачи достигается посредством распределения пользователей по нескольким базам данных на одном сервере. Так как базы данных в данном случае становятся меньшими по размеру, создание дополнительных баз данных позволит реализовывать на каждом сервере поддержку большего числа пользователей. Например, легче работать с шестью базами данных, в каждой из которых тысяча пользователей, чем управлять одной базой данных с шестью тысячами пользователей. Данный подход не только позволяет в отдельном порядке назначать время архивирования и восстановления и выполнять эти процедуры быстрее, но и ведет к снижению числа пользователей (с 6000 до 1000), на которых отразится повреждение одной из баз данных. Кроме этого, Exchange Server 2003 может группировать несколько баз данных в одну группу хранилищ и содержать
несколько групп хранилищ на одном сервере.
Достижение третьей цели – улучшение восстанавливаемости после сбоев – было одной из главных задач группы разработки, и данная цель также достигнута посредством распределения пользователей по базам данных, что позволяет восстанавливать отдельные базы данных во время работы других баз данных. Результатом этого нововведения стало сокращение периодов отключения и повышение производительности работы пользователей, так как переключение базы данных в автономный режим теперь оказывает влияние на работу лишь определенной группы пользователей в организации, а не всех ее сотрудников.
Структура файла базы данных
Любая база данных Exchange 2003 состоит из двух файлов: файла в формате ). Аналогично, хранилище общих папок (в 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.2) Вкладка Database (База данных) окна свойств хранилища почтовых ящиков(рис 2.1) Вкладка 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".)
Наличие нескольких баз данных в нескольких группах хранилищ обеспечивает прекрасную гибкость управления пользователями и базами данных. Например, можно группировать пользователей по подразделениям или расположению и создавать их учетные записи в общей базе данных.
Помимо этого можно осуществлять контроль над соотношением пользователь/база данных, чтобы при росте компании поддерживать определенный размер баз данных и просто создавать дополнительные базы данных для новых пользователей, когда в этом возникнет необходимость.
Кроме того, базы данных являются масштабируемыми, поэтому одна база данных может содержать от одного почтового ящика (теоретически) до неограниченного числа ящиков. Тем не менее, не рекомендуется допускать такие крайности, и в действительности предельное количество почтовых ящиков в базе данных зависит от таких факторов, как емкость аппаратных устройств или количество времени, необходимое для архивации или восстановления баз данных. Архивацию баз данных можно назначать индивидуально для каждой или осуществлять несколько процедур архивации в нескольких базах данных на несколько ленточных носителей одновременно. Эта возможность позволяет сократить время, необходимое для архивации баз данных.
Восстановление данных и журналы транзакций
Три из десяти вопросов, получаемых технической поддержкой Microsoft, связаны с ESE и восстановлением данных. В данном разделе обсуждается роль журналов транзакций и рассказывается о том, как они используются при восстановлении баз данных после сбоев. Здесь также рассказывается о причинах, вызывающих сбои в работе баз данных, и приводятся некоторые распространенные сообщения об ошибках, появляющиеся при сбоях. В лекции 8 "Функциональность, безопасность и поддержка Exchange Server 2003" приводится пошаговое описание процесса восстановления базы данных.
Extensible Storage Engine
Extensible Storage Engine представляет собой систему ведения журналов транзакций, обеспечивающую целостность данных и их сохранность в случае системных сбоев или неполадок в работе носителей. Разработка ESE велась согласно четырем критериям. Первым из них являлся вопрос, что произойдет в случае сбоя. Каждая новая разработка должна была улучшить восстанавливаемость при возникновении неполадок. Вторым критерием было уменьшение числа операций ввода/вывода, производимых ESE, и для достижения этой цели было сделано все возможное. Три операции ввода/вывода выполняются быстрее, чем четыре, а четыре – быстрее, чем пять. Даже если достижение этой цели подразумевает добавление в операцию ввода/вывода дополнительных вычислений, исключение одной операции ввода/вывода значительно улучшает производительность. Третьим критерием при разработке машины базы данных было обеспечение наивысшего уровня самонастраиваемости. Наконец, предусматривалось ее функционирование
в течение времени, максимально приближенного к 24 часам в сутки и 7 дням в неделю. Достижению последней цели способствует обеспечение работы с базой данных в режиме онлайн.
Как работает ESE
Основная функция ESE заключается в управлении транзакциями. ESE выполняет проверку целостности базы с помощью четырех тестов, называемых тестами ACID.
Atomiс (Элементарность). Должны быть завершены либо все операции, выполняющиеся в транзакции, либо не будет завершена ни одна из них.
Consistent (Консистентность). Транзакция должна начинаться в базе данных в консистентном (неизмененном и работоспособном) состоянии и оставлять базу данных после своего завершения в таком же состоянии.
Isolated (Изолированность). Изменения не видны до тех пор, пока не завершатся все операции транзакции. По завершении выполнения всех операций, если база данных находится в консистентном состоянии, транзакция считается фиксированной.
Durable (Стойкость). Фиксированные транзакции сохраняются даже в том случае, если в системе возникают ощутимые проблемы, такие как полный отказ системы.
Примечание. Свойство стойкости проявляется при системных сбоях, возникающих в процессе выполнения операций. Если некоторые операции были завершены перед сбоем в системе (например, электронная почта удалена из папки Inbox [Входящие] и скопирована в папку Private [Личное], но счетчик элементов в каждой папке не обновлен), то после загрузки компьютера при своем запуске процесс Store.exe обнаружит, что база данных находится в неконсистентном состоянии, и произведет откат операций. Эта мера предосторожности обеспечивает невозможность утери сообщения при перемещении, а также отсутствие дубля сообщения после перезагрузки. ESE обеспечивает тот факт, что база данных после перезагрузки компьютера находится в том же самом состоянии, в котором она находилась непосредственно перед началом выполнения операций.
Пример из практики.Что происходит при внесении изменения в страницу базы данных
Предположим, что важное сообщение электронной почты перемещается из папки Inbox (Входящие) в частную папку с именем Private (Личное). Для осуществления этой транзакции должны быть выполнены следующие операции:
добавление сообщения электронной почты в папку Private (Личное);
удаление сообщения электронной почты из папки Inbox (Входящие);
обновление информации о каждой папке для корректного отображения числа элементов в папках;
фиксирование транзакции во временном файле журнала транзакции.
Так как эти операции выполняются в одной и той же транзакции, Exchange либо выполняет их все, либо не выполняет ни одной. Это и есть тест Atomic (Элементарность). Операция фиксирования не может осуществляться до тех пор, пока не будут успешно выполнены все операции. После фиксирования транзакции тест Isolated (Изолированность) считается пройденным. База данных остается в консистентном состоянии, поэтому тест Consistent (Консистентность) также считается пройденным. Таким образом, после фиксирования транзакции в базе данных изменения будут сохранены даже в случае возникновения сбоя. Это обстоятельство отвечает требованиям теста Durable (Стойкость).
Каким образом осуществляется хранение данных. В файле базы данных ESE данные распределены по 4-килобайтным секциям, называемым страницами. Информация считывается из базы данных ESE и загружается в память в виде страницы. Каждая страница содержит определения данных, сами данные, индексы, проверочные суммы, флаги, временные штампы и другую информацию B-дерева. Страницам в базе данных присваиваются последовательные номера для улучшения производительности. Страницы содержат либо непосредственные данные, либо указатели на другие страницы, содержащие данные. Эти указатели формируют структуру B-дерева, и редко встречается дерево, содержащее больше трех или четырех уровней. Следовательно, структура B-дерева широка, но неглубока.
. Для ознакомления с краткими сведениями о структуре B-дерева посетите страницу http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci508442,00.html. И, как известно, с помощью системы Google можно получить дополнительные источники информации, введя строку поиска "B-tree".
Транзакция – это последовательность изменений, вносимых в страницу базы данных. Каждое изменение называется операцией. После выполнения полного набора операций над объектом базы данных транзакция считается завершенной.
Примечание. База данных ESE содержит до 232 (4 292 967 296) страниц. Принимая в расчет 4 Кб на каждую страницу, база данных ESE занимает объем 16 терабайт (4 292 967 296 х 4096 = 17 583 994 044 416 байт) данных. На практике размер базы данных ограничен пространством, обеспечиваемым аппаратными устройствами, методами архивации и восстановления, а не структурой ESE.
Когда страница впервые считывается с диска и сохраняется в памяти, она называется "чистой". Как только страница подвергается изменению посредством выполнения над ней какой-либо операции, она становится "измененной". Измененные страницы доступны для дальнейшей модификации, и такая страница может претерпеть несколько изменений перед записью на диск. Число изменений, вносимых в страницу, не связано с тем, когда страница будет записана на диск. Это действие определяется другими количественными мерами, о которых речь пойдет далее в лекции.
Операции в процессе своего выполнения записываются в хранилище версий. Хранилище версий содержит перечень всех изменений, внесенных в страницу, но еще не зафиксированных. Если питание сервера прервется перед фиксированием последовательности операций, то в процессе отката (отмены) ESE незавершенных операций будет произведено обращение к хранилищу версий. Хранилище версий является виртуальным хранилищем, поэтому на жестком диске нет базы данных с именем Version Store. Хранилище версий располагается в оперативной памяти и действительно содержит версии одной и той же страницы, считанной с диска в память. На рисунке 2.5 приведена наглядная демонстрация этого процесса.
Для непосредственного фиксирования транзакции операции должны записываться в буфер журнала транзакций перед записью в журналы транзакций на диске. ESE использует "упреждающую" регистрацию данных в журнале, т.е. перед внесением изменения в базу данных ESE записывает в файле журнала, какие действия она будет выполнять. Данные записываются в кэшированную версию журнала в области буфера журнала, в страницу в памяти вносятся изменения, и между этими двумя записями устанавливается связь. Перед тем как изменения страницы будут записаны на диск, изменение, записанное в буфере журнала, сначала должно быть записано в файл журнала на диске.
Совет. Одна операция может требовать столько времени для выполнения или быть такой обширной, что в хранилище версий понадобится записать несколько сотен мегабайт данных. Такое может случиться, если операция заключается в индексировании большой таблицы или записи очень большого файла в базу данных. Так как хранилище версий отслеживает все изменения, внесенные в базу данных с момента начала самой старой транзакции, может возникнуть ошибка "-1069 error(JET_errVersionStoreOutOfMemory)". Если это произошло, попробуйте переместить базы данных и хранилища на другой диск с большим объемом свободного пространства, а также рассмотрите вопрос об увеличении объема оперативной памяти компьютера.
(рис 2.5) Метод обработки транзакций ESEЗачастую кэшированные версии изменений страниц не записываются на диск сразу. Это не является проблемой, так как информация записывается в файлы журналов. Если изменения в памяти будут утеряны, при запуске ESE файлы журнала будут считаны вновь (этот процесс обсуждается более подробно далее в лекции), и транзакции будут записаны на диск. Более того, отсутствие немедленной записи кэшированной информации в базу данных увеличивает производительность. Представьте себе ситуацию, в которой страница загружается из памяти и затем подвергается изменению. Если в скором времени после этого ее вновь потребуется изменить, ее не нужно повторно считывать с диска, так как она уже находится в памяти. Таким образом, изменения базы данных могут быть "пакетными", что увеличит производительность.
Файлы базы данных. База данных представляет собой комбинацию файлов .EDB и .STM, хранимых на жестком диске. По существу, все транзакции записываются в один из этих файлов. Тем не менее, перед записью на диск для страницы вычисляется проверочная сумма, после чего эта сумма записывается в страницу вместе с остальными данными. При считывании страницы с диска проверочная сумма вычисляется повторно, и номер страницы проверяется для обеспечения его соответствия номеру запрошенной страницы. Если вычислить проверочную сумму не удается, или если в номере страницы присутствует несоответствие, генерируется сообщение об ошибке "-1018". Эта ошибка означает, что данные, записанные на диск, не являются данными, считанными ESE с диска в оперативную память.
Примечание. Начиная с пакета обновления Service Pack 2 (SP2) в Exchange Server 5.5 и по сей день, в Exchange Server 2003 ESE осуществляет 16 попыток чтения данных перед генерированием ошибки -1018, что уменьшает вероятность возникновения неполадки вследствие какого-либо кратковременного события. Следовательно, возникновение ошибки -1018 означает, что ESE, прежде чем отобразить уведомление об ошибке, многократно повторила попытку чтения данных.
ESE и управление памятью. Перед загрузкой страницы в память ESE должна зарезервировать в памяти область для использования ее в своих целях. Динамическое отведение буфера (DBA) является процессом увеличения размера кэша буфера базы данных перед тем, как возникает надобность в использовании памяти. Достаточно большое число администраторов Exchange пришли к выводу, что Exchange занимает на серверах всю память. Эта ситуация является умышленной, и хотя она не обязательно должна приводить к использованию всей памяти, память, отводимая для Exchange, не является недоступной для других системных процессов. Если процессам требуется дополнительная память, Exchange освободит память для их эффективной работы. Это происходит непосредственно во время работы, и методы, используемые ESE, не являются настраиваемыми.
В Exchange 4 и 5.0 размер кэша устанавливался компонентом Performance Optimizer (Оптимизатор производительности). В Exchange 5.5 этот процесс стал динамическим: ESE исследует систему и настраивает размер кэша базы данных по мере необходимости. Для выяснения объема памяти, резервируемого процессом Store, следует использовать счетчик производительности Cache Size (Размер кэш-памяти).
Теперь самое время выделить общие цели, для достижения которых предназначен процесс DBA. Их знание и понимание поможет легко ответить на любые вопросы относительно управления памятью в Exchange Server 2003. Целями создания DBA являются:
достижение максимального уровня производительности системы. Процесс Store использует общее значение активности страничной организации памяти и ввода/вывода, а также другие факторы для определения количества оперативной памяти, отводимой для буфера базы данных. Данная цель в действительности сфокусирована на общей производительности системы. Ускорение работы Exchange бесполезно, если операционная система постоянно выполняет работу со страницами памяти;
максимизация использования памяти. Неиспользуемая системная память – это потерянные деньги. ESE отводит для себя столько памяти, сколько это возможно, без негативного влияния на другие приложения. Если запускается другое приложение, требующее дополнительного объема памяти, ESE освобождает память для обеспечения эффективной работы этого приложения.
Не стоит беспокоиться, если вы увидите, что в Task Manager (Диспетчер задач) от 1 Гб оперативной памяти системы осталось только 200 Мб, и процесс Store использует все 800 Мб. Недостатка в памяти нет, и процесс Store.exe не содержит утечку памяти. Это лишь означает, что функция DBA машины ESE отвела дополнительный объем оперативной памяти для увеличения производительности системы. На рисунках 2.6 и 2.7 показано, как это выглядит в программе Task Manager (Диспетчер задач). На рисунке 2.6 видно, что процессы Store.exe и Mad.exe используют больший объем памяти, чем большинство других процессов. Это изображение сохранено с экрана сервера, который не был загружен работой, а процесс Store.exe по-прежнему находился на первом месте в списке по уровню использования памяти. На рисунке 2.7 видно, что доступный объем системной памяти
равен лишь 49 176 Кб. Обратите внимание на область Physical Memory (K) (Физическая память, Кб), а именно на значение Available (Доступно).
(рис 2.7) Вкладка Processes (Процессы) в Диспетчере задач Windows, отображающая объем памяти, отведенный для процессов Store.exe и Mad.exe(рис 2.6) Вкладка Performance (Производительность) в Диспетчере задач Windows, отображающая уровень использования памяти и ее свободный объемФайлы журналов транзакций. Теоретически файл журнала транзакции может постоянно увеличиваться. Однако если его размер увеличится до такой степени, что займет очень много пространства на диске, то это сделает работу с ним крайне затруднительной. По этой причине журнал разбивается на поколения, т.е. на несколько файлов, каждый из которых имеет размер 5 Мб и представляет собой определенное поколение. Поколению файла журнала присваивается имя EdbXXXXX.log, где XXXXX представляет собой последовательно увеличивающееся шестнадцатеричное число.
Файл Edb.log представляет собой самое первое поколение. Когда он заполняется, ему присваивается имя со следующим шестнадцатеричным номером. При этом создается временный файл журнала Edbtemp.log для регистрации транзакций, пока не будет создан новый файл Edb.log.
Каждый файл журнала состоит из двух частей – заголовка и данных. Заголовок содержит жестко запрограммированные пути к соответствующим базам данных. В Exchange Server 2003 несколько баз данных могут использовать один и тот же файл журнала, так как файлы журналов обслуживают всю группу хранилищ. С точки зрения администрирования данный подход упрощает процесс восстановления. Независимо от того, какая база данных в группе хранилищ подвергается восстановлению, будет происходить обращение к одним и тем же файлам журналам рассматриваемой группы. Заголовок также содержит подпись, сверенную с подписью базы данных. Это предотвращает сопоставление файла журнала другой базе данных с идентичным именем.
Можно осуществлять разгрузку информации заголовка файла журнала с помощью команды ESEUTIL /ML (см. рис 2.8). В процессе разгрузки отображается номер поколения, пути базы данных и подписи. Часть файла журнала с данными содержит данные о транзакциях, например BeginTransaction (Начало транзакции), Commit (Фиксирование) и Rollback (Откат). Большая часть файла содержит низкоуровневые физические изменения базы данных. Иными словами, эти записи можно интерпретировать следующим образом: "Данная информация была добавлена в эту страницу в такое-то место".
(рис 2.8) Разгрузка заголовка с помощью команды ESEUTIL /MLИзменение базы данных состоит из нескольких этапов. Во-первых, страница считывается в кэш базы данных, после чего обновляется временной штамп этой страницы. Временной штамп инкрементируется для каждой базы данных по отдельности. После этого создается запись журнала с констатацией того, какие действия будут произведены в базе данных. Это происходит в буфере кэш-памяти журнала. Затем страница подвергается изменению, и между этими двумя записями устанавливается связь, не позволяющая записать страницу на диск без предварительного переноса на диск записи файла журнала. Данный этап гарантирует запись изменения базы данных в файл журнала перед обновлением базы данных на диске.
Таким образом, существует разумная концепция кэширования обратной записи, реализуемая на диске с файлом журнала. По существу, кэширование обратной записи подразумевает под собой процесс, в ходе которого оборудование передает обратно в ESE отчеты об успешной записи на диск, даже если информация находится в буфере диска контроллера, и ее непосредственная запись на диск отложена на более позднее время. Кэширование обратной связи, несмотря на улучшение производительности, может прерывать процесс ESE записи изменений в файл журнала перед их занесением в базу данных. При неполадках в работе контроллера или диска может возникнуть ситуация, когда страница будет записана на диск, но не зарегистрирована в файле журнала, что приведет к повреждению базы данных.
Повторное считывание файлов журнала при восстановлении. После восстановления базы данных журналы повторно считываются при запуске процесса Store.exe. Повторное считывание журналов и последующий откат операций являются составными частями "запуска" процесса Store; эта процедура часто называется процессом восстановления. Повторное считывание журналов транзакций представляет собой первую часть процесса восстановления и занимает большую часть времени, необходимого для запуска процесса Store.exe.
Повторное считывание файлов журналов транзакций заключается в том, что для каждой записи журнала считывается страница, соответствующая записи, и временной штамп на этой странице сравнивается с временным штампом записи журнала, ссылающейся на эту страницу. Если временным штампом записи журнала является 12, а страницы, считываемой из базы данных – 11, ESE определяет, что изменение, зафиксированное в файле журнала, не было записано на диск, и запись журнала заносится в базу данных. Однако если значение временного штампа страницы на диске больше или равно временному штампу записи журнала, ESE не записывает эту запись журнала на диск и переходит к следующей записи в журнале.
Во второй, завершающей, фазе процесса восстановления происходит откат всех незафиксированных операций: если передана часть сообщения электронной почты, то его передача отменяется, если сообщение удалено, оно восстанавливается. Этот процесс называется физическим повторением и логической отменой. Восстановление происходит при каждом запуске процесса Store.exe. Если остановить и запустить процесс Store пять раз, то процесс восстановления также будет выполнен пять раз.
Несмотря на то что процесс восстановления выполняет действия с файлами журналов и не затрагивает базы данных, в случае перемещения баз данных восстановление не будет функционировать, так как закодированный в заголовке файла журнала путь к базе данных уже не будет указывать на базу данных. По окончании восстановления выполнение процесса будет казаться успешным, однако при попытке использования соответствующей базы данных сгенерируется сообщение об ошибке с идентификатором события 9519 из журнала приложения MSExchangeIS, предупреждающее об ошибке запуска базы данных (см. рис 2.9).
(рис 2.9) Сообщение об ошибке, возникшей при запуске базы данныхЕсли возвратить базу данных в место расположение, указанное в заголовке файла журнала, а затем запустить процесс Store, процесс восстановления вернет базу данных в консистентное рабочее состояние.
Файл контрольной точки. Файл контрольной точки оптимизирует процесс восстановления. Он фиксирует информацию о том, какие записи в файлах журналов уже записывались на диск. Если все записи файлов журналов записаны на диск, то в процессе восстановления не потребуется их повторного считывания. Файл контрольной точки может сократить время восстановления, сообщая ESE о том, какие записи файла журнала нужно считать повторно, и какие не требуют повторного считывания.
Иногда ускорить процесс восстановления баз данных помогает использование циклического ведения журналов. При этом происходит удаление файлов журналов, более старых, нежели текущее местонахождение контрольной точки. Недостаток циклического ведения журналов заключается в том, что теряется возможность восстановления работоспособности системы с повтором всех завершенных транзакций, записанных на архивный накопитель. Если некоторые файлы журналов удалены в рамках циклического ведения журналов после проведения последней полной архивации, можно произвести восстановление только с использованием последнего полного архива. Однако при наличии всех старых файлов журналов восстановление с помощью последнего полного архива базы данных с резервного накопителя позволит произвести полное восстановление вплоть до момента сбоя, так как все файлы журналов смогут быть повторно считаны и записаны в восстановленную базу данных. Следует помнить, что
для осуществления полного восстановления база данных должна находиться в том же физическом состоянии, в котором она находилась в момент записи файлов журналов. Физически поврежденную базу данных восстановить нельзя.
Внимание! Никогда, никогда, никогда не удаляйте файлы журналов! Предположим, файл журнала 9 содержит команду добавления новой страницы в определенное место базы данных. Файл журнала 10 содержит команду удаления этой страницы. Теперь предположим, что администратор удаляет файл журнала 9, возможно, по причине того, что этот файл слишком устарел, и удаляет файл контрольной точки. После этого администратор решает перезагрузить систему по каким-либо иным причинам. При запуске процесса Store.exe ESE автоматически переходит в режим восстановления. Не обнаружив файла контрольной точки, ESE не сможет сделать ничего, кроме повторного считывания всех файлов журналов. При повторном считывании файла журнала 10 команда удаления будет выполнена на соответствующей странице, и ее содержимое будет уничтожено. ESE не известно о том, что имела место более ранняя команда добавления новой страницы в это расположение базы данных,
так как файл журнала 9 удален. Таким образом, база данных станет поврежденной. Ни при каких обстоятельствах не удаляйте файлы журналов! Более того, имейте в виду, что кэширование обратной записи может вызвать удаление файлов журналов. Рекомендуется отключить кэширование обратной записи и никогда не удалять файлы журналов и файл контрольной точки.
Занесение в базу данных записей журнала. Как уже упоминалось ранее, измененные страницы в памяти и фиксированные транзакции в области буфера журнала не записываются на диск немедленно. Фиксированные транзакции в файле журнала транзакций копируются в базу данных при возникновении одного из следующих условий:
контрольная точка находится слишком далеко в прежнем файле журнала. Если число фиксированных транзакций в файлах журналов достигает определенного порогового значения, ESE сбрасывает эти изменения на диск;
число свободных страниц в памяти стало слишком мало, что, возможно, сказывается на производительности системы. В этом случае фиксированные транзакции в памяти сбрасываются на диск, чтобы освободить страницы в памяти для использования системой;
другая служба запрашивает дополнительный объем памяти, и ESE требуется освободить некоторое количество памяти, занимаемой ESE в данный момент. ESE сбрасывает страницы из памяти в базу данных, после чего обновляет файл контрольной точки;
служба базы данных отключается. В этом случае все обновленные страницы в памяти копируются в файл базы данных.
Имейте в виду, что страницы не копируются из памяти в каком-либо определенном порядке и могут не копироваться все сразу. Случайный порядок копирования страниц на диск означает, что при сбое в системе во время записи страниц на диск файл базы данных может содержать лишь части фиксированной транзакции, обновленные непосредственно в файле. В этом случае при запуске процесса Store транзакция будет повторно считана из файлов журнала транзакций, и обновление базы данных будет произведено полностью.
Монтируемая файловая система
В Exchange 2000 Server ExIFS была смонтирована по умолчанию и являлась рекомендуемым методом управления данными пользователей. Как известно, файловая система Installable File System (Монтируемая файловая система) позволяла пользователям размещать документы любого типа в файле с содержимым в собственном формате (потоковом файле), после чего осуществлять к ним доступ почти из любого клиента, независимо от того, является ли он браузером, клиентом MAPI или приложением Microsoft Internet Explorer.
Однако Microsoft отказалась от использования IFS для управления данными и файлами. В Exchange Server 2003 файловая система IFS не смонтирована по умолчанию. Если нужно смонтировать IFS для представления баз данных в качестве виртуальной файловой системы, необходимо включить устройство M: с помощью следующего параметра реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS\parameters
Параметр: DriveLetter
Тип: String
Значение: M
Следует использовать устройство M: только для получения доступа к данным файла в формате, отличном от MAPI. Не следует открывать доступ к фрагментам устройства M: для доступа пользователей блока серверных сообщений (SMB). Рекомендуется использовать клиент Web Folder для доступа к данным в хранилищах при работе с приложениями типа Microsoft Word вместо использования устройства M: и доступа SMB.
или http://wwwacs.gantep.edu.tr/foldoc/foldoc.cgi?Server+Message+Block. По существу, блоки серверных сообщений представляют собой команды, передаваемые клиентом серверу для запроса файловых операций, таких как копирование, создание каталога и удаление. Будучи во многом похожими на протокол передачи почты SMTP (Simple Mail Transport Protocol), использующий архитектуру "запрос-ответ", команды SMB представляют собой последовательности запросов, исходящих от клиентов, и ответов, получаемых от сервера. Число и тип команд, используемых между клиентом и сервером, определяются в процессе прямого согласования при выполнении трехстороннего рукопожатия TCP, когда между клиентом и сервером устанавливается сеанс связи.
Чтобы лучше разобраться в процессе трехстороннего рукопожатия TCP, обратитесь к книге "Протоколы и службы TCP/IP в Microsoft Windows Server 2003. Справочник администратора" (издательство "Эком").
Клиент Web Folder
Как уже говорилось ранее, доступ к информации, находящейся в файле с содержимым в собственном формате, можно осуществлять через интернет с использованием протокола HTTP. Это осуществляется посредством присвоения каждому объекту в файле уникального URL, позволяющего осуществлять доступ к объекту из браузера, посредством чего стороннее приложение может напрямую запрашивать в хранилище Exchange получение данных как из почтовых ящиков, так и из общих папок.
WebDAV (Web Development Authoring and Versioning) представляет собой расширение протокола HTTP и является стандартизированным протоколом, построенным на основе HTTP 1.1. Он поддерживает более сложную структуру команд, в которую входят новые команды COPY и MOVE, управляющие отдельными объектами на веб-сервере. Кроме этого, данный протокол позволяет осуществлять доступ чтения/записи к информационному хранилищу через HTTP с использованием браузера в качестве клиента. Он поддерживает реляционные базы данных, слабоструктурированные базы данных (такие как базы данных Exchange) и стандартные файловые системы. Более того, клиенты WebDAV могут быть синхронизированы с хранилищами серверной части через интернет посредством репликации, что позволяет эффективно осуществлять онлайн-доступ и работать с данными в автономном режиме. Эта возможность позволяет, например, публиковать ежечасное обновление текущих данных об инвентаризации для
общенационального информирования продавцов. Каждый продавец сможет ознакомиться с этими данными через интернет, ввести заказы и комментарии и обеспечивать наличие финансовой информации на сайте-клиенте, пока будет возможен доступ в интернет.
WebDAV работает с содержимым любого типа, поэтому пользователи могут использовать WebDAV для коллективной работы над текстовым документом, электронной таблицей или изображением. Практически все содержимое файла можно изменить при помощи WebDAV. WebDAV делает интернет, с точки зрения клиента, записываемым носителем информации. Microsoft Internet Explorer 5 и Microsoft Office 2000 (и новее) совместимы с WebDAV. Ниже приведены некоторые возможности WebDAV.
Защита от записи (блокировка файла). Пользователи могут записывать, редактировать и сохранять общие документы без перезаписи результатов работы другого пользователя, независимо от того, какую программу или службу интернета он использует. Это ключевая возможность, обеспечивающая совместную работу.
Управление пространством имен. У пользователей есть возможность удобно управлять файлами и каталогами интернета, включая операции перемещения и копирования файлов. Этот процесс аналогичен тому, как осуществляется управление файлами в Explorer.
Доступ к свойствам (метаданным). Пользователи могут производить индексацию и поиск метаданных о документе, таких как имя автора, авторские права, дата публикации или ключевые слова, с целью нахождения и получения соответствующих документов. (Для получения более подробной информации обратитесь к параграфу "Индексация" далее в лекции.)
Веб-папки позволяют клиентам осуществлять доступ к веб-серверу аналогично тому, как осуществляется работа с файловым сервером. Exchange Server 2003 позволяет клиенту осуществлять доступ к каталогам и элементам в информационном хранилище как к файловому серверу и осуществлять управление данными в веб-папке так, как если бы это был файловый сервер. Общие папки в Exchange Server 2003 также представляются в виде веб-папок. Клиент Web Folder входит в комплект поставки операционных систем Microsoft Windows 2000 Professional и Microsoft Windows XP. Чтобы создать веб-папку ресурса в хранилище Exchange, воспользуйтесь мастером добавления в сетевое окружение (Add Network Place Wizard) в папке My Network Places (Мое сетевое окружение) и введите что-либо из следующего:
расположение каталога на сервере с помощью адреса UNC (Universal Naming Convention), например, \\имя_сервера\имя_каталога ;
адрес URL, такой как http://www.microsoft.com;
сайт FTP с использованием следующего синтаксиса: ftp://ftp.microsoft.com.
После создания веб-папки клиент Web Folder можно использовать для доступа к информации из приложения, программы Windows Explorer (Проводник Windows) или из других утилит клиентской части.
Переход от IFS к клиенту Web Folder является большим шагом вперед, который избавляет от необходимости использовать SMB для работы с интернет-технологиями при управлении и оперировании информацией, в частности, файлами данных. Более того, если у читателя появится возможность ознакомиться со службой Windows SharePoint Services от Microsoft, он обнаружит, что управление файлами теперь базируется на архитектуре базы данных, а не на архитектуре файлового сервера. Этот шаг является частью общей стратегии отказа от использования того, что мы привыкли называть технологиями, основывающимися на локальной сети, и перехода к работе с технологиями, базирующимися на веб-службах. Такой переход действительно осуществляется в настоящее время, и новые принципы работы представлены почти в каждой новой платформе, выпускаемой Microsoft.
Что произойдет, если при использовании Exchange 2000 Server очень большое количество документов будет "сброшено" в общие папки, доступ к которым пользователи осуществляют через IFS? В Exchange Server 2003 можно оставить эти документы в общих папках и, если это действительно нужно, смонтировать IFS и использовать SMB для получения документов. Однако следует иметь в виду, что наступит такой момент, когда все данные будут находиться в базе данных, аналогичной SQL. Система Web Storage System, как известно, уступит место следующей большой базе данных, которая будет построена на базе SQL. Может оказаться полезным произвести в данный момент планирование этого предстоящего изменения.
Общие папки
В Exchange Server 2003 управление общими папками осуществляется аналогично тому, как это реализовано в Exchange 2000 Server. Данный подход включает в себя следующие особенности.
Администрирование общих папок осуществляется через оснастку MMC Exchange Folders (Папки Exchange).
Деревья общих папок гораздо более масштабируемы и гибки. Теперь можно создавать деревья папок по географическому местоположению, подразделениям организации или выполняемым функциям. В следующем параграфе приводится более подробное обсуждение этой возможности.
Общие папки интегрированы с Active Directory, поэтому записи электронной почты позволяют отправлять сообщения в общие папки вместо их непосредственной публикации в общей папке.
Общие папки в целях безопасности работают с пользователями и группами из службы каталогов Active Directory.
Доступ к общей папке через интернет теперь является более прямым и простым. В Exchange 2003 можно открыть содержимое общей папки с помощью обычного адреса URL.
В общих папках предусмотрена полнотекстовая индексация. Клиенты Outlook автоматически используют этот новый индекс при выполнении поиска или расширенного поиска.
По умолчанию включены направления. Направления общей папки позволяют клиентам получать доступ к любой папке в организации, так как теперь направления между группами маршрутизации включены по умолчанию.
Общие папки можно создавать при помощи оснастки Exchange Folders (Папки Exchange). Больше нет необходимости в использовании Outlook для создания общей папки, хотя данная возможность по-прежнему предусмотрена.
Множество деревьев общих папок
В Exchange Server 2003 можно с различными целями создавать большое число деревьев общих папок. Предположим, что группа сотрудников, работающих над одним проектом, состоит из трех внутренних клиентов сети, двух пользователей компании, находящихся в удаленных расположениях, и трех консультантов, не входящих в штат организации. Можно создать для этих пользователей дерево общих папок, отдельно от дерева общих папок по умолчанию (см. рис 2.10).
(рис 2.10) Множество деревьев общих папокКаждое дерево общих папок содержит данные в одном хранилище общих папок на каждом сервере. Можно осуществить репликацию определенных папок в дереве на каждый сервер организации, на котором имеется хранилище общих папок, ассоциированное с этим деревом общих папок. Стандартное дерево общих папок доступно через протоколы MAPI, IMAP4, Network News Transfer Protocol (NNTP) и HTTP. Дополнительные деревья общих папок доступны только клиентам HTTP и NNTP.
Доступ клиентов к хранилищам Exchange 2003
Клиент Exchange 2003 может осуществлять доступ к хранилищу Exchange несколькими способами. Доступ к информационному хранилищу выполняется через POP3, NNTP, IMAP4, HTTP, SMTP, посредством объявления свойств, с помощью обычных адресов URL и WebDAV.
Хранилище данных, в частности, поддерживает работу с MAPI, что обеспечивает возможность отправки и получения пользователями электронной почты. Хранилище также предоставляет URL каждого находящегося в нем элемента. Каждый раз при создании в хранилище сообщения или файла Exchange создает для этого объекта уникальный URL. Например, доступ к папке Inbox (Входящие) пользователя можно осуществить посредством следующего URL: File://./BackOfficeStorage/имя_сервера.имя_домена.com/mbx/имя_пользователя/inbox/имя_документа.
Индексирование
Процесс информационного хранилища создает и использует в работе индексы полей общего ключа для ускорения просмотра и поиска документов, находящихся в хранилище. Индекс позволяет пользователям Outlook упростить поиск элементов. При использовании полнотекстового индексирования индекс создается перед операцией поиска, производимой клиентом, что обеспечивает ускорение процедур поиска. В полнотекстовое индексирование могут быть включены текстовые вложения. Каждое хранилище информации можно проиндексировать в индивидуальном порядке для повышения гибкости.
Объявление свойств позволяет производить расширенный поиск по любым свойствам документов, таким как автор, число строк или тема документа (см. рис 2.11). При сохранении хранилищем Exchange документа в файле поддерживаемого типа свойства документа автоматически считываются и объявляются в информационном документе. Следовательно, свойства становятся частью записи документа в базе данных. Это позволяет осуществлять поиск документов по их свойствам.
Индекс состоит из слов, а не из символов. Это означает, что если пользователь осуществляет поиск по слову "admin", то в результатах поиска будут приведены только документы, содержащие слово "admin". Слово "administrator" не будет соответствовать данному критерию поиска. Можно индексировать как сообщения, так и вложения. Двоичные вложения и свойства документа не индексируются. Не все типы файлов можно проиндексировать; по умолчанию индексируются только следующие типы документов:
документы Word ( *.doc );
документы Excel ( *.xls );
документы PowerPoint ( *.ppt );
документы HTML ( *.html, *.htm, *.asp );
текстовые файлы ( *.txt );
встроенные сообщения MIME ( *.eml )
(рис 2.11) Расширенный поиск документа по его свойствам, объявленным в информационном хранилищеИндексация осуществляется службой Microsoft Search. Для создания, обновления и удаления индекса должны быть запущены служба информационного хранилища и служба поиска. В зависимости от размера хранилища выполнение полного индексирования может занять несколько часов. Следовательно, лучше проводить эту процедуру в то время, когда использование сервера сведено к минимуму. Помните, что процедура индексирования занимает около 20 процентов дискового пространства базы данных. Кроме того, нельзя осуществлять архивацию отдельных индексов; их архивация выполняется на уровне сервера. Наконец, несмотря на то что в базе данных может находиться несколько вхождений сообщения, каждое сообщение индексируется только один раз. Однократное индексирование сообщений обеспечивает меньший размер индексов, что укоряет создание последних.
Процесс индексирования
Microsoft Search создает начальный индекс посредством покатологовой обработки всего хранилища. Процесс Search определяет и регистрирует текст, по которому может осуществляться поиск. В это время наблюдается высокий уровень использования процессора; в зависимости от размера хранилища данный процесс длится несколько часов.
После создания индекса любое изменение, вносимое в папку в хранилище, вызывает событие синхронизации для уведомления службы Microsoft Search о внесенном изменении. В зависимости от настройки службы Search, она будет либо ожидать назначенного времени для генерирования индекса, чтобы индексировать внесенное изменение, либо обновит индекс через небольшой интервал времени после внесения изменения.
Обновление индекса
Интервал времени перед немедленным (автоматическим) обновлением индекса зависит от текущего уровня загрузки сервера. Этот параметр настраивается на вкладке Full-Text Indexing (Полнотекстовое индексирование) окна свойств информационного хранилища (см. рис 2.12).
Назначенные обновления позволяют осуществлять тщательный контроль за тем, когда происходит обновление индекса. Преимущество назначения обновления индекса заключается в том, что оно может быть запланировано на время, когда нагрузка на сервер незначительна из-за относительно небольшого числа пользователей, осуществляющих к нему доступ. Недостатком такого подхода является то, что индекс может стать "просроченным" в рамках одного дня. Тем не менее, это не является большим минусом, так как большинство пользователей осуществляют поиск документов, полученных и индексированных ранее, чем в течение последних 24 часов перед операцией поиска. Следует попытаться настроить выполнение обновления, по крайней мере, один раз в течение каждого дня.
Архитектура поиска
Если требуется реализовать возможность полнотекстового поиска во всей организации, следует рассмотреть вариант с установкой клиентов обмена сообщениями. Только онлайн-клиенты MAPI и IMAP4 имеют возможность осуществлять полнотекстовый поиск на сервере. Клиенты POP3 и WebDAV не предоставляют такой возможности.
Exchange Server 2003 выполняет операции поиска двух типов. Первым из них является полнотекстовый запрос индекса, созданного службой Microsoft Search, вторым – запрос, основанных на свойствах документов, не доступных в полнотекстовом индексе.
(рис 2.12) Вкладка Full-Text Indexing (Полнотекстовое индексирование) окна свойств хранилища общих папокКогда пользователь осуществляет поиск в клиенте Outlook посредством выбора команды ).
(рис 2.13) Диалоговое окно Advanced Find (Расширенный поиск) в Outlook 2003После указания пользователем нужных значений запрос отправляется обработчику запросов Query Processor, определяющему способ выполнения поиска. Если поиск основан как на строке символов, так и на переменной определенного свойства, Query Processor разделяет запрос на две части. Предположим, что запрос охватывает все документы, размер которых превышает 5 Мб, и что в поле темы присутствуют слова "building plan". Query Processor разделяет этот запрос и дает службе Microsoft Search указание сгенерировать список документов, содержащих в поле темы слова "building plan". Затем вычисляется размер каждого документа, возвращенного службой Search, для выявления документов, чей размер превышает 5 Мб, и генерируется новый перечень документов, соответствующих обоим критериям.
Наконец, Exchange Server 2003 налагает ограничения на остальные документы, чтобы клиент не получил документы, на просмотр которых у него нет полномочий. После принятия мер безопасности результаты, соответствующие критериям поиска, возвращаются клиенту.
Файлы сбора данных
Файлы сбора данных создаются при каждой процедуре индексирования. Они по умолчанию располагаются в каталоге ExchangeServer_<имя_сервера>\Gatherlogs и оканчиваются расширением .GTHR. Эти текстовые файлы можно использовать для выявления каждого документа и сообщения, которое не было успешно индексировано. Например, если документу присвоено имя с расширением, соответствующим поддерживаемому типу файлов, однако рассматриваемый файл в действительности представляет собой иной тип файлов, компонент индексирования "зависает", операция индексирования не выполняется, в файл сбора данных записывается URL документа (см. рис 2.14), после чего осуществляется переход к следующему сообщению или документу.
(рис 2.14) URL в файле сбора данныхВ дополнение к URL в файл сбора данных может быть записана тема или имя файла. Для расшифровки номера ошибки следует использовать утилиту Gthrlog.vbs в каталоге \Program Files\Common Files\System\MsSearch\Bin. Синтаксис команды, запускающей эту утилиту, таков:
Gthrlog <имя_файла>
где ).
(рис 2.15) Диалоговое окно со строкой из файла сбора данных
Перемещение индекса по достижении им слишком большого размера
Если каталоги стали настолько большими, что не хватает свободного места на диске, можно переместить индекс на другой сервер. Для этого необходимо остановить службу Search и использовать утилиту Catutil.exe, расположенную в папке Program Files\Common Files\System\MSSearch\Bin. Для получения справки относительно работы с данной утилитой введите в командной строке команду Catutil Movecat /?.
Серверы front-end/back-end
Между архитектурой хранилищ Exchange и протоколами доступа интернета есть слой Exchange Interprocess Communication Layer (EXIPC) (Межпроцессный коммуникационный слой Exchange), или слой epoxy, представляющий собой эффективную асинхронную открытую область в памяти, которая используется процессом Store.exe и протоколами IIS для чтения и записи. Этот слой очередей позволяет очень быстро осуществлять обмен информацией между протоколами IIS, выполняющимися в процессе Inetinfo.exe, и процессом Store.exe. Слой epoxy использует общую память для установления связи между этими процессами и является оптимальным для коммуникации малых пакетов.
Для отслеживания присоединения, подключения и использования очередей слоя epoxy Exchange Server 2003 использует программу Central Queue Manager (Центральный диспетчер очередей). Этот диспетчер отвечает, кроме того, за отсоединение и очистку очереди в случае возникновения фатальной ошибки в другом процессе. Так как транспортные протоколы и хранилище информации разделены, мы можем применить архитектуру front-end/back-end, которая сделает возможным выполнение других протоколов интернета на иных серверах, нежели те, на которых функционируют хранилище и базы данных. Главным преимуществом этого подхода является возможность расширить Exchange на любую нужную установленную базу. Для обеспечения выполнения Exchange Server 2003 роли front-end-сервера нужно просто отметить опцию на вкладке General (Общие) окна свойств сервера Exchange в оснастке Exchange System (см. рис 2.16).
(рис 2.16) Включение на сервере функции front-end-сервераЕсли функция не включена, библиотеки DLL протоколов, такие как Pop3be.dll, Imap4be.dll и Httpbe.dll, загружаются в память. Если на сервере включена функция front-end-сервера, эти протоколы выгружаются, и в память загружаются специальные front-end-библиотеки DLL, такие как Pop3fe.dll, Imap4fe.dll и Httpfe.dll. Для обеспечения равномерного распределения нагрузки между запросами клиентов на front-end-серверах необходимо использовать круговую схему DNS (в которой несколько IP-адресов присваиваются одному имени узла), программу распределения сетевой нагрузки Network Load Balancing (NLB) или иное стороннее программное обеспечение.
Заключение
В лекции рассказывалось об архитектуре хранилищ, используемой в Exchange Server 2003. Говорилось о том, что процесс Store.exe может осуществлять управление множеством баз данных на одном сервере, и что базы данных поделены на хранилища, каждое из которых содержит до пяти баз данных. Были оговорены некоторые моменты, связанные с новой архитектурой общих папок, WebDAV, индексированием, файловой системой ExIFS и серверами front-end/back-end. В следующей лекции рассказывается об архитектуре маршрутизации сообщений в Exchange Server 2003 и приводится описание того, каким образом сообщения передаются между серверами.
