Ausfallsicherheit: Verfügbarkeit planen statt hoffen

Ausfallsicherheit (Hochverfügbarkeit) bedeutet, dass ein Dienst auch bei Ausfall einzelner Komponenten weiterläuft. Der entscheidende Punkt: Man kann gegen bekannte Ausfälle Vorsorge treffen – aber nicht gegen alles. Deshalb steht am Anfang nicht die Technik, sondern die Frage: Was darf ausfallen, und wie lange?

Verfügbarkeitsklassen

Verfuegbarkeit in Prozent je Jahr (365 Tage):
  99,0 %     3,65 Tage Ausfall    - unbrauchbar fuer
                                     kritische Dienste
  99,9 %     8,8 Stunden          - drei Neunen
                                     (viele SaaS-Zusagen)
  99,95 %    4,4 Stunden
  99,99 %    53 Minuten           - vier Neunen
  99,999 %   5,3 Minuten          - fuenf Neunen,
                                     sehr teuer

WICHTIG: Ein Ausfall ist nicht nur "der Server ist weg".
  Die haeufigsten Ursachen in der Praxis:
    Fehlerhafte Aenderungen    40-50 %
    Anwendungsfehler           20 %
    Hardwareausfall            15 %
    Netzwerk                   10 %
    Hoehere Gewalt             Rest
  # Deshalb: Redundanz der Hardware loest nur 15 %
  # der Probleme! Die wichtigste Massnahme ist der
  # UMGANG MIT AENDERUNGEN (Tests, schrittweises
  # Ausrollen, Ruecknahme).

  # Und: Ausfallzeit wird an der SICHT DES NUTZERS gemessen.
  # Ein Server, der laeuft, aber keine Anfragen
  # beantwortet, ist ein Ausfall.

Verfuegbarkeit multipliziert sich:
  Kette: Anwendung (99,9 %) x Datenbank (99,9 %)
         x Netz (99,9 %) = 99,7 %
  # 1,1 Tage Ausfall im Jahr. Redundanz auf einer Ebene
  # bringt wenig, wenn eine andere sie zunichte macht.
  # Die schwaechste Stelle bestimmt das Ergebnis.

Single Point of Failure (SPoF):
  Jede Komponente, deren Ausfall den Dienst stoppt.
  Typische SPoF, die uebersehen werden:
    Der zweite Switch, der keine redundante Stromversorgung hat
    Dieselbe USV fuer beide redundanten Server
    Dasselbe Netzsegment fuer beide Knoten
    Ein DNS-Eintrag, der auf eine Adresse zeigt
    Ein Zertifikat, das auf einem Server erneuert wird
    Das Zertifikat selbst (!!! Ablaufdatum)
    Die Anmeldung (Active Directory / LDAP)
    Der Zeitserver
    Der Protokollspeicher
    Ein einzelnes Speicher-Array
    Ein Backup-Server, der auch DNS macht

Muster für Hochverfügbarkeit

1) AKTIV/PASSIV (Umschalten)
   Ein Knoten arbeitet, ein zweiter wartet.
   Umschaltung dauert Sekunden bis Minuten.
   Kosten: 2x Hardware fuer 1x Leistung
   Einsatz: Datenbanken, die keinen aktiven
     Parallelbetrieb vertragen
   # Vorteil: einfach, gut verstanden
   # Nachteil: Die Haelfte der Hardware ist ungenutzt,
   #           und das Umschalten muss getestet werden!

   WICHTIG: Ein Umschalten, das nie geprueft wurde,
   funktioniert im Ernstfall nicht. Und: Wenn der
   zweite Knoten nie laeuft, veraltet er.

2) AKTIV/AKTIV mit Lastverteilung
   Beide Knoten arbeiten, verteilt eingehende Anfragen.
   Ausfall eines Knotens: der andere uebernimmt.
   # Voraussetzung: Die Anwendung muss ZUSTANDSLOS sein
   # oder die Sitzung muss geteilt werden (Sitzung im
   # Zwischenspeicher, nicht im Arbeitsspeicher des
   # Knotens!).
   # Der haeufigste Fehler: Sitzungen im lokalen
   # Arbeitsspeicher - nach dem Ausfall eines Knotens
   # sind alle Nutzer abgemeldet.

3) REPLIKATION MIT AUTOMATISCHER UMSCHALTUNG
   Datenbanken: Primaer + Replik, automatische
   Erhebung des Repliks zum Primaer.
   # Vorsicht: Automatisches Umschalten kann bei
   # Netzwerkproblemen zu "Split Brain" fuehren -
   # zwei Primaer-Knoten, die auseinanderlaufen.
   # Ein Zeuge (Witness/Koordinator) ist noetig,
   # damit nicht zwei Knoten gleichzeitig der
   # Primaer sind.

4) REDUNDANZ AUF JEDER EBENE
   - Strom: zwei Netzteile an zwei USV
   - Netz: zwei Switches, zwei Karten (Bonding)
   - Speicher: RAID + mehrere Pfade (Multipath)
   - Standort: zweites Rechenzentrum
   # Wichtig: Die Ebenen muessen UNABHAENGIG sein.
   # Zwei Netzteile an derselben USV ist keine Redundanz.
   # Zwei Switches mit demselben Stromkreis auch nicht.

5) VERTEILUNG UEBER STANDORTE
   - Lastverteilung mit Zustandspruefung ueber
     mehrere Rechenzentren
   - Datenreplikation (asynchron bei grosser Entfernung,
     mit Datenverlust im Umschaltfall!)
   # Bei asynchroner Replikation gilt: RPO > 0.
   # Man verliert die Daten, die noch nicht
   # uebertragen waren. Das ist eine bewusste
   # Entscheidung (Latenz gegen Datenverlust).

Betrieb: der Teil, der oft fehlt

1) ZUSTANDSPRUEFUNGEN, DIE DEN NAMEN VERDIENEN
   # FALSCH: Prueft nur, ob der Prozess laeuft
   # RICHTIG: Prueft, ob der Dienst seine Aufgabe
   #          erfuellen kann (inklusive Abhaengigkeiten!)

   # Der Lastverteiler muss einen Knoten aus dem
   # Verkehr nehmen, der zwar antwortet, aber
   # falsch arbeitet.

   # Zustandspruefung, die zu viel prueft:
   #   Wenn sie die Datenbank mitprueft, faellt bei
   #   einem kurzen Datenbankproblem ALLES aus.
   #   Besser: Abhaengigkeiten als Warnung behandeln,
   #   nicht als Ausfall.

2) UMSCHALTEN UEBEN
   # Regelmaessig, mit Zeitmessung, dokumentiert.
   # Zwei Arten von Uebung:
   #   - Geplantes Umschalten (Wartung)
   #   - Ungeplantes Umschalten (Ausfall - im Test
   #     gern mit "Stecker ziehen", nicht mit
   #     "Prozess beenden"! Ein Prozessausfall ist
   #     etwas anderes als ein Hardwareausfall.)
   # Ein RTO, der nie gemessen wurde, ist geraten.

3) UEBERWACHT WIRD DIE SICHT DES NUTZERS
   # Nicht "laeuft der Prozess", sondern "kann ein
   # Nutzer das Ergebnis bekommen".
   # Von aussen pruefen (externer Dienst), nicht nur
   # von innen.

4) SCHWELLEN RICHTIG SETZEN
   # Zu empfindlich: Alarmmuedigkeit (niemand reagiert)
   # Zu traege: Der Ausfall wird zu spaet bemerkt
   # Wichtig: Zwischen "langsam" und "ausgefallen"
   # unterscheiden - und verschiedene Schwellen nutzen.

5) WARTUNGSFENSTER NUTZEN
   # Fuer Aenderungen mit Ausfallrisiko:
   #   - Zeitpunkt mit geringer Last
   #   - Ruecknahmeplan (wie komme ich zurueck?)
   #   - Ansprechpartner erreichbar
   #   - Erfolgskriterium vorher definieren
   # Aenderungen sind die Hauptursache von Ausfaellen.
   # Also: Aenderungsmanagement ist Ausfallsicherheit!

6) KAPAZITAET MITDENKEN
   # Redundanz ohne Reserve ist wertlos:
   # Wenn beide Knoten bei 70 % laufen, uebernimmt
   # der verbleibende 140 % - und faellt ebenfalls aus.
   # Faustregel: n+1 (ein Knoten mehr als noetig),
   # bei grosser Dimensionierung n+2.
   # Auslastung je Knoten unter 50 % halten, wenn
   # ein Knoten ausfallen darf.

7) ES GIBT IMMER EINEN EINZELPUNKT
   # Kostenlose Vollredundanz existiert nicht.
   # Fragen: Welcher Einzelpunkt bleibt, und was
   # passiert dann? (Antwort dokumentieren und
   # genehmigen lassen!)

Prüfliste

Sind Verfügbarkeitsziele je Dienst definiert (nicht „so hoch wie möglich“)?
Gibt es eine Liste der Einzelpunkte (inklusive DNS, AD, Zertifikate, Zeitserver)?
Bekommen beide redundanten Knoten Strom aus unabhängigen Quellen?
Nutzen beide Knoten unabhängige Netzpfade?
Sind Sitzungen zustandslos oder geteilt (nicht im Knoten-Arbeitsspeicher)?
Prüfen Zustandsprüfungen die Funktionsfähigkeit (nicht nur den Prozess)?
Wird das Umschalten regelmäßig geübt und gemessen?
Wird die Verfügbarkeit aus Sicht der Nutzer von außen gemessen?
Sind Reservekapazität und Ausfallkapazität ausreichend (unter 50 % Last je Knoten)?
Gibt es einen Rücknahmeplan für jede Änderung?
Ist bekannt, welcher Einzelpunkt bleibt – und ist das abgesegnet?
Gibt es ein automatisches Umschalten mit Koordinator (kein Split Brain)?

Häufige Fehler

Redundanz ohne Ausfallkapazität. Zwei Knoten bei 70 % Auslastung: Der verbleibende 140 % – und fällt auch aus. Redundanz braucht Reserve.
Umschalten nie geübt. Der zweite Knoten hat veraltete Daten, das Umschaltskript passt nicht mehr, niemand kennt den Ablauf.
Gemeinsame Abhängigkeiten. Dieselbe USV, dieselbe Stromschiene, dasselbe Netzsegment, dasselbe Anmeldesystem. Redundanz, die in der Zeichnung existiert und nicht in der Wirklichkeit.
Änderungen sind die Hauptursache. Wer Ausfälle vermeiden will, muss das Änderungsmanagement verbessern – nicht nur mehr Hardware kaufen.
Einzelpunkte übersehen. Zertifikatsablauf, DNS, AD, Zeitserver, Protokollspeicher. Ein abgelaufenes Zertifikat ist ein Ausfall – und ein sehr häufiger.
Sitzungen im Arbeitsspeicher. Nach dem Knotenausfall sind alle Nutzer abgemeldet. Kein „Ausfall“, aber praktisch unbrauchbar.
Prozess statt Hardware getestet. Ein beendeter Prozess ist etwas anderes als ein ausgefallener Server. Beides üben.
Split Brain. Automatisches Umschalten ohne Koordinator kann zwei Primärknoten erzeugen – mit Datenverlust und inkonsistenten Daten.
Verfügbarkeit auf dem Papier. „Auf dem Papier“ fünf Neunen bei einem Dienstpartner, dessen Ausfall man selbst nicht abfängt.