Роль сервера додатків

Сервер додатків – нова роль сервера в сімействі продуктів Windows
Server 2003, яка поєднує в собі наступні серверні технології:

Сервер додатків дозволяє розробникам Web-додатків і
адміністраторам здійснювати хостинг динамічних додатків, наприклад
керованих базою даних додатків Microsoft ASP.NET, не встановлюючи
на сервері додаткове програмне забезпечення.

Налаштування сервера додатків

У Windows Server 2003 сервер додатків можна налаштувати двома
способами: через майстер Configure Your Server або з додатку
Add/Remove Components.

Майстер Configure Your Server

Майстер Configure Your Server (CYS) – основний засіб
конфігурування ролей Windows Server 2003 – тепер підтримує і роль
сервера додатків. Для доступу до цього майстра клацніть Add or Remove
Roles на сторінці Manage Your Server. Ця роль замінює існуючу
роль Web-сервера. Після встановлення нової ролі сторінка Manage Your Server
буде містити відповідний елемент.

Додаток Add / Remove Components

Сервер додатків також доступний через додаток Windows Server
2003 Add / Remove Components як необов'язковий компонент верхнього рівня.
За допомогою Add / Remove Components можна встановити серверні додатки,
пов'язані з сервера додатків (IIS 6.0, ASP.NET, COM + і MSMQ). Точно
так само встановлюються їх субкомпоненту. Застосування Add / Remove
Components для настройки сервера додатків забезпечує більш тонкий
контроль за встановленими субкомпоненту.

Нова архітектура обробки запитів в IIS 6.0

Складність коду Web-сайтів та програм постійно зростає.
Динамічні Web-сайти і додатки можуть містити неідеальний код,
призводить до витоку пам'яті чи викликає помилки на зразок порушення
доступу до пам'яті. Таким чином, Web-сервер повинен виконувати роль
активного диспетчера середовища виконання програми, автоматично
визначаючи помилки програми та реагуючи на них. Сервер повинен бути
стійким до помилок у додатку, здатним перезапустити збійні
додаток, продовжуючи накопичувати в черзі запити до нього і не
перешкоджаючи роботі кінцевого користувача. IIS 6.0 відрізняється новою
отказоустойчивой архітектурою обробки запитів, яка надає
стабільну виконуючу середу з активним управлінням, а також кардинально
підвищує надійність і масштабованість завдяки застосуванню нової моделі
ізоляції процесу (звану моделлю ізоляції робочого процесу) у
поєднанні з такими вдосконаленнями, як підтримка кешування і
черг в режимі ядра, що призводить до збільшення продуктивності.

У попередній версії IIS (IIS 5.0) один процес, Inetinfo.exe,
виконував функції головного процесу Web-сервера. Він перенаправляли запити
до "внепроцессним" додаткам, розміщеним у процесах DLLHost.exe. IIS
6.0, навпаки, складається з двох нових компонентів: стека HTTP режиму ядра
(HTTP.sys) і компоненту режиму користувача, призначеного для
адміністрування та моніторингу. Така архітектура дозволяє IIS 6.0
відокремлювати операції Web-сервера від виконання коду Web-сайту і додатки
без погіршення продуктивності. Нижче ці два компоненти
отказоустойчивой архітектури IIS 6.0 описуються докладніше.

Перш ніж перейти до обговорення цих компонентів, важливо розглянути
дві нові концепції IIS 6.0: пули додатків (application pools) і
робочі процеси (worker processes).

Пули додатків застосовуються для керування набором Web-сайтів
і додатків. Кожен пул додатка відповідає однієї черги запитів
в HTTP.sys та одного чи більше Windows-процесам, що обробляють ці
запити. IIS 6.0 підтримує до 2 000 пулів додатків на сервер, і
одноразово можуть працювати кілька таких пулів. Наприклад, сервер
відділу (departmental server) може виконувати додаток для обліку кадрів
в одному пулі і бухгалтерське додаток – в іншому. Інтернет-провайдер
(Internet Service Provider, ISP) може запускати Web-сайти і додатки
одного клієнта в одному пулі додатків, а Web-сайти другого клієнта – в
одним. Пули додатків відокремлюються один від одного кордонами процесів в
Windows Server 2003. Таким чином, додатки в одному пулі не впливають на
додатки в іншому, крім того, запити до додатків не можна
перенаправляти з одного пулу в інший при обслуговуванні поточних пулом.
Додатки можна закріплювати за одним пулом під час роботи сервера.

Робочий процес обслуговує запити до Web-сайтів і додатків
в пулі. Вся обробка Web-додатків, в тому числі завантаження
ISAPI-фільтрів і розширень, а також аутентифікація і авторизація,
виконується нової DLL сервісу WWW, що завантажується в один або кілька
робочих хост-процесів. Виконуваний файл робочого процесу називається
W3wp.exe.

HTTP.sys

HTTP.sys в IIS 6.0 приймає запити і поміщає їх в черзі. Кожна
чергу запитів відповідає одному пулу додатків. Так як HTTP.sys
не виконує код додатків, на нього не впливають помилки в коді
користувацького режиму, зазвичай порушують нормальну роботу
Web-сервера. У випадку помилки в додатку HTTP.sys продовжує приймати
і поміщати в чергу нові запити до однієї з наступних подій:
перезапуску процесу, який почне приймати запити, вичерпання
черг, відсутність місця в чергах або зупинки адміністратором
самого Web-сервісу. Так як HTTP.sys – компонент режиму ядра, його робота
з чергами особливо ефективна, даючи можливість поєднувати в
архітектурі IIS 6.0 ізоляцію процесів з високопродуктивною
обробкою запитів.

