Начало продуктивной эксплуатации IIS 7.0

Группа разработчиков IIS корпорации Майкрософт заявляет, что службы Internet Information Services (IIS) 7.0 являются самым крупным выпуском за всю историю IIS. Эта версия устанавливает новые стандарты, предлагает фундаментальные улучшения и приносит новые возможности для консолидации веб-сред. Службы IIS 7.0, входящие в состав Windows Server® 2008 и Windows Vista® SP1, уже сейчас обеспечивают работу Microsoft.com, а несколько компаний, поставляющих услуги размещения веб-узлов, уже начали предоставлять услуги по размещению под IIS 7.0 веб-дизайнерам и разработчикам, желающим перенести свои существующие веб-приложения на платформу нового веб-сервера.

В этой статье я исследую ключевые улучшения в IIS 7.0, которые наиболее важны для специалистов по ИТ, после чего подробно раскрою вопросы переноса веб-приложений ASP.NET и PHP. Но сперва я хотел бы дать краткий эскиз лаборатории тестирования, схожей с базовой производственной средой.

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

Подготовка, установка, тестирование

В состав моей лаборатории тестирования входят системы, работающие на Windows Server 2003 и IIS 6.0, на которых размещены приложения ASP.NET, а также серверы, на которых работает дистрибутив Linux Ubuntu 7.10 и сервер HTTP Apache 2.2, размещающие веб-приложения на основе PHP. Моей конечной целью является развертывание Windows Server 2008 на промежуточных и производственных системах, а затем перевод сложных веб-приложений с целью замены экземпляров IIS 6.0 и Apache на IIS 7.0.

У меня имеются два ключевых веб-приложения: DotNetNuke 4.7 и osCommerce 3.0a4. DotNetNuke – платформа веб-приложений, основанная на ASP.NET 2.0 и Microsoft® SQL Server®. Другое приложение, osCommerce, является последней альфа-версией полнофункционального решения электронной коммерции, построенного на PHP и MySQL. Так что давайте перенесем эти современные приложения на IIS 7.0!

Я хотел бы пояснить, что в мои намерения не входит сравнение версий программного обеспечения, продуктов или платформ. Однако использование Windows Server 2008 и IIS 7.0 в качестве стандарта дает ряд преимуществ, на которые следует указать. А именно, уменьшаются административные сложности и появляется возможность свести к минимуму общее число используемых веб-серверов.

На рис. 1 предоставлен обзор лаборатории тестирования, которую я использую для этой статьи. Если вы хотите последовать моим объяснениям в собственной тестовой среде, ссылки на требуемые компоненты программного обеспечения, а также подробные поэтапные руководства по установке можно найти в сопровождающем материале, доступном в отделе загрузок кода веб-узла журнала TechNet Magazine на .com.

Рис 1. Среда тестирования для развертывания IIS 7.0

Стоит отметить, что когда я завершал работу над этой статьей, Майкрософт выпустила средство командной строки (MSDeploy.exe) для поддержки развертывания IIS 6.0 и 7.0 клиентами, их синхронизации и переноса на них веб-приложений. Я рекомендую познакомиться с этим средством. Подробные сведения можно найти в блоге группы веб-развертываний Майкрософт по адресу go.microsoft.com/fwlink/?LinkId=118272.

Настройка моего теста

Во время написания этой статьи Windows Server 2008 все еще находился в состоянии предварительной версии, так что я не стал заменять Windows Server 2003 на контроллере домена или серверах базы данных. После официального выпуска Windows Server 2008 можно подумать о переносе заодно и инфраструктуры Active Directory®. Перенос баз данных SQL Server® 2005 и MySQL на SQL Server 2008 также выходит за рамки этой статьи.

Я развернул SQL Server 2008 на моем промежуточном сервере в основном потому, что это требует меньше усилий, чем установка SQL Server 2005 с пакетом обновления 2. DotNetNuke может без проблем работать с базой данных SQL Server 2008. Установка MySQL 5.0 на Windows Server 2008 также была незамысловатым процессом безо всяких сложностей.

Хотя службы IIS 7.0 доступны в варианте установки Server Core, я не использовал Server Core из-за определенных требований к моему тестированию. Мой промежуточный сервер требовал полной установки, поскольку являлся моей основной тестовой системой. Вдобавок, Microsoft .NET Framework отсутствует на Server Core.

PHP работает на Server Core без проблем, но моей целью является объединение приложений ASP.NET и PHP, так что Server Core совершенно исключен. Пока .NET Framework не будет поддерживается Server Core, для поддержки приложений ASP.NET будет необходимо выполнять полную установку. Детальное, поэтапное руководство по установке тестовой среды можно найти в файле the 01_install_testlab.htm сопровождающего материала.

Я решил выполнить чистую установку Windows Server 2008 (а не обновлять существующие серверы). Помимо прочего, чистая установка упрощает применение поэтапного варианта переноса, подобного показанному на рис. 2. Базовая стратегия состоит в том, чтобы поддерживать работу существующих веб-ферм, пока все значимые компоненты веб-приложения не прошли успешное тестирование на промежуточном сервере и не перемещены на веб-ферму IIS 7.0.

Рис 2. Организация перехода на IIS 7.0

Можно переместить все существующие веб-приложения разом или делать это постепенно в зависимости от сложности среды. Для каждого веб-приложения или узла после выполнения окончательного приемочного тестирования на новой веб-ферме можно проделать переход, изменив соответствующие записи DNS, чтобы направить обозреватели на новую веб-ферму IIS 7.0. Это позволяет свести к минимуму простои и перерывы в работе.

Важные усовершенствования для администраторов отделов ИТ

В журнале MSDN® Magazine есть превосходная статья Майка Володарского (Mike Volodarsky), озаглавленная "Explore the Web Server for Windows Vista and Beyond" («Рассмотрим веб-сервер для Windows Vista и далее») (доступна по адресу msdn2.microsoft.com/magazine/cc163453.aspx), которая позволяет быстро ознакомиться с улучшениями, имеющимися в IIS 7.0.

Также стоит прочитать запись в блоге группы Microsoft.com, названную "The Tasty Morsels Found in Dogfood" («Вкусные кусочки, найденные в собачьем корме») (доступна на go.microsoft.com/fwlink/?LinkId=117436). Запись сводит воедино первоначальные впечатления членов группы от IIS 7.0. Вкратце, они выстроили основные улучшения следующим образом:

1. Упрощенная установка.
2. Отличная совместимость
3. Ликвидация метабазы.
4. Централизованная настройка через файл applicationHost.config, помещенный в общей папке с адресом в формате UNC.
5. Делегированная настройка посредством файлов web.config в каталогах приложений
6. Улучшенные средства управления.
7. Отслеживание неудачных запросов.
8. Запрос фильтрации без необходимости в URLScan.
9. Упрощенная доступность синхронизации содержимого через общие папки с адресами в формате UNC.
10. Кэширование исходящих данных динамического содержимого.

Упрощенная установка определенно находится в моем списке. В своей записи в блоге группа Microsoft.com показывает, как можно развернуть все компоненты IIS 7.0 (или само собой, только нужные пользователю компоненты) с помощью единственной командной строки. Я с радостью включил этот подход в инструкции для моей лаборатории тестирования с помощью командной строки, показанной на рис. 3.

Следует признать, что эта команда довольно длинна. (Если требуется скопировать эту команду, я рекомендую скопировать ее с веб-узла TechNet Magazine и вставить, а не набирать вручную.) Хотя эта команда помещает все доступные модули на компьютер IIS 7.0, она не включает PHP. В составе IIS 7.0 отсутствует PHP, и мысль о загрузке и установке пакетов Debian через Интернет является чуждой концепцией для диспетчера пакетов Windows® (pkgmgr.exe). Тут-то и появляется на сцене пакет автоматической установки Windows (Automated Installation Kit – AIK).

 Рис. 3. Развертывание компонентов IIS 7.0 с помощью единственной командной строки

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-­WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).

С помощью AIK можно создать специальный установочный диск DVD для Windows Server 2008, в составе которого есть IIS 7.0 и PHP 5. Можно также включить туда MySQL, файлы веб-приложений и любые другие компоненты, необходимые при развертывании. Все компоненты могут быть частью установки Windows Server 2008, что позволяет применить модификации по единому образцу на все своих веб-серверах. При этом нет необходимости в командных строках или во внесении изменений в файл настроек.

