IIS fuer Einsteiger - Arbeitsweise verstehen

IIS für Einsteiger – Teil 3
IIS Arbeitsweise verstehen: Anwendungspool, Arbeitsprozess und Co.
In den beiden vorangegangen Kapiteln haben wir den IIS installiert und 2 Beispielwebseiten angelegt.
Nur wer oder welcher Windows Prozess ist für die Abarbeitung der http-Anfragen auf die beiden
Websites verantwortlich?
Für die Verarbeitung einer Http-Anfrage sind mehrere Stellen des IIS verantwortlich, den
Administrator und Entwickler sollten jedoch besonders die sog. Arbeitsprozesse interessieren. (siehe
Introduction to IIS 7 Architecture)
Warum sind Arbeitsprozesse interessant?
Weil ein Arbeitsprozess (w3wp.exe) http Anfragen verarbeitet und die dazu passende Antwort
erzeugt. Verarbeiten heißt z.B. einen Benutzer authentifizieren, Inhalte (html, jpg, etc.) von der
Festplatte | Cache holen oder ASP.NET bzw. PHP Code Ausführen lassen und das Ergebnis an den
Anfrager zurücksenden.
Was ein Arbeitsprozess tut um Anfragen zu bearbeiten lässt sich konfigurieren und
anprogrammieren.
Über die IIS Management Konsole kann ich einsehen welche http Anfragen gerade pro ausgeführten
Arbeitsprozess ausgeführt werden:
Auf einem IIS sind in der Regel mehrere Arbeitsprozesse aktiv, wie viele ist Konfigurationssache.
Warum brauche ich mehrere Arbeitsprozesse?
Das Konzept der Arbeitsprozesse ermöglicht Websites oder Teile von Websites voneinander zu
isolieren, so können z.B. 2 Websites in ihren eigenen w3wp.exe‘s laufen und unterliegen damit der
Prozessisolation des Windows OS. Zusätzlich lassen sich den Arbeitsprozessen jeweils
unterschiedliche Benutzerkonten zuweisen, dadurch kann man mittels NTFS Berechtigungen Datei
und Ordnerzugriff einschränken.
Warum sollte ich isolieren?
Das erhöht die Stabilität, weil Website X auch dann noch antwortet wenn Website Y abgestürzt ist.
Troubleshooting wird einfacher, weil man sich peel-the-onion-mäßig an den Problemteil einer
Website heran-‚isolieren‘ kann.
Sicherheit wird erhöht indem man unterschiedliche Accounts für die Arbeitsprozesse verwendet und
den Arbeitsprozessen damit nur NTFS Rechte auf den eigenen Webordner gibt.
Verhalten | Leistung von Websites wird planbarer, weil sich die Zuweisung von CPU- und SpeicherRessourcen auf die Arbeitsprozesse steuern lässt und man kontrollieren kann was passiert wenn
Limits überschritten werden. (mehr dazu Verwalten von Anwendungspools in IIS 7 und Using WSRM
to manage IIS 7 AppPool CPU Utilization)
Wie isoliere ich mit Arbeitsprozessen?
Die Arbeitsprozesse werden im IIS über Anwendungspools (Application Pool) angelegt und verwaltet:
In einem Anwendungspool ist definiert welche (Teile einer) Website von welchem
Arbeitsprozess(en) ausgeliefert werden – letztlich heißt das, dass ein Anwendungspool definiert
wer die Bearbeitung einer (oder mehrerer) URL(s) übernimmt.
Um z.B. eine Website nun einem Anwendungspool zuzuordnen sind folgende Schritte notwendig:
IIS Manager -> Sites -> Website auswählen ->Advanced Settings -> “Application Pool” drop down box
auswählen -> aus einer Liste von Anwendungspools auswählen.
In diesem Beispiel wurde eine ganze Website dem Anwendungspool „myothersite“ zugeordnet,
alternativ könnte man nur Teile z.B. ein Unterverzeichnis einem Anwendungspool zuordnen.
Voraussetzung ist, dass das Unterverzeichnis (wie z.B. unten „shop“) eine Anwendung (im Sinne des
IIS) ist:
Ordner welche als IIS Anwendungen markiert sind erhalten in der Ansicht eine kleine Weltkugel.
Was ist eine IIS Anwendung?
Eine Site ist für den IIS ein Container in dem Anwendungen und (virtuelle) Verzeichnisse mit Inhalten
(*.html, *.css, *.gif,....) und Code (ASP.NET Seiten o.ä.) liegen. Auf eine Site kann von außen z.B. über
http zugegriffen werden.
Ein (virtuelles) Verzeichnis ist für den IIS ein Ort (Pfad) wo er Inhalte einer Website findet. Dabei wird
der Name des Verzeichnisses Teil der URL der Website über die von ‚draußen‘ auf die Inhalte
zugegriffen werden kann (z.B. http://www.meinewebsite..../gallery/).
Eine IIS Anwendung (aka application) definiert wie ein Verzeichnis eine Gruppe von Dateien die
Inhalte einer Website liefert - zusätzlich kann für eine Anwendung noch die Zugehörigkeit zu einem
Anwendungspool definiert werden.
Anm.: D.h. durch ‚Aufspalten‘ meiner Website in mehrere Anwendungen wäre ich in der Lage diese
Website durch mehrere Anwendungspools ausliefern zu lassen.
(Mehr dazu unter Understanding Sites, Applications, and Virtual Directories on IIS 7)
Welche Websites (oder Anwendungen) sollten in einen Anwendungspool isoliert werden?
Persönliche Meinung des Autors: „Jede Website sollte im eigenen Anwendungspool mit eigener
Identität – idealerweise der Application Pool Identity – laufen.“ Das ist übrigens auch das
Standardverhalten beim Neuanlegen einer Website beim IIS7 unter Windows 7 oder Windows Server
2008 R2.
Um Ressourcen zu sparen mag man möglicherweise davon abrücken und mehr Websites in einen
Anwendungspool packen, jedoch in folgenden Fällen würde(müsste) ich immer isolieren:
Szenario
Link zur Vorgehensweise
Websites mit Problemen (z.B. Memory Leaks),
Verwalten von Anwendungspools in IIS 7
Experimenteller oder Beta Code sollten in
eigenen Application Pools laufen.
Websites von unterschiedlichen Leuten
 Application Pool Identities
(gehostet auf einem IIS) bei denen sichergestellt  Ensure Security Isolation for Web Sites
werden soll dass sie nicht auf die Inhalte des
anderen zugreifen (lesen, schreiben, löschen)
können.
Websites welche unterschiedliche .NET
s.o.
Framework-, PHP- Versionen o.ä. verwenden.
Wenn die IIS-Anwendung einen höher
Specify an Identity for an Application Pool (IIS 7)
privilegierten Benutzerkontext braucht.
Wenn IIS-Anwendungen zu IIS 6 kompatibel sein  Introduction to IIS 7 Architecture #IIS 7
müssen bzw. wenn ASP.NET 1.1 auf IIS7
Application Pools
verwendet werden soll
 How to install ASP.NET 1.1 with IIS7 on Vista
and Windows 2008
Was sind jetzt die wichtigsten Einstellungen für einen Anwendungspool?
Sehen wir uns dazu die Einstellungen des Anwendungspools „myothersite“an:
IIS Manager -> Application Pools -> doppelclick auf „myothersite“:
Der Name eines Anwendungspools muss eindeutig und sollte aussagekräftig sein. Pro
Anwendungspool kann nur eine Version des .NET Frameworks geladen werden (Evtl. mit dem
Entwickler abklären, welche Version des .NET Frameworks benötigt wird).
Der Managed pipeline mode bestimmt welche Architektur im Arbeitsprozess (w3wp.exe) genommen
wird:
 classic: IIS 6 kompatibel
 integrated: IIS7 Architektur
Der Managed pipeline mode beeinflusst wann .NET Module aufgerufen werden und das hat
Auswirkung wie http Anfragen abgearbeitet werden.
Persönliche Meinung des Autors: “Ich würde Anwendungspools immer im Integrated Pipeline Mode
betreiben, weil: neu, verständlicher, erweiterbarer und nur bei Problemen den Classic Modus
verwenden“
(Mehr dazu Introduction to IIS 7 Architecture und ASP.NET Integration with IIS 7)
Anwendungspool-Identität und Recycling
Für Mehr Isolation/Sicherheit und Stabilität sollte man noch 2 Einstellungen von Anwendungspools
kennen:
IIS Manager -> Application Pools -> „myothersite“ auswählen -> Advanced Settings auswählen:
Identität
Der Benutzerkontext unter dem der Arbeitsprozess läuft kann ein Built-in Account wie z.B. Network
Service, die ApplicationPoolIdentity oder ein anderer Windows Benutzer sein.
Was ist eine ApplicationPoolIdentity?
Seit Windows 7 (oder Windows Server 2008 R2, bzw. ab Windows Server 2008 Service Pack 2) kann
der IIS7 pro ApplicationPool einen virtuellen Benutzer verwenden – die sog. ApplicationPoolIdentity.
Dieser Benutzer trägt den gleichen Namen wie der Anwendungspool.
Vorteile von ApplicationPoolIdentities:
 Haben nur die minimal notwendigen Rechte
 Werden vom IIS automatisch angelegt (d.h. kein Eingeben von Passwörtern: kein Vergessen
&Verfallen)
 Ich kann NTFS Rechte pro ApplicationPoolIdentity vergeben z.B. um Zugriff auf WebVerzeichnis einzuschränken – Isolation.
Beispiel: Anwendungspool „myothersite“ läuft unter der ApplicationPoolIdentity im Taskmanager
sehe ich den Arbeitsprozess w3wp.exe dessen Benutzername „IIS AppPool\myothersite“ ist:
(mehr dazu Application Pool Identities)
Recycling
Standardmäßig wird der Arbeitsprozess(e) eines Anwendungspools nach 29min (=1740 min) neu
gestartet („Regular Time Intervals“). Das gibt bis dahin vergebenen Speicher wieder frei und
initialisiert die Webanwendung. Dabei wird ein neuer Arbeitsprozess gestartet, dieser bekommt
neue eingehende http-Anfragen zugewiesen. Der ‚alte‘ Arbeitsprozess(e) darf seine verbleibenden
Anfragen abarbeiten und wird dann beendet. D.h. das Recyclen geht ohne Ausfallzeit und der
Websitebesucher merkt davon nichts (=Overlapped Recycle). Um Ressourcen zu sparen wird ein
neuer Arbeitsprozess immer nur dann gestartet wenn auch wirklich http-Anfragen dafür anliegen –
d.h. die erste http Anfrage nach 30min Leerlauf auf einen Webserver könnte wegen des Startups ein
bisschen länger dauern. (Abhilfe siehe:Using the IIS Application Warm-Up Module)
Ist die Webanwendung gut programmiert, geht bewusst mit Ressourcen um und ist über einen
längeren Zeitraum stabil dann spricht nichts dagegen das Zeitraum für das Recycling zu verlängern
oder ganz abzuschalten.
(mehr unter Verwalten von Anwendungspools in IIS 7)
Kurz zusammengefasst:
Der IIS bearbeitet http-Anfragen durch die Arbeitsprozesse (w3wp.exe).
(Teile von) Websites lassen sich über die Arbeitsprozesse voneinander isolieren für mehr Stabilität.
Arbeitsprozesse und Stabilitäts-Funktionalitäten werden im IIS über Anwendungspools konfiguriert.
Weiterführend empfehle ich Introduction to IIS 7 Architecture zu lesen.
Wer einfach mal sehen möchte worauf ein w3wp.exe unter welchem Account zugreift sollte mit dem
Process Monitor spielen – auch für Troubleshooting zwecke ganz hilfreich: