Thought Leadership
Wie viel Hochverfügbarkeit braucht ein Unternehmen bzw. sollte sich leisten? Nach welchen Kriterien wägt man die Investitionen ab und worauf sollte man genau achten? Doc Storage erklärt die Unterschiede der verschiedenen Cluster-Architekturen und warum nicht jeder Rat nützlich ist.
Antwort Doc Storage:
Im reinsten Sinne ermöglicht Hochverfügbarkeit (High-Availability) Anwendern oder Unternehmen, über einen bestimmten Zeitraum störungsfrei und ununterbrochen zu arbeiten. Einige Unternehmen können sich heute nicht einmal eine Minute Ausfallzeit leisten, zumindest, wenn man ihren eigenen Angaben Glauben schenkt. Bedenkt man weiterhin, dass Daten heute so etwas wie das Lebenselixier vieler Firmen sind, kann und wird selbst eine kurze Ausfallzeit unglaublich kostspielig sein. In bestimmten Szenarien können Leben von einer Datenbank abhängen, welche an sich für Hochverfügbarkeit ausgelegt ist. Kommt beispielsweise ein Patient in der Notaufnahme an, benötigen Mediziner sofortigen Zugriff auf die Krankenakten, um die in diesem Fall besten Entscheidungen treffen zu können. Jede Verzögerung kann verheerende Auswirkungen haben.
Verfügbarkeit durch Cluster
Vielleicht zwischendurch erst einmal eine Definition: Hochverfügbarkeit wird meist in Prozent der Zeit gemessen, in der ein Dienst für Benutzer zur Verfügung steht. Laut vielen Herstellern sollte ein Server eine Verfügbarkeit von 99,999 Prozent (»fünf Neunen«) erreichen, um als hochverfügbar zu gelten.
Um dies zu erreichen, arbeiten Unternehmen häufig mit Cluster-Architekturen. Solche Cluster bilden mehreren Rechnern (Nodes, Knoten), welche zu einem einzigen System zusammengeführt werden. Dies soll vor allem Ausfallzeiten der Standard-Intel-Architekturen abfangen und mildern. Fällt in einem Cluster ein Knoten aus, werden die auf ihm laufenden kritischen Anwendungen sofort nach Erkennen des Fehlers auf einen anderen Knoten übertragen. Eines müssen wir uns immer wieder klar machen, auch wenn Berater vielfach etwas anderes erzählen: Kein menschengemachtes System ist immun gegen Ausfälle. Aber Cluster mit hoher Verfügbarkeit stellen sicher, dass unabhängig von solch unvermeidlichen Ausfällen die bestmöglichen Leistungen aufrechterhalten werden. Aus diesem Grund werden solche meist für die geschäftskritische Anwendungen, Internet-Dienste oder Transaktionsverarbeitungssysteme verwendet.
Ein Cluster verwendet mehrere integrierte Systeme. Sollte es also zu einem Ausfall eines einzelnen Systems führen, lässt sich ein anderes ersatzweise nutzen, um die Verwendbarkeit eines Dienstes oder einer Anwendung aufrechtzuerhalten. Ein Load-Balancing-Cluster spielt eine entscheidende Rolle bei der Vermeidung von Systemausfällen. Hierbei verteilt eine spezialisierte Anwendung den Datenverkehr auf verschiedene Knoten, die denselben Netz- oder Anwendungsbenutzern transparent zur Verfügung stehen. Dies reduziert die Last auf einzelnen Servern, so dass sich jeder Knoten besser ausnutzen lässt, während der Datenverkehr daneben nur an fehlerfreie Knoten gesendet wird.
Aktiv-Passiv- und Aktiv-Aktiv-Cluster
Cluster unterteilen sich im Wesentlichen in zwei Arten: Aktiv-Passiv- und Aktiv-Aktiv-Installationen. Ein Aktiv-Passiv-Cluster besteht aus mindestens zwei Knoten. Wie sich aus dem Namen ergibt, sind nicht alle Knoten für den Anwender verfügbar. Wenn ein Knoten aktiv ist, steht der zweite im Wartebetrieb nicht online. Der passive Knoten fungiert als Backup und wird nur verwendet, falls der vormals aktive ausfallen sollte.
Ein Aktiv-Aktiv-Cluster verwendet mindestens zwei Knoten, die dieselben Dienste gleichzeitig ausführen. In einem Aktiv-Aktiv-Cluster fungieren alle Knoten als primäre Knoten, also werden alle Lese- und Schreibvorgänge parallel akzeptiert. Sollte ein Knoten ausfallen, wird der Benutzer automatisch mit einem der anderen verbunden, um den Betrieb zu gewährleisten. Wenn der defekte Knoten ersetzt ist, werden die Benutzer auf die alle ursprünglichen Knoten aufgeteilt.
Der überwiegende Vorteil eines Aktiv-Aktiv-Clusters besteht darin, dass sich mit seiner Nutzung ein Gleichgewicht zwischen Knoten und Netzwerk erreichen lässt. Wird der Ausfall eines Knotens erkannt, überträgt der Load-Balancer folgende Benutzeranfragen an die Knoten, die noch verfügbar sind, und steuert dann weiterhin die Aktivität des Clusters. Der Load-Balancer leitet den Datenverkehr an die Knoten weiter, die diese Arbeitslast jeweils bedienen können, was eine nochmals höhere Fehlertoleranz ermöglicht. Die meisten Cluster dieser Art folgen einem zyklischen Prozess, ähnlich dem Round-Robin-Modell, bei dem Benutzer zufällig auf verfügbare Knoten verteilt werden. Umgekehrt einem Abwägungsschema etwa, bei dem ein Knoten basierend auf einem Prozentsatz der verfügbaren Arbeitsleistung gegenüber einem anderen priorisiert wird. Eine solche Art von Clustern verwendet mindestens zwei Knoten, die dieselben Anwendungen gleichzeitig ausführen.
In einem Aktiv-Aktiv-Cluster arbeiten alle Knoten als primäre Knoten, alle akzeptieren also sämtliche Lese- oder Schreibvorgänge. Sollte ein Knoten ausfallen, werden Benutzer transparent mit einem anderen verbunden, auch so ist die Ausfallfreiheit gesichert. Sollte der ausgefallene Knoten ersetzt sein, teilt das System alle Benutzer wieder auf alle verfügbaren Knoten auf.
Keine Single-Points-of-Failure
Eine weitere Unterscheidung bei Clustern wird über sogenanntes Shared-Nothing oder Shared-Disk getroffen. Nach einer einleuchtenden Regel des verteilten Rechnens gilt es Single-Points-of-Failure (SPoF), um jeden Preis zu vermeiden. Dies erfordert allerdings, dass einzelne Ressourcen aktiv repliziert oder beschädigte ersetzt werden können, ohne dass eine einzige Komponente durch den Ausfall anderer Dienste gestört wird. In einem Aktiv-Aktiv-Cluster, auf dem eine Datenbank betrieben wird, hat der Ausfall eines Knotens keine Auswirkung auf die Verfügbarkeit anderer, unabhängig von der Anzahl der laufenden Knoten (abgesehen natürlich von der abnehmenden Leistung durch den nicht mehr verfügbaren Knoten). Sollte allerdings die Datenbank beschädigt sein, so fällt die gesamte Anwendung auf dem Cluster aus. Dies macht die Datenbank zu einem Single-Points-of-Failure. Dies wird weithin als gemeinsam genutzter Plattencluster bezeichnet. Sollte andererseits jeder Knoten seine eigene Datenbank verwalten, wirkt sich ein Knotenausfall folgerichtig nicht auf den gesamten Cluster aus. Eine solche Architektur bezeichnet man als Shared-Nothing-Cluster.
Es gibt eine Reihe unterschiedlicher Anforderungen, um die Haltbarkeit und Hochverfügbarkeit von Systemen zu gewährleisten. Lastverteilung (Load-Balancing) ist für jede hochverfügbare Architektur von entscheidender Bedeutung. Die Hauptfunktion besteht darin, den Datenverkehr paritätisch auf Knoten zu verteilen, um Daten effizienter zu übertragen und Server-Überlastungen zu vermeiden. Eine Grundfunktion jedes Systems ist die Identifizierung, welcher Failover-Prozess ausgeführt werden soll, wenn ein Knoten ausfällt. Die Skalierbarkeit von Datenbanken oder Plattenspeichern sollten IT-Manager bei allen hochverfügbaren Architekturen berücksichtigen. Es gibt grundsätzlich zwei Lösungen, um eine solche Skalierbarkeit zu erreichen. Entweder die Nutzung der Hauptdatenbank der Architektur und Verwendung von Replikation oder Partitionierung, um deren Verfügbarkeit zu steigern, oder aber alle einzelnen Anwendungsinstanzen in die Lage zu versetzen, ihre eigene Datenspeicherung zu verwalten.
Wiederherstellungsstrategie nicht vernachlässigen
In der heutigen immer schnelllebigeren Welt ist es für die meisten Unternehmen (angeblich) zwingend erforderlich, Cluster über die ganze Welt zu verteilen. Nur dadurch wird die Verfügbarkeit einer Anwendung oder eines Netzdienstes gewährleistet, sollte eine Naturkatastrophe einen einzelnen Standort heimsuchen. Bei aller Verfügbarkeit sind Cluster immer anfällig für Fehlfunktionen, die ihre Dienste stören können. Fällt ein Cluster komplett aus, müssen zwangsweise Unternehmen über eine Wiederherstellungsstrategie verfügen. Diese sollte den kompletten Neuaufbau des gesamten System in möglichst kurzer Zeit umfassen. Diese Notfallwiederherstellung umfasst Reihe von Richtlinien und Verfahren, welche darauf ausgelegt sind, einen kompletten Dienst (also Cluster, Speicher, Netze usw.) nach einem Störfall wieder voll funktionsfähig zu machen.
99,99 Prozent Verfügbarkeit gilt als Industriestandard
Wie bereits erwähnt, wird Hochverfügbarkeit oft in Prozent der Zeit gemessen, in der eine Anwendung oder ein System für Benutzer verfügbar ist. Dazu wird die Gesamtbetriebszeit durch die Systemzeit dividiert, um sie dann mit 100 zu multiplizieren. Dies ergibt einen bestimmten Prozentsatz, der für hochverfügbare Systeme 99,999 Prozent erreichen sollte. Sehr oft wird die prozentuale Verfügbarkeit als die Anzahl der Neunen in den Ziffern bezeichnet. »Vier Neunen« wären also 99,99 Prozent usw. Diese 99,99 Prozent gelten weithin als Industriestandard.
Georedundanz und Failover
Es gibt eine Reihe von Schritten, um zur Hochverfügbarkeit zu gelangen. Dies fängt bei der Anzahl der zu überwachenden Komponenten an, und geht bis hin zum Austausch ausgefallener Knoten. Georedundanz, also die Installation von Komponenten an verschiedenen voneinander entfernten Standorten, ist eine entscheidende Maßnahme zum Schutz vor von Naturkatastrophen oder nicht steuerbaren externen Ausfällen. Hierzu sollten zahlreiche Knoten an verschiedenen Standorten verteilt werden. Dies mindert das Risiko und schafft die Möglichkeit, auf einen anderen Server zurückgreifen zu können, falls die Komponenten in einer Region aus unterschiedlichen Gründen nicht mehr zur Verfügung stehen.
Hochverfügbare Architekturen umfassen normalerweise zahlreiche lose gekoppelte Systeme, welche Failover-Funktionen bieten. Ein Failover wird dabei als Backup-Betriebsmodus angesehen, der automatisch verwendet wird, wenn die Funktionen eines primären Systems nicht mehr zur Verfügung stehen. Wie bereits erwähnt, verteilt ein Load-Balancer den eingehenden Datenverkehr auf verschiedene Server, um das Risiko von Ausfallzeiten zu mindern. Hierbei sollte sichergestellt sein, dass dieser einen Algorithmus verwendet, welcher genau auf die Ansprüche des Anwenders zugeschnitten ist.
Unterschied zwischen Recovery-Point-Objective & Recovery-Time-Objective
Zu guter Letzt noch zwei Begriffe, mit dem vor allem Berater gern um sich werfen, RPO (Recovery Point Objective) und RTO (Recovery Time Objective). RPO ist der Indikator für die maximale Datenmenge, die eine Anwendung verlieren kann, ohne dem Unternehmen Schaden zuzufügen. Dies unterstreicht die Datenverlusttoleranz eines Unternehmens als Ganzes und wird in der Regel in einer Zeiteinheit gemessen, beispielsweise eine Minute oder ein Tag. Sollte das RPO auf weniger oder gleich einer Minute definiert sein, kann die maximale Verfügbarkeit aufrechterhalten werden. Hierdurch wird sichergestellt, dass bei einem Ausfall der Primärquelle nicht mehr als 60 Sekunden an Daten verloren gehen. RTO im Gegensatz hierzu ist die Zeit, die für die vollständige Wiederherstellung der Nutzbarkeit einer Anwendung oder einer Umgebung vergehen darf. Auch hier wird die Angabe in Sekunden, Minuten oder länger vorgenommen.
Abwägen zwischen kaufmännischen & technischen Aspekten
Mit beiden Begriffen wird gern um sich geworfen, um den Betreibern von DV-Umgebungen möglichst so viel Angst zu machen, dass möglichst viel Geld in den Ausbau der Infrastruktur geleitet wird. Die Betreiber sollten sich allerdings in stillen Stunden fragen, ob tatsächlich so wenige Daten verlustig gehen können, ohne dass der Betrieb nachhaltig gestört wird. Und, eigentlich noch viel wichtiger, ob das meist von Beratern immer wieder gern geforderte »RTO=0« tatsächlich erreichbar sein muss. Beides sind im Ende kaufmännische und keine DV-Entscheidungen, und über den Daumen gilt immer, dass weniger Daten bzw. kürzere Zeit auch wesentlich mehr kostet.
Fordert wer auch immer also eine Verbesserung dieser Werte, kann sich derjenige auch gleich auf die Suche nach jemandem machen, der den ganzen Aufwand bezahlt, denn im laufenden DV-Budget wird dies Geld meist nicht auffindbar sein. Auch in Zeiten von Mal- und Ransomware und anderen kriminellen Machenschaften gilt es immer die Nerven zu bewahren und tatsächlich abzuwägen, wie viele Daten das Unternehmen in welcher Zeit herzugeben bereit und in der Lage ist. Manchmal reichen auch alternative Lösungen wie Replikate bestimmter Systeme in Cloud-Speicher oder die Nutzung von nichtveränderlichen (immutable) Speicher- oder Backup-Systemen, um die Firma vor dem schlimmsten zu bewahren. Schlussendlich steht hier immer die Frage, die immer schon in der Budget-Planung im RZ ganz oben stand: »Was kostet das, wenn das nicht geht?«
Gruß
Doc Storage