Можно даже создать специальный диск DVD для полностью автоматических установок. В AIK имеются документация и средства для создания файла AutoUnattend.xml, который можно затем поместить в корневую папку диска DVD. В файле Custom Image Deployment.htm в сопровождающем материале имеются поэтапные указания.

Многие администраторы также согласны, что совместимость является ключевым улучшением. Приступая к работе, я ожидал некоторых проблем совместимости с DotNetNuke и osCommerce, но переход на IIS 7.0 оказался довольно безболезненным, несмотря на то, что оба эти веб-приложения содержат расширенные возможности, такие, как проверку подлинности на основе форм и удобные для поисковиков URL-адреса.

В случае DotNetNuke я не встретил никаких проблем, пока не перешел к случаю сложной веб-фермы с общим использованием содержимого папок с адресами формата UNC на 64-разрядной платформе. Но и тогда проблема была довольно мелкой. В конечном счете, эта улучшенная совместимость означает, что меньше времени уходит на приспособление веб-приложений к работе на IIS 7.0.

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

На рис. 4 показана диагностическая информация, которая будет получена при запуске DotNetNuke 4.7 на IIS 7.0 в интегрированном режиме. В данном примере имеются три варианта (показанные в разделе «Что можно предпринять»). Изменение приложения для поддержки интегрированного режима является, вероятно, лучшим выбором для разработчиков DotNetNuke. Игнорирование ошибки – вероятно, плохая идея. Мне нравится третий вариант, в котором включается классический режим путем переключения веб-приложения на Classic .NET AppPool, поскольку мне нужно использовать неизмененный DotNetNuke 4.7 на IIS 7.0.

Рис. 4 Диагностическая информация для DotNetNuke, работающего в интегрированном режиме (щелкните изображение, чтобы увеличить его)

Архитектура IIS

Может возникнуть вопрос о том, что из себя представляют эти интегрированный и классический режимы и почему они влияют на приложение ASP.NET (DotNetNuke), но не на приложение PHP (osCommerce). Чтобы лучше понять это, необходимо сперва взглянуть на архитектуру IIS 7.0. В предыдущих версиях среда выполнения ASP.NET была интегрирована в центральный веб-сервер в основном через расширение ISAPI (aspnet_isapi.dll). IIS 7.0, с другой стороны, позволяет подключать модули ASP.NET напрямую к центральному веб-серверу через модуль HTTP глобального уровня, именуемый ManagedEngine, который загружает вспомогательную библиотеку DLL ASP.NET (webengine.dll) в конвейер обработки запросов IIS 7.0.

Модули в машинном коде используют интерфейс API IIS Web Server Core для регистрации конкретных событий на конвейере, таких как BeginRequest, AuthenticateRequest, AuthorizeRequest и ExecuteRequestHandler. ManagedEngine также предоставляет необходимую поддержку для интеграции модулей ASP.NET в конвейер запросов. С помощью этой новой архитектуры службы IIS 7.0 могут вызывать собственные модули и модули ASP.NET на любом этапе обработки запроса и вне зависимости от типа запрашиваемого содержимого.

В качестве примера давайте рассмотрим проверку подлинности пользователя ASP.NET. В IIS 6.0 для модуля HTTP на основе ASP.NET возможно регистрироваться на события OnAuthenticate (такие как FormsAuthentication.OnAuthenticate и WindowsAuthentication.OnAuthenticate) для установки учетных данных пользователя в текущем HttpContext. Это отлично работает в среде выполнения ASP.NET, но такой код ASP.NET нельзя использовать для защиты ресурсов, предоставляемых через веб-приложения на основе PHP.

Согласно настройке карты сценариев, службы IIS 6.0 перенаправляют запросы для типов содержимого ASP.NET к aspnet_isapi.dll, но не перенаправляют запросы для типов содержимого PHP к расширению ISAPI для ASP.NET. В конце концов, ASP.NET не обрабатывает код PHP, но это также значит, что код проверки подлинности ASP.NET не выполняется, если запрошена страница PHP. Таким образом, в случае IIS 6.0 необходимо продублировать логику проверки подлинности, поскольку приложениям на PHP приходится применять собственный механизм проверки подлинности.

