IIS

Bereitstellung mit IIS 7.0

Fergus Strachan

Auf einen Blick:

  • Bereitstellen von IIS 7.0 in einer Webfarmumgebung
  • Sicherheitsverbesserungen und Leistungsoptimierung
  • Migrieren von ASP.NET-Webanwendungen von IIS 6.0 zu IIS 7.0
  • Migrieren von PHP-Webanwendungen zu IIS 7.0

Inhalt

Auf die Plätze, fertig, testen
Meine Testeinrichtung
Wichtige Verbesserungen für IT-Administratoren
IIS-Architektur
Integrierter und klassischer Modus
Module und Funktionalität
Migration von Webanwendungen
Zusammenfassung

Nach Aussage des IIS-Teams bei Microsoft sind Internetinformationsdienste (IIS) 7.0 die bisher wichtigste Version in der Geschichte von IIS. Diese Version setzt neue Standards und bietet grundlegende Verbesserungen sowie

neue Funktionen für die Konsolidierung von Webumgebungen. Das im Lieferumfang von Windows Server® 2008 und Windows Vista® SP1 enthaltene IIS 7.0 ist bereits der Motor hinter Microsoft.com, und mehrere Webhostingunternehmen haben damit begonnen, Webdesignern und Entwicklern, die ihre vorhandenen Webanwendungen auf die neue Webserverplattform portieren möchten, IIS 7.0-Hosting bereitzustellen.

In diesem Artikel sollen wichtige Verbesserungen in IIS 7.0 untersucht werden, die für IT-Experten eine bedeutende Rolle spielen. Anschließend folgen detaillierte Informationen zur Migration von ASP.NET- und PHP-Webanwendungen. Zunächst jedoch möchte ich eine Testumgebung skizzieren, die einer einfachen Produktionsumgebung ähnelt.

Dies ist eine wichtige Aufgabe. Bevor Sie IIS 7.0 auf Ihren Produktionsservern bereitstellen, müssen Sie Zeit in gründliche Tests in einer Testumgebung investieren. Nur so können Sie sicherstellen, dass Ihre Webanwendungen auf dem neuen Webserver reibungslos funktionieren.

Auf die Plätze, fertig, testen

Meine Testumgebung umfasst Systeme mit Windows Server 2003 und IIS 6.0, die ASP.NET-Anwendungen hosten sowie Server, auf denen die Ubuntu 7.10 Linux-Distribution ausgeführt wird, sowie Apache HTTP Server 2.2 als Host für PHP-basierte Webanwendungen. Mein endgültiges Ziel besteht darin, Windows Server 2008 auf Bereitstellungs- und Produktionssystemen bereitzustellen und dann komplexe Webanwendungen zu übertragen, um IIS 6.0 und Apache-Instanzen durch IIS 7.0 zu ersetzen.

Ich habe zwei wichtige Webanwendungen: DotNetNuke 4.7 und osCommerce 3.0a4. DotNetNuke ist ein Webanwendungsframework auf der Grundlage von ASP.NET 2.0 und Microsoft® SQL Server®. Bei der anderen Anwendung, osCommerce, handelt es sich um die neueste Alphaversion einer E-Commercelösung mit umfassenden Funktionen auf Basis von PHP und MySQL. Der Plan besteht darin, diese hoch entwickelten Anwendungen auf IIS 7.0 zu übertragen!

Ich möchte klarstellen, dass es mir nicht darum geht, Softwareversionen, Produkte oder Plattformen zu vergleichen. Es gibt jedoch einige Vorteile der Standardisierung in Windows Server 2008 und IIS 7.0, auf die ich aufmerksam machen möchte. Die Komplexität der Verwaltung wird verringert, und Sie können die Gesamtzahl der Webserver, die Sie ausführen, minimieren.

Abbildung 1 bietet einen Überblick über die Testumgebung, die ich für diesen Artikel verwende. Wenn Sie meinen Erklärungen in Ihrer eigenen Testumgebung folgen wollen, finden Sie Links zu den erforderlichen Softwarekomponenten sowie ausführliche schrittweise Installationsanweisungen im Begleitmaterial, das Sie im Bereich mit den Codedownloads der TechNet Magazin-Website unter .com herunterladen können.

fig01.gif

Abbildung 1 Die Testumgebung für die Bereitstellung von IIS 7.0 (zum Vergrößern auf das Bild klicken)

