CephFS Ausfall vom 12.6. (Erklaerung)

[Daniel Baumann]

Hallo zusammen,

wie immer hier der ausfuehrliche Bericht zum CephFS-Ausfall von letzter
Woche.


Zusammenfassung
===============

  * es sind 6 von 72 Harddisks innerhalb von wenigen Minuten
    ausgefallen, das ist durchaus ein normales Ereignis und nicht weiter
    tragisch.

    Ceph ist robust genug, Ausfaelle in solchen Groessenordnungen
    problemlos und unterbruchsfrei zu ueberstehen.

  * Datenintegritaet war und ist jederzeit Gewaehrleistet.

  * das sofort automatisch einsetzende Rebalance
    (= Wiederherstellen der 3-fachen Redundanz aller Dateien
    im Cluster durch Anlegen von Kopien der durch den Disk-Ausfall
    fehlenden Objekte) hat in der Standarteinstellung
    von Ceph fuer kleine Cluster eine zu hohe Prioritaet.

    Dies fuehrt dazu dass die I/O Performance des Clusters waehrend
    dem Rebalance zu stark vermindert ist, so dass diese nicht mehr
    fuer Anwendungen mit groessere Nutzerzahlen ausreicht.

  * sicherheitshalber haben wir das Rebalance abgewartet und die
    ensprechenden Dienste fuer diese Zeit heruntergefahren.

  * Moodle war deshalb am 12.6. von 11:16 bis 18:00 nicht erreichbar.


Massnahmen
==========

  * Wir haben die Rebalance Settings ensprechend angepasst
    (osd_scrub_during_recovery und osd_recovery_max_active).

  * Damit sind wir sicher dass bei einem beliebig grossen gleichzeitigen
    Ausfall von Disks (unterhalbs des Maximums der aktuellen Belegung
    des Clusters) die I/O Performance ueber die ganze
    Rebalance Dauer gewaehrleistet bleibt und alle darauf aufbauenden
    Dienste wie z.B. Moodle fuer alle Nutzer unveraendert weiterlaufen.


---


Details
=======


Bemerkungen zu Harddisks im Allgemeinen
---------------------------------------

  * Grundsaetzlich sind Harddisks Verrauchsmaterial, d.h. weil sie
    rotierende Medien sind ist es nur eine Frage der Zeit bis sie
    kaputt gehen und nicht ob sie kaputt gehen.

  * Wenn man eine geneugend grosse Anzahl Disks im Einsatz hat gehen
    staendig Disks kaputt, das ist normal.

  * So haben groessere Rechenzentren von z.B. Cloud-Anbietern
    jederzeit mehrere Dutzend Personen im Einsatz welche rund um die Uhr
    im 4-Schicht-Betrieb nur eines tun - Disks wechseln.

  * Wenn man viele Disks gleichzeitig beschafft, erhaelt man in der
    Regel alle von der gleichen Produktionscharge. Zusaetzlich werden
    Disks in Storage-Systemen ueblicherweise "gleich" benutzt, d.h. sie
    laufen alle genau gleich lang, wurden gleichviel an- und
    abgeschaltet, und es wurde auch gleichviel und in gleichen Mustern
    gelesen/geschrieben.

    Dadurch ergibt sich eine gleiche Abnutzung/Verbrauch der Mechanik
    und damit ein grosses Klumpenrisiko: wenn eine Disk aufgrund von
    Abnutzung/Verbrauch ausfaellt, ist es sehr wahrscheinlich dass
    weitere Disks innerhalb kurzer Zeit ebenfalls ausfallen.

  * Um dieses Risiko zu verringern (sowohl aufgrund Abnutzung/Verbrauch,
    als auch die Chance dafuer, dass man eine schlechte Charge erwischt
    hat) setzt man auf unterschiedliche Hersteller und u.U. auch
    unterschiedliche Modelle/Groessen einer Harddisk.

    Ceph welches fuer maximales Scale-out designed ist, ist flexibel
    und kann jede beliebige Groesse von Disks ohne Verschnitt im Cluster
    einbinden (was ja bei RAID nicht so waere), was ein grosser Vorteil
    resp. eine zwingende Anforderung fuer mittlere und groessere Storage
    Systeme ist.

  * Trotzdem: Disks sind Verbrauchsmaterial und fallen so oder so aus.
    Die Aufgabe des Sysadmins ists beim Aufbau von Storage Systemen
    dafuer zu sorgen, dass der garantiert auftretende gleichzeitige und
    mehrfacher Ausfall von Disks einen minimal geringen Einfluss auf das
    System haben kann.

  * Backblaze (Anbieter von Cloud-Storage) ist einer der wenigen die
    Statistiken ueber Diskausfaelle veroeffentlichen. Bei der
    Interpretation muss man allerdings etwas aufpassen - Backblaze setzt
    auf moeglichst billig und auf Masse, d.h. sie setzt auch
    Occasion/Second Hand/Used Disks und Retouren/Refurbished Disks ein
    welche via Ebay und andere "Quellen" gekauft werden.

    https://www.backblaze.com/b2/hard-drive-test-data.html


