Кен Спенсер

Основное преимущество Microsoft Internet Information Server (IIS) 4.0 заключается в его способности выполнять приложения как внутри собственного процесса, так и вне его. По умолчанию, IIS запускает каждое приложение в рамках адресного пространства своего собственного процесса (inetinfo.exe). Чтобы оценить интенсивность работы приложений в этом режиме, можно запустить утилиту Task Manager или Performance Monitor и посмотреть, как процесс inetinfo.exe использует ресурсы процессора.

Выполнение приложений в адресном пространстве процесса IIS обеспечивает им максимально быстрый доступ к ресурсам сервера и повышает эффективность их работы. В таком режиме, например, работает высокопроизводительное приложение FMStocks, разработанное для Microsoft компанией Vertigo Software. В то же время запуск всех программ в адресном пространстве IIS 4.0 имеет свои недостатки, поскольку в этом случае они могут воздействовать друг на друга. Так, отказ одного из них вполне может привести к «обвалу» остальных. Правда, если сбой прикладного компонента произошел вследствие логической ошибки, он обычно не оказывает влияния на работу IIS и других приложений. Однако, когда такой сбой происходит в результате попытки приложения получить доступ к памяти вне адресного пространства процесса, он может привести к отказу IIS и остальных приложений.

При возникновении проблемы в работе IIS прежде всего нужно локализовать ее источник. Поэтому если приложение периодически «падает» и останавливает работу Web-сервера, его следует сконфигурировать с помощью страницы свойств для работы в отдельном адресном пространстве, что позволит предотвратить дальнейшие отказы до выяснения их причины. На Экране 1 показана страница Properties моего тестового приложения MTSTester.

Надо отметить, что Web-узлы, на которых установлены лишь IIS, не требуется часто перезагружать или перенастраивать, поскольку в этом случае сервер функционирует очень устойчиво. Например, у моего провайдера 17 надежно работающих серверов IIS 4.0 под управлением Windows NT 4.0 Server с SP5, на которых выполняются приложения HTML, Active Server Pages (ASP) и COM.

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

Управление COM-объектами требует понимания особенностей их работы. Поскольку они представляют собой откомпилированный программный модуль, изучить их код и алгоритмы, как правило, не представляется возможным, а это затрудняет контроль за работой приложения и выявление причин возникающих отказов. Например, можно использовать приобретенные COM-объекты, разработчики которых не предоставили доступа к исходным текстам. Загрузив эти объекты, процесс IIS исполняет их код в своем адресном пространстве.

Хотя мой Internet-провайдер прилагает все усилия к тому, чтобы его COM-объекты работали надежно, во второй половине 1998 года я заметил, что мой узел в течение некоторого времени функционирует нормально, а затем его производительность постепенно падает до нуля. Снижение производительности имело место в течение нескольких недель или месяцев и носило беспорядочный характер. Когда я вызвал специалиста по технической поддержке, он выяснил, что мой узел работает во внепроцессном режиме. Как только его перевели на работу во внутрипроцессном режиме, все стало на свои места.

После случившегося я разговаривал с несколькими людьми, которым пришлось столкнуться с подобной ситуацией. Мы сошлись на том, что приложения IIS 4.0, работающие во внепроцессном режиме, часто вызывают такого рода проблемы, которые заставляют перезагружать сервер. Я знаю администраторов, которые запускают приложения intranet в фоновом режиме для предотвращения отказа серверов, но при этом периодически перезагружают их. Такой подход помогает, так что администраторам приходится мириться с неприятностями.

Для управления внепроцессными и внутрипроцессными компонентами IIS 4.0 задействует Microsoft Transaction Server (MTS), формирующий так называемые пакеты MTS. Эти пакеты представляют собой контейнеры для одного или нескольких COM-компонентов, и они же определяют пространство имен этих компонентов. Управление пакетами MTS возложено на программу mtx.exe. Контролировать работу экземпляров mtx.exe, создаваемых MTS при запуске фоновых приложений, можно с помощью утилиты Task Manager.

Желая повысить производительность, администраторы запускают пакеты MTS в адресном пространстве процесса IIS (для этого необходимы

административные привилегии MTS Explorer). Пакеты MTS могут выполняться в рамках серверного процесса (так называемые серверные пакеты) или внутри процесса вызывающего их приложения. С помощью страницы свойств можно сконфигурировать пакет для работы в рамках процесса inetinfo.exe. Чтобы открыть страницу свойств, следует запустить MTS Explorer из меню Programs, открыть папку Computers, папку необходимого компьютера, а затем папку Packages Installed. После этого нужно выбрать настраиваемый пакет и открыть его страницу свойств. На вкладке Activation, как показано на Экране 2, следует установить переключатель Library Package и нажать кнопку ОК. После такой операции объекты пакета будут работать в адресном пространстве вызывающего приложения (inetinfo.exe в случае IIS).

Чтобы изолировать некорректно работающие приложения IIS, нужно изменить настройки используемых пакетов MTS и убедиться, что они работают как серверные (т. е. установлен переключатель Server Packages), а не как библиотечные. В результате пострадает производительность, но IIS останется работоспособным в случае отказа объекта MTS.

Служба IIS Exception Monitor помогает администраторам выявлять причины сбоя в работе IIS. Этот инструмент предназначен для контроля за работой IIS и исправления ошибок в случае нарушений в работе сервера. При этом тип выполняемой диспетчером операции зависит от его конфигурации.