Zum Zeitpunkt der Abfassung dieses Artikels veröffentlichte Microsoft ein Befehlszeilentool (MSDeploy.exe), um Kunden bei der Bereitstellung, Synchronisierung und Migration von Webanwendungen zu IIS 6.0 und 7.0 zu unterstützen. Dieses Tool sollten Sie sich näher ansehen. Ausführliche Informationen finden Sie im Blog des Webbereitstellungsteams von Microsoft unter go.microsoft.com/fwlink/?LinkId=118272.

Meine Testeinrichtung

Zum Zeitpunkt der Abfassung dieses Artikels lag Windows Server 2008 noch in einer Vorabversion vor. Daher habe ich Windows Server 2003 auf Domänencontroller- oder Datenbankservern nicht ersetzt. Nach der offiziellen Veröffentlichung von Windows Server 2008 könnten Sie nun auch Ihre Active Directory®-Infrastruktur migrieren. Auf die Migration von SQL Server® 2005- und MySQL-Datenbanken zu SQL Server 2008 wird in diesem Artikel ebenfalls nicht eingegangen.

Ich habe SQL Server 2008 in erster Linie deshalb auf meinem Bereitstellungsserver bereitgestellt, weil dies einen geringeren Aufwand bedeutet als die Installation von SQL Server 2005 mit Service Pack 2. DotNetNuke konnte ohne Probleme mit einer SQL Server 2008-Datenbank ausgeführt werden. Auch die Installation von MySQL 5.0 auf Windows Server 2008 verlief ohne Komplikationen.

IIS 7.0 ist zwar auf Server Core verfügbar, dennoch habe ich aufgrund bestimmter Anforderungen für das Testen keine Server Core-Installation gewählt. Mein Bereitstellungsserver erforderte eine vollständige Installation, da es sich um mein primäres Testsystem handelte. Außerdem ist Microsoft .NET Framework auf Server Core nicht verfügbar.

PHP lässt sich problemlos auf Server Core ausführen. Da mein Ziel jedoch darin besteht, ASP.NET- und PHP-Anwendungen zu konsolidieren, kommt Server Core ganz einfach nicht in Frage. Solange .NET Framework nicht auf Server Core unterstützt wird, müssen Sie eine vollständige Installation durchführen, um ASP.NET-Anwendungen zu unterstützen. Ausführliche schrittweise Anleitungen zur Installation der Testumgebung finden Sie in der Datei „01_install_testlab.htm“ im Begleitmaterial.

Ich habe mich für eine Neuinstallation von Windows Server 2008 (im Gegensatz zur Aktualisierung vorhandener Server) entschieden. Unter anderem ist es bei einer Neuinstallation einfacher, ein Szenario einer gestaffelten Migration wie das in Abbildung 2 zu implementieren. Die zugrunde liegende Strategie besteht darin, mit den vorhandenen Webfarmen so lange zu arbeiten, bis alle relevanten Webanwendungskomponenten erfolgreich auf dem Bereitstellungsserver getestet und in die neue IIS 7.0-Webfarm verschoben wurden.

fig02.gif

Abbildung 2 Gestaffelte Umstellung auf IIS 7.0 (zum Vergrößern auf das Bild klicken)

Sie können alle vorhandenen Webanwendungen auf einmal oder nacheinander verschieben, je nach der Komplexität Ihrer Umgebung. Für jede Webanwendung oder Website können Sie nach der Durchführung eines abschließenden Akzeptanztests auf der neuen Webfarm den Wechsel vornehmen, indem Sie die relevanten DNS-Datensätze so ändern, dass Browser zur neuen IIS 7.0-Webfarm geleitet werden. So verringern Sie die Ausfallzeiten und Unterbrechungen auf ein Minimum.

Wichtige Verbesserungen für IT-Administratoren

Im MSDN® Magazin finden Sie einen hervorragenden Artikel von Mike Volodarsky mit dem Titel „Webserver für Windows Vista und mehr“ (verfügbar unter msdn2.microsoft.com/magazine/cc163453.aspx), in dem Sie sich über die Verbesserungen in IIS 7.0 informieren können.