Після того як сервіс WWW виявляє помилку в додатку, він
запускає новий робочий процес при наявності запитів, що очікують
обслуговування в пулі додатків робочого процесу. Тобто, хоча
тимчасова затримка в обробці запитів користувальницького режиму цілком
можлива, кінцевий користувач не помічає її, оскільки запити
як і раніше приймаються і поміщаються в чергу.

Компонент WWW Service Administration and Monitoring

Компонент WWW Service Administration і Monitoring є основною
частиною сервісу WWW. Як і HTTP.sys, він не виконує код додатку. У
нього дві основні обов'язки: конфігурування системи та управління
робочим процесом.

Налаштування сервера

При ініціалізації частина сервісу WWW, що відповідає за
конфігурування, використовує зберігається в пам'яті конфігураційну
метабази для ініціалізації таблиці маршрутизації (routing table)
простору імен HTTP.sys. Кожен запис в цій таблиці містить
інформацію, необхідну для перенаправлення входять URL пулу
додатків, де знаходиться зіставлені з даними адресою додаток.
Ці попередні дії повідомляють HTTP.sys про наявність пулу
додатків, що відповідає на запити до конкретної частини простору імен,
і про те, що HTTP.sys може зажадати запуску робочого процесу для
пулу додатків при надходженні запиту. Всі попередні дії
виконуються до того, як HTTP.sys приступає до перенаправлення запитів
індивідуальним процесам. У міру додавання нових додатків і їх пулів
Web-сервіс налаштовує HTTP.sys на прийом нових адрес, створює нові
черги запитів для нових пулів додатків і вказує, куди
перенаправляти нові URL. Для динамічного зміни інформації про
маршрутизації перезапуск сервісу не потрібно.

Управління робочим процесом

У ролі керуючого робочим процесом компонент WWW Service
Administration і Monitoring відповідає за управління життєвим циклом
робочого процесу, обробного запити. Це передбачає прийняття
рішень про запуск, використанні і перезапуск робочого процесу в
випадку, якщо він не може обслуговувати подальші запити (заблокований).
Крім того, він веде моніторинг робочого процесу і здатний виявити
його несподіване завершення.

Режим ізоляції робочого процесу

IIS 6.0 надає новий режим ізоляції програми для управління
обробкою Web-сайтів і додатків – режим ізоляції робочого процесу. У
цьому режимі всі програми виконуються в ізольованому середовищі, причому
така ізоляція не призводить до погіршення продуктивності. Програми
можна повністю ізолювати один від одного, в цьому випадку помилка в одному
додатку не впливає на інший додаток в іншому процесі. Для цього
застосовуються пули додатків. Запити надходять безпосередньо від ядра, а не від
якогось процесу користувацького режиму, який отримував би запити від
ядра, а потім відправляв би їх іншим процесам користувацького режиму.
Першим ділом HTTP.sys відправляє запити, адресовані до Web-сайтів і
додаткам, відповідним черг пулів додатків. Потім робочий
процес, обслуговуючий пул додатків, витягує запити безпосередньо з
черги додатків в HTTP.sys. Така модель дозволяє позбутися від
зайвих перемикань процесів, що виникають при відправленні запитів
внепроцессному DLLHost.exe і назад (як в IIS 4.0 і 5.0), що
збільшує продуктивність.

Важливо відзначити, що в IIS 6.0 більше немає поняття внутріпроцессного
додатки. Всі необхідні додатком сервіси періоду виконання, такі
як підтримка розширень ISAPI, так само доступні в будь-якому пулі додатків.
Подібна архітектура не дає збійному Web-сайту або програми порушити
роботу іншого Web-додатки або самого сервера. В IIS 6.0 тепер можна
вивантажити внутріпроцессний компонент, не зупиняючи Web-сервіс.
Робочий хост-процес можна тимчасово зупинити, не зачіпаючи інші
робочі процеси, що обробляють контент. Додаткова перевага –
можливість задіяти інші сервіси операційної системи, доступні
на рівні процесу [наприклад управління розподілом процесорного
часу (CPU throttling)] для пулів додатків. Крім того, архітектура
Windows Server 2003 підтримує набагато більше паралельних процесів,
ніж у попередніх операційних системах.

Режим ізоляції робочого процесу не дає одному з додатком або сайту
зупинити інші додатки. Крім цього, поділ їх застосування чи
сайтів на окремі робочі процеси спрощує багато завдань управління,
наприклад включення / вимикання сайту або додатку (незалежно від
інших працюючих сайтів або додатків), зміна використовуваного
додатком компонента, налагодження програми, спостереження за лічильниками
продуктивності, а також регулювання ресурсів, що виділяються
додатком.

Режим ізоляції робочого процесу в IIS 6.0 має наступні
особливості.

Режим ізоляції IIS 5.0

