Lessons Learned: Der Weg zu stabilem CephFS

[Daniel Baumann]

Hallo zusammen,

hier eine Zusammenfassung zu "8 Monaten CephFS im Produktiv-Einsatz" und
wie wir die aufgetretenen Probleme bzgl. Stabilitaet der letzten drei
Wochen loesen koennen.


Vorausbemerkung
===============

  * In einem Ceph Storage Cluster werden die Daten in der Form
    von Objekten abgelegt.

  * Objekte in Ceph koennen entweder als Objekte, als Block Storage
    oder als Dateisystem (CephFS) von ausserhalb des Ceph Clusters
    benutzt werden.

  * Mit Ceph (= da wo die Daten physisch abgelegt werden) hatten wir nie
    Probleme, im Gegenteil - selbst ein gleichzeitiger Ausfall von 6
    Festplatten konnte Ceph nichts anhaben.

  * Mit CephFS (= so wie die Daten "angezeigt" werden) hatten wir einige
    Probleme. Diese lassen sich in die folgenden zwei Problemkreise
    einteilen.


1st Lesson Learned:
Single MDS in Default-Settings fuer CephFS ist nicht stabil genug
=================================================================

Bei Ceph Version 11.2 (kraken) vom Januar 2017, mit welchem wir den
Storage Cluster im Februar aufgesetzt haben, gab es nur die Moeglichkeit
eines einzelnen aktiven Meta-Daten-Servers (MDS), sowie mehreren
Standby-MDS.

Der MDS stellt die Ceph Objekte als CephFS zur Verfuegung, vergleichbar
einem Webserver (z.B. apache) welche eine Website (html Dateien) den
Nutzern zur Verfuegung stellt.

Dabei sind zwei Probleme aufgetreten:

1. Die Standardeinstellungen fuer den Cache eines MDS sind fuer die
   Daten und Einsatzzweck wie wir sie an der BFH haben (insbesondere
   Moodle mit 2TB Daten in knapp 1Mio. Files) nicht geignet und mussten
   zuerst optimal eingestellt werden.

   Dies hat zweimal eine kurze Downtime von Moodle im April verursacht.

2. Da nur ein einzelner MDS aktiv sein kann, und dieser crasht wegen
   zu vielen Anfragen, ist der Wechsel auf den Standby fuer einige
   Applikationen (u.a. Moodle) nicht schnell genug und kann dann zu
   Aussetzern in der Applikation fuehren.

   Dies hat zweimal eine kurze Downtime (davon einmal Moodle) Ende Juni
   und Mitte August verursacht.

Loesung: Multi-MDS mit Ceph 12.2 (luminous)
-------------------------------------------

Seit Ceph Version 12.2 (luminous) vom September werden Multi-MDS
unterstuetzt (d.h. mehrere gleichzeitig aktive MDS Instanzen, die sich
loadbalanced in einer echten aktiv-aktiv Konfiguration formieren).

Wir haben Anfang September auf luminous aktualisiert. Wir haben mit
einigen Tests ueberpruefen koennen, dass das neue Multi-MDS Setup obige
Probleme zuverlaessig behebt.


2nd Lesson Learned:
Multi-Protokoll Zugriffe auf einzelnes CephFS ist problematisch
===============================================================

Unsere Idee war folgende: Wir legen einziges CephFS an und speichern
alle Daten darauf, so dass:

  * alle Linux Systeme CephFS nativ einbinden koennen

  * fuer Windows Systeme haben wir einen Samba als Gateway-Server
    aufgesetzt, welcher das gleiche, eingebundene CephFS via SMB
    serviert.

Vorteil davon ist dass alle Daten, unabhaengig vom Zugriffsprotokoll/Art
nur einmal zentral abgelegt werden muessen und der Komfort, dass von
ueberall/mit allen Clientssystemen gleichermassen benutzt werden
koennen.

