WG: Desaster-Recovery Uebung erfolgreich

[Kessler Dorian]

Guten Tag,

ich konnte eine Berechnung auf dem R Studio-Server nicht beenden und habe darum den Tab geschlossen. Jetzt kann ich micht nicht mehr einloggen (R lädt ein bisschen, dann grau). Könnte mir jemand den laufenden Prozess killen?

Herzlichen Dank und Grüsse
Dorian

-----Ursprüngliche Nachricht-----
Von: Kessler Dorian 
Gesendet: Dienstag, 14. Mai 2019 12:06
An: bfh-linux-users at lists.bfh.science; bfh-linux-announce at lists.bfh.science
Betreff: RE: Desaster-Recovery Uebung erfolgreich

Hallo Daniel,

habe ich die Nachricht richtig verstanden: Der Umzug der Container verschiebt sich um eine Woche?

Danke für eine kurze Rückmeldung.

Viele Grüsse
Dorian

-----Original Message-----
From: bfh-linux-announce <bfh-linux-announce-bounces at lists.bfh.science> On Behalf Of Daniel Baumann
Sent: Freitag, 10. Mai 2019 19:13
To: bfh-linux-announce at lists.bfh.science
Subject: Desaster-Recovery Uebung erfolgreich

Hallo zusammen

Kurzfassung
===========

  * Die Desastery-Recovery Uebung war erfolgreich.

  * Seit kurz vor 18 Uhr sind alle Dienste wie geplant und
    uneingeschraenkt wieder verfuegbar.

  * Der Topologie-Wechsel konnte aus Zeitmangel nicht abgeschlossen
    werden, wir werden naechsten Freitag nochmals eine Downtime
    einplanen (Announcement folgt Montag vormittags).



Hintergrund
===========

  * Wir haben wegen des vollstaendigen Abschaltens von Ceph und des
    wieder Zusammenfuehrens des Clusters fuer die Simulation des
    Desastery-Recoveries sowie fuer den Einbau/Verkabelung der
    zusaetzlichen Arista Switches (Science DMZ Border Router) etwas
    laenger gebraucht als urspruenglich geplant.

  * Sehr wertvoll war dabei, dass wir das "Split-Brain"-Verhalten
    (resp. dessen Verhinderung) von Ceph testen konnten. Wir erlaeutern
    dies hier weil es dazu bisher keine oeffentlich zugaenglichen
    Erfahrungsberichte oder Dokumentation gibt:

    - ein Ceph Cluster besteht aus div. Diensten, die zwei wichtigsten
      sind die Monitors (enthalten die "Inhalts-Karten" im Sinne von
      Inhaltsverzeichnissen was/wie/wo gespeichert ist) und die OSDs
      (speichern die eigentlichen Daten auf die Disks/SSDs).

    - ein Cluster hat mehrere (ungerade Anzahl) Monitore, welche sich
      gegenseitig untereinander synchroniseren und abstimmen, wer die
      neuste, gueltigen "Inhalts-Karten" hat (Quorum).

    - sind die Monitore und OSDs ueber mehrere Racks verteilt (bei uns 2
      Monitore in Rack 1, und 1 Monitor in Rack 2), wird der Cluster in
      mehrere Teile zerfallen wenn die Verbindung zwischen den Racks
      unterbrochen wird.

    - bei uns sind das 2 Racks, d.h. 2 Teile. Sofern jede Seite
      Verbindung zu genuegend OSDs hat, waere vorstellbar dass jede
      Seite fuer sich entscheiden koennte, dass sie der "ueberlebende"
      Teil des Clusters ist und wuerde Anfragen (weil die Racks jeweils
      eigene Uplinks haben) von Usern unabhaengig von der anderen
      Haelfte verarbeiten.

    - dadurch wuerden die Daten auf beiden Cluster-Haelften auseinander
      divergieren und ein Zusammenfuehren nach dem Wiederherstellen der
      Verbindung zwischen den zwei Racks waere nicht mehr (sinnvoll)
      moeglich. Dies nennt man "Split-Brain" und gilt es um jeden Preis
      zu vermeiden.

    - bei Ceph ist dies ganz einfach (und uninteressant) geloest: die
      Cluster-Seite, welche weniger Monitore hat, wird beim Trennen
      automatisch inaktiv. D.h. in unserem Falle waeren die Cluster-
      Teile in Rack 2 (weil nur 1 von 3 Monitoren) inaktiv,
      die Teile in Rack 1 (weil 2 von 3 Monitoren) blieben aktiv
      und wuerden Anfragen von Usern weiterhin beantworten.

      Dieses Verhalten haben wir zuvor schon simuliert und kennen wir/
      koennen damit umgehen.

    - Das Interessante ist nun aber.. was passiert, wenn die "kleinere
      Haelfte" eine aktuellere "Inhalts-Karte" hat als die "groessere
      Haelfte". Dieser Fall ist wichtig, weil in der Praxis oft eine
      Verbindung zwischen den Racks nicht von einem logischen Moment zum
      naechsten "komplett/vollstaendig" ausfaellt, sondern entweder
      die Verbindung flackert oder schmierend/langsam ausfaellt, also
      die Trennung nicht mit einem "scharfen Schnitt" erfolgt.

      oder anderst: wenn etwas total schiefgeht, ist es in der Regel so,
      dass es nicht nach dem fuers Recovery "best moeglichen Fall"
      schief geht.

    - Diese oben beschrieben Fehlermoeglichkeit ist neu (vor der Science
      DMZ hatten wir den "alten" Cluster im BFH.ch Netz nur innerhalb
      eines Racks platziert) und muss daher getestet werden.

    - Wir haben diese Fehlersituation ereichen koennen in dem wir die
      Hosts und Verbindungen absichtlich in der am schlechtesten
      moeglichen Reihenfolge nacheinander getrennt und abgeschaltet
      haben.

    - Ceph hat sich auch in diesem Fall "korrekt" (im Sinne von
      "Datenintegritaet ist jederzeit gewaehrleistet") verhalten
      und den Cluster als ganzes inaktiv geschaltet, bis die aktuelle
      Seite einen weiteren Monitor (und damit die Mehrheit) erhalten
      hat.

    - D.h. in einem Ernstfall wuerden wir zuerst schauen, welche Seite
      die aktuellere ist und dieser durch Instanzieren von zusaetzlichen
      Monitor-Containern zu einer Mehrheit verhelfen. Erst danach
      sollte die Verbindung der Racks repariert werden und der Cluster
      (ohne temporaeres Split-Brain) auf herkoemliche Weise einfach
      wieder zusammengefuegt werden.

    - dabei haben wir noch geuebt und verifiziert, wie man an diese
      Informationen in einem vollstaendig nicht mehr funktionierenden
      Cluster kommt (d.h. wenn "zufaelligerweise" ebenfalls auch alle
      Status-Informationsdienste ausgefallen sind und man mit den
      Daemons per Socket lokal und einzeln sprechen muss), d.h.
      quasi den Flug ohne Sicht und nur mit Instrumenten.

Fazit
-----

Durch die Disastery-Recovery Uebung..

  * ..haben wir verifiziert, dass der Betrieb unseres neuen, mehr als
    ein Rack umspannenden Ceph Clusters selbst bei einem vollstaendigen
    Ausfalls aller(!) Netzwerkverbindungen zwischen und(!) innerhalb der
    Racks mit minimaler Downtime und garantierter Datenintegritaet
    gewaehrleistet ist.

  * ..sind wir uns sicher, dass unsere Infrastruktur, sowohl was
    Netzwerkkomponenten und -konzept, als auch die darauf laufenden
    Dienste (insbesondere Ceph als Fundament der Science DMZ)
    funktioniert.

Gruesse,
Daniel

--
Berner Fachhochschule / Bern University of Applied Sciences Services / IT-Services Daniel Baumann Teamleiter Linux Services ___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science
_______________________________________________
bfh-linux-announce mailing list
bfh-linux-announce at lists.bfh.science
https://lists.bfh.science/listinfo/bfh-linux-announce