Hintergrund zum Ceph-Ausfall - technische Kurzfassung

[Daniel Baumann]

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