О том, как загрузить IIS Exception Monitor, рассказано в статье Microsoft «INFO: Troubleshooting Exceptions in Internet Server Products» (http://support.microsoft.com/support/kb/articles/q160/3/60.asp), где есть ссылка на страницу загрузки и документации. Я настоятельно рекомендую загрузить документацию — она поможет разобраться, как работает это приложение. В файле README, который входит в комплект поставки, тоже содержится полезная информация об этом продукте.

Процедура установки IIS Exception Monitor проста и занимает всего несколько минут. Для ее выполнения нужно запустить на сервере IIS программу ixcptmon.exe. через меню Programs. Исполняемый файл находится в каталоге, куда загружалась программа (по умолчанию — C:ixcptmon). После запуска программы дальнейшие действия подскажет мастер установки.

Запустив IIS Exception Monitor, нужно в первом диалоговом окне нажать на кнопку Next. Во втором диалоговом окне следует установить переключатель Yes, Verify the IIS symbols that I have installed, а затем опять нажать Next. В результате этих действий диспетчер исключений проверит систему и выяснит, какие символьные файлы необходимы. Эти файлы содержат данные, которые нужны диспетчеру для отладки процесса IIS, — они позволяют ему выявить источник ошибок.

Выяснив, какие символьные файлы требуются системе, диспетчер отобразит их список, показанный на Экране 3. Состав списка зависит от конкретной конфигурации. По окончании процедуры анализа системы следует установить флажок Determine which symbol packages can be installed from Microsoft’s Internet Site и нажать Next. В открывшемся диалоговом окне Download Symbols нужно выбрать первый символьный файл в списке и щелкнуть мышью на кнопке Download, а затем, чтобы загрузить файл, — на кнопке Next. Последовательно выполняя эту операцию, загрузите все нужные файлы (процедура может продолжаться несколько минут). Как только процесс загрузки файлов завершится, программа предложит установить их.

Чтобы начать сеанс IIS Exception Monitor, нужно снова запустить ixcptmon.exe. Если программа все еще работает после установки символьных файлов, стоит воспользоваться текущим сеансом. В случае повторного запуска в диалоговом окне Check Symbols следует установить переключатель No, I am confident that the symbols are installed correctly, а затем нажать кнопку Next.

В открывшемся диалоговом окне Process Options нужно указать тип процесса, который предстоит контролировать. Можно выбрать компонент, выполняющийся внутри процесса inetinfo.exe (переключатель In Process), приложение, которое должно исполняться в отдельном адресном пространстве (Out of Process), или любой другой процесс (Other Process). Установив переключатель In Process, нужно щелкнуть кнопкой Next, чтобы открыть диалоговое окно Session Options.

Параметры диалогового окна Session Options определяют, как будет работать IIS Exception Monitor. Предлагается два варианта: выбрать режим контроля в одном сеансе или рекурсивный режим Recursive Mode для мониторинга процессов до момента возникновения неполадок в работе сервера. Когда IIS Exception Monitor обнаружит ошибку в рекурсивном режиме, он сделает запись в протоколе, остановит и перезапустит процесс inetinfo.exe, а затем возобновит мониторинг. Если в этом отказоустойчивом режиме диспетчер выявит серьезную ошибку, он остановит IIS и перезагрузит сервер.

Включить рекурсивный режим можно двумя способами: установить в диалоговом окне Session Options флажок Enable Recursive Mode либо запустить сценарий ixcptmon.vbs с параметром командной строки /r. Этот же параметр позволяет отключить рекурсивный режим. В диалоговом окне Session Options также можно ввести адрес, по которому будут автоматически отправляться оповещения об ошибке (командой net send). Для этого в текстовом поле Notify Admin нужно ввести имя компьютера или пользователя. Если же в системе установлена и сконфигурирована библиотека Collaboration Data Objects (CDO), для оповещения можно использовать электронную почту. Имя компьютера или адрес электронной почты задается с помощью ключа командной строки /notify.

Переключатель Manual диалогового окна Session Options позволяет запустить диспетчер исключений в ручном режиме (например, для выполнения работ, связанных с сопровождением). Этот режим пригодится при работе со специалистом службы технической поддержки Microsoft — он позволит ему получить удаленный доступ к неисправному серверу и принять участие в решении проблемы.

Выбрав параметры в диалоговом окне Session Options, нужно щелкнуть мышью на кнопке Next, затем в открывшемся диалоговом окне Start Monitoring нажать Run This Monitoring Session. Когда IIS Exсeption Monitor запустит файл ixcptmon.vbs с соответствующими переключателями, начнется сеанс мониторинга. После загрузки сценария ixcptmon.vbs откроется окно сеанса командной строки. Не стоит его закрывать — оно необходимо для работы сценария. После запуска сеанса следует нажать кнопку Next, чтобы открыть окно Session Status. Это окно обеспечивает пользовательский интерфейс к процессу IIS Exception Monitor.

Из диалогового окна Session Status можно контролировать ход активного сеанса мониторинга или просматривать файлы журналов предыдущих сеансов. Как показано на Экране 4, нужно выбрать созданный диспетчером журнал, а затем открыть его, нажав кнопку View Log. Перед просмотром журнала процесс мониторинга следует остановить. Для остановки мониторинга, а также для остановки и перезапуска IIS нужно открыть окно командной строки диспетчера и нажать клавиши CRTL+C. После этого можно вновь запустить IIS Exception Monitor и приступать к просмотру журнала.

Кнопка View Log диалогового окна Session Status открывает изображенное на Экране 5 окно Log, которое предоставляет на выбор несколько вариантов просмотра информации о статусе сеанса протоколирования и IIS. Нужный вариант просмотра можно выбрать, нажимая кнопки окна.

Кроме того, диспетчер исключений может остановить процесс inetinfo.exe и перезапустить IIS. Эту операцию выполняет входящая в состав Microsoft Windows NT Server 4.0 Resource Kit программа kill.exe, которая при установке IIS Exception Monitor размещается в папке ixcptmonbin. Программу запускает сценарий ixcptmon.vbs. Остановить iteninfo.exe можно и вручную, командой kill -f inetinfo.exe.

Для поиска и анализа ошибок в работе IIS следует переместить подозрительное приложение в отдельное адресное пространство и заставить его работать в фоновом режиме. После этого можно смело тестировать приложение, не боясь, что оно повлияет на работу IIS. Кроме того, можно переконфигурировать пакеты MTS, придав им статус серверных пакетов (установив переключатель Server Packages). Затем с помощью IIS Exception Monitor остается определить, в каком из прикладных компонентов IIS возникает сбой.