Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-2
Pfeil 17 Webserver (IIS)
Pfeil 17.1 Begriffsdefinitionen
Pfeil 17.1.1 Webapplikation vs. Webservice
Pfeil 17.1.2 Website vs. Webseite
Pfeil 17.2 ASP.NET
Pfeil 17.2.1 Die Entwicklungsumgebung
Pfeil 17.2.2 Clientseitig: JavaScript
Pfeil 17.2.3 Die web.config-Datei
Pfeil 17.2.4 Kompilierung und Vorkompilierung
Pfeil 17.2.5 Sicherheit und ASP.NET
Pfeil 17.3 Installation
Pfeil 17.4 Kurzer Überblick über die Architektur des Webservers
Pfeil 17.4.1 Architektur
Pfeil 17.4.2 Anforderungsverarbeitung
Pfeil 17.4.3 Anforderungsverarbeitung im Anwendungspool
Pfeil 17.4.4 Die »Modulbauweise«
Pfeil 17.5 Webserver, Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
Pfeil 17.5.1 Die Zusammenhänge
Pfeil 17.5.2 Webserver
Pfeil 17.5.3 Anwendungspool
Pfeil 17.5.4 Website
Pfeil 17.5.5 Anwendung
Pfeil 17.5.6 Virtuelles Verzeichnis
Pfeil 17.6 Authentifizierung
Pfeil 17.6.1 Anonyme Authentifizierung
Pfeil 17.6.2 Standardauthentifizierung
Pfeil 17.6.3 Digestauthentifizierung
Pfeil 17.6.4 Windows-Authentifizierung
Pfeil 17.6.5 Authentifizierungsdelegierung
Pfeil 17.6.6 Webanwendungen und Kerberos
Pfeil 17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang
Pfeil 17.6.8 Formularauthentifizierung
Pfeil 17.7 Autorisierung
Pfeil 17.7.1 NTFS-Berechtigungen
Pfeil 17.7.2 URL-Autorisierung
Pfeil 17.8 Sonstiges zum Thema »Sicherheit«
Pfeil 17.8.1 SSL-Verschlüsselung
Pfeil 17.8.2 .NET-Vertrauensebenen
Pfeil 17.8.3 IP- und Domäneneinschränkungen
Pfeil 17.9 Sitzungszustand
Pfeil 17.10 Load Balancing und Redundanz
Pfeil 17.10.1 Verwendung von Microsoft NLB
Pfeil 17.10.2 Remoteanforderungen
Pfeil 17.10.3 Freigegebene Konfiguration
Pfeil 17.10.4 Sitzungsstatus
Pfeil 17.10.5 Datenbankserver
Pfeil 17.11 Administration
Pfeil 17.11.1 Remote-Administration
Pfeil 17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer
Pfeil 17.11.3 Delegierung von Features
Pfeil 17.11.4 Protokollierung
Pfeil 17.12 Der Best Practice Analyzer (BPA)
Pfeil 17.13 IIS-Schlussbemerkung


Galileo Computing - Zum Seitenanfang

17.9 Sitzungszustand & Co. topZur vorigen Überschrift

Bei der Planung von Webanwendungen ist der Sitzungszustand ein wichtiges Thema. Wenn eine Webanwendung nur statische Webseiten (z. B. mit Produktabbildungen) anzeigt und keine Authentifizierung der Benutzer vornimmt, stellt sich die Frage nach dem Sitzungszustand nicht. Wenn aber mehr oder weniger komplexe Business-Applikationen bereitgestellt werden, ist der Sitzungszustand ein extrem wichtiger Aspekt. Im Sitzungszustand wird beispielsweise gespeichert, ob der Benutzer authentifiziert ist, welche Daten er abgerufen hat, an »welcher Stelle« der Webapplikation er sich gerade befindet und vieles andere mehr.

Abbildung 17.114 zeigt die zu lösende Aufgabenstellung:

  • Ein Client greift auf eine Webserver-Farm zu. Damit alle Server gleichmäßig genutzt werden und es im Fall eines Ausfalls nicht zu Unterbrechungen kommt, wird ein Load Balancer verwendet (siehe auch Abschnitt 20.3). Der Client spricht nur eine IP-Adresse an, und die Anfragen werden vom Load Balancer auf mehrere Server verteilt.
  • Wie Sie sehen, leitet der Load Balancer den ersten Zugriff an den obersten Server, den zweiten an eines der unteren Systeme.
  • Damit der Server, der den zweiten Zugriff bedient, vereinfacht gesagt »an der richtigen Stelle weitermacht«, benötigt er die Sitzungsstatus-Informationen. So kann er beispielsweise die Authentifizierung, die vom oberen Server durchgeführt worden ist, weiterverwenden. Ohne Sitzungsstatus müsste jeder Server »von vorn« anfangen, was das Konzept der Lastverteilung ad absurdum führen würde.

