So heute der zweite Teil des Gastbeitrages von Andreas Buschmann, der erste Teil erschien gestern.
Teil 2
Einführung von Redundanten Elementen
Wenn die Verfügbarkeit einer Hot Standby Lösung nicht ausreichend ist, oder eine Hot Standby Lösung nicht möglich ist, gibt es die Möglichkeit Redundante Elemente einzusetzen.
Redundante Server
zwei oder mehr baugleiche Server sind gleichzeitig aktiv, und arbeiten parallel.
Bei einem Ausfall eines der Server übernimmt der/die verbleibenden Server die volle Last.
Für die Verteilung der http Requests auf die Server ist ein Loadbalancer erforderlich, der die eingehenden Requests auf die vorhandenen verfügbaren Server verteilt.
Weiterhin ist ein Mechanismus erforderlich, der die Daten zwischen den Servern konsistent hält.
Das wieder aktivieren eines ausgefallenen Servers muß in der Regel manuell geschehen, da vorher die Konsistenz der Daten gesichert werden muß.
Single point of failure ist jetzt nicht mehr der Webserver, sondern der Loadbalancer und die Datenhaltung.
Loadbalancer
Wenn aus Last- oder aus Verfügbarkeitsgründen eine Webseite von mehreren Servern parallel präsentiert werden soll, ist ein Loadbalancer zwischen Webbrowser und Webserver erforderlich.
Die Einführung eines Loadbalancers erzeugt mehrere Probleme:
- Ein Loadbalancer ist ein zusätzlicher single point of failure.d.h. in der Regel ist ein Loadbalancer Paar erforderlich.
(active/passive oder active/active) - Ein Loadbalancer kann niemals komplett transparent sein. Die Implementierung der Webseite muß auf den Loadbalancer abgestimmt werden.
- in der Regel müssen alle Zugriffe einer Websession den selben Webserver erreichen.Wenn ein Webserver ausfällt, muß eine Websession in der Regel neu aufgebaut werden; was vom Kunden bemerkt wird.
- Loadbalancer sind im Verhältnis zu PC-Servern teuer.
- Einige verfügbare Loadbalancer sind limitiert auf
- IPv4
- 1GBit Ethernet
- bestimmte Netzwerk Konfigurationen
- NAT
- Insbesondere neuere Loadbalancer basieren auf PC-Server Hardware, und haben daher keine besseren Verfügbarkeiten, als PC-Server selbst.Verfügbarkeiten und Lebensdauer, wie von Cisco Routern und Switchen gewohnt wären wünschenswert.
Datenhaltung
Ab Hot Standby Servern ist die Synchronisation der Datenhaltung ein Problem, welches vom Design der Webpräsentation bzw. des Webshops berücksichtigt werden muß.
Bei einer reinen Webpräsentation, die keine Daten welche sie vom Webbrowser entgegen nimmt persistent speichern muß, besteht noch die Möglichkeit alle Dateien über ein spezielles FTP Programm hochzuladen, welche jede Datei auf alle verfügbaren Webserver verteilt, bevor die Datei als hochgeladen markiert wird.
Wenn ein in Wartung befindlicher Server wieder aktiv geschaltet werden soll, muß die folgende Reihenfolge eingehalten werden, um die Konsistenz der Daten zu gewährleisten:
- Abschalten des FTP Uploads
- Synchronisieren des Datenbestandes von einem aktiven Rechner auf den neu hinzuzufügenden.
- Wieder aktivieren des FTP Uploads
Wenn das nicht möglich ist, oder die Webserver auf ihren Datenbestand selbst schreiben sollen ist eine andere Lösung erforderlich.
Verwendet werden können:
- ein globales Filesystem (GFS)
(unüblich)
(Performance Probleme mit vielen kleinen Dateien) - ein NFS Server
(neuer single Point of Failure)
hilft nur für die Verfügbarkeit, wenn regelmäßig Änderungen an den Webservern erforderlich sind, und der NFS Server sehr selten angefaßt werden muß.Bis vor fünf Jahren konnte hier ein Sun Sparc Server unter Solaris verwendet werden, der eine höhere Verfügbarkeit als PC-Server hatte. Ist heute in der Regel entweder nicht möglich, oder nicht bezahlbar. - eine NFS Appliance
(neuer single Point of Failure)
z.B.: NetApp - Replizierte Datenbanken
Virtualisierung
Eine Virtualisierung löst hier keine Probleme, sondern erzeugt zusätzliche Wartungszeiten.
Ansonsten wie Virtualisierung ohne redundante Elemente.
Verteilung auf mehrere Standorte
Die Voraussetzung hier ist, daß man die redundanten Elemente schon im Griff hat.
Zwei Standorte
Die Loadbalancer werden auf beide Standorte verteilt.
Die Server werden auf beide Standorte verteilt.
Datenkonsistenz
Es sind zwei NFS Server oder zwei NFS Appliances erforderlich, die im Master Slave Betrieb jeweils die Daten vom primären Gerät auf das standby Gerät spiegeln.
Zur Optimierung können ggf. die Daten in zwei Partitionen unterteilt werden, so daß jedes Gerät für eine Partition Master ist.
Wenn die Standorte mehr als N km von einander entfernt sind, ist eine synchrone Spiegelung nicht mehr möglich, da dadurch die Schreibgeschwindigkeit zu sehr beeinträchtigt wird.
Eine asynchrone Spiegelung erzeugt aber einen Datenverlust beim Umschalten vom primären auf das standby Gerät.
Das Umschalten muß beim asynchronen Spiegeln manuell gemacht werden.
Drei Standorte
Loadbalancer
- Eine Unterstützung von drei Standorten ist bei Loadbalancern unüblich. ggf. müssen an jedem Standort zwei Loadbalancer aufgebaut werden, oder die Loadbalancer müssen speziell partitioniert werden.
Datenhaltung
- Ein automatisches Failover bei einer auf drei Standorte verteilte Datenhaltung ist möglich.zwei Standorte mit Disksystemen und ein Standort mit Voter ist u.U. möglich.
- Ein mögliches Problem ist die notwendige Verkabelung zwischen den Standorten. Mir ist nicht klar, ob alle Leitungen die selbe Bandbreite benötigen, oder ob die Leitungen zum Voter eine niedrigere Bandbreite haben dürfen. Was geschieht, wenn die Hauptleitung ausfällt?
Datenkonsistenz
zum Thema verteilte bzw. replizierte Datenhaltung schreibe ich noch einen eigenen Artikel.
geplante Downtimes
geplante Downtimes sind:
- Updates
- von Firmware
- des Betriebsystems
- des Webservers
- der Webseiten
- der Datenbank Software
- Reparatur von Hardware
- Austausch von Hardware
- Umverkabeln des Netzwerks
- Umziehen von Komponenten in andere Racks
ungeplante Downtimes
- Ausfälle durch Fehler
- in der Hardware
- im Netzwerk
- in der Stomversorgung
- im Betriebssystem
- in der Software
weitere Artikel
Für nähere Details werde ich eigene Artikel schreiben.
Insbesondere will ich auf die Datenhaltung für Hochverfügbare Systeme eingehen.