Деякі програми не сумісні з режимом ізоляції робочого
процесу IIS 6.0, наприклад програми-фільтри, які читають необроблені
дані, або програми, що покладаються на виконання в Inetinfo.exe або
DLLHost.exe. Тому IIS 6.0 здатний працювати в іншому режимі ізоляції,
який називається режимом ізоляції IIS 5.0 і забезпечує
сумісність. Використання цього режиму сильно нагадує роботу з
самим IIS 5.0, так як в ньому присутні ті ж основні процеси
користувацького режиму. Зокрема, є ті ж методи ізоляції
додатків (низький, середній у пулі і високий), а Inetinfo.exe –
як і раніше головний процес, через який проходять всі запити. Але
незважаючи на схожість, режим ізоляції IIS 5.0 виграє від
швидкодії HTTP.sys режиму ядра в роботі з чергами і при
кешуванні. Зверніть увагу, що інші сервіси IIS 6.0 на зразок File
Transfer Protocol (FTP), Network News Transfer Protocol (NNTP) і Simple
Mail Transfer Protocol (SMTP) працюють, як в IIS 5.0, і виконуються в
Inetinfo.exe. Тільки сервіс WWW в IIS 6.0 змінений і отримує запити від
HTTP.sys.

Переваги архітектури обробки запитів в IIS 6.0

Архітектура обробки запитів IIS 6.0 забезпечує дуже високий
рівень надійності без погіршення продуктивності.

Удосконалення в захисті

Захист завжди була важливою частиною Internet Information Services.
Однак у попередніх версіях продукту (наприклад в IIS 5.0 на комп'ютері з
Windows 2000 Server) сервер не поставлявся в блокованому стані по
замовчуванням. У пакет установки входили багато непотрібні сервіси, наприклад
друк через Інтернет. Посилення захисту системи вимагало ручного
втручання, і в багатьох організаціях параметри сервера залишали
незмінними. Це створювало масу вразливостей, оскільки, хоча можна було
захистити будь-який сервер, багато адміністраторів просто не розуміли, що
робити це необхідно, або в них не було відповідних інструментів.

Розробляючи IIS 6.0, Microsoft приділила значно більше уваги
захисту в порівнянні з розробкою попередніх версій IIS. Так, на початку
2002 робота всіх інженерів Windows (понад 8 500 чоловік) була
зупинена на час проведення інтенсивних тренінгів з безпеки.
По завершенні тренінгів група розробників проаналізувала кодову
базу Windows, в тому числі HTTP.sys та IIS 6.0, та реалізує нові
знання. Це значний внесок у поліпшення захисту платформи Windows.
Крім того, під час проектування Microsoft провела всебічне
моделювання загроз, щоб розробники розуміли, атакам яких типів
може піддатися сервер у замовників. Сторонні експерти також
провели аналіз захищеності коду.

Заблокований сервер

Щоб звузити можливості для атак на інфраструктуру Web, при
установці Windows Server 2003 IIS 6.0 за замовчуванням не встановлюється.
Адміністратори повинні явно вибрати і встановити IIS 6.0 у всіх версіях
Windows Server 2003 за винятком Windows Server 2003 Web Edition. Це
означає, що тепер IIS 6.0 не потрібно видаляти після установки Windows,
якщо він не потрібний для ролі сервера, наприклад, якщо сервер
призначений для роботи в якості поштового або сервера бази даних.
IIS 6.0 також буде заблокований при оновленні сервера до Windows
Server 2003, якщо тільки раніше не був встановлений IIS 5.0 Lockdown Tool
або не налаштований відповідний параметр в реєстрі. Крім того, після
установки IIS 6.0 за замовчуванням перебуває в стані "заблокована". Це
значить, що він приймає запити тільки до статичних файлів, якщо
спеціально не налаштований на обслуговування динамічного контенту, і що у
всіх таймаутів і параметрів є значення за замовчуванням,
забезпечують максимальний захист. IIS 6.0 також можна вимкнути через
групові політики Windows Server 2003.

Багаторівневий захист

У наступній таблиці перераховані рівні захисту, доступні в IIS 6.0.

Табл. 1. Рівні захисту в IIS 6.0

 

Рівень захисту в IIS 6.0 Опис
Не встановлюється за умовчанням в
Windows Server 2003
Важлива складова захисту –
скорочення можливостей для атак на систему. Тому IIS 6.0 НЕ
встановлюється за умовчанням в Windows Server 2003.
Адміністратори повинні явно вибрати і встановити IIS 6.0
Встановлюється в заблокованому
стані
Функціональність IIS 6.0 після
установки за замовчуванням мінімальна. Обслуговуються тільки
статичні файли, а додаткову функціональність (на кшталт ASP
і ASP.NET) адміністратор повинен включити явним чином
Блокується при оновленнях При оновленні серверів IIS до
Windows Server 2003 нова версія IIS встановлюється в
заблокованому стані, якщо адміністратор не встановив і не
запустив Lockdown Tool або не набудував параметр реєстру
RetainW3SVCStatus
на оновлюваному сервері
Вимкнення через групову
політику
У Windows Server 2003
адміністратори домену можуть заборонити користувачам
встановлювати IIS 6.0
Виконання під обліковим записом з
малим набором привілеїв
За замовчуванням робочі процеси IIS
6.0 виконуються в користувацькому контексті з малим набором
привілеїв. Це кардинально зменшує шкоду від потенційно
можливих атак
Захищений ASP Всі вбудовані функції ASP завжди
виконуються під обліковим записом з малим набором привілеїв (як
анонімний користувач)
Розпізнавані розширення файлів Виконуються лише запити до файлів
з розпізнаваними розширеннями, а запити до файлів з
невідомими розширеннями відхиляються
Утиліти командного рядка
недоступні Web-користувачам
Атакуючі часто користуються
утилітами командного рядка, що запускаються через Web-сервер.
Web-сервер в IIS 6.0 не виконує такі програми
Контент захищений від запису Атакуючі, отримавши доступ до
сервера, намагаються підмінити (deface) його Web-сайти. Заборона
анонімним Web-користувачам перезаписувати Web-контент
перешкоджає таким атакам
Таймаут і обмеження За замовчуванням параметрами присвоєні
значення, що забезпечують максимальний захист
Обмеження на завантаження даних Адміністратори можуть обмежити
дозволений розмір даних, закачуваних на сервер
Захист від переповнення буфера Робочий процес перериває
виконання програми, виявивши переповнення буферу
Верифікація файлів Ядро сервера перевіряє наявність
запитаного контенту до передачі запиту оброблювачу
(ISAPI-розширенню)

