Повышенная надежность

Как сделать так, чтобы Web-серверы Microsoft IIS работали стабильно и надежно? Как добиться, чтобы приложения объявляли о своей неспособности продолжать работу и автоматически перезапускались без вмешательства администратора? Могут ли клиенты загружать на сервер большое количество файлов, не занимая при этом всей полосы пропускания канала связи, а после сбоя возобновлять работу с прежнего места? Существуют ли Web-приложения, которые отвечают всем перечисленным требованиям и при этом занимают не более 50% ресурсов процессора? Администраторов, знакомых с IIS 5.0 и IIS 4.0, возможно, удивит, что IIS 6.0 приближается к этому идеалу.

Результаты Microsoft.com

В июне 2003 г. на конференции Microsoft TechEd в Далласе вместе с менеджером группы Microsoft.com Кейси Джейкобс мы проводили презентацию. Кейси представил ряд статистических данных о Microsoft.com, в настоящее время самом крупном сайте на базе IIS 6.0:

  • период работоспособности 99,8 % (по данным организации Keynote Systems, которая занимается испытаниями производительности Web-сайтов);
  • 950 серверов и три центра обработки данных;
  • 80 Internet-сайтов, обслуживающих 1000 баз данных Microsoft SQL Server и тысячи Web-приложений;
  • 25,5 млн. обращений к домашней странице в марте 2003 г.;
  • более 75 000 запросов в секунду;
  • более 300 000 одновременных пользователей;
  • 20 системных инженеров, 12 администраторов баз данных и 16 техников, обеспечивающих круглосуточное обслуживание без выходных.

Время безотказной работы, превышающее 99% на 950 серверах, обслуживаемых 20 системными инженерами, — впечатляющий результат, особенно если учесть, что эта информация исходит непосредственно от технических специалистов, а не из отдела маркетинга. Сотрудники Microsoft достигли таких показателей, работая со смешанным набором серверов IIS 6.0 и IIS 5.0.

Каким образом переход с Windows 2000 Server на Windows Server 2003 отразился на надежности Microsoft.com? Время непрерывной работы сети Microsoft Developer Network (MSDN) увеличилось на 100% (табл. 1). Некоторые случаи перезагрузки операционной системы были вызваны применением исправлений и пакетов обновлений, и компания Microsoft стремится еще больше сократить их число.

Надежность удалось повысить благодаря новым мощным функциям семейства серверов Windows 2003 и IIS 6.0.

Изоляция WWW Service Administration and Monitoring

Одним из важнейших изменений, оказавших непосредственное влияние на надежность, стало совершенствование внутренних механизмов IIS 6.0. Краткий обзор архитектуры IIS 5.0 может послужить материалом для сравнения. Первичный процесс IIS 5.0, который обеспечивает основные функции IIS — inetinfo.exe. Кроме того, в Inetinfo размещаются Web-приложения, запущенные в режиме Low (In Process) Application Protection из консоли Microsoft Management Console (MMC) Internet Information Services. Web-приложения можно запускать «вне процесса» (out of process), в среднем — объединенном (Medium-Pooled) или высоком — изолированном (High-Isolated) режиме; в этом случае они выполняются в процессе с именем dllhost.exe. На Inetinfo возлагаются и другие важные функции, в частности маршрутизация входящих запросов из Winsock в соответствующие внепроцессные Web-приложения и хостинг службы IIS Admin Service, которая обеспечивает связь с метабазой (хранилищем параметров настройки для Web-узлов IIS и каталогов). В результате задачи, связанные с настройкой конфигурации и внутренним администрированием Web-сервера, работают в одном процессе с Web-приложениями. Поэтому неудачно составленная программа может вызвать исключительную ситуацию (то есть сбой) или иным способом остановить Inetinfo и прервать работу всего Web-сервера, в том числе и внепроцессных приложений.

В IIS 6.0 компонент WWW Service Administration and Monitoring и Web-приложения работают в отдельных процессах, и вызывающее сбой или зависшее Web-приложение не приведет к краху WWW Service Administration and Monitoring. Такое разделение позволяет службе WWW Service Administration and Monitoring контролировать Web-сервер, поддерживать его в рабочем состоянии и даже перезапускать приложения, которые не отвечают на исходящие от компонента запросы «Are you live?».

Пулы приложений

Web-приложения IIS 6.0 работают в исполнительном процессе (worker process) с именем w3wp.exe, который заменяет Dllhost IIS 5.0 (и wam.exe IIS 4.0). Однако в IIS 6.0 можно дать исполнительному процессу имя и управлять им как элементом, называемым «пулом приложений» (application pool). Любому пулу приложений нетрудно сопоставить Web-узел, каталог или виртуальный каталог в диалоговом окне Properties данного элемента (экран 1).

Экран 1. Назначение Web-сайта пулу приложений

Следует помнить, что каждый пул приложений изолирован от других пулов, и если один пул откажет или будет остановлен и перезапущен, то это повлияет только на приложения данного пула; остальные пулы приложений будут по-прежнему доставлять контент. Эта особенность, вероятно, стала главной причиной повышения надежности IIS 6.0. Пулы приложений можно организовать в соответствии с требованиями конкретного предприятия. Например, можно сгруппировать надежно работающие приложения в один пул, оградив их от непредсказуемого поведения неустойчивых или непроверенных программ, изолированных в других пулах.

WWW Service Administration and Monitoring автоматически проверяет, реагирует ли пул приложений на запросы, через каждые 30 секунд (по умолчанию) или через интервал, задаваемый на вкладке Health диалогового окна Properties пула приложений. Если пул не отвечает, то WWW Service Administration and Monitoring перезапускает его без вмешательства администратора, что существенно повышает надежность. Кроме того, время цикла (останова и нового запуска) пула можно задать с помощью параметров на вкладке Recycling (экран 2). Например, по умолчанию время цикла пула приложений составляет 1740 минут (29 часов). На мой взгляд, не имеет никакого смысла принимать данное значение в качестве стандартного, поэтому я назначил рециркуляцию на определенное время суток, 3.00 утра по местному времени. Рециркуляция по графику удобна для приложений, требующих периодического перезапуска.

Экран 2. Настройка рециркуляции пула приложений

На вкладке Recycling можно контолировать потребление памяти исполнительным процессом и перезапустить приложение, если значение занятой памяти превышает заданный порог. Возможность автоматически перезапускать приложения, потребляющие слишком много ресурсов, может пригодиться при использовании большого количества IIS-серверов, работающих с приложениями, которые со временем необъяснимым образом начинают занимать очень много памяти. Более подробно механизм рециркуляции IIS 6.0 описан во врезке «Как происходит рециркуляция».

Формируя цикл пулов приложений, следует настроить IIS 6.0 на запись событий рециркуляции в Event Viewer. По умолчанию записываются только события рециркуляции, связанные с памятью и временем. В help-файлах IIS 6.0 приведены сведения о свойстве метабазы LogEventOnRecycle. Это свойство представляет собой битовую маску, в которой каждый разряд активизирует или блокирует запись определенного события. С помощью следующей команды можно активизировать запись всех событий:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs

set W3SVC/AppPools/LogEventOnRecycle

Приложения с самоконтролем

Возможность настроить пулы приложений на перезапуск по определенным событиям полезна, но лучше всего встроить проверки состояния непосредственно в приложение, чтобы при необходимости оно могло запросить рециркуляцию. В любом расширении IIS 6.0 Internet Server API (ISAPI), в том числе и составленном администратором, можно инициировать рециркуляцию приложения с помощью новой функции HSE_REQ_REPORT_UNHEALTHY. Проверки состояния можно вставлять непосредственно в расширения ISAPI, не полагаясь исключительно на сервер. Более подробная информация об этой функции приведена по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/iis/extensions_ssf_hse_req_report_unhealthy.asp.

В IIS 6.0 приложения Active Server Pages (ASP) и ASP.NET — самоконтролируемые; при определенных обстоятельствах они вызывают HSE_REQ_REPORT UNHEALTHY. Например, ASP отслеживает время, необходимое механизму сценариев ASP, чтобы обработать запрос. Если это время превышает величину ASP Script Timeout, заданную в консоли Internet Information Services, то IIS дает механизму команду прекратить выполнение сценария. Если механизм сценариев на эту команду не реагирует, то ASP оставляет поток. Внутренний счетчик ASP отслеживает число оставленных потоков. Когда оно достигает определенного значения, asp.dll запрашивает рециркуляцию.

Аффинность процессоров

Следует обратить внимание еще на одно свойство пулов приложений в многопроцессорных системах: аффинность процессоров (CPU affinity). Свойство аффинности позволяет назначить процессоры для Web-приложений и пригодится, если администратору нужно выделить процессор для определенного клиентского приложения. Чтобы установить аффинные отношения между пулом приложений и процессором, необходимо задать два свойства метабазы: SMPAffinitized и SMPProcessorAffinityMask.

С помощью свойства SMPAffinitized активизируется аффинность для пула приложений. В Adsutil это свойство можно установить следующей командой:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs

set W3SVC/AppPools/

ApplicationPoolName/

SMPAffinitized TRUE

где ApplicationPoolName — имя пула, с которым требуется установить аффинность. Если SMPAffinitized присвоено значение 0 (FALSE, с использованием Adsutil), то пул приложений может работать на любом процессоре.