Problem: das funktioniert so nicht :(

Es treten zwei problematische Szenarien auf: Der Samba Server hat,
standardmaessig, alle Files die durch Windows User in Benutzung waren,
innerhalb von Samba gelockt. Diesen Lock gibt er an CephFS
"unvollstaendig" weiter, d.h.:

   * (vereinfacht:) Bricht ein Windows Client ab, werden die Samba Locks
     wieder freigegeben, nicht aber die darunterliegenden CephFS Locks.

     Dadurch wird der MDS extrem belastet (bis er dann nach einer
     grossen Anzahl von "haengenden" Locks sich beendet und das ganze
     CephFS mit sich reist), und andere User koennen die Files via
     CephFS nicht bearbeiten. Das ist insbesondere bei den Linux Number
     Crunchern ein grosses Problem, da dort die User mit Windows Clients
     die Daten "organisieren" und via SSH auf den Linux Servern dann
     damit rechnen.

     Abschalten der Locks im Samba Server hilft, ist aber nicht
     trivial bzgl. dessen Verhalten, siehe anstatt vieler:


https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html

   * Wird ein File zuerst auf CephFS bearbeitet, kann es trotzdem durch
     Samba gleichzeitig bearbeitet werden, da dieser die CephFS Locks
     wegen obigem Verhalten dann nicht/nur unvollstaendig beachtet.

Diese Problematik hat sich erst in den letzten drei Wochen ergeben,
da seither viel mehr Leute den Samba Server fuer Dateiaustausch benutzt
haben. Dies war im ersten Halbjahr nicht der Fall, weshalb dies
unbemerkt blieb.

Loesung: kein Multi-Protokoll sondern dezidierte Ceph Pools
-----------------------------------------------------------

Die gute Nachricht:

  Ein Ceph Storage Cluster kann immer schon in mehrere
  Pools partitioniert werden. Wenn wir also einen eigenen Pool pro
  Protokoll/Zugriffsart verwenden (einen fuer SMB, einen fuer NFS, einen
  fuer CephFS), gibt es keine konkurrierenden Zugriffe und wir
  haben einen stabilen Zugriff auf unseren Ceph Storage Cluster.

Die schlechte Nachricht:

  * da wir durch einige konkurierende Zugriffe der letzten Paar Tage
    einige Datei-Artefakten haben die wir nicht mehr loeschen koennen,
    muessen wir fuer eine saubere Transition einen neuen Pool anlegen
    und die Daten umkopieren.

  * Dies ginge online (d.h. ohne Unterbruch und transparent fuer die
    Nutzer), sofern wir genuegend Platz auf unserem Ceph Cluster haetten.

    Die Erweiterung des Clusters war fuer Herbst 2016 geplant und hat
    sich leider immer wieder verzoegert. Voraussichtlich werden wir
    im Fruehling 2018 den Ausbau vornehmen koennen.

    Da die Migration aber dringend ist, muessen wir eine offline
    Migration machen, d.h. alle Daten wegkopieren, Pool loeschen,
    Pool neu anlegen, Daten zurueckkopieren.

    Von den momentan belegten 53TB muessen wir so rund 37TB hin- und
    herschaufeln, frei sind (abzueglich Sicherheitsreserven etc.) gerade
    noch rund 15TB.

Glueck im Unglueck:

  * Wegen der laufenden NetApp Migration koennen wir den alten NetApp
    als temporaeren Zwischenspeicher benutzen und dies innerhalb der
    naechsten 10 Tage durchfuehren (mehr dazu im naechsten Mail).


Schlussbemerkungen
==================

Wir haben versucht, maximalen Komfort fuer unsere User zur Verfuegung
zu stellen - CephFS ist leider immernoch etwas Neuland und so kommt
dieser Komfort leider zum Preis von oben genannten Service
Unterbruechen.

Datenverfuegbarkeit und -integritaet sind wichtiger als Komfort, daher
muessen wir die Migration auf einzelne Pools vornehmen, auch wenn
dadurch z.B. nicht-Linux User fuer den Datenaustausch mit den Linux
Number Crunchern ein zusaetzliches Programm (WinSCP/Cyberduck) benutzen
muessen, statt des Windows Explorers/Finders.

Wir moechten uns nochmal ausdruecklich fuer die Unanehmlichkeiten der
letzten drei Wochen entschuldigen und hoffen auf euer Verstaendnis.

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