Eine weitere gute Quelle ist ein Blogbeitrag des Microsoft.com-Teams mit dem Titel „The Tasty Morsels Found in Dogfood“ (verfügbar unter go.microsoft.com/fwlink/?LinkId=117436). Im Beitrag werden die ersten Erfahrungen der Teammitglieder mit IIS 7.0 resümiert. Kurz gefasst, sind die wichtigsten Verbesserungen die folgenden:

  1. Vereinfachtes Setup.
  2. Hervorragende Kompatibilität.
  3. Keine Metabasis mehr.
  4. Zentralisierung der Konfiguration erfolgt über die Datei „applicationHost.config“, die in einer UNC-Freigabe abgelegt wird.
  5. Delegierung der Konfiguration mittels Web.config-Dateien in Anwendungsverzeichnissen
  6. Verbesserte Verwaltungstools.
  7. Ablaufverfolgung für Anforderungsfehler.
  8. Anforderungsfilterung ohne die Notwendigkeit von URLScan.
  9. Verfügbarkeit vereinfachter Inhaltssynchronisierung durch UNC-Freigaben.

Ausgabezwischenspeicherung dynamischer Inhalte.

Vereinfachtes Setup steht ganz sicher auf meiner Liste. In seinem Blogbeitrag veranschaulicht das Microsoft.com-Team, wie Sie sämtliche Features (oder auch nur die gewünschten) von IIS 7.0 mit einer einzelnen Befehlszeile bereitstellen können. Ich habe diesen Ansatz sofort in meine Anweisungen zur Einrichtung der Testumgebung integriert. Die Befehlszeile wird in Abbildung 3 gezeigt.

Zugegeben, dieser Befehl ist ziemlich lang. (Wenn Sie den Befehl kopieren möchten, sollten Sie ihn von der TechNet Magazin-Website kopieren und dann einfügen, anstatt ihn per Hand einzugeben.) Mit diesem Befehl werden zwar alle verfügbaren Module auf dem IIS 7.0-Computer installiert, PHP wird jedoch nicht berücksichtigt. In IIS 7.0 ist PHP nicht enthalten, und das Konzept des Herunterladens und Installierens von Debian-Paketen über das Internet ist dem Windows®-Paket-Manager (pkgmgr.exe) fremd. Hier kommt Windows Automated Installation Kit (AIK) ins Spiel.