Свойство SMPProcessorAffinityMask — битовая маска, представленная шестнадцатеричным числом, которая указывает процессор, выделяемый для пула. Если в машине имеется несколько процессоров, то пул может выполняться на нескольких из них. Следующая команда настраивает пул для работы на процессорах 0 и 2:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs

set W3SVC/AppPools/

ApplicationPoolName/

SMPProcessorAffinityMask 0x5

В главе 4 «Running IIS 6.0 as an Application Server» комплекта ресурсов Internet Information Services (IIS) 6.0 Resource Kit (http://www.microsoft.com/downloads/details.aspx?familyid=80a1b6e6-829e-49b7-8c02-333d9c148e69&displaylang=en) имеется таблица шестнадцатеричных значений для выбора процессоров.

Web-сады

В IIS 6.0 предусмотрен еще один способ взаимодействия с пулами приложений — в Web-садах (Web garden) можно определить пулы приложений, содержащие более одного исполнительного процесса. В такой конфигурации IIS 6.0 создает экземпляр w3wp.exe для каждого запроса (вплоть до числа исполнительных процессов в пуле). Например, если в пуле приложений имеется три исполнительных процесса, то на сервере будет работать три экземпляра w3wp, доставляющих одинаковый контент. Последующие соединения с исполнительными процессами в Web-саду устанавливаются по круговой системе. В Web-садах нет явной сеансовой привязки, но IIS 6.0 направляет весь трафик одного соединения в один исполнительный процесс. Исполнительный процесс хранит сеансовую информацию, секретный ключ Secure Sockets Layer (SSL) и данные для аутентификации до тех пор, пока соединение не будет разорвано или не будет перезапущен исполнительный процесс.

Web-сады не нашли широкого применения отчасти потому, что и без них производительность и надежность IIS 6.0 в целом хорошие или отличные, а отчасти потому, что администраторы не знают, какие приложения выгодно запускать в Web-садах. Я не смог найти реальных примеров применения Web-садов, которые принесли бы явную пользу приложениям. Тем не менее я приведу два теоретических примера.

Web-сад может быть полезен, если приложение использует компонент со встроенными ограничениями. Например, если объект связи с базой данных устанавливает лишь десять соединений, можно организовать n исполнительных процессов, которые обеспечат 10 * n-соединений.

Другой, более вероятный сценарий — блокирование приложения соединением базы данных. Приложение направляет запрос к базе данных, для выполнения которого требуется время. Поток (исполнительная единица для выполнения программного кода на центральном процессоре), сделавший запрос, оказывается связанным ожиданием результатов запроса и не может выполнять никаких других задач. Таким образом, число доступных рабочих потоков уменьшается на 1. Если запросы поступают быстрее, чем их может обработать база данных, то приложение испытывает «потоковое голодание». В таком случае Web-сад может быть полезен, так как каждый процесс в Web-саду располагает собственным выделенным пулом потоков.

ASP.NET также располагает Web-садом и свойством аффинности процессоров, которые заметно отличаются от реализации IIS 6.0. Параметры для этих функций можно найти в элементе processModel XML-файла machine.config, основного файла настройки приложений ASP.NET. Сервер IIS 6.0 полностью игнорирует параметры machine.config для Web-сада и аффинности процессоров; они используются лишь в IIS 5.x. Более подробную информацию об ASP.NET и IIS 6.0 можно найти в статье «How ASP.NET Works with IIS 6.0» (http://www.microsoft.com/technet/ treeview/default.asp?url=/technet/prodtechnol/iis/iis6/proddocs/ resguide/iisrg_arc_dkvi.asp).

Диспетчер системных ресурсов Windows

Если приложение потребляет слишком много системных ресурсов, то можно потерять все преимущества изоляции процессов, обеспечиваемые пулом приложений. Конечно, можно рециркулировать приложения, занимающие слишком много памяти, но не лучше ли указать максимальную емкость оперативной памяти, доступную приложению? Кроме того, с помощью слабых встроенных функций мониторинга процессора IIS 6.0 можно лишь отключать или включать приложение, которое потребляет много ресурсов процессора. Приложение IIS 6.0 работает в режиме пользователя, не имеет достаточных полномочий в режиме ядра и поэтому лишено возможности саморегуляции.

Для решения этой проблемы разработчики Microsoft выпустили новую службу Windows System Resource Manager (WSRM — диспетчер системных ресурсов). WSRM работает только с Windows 2003, Enterprise Edition и Windows 2003, Datacenter Edition, но управлять ею можно с любого сервера Windows 2003. После развертывания WSRM можно настроить процесс (вместе со службами), установив верхний предел потребляемой им памяти или ресурсов процессора. Кроме того, можно выделить приложения, имеющие высокий уровень доступа к определенным процессорам, и предоставить ресурсы оставшихся процессоров другим процессам и службам — не используя функцию процессорной аффинности IIS 6.0. Среди прочих встроенных функций WSRM следует назвать протоколирование, мониторинг производительности, возможность вводить ограничения по дате и времени, исключать и добавлять пользователей. WSRM — лучшее средство для надежного распределения ресурсов памяти и процессоров на сервере. Более подробная информация о WSRM приведена по адресу http://www.microsoft.com/windowsserver2003/ downloads/wsrm.msp.

BITS

Очень мало известна новая функция Background Intelligent Transfer Service (BITS — служба фоновой интеллектуальной пересылки); я называю ее службой «сбора по капле». BITS позволит не только повеселиться, наблюдая за недоумением на лицах коллег, когда они услышат выражение dribble service, но и поможет сэкономить ресурсы канала связи, повысив отказоустойчивость при работе с высокими нагрузками.

После установки BITS управляет загрузкой и получением данных с сервера, используя избыточные ресурсы для доставки контента клиенту. BITS также отслеживает запрошенные операции по загрузке данных, ставит в очередь и позволяет возобновить выполнение запросов. Как показано на экране 3, администратор может настроить несколько параметров, в том числе максимальный размер файла и частоту очистки очереди от незавершенных заданий, а также активизировать или отключить ограниченную поддержку серверных ферм. Клиентское окно, показывающее состояние загрузки, будет знакомо пользователям, которым приходилось загружать большие файлы из сети MSDN.

Экран 3. Настройка BITS

Служба BITS не устанавливается по умолчанию вместе с IIS. Чтобы развернуть BITS на серверах Windows 2003, нужно открыть панель управления и выбрать функцию Add/Remove Programs, Windows Components, Application Server, Internet Information Services (IIS), Background Intelligent Transfer Service Server Extensions. Загрузить версию BITS, которая работает с Windows 2000 Server и IIS 5.0, можно по адресу http://www.microsoft.com/downloads/details.aspx?familyid=17967848-be86-4cd6-891c-ec8241611ad4&displaylang=en.

В help-файлах содержатся важные сведения о безопасности и BITS-совместимых виртуальных каталогах. BITS обходит параметры безопасности IIS 6.0 и позволяет загружать файлы в папку с отключенным в IIS разрешением Write. Обычные разрешения безопасности NTFS соблюдаются. В качестве приложения к BITS можно получить комплекс инструментальных средств для разработки программ (SDK), который находится по адресу http://www.microsoft.com/downloads/details.aspx?familyid=ad9fb937-62f9-4b9f-993b-f754f968b8a6&displaylang=en. Благодаря совместимости с SSL, полной программируемости, использованию NTFS и процедур аутентификации Windows, BITS может оказаться столь необходимой заменой FTP для публикации файлов на IIS-сервере без использования Microsoft FrontPage Server Extensions.

Новый уровень надежности

Таким образом, IIS 6.0 обеспечивает:

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

Благодаря этим и другим возможностям, о которых не было рассказано в данной статье из-за недостатка места (например, политиках качества обслуживания — QoS, накладывающих ограничения на ресурсы канала связи, выделяемые IIS), сервер IIS 6.0 гораздо надежнее любой предшествующей версии IIS. А если учесть повышенную производительность и безопасность IIS 6.0 и единодушно положительные отзывы всех знакомых мне специалистов, которые развертывали IIS 6.0, то у предприятий есть веские причины для перехода на новейшую версию Web-сервера.

Как происходит рециркуляция

Для рециркуляции исполнительных процессов в IIS 6.0 используется метод, называемый перекрывающимся циклом (overlapping recycling). Коротко всю процедуру можно представить следующим образом.

  • Исполнительный процесс отмечается как предназначенный для рециркуляции службой WWW Service Administration and Monitoring или по запросу приложения.
  • IIS 6.0 создает другой исполнительный процесс для замены избранного для рециркуляции. В этот момент оба исполнительных процесса находятся в памяти и могут быть активными одновременно.
  • Новые запросы посылаются в новый исполнительный процесс, а отмеченный для уничтожения процесс продолжает (если может) обслуживать запросы в своей очереди.
  • После того как очередь запросов старого процесса иссякнет или наступит тайм-аут (если исполнительный процесс не отвечает), IIS 6.0 уничтожает исполнительный процесс. IIS 6.0 сохраняет исполнительный процесс для диагностики лишь в тех случаях, когда установлен параметр метабазы OrphanWorkerProcess.

Параметр OrphanWorkerProcess очень полезен для отладки исполнительных процессов в производственных условиях. Более подробную информацию об этом параметре можно найти в help-файлах IIS 6.0.

Бретт Хилл — организатор узла http://www.iistraining.com, консультант по Microsoft IIS, IIS MVP; автор и преподаватель курсов IIS. С ним можно связаться по адресу: brett@iisanswers.com