Hochverfügbarkeit und Notfallwiederherstellung

01

Ausfälle kommen bestimmt: Verfügbarkeit in Zahlen und Single Points of Failure

Verfügbarkeit ist der Anteil der Zeit, in der dein Dienst nutzbar war. 99,9 % klingt ziemlich hoch, bedeutet aufs Jahr gerechnet aber rund 8 Stunden 45 Minuten Ausfall. Jede zusätzliche 9 schrumpft die erlaubte Ausfallzeit auf ein Zehntel – und Kosten und Design werden ungefähr im selben Maß aufwendiger.

Hintereinander sinkt sie, nebeneinander steigt sie

Ein Dienst besteht aus mehreren Komponenten, die hintereinanderhängen. Muss eine Antwort erst durch einen Webserver, dann durch einen App-Server und dann durch eine DB, müssen alle drei laufen. Die Gesamtverfügbarkeit ist deshalb das Produkt der einzelnen Verfügbarkeiten. Hängst du drei Komponenten mit je 99,9 % hintereinander, landest du bei etwa 99,7 %. Stellst du dagegen zwei gleiche Server nebeneinander, fällt diese Schicht nur aus, wenn beide ausfallen – sie steigt auf 99,9999 % (vorausgesetzt, die beiden fallen unabhängig voneinander aus). Verdopple in der Szene unten ruhig mal jede Schicht.

Eine Stelle, an der ein einziges Teil alles lahmlegt, wenn es ausfällt, heißt Single Point of Failure. Hochverfügbares Design bedeutet, Single Points of Failure aufzuspüren und einen nach dem anderen zu beseitigen. Und das betrifft nicht nur Server: Auch eine DB, ein Load Balancer, ein Netzwerkpfad oder sogar „die eine Person, die weiß, wie dieser Server eingerichtet ist“ kann ein Single Point of Failure sein.

Ein SLA ist ein Erstattungsversprechen, keine Garantie

Jeder Cloud-Dienst verspricht über sein SLA (Service Level Agreement) eine monatliche Verfügbarkeit. Hier stolpern viele: Ein SLA ist keine Garantie nach dem Motto „Es läuft auf jeden Fall so lange“. Es ist ein Versprechen: „Schaffen wir das nicht, bekommst du einen Teil deiner Rechnung als Gutschrift zurück.“ Was dir während des Ausfalls entgeht, deckt es nicht ab – die Verfügbarkeit deines eigenen Dienstes muss also aus deinem Design kommen. Selbst beim gleichen Dienst ist das SLA höher, wenn du ihn auf mehrere Zonen verteilst, als wenn du nur einen Server betreibst.

Um den Single Point of Failure loszuwerden, bist du von einem Server auf zwei gegangen. Aber was, wenn die beiden im selben Gebäude stehen?

02

Wie groß ein Ausfall wird: Server, Zonen und Regionen

Ausfälle gibt es in verschiedenen Größen. Mal stirbt die Festplatte eines einzelnen Servers. Mal fällt ein ganzes Rechenzentrum durch Stromausfall, Brand oder Netzwerkstörung aus. Und ab und zu legt eine Naturkatastrophe oder eine riesige Störung ein ganzes geografisches Gebiet lahm. Den Bereich, den ein einzelner Ausfall trifft, nennt man seinen Auswirkungsbereich (Blast Radius).

Die Cloud zeigt dir diese Bereiche als Verfügbarkeitszonen und Regionen. Eine Region ist ein geografisches Gebiet wie Frankfurt oder Tokio. Darin liegen mehrere Verfügbarkeitszonen: Gruppen von Rechenzentren mit jeweils eigener, unabhängiger Stromversorgung, Kühlung und Netzwerkanbindung. Die Zonen liegen nah genug beieinander für synchrone Replikation (wenige Millisekunden Latenz), aber weit genug auseinander, dass sich eine Katastrophe in einer Zone nicht auf eine andere ausbreitet.

Die meisten Produktionsdienste setzen mehrere Zonen als Basis. Sie liegen in derselben Region, die Latenz ist also niedrig genug, um die DB synchron zu replizieren, und du überstehst einen Zonenausfall. Auf mehrere Regionen weitest du nur aus, wenn du auch einen Regionsausfall überstehen musst (wegen Gesetzen und Vorschriften oder bei einem sehr großen Dienst). Wie das geht, zeigen die Strategien zur Notfallwiederherstellung in Kapitel 7.

Um zu entscheiden, wie viel du überstehen musst, brauchst du zuerst ein Ziel. Wie lange darf der Dienst ausfallen, und wie viele Daten darfst du verlieren?

03

Was du schützt und wie viel: RTO und RPO

Wenn du Notfallwiederherstellung planst, legst du zuerst zwei Zahlen fest. RPO (Recovery Point Objective) heißt: „Wie viele Daten darfst du bei einem Ausfall verlieren?“ – angegeben als Zeitspanne. RTO (Recovery Time Objective) heißt: „Wie lange darf der Dienst stillstehen?“

Am einfachsten wird es, wenn du den Ausfallzeitpunkt in die Mitte legst. Blickst du zurück, ist alles seit dem letzten Punkt, an dem du deine Daten gesichert hast (dem letzten Backup oder der letzten Replikation), das, was du verlierst: das ist das RPO. Blickst du nach vorn, ist alles bis zu dem Moment, in dem der Dienst wieder läuft, deine Ausfallzeit: das ist das RTO. Probier in der Szene unten aus, wie sich andere Arten der Datensicherung und der Wiederherstellung auswirken.

Diese beiden Ziele legt das Geschäft fest, nicht die Technik. Ein Bestellsystem verliert schon bei einer Minute Ausfall viel Geld und darf keine einzige Bestellung verlieren, während ein internes Berichtssystem auch einen Tag Ausfall verkraften kann. Je knapper das Ziel, desto höher die Kosten – also wägst du für jedes System Verluste gegen Kosten ab. Kostet die Wiederherstellung mehr, als dich der Ausfall kosten würde, hast du das Ziel zu hoch angesetzt.

Die Ziele stehen, jetzt geht es darum, Ausfälle zu verhindern. Zuerst: Wie halten Server stand, wenn plötzlich Anfragen hereinströmen?