Hochverfügbarkeit am Beispiel einer Webpräsentation oder eines Webshops 1

So, heute ein Gastbeitrag von Andreas Buschmann in zwei Teilen. Den zweiten Teil gibt es morgen.

Teil 1

Von dem Moment an, an dem eine Webpräsentation oder ein Webshop ernsthaft Benutzt wird, ist die Verfügbarkeit der zugehörigen Webseiten relevant.

Ernsthaft Benutzt bedeutet in diesem Fall, die Nicht Erreichbarkeit der Webseiten tut dem Eigentümer weh. (z.B. Einnahmenausfall oder es paßt nicht zum Renommee).

Die Verfügbarkeit von Webseiten wird ggf. vertraglich vereinbart, dabei werden oft die Begriffe „best effort“, bestimmte erlaubte Ausfallzeiten, oder N Neunen verwendet.
Die Vertragliche Situation (oder die in house gewünschte Verfügbarkeit) muß dann irgendwie auf eine technische Implementierung abgebildet werden, dazu gehört dann auch ein Satz Regeln für das Management der Hard- und Software.

Die Verfügbarkeit von Webseiten kann durch technische Maßnamen bei der Implementierung beeinflußt werden werden, die ich im weiteren betrachten möchte.
Ich beschränke mich hier auf die Serverstruktur. Die Netzwerkstruktur ist auch relevant, kann aber gesondert betrachtet werden. (Switche und Router haben im Regelfall höhere Verfügbarkeiten als Server.)

Ohne spezielle Anforderungen

Wenn keine speziellen Anforderungen an die Verfügbarkeit von Webseiten vorliegen, so werden diese in der Regel auf einem für eine Firma normalen Server abgelegt. d.h. wenn in der Regel Dell R420 verwendet werden, dann werden die Webseiten auch auf einem solchen Server abgelegt.
Ziel ist hier die Minimierung der Arbeitszeit für die Administratoren, die Einfachheit der Beschaffung, und die Minimierung der vorzuhaltenden Ersatzteile.

Alle weiteren Aufwände erzeugen zusätzliche Kosten, die gegen die Kosten, die ein Ausfall des Webserver erzeugt, abgewogen werden müssen.

Best Effort

Es wird ein Server ausgewählt, der eine höhere Verfügbarkeit hat, als der in einer Firma verwendete Standardserver.

Bis zur Übernahme von Fa. Sun durch Oracle, war es hilfreich für die Verfügbarkeit einen Sun Sparc Server mit Solaris statt einen PC Server mit Linux zu nehmen.
Der letzte preiswerte Sun Sparc Server war allerdings die Sun T1000.

Alternativ ist ein IBM PC Server in der Regel zuverlässiger als ein NoName Server. Es sollte aber schon ein 2HE Server sein.

Wenn AIX in der Firma bekannt, und im Einsatz ist, kann ein RS6000 Server mit AIX verwendet werden. Ist aber relativ teuer und unüblich.

Aktuelle Optionen:

• Der Server wird mit redundanten Netzteilen ausgestattet, diese werden an zwei verschiedene Stromkreise angeschlossen.
  Hier ist darauf zu achten, das zwei Netzteile, und zwei Eingänge vorhanden sind.
  Redundante Netzteile, die aus drei Elementen bestehen, machen regelmäßig Probleme, da in der Regel zwei gleichzeitig benötigt werden, und drei unabhängige Stromversorgungen unüblich sind.
• Der Server wird mit ECC RAM ausgestattet.
• Einen 2HE Server nehmen, statt einen 1HE Server.
• SAS Platten verwenden anstelle von SATA Platten.
• RAID 1 oder höher statt ohne RAID oder RAID 0.
  Hier ist aber in der Regel Hardware RAID erforderlich.
  Software RAID funktioniert unter Linux prima, aber die erforderlichen Downtimes beim Tauschen der Platten sind in der Regel länger.
• Remote Management auf Betriebssystem Ebene.Zugang zum Server für die Admins auch Nachts und am Wochenende, von zu Hause aus. ggf. über VPN.Spart im Fehlerfall die Zeit für die Anfahrt.
  Fehlerbehebung außerhalb der normalen Arbeitszeiten wird regelmäßig nur vertraglich zugesichert, wenn dieses Remote Management möglich ist.
• Remote Management Karte im Server.
  z.B. iLO bei HP, iDRAC bei Dell
  Ermöglicht das Debuggen eines Servers, wenn sich das Betriebssystem aufgehängt hat, oder in einen Zustand gerät, in dem ein Zugriff über den normalen Netzwerkzugang nicht mehr möglich ist.Hier ist zu beachten, daß die zugehörige Software regelmäßig Probleme bereitet, sei es, daß ein Betriebssystem spezifischer Client benötigt wird, der nicht überall läuft, sei es daß eine ganz spezielle Java Version erforderlich ist, oder auch nur, daß eine Tastenkombination gedrückt werden muß, die sich auf dem Linux PC des Notdienst Admins nicht auslösen läßt.Der kleine Bruder ist hier IPMI, mit dem man zumindest einen Reboot eines Servers auslösen kann, und wenn Eingerichtet, Zugriff auf einen seriellen Login auf den Server hat.Weniger mächtig als die remote Management Karte, macht aber weniger Software Probleme beim Zugriff.
