17.9 Sitzungszustand & Co.
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.119 In einer Webserver-Farm kann es durchaus passieren, dass zwei Anfragen des Servers von zwei verschiedenen Servern bearbeitet werden.
Abbildung 17.119 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 weiterverwenden, die vom oberen Server durchgeführt worden ist. Ohne Sitzungsstatus müsste jeder Server »von vorn« anfangen, was das Konzept der Lastverteilung ad absurdum führen würde.
Die Clients identifizieren sich gegenüber dem Server übrigens durch Cookies oder URL-Rewriting.
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.119: 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.120 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.
- 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.119 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.120 Mit diesem Dialog konfigurieren Sie, wie der Sitzungszustand gespeichert werden soll. Außerdem kann festgelegt werden, ob Cookies oder URL-Rewriting genutzt wird.
Etwas weiter vorn habe ich den ASP.NET-Zustandsserver 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.121). 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.
Abbildung 17.121 Der ASP.NET-Zustandsdienst ist standardmäßig installiert, aber nicht gestartet.
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.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.