Bemerkungen zu den Harddisks im BFH Ceph Cluster
------------------------------------------------

  * Unser Cluster hat insgesamt 72 Disks:
    - 36x Western Digital Red Pro 4TB
    - 36x Seagate Enterprise Capacity 4TB

  * Die Seriennummern von beiden Modellen sind z.T. direkt
    aufeinanderfolgend, kommen also alle aus einer Charge. Als kleiner
    Kunde koennen wir leider nicht vernuenftige Verteilung ueber mehrere
    Chargen erhalten (oder muessten stark Zeitversetzt einkaufen, was
    Beschaffungen enorm verkompliziert). Wir koennen daher lediglich auf
    die Diversifizierung (unterschiedliche Hersteller, unterschiedliche
    Modelle) setzen um eine maximale Diversitaet zu erreichen.

  * Fuer zukuenftige Ceph Cluster Erweiterungen werden wir mind. auf ein
    weiteren Hersteller zurueckgreifen, so dass wir dann Disks von 3
    Herstellern im Verbund haben.

  * Die 6 gleichzeitig ausgefallenen Disks waren folgendermassen verteilt:

    - storage2.ceph.bfh.ch: /dev/sdh1 - WD Red Pro
      (S/N: WD-WMC5D0D683A1)
    - storage2.ceph.bfh.ch: /dev/sdm1 - WD Red Pro
      (S/N: WD-WMC5D0D79C84)
    - storage4.ceph.bfh.ch: /dev/sdc1 - WD Red Pro
      (S/N: WD-WMC5D0D23D88)
    - storage4.ceph.bfh.ch: /dev/sdk1 - WD Red Pro
      (S/N: WD-WMC5D0D0YJTD)
    - storage4.ceph.bfh.ch: /dev/sdl1 - WD Red Pro
      (S/N: WD-WMC5D0D57V5T)
    - storage6.ceph.bfh.ch: /dev/sdf1 - WD Red Pro
      (S/N: WD-WMC5D0D9X5L3)

  * Dies "passt" ein bisschen ins Bild - alle 72 Disks laufen seit
    September 2015 im 24/7 Betrieb, bisher sind erst 3 Disks Ausgefallen
    (3x WD Red Pro im Herbst/Winter 2016).

  * Daraus kann man allerdings keine serioesen verallgemeinernde
    Schluesse ziehen:
    - die Gesamtanzahl der Disks ist mit 72 zu gering
    - in der Regel sind alle Disks gleich "schlecht", egal welcher
      Hersteller.
    - man kann Glueck oder Pech haben mit einer Charge/Produktionslinie
      von Disks, unabhaengig von Hersteller und Modell. So ist ein Jahr
      mal das eine Modell das beste, und im Folgejahr ist das
      schlechteste.