• Sicherung der Stromversorgung durch eine USV.
  Hier ist zu Beachten, daß eine kleine Tisch USV oder eine kleine Rack taugliche USV die Verfügbarkeit eines Servers durchaus verschlechtern kann.
  In deutschen Städten ist die Verfügbarkeit des Stromnetzes der Stadtwerke besser als ein Ausfall pro Jahr.
  Kleine USVs sind oft schon nach drei Jahren defekt, oder benötigen neue Akkus.Wenn eine USV, dann nur eine große (> 15 kVA), fest eingebaute. Ein STS für die USV Wartung ist erforderlich.Weiterhin sollten USVs nur im Zusammenhang mit redundanten Netzteilen verwendet werden. Gerade bei kleinen USVs ist es erforderlich, den zweiten Stromanschluß direkt mit dem Normal Netz (Strom von den Stadtwerken) zu verbinden.
• Sicherung der Stromversorgung durch eine Netzersatzanlage (Diesel oder Erdgas).Macht nur in Verbindung mit einer USV Sinn.Ist wie in der Regel die USV ein Ausstattungsmerkmal des RZ, in dem ein Server untergebracht wird.
  d.h. der Server muß ggf. in einem anderen RZ untergebracht werden.

Wartungvertrag mit 4 Stunden Reaktionszeit

Eine Option, die man bei teuren Servern anstelle eines dedizierten Ersatzgerätes kaufen kann. Bei vielen Servern ist ein dediziertes Ersatzgerät preiswerter.

Nur die Reaktionszeit des Lieferanten ist 4 Stunden. Die Lieferzeit der Ersatzteile und die Zeit für das Beheben des Schadens ist da nicht mit drin.

Dediziertes Ersatzgerät

Es wird ein baugleiches Ersatzgerät für den Webserver im Lager vorgehalten.

Im Schadensfall werden die Platten aus dem defekten Webserver in das Ersatzgerät umgesteckt.

Hier ist ein übliches Problem, daß dieses Ersatzgerät mal eben für einen anderen Zweck verwendet wird, und dann nicht sofort auffindbar ist.

In der Regel sollte ein Großteil der Punkte aus „best Effort“ beachtet werden, damit das finanziell Sinn macht.

Ist das Minimum, um überhaupt eine bestimmte Verfügbarkeit vertraglich anbieten zu können.

Cold Standby

Ein dediziertes Ersatzgerät wird ins Rack gebaut, fertig verkabelt, die Software installiert, und das Gerät getestet.

Im Schadensfall wird entweder ein Backup der Daten eingespielt, oder die Platten aus dem defekten Webserver in das Ersatzgerät umgesteckt.

Hier ist ein übliches Problem, daß die Netzwerkverbindungen des Ersatzgerätes unbemerkt verändert oder abgebaut werden können.

Warm Standby

Ein dediziertes Ersatzgerät wird wie bei Cold Standby eingerichtet, aber nicht wieder ausgeschaltet.
Das Ersatzgerät wird in die Überwachung aufgenommen. Das Ersatzgerät bekommt regelmäßig (z.B.: 1x am Tag) die aktuellen Daten und Konfiguration des primären Gerätes kopiert.
Die Webserver Software kann laufen, muß aber nicht.

Im Schadensfall wird das primäre Gerät abgeschaltet, das Ersatzgerät bekommt die IP Adresse des primären Gerätes, und die Webserver Software wird auf dem Ersatzgerät gestartet.

Das Umschalten geschieht manuell.

Wenn möglich werden nach dem Umschalten noch Daten vom primären Gerät kopiert, oder neu auf das Ersatzgerät hochgeladen.

Die Webseite läuft dann für einen gewissen Zeitraum mit alten Daten.

Hier werden in der Regel drei IP Adressen benötigt, eine für jedes Gerät, und eine dritte für die Webseite. Nur diese dritte IP Adresse wird auf das Ersatzgerät umgezogen.

Hot Standby

Ein dediziertes Ersatzgerät wird wie bei Warm Standby eingerichtet.

Die Daten auf dem Ersatzgerät werden jederzeit aktuell oder fast aktuell gehalten.

Das Umschalten vom primären Gerät auf das Ersatzgerät erfolgt automatisch. Nach dem Umschalten muß das primäre Gerät isoliert werden, und es dürfen keine Daten mehr vom primären Gerät auf das Ersatzgerät kopiert werden.

Es darf auf keinen Fall automatisch vom Hot Standby auf das primäre Gerät zurückgeschaltet werden.

Für das Fallback ist eine Synchronisation Hot Standby –> primäres Gerät erforderlich.

Alle bisherigen Varianten arbeiten mit lokalem Plattenspeicher.

Virtualisierung

Wenn Webserver virtualisiert werden, ist erst einmal von einer geringeren Verfügbarkeit, als bei nicht virtualisierten Webservern auszugehen. (Auch für die Wartung der Virtualisierungssoftware sind Downtimes erforderlich.)

Die Virtualisierungssoftware kann jedoch den Datenabgleich zu Warm und Hot Standby Servern übernehmen, sowie auch das Failover.

Damit sind u.U. die Umschaltzeiten vom primären zum Standby Server geringer bzw. benötigen weniger Arbeitsaufwand vom Administrator.

(Ich betrachte hier immer noch die Verwendung von lokalen Platten.)

Ansonsten verhalten sich die Webserver immer noch wie bei Warm Standby oder Hot Standby.

 

Fortsetzung in Teil 2