In der Realität hat es sich als praktisch herausgestellt, die existierende Crushmap um neue Einträge zu erweitern, statt eine komplette neue zu bauen. Um an die gerade laufende Crushmap heranzukommen, ist der folgende Befehl nützlich: »ceph osd getcrushmap -o crush.running.map
«
schreibt die Crushmap in binärer Form in »crush.running.map
«
, es folgt ein Decode: »crushtool -d crush.running.map -o crush.map
«
befördert die Plaintext-Ausgabe in » crush.map
«
. Nach dem Editieren ist die Crushmap mittels »crushtool -c crush.map -o crush.new.map
«
wieder zu encodieren, bevor sie mit »ceph osd setcrushmap -i crush.new.map
«
ihren Weg zurück in den RADOS-Cluster findet.
Dass ein neu angelegter Pool die erstellte Regel verwenden soll, ist dann idealerweise in »ceph.conf
«
festzulegen: Dort wird die neue Regel einfach zum Standard-Wert. Wenn das neue Ruleset aus dem Beispiel in der Crushmap die ID 4 hat (»ruleset 4
«
), hilft beim Konfigurationsblock »[osd]
«
die Zeile »osd pool default crush rule = 4
«
. Zusätzlich lässt sich mit »osd pool default size = 3
«
festlegen, dass neue Pools immer mit 3 Replicas angelegt werden.
Nach einiger Storage-Theorie geht es zurück in den Alltag des Sysadmins. Wer eine RADOS-Installation durchführt und als Dateisystem für die Objekte von RADOS ein Ext3 oder Ext4 verwendet, tappt schnell in eine Falle: Dort dürfen die XATTR-Attribute von Dateien, also die Extended Attributes, eine Größe von 4 Kilobyte nicht überschreiten. Genau das tun die XATTR-Einträge von RADOS aber regelmäßig. Sorgt der Admin nicht vor, stürzt im schlimmsten Falle »ceph-osd
«
ab oder wirft mit kryptischen Fehlermeldungen um sich (»Operation not supported
«
).
Abhilfe schafft die Verwendung einer externen Datei, um die XATTR-Einträge zu speichern. Dazu gehört in den »[osd]
«
-Eintrag in »ceph.conf
«
die Zeile »filestore xattr use omap = true ; for ext3/4 filesystem
«
(Abbildung 3). So schützt der Admin den Cluster gegen eventuelle Probleme.