Опубликован: 30.04.2006 | Уровень: специалист | Доступ: свободно
Лекция 2:

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

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >

Файлы сбора данных

Файлы сбора данных создаются при каждой процедуре индексирования. Они по умолчанию располагаются в каталоге ExchangeServer_<имя_сервера>\Gatherlogs и оканчиваются расширением .GTHR. Эти текстовые файлы можно использовать для выявления каждого документа и сообщения, которое не было успешно индексировано. Например, если документу присвоено имя с расширением, соответствующим поддерживаемому типу файлов, однако рассматриваемый файл в действительности представляет собой иной тип файлов, компонент индексирования "зависает", операция индексирования не выполняется, в файл сбора данных записывается URL документа (см. рис. 2.14), после чего осуществляется переход к следующему сообщению или документу.

URL в файле сбора данных

увеличить изображение
Рис. 2.14. URL в файле сбора данных

В дополнение к URL в файл сбора данных может быть записана тема или имя файла. Для расшифровки номера ошибки следует использовать утилиту Gthrlog.vbs в каталоге \Program Files\Common Files\System\MsSearch\Bin. Синтаксис команды, запускающей эту утилиту, таков:

Gthrlog <имя_файла>

где <имя_файла> представляет собой имя файла сбора данных. Будет отображен набор диалоговых окон с информацией, обнаруженной в каждой строке файла сбора данных (см. рис. 2.15).

Диалоговое окно со строкой из файла сбора данных

Рис. 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).

Включение на сервере функции front-end-сервера

Рис. 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 и приводится описание того, каким образом сообщения передаются между серверами.

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >
Дмитрий Матвеев
Дмитрий Матвеев
Россия, Москва, 1100, 2009