Розблокування функціональності в IIS 6.0 Web Service Extensions

З метою звуження можливостей для атак на Web-сервер після установки
за замовчуванням IIS 6.0 обслуговує тільки статичний контент.
Програмована функціональність начебто розширень Internet Server API
(ISAPI) або Common Gateway Interfaces (CGI) повинна встановлюватися
адміністратором IIS 6.0 вручну. ISAPI і CGI розширюють функціональність
Web-сторінок і тому називаються розширеннями Web-сервісу. Наприклад, для
запуску Active Server Pages (ASP) в IIS 6.0 ISAPI, що реалізує ASP.DLL,
повинен бути явно включений як розширення Web-сервісу. Щоб працювали
серверні розширення Microsoft FrontPage® і ASP.NET, їх теж
потрібно активізувати вручну. Використовуючи розширення Web-сервісу,
адміністратори Web-сайтів можуть включати і вимикати функції IIS 6.0 у
залежно від потреб організації. Ця функціональність поширюється
на весь сервер. IIS 6.0 містить програмні, графічні і запускаються
з командного рядка кошти для включення розширень Web-сервісу.

Налаштовувана ідентифікація робочого процесу

Виконання декількох додатків або сайтів на одному Web-сервері
пред'являє до нього додаткові вимоги. Якщо ISP здійснює
хостинг для двох компаній (можливо, конкурентів), він повинен
гарантувати, що два додатки ізольовані один від одного. Ще важливіше
для ISP гарантувати, що зловмисний адміністратор однієї програми
не зуміє звернутися до даних іншого. IIS 6.0 забезпечує цей рівень
ізоляції за допомогою настроюваної ідентифікації робочого процесу. У
поєднанні з іншими функціями ізоляції, наприклад з регулюванням смуги
пропускання і процесорного часу, або з повторним використанням
(Рециклінгу) у пам'яті, IIS 6.0 створює середовище для виконання декількох
повністю ізольованих додатків на одному сервері. Ви можете налаштувати
ідентифікацію базового процесу пулу додатків як специфічну для
користувача в даному пулі. Це забезпечує ще більшу ізоляцію пулу.

IIS 6.0 за умовчанням виконується під обліковим записом з малим набором
привілеїв

За замовчуванням робочий процес виконується під новою вбудованою облікової
записом Network Service, у якої рівно сім привілеїв. Вона дозволяє:

Виконання під обліковим записом з малим набором привілеїв – найважливіший
принцип безпеки. Імовірність використання уразливості можна
істотно зменшити, якщо у робочого процесу мало прав в системі. При
бажанні пул додатків можна налаштувати на виконання під будь-якою обліковою
записом (Network Service, Local System, Local Service або
сконфігурованої адміністратором).

Удосконалення в SSL

В IIS 6.0 внесено три основних удосконалення в SSL (secure
sockets layer). Вони перераховані нижче.

Авторизація і аутентифікація

Якщо аутентифікація відповідає на питання "Хто ви?", То авторизація – на
питання "Що ви можете робити?". Авторизація дозволяє або забороняє
користувачеві виконувати певні операції. У Windows Server 2003
інтегрований. NET Passport, який служить механізмом аутентифікації для
IIS 6.0. Останній розширює застосування нової інфраструктури
авторизації, що поставляється з сімейством Windows Server 2003. Крім того,
Web-додатки можуть задіяти для управління доступом авторизацію
по URL в поєднанні з Authorization Manager. У Windows Server 2003
добавлена обмежена делегована авторизація, щоб адміністратори
домену могли дозволяти делегування тільки обраним комп'ютерів і
сервісам.

Інтеграція. NET Passport з IIS 6.0