Die Clients identifzieren sich gegenüber dem Server übrigens durch Cookies oder URL-Rewriting.

Abbildung 17.114 In einer Webserver-Farm kann es durchaus passieren, dass zwei Anfragen des Servers von zwei verschiedenen Servern bearbeitet werden.


Load Balancer

Ein »vernünftiger« Load Balancer wird dafür sorgen, dass ein Client während einer Sitzung immer auf denselben Server geleitet wird (Sticky Connection). Ein zentraler Zustandsserver macht natürlich Sinn, falls einer der Webserver während einer Sitzung nicht mehr erreichbar ist. Würde der Benutzer ohne eine zentrale Speicherung des Sitzungszustands auf einen anderen Server geleitet, finge er sozusagen bei null an.

Beim Microsoft NLB kann das Verhalten des Load Balancings konfiguriert werden (siehe auch Abschnitt 20.3).

Und noch eine Ergänzung zu Abbildung 17.114: Die Webserver sind hier redundant vorhanden, der Server für den Sitzungszustand aber nicht. Wenn das Ziel eine Hochverfügbarkeit ist, müsste man diese Komponente ebenfalls redundant machen.


Wie Sie in Abbildung 17.115 sehen, gibt es für das Sitzungszustandsmodul fünf Einstellungen:

  • Nicht aktiviert: Dies kommt nur für Szenarien infrage, in denen einem anonymen Benutzer statische Webseiten gezeigt werden.

Abbildung 17.115 Mit diesem Dialog konfigurieren Sie, wie der Sitzungszustand gespeichert werden soll. Außerdem kann festgelegt werden, ob Cookies oder URL-Rewriting genutzt wird.

  • In-Process: Bei dieser Einstellung verwaltet der IIS-Prozess den Sitzungszustand intern. Diese Einstellung ist dann richtig, wenn ein Internet Information Server allein arbeitet und keine Webserver-Farm mit Load Balancing existiert.
  • Zustandsserver: Der ASP.NET Zustandsserver ist ein auf einem Server zu aktivierender Dienst, der ein Nutzungsszenario ermöglicht, wie es in Abbildung 17.114 gezeigt ist.
  • SQL Server: Anstelle des ASP.NET-Zustandsservers kann für Webserver-Farmen mit Load Balancing auch eine SQL-Datenbank verwendet werden. Dieses Szenario kommt in sehr stark belasteten Webserver-Farmen mit sehr vielen gleichzeitigen Benutzern in Betracht. Die SQL Server-basierte Sitzungszustandsverwaltung ist skalierbarer als der ASP.NET Zustandsserver – vorausgesetzt, Sie haben für den SQL Server leistungsfähige Hardware beschafft.

Die zweite Konfigurationsmöglichkeit betrifft die Verwendung (oder Nichtverwendung) von Cookies. Bei der Kommunikation eines Clients mit einem Server via HTTP/S muss der Client sich bei jeder Anforderung identifizieren. Dies kann entweder durch das Setzen eines Cookies oder die Modifikation der URL erfolgen. Obgleich jeder einigermaßen ernst zu nehmende Browser mit Cookies umgehen kann, könnten diese ausgeschaltet sein. In diesem Fall bietet sich als Alternative das bereits genannte URL-Rewriting an. URL-Rewriting funktioniert immer, es sei denn, dass die resultierenden URLs für einen Browser zu lang werden, was insbesondere bei älteren Mobilgeräten (PDAs, Smartphones etc.) passieren könnte.

Abbildung 17.116 Der ASP.NET-Zustandsdienst ist standardmäßig installiert, aber nicht gestartet.

Etwas weiter vorn habe ich den ASP.NET-Zustandsdienst erwähnt. Hier noch ein kurzer Nachtrag zu diesem Thema: Bei der Installation von ASP.NET wird dieser automatisch mitinstalliert, allerdings nicht gestartet. Dies ist beispielsweise im Server-Manager zu sehen (Abbildung 17.116). Wenn Sie ihn nutzen möchten, starten Sie ihn auf einem Webserver! Es ist natürlich notwendig, dass alle Webserver einen einzigen ASP.NET-Zustandsdienst verwenden und nicht jeder seinen eigenen nutzt. Letzteres würde technisch sogar funktionieren, verfehlt aber seinen Zweck, denn schließlich geht es ja genau um die serverübergreifende Zustandsverwaltung.

Das eigentlich nicht ganz unkomplizierte Thema der Sitzungsverwaltung wird durch ASP.NET sowohl für den Entwickler als auch für den Administrator sehr problemlos. Als Administrator müssen Sie lediglich konfigurierend aktiv werden, wenn Sie bei einer Webserver-Farm den Sitzungszustand serverübergreifend speichern müssen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de