Bemerkungen zum Ceph Rebalance
------------------------------

  * Bei Ceph ist bzgl. Rebalance nicht relevant, wann eine defekte Disk
    ersetzt wird oder nicht - im Fehlerfall werden die (zum
    vollstaendigen Erreichen der verwendeten Anzahl der Replicas)
    Objekte automatisch und sofort auf allen anderen verfuegbaren Disks
    gleichmaessig verteilt.

  * Ebenfalls ist nicht relevant wieviele Disks gleichzeitig ausfallen,
    solange es noch genuegend "freien" Platz hat um durch Rebalance zu
    kompensieren.

  * Der Einfachheit halber kann man sich das mit dem folgenden Modell
    vorstellen...
    - bei Replica 3 bilden 3 Disks zusammen eine logische Gruppe
    - innerhalb dieser Gruppe ist ein gewisses Set an Dateien abgelegt
      und ueber diese gleichmaessig verteilt (d.h. jede Disk hat je eine
      Kopie aller Daten).
    - wenn eine Disk der Gruppe ausfaellt, haben nur noch zwei Disks die
      Daten, auf diesen koennen die Daten jederzeit gelesen/geschrieben
      werden. Die Gruppe bestehlt also nur noch aus zwei Disks.
    - setzt das Rebalance ein, kommt (fiktiv) eine neue Disk in die
      Gruppe rein.
    - damit auf die neue Disk geschrieben werden kann, werden von den
      anderen zwei Disks gleichzeitig die Daten je zur Haelfte gelesen.
    - Dadurch verringert sich die Lese/Schreib-Performance auf die
      Dateien welche innerhalb dieser logischen Gruppe abgelegt sind.

  * ...mit folgender Charakteristika:
    - Wenn niemand waehrend des Rebalances auf diese Dateien zugreifen
      will, spielt es keine Rolle dass diese nur langsam verfuegbar
      waeren.
    - Wenn auf diese Dateien zugegriffen werden soll, muss der Ceph
      ensprechend QoS machen, d.h. Zugriffe abseits des Rebalance
      muessen prioritaer behandelt werden, ansonsten sind die Files
      nicht in nuetzlicher Performance les/schreibbar.

  * Die Anzahl der gleichzeitig rebalancenden logischen Gruppen ist
    bzgl. Performance nur insofern relevant, als dass bei sehr kleinen
    Clustern (<< 100 Disks) aufgrund der groesseren relativen
    Gesamtanteils einer Disk am Cluster, dies die Wahrscheinlichkeit
    erhoeht dass durch das Rebalance die Disks beschaeftigt sind mit
    genau den Daten, die man lesen/schreiben will.

  * oder anderst:
    - faellt eine Disk aus, sind drei beschaeftig (2x lesen,
      1x schreiben)
    - fallen 6 Disks aus, sind 18 Disks beschaeftigt (12 lesen,
      6x schreiben)
    - Daumenregel: sind ~10% oder mehr der Disks des Clusters
      beschaeftigt waehrend eines Rebalances, ist die Gesamt-I/O
      Performance des Clusters nicht mehr ausreichend gewaehrleistet.

  * Nota Bene: ja, auch Netzwerk-Performance spielt hier eine Rolle, wir
    haben allerdings genug davon so dass wir mit gemessenen 8Gbit Netto
    rebalancen koennen, pro System:
    - 2x 10GBit active-active LACP: Ceph Public Network, da kommen
      die "Client" Anfragen rein
    - 2x 10Gbit active-active LACP: Ceph Private Network, darueber
      laeuft der Rebalance Traffic

    Unser Problem ist lediglich die geringe Anzahl der Disks resp. der
    Treshold, siehe unten.

  * Nota Bene 2: es gibt kein anderes System das so robust ist wie Ceph
    das eine so hohe Anzahl gleichzeit ausfallender Disks ohne
    Datenverlust uebersteht - weder generell noch (und insbesondere)
    and der BFH.


Was koennen wir dagegen tun?
----------------------------

Es gibt zwei Moeglichkeiten:

  * Ceph erlaubt die Anzahl Threads welche pro Disk lesen
    einzuschraenken, default ist diese auf 15. Wir haben sie auf 1
    gestellt.

    Dadurch wird das die Recovery Zeit bis wieder alle Replicas im
    Cluster erstellt sind zu Gunsten von konstanter I/O Performance
    verlaengert.

    Da wir Replica 3 haben, ist dies in Ordnung so.

  * Wenn die Anzahl Disks erhoeht wird, koennen gleichzeitig mehr Disks
    Rebalancen ohne dass die I/O Performance runter geht.

    Bei 6 gleichzeitig ausfallenden Disks sind 18 beschaeftigt, bei 72
    Disks enspricht das rund 25%.

    Haetten wir 288 Disks im Cluster, waehren es nur noch 6.25% :)

  * Wir haben als Sofortmassnahme den Treshold angepasst. Unabhaengig
    davon werden wir voraussichtlich diesen Sommer unseren Storage
    Cluster mit weiteren Disks ergaenzen, welches zusaezlichen
    Performance-Puffer bieten wird (Ceph ist ja das einzige System, das
    je mehr Disks dazukommen, umso schneller wird das ganze System).

  * Uebrigens: der Treshold laesst sich natuerlich online waehrend eines
    Rebalances anpassen. Ich habe mich allerdings ohne vorgaengie
    Recherche dagegen enschieden um auf der sicheren Seite zu sein.

    Haette ich den Treshold runtergesetzt, waehre Moodle ueber die ganze
    Zeit des Rebalances unveraendert benutztbar gewesen.

    Serioese Storage-Admins irren lieber auf der zu vorsichtigen Seite,
    oder anderst: konservativ-vorsichtige Admins ist ein Feature sofern
    einem die Daten wichtig sind ;)


Damit moechten wir uns nochmals fuer die Unannehmlichkeiten
entschuldigen und hoffen, hiermit transparent aufgezeigt zu haben, was
das Problem war und wie wir es fuer die Zukunft ausschliessen koennen.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch