Alternative Wege zur Hochverfügbarkeit mittels vServern

Ein System gilt als hochverfügbar, wenn es im Fall eines Ausfalls von einzelnen Komponenten immer noch erreichbar und uneingeschränkt funktionsfähig bleibt. Wichtig ist dabei, dass es um die Hochverfügbarkeit der Applikation beziehungsweise des Services geht und damit die uneingeschränkte User-Experience gewährleistet ist.

Dies bedeutet aber nicht zwangsweise die Hochverfügbarkeit des einzelnen virtuellen oder physikalischen Servers. Das Ziel aller Anstrengungen in der IT ist es dem Anwender Systeme zur Verfügung zu stellen, die möglichst selten ausfallen oder deren Nutzung durch Wartungen beziehungsweise Updates eingeschränkt ist.

Genau diesen Punkt möchte ich hier beleuchten, denn meiner Meinung nach führen mehrere Server im Parallelbetrieb mit niedriger Verfügbarkeit pro Maschine besser zum Ziel, als ein Server mit sehr hoher Verfügbarkeit wie ein HA vServer.

Die meisten hochverfügbaren Systeme – bei der ADACOR sind das zum Beispiel virtuelle Server mit HA-Funktionalität von VMware – funktionieren vom Prinzip her ähnlich: Mehrere physikalische Server sind mit einem zentralen und hoffentlich hochverfügbaren Storage verbunden. Der persistente Storage der virtuellen Maschine liegt auf diesem physikalischen Knoten und die in den RAM geladene Maschine befindet sich auf einem der verbundenen Server. Bei einem Serverausfall wird die Maschine von dem zentralen Storage und einem neuen physikalischen Knoten aus gestartet.

Das Booten kostet Zeit

Gestartet – und schon ist das erste Problem da. Die virtuelle Maschine bootet und lädt sich in den RAM des neuen Knotens. Dieser Vorgang kann einen Reboot lang dauern oder im schlimmsten Fall bei Linux basierten Systemen auch mal einen ganzen File-System-Check lang. 20 Minuten sind hier keine Seltenheit. Damit kann man leben, wenn es nicht hier und da auf eine kurze Downtime ankommt.

Das zweite – und meiner Meinung nach das wichtigere – Problem entsteht faktisch aus dem Betrieb und dem Handling beziehungsweise der Wartung der Maschine. Glücklicherweise ist es heute Usus, Systeme up-to-date zu halten. Was aber oft vergessen wird, ist der Umstand, dass jeder Boot auch gut tut. Das bedeutet: Bei jedem System-Update und den Aktualisierungen des „Cores“ ist ein Reboot fällig. Dieser Neustart ist diesmal geplant und verbunden mit einer kurzen Downtime des Systems. Im Idealfall war es das.

Wenn es nach dem Update nicht funktioniert

Selten, aber dank Murphys Gesetz gar nicht so selten, passiert es, dass nach dem Update etwas nicht mehr funktioniert. Gerade wenn man als Individual-Hoster wie die ADACOR meist unbekannte und individuell von Dritten entwickelte Software betreibt, kommt es manchmal vor, dass nach einem Update nichts mehr geht. Das Zurückspielen des Snapshots und die Fehlersuche produzieren hier Downtimes, welche die Serviceverfügbarkeit für den Benutzer einschränken.

Die Vorteile beim Einsatz von beispielsweise zwei Webservern liegen auf der Hand:

• Selbst wenn faktisch zwei Systeme und ein Loadbalancer betrieben werden müssen, sorgen diese dafür, dass bei einem Systemausfall ein weiteres System ohne Ausfall des Service gegenüber dem Kunden weiterläuft. Das senkt den Stressfaktor im Operations-Bereich: Den Systemausfall bemerkt der Kunde in der Regel nicht. Die Kollegen suchen nach einer Lösung und fahren das System wieder hoch.
• Wartungen werden entspannter. Es ist möglich beide Systeme zu Bürozeiten nacheinander zu aktualisieren und zu warten. Teure Nachteinsätze entfallen. Bei weltweit genutzten Systemen ist es ohnehin herausfordernd „eine gemeinsame Nacht“ zu finden. Manchmal ist das auch gar nicht möglich. Wir nehmen ein System nach dem anderen offline, aktualisieren, testen und nehmen es wieder online. Sämtliche Vorgänge passieren ohne den Anwender des Services einzuschränken. •
• Der Betrieb von zwei Systemen bedeutet Lastverteilung und somit mehr Leistung, die direkt genutzt wird. Beim hochverfügbaren vServer sind ebenso Ressourcen für den Failover blockiert. Diese nutzt der Kunde zwar nicht, er muss sie aber faktisch bezahlen.
• Zwei bereits parallel laufende Systeme sind leichter horizontal skalierbar. Diese Behauptung ist zwar immer abhängig vom Projekt und den eingesetzten Technologien, aber ich schätze, dass das in rund 80 % der Fälle stimmt. Wurden ein System und eine Software erst einmal so angepasst, dass beide miteinander in einem lastverteilten Verbund aus mindestens zwei Servern laufen, ist die Aufstockung auf ein drittes System einfacher. Bei einem vertikal schon maximal skalierten, einzelnen System wird es in der Regel anstrengend und das Experimentieren – meist im laufenden Betrieb- geht los.