Службы IIS 7.0 используют управляемую событиями модель обработки, поддерживающую смешивание и согласование отдельных модулей в конвейере запросов. Помимо прочих компонентов, в IIS 7.0 входят управляемые модули WindowsAuthentication и FormsAuthentication, которые создают события OnAuthenticate, когда конвейер запроса запускает событие AuthenticateRequest. Теперь модуль в машинном коде, такой как RequestFilteringModule или IpRestrictionModule, может обрабатывать событие BeginRequest, чтобы отвергать опасные запросы как можно раньше, после чего запускать специальный код проверки подлинности ASP.NET в момент события AuthenticateRequest и предоставить FastCgiModule возможность запустить обработчик сценариев PHP (php-cgi.exe) в момент события ExecuteRequestHandler для обработки страниц PHP.

Эта интегрированная архитектура избавляет веб-разработчиков от необходимости дублировать код для реализации распространенной бизнес-логики. Пользовательский вариант проверки подлинности ASP.NET можно использовать для защиты всех своих ресурсов IIS, включая приложения PHP. Кроме того, через модули ASP.NET можно выполнять другие задачи предобработки и послеобработки, такие как переписывание URL-адресов, пользовательское отслеживание и ведение журнала ошибок.

Интегрированный и классический режимы

Побочным эффектом этой новой архитектуры является то, что существующие приложения ASP.NET могут потребовать изменений в коде и настройке, которые разработчикам приложений следует выполнить, чтобы гарантировать отсутствие вызванных изменениями конфликтов модулей в конвейере запросов. Но если немедленно перенести существующее веб-приложение нельзя, то можно включить классический режим в пуле приложений, который рабочий процесс использует для выполнения веб-приложения. Службы IIS 7.0 не загружают ManagedEngine в рабочие процессы классического режима, из чего в данном случае следует, что конвейер запросов не может разрешать или вызывать модули ASP.NET. Вместо этого IIS 7.0 активирует ряд обработчиков ISAPI, основанных на IsapiModule (aspnet_isapi.dll), для обработки типов содержимого ASP.NET подобно IIS 6.0. Это можно увидеть, если проанализировать раздел обработчиков в system.webServer в файле applicationHost.config, который по умолчанию можно найти в папке %WinDir%\­System32\InetSrv\Config.

Проведите поиск строки «aspx» в качестве примера, и будет найдена одна запись, указывающая PageHandlerFactory-Integrated (загруженную в рабочие процессы пула приложений интегрированного режима, согласно параметру preCondition="integratedMode") и другие записи, указывающие на PageHandlerFactory-ISAPI-2.0 и PageHandlerFactory-ISAPI-2.0-64 (загруженные в рабочие процессы пула приложений классического режима, согласно параметру preCondition="classicMode").

Поскольку режим конвейера устанавливается на уровне пула приложений, IIS 7.0 может запускать веб-приложения в интегрированном и классическом режимах одновременно. А рабочим процессам лишь нужно работать в разных пулах приложений, но они могут быть размещены на одном сервере.

Не забывайте, что интегрированный и классический режимы влияют лишь на то, как IIS 7.0 интегрирует ASP.NET в конвейер запросов. Эти режимы конвейера не влияют на приложения PHP напрямую. FastCgiModule и все прочие модули в машинном коде загружаются без предварительных условий, связанных с режимом конвейера, как в интегрированном, так и в классическом режиме. Для выполнения механизма сценариев PHP на IIS 7.0 желательно использовать интерфейс FastCGI Вместо использования FastCGI можно также создать сопоставление обработчика для механизма сценариев PHP с помощью CGI, либо можно использовать IsapiModule в сочетании PHP-ISAPI (php4isapi.dll).

Я, впрочем, думаю, что эти альтернативные конструкции в манере IIS 6.0 теперь устарели, поскольку FastCGI предлагает значительно улучшенные производительность и стабильность. CGI работает медленнее, поскольку службам IIS необходимо инициализировать новый процесс CGI для каждого запроса HTTP, тогда как FastCGI повторно использует процессы CGI для нескольких запросов. Для ISAPI требуется сборка PHP, поддерживающая многопоточное выполнение, а она требует большего расхода ресурсов, чем выполнение сборки PHP, не поддерживающей многопоточное выполнение.

