Was ist besser? HA-vServer oder ...?

Die Server-Alternativen für Service-Hochverfügbarkeit

| Autor / Redakteur: Alexander Lapp* / Ulrike Ostler

Nicht auf die Leistungsfähigkeit einer einzelnen Maschine entscheidet; mehrere Server im Parallelbetrieb sorgen für die Hochverfügbarkeit.
Nicht auf die Leistungsfähigkeit einer einzelnen Maschine entscheidet; mehrere Server im Parallelbetrieb sorgen für die Hochverfügbarkeit. (Bild: vege/ Fotolia.com)

Mehrere Server im Parallelbetrieb mit niedriger Verfügbarkeit pro Maschine sorgen besser für Hochverfügbarkeit, als ein Server mit sehr hoher Verfügbarkeit wie ein „HA vServer“.

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.

Das Booten kostet Zeit

Die meisten hochverfügbaren Systeme – bei 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 Server-Ausfall wird die Maschine von dem zentralen Storage und einem neuen physikalischen Knoten aus gestartet.

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.

Parallel laufende Systeme sind leichter horizontal skalierbar und mit weniger Downtime wartbar.
Parallel laufende Systeme sind leichter horizontal skalierbar und mit weniger Downtime wartbar. (Bild: vege/Fotolia.com)

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.

Ergänzendes zum Thema
 
Das Fazit des Autors

Das bedeutet: Bei jedem System-Update und den Aktualisierungen des Core 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 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 Web-Servern 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 Prozent 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.

* Alexander Lapp ist Chief Customer Officer (CCO) der Adacor Hosting. In dieser Funktion obliegt ihm die Leitung für die beiden Vertriebsbereiche Technical Sales und Pre-Sales. Hierbei ist er für das Produkt-Management und die technische Beratung im Vertriebsumfeld verantwortlich.

Was meinen Sie zu diesem Thema?
Contra: Lizenzkosten! Sobald man sich im Windows-Server Bereich aufhält heißt das...  lesen
posted am 06.02.2016 um 21:36 von Unregistriert


Mitdiskutieren

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43845606 / Hardware)