Администраторам, уже использующим технологии IIS, наверняка будет интересно познакомиться с новшествами IIS 6.0. В одной статье невозможно рассказать о многочисленных отличиях Microsoft Internet Information Services (IIS) 6.0 от прежних версий продукта, поэтому в первой части я расскажу об установке, архитектуре и новых функциях сервера, реализованных благодаря архитектурным изменениям. В следующей статье речь пойдет о новых возможностях, в том числе малоизвестных, а также о важных изменениях стандартных параметров, влияющих на процедуру миграции.
Установка IIS 6.0
Microsoft поставляет IIS 6.0 вместе с четырьмя версиями Windows Server 2003: Windows 2003, Datacenter Edition; Windows 2003, Enterprise Edition; Windows 2003, Standard Edition и Windows 2003, Web Edition. Версия IIS 6.0 не будет поставляться в составе Windows XP, Windows 2000 или Windows NT.
Новшества Windows 2003/IIS 6.0 дают о себе знать сразу после установки Windows 2003. Одно из важнейших отличий заключается в том, что IIS не устанавливается по умолчанию ни в одной версии Windows 2003, за исключением Windows 2003 Web Edition. Таким образом, компания отказывается от развертывания операционной системы вместе со службой IIS, активированной для многих Web-приложений. Установить IIS можно одним из трех способов: с помощью мастера Manage Your Server Wizard, с использованием утилиты панели управления Add/Remove Windows Components или выполнив автоматическую процедуру без участия оператора.
Мастер Manage Your Server Wizard запускается немедленно после начальной загрузки системы Windows 2003. Выбрав функцию Add or remove a role, можно увидеть несколько вариантов ролей, в том числе Web Application Server (IIS), как показано на Экране 1.
|
| Экран 1. Добавление серверной роли. |
Более интересный метод — использование утилиты Add/Remove Windows Components. Если выбрать Application Server и щелкнуть на кнопке Details, то утилита Add/Remove Windows Components отображает список компонентов, в который входят Internet Information Services и несколько элементов, отсутствовавших в предыдущих версиях утилиты. В Таблице 1 приведены сравнительные данные о Web-компонентах IIS 6.0 и IIS 5.0. Если установить IIS 6.0 с помощью этой утилиты, то в результате будет построен Web-сервер, который предоставляет только статический контент (если в процессе установки не были активированы приложения с определенными расширениями). Если выбрать IIS и щелкнуть на кнопке Details, то будут показаны элементы IIS 6.0 (см. Экран 2).
|
| Экран 2. Элементы IIS. |
В Таблице 1 обращают на себя внимание некоторые новые компоненты, но хочется вспомнить и те компоненты, которых там нет. Один из важных отсутствующих компонентов — Documentation. Вся документация
IIS 6.0 целиком заключена в Help-файле, и администраторам не нужно управлять виртуальным каталогом IISHelp. В IIS 5.0 Default Web Site автоматически открывал документацию IIS при локальном обращении к серверу. В IIS 6.0 при вводе команды
http://localhost
отображается экран Under Construction.
Кроме того, в виртуальном каталоге IISHelp версии IIS 5.0 содержатся страницы обработки ошибок, построенные на базе Active Server Pages (ASP). Если в IISHelp размещены специализированные или измененные справочные файлы, то необходимо создать такой каталог и на Web-узлах IIS 6.0.
Если внимательно взглянуть на элементы IIS 6.0, станет ясно, что отсутствует диспетчер Internet Services Manager (ISM), известный также как Administration Web Site, создаваемый по умолчанию в IIS 5.0 и IIS 4.0. Но если щелкнуть на World Wide Web Service (один из элементов IIS 6.0, не показанный на Экране 2), а затем на кнопке Details, то можно увидеть, что в World Wide Web Service версии IIS 6.0 присутствуют элементы, показанные на Экране 3.
|
| Экран 3. Элементы World Wide Web Service. |
Последний способ установки IIS 6.0 — с использованием автоматической процедуры без участия оператора. Это по-прежнему единственный метод, позволяющий расположить контент сайтов Administration и Default Web Site на каком-либо диске, кроме системного. В Windows 2003 и Windows 2000 используется один и тот же способ выбора компонентов для развертывания с помощью утилиты Sysocmgr и файла ответов. Конечно, для новых функций нужны другие ключи. Список ключей для Windows 2003 Release Candidate 2 (RC2) можно найти по адресу: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/ datacenter/gs_installingiis.asp.
При замене сервера IIS 5.0 или IIS 4.0 на Windows 2003 версия IIS 6.0 автоматически не запускается. По умолчанию, после модернизации IIS 6.0 не активизирован, за исключением следующих ситуаций:
- если на предшествующем экземпляре IIS была запущена утилита Microsoft IIS Lockdown;
- если в реестре имеется раздел HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesW3SVCRetainW3SVCStatus, содержащий подраздел с любым параметром. Например, можно создать параметр с именем EnableIIS6 и присвоить ему значение первого типа DWORD;
- в процессе автоматической модернизации в разделе [InternetServer] файла ответов содержится элемент DisableWebServiceOnUpgrade = True/False.
Вспомогательные службы
Некоторые функции IIS очень часто упоминаются при описании IIS 6.0, но малоизвестные вспомогательные Internet-службы тоже заслуживают внимания. Как ни странно, я обнаружил среди них POP3 Service и POP3 Service Web Administration. Неясно, почему служба POP3 не входит в список элементов Application Server или в состав консоли Internet Information Services — многие администраторы хотели бы иметь в своем распоряжении эту службу как логическое продолжение SMTP (которая поставляется вместе со службой POP3) и в качестве альтернативы громоздкому приложению Microsoft Exchange Server.
Служба Universal Description, Discovery and Integration (UDDI) Services — еще один новый вспомогательный компонент Windows 2003, связанный с IIS и не устанавливаемый по умолчанию (следует помнить, что UDDI Services нельзя установить на Windows 2003 Web Edition). UDDI — отраслевой стандарт (т. е. не продукт Microsoft). С помощью этого компонента можно объявить о Web-службе, реализованной на IIS-сервере. «Объявить» — значит сообщить клиенту (как правило, браузеру) подробные сведения, необходимые для использования Web-службы (обычно приложения ASP.NET). Пока UDDI — незрелый стандарт, но в некоторых компаниях его применяют для внутренних нужд, как средство обмена исходными текстами между программистами. Более подробную информацию об UDDI можно найти по адресам: http://www.uddi.org и http://www.uddicentral.com.
Последний вспомогательный компонент — новая служба Background Intelligent Transfer Service (BITS). Благодаря ей сервер может принимать и передавать данные малыми порциями. Если 100 пользователей попытаются одновременно загрузить файл на 500 Мбайт, то в отсутствии BITS нагрузка на каналы связи резко возрастет, что может привести к задержке работы других сеансов на сервере. Благодаря BITS для передачи файлов используются избыточные ресурсы, а не вся полоса пропускания канала связи. Если служба будет работать так, как обещают разработчики, она будет очень полезной. Кроме того, после выпуска Windows 2003, BITS будет доступна для пользователей Windows 2000. Подробнее о службе BITS рассказано по адресу: http://www.microsoft.com/windows.netserver/techinfo/ overview/bits.mspx.
Закладка фундамента
IIS 5.0 и IIS 4.0 построены на базе одной и той же программной архитектуры: это приложения, которые работают в режиме пользователя и предоставляются Web-приложениям под учетной записью System в процессе Inetinfo или как пользователь IWAM вне процесса Inetinfo. IIS 5.0 хорошо справляется с нагрузкой, но требования к Web-серверам изменились. Чтобы увеличить число Web-узлов, поддерживаемых IIS, с 1000 до более чем 10 000, одновременно повысив безопасность и надежность, разработчикам Microsoft пришлось полностью заменить прежнее ядро.
Еще одна причина закладки нового фундамента для IIS заключается в том, что, по мнению поставщиков, плохо спроектированные приложения — главный источник проблем производительности и надежности Web-серверов. В IIS 5.0 эти недостатки были не столь заметны благодаря контейнеру объединенных изолированных процессов (Pooled Out of Process) для Web-приложений. Отказавшее приложение, выполняемое в пуле Out of Process, не обязательно приводит к краху IIS 5.0, так как работает в процессе, отличном от Inetinfo, но выполнение всех Web-приложений в пуле Out of Process будет остановлено, а в этом пуле по умолчанию работают все приложения. Проводить диагностику в такой ситуации затруднительно, так как сложно определить, какое приложение вызвало отказ. В новой архитектуре IIS 6.0 подобные проблемы решаются посредством локализации задач приема запросов, создания и мониторинга Web-узлов, выполнения Web-приложений. Теоретически новая архитектура обеспечивает более высокий уровень отказоустойчивости, безопасности и производительности. На практике же, как сообщают специалисты Microsoft и участники бета-тестирования, удалось резко повысить стабильность и производительность. В основе архитектуры IIS 6.0 лежит три новых компонента: W3SVC, http.sys и W3Core.
W3SVC. Это, вероятно, самый малоизвестный, но тем не менее важный компонент архитектуры IIS 6.0 — он создает и контролирует рабочие процессы (в которых выполняются приложения Web-узла) в соответствии с параметрами метабазы. Ближайший родственник компонента W3SVC в IIS 5.0 — служба IIS Administration Service, которая представляет собой часть Inetinfo; следовательно, если Inetinfo отказывает, то IIS Administration Service также не может перезапустить Inetinfo и другие приложения. В IIS 6.0 компонент W3SVC работает как независимый процесс, которому не угрожает отказ Web-приложений, так как в W3SVC не исполняются никакие программы независимых поставщиков. Процесс W3SVC всегда активен, поэтому он осуществляет мониторинг готовности Web-приложений и выполняет соответствующие действия. Благодаря такому подходу сервер контролирует и перезапускает приложения в соответствии с назначенными администратором параметрами.
Http.sys. Наиболее радикальное изменение в архитектуре IIS 6.0 — появление драйвера http.sys, который обрабатывает запросы HTTP и функционирует в режиме ядра. Перенос обработки запросов HTTP из пользовательского режима IIS 5.0 и IIS 4.0 в ядро IIS 6.0 знаменует появление нового поколения серверов IIS.
В Windows 2000 и NT 4.0 служба IIS работает в пользовательском режиме вместе с прикладными программами. Приложения, выполняемые в пользовательском режиме, не могут напрямую обращаться к аппаратным средствам, а вызывают стандартные процедуры передачи данных или функции компонентов ядра (например, драйверов, сетевых адаптеров, графических подсистем), чтобы выполнить такие операции, как сохранение файла, назначение IP-адреса или пересылка HTML-файла по сети.
Переходы между пользовательским режимом и режимом ядра отрицательно влияют на производительность. Серверы Microsoft передают входящий запрос HTTP из стека TCP/IP в ядре в процесс Winsock, выполняемый в пользовательском режиме, который затем передает запрос в IIS. Переход от режима ядра к пользовательскому режиму происходит быстро, но вносит в процедуру моментальную задержку. При работе с интенсивной нагрузкой малые задержки могут накапливаться, и, поскольку такие переходы — обязательный элемент процесса, устранить их нельзя.
Благодаря функционирующему в режиме ядра драйверу http.sys, разработчикам IIS 6.0 удалось существенно сократить число переключений между режимами. Http.sys принимает запросы HTTP и определяет, какой процесс пользовательского режима должен обрабатывать этот запрос, или самостоятельно доставляет запрошенный контент.
IIS 6.0, работающий в пользовательском режиме, целиком зависит от http.sys как от механизма приема пользовательских запросов. Следовательно, драйвер должен быть надежным и быстро реагировать на события. Поэтому драйвер не выполняет никакого пользовательского кода, который мог бы вызвать его сбой. В результате зависшее приложение не помешает IIS 6.0 принимать запросы HTTP.
Быстродействующий обработчик запросов HTTP, функционирующий в режиме ядра и не предназначенный для выполнения приложений, — идеальное средство обслуживания запросов на статический и неизменный контент прямо из кэша ядра. Благодаря такой организации, сокращается число затратных переключений в пользовательский режим, а ответы из кэша ядра выдаются быстро. Драйвер http.sys управляет кэшем и использует усовершенствованные эвристические алгоритмы кэширования для отбора сохраняемой в кэше информации. Например, чтобы контент был направлен в кэш, http.sys должен получить несколько запросов на данный материал.
Поскольку статический контент доставляется из кэша без переключения в пользовательский режим, общая производительность IIS 6.0, по сравнению с IIS 5.0, существенно возрастает. На презентациях Microsoft были предъявлены результаты эталонных тестов WebBench, на которых IIS 6.0 доставлял статический контент на 150% быстрее, чем IIS 5.0. Даже если запустить сервер IIS 6.0 в изолированном режиме IIS 5.0 (в котором архитектура IIS 6.0 имитирует IIS 5.0), производительность повышается благодаря кэшу и другим новым возможностям драйвера http.sys.
Кроме того, оптимизированный драйвер http.sys направляет запросы непосредственно в нужные рабочие процессы. В IIS 5.0 и IIS 4.0 применялась многоэтапная процедура, позволявшая определять, какой экземпляр процесса содержит Web-приложение, которому следует передать запрос. Http.sys регистрирует все приложения IIS 6.0 и назначает каждому из них дескриптор. С помощью этого дескриптора IIS идентифицирует одно или несколько пространств имен, которые используются зарегистрированным приложением. Таким образом, получив запрос HTTP, http.sys быстро направляет запрос из режима ядра конкретному Web-приложению, функционирующему в пользовательском режиме.
Функция приема запросов http.sys выполняет и некоторые другие задачи, в том числе:
- проверяет длину и структуру поступающих адресов URL на соответствие правилам;
- управляет очередями входящих запросов;
- выполняет задачи, связанные с регистрацией на Web-узлах IIS (для ускорения регистрации);
- накладывает ограничения на использование канала связи и обеспечивает возможность управления на уровне TCP/IP;
- обслуживает клиентские запросы сертификатов (но не Secure Sockets Layer, SSL).
Http.sys — не компонент IIS, а драйвер операционной системы, поэтому для его настройки используется не метабаза IIS, а параметры реестра. В настоящее время многие параметры реестра недокументированы. Пробелы в документации говорят о том, что разработчики стремятся препятствовать изменению параметров пользователями. Параметры реестра для драйвера http.sys находятся в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesHTTP, который можно дополнить параметрами (они отсутствуют по умолчанию), в том числе:
- EnableNonUTF8 — если добавить этот параметр и присвоить ему значение 0, то http.sys будет принимать только URL в формате Universal Character Set (UCS) Transformation Format 8 (UTF-8). UTF-8 — стандарт (описание можно найти по адресу: http://www.ietf.org/rfc/rfc2279.txt) для работы с символами иностранных языков. По умолчанию, значение EnableNonUTF8 равно 1, и IIS принимает URL в форматах UTF-8, ANSI и DBCS (double-byte character set — двухбайтовый набор символов);
- PercentUAllowed — если значение этого параметра равно 1 (по умолчанию), то http.sys принимает URL, содержащие символы в системе обозначений %uNNNN (NNNN — набор цифр, указывающий на нужный символ). Если PercentUAllowed равен 0, то IIS 6.0 не принимает URL с символами, представленными в данной форме.
Форма %uNNNN системы Unicode используется редко. Не следует путать ее с более распространенной формой UTF-8, в которой %20 представляет пробел (таким образом, записи http://www.iisanswers.com/new article.htm и http://www.iisanswers.com/new%20article.htm равнозначны). Microsoft Internet Explorer (IE) автоматически выполняет преобразования UTF-8, и IIS 6.0 принимает URL независимо от значений параметров EnableNonUTF8 и PercentUAllowed.
Эти два параметра для http.sys и другие, перечисленные в документации IIS 6.0, отражают прогресс в методах интерпретации URL сервером IIS 6.0. Часть наиболее серьезных проблем безопасности IIS 5.0 связана с методами разбора URL. Разработчики Microsoft устранили уязвимые места и внесли усовершенствования, благодаря которым администратор может более четко указать правила, используемые IIS 6.0 для декодирования URL. Эти улучшения особенно важны для тех частей Internet, в которых широко представлены различные языки.
Более подробную информацию о Unicode можно найти на сайте http://www.unicode.org. Подробнее об уязвимых местах IIS 5.0 можно прочитать по адресу: http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm. В наборе ресурсов Microsoft Windows Server 2003 Resource Kit есть утилита для настройки http.sys.
W3Core (пул приложений). По умолчанию, IIS 6.0 выполняется в изолированном рабочем процессе (см. Экран 4). В этом режиме IIS 6.0 использует отдельный экземпляр w3wp.exe, также называемый исполнительным процессом (worker process) или W3Core, для запуска каждого Web-приложения. Следовательно, в изолированном исполнительном процессе внутрипроцессных приложений не существует. В результате повышаются надежность и безопасность. Надежность повышается, так как Web-приложения не создают помех друг другу, не могут вызывать сбой http.sys, а их состояние независимо контролируется процессом W3SVC. Безопасность повышается благодаря тому, что приложения не выполняются с учетной записью System, как внутрипроцессные приложения IIS 5.0 и IIS 4.0. По умолчанию, все экземпляры w3wp.exe выполняются с учетной записью Network Service с ограниченными полномочиями (см. Экран 5).
|
| Экран 5. Выбор учетной записи для пула приложений. |
В случае успешной атаки с переполнением буфера, направленной против Web-приложения, взломщик получает доступ лишь к ресурсам пораженного исполнительного процесса (по умолчанию, с учетной записью Network Service). Учетная запись Network Service не имеет полномочия Write в папке Inetpub или права Execute в большинстве подпапок System32, поэтому, например, «червю» CodeRed было бы некуда распространяться.
Некоторые Web-приложения, в особенности фильтры Internet Server API (ISAPI), могут вызвать проблемы, работая вне процесса. Фильтры ISAPI серверов IIS 5.0 и IIS 4.0 всегда выполняются внутри Inetinfo, поэтому они не проектировались для работы вне процесса. Следовательно, некоторые фильтры при работе в изолированном режиме исполнительного процесса IIS 6.0 откажут — в частности, фильтры, вызывающие SF_READ_RAW_DATA или SF_SEND_RAW_DATA. В версии IIS 6.0 реализован второй режим функционирования, именуемый изолированным режимом IIS 5.0. Фильтры ISAPI, которые плохо работают в изолированном режиме исполнительного процесса, должны корректно выполняться в изолированном режиме IIS 5.0. При этом сохранятся многочисленные преимущества IIS 6.0, в том числе быстродействие и уровень готовности, обеспечиваемые драйвером http.sys.
Нередко упоминают и о пулах приложений (application pools) IIS 6.0. Пул приложений — именованный исполнительный процесс (или группа процессов). В IIS 5.0 можно назначить низкий (Low — IIS Process), средний — объединенный (Medium — Pooled) или высокий — изолированный (High — Isolated) — уровень защиты приложений. Эти меры полезны, но что делать, если нужно запустить два приложения в одном пуле (экземпляр dllhost.exe) и два приложения в другом пуле (другой экземпляр dllhost.exe)? В IIS 5.0 нет способа присвоить имена экземплярам dllhost.exe и связать приложения с назначенными именами. Благодаря пулам приложений IIS 6.0, администратор может дать исполнительному процессу имя (см. Экран 6) и связать Web-узлы или каталоги с этим пулом (см. Экран 7).
|
| Экран 6. Именование пула приложений. |
|
| Экран 7. Назначение ресурсов серверу. |
Работа с пулами
Мы познакомились с ключевыми архитектурными компонентами IIS 6.0, и настало время рассказать о возможностях пулов приложений. В диалоговом окне Properties пула приложений имеется четыре вкладки — Recycling, Performance, Health и Identity (см. Экран 5). Вероятно, самая важная из них — вкладка Recycling. Из нее можно управлять циклом пула приложений (останавливать или запускать) с помощью W3SVC, в зависимости от времени (в минутах), прошедшего после запуска процесса, числа запросов get, времени суток или размера занятой памяти. По умолчанию цикл пула приложений составляет 1740 мин (29 ч).
W3SVC определяет состояние пула отчасти на основе параметров на вкладке Health, среди которых — Ping worker process every (frequency in seconds) (ping-тестирование рабочего процесса через каждые «число секунд»), Worker process must startup within (time in seconds) («Рабочий процесс должен быть запущен через «время в секундах») и Worker process must shutdown within (time in seconds) («Рабочий процесс должен быть завершен через «время в секундах»). Кроме того, приложения ISAPI (в том числе ASP.NET и asp.dll) могут объявить о своей неготовности к работе и потребовать перезапуска.
По умолчанию, при управлении циклом пула IIS 6.0 использует метод, именуемый перекрывающимся циклом (overlapped recycle). В этом режиме сбившийся рабочий процесс продолжает работу и запускается новый процесс. IIS 6.0 направляет новые запросы в новый рабочий процесс, но не уничтожает старый до тех пор, пока старый процесс обслуживает запросы в своей очереди или не наступит тайм-аут. Соединения TCP/IP не теряются, так как их поддерживает http.sys. После тайм-аута сбившегося рабочего процесса следующий запрос к новому процессу будет новым, и сеансовая информация, хранившаяся в процессе, теряется. Все эти операции происходят без участия администратора и, во многих случаях, без очевидного сбоя в работе службы. Если присвоить свойству метабазы LogEventOnRecycle значение True (1), то W3SVC может сделать в журнале событий запись о смене цикла.
Перекрывающиеся циклы могут вызвать проблемы с приложениями, которые нельзя запустить в нескольких экземплярах. В этом случае следует присвоить элементу метабазы DissallowOverlappingRotation значение True (1), чтобы отключить перекрытие для пула приложений. Иногда полезно не уничтожать сбившийся рабочий процесс, а сохранить его для углубленной диагностики. Для этого нужно присвоить значение True (1) элементу OrphanWorkerProcess метабазы рабочего процесса. Можно также присвоить свойству метабазы OrphanActionExe имя исполняемого файла, чтобы программа продолжала работать после того, как рабочий процесс останется не у дел.
Еще одна функция, связанная с пулами приложений, — возможность превратить пул приложений, в Web-сад (Web garden). Web-сад можно представить себе как сервер IIS 5.0 с тремя Web-узлами, на каждом из которых размещено одно и то же приложение. Если IIS 5.0 может автоматически поочередно посылать трафик в каждый из этих идентичных, но раздельных Web-узлов, распределяя нагрузку между тремя различными процессами, то образуется маленькая Web-ферма (Web farm), отсюда термин «Web-сад».
В Web-саду IIS 6.0 не требуется строить дополнительные Web-узлы, достаточно указать число рабочих процессов, которые следует использовать в пуле приложений. Для этого нужно открыть диалоговое окно Properties пула приложений, перейти к вкладке Performance, щелкнуть на функции Web Garden и ввести число в поле Maximum number of worker processes («Максимальное число исполнительных процессов»). Если из-за недогруженности сервера дополнительные исполнительные процессы не используются, то IIS 6.0 уничтожает их по истечении указанного администратором периода (по умолчанию, 20 мин). Когда они понадобятся снова, IIS 6.0 создаст исполнительный процесс. Все эти операции производятся автоматически.
Пулы приложений (в том числе и Web-сады) обеспечивают еще одну новую возможность. С помощью двух новых свойств метабазы, SMPAffinitze и SMPAffinitzeCPUMask, можно связать пул приложений с центральным процессором, чтобы оптимизировать использование ресурсов процессора Web-приложениями.
Во второй части статьи я расскажу о других новшествах, многие из которых давно ожидаются администраторами.
Брет Хилл — консультант, преподаватель технических курсов. Имеет сертификаты MCSE, MCT, MCP+Internet и A+/Network+. Поддерживает сайт http://www.IISAnswers.com. С ним можно связаться по электронной почте по адресу: brett@iisanswers.com.