Ceph Cluster Konfiguration zum Imitieren von RAID 1 auf einem Cluster Knoten

[mbuecherl]

Guten Tag zusammen,
zur Zeit arbeite ich mich in die Konfiguration von einem Ceph Clusters als Speicherlösung ein.
Ich habe es auch geschafft ein einfaches Ceph Cluster mit der Standardkonfiguration zu erstellen.

2 Knoten mit identischem Aufbau:
- 2 HDD Festplatten
- 2 SSD Festplatten
-> auf den Festplatten ist jeweils eine OSD

Des weiteren habe ich jeweils eine Crush Rule für jeden Typen erstellt (HDD & SSD).
Diese Crush Rules sehen folgender maßen aus (die andere Regel ist analog zu dieser nur für den anderen Festplattentypen):

rule replicated_hdd {
id 2
type replicated
step take default class hdd-vm-store
step chooseleaf firstn 0 type host
step emit
}

Mit dieser Konfiguration ist mir aufgefallen, dass der resultierende Pool eine Gesamtkapazität von den beiden OSDs hat. Wenn ich im Anschluss eine ISO auf dem Knoten in das CephFS hochlade, dann ist die belegte Speichergröße im Cluster doppelt so viel wie die ISO und auf dem Knoten ist diese identisch der ISO. Diese Beobachtungen signalisieren mir, dass die Daten in dem Ceph Cluster, ähnlich wie bei einem RAID 0, die Daten auf beide Festplatten verteilt. Hier kommt bei mir die Frage der Ausfallsicherheit der Festplatten.

Durch die Replikation in dem Ceph Cluster sollte eine Festplatte bzw. ein kompletter Server (in diesem Cluster) ausfallen können ohne das es zum Datenverlust kommt. Falls eine Festplatte pro Server ausfällt, dann habe ich die Befürchtung, dass es hierbei zu einem Verlust der Gesamten Daten kommt.

Die Speicherarchitektur für dem Konten soll so aussehen, dass bspw. eine OSD auf die andere des gleichen Knotens gespiegelt wird, was im Anschluss dazu auf den anderen Knoten repliziert werden soll. Ist eine solche Architektur mit Ceph möglich und wie kann ich diese umsetzen?

 

[aaron]

Ich glaube, du versucht Ceph in etwas zu pressen, für das es nicht gemacht wurde. Verabschiede dich bitte von jeglichen Analogien zu klassischen RAID Levels.

Ceph ist primär für große Cluster gedacht. Minimum sind 3 Nodes, und das ist ein bisschen ein Spezialfall, den man beachten muss. Mehr dazu später.
Ceph verspricht, mehrere Replicas der Daten irgendwo im Cluster zu speichern. Wie viele, hängt vom size Parameter des jeweiligen Pools ab. Wie genau die Redundanzen gegeben sein müssen, lassen sich mittel CRUSH Regeln festlegen. Die Defaultregel stellt sicher, dass die Replicas über die Nodes verteilt werden, also nie 2 Replicas auf der gleichen Node landen.
Weitere gängige Möglichkeiten sind, einzuschränken, auf welcher "Device Class" innerhalb eine Node die Replicas landen sollen, oder weitere Unterteilungen in Räume, Datacenter etc.

Das bedeutet, sobald man mehr als size Nodes im Cluster hat, kann man nicht mehr so leicht vorhersagen, auf welchen Nodes die jeweiligen Replicas landen.

Je mehr Resourcen man Ceph gibt, desto leichter tut sich Ceph, beim Ausfall einer, selbst zu heilen. Ob das nun ganze Nodes oder nur einzelne OSDs (Festplatten) sind. Deshalb auch lieber mal kleinere aber mehr Resourcen nehmen im Zweifelsfall.


Zusätzlich zum size Parameter gibt es noch den min_size welcher festlegt, wieviele Replicas aller Daten des betreffenden Pools mindestens vorhanden sein müssen, damit der Pool IO zulässt. Sind weniger vorhanden, wird jegliches IO geblockt, bis wieder min_size Replicas vorhanden sind. Entweder weil die Node/OSD wieder verfügbar ist, oder Ceph die zweiten Replicas woanders im Cluster wiederherstellen konnte (Selbstheilung).

Die Standardwerte für size/min_size sind 3/2. Sprich, idealerweise gibt es 3 Replicas, aber solange noch 2 vorhanden sind, läuft alles. min_size = 1 zu setzen ist absolut nicht empfohlen und kann mit ein wenig Pech zu Datenverlust/-korruption führen!

Deshalb macht Ceph auch nur erst ab 3 Nodes wirklich Sinn für den Produktivbetrieb. Selbst für eine Testinstallation würde ich nicht weniger nehmen, da sich Ceph dann doch sehr anders verhalten kann.


Wie sieht es mit diversen Ausfallszenarien aus, und vor allem mit dem Spezialfall, dass die Anzahl der Nodes gleich der size ist?

In einem Cluster mit mehr Nodes als size, gibt es immer Nodes die noch keine der 3 Replicas haben. Somit kann sich der Cluster sowohl von dem Verlust einer ganzen Node, als auch einer einzelnen OSD gut erholen, sofern noch genug Platz vorhanden ist.

Wenn nun aber Anzahl der Nodes = size ist, muss man aufpassen. Wenn eine ganze Node ausfällt, sind die PGs (placement groups) in einem "degraded" State bis die Node wieder da ist, oder durch eine neue ersetzt wurde. Soweit so gut.
Wenn aber nur eine OSD in einer Node ausfällt wird es spannend. Die Node ist noch da, uns somit kann Ceph die Regel, nur eine Replica / Node erfüllen -> Die verlorenen PGs werden auf der gleichen Node recovered. Wenn die Node nur eine OSD hat, geht das natürlich nicht, und es ist ähnlich als wenn die ganze Node verloren wäre. Aber wenn es noch OSDs gibt, wird auf diesen recovered. Das kann, wenn man nicht genug OSDs (pro device class) hat, sehr schnell eng werden.

Beispiel: 2 OSDs in der Node und eine fällt aus. Die Daten werden auf der verbleibenden recovered. Wenn die OSDs nicht gerade sehr leer waren, wird die verbleibende OSD wohl nicht reichen und Ceph hat nicht mehr genug Speicherplatz. Deshalb lieber kleinere Disks nehmen, aber mehr. Damit können die Daten kann besser innerhalb der Node verteilt werden.
In einem Cluster mit mehr Nodes, können die Daten auch auf anderen Nodes recovered werden, ohne die Regel von einer Replica pro Node nicht zu verletzen.

Ceph kann viel aushalten, aber keinen Platz mehr zu haben will man tunlichst vermeiden, das ist eine der Schmerzvolleren Erfahrungen!

Ich hoffe dieser Crashkurs hat ein bisschen geholfen, Ceph besser zu verstehen