2h CephFS Ausfall vom 11.5. (Erklaerung)

[Daniel Baumann]

Hallo zusammen,

wie angekuendigt hier der ausfuehrliche Bericht zum CephFS-Ausfall vom
letzten Donnerstag.

Der Vollstaendigkeit halber nochmal vorneweg (siehe
https://lists.bfh.ch/pipermail/bfh-linux-announce/2017-May/000040.html):

  * beim Ausfall letzten Donnerstag zwischen 16:00 und 18:00 waren
    Moodle, RStudio und diverse LFE Linux Container down.

  * Datenintegritaet war und ist jederzeit gewaehrleistet.




1. Vorbemerkungen
=================


1.1 Ceph vs CephFS, oder "wie funktioniert CephFS"?
---------------------------------------------------

Ein Ceph Storage Cluster kann drei externe Zugriffsarten nativ anbieten:

  * objektbasiert: ein "Dateisystem" ueber eine REST API via HTTP(s),
    vergleichbar zu Amazon S3, Google Cloud Storage, Microsoft Azure
    Blob Storage und anderen.

  * blockbasiert (RBD): "virtuelle" Festplatten als Geraete, die von
    anderen Systemen her eingehaengt werden koennen, aehnlich wie ein
    iSCSI LUN.

  * Dateisystem (CephFS): ein Netzwerkdateisystem das man von anderen
    Systemen aus einbinden kann, aehnlich wie ein SMB oder NFS Share.

Ein Ceph Storage Cluster kann in mehrere Pools (mit jeweils
unterschiedlichen Eigenschaften) unterteilt werden. Allen gleich ist,
dass es sich Cluster-intern immer um Object-Pools handelt, unabhaengig
von der Zugriffsart.

d.h.: Die Dateien in einem CephFS werden nicht in einer eigenen
Datenstruktur abgelegt, sondern werden Flach und ohne
Permission/Owner-Informationen in einem Object-Pool abgelegt.


1.2 Ceph MDS
------------

Um trotzdem Daten als Dateisystem (mit Permission/Owner-Informationen
und einer Baum-artigen Verzeichnisstruktur) innerhalb eines CephFS
abzulegen, sind also weitere Informationen (sogenannte Metadaten)
noetig welche die Objekte im Object-Pool ergaenzen.

In einem Ceph Cluster werden diese Metadaten (und nur diese) in einem
extra Pool abgelegt, das sieht dann z.B. so aus (Ausschnitt von
http://master.ceph.bfh.ch/ceph-info/):

    POOL               USED        OBJECTS
    cephfs.data        14'634GB    7400122
    cephfs.metadata    382MB       649518

Hier sehen wir, dass im cephfs.data-Pool momentan rund 650'000 Dateien
in 7.4 Millionen Objekten abegelegt sind und 14.6TB Platz belegen.

Die Metadatan dazu sind in cephfs.metadata und belegen rund 400MB.

Wenn ein System ein CephFS einbindet, muss es also einerseits mit
Informationen aus dem Object-Pool (cephfs.data) erhalten und
andererseits aus dem Metadatan-Pool (cephfs.metadata). Nur wenn diese
beiden Informationen zusammenfliessen, koennen die Daten als
"herkoemmliches" Dateisystem verwendet werden.

Diese Arbeit des Zusammenfuehrens der Informationen wird durch eine Ceph
Komponente namens MDS (Meta Data Server, ein Daemon) zentral
vorgenommen und nicht auf jedem System einzeln. Das hat primaer zwei
Gruende:

  * Aenderung an den Metadatan muessen konsistent zu den dazugehoerigen
    Aenderungen an den Objekten erfolgen und umgekehrt.

    Wenn alle Modifikationen zentral erfolgen, koennen diese einfach
    serialisiert werden und es entfaellt ein aufwendiges Locking um
    konkurrierende Zugriffe zu abarbeiten.

  * Zusammenfuehren der Metadaten ist eine grundsaetzlich teure
    Operation und wird daher von Vorteil ge-cached.

    Caches koennen generell nur effektiv und effizient sein,
    wenn sie moeglichst nahe an der Quelle sind, d.h. hier im Ceph
    Cluster selbst.

    Damit entfallen alle aufwendigen Cache-ist-outdated/poisoned/etc.
    -Handlings.

Da Ceph keinen Single-Point-of-Failure hat, hat man natuerlich mehrere
MDS am laufen. An der BFH haben wir 3.

Im Gegensatz zu allen anderen Ceph Komponenten ist der MDS die einzige,
welche nicht als Cluster parallel laeuft.

D.h. bei mehreren MDS Instanzen ist immer eine die aktive, die anderen
sind Hot-Standby und uebernehmen unterbruchsfrei
(alle anderen Komponenten sind active-active-active-...).


1.3 Ceph MDS Bugs
-----------------

Ein MDS Cached aus Performance und Komplexitaets-verringernden Gruenden
in-memory. D.h. der Cache des MDS befindet sich im RAM.

Die Standardeinstellungen fuer die Groesse des Caches sind eher
konservativ gewaehlt, so dass ein MDS auch auf langsamer Hardware gut
funktioniert.

Fuer groessere Installationen und insbesondere wenn die
Hauptlast/Workload eines Clusters auf CephFS und damit schlussendlich
auf dem MDS liegt, stellt der Sysadmin ensprechend den Cache fuer seine
Systeme passend ein. Wir haben einen Faktor 100 groesseren Cache
(welcher ein Sliding Window ist und sich nach Anzahl zu cachender Inodes
bemisst).

Was wenn der Cache nicht ausreicht? Dazu gibts zwei Szenarien:

  * wenn der Cache nur kurzfristig nicht ausreicht, werden die Client
    Requests verzoegert abgearbeitet
    ("ceph -w"-Meldung dazu: MDS under pressure)

  * wenn der Cache laenger nicht ausreicht, "crasht" der MDS
    kontrolliert (klingt schlimmer als es ist):

    - es werden keine neuen Client Requests mehr angenommen, der Cache
      und Journal wird runtergeschrieben
    - der naechste Hot-Standby MDS uebernimmt mit einem "leeren" Cache

Dieses Wechseln passiert in Sekundenbruchteilen und ist von einem Client
nicht bemerktbar (wir haben das extensiv getestet unter vollem I/O- und
MDS-Load mit ein paar Millionen Dateien).

Obwohl es sich um einen grundsaetzlichen Bug handelt, ist er in der
Praxis eigentlich nicht relevant. In der naechsten Ceph Version vom
Herbst 2017 ist dies ensprechend behoben (aktuell benutzen wir 11.2
"kraken", naechsten Herbst kommt 12 "luminous", siehe weiter unten).

Nach ueber 10 Jahren Ceph-Entwicklung (vergl.
https://en.wikipedia.org/wiki/Ceph_(software) fuer mehr Informationen)
ist dies der letzte "Bug" in Ceph. Das dieser erst jetzt gefixt wurde,
liegt daran,
dass CephFS chronologisch als letzte Zugriffsart fertiggestellt wurde.




2. Vorfall vom Donnerstag
=========================


2.1 Kontext
-----------

Wir zuegeln schon laenger nach und nach einige Ressourcen fuer Lehre,
Forschung und Entwicklung (LFE) vom traditionellen NetApp SAN Storage
auf CephFS. Produktiv ist seit Februar u.a. Moodle, RStudio sowie die
Linux Number Cruncher und einige Linux Container.

Am Donnerstag Nachmittag habe ich zwei rsync gleichzeitig angeworfen:

  * Uebernahme von ETHZ Daten fuer LFE ueber Internet:
    878GB in 72'632 Dateien
    -> unproblematisch

  * Kopieren des PXE RootFS Shares fuer die Migration der PXE Systeme
    von NetApp auf Ceph:
    84GB in 5'479'012 Dateien ueber lokales Netz (d.h. 20GBit/s)
    -> problematisch: sehr viele winzige Files,
       hat den MDS Cache gesprengt.


2.2 MDS degraded
----------------

Ein initiales rsync ohne Unterbrechung oder ein simples Kopieren haette
zu keinen Problemen gefuehrt. Ich musste allerdings rsync einmal
unterbrechen und habs dann um ~16 Uhr nochmal vortgefuehrt. Weil rsync
so wie rsync eben funktioniert, d.h. zuerst einen Filecatalog aller
Files macht ohne diese zu kopieren ist dieses extrem I/O und
Metadaten-intensiv (salopp gesagt: rsync will erstmal alles sehen was da
ist, und zwar sofort, und ohne die Dateien ueberhaupt anzuschauen; siehe
rsync Manpage fuer mehr Informationen), hat dies den MDS Cache gesprengt.

Normalerweise waere wie zuvor erlaeutert ebenfalls kein Problem. In
diesem speziellen Fall haben wir aber eine so "schnelle" Ueberlastung
des MDS Caches erreicht, dass dieser in mitten des "schreibe Journal
runter, uebergib an den naechsten MDS"-Vorganges gecrashed ist.

Dadurch wurde das MDS Journal inkonsistent und einer der Hot-Standby MDS
uebernahm (absichtlich) nicht automatisch (bei Inkonsistenzen muss der
Sysadmin schauen, damit Datenintegritaet gewaehrleistet werden kann).
Der MDS Verbund ist damit degraded und CephFS ist komplett down.

Davon unbeintraechtigt ist der Ceph Cluster (siehe Vorbemerkungen bzgl.
Ceph vs CephFS) und damit die Datenintegritaet.


2.3 Loesung
-----------

Um einen MDS wieder starten zu koennen, muessen alle MDS runtergefahren
werden, alle CephFS ge-unmounted werden (damit keine Client Requests
mehr von den Servern im Journal/Backlog landen).

Danach kann das MDS Journal zur Inspektion gedumt werden (2.8TB
Sparse-File). Wir haben das Journal durchgeschaut und gesehen, dass nur
"unwichtige" Daten darin sind (d.h. die, welche vom rsync her kommen und
spaeter sowieso nochmal kopiert werden wuerden).

Daher haben wir das Journal geflusht. Nun konnten die MDS wieder
gestartet werden und CephFS war wieder online.

Philipp und ich haben das Problem detailiert und umfassend zusammen
angeschaut. So konnten wir bei jedem Schritt sicherstellen, dass
Datenintegritaet gewaehrleistet bleibt, inkl. Netz und Doppeltem Boden.

Leider ergab sich dadurch eine verhaeltnismaessig lange Downtime von 2
Stunden. Dafuer moechten wir uns entschuldigen.


2.4 Ausblick
------------

Fuer die Ceph 12 (luminous) Version welche fuer Herbst 2017 erwartet
wird, wurde der MDS wesentlich ueberarbeitet. Im Gegensatz zum
bisherigen serialisierten Hot-Standby Betrieb sind die MDS nun in einem
echten, parallelen Cluster und locken den durch sie im Moment zu
bearbeitenden Verzeichnisbaum.

Dadurch wird obiges Problem konzeptionell gar nicht mehr auftreten koennen.


2.5 Massnahmen
--------------

Bis wir im Herbst auf Ceph 12 aktualisieren werden, werden resp. haben
wir folgende Massnahmen getroffen:

  * erneutes, grosszuegiges Vergroessern des Ceph MDS Cache

  * Tests mit rsync in einem Wartungsfenster zur Verifikation,
    damit wir sicher sind das Problem nicht mehr triggern zu 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