Web-сервер, на який можна покластися

1. підвищена надійність Як зробити так, щоб Web-сервери Microsoft IIS працювали стабільно і надійно?...
2. Ізоляція WWW Service Administration and Monitoring
3. пули додатків
4. Додатки з самоконтролем
5. афінність процесорів
6. Web-сади
7. Диспетчер системних ресурсів Windows
8. BITS
9. Новий рівень надійності
10. Як відбувається рециркуляція

підвищена надійність

Як зробити так, щоб 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).

Слід пам'ятати, що кожен пул додатків ізольований від інших пулів, і якщо один пул відмовить або буде зупинений і перезапущений, то це вплине тільки на додатки даного пулу; інші пули додатків будуть як і раніше доставляти контент. Ця особливість, ймовірно, стала головною причиною підвищення надійності IIS 6.0. Пули додатків можна організувати відповідно до вимог конкретного підприємства. Наприклад, можна згрупувати надійно працюючі додатки в один пул, захистивши їх від непередбачуваної поведінки нестійких або неперевірених програм, ізольованих в інших пулах.

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

На вкладці 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 .

Бретт Хілл - організатор вузла http://www.iistraining.com , Консультант по Microsoft IIS, IIS MVP; автор і викладач курсів IIS. З ним можна зв'язатися за адресою: [email protected]