Die eigene Crushmap

In einer eigenen Crushmap kann der Administrator nach Belieben festlegen, wie die Objekte seiner Pools zu verteilen sind. Das Tool »crushtool« leistet in diesem Zusammenhang wertvolle Dienste, denn es erstellt entsprechende Vorlagen. Das folgende Beispiel erstellt eine Crushmap für ein Setup aus sechs OSDs (also einzelne Storage-Devices in Servern), die auf drei Racks verteilt sind:

»crushtool --num_osds 6 -o crush.example.map --build host straw 1 rack straw 2 root straw 0«

Der Parameter »--num_osds 6« legt fest, dass dem Cluster sechs einzelne Storage-Devices zur Verfügung stehen. »--build« leitet ein Statement aus drei dreiteiligen Parametern ein, die der Syntax » Name Interner Crush- Algorithmus Zahl « folgen. » Name « ist frei wählbar, allerdings empfiehlt es sich, aussagekräftige Bezeichnungen zu nutzen. »host straw 1« legt fest, dass pro Host eine Replica erlaubt ist, »rack straw 2« lässt RADOS wissen, dass pro Rack 2 Server existieren. »root straw 0« bezieht sich auf die Anzahl der Racks und legt fest, dass die Replicas gleichmäßig auf die vorhandenen Racks verteilt sein sollen.

Wer sich die entstandene Crushmap im Klartext ansehen möchte, der greift anschließend zum Befehl »crushtool -d crush.example.map -o crush.example« ; die Datei, in der die Map im Klartext steht, ist dann »crush.example« ( Listing 1 ). Die Namen der Devices und Hosts ( »device0, device 2 ...« und »host1m host 2 ...« ) sind freilich an die lokalen Gegebenheiten anzupassen. So sollte der Name des Devices mit dem Devicenamen aus »ceph.conf« übereinstimmen (im Beispiel »osd.0« ), und der Hostname sollte mit dem Hostname des Server kongruieren.

Replikas auf Racks verteilen

Die eigentliche Replikation definiert die Zeile »step chooseleaf firstn 0 type rack« , die festlegt, dass Replicas auf die Racks zu verteilen sind. Um für eine Verteilung pro Host zu sorgen, weicht »rack« zugunsten von »host« . Die Parameter »min_size« und »max_size« wirken unscheinbar, sind aber ganz besonders in Kombination mit »ruleset 1« von großer Bedeutung dafür, dass RADOS später tatsächlich auch die erstellte Regel nutzt. Für jeden Pool ist festgelegt, welches Ruleset der Crushmap es verwendet; RADOS matcht dabei aber nicht nur auf den Namen, sondern eben auch auf die Paremeter »min_size« und »max_size« , die sich auf die Anzahl der Replikas beziehen. Konkret heißt das: Soll RADOS einen Pool nach dem Ruleset 1 beackern, der 2 Replicas nutzt, greift die Regel aus dem Beispiel. Hat der Admin aber mit dem oben erläuterten Befehl festgelegt, dass 3 Replikas für die Objekte des Pools vorhanden sein sollen, würde RADOS die Regel nicht anwenden. Um sie genereller zu gestalten, empfiehlt sich »min_size« mit 1 und »max_size« mit 10 – diese Regel greift dann für alle Pools, die das Ruleset 1 nutzen und eine bis zehn Replikas voraussetzen.

Ausgehend von diesem Beispiel ist es Admins möglich, eine eigene Crushmap zu gestalten. Diese muss anschließend ihren Weg zurück in RADOS finden.