17.10 Load Balancing und Redundanz

Webanwendungen sind ohne Zweifel wichtig, teilweise sogar unternehmenskritisch: Demzufolge müssen Sie sich sowohl über Performance als auch über Redundanz Gedanken machen. Um Webserver verfügbar zu machen, baut man nun aber keine Failover-Cluster auf, sondern arbeitet auf Netzwerkebene. Das funktioniert dann in etwa so, wie in Abbildung 17.122 gezeigt:

• Die Clients greifen auf eine virtuelle IP-Adresse zu. Hinter dieser kann sich entweder ein Hardware-Load-Balancer verbergen oder eine integrierte Technologie wie das Microsoft Network Load Balancing (NLB). Im ersten Fall ist zu überlegen, wie man den eingesetzten Hardware-Load-Balancer redundant macht.
• Fällt ein Webserver aus, können die anderen dessen Anforderungen bedienen.
• Ein angenehmer Nebeneffekt dieses Technologieansatzes ist, dass eine Performance-Verbesserung durch Load Balancing erfolgt. Der Einsatz von vier Servern bedeutet prinzipiell, dass die vierfache Last an Anforderungen bedient werden kann. In der Praxis wird man immer so dimensionieren, dass die Last auch von n-1 Servern abgefangen werden könnte, um Reserven für den Ausfall einer Maschine zu haben.

In Abbildung 17.122 sieht das vermutlich ganz einleuchtend aus, allerdings müssten einige Aspekte berücksichtigt werden, die in den nächsten Abschnitten dargestellt sind.

Abbildung 17.122 Webserver werden nicht mit einem Failover-Cluster redundant gemacht, sondern auf Netzwerkebene. Ein zusätzlicher angenehmer Nebeneffekt ist eine Performance-Optimierung durch Load Balancing.

17.10.1 Verwendung von Microsoft NLB

Es gibt gleich eine gute Nachricht, denn die Technologie für das Network Load Balancing ist in Windows Server 2008/2012/R2 bereits »eingebaut«. Das Microsoft NLB wird in Abschnitt 20.3 ausführlich besprochen. Auch die Besonderheiten der Kerberos-Authentifizierung in einer Webserver-NLB-Umgebung werden dort diskutiert (Abschnitt 20.3.4).

17.10.2 Remoteanforderungen

Eine Webanwendung benötigt stets mehr oder weniger viele Dateien. Bei einer ASP.NET-Anwendung sind dies in erster Linie .aspx-Dateien, aber auch statische Elemente wie beispielsweise Bilddateien. Zur Bereitstellung dieser Daten gibt es grundsätzlich zwei Wege:

• Alle Dateien werden auf die lokalen Festplatten der einzelnen Server verteilt. Sinnvollerweise sorgt man über einen automatischen Mechanismus (Softwareverteilung) dafür, dass alle Server denselben Stand haben.
• Es böte sich natürlich auch an, die Dateien auf einem gemeinsamen Dateiserver abzulegen. Das ist durchaus charmant, denn Sie sparen sich die »Verteilerei«; allerdings müssten wir hier schon mit einem Dateiserver-Cluster planen: Es macht nicht viel Sinn, über redundante Webserver zu verfügen, aber zu riskieren, dass diese allesamt durch einen nicht-redundanten einzelnen Dateiserver außer Gefecht gesetzt werden. Man würde also das Szenario aus Abbildung 17.123 aufbauen.

Abbildung 17.123 Eine mögliche Variante ist die Bereitstellung der Anwendungsdateien auf einem Dateiserver-Cluster.

Wenn Sie sich dafür entscheiden, die Daten der Webserver auf eine gemeinsame Netzwerkressource (Dateiserver) zu legen, werden Sie sich vermutlich Gedanken über die Zugriffssicherheit machen. Falls die Webanwendung die Identität des angemeldeten Benutzers annimmt, können Sie die potenziell zugreifenden Benutzer für die Freigabe berechtigen. (Beachten Sie die Authentifizierungsdelegierung aus Abschnitt 17.6.5.)

Falls die Webanwendungen mit der Identität des Anwendungspools laufen und dieser eines der »eingebauten« Konten ist, beispielsweise Netzwerkdienst, wird es mit dem Einstellen der Berechtigungen schwierig: Konten wie der Netzwerkdienst sind nur auf der eigenen Maschine gültig. Die Lösung ist allerdings einfach: In den Grundeinstellungen einer Webanwendung (übrigens auch in denen eines virtuellen Verzeichnisses) können Sie einstellen, mit welcher Identität zugegriffen werden soll (Abbildung 17.124). Es kann entweder der Anwendungsbenutzer oder ein Bestimmter Benutzer ausgewählt werden. Beim Anwendungsbenutzer wird die Identität verwendet, mit der die Webanwendung ausgeführt wird. Dies kann entweder die Poolidentität oder bei Verwendung des ASP.NET-Identitätswechsels (Impersonation) diejenige des angemeldeten Benutzers sein.

Abbildung 17.124 In den Grundeinstellungen einer Anwendung kann festgelegt werden, mit welcher Identität auf den Speicherort zugegriffen werden soll.

17.10.3 Freigegebene Konfiguration

Die Webserver in einem NLB-Cluster sind notwendigerweise identisch konfiguriert. Es wäre natürlich einigermaßen unschön, wenn in einer großen Farm zigfach dieselbe Serverkonfiguration erstellt werden müsste.

Ähnlich wie bei den zuvor besprochenen Remoteanforderungen kann die Konfiguration an einer zentralen Stelle abgelegt und von allen Webservern verwendet werden.

Abbildung 17.125 zeigt die Konfigurationsseite Freigegebene Konfiguration:

• Mit der Funktion Konfiguration exportieren (in der Aufgabenleiste Aktionen) kann die aktuelle Konfiguration in ein Verzeichnis exportiert werden, das sinnvollerweise auf einem gemeinsam genutzten Dateiserver liegt.
• Auf den einzelnen Webservern wird mit der Checkbox Freigegebene Konfiguration aktivieren auf die Nutzung der gemeinsamen Konfiguration umgeschaltet.

Abbildung 17.125 Die Konfiguration der »freigegebenen Konfiguration«

17.10.4 Sitzungsstatus

Grundlegende Informationen über den Sitzungsstatus finden Sie in Abschnitt 17.9. An dieser Stelle möchte ich darauf hinweisen, dass Sie mindestens dann, wenn in einem NLB-Cluster Keine Affinität konfiguriert ist, die Informationen zum Sitzungszustand auf einem gemeinsam genutzten System ablegen müssen.

17.10.5 Datenbankserver & Co.

Für die von Webanwendungen auf NLB-Clustern genutzten »Back-End«-Systeme (wie beispielsweise Datenbankserver) gilt, dass diese konsequent redundant ausgelegt sein sollten bzw. müssen. Es wäre zu ärgerlich, wenn die schöne Webfarm nicht funktioniert, weil der Datenbankserver nicht mehr funktioniert.

Auch wenn dieses Buch sich nicht weiter um Details der SQL Server-Implementierung kümmert, sei darauf hingewiesen, dass es neben dem klassischen Failover-Cluster weitere interessante Hochverfügbarkeitsszenarien für SQL Server gibt. Insbesondere sei die Datenbankspiegelung genannt.

---

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.