Abbildung 3 Bereitstellen von IIS 7.0-Features mit einer einzelnen Befehlszeile

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 (<a href=\"https://blogs.technet.com/mscom\" xmlns=\"http://www.w3.org/1999/xhtml\">blogs.technet.com/mscom</a>).

Mit AIK können Sie eine benutzerdefinierte Installations-DVD für Windows Server 2008 erstellen, die IIS 7.0 und PHP 5 enthält. Außerdem können Sie MySQL, Webanwendungsdateien und andere Komponenten einbeziehen, die für Ihre Bereitstellung erforderlich sind. Alle Komponenten können Teil Ihres Windows Server 2008-Setups sein, was Ihnen ermöglicht, einheitlich Anpassungen auf allen Webservern durchzuführen. Befehlszeilen oder die Bearbeitung von Konfigurationsdateien sind überflüssig.

Sie können sogar eine benutzerdefinierte DVD für vollständig unbeaufsichtigte Installationen erstellen. Das AIK umfasst Dokumentationsmaterial und Tools zur Erstellung der Datei „AutoUnattend.xml“, die Sie dann im Stammordner der DVD ablegen können. In der Datei „Custom Image Deployment.htm“ im Begleitmaterial finden Sie schrittweise Anleitungen.

Viele Administratoren sind sich außerdem darin einig, dass Kompatibilität zu den wichtigsten Verbesserungen zählt. Anfangs habe ich mit einigen Kompatibilitätsproblemen mit DotNetNuke und osCommerce gerechnet. Der Übergang zu IIS 7.0 verlief jedoch recht problemlos, und das trotz der Tatsache, dass beide Webanwendungen erweiterte Features enthalten (z. B. Formularauthentifizierung und suchmaschinenfreundliche URLs).

Bei DotNetNuke traten keinerlei Probleme auf, bis ich zu einem komplexen Webfarmszenario mit UNC-Inhaltsfreigabe auf einer 64-Bit-Plattform wechselte. Das Problem war jedoch ziemlich unbedeutend. Die bessere Kompatibilität bedeutet letzten Endes, dass Sie weniger Zeit benötigen, bis Ihre Webanwendungen unter IIS 7.0 zur Ausführung bereit sind.

Wenn Sie tatsächlich auf Kompatibilitätsprobleme mit Ihren Webanwendungen stoßen, werden die integrierte Diagnose und die Ablaufverfolgungsunterstützung bald zu Ihren neuen Lieblingsfunktionen gehören. Die ausführlichen Diagnoseinformationen sind sehr aussagekräftig, und die vorgeschlagenen Lösungswege sind nützlich und funktionieren.

Abbildung 4 zeigt die Diagnoseinformationen, die bei Ausführung von DotNetNuke 4.7 unter IIS 7.0 im integrierten Modus angezeigt werden. In diesem Beispiel gibt es drei Optionen (siehe den Abschnitt „Mögliche Vorgehensweise“). Die beste Option für DotNetNuke-Entwickler besteht vermutlich darin, die Anwendung so zu ändern, dass sie den integrierten Modus unterstützt. Den Fehler zu ignorieren ist sicher keine gute Idee. Mir persönlich gefällt die dritte Option, die Aktivierung des klassischen Modus. Hierzu aktiviere ich die Webanwendung für einen Anwendungspool im klassischen Modus, Classic .NET AppPool, weil ich DotNetNuke 4.7 unter IIS 7.0 unverändert ausführen möchte.

fig04.gif

Abbildung 4 Diagnoseinformationen für DotNetNuke bei Ausführung im integrierten Modus (zum Vergrößern auf das Bild klicken)

IIS-Architektur

Vielleicht fragen Sie sich, was diese integrierten und klassischen Modi eigentlich sind und warum sie zwar die ASP.NET-Anwendung (DotNetNuke), jedoch nicht die PHP-Anwendung (osCommerce) beeinflussen. Um dies zu verstehen, sollten Sie zuerst die Architektur von IIS 7.0 näher betrachten. In früheren Versionen war die ASP.NET-Laufzeit in den zentralen Webserver integriert, hauptsächlich durch eine ISAPI-Erweiterung (aspnet_isapi.dll). In IIS 7.0 hingegen ist es möglich, ASP.NET-Module direkt mit dem zentralen Webserver zu verbinden, und zwar über ein HTTP-Modul auf globaler Ebene namens „ManagedEngine“, das die ASP.NET-Support-DLL (webengine.dll) in die Pipeline für die Anforderungsverarbeitung von IIS 7.0 lädt.

Systemeigene Module verwenden die Core-API des IIS-Webservers zur Registrierung für spezifische Ereignisse in der Pipeline, z. B. „BeginRequest“, „Authenticate­Request“, „AuthorizeRequest“ und „Execute­RequestHandler“. „ManagedEngine“ bietet ebenfalls die notwendige Unterstützung für die Integration von ASP.NET-Modulen in die Anforderungspipeline. Dank dieser neuen Architektur kann IIS 7.0 systemeigene und ASP.NET-Module in jeder Phase während der Anforderungsverarbeitung aufrufen, unabhängig von der Art des angeforderten Inhalts.

Betrachten wir als Beispiel die ASP.NET-Benutzerauthentifizierung. In IIS 6.0 kann ein ASP.NET-basiertes HTTP-Modul sich für On­Authenticate-Ereignisse registrieren (z. B. „Forms­Authentication.OnAuthenticate“ und „Windows­Authentication.OnAuthenticate“), um die Identität des Benutzers im aktuellen HttpContext festzulegen. Dies funktioniert innerhalb der ASP.NET-Laufzeit ohne Probleme, Sie können diesen ASP.NET-Code jedoch nicht zum Schutz von Ressourcen verwenden, die durch eine PHP-basierte Webanwendung verfügbar gemacht werden.

Gemäß seiner Skriptzuordnungskonfiguration leitet IIS 6.0 Anforderungen für ASP.NET-Inhaltstypen an „aspnet_isapi.dll“ weiter. Anforderungen für PHP-Inhaltstypen werden jedoch nicht an die ISAPI-Erweiterung für ASP.NET weitergeleitet. ASP.NET verarbeitet schließlich keinen PHP-Code, dies bedeutet jedoch auch, dass der ASP.NET-Authentifizierungscode bei Anforderung einer PHP-Seite nicht ausgeführt wird. Folglich müssen Sie bei IIS 6.0 die Authentifizierungslogik duplizieren, da PHP-Anwendungen ihre eigenen Authentifizierungsmechanismen implementieren müssen.

IIS 7.0 verwendet ein ereignisgesteuertes Verarbeitungsmodell, das Unterstützung für das Mischen und Anpassen einzelner Module in der Anforderungspipeline bietet. Zu den Komponenten von IIS 7.0 gehören u. a. verwaltete WindowsAuthentication- und FormsAuthentication-Module, die OnAuthenticate-Ereignisse auslösen, wenn die Anforderungspipeline das AuthenticateRequest-Ereignis auslöst. Sie können jetzt festlegen, dass ein systemeigenes Modul wie „Request­FilteringModule“ oder „IpRestrictionModule“ das BeginRequest-Ereignis so handhabt, dass kritische Anforderungen so früh wie möglich abgelehnt werden, dann benutzerdefinierter ASP.NET-Authentifizierungscode am AuthenticateRequest-Ereignis ausgeführt und das FastCgiModule zur Ausführung des PHP-Skriptmoduls (php-cgi.exe) am Execute­RequestHandler-Ereignis veranlasst wird, um PHP-Seiten zu verarbeiten.

Das Ergebnis dieser integrierten Architektur besteht darin, dass Webentwickler Code nicht duplizieren müssen, um allgemeine Geschäftslogik zu implementieren. Sie können benutzerdefinierten ASP.NET-Authentifizierungscode dazu verwenden, alle Ihre IIS-Ressourcen einschließlich PHP-Anwendungen zu schützen. Sie können ASP.NET-Module außerdem für andere nachträglich durchgeführte Verarbeitungsaufgaben verwenden. Hierzu gehören z. B. URL-Umschreibung, benutzerdefinierte Ablaufverfolgung und Fehlerprotokollierung.

Integrierter und klassischer Modus

Der von dieser neuen Architektur verursachte Nebeneffekt besteht darin, dass für vorhandene ASP.NET-Anwendungen möglicherweise Code- und Konfigurationsänderungen erforderlich sind, die von Anwendungsentwicklern durchgeführt werden sollten, um sicherzustellen, dass die Änderungen nicht zu Modulkonflikten in der Anforderungspipeline führen. Wenn Sie eine vorhandene Webanwendung jedoch nicht sofort portieren können, haben Sie die Möglichkeit, den klassischen Modus im Anwendungspool zu aktivieren, den der Arbeitsprozess zur Ausführung der Webanwendung verwendet. IIS 7.0 lädt „ManagedEngine“ nicht in Arbeitsprozesse im klassischen Modus, was in diesem Fall bedeutet, dass die Anforderungspipeline ASP.NET-Module nicht auflösen oder aufrufen kann. Stattdessen aktiviert IIS 7.0 einige auf „IsapiModule“ (aspnet_isapi.dll) basierende ISAPI-Handler, um ASP.NET-Inhaltstypen ähnlich wie in IIS 6.0 zu verarbeiten. Sie können sich davon überzeugen, wenn Sie den Abschnitt „Handler“ unter „system.web­Server“ in der Datei „applicationHost.config“ analysieren, die Sie standardmäßig im Ordner „%WinDir%\­System32\InetSrv\Config“ finden.

Wenn Sie nach der Zeichenfolge „aspx“ als Beispiel suchen, finden Sie einen Eintrag, der auf „PageHandlerFactory-Integrated“ verweist (geladen in Arbeitsprozesse im Anwendungspool im integrierten Modus gemäß der Einstellung „preCondition="integratedMode"“), und andere Einträge, die auf „PageHandlerFactory-ISAPI-2.0“ und „PageHandlerFactory-ISAPI-2.0-64“ verweisen (geladen in Arbeitsprozesse im Anwendungspool im klassischen Modus gemäß der Einstellung „preCondition="classicMode"“).

Weil der Pipelinemodus auf der Ebene des Anwendungspools festgelegt wird, kann IIS 7.0 Webanwendungen im integrierten und klassischen Modus gleichzeitig ausführen. Die Arbeitsprozesse müssen dabei nur in verschiedenen Anwendungspools ausgeführt, können jedoch auf demselben Server gehostet werden.

Bedenken Sie, dass durch den integrierten und den klassischen Modus nur beeinflusst wird, wie IIS 7.0 ASP.NET in die Anforderungspipeline integriert. Diese Pipelinemodi haben keine direkten Auswirkungen auf PHP-Anwendungen. Das Modul „FastCgiModule“ und alle anderen systemeigenen Module werden ohne Vorbedingungen für den Pipelinemodus sowohl im integrierten als auch klassischen Modus geladen. FastCGI ist die bevorzugte Schnittstelle für die Ausführung des PHP-Skriptmoduls unter IIS 7.0. Anstatt FastCGI zu verwenden, können Sie auch eine Handlerzuordnung für das PHP-Skriptmodul über CGI erstellen, oder Sie können das Modul „IsapiModule“ in Verbindung mit PHP-ISAPI (php4isapi.dll) verwenden.

Meiner Ansicht nach sind diese Konfigurationsalternativen im Stil von IIS 6.0 jedoch veraltet, zumal FastCGI eine deutlich verbesserte Leistung und Stabilität zu bieten hat. CGI ist langsamer, da IIS einen neuen CGI-Prozess für jede HTTP-Anforderung initialisieren muss, während FastCGI CGI-Prozesse für mehrere Anforderungen wieder verwendet. ISAPI erfordert einen threadsicheren PHP-Build, was einen größeren Aufwand zur Folge hat als beim Ausführen eines nicht threadsicheren PHP-Builds.

Noch wichtiger ist vielleicht, dass nicht alle PHP-Erweiterungen in einer threadsicheren Version verfügbar sind, und von der Ausführung nicht threadsicherer Erweiterungen mit ISAPI ist abzuraten, da es hierdurch zu Stabilitätsproblemen auf dem Server kommen kann. FastCGI hingegen ist eine Umgebung mit Einzelparallelität wie CGI. FastCGI, das zur Ausführung nicht threadsicherer PHP-Dateien verwendet wird, ist stabil und schnell, und ist ganz sicher die Lösung für PHP 5 unter IIS 7.0. Außerdem ist FastCGI unter IIS 6.0 verfügbar, falls Sie für den Übergang zu IIS 7.0 noch nicht bereit sind.

Module und Funktionalität

IIS 7.0 verfügt über eine stark modularisierte Architektur oder (um es mit den Worten der IIS-Entwickler zu sagen) eine in Komponenten gegliederte Featuregruppe. Dies sind gute Nachrichten für Webadministratoren, die den Speicherbedarf und die Angriffsfläche von IIS 7.0 so klein wie möglich halten möchten. Durch Aktivierung verschiedener Module oder vielleicht gar das Ersetzen von Standardmodulen durch benutzerdefinierte Module können Sie die vollständige Kontrolle über die IIS 7.0-Features auf Ihren Webservern gewinnen.

Um ASP.NET im integrierten oder klassischen Modus sowie PHP-Anwendungen auf demselben Server ausführen zu können, müssen Sie mindestens die Webserverrolle und die zentralen Module installieren, um Anforderungsverarbeitung, Serverkonfiguration, ASP.NET, ISAPI und CGI zu unterstützen (einschließlich des FastCGI-Moduls). Hierzu können Sie die folgenden Befehlszeile verwenden:

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

Ich installiere in der Regel lieber IIS 7.0 mit allen verfügbaren Optionen auf meinem Bereitstellungsserver, um sicherzustellen, dass alle Komponenten und Verwaltungstools verfügbar sind, die ich benötige, um meine Webanwendungen schnell einsatzbereit zu machen. Meine Strategie besteht darin, zunächst dafür zu sorgen, dass alles funktioniert, und anschließend die Konfiguration durch Deinstallieren von Rollendiensten und Deaktivieren von Modulen einzugrenzen. Wenn eine Webanwendung Probleme bereitet, füge ich Rollendienste oder Module, die ich gerade entfernt habe, wieder hinzu.

Sie können ferner auswählen, ob Sie Paket-Manager (pkgmgr.exe) oder das IIS 7.0-Befehlszeilentool (appcmd.exe) verwenden oder den Abschnitt „globalModules“ in der Datei „applicationHost.config“ direkt bearbeiten möchten. Meiner Ansicht nach sind die grafischen Tools jedoch sehr praktisch. Beachten Sie, dass einige Module (z. B. „RequestFilteringModule“ und „StaticCompressionModule“) recht nützlich sind, obwohl sie genau genommen nicht für die Ausführung Ihrer Webanwendungen benötigt werden. Wenn Sie ein Modul deinstallieren, das für einen Anwendungspool erforderlich ist, erhalten Sie beim Zugriff auf Ihre Webanwendung einen HTTP-Fehler, wie in Abbildung 5 gezeigt.

fig05.gif

Abbildung 5 Eine ASP.NET-Anwendung kann nicht im klassischen Modus ausgeführt werden, da IsapiModule fehlt (zum Vergrößern auf das Bild klicken)

Hinweis: Eine bewährte Methode besteht darin, sicherzustellen, dass auf allen IIS 7.0-Servern die gleiche Gruppe von Modulen installiert und aktiviert ist. Um die installierten Komponenten zu überprüfen, wechseln Sie zu „HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\“, und überprüfen Sie die Registrierungsschlüssel. Ein REG_DWORD-Wert von 0000 0001 für einen Registrierungsschlüssel, z. B. für NetFxEnvironment oder CGI, zeigt an, dass die entsprechende Komponente installiert ist.

Migration von Webanwendungen

Genug der Theorie. Nun ist es Zeit, die Ärmel hochzukrempeln und einige Webanwendungen auf IIS 7.0 zu verschieben. Wie bereits erwähnt, werden auf meinem Bereitstellungsserver IIS 7.0 mit allen verfügbaren Komponenten und der nicht threadsichere PHP 5-Build ausgeführt, registriert bei FastCGI. Zunächst muss ich jedoch einige grundlegenden Fragen stellen:

  • Erfordert die Webanwendung ein Datenbankverwaltungssystem, z. B. SQL Server oder MySQL?
  • Muss ich zusätzliche Komponenten installieren oder konfigurieren, z. B. ODBC-Verbindungen, COM-Objekte oder SSL-Zertifikate?
  • Erfordert die Webanwendung besondere Dienstkonten und erhöhte Berechtigungen für den lokalen oder Remotezugriff auf Dateifreigaben und andere Ressourcen?
  • Bestehen Abhängigkeiten von plattformspezifischen Features, die unter IIS 7.0 nicht verfügbar sind, z. B. Abhängigkeiten vom Apache-Modul für die URL-Umschreibung (mod_rewrite)?

Wenn Sie Fragen wie diese stellen, benötigen Sie weniger Zeit, Ihre Webanwendungen unter IIS 7.0 startbereit zu machen. Wenn Sie beispielsweise versuchen, eine PHP-Anwendung von Apache 2.2 zu migrieren, die „mod_rewrite“ verwendet (z. B. zum Zweck der Suchmaschinenfreundlichkeit oder um Bandbreitenaneignung durch Inline-Verknüpfung von Bildern zu verhindern), treten Probleme auf, bis Sie eine kompatible benutzerdefinierte Lösung für die URL-Umschreibung unter IIS 7.0 implementieren. Glücklicherweise erfordert osCommerce keine mod_rewrite-Funktion unter IIS 7.0, auf einige Pakete zur Suchmoduloptimierung könnte dies jedoch zutreffen.

Nachdem ich die erforderlichen zusätzlichen Komponenten bestimmt und auf dem Bereitstellungsserver installiert habe, kann ich nun meine Webanwendungen startklar machen. Auch jetzt gibt es wieder einige Fragen, die ich mir stellen möchte:

  • Wie sieht die einfachste Konfiguration aus, die ich zur Unterstützung der Webanwendung verwenden kann?
  • Welche Konfiguration wird derzeit in der Produktionsumgebung verwendet?
  • Kann ich die Webanwendungskonfiguration auf der neuen Plattform optimieren?
  • Welchen Mindestsatz an Rollendiensten und Modulen benötigt die Webanwendung, um in der gewünschten Konfiguration zu funktionieren?

Wenn Sie die Webanwendung in der einfachsten Konfiguration ausführen, können Sie rasch herausfinden, ob sie funktioniert. Verläuft alles ohne Probleme, können Sie eine Konfiguration anwenden, die der in der vorhandenen Produktionsumgebung ähnelt, und Produktionsdaten in die Testdatenbanken importieren. Einige Probleme dürften selbstverständlich nur in erweiterten Konfigurationen auftreten.

Vielleicht entdecken Sie beim Spiegeln Ihrer Produktionskonfiguration in einer Testumgebung auch Möglichkeiten für Verbesserungen. Das Ablegen der Datei „applicationHost.config“ in einer UNC-Freigabe bietet eine hervorragende Möglichkeit, die Konfiguration mehrerer Webserver zu zentralisieren. Um die Fehlertoleranz durch Redundanz und Inhaltssynchronisierung zu erhöhen, sollten Sie die Implementierung von DFS-Replikation erwägen, einem statusbasierten Multimasterreplikationsmodul, das in Windows Server 2003 R2 und Windows Server 2008 verfügbar ist. Außerdem können Sie die Speicheranforderungen auf Web-Front-End-Computern minimieren, indem Sie die Inhaltsdateien Ihrer Webanwendungen in UNC-Freigaben ablegen.

Weitere potenzielle Optimierungen betreffen die Sicherheit oder dynamische Zwischenspeicherung. Auf Sicherheits- und Leistungsoptimierungen bin ich in meiner Testumgebung nicht eingegangen, weil dies den Rahmen dieses Artikels sprengen würde. Ebenso wenig habe ich DFS konfiguriert, um die Installation weiterer Server zu vermeiden. In den Schritt-für-Schritt-Anweisungen im Begleitmaterial finden Sie ein vereinfachtes Beispiel für das Hosten der Datei „applicationHost.config“ und des Webinhalts in UNC-Freigaben. In Abbildung 6 wird gezeigt, wie eine UNC-basierte Webfarm in DFS implementiert werden kann.

fig06.gif

Abbildung 6 Webfarmbereitstellung mit der Datei „applicationHost.config“ und Webinhalt in UNC-Freigaben (zum Vergrößern auf das Bild klicken)

Zusammenfassung

IIS 7.0 ist eine beeindruckende Webserverplattform. Trotz der neu gestalteten Kernarchitektur bleibt die Abwärtskompatibilität mit IIS 6.0 fast zu 100 Prozent erhalten. IIS 7.0 sollte in der Lage sein, die meisten vorhandenen ASP.NET-Webanwendungen ohne Änderung auszuführen. Angesichts des Umfangs der Änderungen an der Architektur können Sie sich jedoch nicht darauf verlassen, dass keine Kompatibilitätsprobleme auftreten.

Ganz gleich, ob Sie ASP.NET- oder PHP- Webanwendungen zu IIS 7.0 migrieren – am besten eignet sich ein gestaffelter Ansatz. Wichtig sind richtige Planung, Vorbereitung, gründliches Testen und das Dokumentieren von Code- und Konfigurationsänderungen.

IIS 7.0 ist den Arbeitsaufwand wert. In Bereichen wie Sicherheit, Leistung, Konfigurierbarkeit und Flexibilität gibt es viele Verbesserungen. Die umfassende Erläuterung aller dieser Verbesserungen würde ein ganzes Buch füllen. Zentralisierte Konfiguration und Inhaltsfreigabe auf der Basis von UNC-Freigaben, delegierte Konfiguration mittels web.config-Dateien in Anwendungsverzeichnissen, verbesserte Verwaltungstools, detaillierte Diagnoseinformationen und Ablaufverfolgung für Anforderungsfehler sowie dynamische Ausgabezwischenspeicherung sind mit Sicherheit Features, die den Beifall von Webadministratoren finden.

Entwickler profitieren von der Fähigkeit, systemeigene und verwaltete Module in der Pipeline für die Anforderungsverarbeitung zu mischen. Entwickler von PHP-Anwendungen sind ganz sicher von den Verbesserungen in puncto Leistung und Stabilität beeindruckt, die FastCGI unter IIS 7.0 mit sich bringt.

Schließlich muss noch ein weiterer wichtiger Faktor erwähnt werden, der IT-Experten zum Erfolg mit IIS 7.0 verhilft: das Microsoft IIS Community Portal (www.iis.net). Dort finden Sie alle Informationen, die Sie benötigen. Dazu gehören ausführliche Artikel über die neue Architektur, Quellcode für C++- und ASP.NET-Entwickler, der veranschaulicht, wie IIS 7.0-Module erstellt werden, sowie Schritt-für-Schritt-Anweisungen, um PHP-Anwendungen zum Laufen zu bringen. Diese Website sollten Sie sich unbedingt ansehen. Sie ist ein gute Adresse, wenn Sie Antworten auf IIS-bezogene Fragen suchen.

Fergus Strachan ist Gründer und Leiter von Maestra Ltd London, einer Beratungsfirma mit Spezialisierung auf IT-Infrastrukturentwurf und Projektmanagement-Unterstützung. Zu den Kunden des Unternehmens gehören internationale Banken und Bildungsinstitutionen in Großbritannien. Fergus Strachan verfasst Artikel über Microsoft-Servertechnologie und ist Autor der Publikation Integrating ISA Server 2006 with Microsoft Exchange 2007. Er ist Mitautor von Microsoft Exchange Server 2003 Resource Kit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig