Die Fehlerdomänen-Karte, und der Übergabetest, der sie beweist

Jedes Plattformdiagramm hat drei Datenbank-Kästchen, zwei Load Balancer und ein Cache-Paar, und jedes davon trägt das Etikett «hochverfügbar». Ob es das ist, hängt von zwei Dokumenten ab, die die meisten Builds nie hervorbringen: einer Karte, von welchen physischen Dingen jede Replika abhängt, und einem Testbogen, der festhält, was geschah, als jedes davon entfernt wurde. So schreiben wir beide.

Das Problem: drei Replikas können ein einziger Ausfall sein

Redundanz zählt Kopien. Verfügbarkeit hängt davon ab, ob diese Kopien unabhängig voneinander ausfallen können. Drei Datenbankknoten auf drei virtuellen Maschinen, die der Scheduler zufällig auf zwei Hosts platziert hat, sind bei einem Host-Ausfall zwei Knoten. Drei Knoten auf drei Hosts, deren Festplatten alle auf einem Storage-Array liegen, sind bei einem Array-Ausfall keiner. Nichts in der Anwendung oder im Dashboard sagt Ihnen das. Sie müssen es aufschreiben.

Schritt eins: die Fehlerdomänen auflisten

Für eine typische Plattform listen Sie mindestens auf:

• Host: der physische Server oder das Blade.
• Chassis oder Enclosure: Blades teilen sich Stromversorgung, Kühlung und Interconnects.
• Storage-Array: und darunter den Pfad durch die Storage-Fabric.
• Netzwerk: das Top-of-Rack-Switch-Paar, die Uplinks, der Edge.
• Standort: Stromeinspeisung, Kühlung, das Gebäude selbst.

Dann entscheiden Sie, welche davon die Plattform überleben muss. Den Verlust eines beliebigen Hosts und eines beliebigen Arrays zu überleben, ist eine vernünftige Grundlage. Einen ganzen Standort zu überleben, braucht einen zweiten Standort und ist ein anderes Design.

Schritt zwei: die Karte zeichnen

Erstellen Sie eine Tabelle mit einer Zeile pro Mitglied jeder redundanten Schicht und einer Spalte pro Fehlerdomäne:

Schicht	Mitglied	Host	Chassis	Array
database	db-a	host 1	enclosure 1	array A
database	db-b	host 2	enclosure 2	array B
database	db-c	host 3	enclosure 1	array C
cache	cache-a	host 2	enclosure 2	array A
...

Die Regel ist einfach: Innerhalb einer Schicht darf keine Fehlerdomäne, die Sie überleben wollen, die Mehrheit der Mitglieder halten. Lesen Sie jede Spalte für jede Schicht von oben nach unten. Zwei von drei Datenbankmitgliedern in enclosure 1 bedeuten, dass ein Enclosure-Ausfall das Quorum bricht. Korrigieren Sie die Platzierung, oder akzeptieren Sie das Risiko schriftlich.

Schritt drei: die Quorum-Arithmetik richtig machen

Wenn Sie zwei gleichzeitige Host-Ausfälle überleben müssen, wie es eine Storage-Schicht oft sollte, brauchen Sie fünf Mitglieder in fünf getrennten Domänen, nicht vier: Ein viertes Mitglied bringt Kosten, ohne Toleranz zu bringen.

Schritt vier: den Scheduler die Karte durchsetzen lassen

Eine Karte, die davon abhängt, dass jemand die Maschinen richtig platziert, ist nach der ersten Wartung falsch. Lassen Sie die Plattform sie durchsetzen.

In einem Virtualisierungsmanager wie OLVM legen Sie pro Schicht eine negative, erzwingende Affinity-Gruppe an, damit zwei Mitglieder nie auf demselben Host laufen können, auch nicht, nachdem ein Host geleert wurde.