Інтеграція. NET Passport і IIS 6.0 дозволяє використовувати сервіси
аутентифікації. NET Passport в ядрі Web-сервера. В. NET Passport 2.0
застосовуються інтерфейси, що надаються стандартними компонентами
Passport, а саме шифрування Secure Sockets Layer (SSL),
HTTP-перенаправлення і cookie. Адміністратори можуть робити свої
Web-сайти і додатки доступними всім користувачам. NET Passport,
яких налічується більше 150 000 000, не піклуючись про проблеми
управління обліковими записами, наприклад про закінчення терміну дії
пароля або про генерації паролів. Після аутентифікації користувача його
унікальний ідентифікатор в. NET Passport (Passport Unique ID, PUID)
можна зіставити облікового запису у службі каталогів Microsoft Active
Directory®, Якщо таке зіставлення для ваших Web-сайтів
дозволено. Local Security Authority (LSA) створює для користувача
маркер (token), який застосовується IIS 6.0 для HTTP-запиту.
Розробники додатків і адміністратори Web-сайтів можуть застосовувати цю
модель захисту для авторизації по облікових записів користувачів Active
Directory. Ці облікові дані (посвідчення) також можна делегувати,
задіявши нову функцію обмеженого делегування (Constrained
Delegation) підтримувану Windows Server 2003.

Авторизація на основі URL і розширення нової інфраструктури
авторизації

В даний час для прийняття рішень про авторизацію застосовуються
списки управління доступом (ACL). Проблема в тому, що модель ACL занадто
вже прив'язана до об'єктів (сконцентрована на об'єктах "файл" та
"Каталог") і відповідає вимогам диспетчера ресурсів (файлової
системи NTFS), а не розробника додатків. З іншого боку,
більшість бізнес-додатків Web засноване не на об'єктах, а на
операціях або завданнях. Якщо розробнику потрібна заснована на операціях
або завданнях модель управління доступом, йому доведеться створювати її
окремо. Нова інфраструктура авторизації в Windows Server 2003
пропонує засіб вирішення цієї проблеми. IIS 6.0 розширює це
засіб, забезпечуючи авторизацію по заданим URL. Крім того,
Web-додатки можуть використовувати URL-авторизацію разом з Authorization
Manager, щоб контролювати доступ з одного і того ж сховища
політик до скомпрометованим URL і керувати специфічними для
програми завданнями та операціями. Зберігання політик в одному сховищі
дозволяє адміністраторам керувати доступом до URL і функціональності
програми з однієї точки, використовуючи при цьому групи додатки на
рівні сховища і програмуванням бізнес-правила.

Обмежена делегована аутентифікація

 

Делегування – це дозвіл серверним додаткам діяти в
мережі від імені користувача. Як приклад можна навести додаток
– Web-сервіс в інтрамережі підприємства, яка звертається до інформації на
інших серверах організації від імені клієнта, а потім надає по
HTTP консолідований звіт кінцевому користувачеві. Обмежене
делегування додано в Windows Server 2003 для того, щоб
адміністратори домену могли дозволяти делегування лише певним
комп'ютерів і сервісам. Далі наведені рекомендації з делегування.

Обмежена делегована аутентифікація найбільш переважна
для додатків в середовищі Windows Server 2003, так як вона дозволяє
використовувати високорівневі протоколи на зразок Remote Procedure Call (RPC)
і Distributed Component Object Model (DCOM). Ці протоколи можуть
застосовуватися для прозорої передачі користувацького контексту від
сервера до сервера, підміни (уособлення) користувацького контексту і
його авторизації на об'єктах від імені користувача за правилами
авторизації, які визначаються участю в доменній та локальної
групах, а також списками управління виборчим доступом (DACL) до
ресурсів на сервері.

Покращена керованість

Типовий Web-сайт в Інтернеті не працює тільки на одному сервері.
Тепер сайти розподілені по безлічі Web-серверів або Web-ферм.
(Останні є кластери серверів, виділені для
надання контенту, бізнес-логіки і сервісів.) Збільшується і
число сайтів в інтрамережі в міру того, як в організаціях
розробляється все більше бізнес-додатків, орієнтованих на роботу
в Web. Крім того, зі все більшим поширенням віддаленого
адміністрування зростає потреба у розширеній підтримки API
доступу і прямого конфігурування. У зв'язку зі змінами, що відбулися
в технологіях Інтернету і интрасетей за останні кілька років,
управління Web-сайтом перестало бути простою справою – тепер це
заплутаний і складний процес.

Нові засоби IIS 6.0 полегшують адміністрування Web-сайтів.
Сховище конфігураційної інформації IIS 6.0 тепер представляє собою
прості текстові XML-файли, що дозволяє безпосередньо редагувати (з
можливістю відновлення) конфігурацію метабази навіть під час роботи
сервера. Більш того, в Windows Management Instrumentation (WMI) поліпшена
підтримка командного рядка та сценаріїв для програмного керування
Web-сайтом без графічного інтерфейсу IIS 6.0
Manager. IIS 6.0 також включає нову Web-консоль для віддаленого
адміністрування – Remote Administration Tool.

Метабази XML

Метабази – це ієрархічне сховище параметрів конфігурації,
використовуваних IIS 6.0. Вона підтримує спадкування, типізацію даних,
повідомлення про зміни та захист. Конфігурація метабази для IIS 4.0 і
5.0 зберігалася в спеціальному двійковому файлі, який не так-то легко було
редагувати або читати. В IIS 6.0 двійковий файл, що називався
MetaBase.bin, замінений на текстові XML-файли. Адміністраторам і
розробникам додатків давно було потрібно доступне, швидкодіюче
сховище конфігурації, яка не сприймалося б як "чорний ящик".
Нова XML-метабази задовольняє цим вимогам, підвищуючи
продуктивність і керованість за рахунок функцій, описуваних нижче.
Схема Active Directory Service Interfaces (ADSI) і розширюваність схем
як і раніше підтримуються.

Нова XML-метабази поліпшує керованість сервера, дозволяючи:

Нова XML-метабази дає можливість адміністраторам легко читати і
редагувати конфігураційні параметри безпосередньо, управляючи Web-сервером
без написання сценаріїв або коду. XML-метабази значно спрощує
виявлення потенційно можливих пошкоджень і дозволяє розширювати
існуючу схему, використовуючи XML. Адміністратори також можуть читати і
редагувати поточну конфігурацію метабази безпосередньо через файл цієї
метабази, зберігаючи при цьому стовідсоткову сумісність з існуючим
API метабази і ADSI. Двійкова метабази попередніх версій IIS
автоматично оновлюється до нової XML-метабази, застосовуваної в IIS 6.0.

Автоматичне архівування версій конфігурації

Функція архіву метабази автоматично відстежує зміни в
метабази, збережені на диск. При записі метабази на диск IIS 6.0
додає до нового файлу MetaBase.xml номер версії і зберігає його копію
в архівній папці. Кожен архівний файл містить унікальний номер версії,
придатний для відкоту або відновлення. За замовчуванням функції
архівування включені.

Функція редагування під час роботи

IIS 6.0 дає адміністраторам можливість змінювати конфігурацію
сервера під час його роботи, безпосередньо редагуючи файл MetaBase.xml.
Наприклад, ця функція придатна для додавання нового сайту, створення
віртуальних каталогів або зміни конфігурації пулів додатків і
робочих процесів, поки IIS 6.0 обробляє запити. Адміністратори
можуть легко зробити це, відкривши MetaBase.xml в Notepad, створивши необхідний
віртуальний каталог та зберігши файл (ще раз підкреслимо: в процесі
роботи IIS). Сервер виявить зміни, перевірить їх коректність і
застосує до метабази, якщо зміни стосуються схемою.

Експорт і імпорт конфігурації

IIS 6.0 пропонує два нових методи Admin Base Object (ABO): Export ()
і Import (). Ці методи дозволяють експортувати і імпортувати між
серверами конфігурацію вузла будь-якого рівня. Секретні дані захищаються
користувацькими паролями точно так само, як і нові функції резервного
копіювання і відновлення. Ці нові методи доступні користувачам
ADSI і WMI, а також з IIS Manager. Застосовуючи Export () і Import (),
адміністратори можуть:

Незалежні від сервера резервне копіювання і відновлення

В IIS 6.0 розробникам доступний новий ABO API, застосовуваний для
резервного копіювання і відновлення метабази із захистом паролем. Це
дозволяє адміністраторам і розробникам виконувати незалежне від
сервера резервне копіювання. Сеансовий ключ шифрується необов'язковим
користувальницьким паролем при резервному копіюванні, причому цей ключ не
заснований на ключі комп'ютера. Під час резервного копіювання метабази
система шифрує сеансовий ключ паролем, наданим користувачем.
При відновленні сеансовий ключ розшифровується з використанням
наданого пароля і знову шифрується поточним ключем комп'ютера.
Новий метод відновлення забезпечує відновлення з копій,
створених старим методом, і у випадках, коли розшифрувати сеансовий ключ
не можна, його поведінка збігається з поведінкою старого методу
відновлення. WMI і ADSI підтримують нові методи
копіювання / відновлення. На ці ж методи спирається і існуючий
користувальницький інтерфейс копіювання / відновлення метабази.

Переваги XML-метабази IIS 6.0

Масштабованість файлу метабази IIS 6.0 помітно збільшена. За
порівняно з двійковою метабази IIS 5.0 його розмір такої ж або менше, а
швидкість зчитування при запуску Web-сервера вище. Додаткові
переваги такі:

WMI-провайдер IIS 6.0

У Windows 2000 був введений компонент Windows Management
Instrumentation (WMI) – новий засіб конфігурування сервера і
отримання доступу до важливих даних на зразок лічильників продуктивності і
системних параметрів. Тепер в IIS 6.0 є WMI-провайдер, що дозволяє
адміністраторам задіяти можливості WMI, зокрема підтримку
запитів і зіставлень між об'єктами. WMI містить багатий набір
програмних інтерфейсів, що пропонують більш потужні та гнучкі способи
адміністрування Web-сервера. Для редагування метабази WMI-провайдер
в IIS 6.0 має функціональність, аналогічну функціональності
ADSI-провайдера.

Призначення WMI-провайдера IIS 6.0 – забезпечити керованість IIS
6.0 на рівні функціональності, еквівалентній ADSI-провайдеру IIS 6.0, і
підтримку розширюваної схеми. Для цього потрібна WMI-схема, сумісна зі
схемою метабази IIS 6.0. Хоча ADSI і WMI відрізняються за своїм об'єктним
моделями та моделями даних, вони пропонують еквівалентну функціональність.
Іншими словами, завдання адміністратора можна вирішити за допомогою сценаріїв,
використовують або модель ADSI, або WMI. Вплив на метабази одного і
того ж сценарію, що використовує ADSI або WMI однаково. Точно так само всі
зміни схеми, що виконуються через ADSI, автоматично відображаються в
WMI-провайдера.

Адміністрування з командного рядка

Тепер IIS 6.0 поставляється зі сценаріями, які можна використовувати
для його адміністрування. Сценарії знаходяться в каталозі
WindowsSystem32 і написані на мові сценаріїв Microsoft Visual Basic®.
Для отримання інформації з метабази в них використовується WMI-провайдер
IIS 6.0. Сценарії запускаються з командного рядка і виконують найбільш
поширені завдання адміністратора Web-сервера. Користувальницького
інтерфейсу сценарії не надають. До складу IIS 6.0 включені
наступні сценарії для адміністративних операцій, які виконуються з
командного рядка:

Нова Web-консоль адміністрування

IIS 6.0 включає нову Web-консоль адміністрування – Remote
Administration Tool. З її допомогою адміністратори можуть віддалено
адмініструвати IIS 6.0 через Інтернет або інтрамережа з використанням
Web-браузера.

Більш висока продуктивність і масштабованість

Програми нового покоління пред'являють більш високі вимоги до
продуктивності та масштабованості Web-серверів. Збільшення швидкості
обробки HTTP-запитів і кількості сайтів і додатків, що виконуються на
одному сервері, тягне за собою зменшення кількості серверів,
необхідних для хостингу сайту. Ще один наслідок – більш ефективне
використання інвестицій в існуюче обладнання.

Windows Server 2003 містить новий драйвер режиму ядра, HTTP.sys,
розбирає HTTP-запити і виконує кешування. HTTP.sys спеціально
призначений для підвищення продуктивності Web-сервера і
спроектований так, щоб виключити перемикання процесора в
користувальницький режим, якщо запитаний контент можна обробити на
рівні ядра. Це важливо для користувачів IIS, оскільки IIS 6.0 побудований
на основі HTTP.sys. Якщо компоненту користувацького режиму потрібно
прийняти участь в обробці запиту, HTTP.sys перенаправляє запит до
відповідний робочий процес користувальницької режиму напряму, не
залучаючи до його обробку інші процеси користувальницького режиму.

Крім того, IIS 6.0 більше "знає" про середовище обробки. Компоненти
режиму ядра і користувальницького режиму IIS 6.0 підтримують концепцію
локальності процесорів (processor locality) і прагнуть по можливості
зберегти локальність внутрішніх даних процесора. Це також
сприяє збільшенню масштабованості сервера в багатопроцесорних
системах. При необхідності адміністратори можуть прив'язати окремі
додатки / сайти до конкретних процесорним підсистемам. Це означає, що
додатки можуть створювати віртуальні розділи обробки додатків
(Virtual application processing silos) в одному образі операційної
системи, як показано на рис. 1.

Рис. 1. Віртуальні розділи обробки запитів в IIS 6.0

{
Малюнок:
Worker Process (affinitized to proc 0, 1, 2, 3) – Робочі процеси
(Прив'язані до процесорів 0, 1, 2, 3)
Worker Process (affinitized to proc 4, 5, 6, 7) – Робочі процеси
(Прив'язані до процесорів 4, 5, 6, 7)
User – для користувача режим
Kernel – Режим ядра
Application pool request queue # 0 – Черга запитів до пулу додатків 0

Application pool request queue # 1 – Черга запитів до пулу додатків 1

Arriving on proc # 0, 1, 2, 3 – Надходять до процесорів 0, 1, 2, 3
Arriving on proc # 4, 5, 6, 7 – Надходять до процесорів 4, 5, 6, 7
}

HTTP.sys: новий драйвер режиму ядра

Новий драйвер режиму ядра HTTP.sys – єдина точка прийому всіх
входять (серверних) HTTP-запитів. Він забезпечує
високопродуктивну з'єднання між серверними HTTP-додатками.
Цей драйвер розміщується поверх TCP / IP і приймає всі запити на
з'єднання, що їх посилають на прослуховується ним IP-адреси та порти. HTTP.sys
також відповідає за загальне управління з'єднаннями, регулювання смуги
пропускання і протоколювання Web-сервера.

Стратегія кешування і керування потоками

В IIS 6.0 вбудований евристичний механізм, що визначає важливі
кешованим частини програми або набору сайтів. З того, що якийсь
елемент можна зберегти в кеші, не обов'язково слід, що його потрібно
туди поміщати, оскільки управління елементом у кеші призводить до
додаткових витрат і, крім того, кеш займає пам'ять. Тому IIS
6.0 використовує новий евристичний механізм для визначення даних,
які слід кешувати. Механізм виходить з розподілу запитів,
вступників з додатком. Тобто масштабованість сервера поліпшується, так
як даний механізм позвляет ефективніше використовувати серверні ресурси,
не знижуючи швидкість обробки часто зустрічаються запитів. IIS 6.0 також
містить вбудований евристичний механізм для відстеження загального
стану сервера, який приймає рішення про збільшення або
зменшенні ступеня паралелізму. Основна ідея – в ефективному
застосуванні паралелізму. Так, одночасне виконання прив'язаних до
процесору запитів – аж ніяк не завжди найкращий підхід.

Web-сади

Web-сад – це пул додатків, що містить кілька процесів, які
обслуговують запити до цього пулу. Робочі процеси в Web-саду можна
прив'язати до конкретного набору процесорів у багатопроцесорній системі.
Завдяки Web-садам масштабованість Web-додатків зростає, так як
програмна блокування одного процесу не блокує всі запити,
надходять з додатком. Наприклад, якщо в Web-саду виконується чотири
процесу, програмна блокування заблокує близько чверті запитів.

Зберігається кеш ASP-шаблонів

Перш ніж ASP-код виконується в IIS 5.0, ядро ASP компілює
ASP-файл в ASP-шаблон. Ці шаблони зберігаються в пам'яті процесу. Якщо сайт
складається з безлічі ASP-сторінок, з кеша видаляються найстаріші
шаблони, щоб звільнити місце для нових. В IIS 6.0 такі шаблони
зберігаються на диску. Якщо який-небудь з цих файлів запитується
знову, ядро ASP завантажує шаблон, не витрачаючи додаткове процесорний
час на повторну компіляцію ASP-файлу.

Підтримка великого об'єму пам'яті для x86

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

Масштабованість сайту

В IIS 6.0 покращено внутрішнє використання ресурсів. Прийнятий підхід
– Виділяти ресурси в міру надходження HTTP-запитів, а не
завчасно, при ініціалізації. Це дає наступні переваги:

Попереднє тестування показує, що IIS 6.0 здатний
виконувати на порядок більше додатків в пулі в порівнянні з IIS 5.0. У
IIS 6.0 можна налаштувати тисячі ізольованих застосувань, і кожне з них
може виконуватися зі своєю ідентифікацією робочого процесу в пулі.
Звичайно, кількість одночасно працюючих ізольованих додатків
залежить від ресурсів системи. IIS 6.0 дозволяє легко налаштувати десятки
тисяч додатків на одному сервері, якщо вони налаштовані на
виконання в загальному пулі.

Звільнення ресурсів простоюють додатків

Додаткове поліпшення в архітектурі IIS 6.0, спрямоване на
збільшення масштабованості, полягає в тому, що IIS 6.0 здатний
зупиняти робочі процеси, які простоюють у протягом заданого
періоду. Адже якщо до пулу додатків не надходять запити, немає сенсу
витрачати на нього ресурси. На додаток IIS 6.0 динамічно видаляє з
кешу дані неактивних сайтів. Крім того, робочі процеси можуть
створюватися і запускатися на вимогу. Якщо робочого процесу в пулі
немає, він з'явиться, як тільки до пулу надійде перший запит. Таким
чином, IIS 6.0 витрачає лише необхідні ресурси.

Більш досконала платформа додатків

IIS 6.0 пропонує кілька нових програмованих засобів і
як і раніше використовує модель програмування ISAPI. До нових засобів
відносяться:

Інтеграція ASP.NET та IIS 6.0 і різноманітність мов програмування

Windows Server 2003 спрощує роботу програмістам за рахунок інтеграції
ASP.NET та IIS 6.0. Удосконалення, внесені в платформу і
засновані на IIS 6.0, надають розробникам дуже високий рівень
функціональності і багатий вибір мов програмування, а також
забезпечують швидку розробку програм. У Windows Server 2003
використання ASP.NET і. NET Framework спростилося завдяки інтеграції
більш досконалої моделі процесів в IIS 6.0, який підтримує
новітні стандарти Web, в тому числі XML, SOAP і IPv6.

ExecuteURL

Серверна допоміжна функція HSE_REQ_EXEC_URL тепер дозволяє
ISAPI-розширень легко перенаправляти запити по іншому URL. Вона
відповідає на зростаючі потреби розробників ISAPI-розширень в
"Цепочечной" обробці запитів.

Заміна фільтрів читання необроблених даних

ExecuteURL пропонує функціональність, що служить заміною
практично всім фільтрам читання необроблених даних (read raw data
filters). Найбільш часте застосування таких фільтрів – аналіз або
зміна запиту (заголовка або всього тіла) до того, як його обробить
URL-адресат. Зараз єдиний спосіб переглянути тіло запиту (у
точці, відмінній від URL-адресата) – використовувати повідомлення читання
необроблених даних. На жаль, створення ISAPI-фільтра, вирішального
це завдання, може виявитися вельми скрутним або навіть неможливим
в деяких конфігураціях. З іншого боку, ISAPI-розширення
забезпечують функціональність, що дозволяє легко отримувати тіло запиту і
маніпулювати ним. ISAPI-розширення можуть через ExecuteURL обробляти
тіло запиту і передавати його дочірньому запиту, що вирішує практично
всі проблеми розробників фільтрів читання необроблені дані.

Глобальні перехоплювачі

ExecuteURL дозволяє IIS 6.0 реалізувати ISAPI-перехоплювачі,
здатні перехоплювати, змінювати, переадресовувати або забороняти все
входять HTTP-запити до необхідного URL-простору.

ISAPI-фільтри

У попередніх версіях IIS приймати всі запити до конкретного URL
можна було тільки в ISAPI-фільтрах. Але з ними пов'язані такі
проблеми:

Так як глобальні перехоплювачі – це ISAPI-розширення, на них не
накладаються обмеження, властиві ISAPI-фільтрам, і їх функціональність в
поєднанні з ExecuteURL замінює практично всі фільтри читання
необроблених даних.

VectorSend

Сьогодні у ISAPI-розробників є тільки два способи сформувати
відповідь з декількох буферів. Вони можуть або кілька разів викликати
WriteClient, або об'єднати відповідь в один великий буфер.

У

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*