Ceph Crush Rules verstehen

[Ketanest]

Hallo zusammen,

ich habe eine Frage zu Ceph, konkret zu den Crush Rules und deren Funktionsweise. Eine Crush Rule ist ja dafür da zu steuern, wo die Daten gespeichert werden, richtig?
Hierzu kann man mit
ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}]
eine Regel anlegen, die dann auf der Failure Domain (z.B. ein Host, Rack oder Brandschutzabschnitt) die Daten verteilt. Je nach Pool-Size werden dann die Daten auf OSDs innerhalb verschiedener Failure Domain gespeichert oder?
Beispiel - OSD Tree:
root
- Rechenzentrum 1
-- Brandschutzabschnitt 1
--- Host 1
--- Host 2
-- Brandschutzabschnitt 2
--- Host 3
--- Host 4
-- Brandschutzabschnitt 3
--- Host 5
--- Host 6
- Rechenzentrum 2
-- Brandschutzabschnitt 4
--- Host 7
--- Host 8
Lege ich eine Regel an mit Failure Domain Rechenzentrum, würden die Daten bei einem 3/2er Pool ja in mindestens 2 Rechenzentren landen, richtig? Wo wird die dritte Kopie gespeichert? RZ 1 oder RZ 2 oder ist das variabel, weil ja bereits die Anforderung der Failure Domain (Daten auf zwei verschiedenen RZ) erfüllt ist? Landet die dritte Kopie zwingend auf einem anderen Host oder könnte diese auch "nur" auf einer anderen OSD des gleichen Hosts landen, z.B. Host 1 OSD 1, Host 1 OSD 2, Host 7 OSD 1?

Kann man mehrere Failure Domains / Ebenen in einer Regel definieren? Also z.B. auf erster Ebene RZ und auf zweiter Ebene Brandschutz? Denn wenn ich direkt Brandschutz definiere könnte es bei einem 3/2er Pool ja auch sein, dass die Daten überhaupt nicht im RZ 2 landen sondern nur in verschiedenen Brandschutzabschnitten des RZ 1 oder liege ich da falsch?

Gibt es vielleicht auch irgendwo ordentliche Lektüre, um das Ganze zu verstehen? Im Netz hab ich dazu nichts brauchbares gefunden.

Danke schonmal für eure Antworten!

Viele Grüße
Ketanest

 

[Falk R.]

Hi,
eigentlich ist hier alles dukumentiert:
https://docs.ceph.com/en/reef/rados/operations/crush-map/

Das Thema ist aber recht komplex. Ich baue manchmal 2 Datacenter Streched Setups aber dann immer mindestens mit Rule 4/2.

DC1 - many Nodes
DC2 - many Nodes
DC3 - Tiebreaker Node (keine OSDs)

Wenn du auf zwei DC verteilst, brauchst du mindestens 4 Kopien, damit im Fehlerfall 2 Kopien online sind. Sonst geht der ganze Pool in Readonly.
Hier mal eine Beispielkonfiguration:

ceph osd crush add-bucket dc1 datacenter 
ceph osd crush add-bucket dc2 datacenter 
ceph osd crush move dc1 root=default 
ceph osd crush move dc2 root=default

ceph osd crush move srv1 datacenter=dc1 
ceph osd crush move srv2 datacenter=dc2

ceph osd crush rule create-replicated stretched-replica "default" datacenter ssd stretched dc1 dc2 dc3

ceph mon set election_strategy connectivity
ceph mon set_location srv3 datacenter=dc3
ceph mon enable_stretch_mode srv3 stretch_rule datacenter

 

[Ketanest]

Das Thema ist aber recht komplex.

Da hast du wohl recht

Den Rest von deinem Post hab ich aber leider irgendwie nicht verstanden...

Wenn du auf zwei DC verteilst, brauchst du mindestens 4 Kopien, damit im Fehlerfall 2 Kopien online sind.

Du meinst, wenn ich den Fall abdecken will, dass ein ganzes Datacenter offline geht? Das leuchtet ein, ja.
Ich hab zwar schon gesehen, dass man mehrere "Steps" in der Crush Rule definieren kann aber noch nicht wirklich verstanden, wie das dann funktionieren würde. Also wenn ich (4/2 vorausgesetzt) zunächst die Daten 50/50 auf die Datacenter aufteilen möchte und dann innerhalb der Datacenter weiter in Brandschutzabschnitte z.B. oder in verschiedene Cages/Racks. Dann braucht man ja 2 Steps oder? Ist das mit dem ceph osd crush rule Kommando überhaupt möglich oder müsste man da dann den Weg über den Export / Konvertierung / Import nehmen?

 

[Falk R.]

Mit dem Kommando kannst du das nicht bauen.
Du kannst dir deine Crushmap mal exportieren:

ceph osd getcrushmap > crush.map.bin
crushtool -d crush.map.bin -o crush.map.txt

Da kannst du einfach drin editieren, aber bevor du das in deinen Produktiven Ceph zurückschreibst, solltest du dir 100% sicher sein, dass alles 1000% passt.

 

[Ketanest]

Ja genau, den Weg meinte ich mit export und import.
Kennst du irgendeine Seite, wo so eine Crush Rule visualisiert oder zumindest in Textform ausgewertet wird, was sie effektiv macht? Oder wie könnte man sonst prüfen, dass

alles 1000% passt

?

 

[Falk R.]

Eine Aufteilung auf so viele Brandabschnitte habe ich noch nie gesehen, und kenne auch kein Datacenter mit so vielen echten Brandabschnitten.
Sinn ist es ja eine Verfügbare Lösung zu schaffen und eine Datenkopie in einem Brandabschnitt, könnte theoretisch der letzte Anker im Desasterfall sein, aber darauf will ich mich nicht verlassen, Für echte Desaster hat man ein gutes Backup.

 

[Falk R.]

Ja genau, den Weg meinte ich mit export und import.
Kennst du irgendeine Seite, wo so eine Crush Rule visualisiert oder zumindest in Textform ausgewertet wird, was sie effektiv macht? Oder wie könnte man sonst prüfen, dass

?

Ich kenne nur Doku lesen und selbst verifizieren. ich nutze auch gern die IBM Dokus. Die haben solche Szenarien besser mit Beispielen dokumentiert.

 

[Ketanest]

Eine Aufteilung auf so viele Brandabschnitte habe ich noch nie gesehen, und kenne auch kein Datacenter mit so vielen echten Brandabschnitten.

Das war tatsächlich auch eher ein Gedankenspiel ;-)

Für echte Desaster hat man ein gutes Backup.

Yep.

 

[Ketanest]

Das war tatsächlich auch eher ein Gedankenspiel ;-)

Was aber ganz gut dazu geeignet wäre, das Procedere zu verstehen in meinen Augen.