Pro und Contra

Sicher gibt es auch einige Gegenargumente für meine Behauptung. Ein paar davon habe ich schon gehört. Deshalb möchte ich diese hier ein wenig entkräften beziehungsweise direkt dazu Stellung nehmen.

Kundenargument	Feedback
Wir müssen eine Lastverteilung vornehmen und mit hochverfügbarem Loadbalancer auf die beiden Systeme umleiten. Das produziert Kosten!	Richtig und falsch. Der Loadbalancer ist günstiger als gemeinhin angenommen wird. Mittlerweile gibt es schlanke Lösungen, die im Vorfeld exakt auf die (recht minimalen) Kundenanforderungen angepasst und dementsprechend kostengünstig betrieben werden können. Und die ebenfalls hochverfügbar sind. Die minimalen Mehrkosten werden durch die organisatorischen Vorteile ausgeglichen.
Ich zahle mehr Ressourcen und zwei vServer!	Ja, das stimmt. Diese lassen sich aber vollständig nutzen und gegebenenfalls kleiner auslegen. Damit kompensieren Kunden den nicht genutzten, aber gezahlten Überhang bei den HA vServern.
Meine Applikation muss mit der Lastverteilung und horizontalen Skalierung umgehen können!	Völlig richtig. In diesem Zusammenhang stellen sich aber folgende Fragen: „Wann mache ich diese Investition?“, „Was erwarte ich von meinem Projekt und meiner Webanwendung?“. Wenn ein Kunde nur sein Ladengeschäft im Internet ohne Online-Shop und Social-Media-Aktivität präsentieren möchte, ist diese Investition nicht lohnenswert. Ist das Geschäft allerdings auf die Webanwendung ausgerichtet oder ist es sogar eine betriebskritische Anwendung bei einem florierenden Startup mit wachsender Mitarbeiterzahl, werden Marketingkampagnen geschaltet oder wächst das Unternehmen mit der Onlineaktivität? Spätestens dann sollte man Investieren und das anschließende horizontale Wachstum in die Breite fördern und dabei verhindern, dass die Umbauten im laufenden Betrieb erfolgen, gerade dann, wenn der Besucher vor der Onlinetür steht.

Fazit

Ich möchte auf keinen Fall falsch verstanden werden. HA-vServer haben definitiv ihre Daseinsberechtigung. Dazu sind die genannten Beispiele auf Web-Anwendungen gemünzt, die skaliert werden müssen. Es gibt hundert andere Beispiele, bei denen ich den HA-vServer vorziehen würde, weil alles andere einen Overkill darstellen würde. Denkt man nur an die für jedes Projekt nötigen Suchdienste, Verzeichnisdienste und Datenbanken, die nicht skaliert werden können. Hier ist mit einem Reboot im Fehlerfall eine ausreichend hohe Verfügbarkeit gegeben!

Es geht alles um die Bedarfsanalyse und ein bereits am Anfang genau beleuchtetes Projekt: Womit kann ich leben, welchen Ausfall kann ich tolerieren? Kostet mich die höhere Verfügbarkeit mehr als ein Ausfall des Dienstes? Jeder Dienst an sich muss analysiert und in seiner Verfügbarkeit eingeordnet werden. Alles mit dem Ziel dem Anwender eine nahezu uneingeschränkte Verfügbarkeit des Services zu garantieren.

Wie wir Verfügbarkeit durch unsere SLAs garantieren, beschreiben wir in einem Whitepaper, das Sie hier kostenlos downloaden können:

Genau aus diesem Grund ist unser Sales-Prozess so abwechslungsreich. Wir lassen unsere Kunden nie allein, wir verkaufen nichts von der Stange, sondern wir begleiten jeden einzelnen Kunden von Anfang an im Presales-Consulting und konzipieren mit ihm ein individuelles Betriebskonzept.
Dazu ein anderes Mal mehr oder fragen Sie mich direkt: Meine Kontaktdaten finden Sie hier oder senden Sie mir persönlich eine Mailnachricht.

Dieser Beitrag ist auch bei Datacenter-Insider und bei Storage Insider erschienen.