Hintergrund zum Ceph-Ausfall - technische Kurzfassung

[Mähne Torsten]

Hallo Daniel,

vielen Dank an Dich und Dein Team für Deinen grossen Einsatz von Donnerstag bis Sonntag, um die für die Lehre, Forschung und Entwicklung so wichtigen Dienste wieder zur Verfügung zu stellen! Eure Transparenz und Informationspolitik bei Ausfällen ist vorbildlich! Ich hoffe Ihr bekommt die nötigen Ressourcen zur Verfügung gestellt, damit Ihr die Dienste mit der von Euch und den Nutzern gewünschten Zuverlässigkeit und Qualität bereitstellen könnt.

Viele Grüsse,

Torsten

> -----Original Message-----
> From: bfh-linux-announce <bfh-linux-announce-bounces at lists.bfh.science>
> On Behalf Of Daniel Baumann
> Sent: Sunday, April 18, 2021 10:04 PM
> To: bfh-linux-announce at lists.bfh.science
> Subject: Hintergrund zum Ceph-Ausfall - technische Kurzfassung
> 
> Hallo zusammen
> 
> Hier die technische Kurzfassung fuer Ceph-vertraute Personen zum Ceph
> Totalausfall der vergangenen Woche.
> 
> Diese Kurzfassung enthaelt keine weiteren Links, Zahlen, Erklaerungen oder
> Loesungsschritte (dazu dann zu Dokumentationszwecken die Langfassung
> spaeter).
> 
> 
> 1. Ausgangslage
> ===============
> 
>   * Wir betreiben Ceph in der aktuellen Version 15 (octopus) mit
>     replica 3 und min_size 2.
> 
>   * Aktuell relevant laufen wegen des Rechenzentrum-Umzuges
>     nur 3 von 6 HDD Server, jeder mit jeweils 60 OSDs
>     (= total 180 HDD OSDs up).
> 
>   * Fuer unstruktierten Legacy-Storage via SMB verwenden wir zwischen
>     50TB und 250TB RBDs pro Departement, formatiert als ext4,
>     gemountet via kernel rbd, exportiert via Samba.
> 
> 
> 2. Probleme
> ===========
> 
> 2.1 kernel rbd - Snapshot Limit
> -------------------------------
> 
>   * Durch Erreichen des 513. Snapshots (undokumentiertes Hardlimit bei
>     Verwendung des kernel rbd) auf dem HAFL RBD wurde dieses fuer den
>     kernel rbd automatisch gelockt.
> 
>   * Das Removal von Snapshots auf RBDs triggert snaptrim auf den OSDs.
> 
> 
> 2.2 bluefs_buffered_io - Default Value
> --------------------------------------
> 
>   * Upstream hat bluefs_buffered_io in einem der letzten Point Releases
>     von true auf false gesetzt.
> 
>   * Upstream hats seither fuer alle vorherigen Releases wieder reverted,
>     (noch) nicht aber fuer Ceph 15.
> 
>   * Mit bluefs_buffered_io=false wurden waehrend snaptrim die OSDs
>     unresponsive, die MONs markierten die OSDs dementsprechend als down.
> 
> 
> 2.3 Python import - Bug in den Paketen
> --------------------------------------
> 
>   * Upstream hat einen Bug in den Downstream Paketen wie Ceph den
> Python
>     Module Loader verwendet.
> 
>   * Der Bug fuehrt bei den OSDs zum Nicht-Starten des eigentlichen
>     Prozesses.
> 
>   * Da die MONs alle OSDs die als down markiert sind, automatisch weil
>     selbstheilend neu startet, fallen somit snaptrimmende OSDs komplett
>     aus.
> 
> 
> 2.4 halbe Redundanz/Groesse
> ---------------------------
> 
>   * Durch die suboptimale Verteilung aufgrund des wegen Rechenzentrum-
>     Umzuges um die Haelfte verkleinerten Clusters hat jeder Host im
>     Schnitt 1+1/3 Replicas.
> 
>   * Da alle PGs des Pools gleichverteilt sind, faellt somit beim Ausfall
>     eines OSDs mind. mehrere PGs aus.
> 
>   * Da bei RBDs faktisch Inodes = Objects gilt, und diese ueber die PGs
>     gleichverteilt sind, und alle RBDs fuer SMB in einem Pool sind,
>     faellt beim Ausfall einer PG mit groesster anzunehmender
>     Wahrscheinlichkeit Inodes aus mehreren resp. aus allen RBDs
>     innerhalb des gleichen Pools weg.
> 
>   * Weil wenn 1.33 Replicas von 3 wegfallen, die verbleibende Replica-
>     Zahl unter 2 ist und wir den Cluster auf min_size=2 haben, sind
>     somit beim Ausfall *eines* einzigen (sic!) OSDs *alle* (sic!)
>     SMB RBDs nicht nur im ueblichen write-lock, sondern weil
>     'data unavailable' komplett down.
> 
> 
> 3. Zusammenfassung
> ==================
> 
> TL;DR:
> 
>   * weil Snapshot Limit auf einem RBD erreicht...
>   * danach ein Snapshot geloescht...
>   * darum laeuft snaptrim...
>   * wegen bluefs_buffered_io=false dadurch OSDs unresponsive...
>   * somit MONs markieren OSDs down...
> 
>   * weil OSDs nicht mehr starten wegen Python Bug...
>   * und mehr OSDs nicht da weil Cluster reduziert wegen RZ-Umzug...
>   * darum PGs nicht mehr verfuegbar...
>   * soweit dass min_size unterschritten wird...
> 
>   * somit alle RBDs down...
>   * dadurch alle nicht-Basisdienste der Science DMZ down...
>   * verstaendlicherweise alle User unhappy...
>   * LNI arbeitet ueber Nacht durch...
>   * alles wieder gut.
> 
> Gruesse,
> Daniel
> 
> --
> Berner Fachhochschule / Bern University of Applied Sciences Services / IT-
> Services Daniel Baumann Teamleiter Linux & Infrastructure 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