Что, возможно, еще более важно, не все расширения PHP доступны в версии, поддерживающей многопоточное выполнение, а запуск не поддерживающих многопоточное выполнение расширений с помощью ISAPI – плохая мысль, поскольку это может привести к проблемам со стабильностью на сервере. FastCGI, с другой стороны, является средой с единственным параллелизмом, подобно CGI. Среда FastCGI, используемая для выполнения не поддерживающей многопоточное выполнение сборки PHP, стабильна и быстра, так что ее использование для запуска PHP 5 на IIS 7.0 является очевидным выбором. Она также доступна на IIS 6.0 для тех, кто еще не готов перейти на IIS 7.0.

Модули и функции

Архитектура IIS 7.0 имеет высокую степень модульности – или, как сформулировали это разработчики IIS, компонентный набор функций. Это хорошая новость для веб-администраторов, которые стремятся сделать занимаемый объем памяти и открытую для атак область IIS 7.0 настолько маленькими, насколько это возможно. Включая различные модули или, возможно, даже заменяя стандартные модули на пользовательские, можно полностью контролировать компоненты IIS 7.0 на своих веб-серверах.

Чтобы запустить ASP.NET в интегрированном или классическом режиме, а также запустить приложения PHP на том же сервере, нужно установить, как минимум, роль веб-сервера и основные модули для поддержки обработки запросов, настройки сервера ASP.NET, ISAPI и CGI (куда входит модуль FastCGI). Для этого можно использовать следующую командную строку:

start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

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

Также имеется возможность использовать диспетчер пакетов (pkgmgr.exe) или средство командной строки IIS 7.0 (appcmd.exe), или прямое внесение изменений в раздел globalModules в файле applicationHost.config, но я нахожу очень удобными графические средства. Не забывайте, что некоторые модули, такие как RequestFilteringModule и StaticCompressionModule, весьма полезны, даже если они, строго говоря, и не требуются для запуска веб-приложения. В случае удаления модуля, который требуется пулу приложений, при попытке доступа к веб-приложению будет получена ошибка HTTP, как показано на рис. 5.

Рис. 5 Приложение ASP.NET не будет работать в классическом режиме, поскольку IsapiModule отсутствует

Примечание: наилучшим вариантом является использование одного и того же набора модулей на всех своих серверах IIS 7.0. Чтобы проверить установленные компоненты, перейдите на HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ и проверьте разделы реестра. Значение 0000 0001 формата REG_DWORD для параметра реестра, такого как NetFxEnvironment или CGI, указывает, что соответствующий компонент установлен.

Перенос веб-приложений

Достаточно теории, пора мне закатать рукава и заняться переносом веб-приложений на IIS 7.0. Как упоминалось ранее, на моем промежуточном сервере работают службы IIS 7.0 со всеми доступными компонентами и не поддерживающая многопоточную обработку сборка PHP 5, зарегистрированная с помощью FastCGI. Прежде чем приступать, мне необходимо задать несколько базовых вопросов:

• Нужна ли веб-приложению система управления базами данных, такая как SQL Server или MySQL?
• Нужно или мне установить или настроить дополнительные компоненты, такие как подключения ODBC, объекты COM или сертификаты SSL?
• Требует ли веб-приложение специальных учетных записей служб и повышенных прав локального или удаленного доступа к общим файловым ресурсам и прочим ресурсам?
• Имеются ли в нем любые зависимости от функций конкретных платформ, недоступных на IIS 7.0, такие как зависимость от модуля Apache в плане переписывания URL-адресов (mod_rewrite)?

Ответы на подобные вопросы помогут заставить веб-приложения быстрее работать на IIS 7.0. Например, при попытке переноса приложения PHP, использующего mod_rewrite, с Apache 2.2 (скажем, ради удобства работы поисковиков или для предотвращения кражи пропускной способности через связанно-встроенные образы) возникнут проблемы, если не применить на IIS 7.0 пользовательское совместимое решение для переписывания URL-адресов. К счастью, osCommerce не требует функций mod_rewrite на IIS 7.0, но некоторые пакеты оптимизации работы поисковиков могут требовать его.