Unter Kubernetes verwenden Sie Required Pod Anti-Affinity und ein PodDisruptionBudget für jede Workload mit Quorum:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      [ { labelSelector: { matchLabels: { app: galera } },
          topologyKey: kubernetes.io/hostname } ]

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: galera }
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: galera }

Die Anti-Affinity hält die Mitglieder auf verschiedenen Knoten. Versehen Sie die Knoten mit Labels pro Chassis und ergänzen Sie eine zweite Regel auf diesem Label, wenn Enclosures eine Domäne sind. Das Budget bedeutet, dass ein rollierendes Knoten-Update nie ein zweites Mitglied verdrängen kann, solange eines bereits ausgefallen ist. Prüfen Sie das Ergebnis, nicht die Absicht:

kubectl get pods -l app=galera -o wide

Schritt fünf: der Übergabe-Testbogen

Jetzt beweisen Sie es. Entfernen Sie für jede Schicht ein Mitglied so, wie es ein echter Ausfall täte, mit verbundener Anwendung und fließendem echtem Datenverkehr, und halten Sie fest, was geschah:

Aktion	Erwartet	Gemessen	Was die Clients sahen
den Datenbank-Writer stoppen	der Proxy verlagert die Schreibvorgänge auf einen überlebenden Knoten	Sekunden, bis die Schreibvorgänge wieder laufen
das Cache-Primary stoppen	Sentinel befördert eine Replika	Sekunden bis zur Beförderung
einen Edge-Knoten ausfallen lassen	die Floating-Adresse wandert zum Peer	Sekunden, in jede Richtung
einen Host ausschalten	seine Mitglieder werden anderswo neu aufgebaut, das Quorum hält
einen Array-Pfad trennen	der Storage-Verkehr läuft auf dem anderen Pfad weiter

Lassen Sie bei jedem Test eine Sonde mit Zeitstempel von außen laufen, damit «was die Clients sahen» eine Messung ist:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://app.example.com/health
  sleep 0.2
done | tee failover-$(date +%F).log

Dann stellen Sie jedes Mitglied wieder her und halten fest, dass es sauber wieder beigetreten ist, als Replika des neuen Primary und nicht als sein Rivale. Ein Test, der mit zwei Primaries endet, hat den wichtigsten Fehler auf dem Bogen gefunden.

Schritt sechs: jemand anderen prüfen lassen

Wer eine Plattform gebaut hat, liest beim Prüfen die Bau-Notizen, und die Notizen sagen, was beabsichtigt war. Lassen Sie einen zweiten Ingenieur die Karte von einer anderen Maschine aus gegen die laufende Plattform prüfen: Fragen Sie den Virtualisierungsmanager nach der tatsächlichen Platzierung, den Storage nach den tatsächlichen Positionen der Festplatten, das Cluster nach der tatsächlichen Mitgliedschaft. Die Unterschiede zwischen Karte und Wirklichkeit sind die Befunde, die zählen.

Ihre Checkliste

• Die Fehlerdomänen, die Sie überleben werden, schriftlich.
• Eine Karte jedes Mitglieds jeder Schicht gegen diese Domänen, ohne Mehrheit in einer Domäne.
• Quorum-Größen, die durch Arithmetik gewählt sind, nur ungerade Zahlen.
• Anti-Affinity und Disruption Budgets, die von der Plattform durchgesetzt und geprüft werden.
• Ein Übergabe-Testbogen mit gemessenen Zeiten und Ergebnissen aus Client-Sicht für jede Schicht.
• Unabhängige Prüfung gegen die laufende Plattform, nicht gegen die Notizen.

Wenn Sie eine zweite Meinung dazu möchten, wie unabhängig Ihre Redundanz wirklich ist, kartieren wir sie gern mit Ihnen.

Mit einem Ingenieur sprechen

Verwandt: Hochverfügbare Plattform-Builds · Geclusterte Datenbanken mit Percona XtraDB Cluster · Object Caching mit automatischem Failover