Ceph Crushmap

[tmdnw]

Guten Morgen,

ich hab mich versucht mit den Crushmaps zu befassen, außer mein Ceph zu Crushen lief bisher allerdings garnichts.

Bisher finde ich nur Beiträge, die wohl nicht mehr zu aktuellen PVE Version passen.

Wie sieht denn eine aus die für HDD SSD und NVME unterteilt ist? Ohne sonstiges wie Racks, Zones etc.

Danke!

 

[gurubert]

Über die Buckets und Device Classes steht alles hier: https://docs.ceph.com/en/reef/rados/operations/crush-map/

 

[tmdnw]

Hi gurubert,

danke für den Link, den kenne ich bereits, leider bringt er mich nicht so recht weiter da, da fehlen mir glaube ich diverse vorkenntnisse, ich hab garkeinen Schimmer wo ich die befehle da übergebe? Ich bin hierbei danach vorgegangen, das scheint mir aber völlig anders: https://forum.proxmox.com/threads/ceph-classes-rules-and-pools.60013/

Allerdings scheinen die Befehle teils veraltet und unvollständig. Wenn ich das hier als Regel festlege:

rule replicated_hdd {
id 0
type replicated
min_size 1
max_size 10
step take default class hdd
step chooseleaf firstn 0 type host
step emit
}

Akzeptiert er fettgedrucktes nicht, min und max size verstehe ich, ist raus - aber ohne die default class, weiß er ja gar nicht welche Festplatte er wie zuordnet. Korrekt?

 

[gurubert]

Im Oktober bieten wir wieder eine Schulung an: https://www.heinlein-support.de/schulung/ceph-grundlagen

ceph osd crush rule create-replicated --help könnte Dir auch weiterhelfen.

Ich kann Dir nicht empfehlen, die CRUSH-Map per Hand zu bearbeiten. Das in dem Forumspost vorgestellte Vorgehen ist nur für Experten gedacht.

 

[aaron]

Was willst du erreichen?

ohne die default class, weiß er ja gar nicht welche Festplatte er wie zuordnet. Korrekt?

Die initiale replicated_rule macht keine Unterscheidung auf die Device Class der OSDs und verteilt die Daten über alle OSDs.
Wenn du eine Device-Class spezifische Regel erstellst, so wie deine aussieht, dann werden die Pools, denen diese Regel zugewiesen ist, nur noch diese OSDs verwenden. Bestehende Daten werden entsprechend herumgeschoben.

Wenn du unterschiedliche Device Classes hast und mit entsprechenden Regeln anfängst, ist es wichtig, dass alle Pools (auch der .mgr) eine entsprechende Regel zugewiesen haben und keiner mehr die replicated_rule verwendet.
Denn ansonsten gibt es einen Überlapp mit den Pools denen die Device Class egal ist, und der Autoscaler kann nicht mehr ausrechnen, wie viele PGs jeder Pool idealerweise haben sollte.

 

[tmdnw]

Hab schon die Schulung im September gebucht und auch schon Subscriptions für 6 Server gebucht, haben aber etwas Zeitdruck.

Schau ich mir mal an, danke!

 

[gurubert]

haben aber etwas Zeitdruck.

Gegen Geld helfen wir auch recht kurzfristig: https://www.heinlein-support.de/soforthilfe

 

[tmdnw]

Was willst du erreichen?


Die initiale replicated_rule macht keine Unterscheidung auf die Device Class der OSDs und verteilt die Daten über alle OSDs.
Wenn du eine Device-Class spezifische Regel erstellst, so wie deine aussieht, dann werden die Pools, denen diese Regel zugewiesen ist, nur noch diese OSDs verwenden. Bestehende Daten werden entsprechend herumgeschoben.

Wenn du unterschiedliche Device Classes hast und mit entsprechenden Regeln anfängst, ist es wichtig, dass alle Pools (auch der .mgr) eine entsprechende Regel zugewiesen haben und keiner mehr die replicated_rule verwendet.
Denn ansonsten gibt es einen Überlapp mit den Pools denen die Device Class egal ist, und der Autoscaler kann nicht mehr ausrechnen, wie viele PGs jeder Pool idealerweise haben sollte.

Genau, soweit hatten mir das auch die Kollegen von Inett erklärt, das Ziel ist es tatsächlich nur die zwei Pools NVME und HDD zu trennen, sprich, wenn ich neue NVMEs einbaue die in einen Pool wandern und HDDS in denselben. Die OSDs hab ich schon erstellt und auch entsprechend zugewiesen.

Die Frage ist, kann ich auch beliebig eigene Classes zuweisen für unterschiedlich schnelle NVMEs?

Die Befehle erstelle ich dann einfach in der Shell des jeweiligen Servers?

 

[aaron]

Die Frage ist, kann ich auch beliebig eigene Classes zuweisen für unterschiedlich schnelle NVMEs?

ja, entweder per CLI oder in der Web UI einfach in das Feld den Namen der neuen Class schreiben. Sobald es mindestens eine OSD mit der Class gibt, kannst du eine entsprechende Regel erstellen.

Allerdings ist die Frage, ob so eine Separierung was bringt. Wahrscheinlich nur, wenn die Geschwindigkeitsunterschiede eklatant sind. Denn Ein Recovery, wenn eine OSD/Node Ausfällt, findet auch nur innerhalb der Device Class statt. Da kann es dann evtl. dazu kommen, je nach Clusteraufbau, dass eine Device Class sehr volle OSDs hat, während die nächste sehr leer ist.

 

[tmdnw]

da gehts mehr um die Trennung von Testbereichen und Produktivbereichen. Danke mal

Wie ist denn die Reihenfolge: 1. OSD erstellen 2. Crushmap 3. Pool erstellen?

 

[Falk R.]

Ich mache soetwas bei großen EC Pools, wo der Metadatenpool auf SSDs gepinnt wird und nur die Nutzdaten auf die HDDs wandern.

 

[Falk R.]

Du baust OSDs dann einfach neue Rules anlegen und damit dann die Pools.
Crushmap brauchst du in der Regel nicht anfassen.

 

[Falk R.]

Hier mal ein Beispiel aus meiner Doku:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>

ceph osd crush rule create-replicated metadata-ssd "default" host ssd