Теперь, когда я определил и установил необходимые дополнительные компоненты на промежуточном сервере, я готов к установке и запуску моих веб-приложений. Опять же, мне желательно задать себе несколько вопросов:

• Какова простейшая настройка, которую я могу использовать для поддержки веб-приложения?
• Какая настройка используется в производственной среде сейчас?
• Могу ли я оптимизировать настройку веб-приложения на новой платформе?
• Каков минимальный набор служб ролей и модулей, необходимых веб-приложению для работы в желаемой настройке?

Быстрейший способ убедиться, что веб-приложение работает – это заставить его работать в простейшей настройке. Если все выглядит отлично, пора применить настройку, подобную существующей производственной среде, и импортировать производственные данные в базы данных тестирования. Само собой, некоторые проблемы могут всплыть только в расширенных настройках.

Возможности для улучшения также могут быть замечены при зеркальном отражении производственной настройки в лаборатории тестирования. Помещение файла applicationHost.config в общую папку с путем в формате UNC является отличным способом централизовать настройку нескольких веб-серверов. Чтобы повысить отказоустойчивость через избыточность и синхронизацию содержимого, подумайте насчет применения репликации распределенной файловой системы (Distributed File System – DFS) – основанного на состоянии модуля репликации с несколькими хозяевами, доступного на Windows Server 2003 R2 и Windows Server 2008. Также можно свести к минимуму требуемое пространство хранилищ на веб-интерфейсах путем помещения файлов содержимого веб-приложений в общие папки с путем в формате UNC.

Другие потенциальные оптимизации могут затрагивать безопасность или динамическое кэширование. Здесь я не касался оптимизаций безопасности и производительности в моей лаборатории тестирования, поскольку они выходят за рамки данной статьи. Не производил я и настройки DFS, чтобы избежать установки новых серверов. Поэтапные указания в сопровождающем материале предоставляют упрощенный пример того, как разместить файл applicationHost.config и веб-содержимое в общих папках с путем в формате UNC. А на рис. 6 показано создание веб-фермы на основе UNC с помощью DFS.

Рис. 6 Развертывание веб-фермы с помощью файла applicationHost.config и веб-содержимого в общих папках с путем в формате UNC

Заключение

IIS 7.0 – впечатляющая платформа веб-сервера. Ее базовая архитектура переработана и в то же время поддерживает почти стопроцентную обратную совместимость с IIS 6.0. Она должна быть способна использовать большинство существующих веб-приложений ASP.NET без изменений. Но, учитывая размах изменений архитектуры, надеяться на полное отсутствие проблем с совместимостью нельзя.

Независимо от того, планируется ли перенос на IIS 7.0 веб-приложений ASP.NET или PHP, лучшим является поэтапный подход, при котором основное внимание уделяется правильному планированию, подготовке, тестированию и документированию изменений в коде и настройке.

Службы IIS 7.0 стоят такой работы. Там имеется множество улучшений в таких областях, как безопасность, производительность, настраиваемость и гибкость. Рассказ о всех них занял бы целую книгу. Централизованная настройка и совместное использование содержимого на основе общих папок с путем формата UNC, делегированная настройка посредством файлов web.config в каталогах приложений, улучшенные средства управления, подробная диагностическая информация и отслеживание неудачных запросов, а также динамическое кэширование исходящих данных наверняка завоюют любовь веб-администраторов.

Возможность смешивать модули в машинном коде и управляемые модули в конвейере обработки процессов помогает разработчикам ASP.NET. А улучшения безопасности и стабильности, связанные с FastCGI в IIS 7.0 – отличная новость для разработчиков приложений на PHP.

И еще одна важная вещь, помогающая специалистам по ИТ успешно работать с IIS 7.0: портал сетевого сообщества Microsoft IIS (www.iis.net). Он содержит всю необходимую информацию, включая подробные статьи о новой архитектуре, исходный код для разработчиков C++ и ASP.NET, демонстрирующий, как создавать модули IIS 7.0, и поэтапные указания по установке и запуску приложений PHP. На этот веб-узел определенно стоит заглянуть. Он является хорошим местом для получения ответов на все вопросы, относящиеся к IIS.