Über die CRUSH Map ist es möglich zu beinflussen wie Ceph seine Objekte repliziert und verteilt. Die Standard CRUSH Map verteilt die Daten, sodass jeweils nur eine Kopie per Host abgelegt wird.
Wenn nun ein Ceph Cluster andere Prioritäten voraussieht, bspw. Hosts sich ein Netz, oder ein Rack mit gleicher Stromversorgung teilen, oder im gleichen Rechenzentrum stehen, sprich die Failure Domains anders aufgeteilt sind, ist es möglich diese Abhängigkeiten in der CRUSH Map zu berücksichtigen.
Beispielsweise wollen wir unseren Cluster mit einer Replikation von 3 auf eine 2er Replikation zurücksetzen. Da sich jedoch 2 Hosts einen Rack teilen, wollen wir das auch in unserer CRUSH Map abbilden und das über die CLI:
Ausgangslage:
[root@box12 ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -6 0.33110 datacenter dc03 -1 0.33110 root datacenter01 -5 0.33110 datacenter datacenter02 -4 0.11037 host box14 6 0.03679 osd.6 up 1.00000 1.00000 7 0.03679 osd.7 up 1.00000 1.00000 8 0.03679 osd.8 up 1.00000 1.00000 -3 0.11037 host box13 3 0.03679 osd.3 up 1.00000 1.00000 4 0.03679 osd.4 up 1.00000 1.00000 5 0.03679 osd.5 up 1.00000 1.00000 -2 0.11037 host box12 0 0.03679 osd.0 up 1.00000 1.00000 1 0.03679 osd.1 up 1.00000 1.00000 2 0.03679 osd.2 up 1.00000 1.00000
Wir erstellen die beiden Racks:
[root@box12 ~]# ceph osd crush add-bucket rack1 rack added bucket rack1 type rack to crush map [root@box12 ~]# ceph osd crush add-bucket rack2 rack added bucket rack2 type rack to crush map
Die Racks wurden erstellt:
[root@box12 ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -8 0 rack rack2 -7 0 rack rack1 -6 0.33110 datacenter dc03 -1 0.33110 root datacenter01 -5 0.33110 datacenter datacenter02 -4 0.11037 host box14 6 0.03679 osd.6 up 1.00000 1.00000 7 0.03679 osd.7 up 1.00000 1.00000 8 0.03679 osd.8 up 1.00000 1.00000 -3 0.11037 host box13 3 0.03679 osd.3 up 1.00000 1.00000 4 0.03679 osd.4 up 1.00000 1.00000 5 0.03679 osd.5 up 1.00000 1.00000 -2 0.11037 host box12 0 0.03679 osd.0 up 1.00000 1.00000 1 0.03679 osd.1 up 1.00000 1.00000 2 0.03679 osd.2 up 1.00000 1.00000
Nun verschieben wir die Hosts 14 & 13 nach Rack1 und 12 nach Rack2:
[root@box12 ~]# ceph osd crush move box14 rack=rack1 moved item id -4 name 'box14' to location {rack=rack1} in crush map [root@box12 ~]# ceph osd crush move box13 rack=rack1 moved item id -3 name 'box13' to location {rack=rack1} in crush map [root@box12 ~]# ceph osd crush move box12 rack=rack2 moved item id -2 name 'box12' to location {rack=rack2} in crush map
Und die Racks in das Rechenzentrum(datacenter02):
[root@box12 ~]# ceph osd crush move rack1 datacenter=datacenter02 moved item id -7 name 'rack1' to location {datacenter=datacenter02} in crush map [root@box12 ~]# ceph osd crush move rack2 datacenter=datacenter02 moved item id -8 name 'rack2' to location {datacenter=datacenter02} in crush map
Das ganze sieht dann so aus:
[root@box12 ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -6 0.33110 datacenter dc03 -1 0.33110 root datacenter01 -5 0.33110 datacenter datacenter02 -7 0.22073 rack rack1 -4 0.11037 host box14 6 0.03679 osd.6 up 1.00000 1.00000 7 0.03679 osd.7 up 1.00000 1.00000 8 0.03679 osd.8 up 1.00000 1.00000 -3 0.11037 host box13 3 0.03679 osd.3 up 1.00000 1.00000 4 0.03679 osd.4 up 1.00000 1.00000 5 0.03679 osd.5 up 1.00000 1.00000 -8 0.11037 rack rack2 -2 0.11037 host box12 0 0.03679 osd.0 up 1.00000 1.00000 1 0.03679 osd.1 up 1.00000 1.00000 2 0.03679 osd.2 up 1.00000 1.00000
Im nächsten Schritt lassen wir uns automatisch eine CRUSH Rule erstellen und ausgeben:
[root@box12 ~]# ceph osd crush rule create-simple ceph-blog datacenter01 rack [root@box12 ~]# ceph osd crush rule ls [ "ceph-blog", "test03" ]
‘datacenter01 rack’ sagt hier, dass beim datacenter01 begonnen werden soll und alle Kindknoten(leaf) vom Typ rack ausgewählt werden sollen.
Wir lassen uns die CRUSH Rule ausgeben:
[root@box12 ~]# ceph osd crush rule dump ceph-blog { "rule_id": 0, "rule_name": "ceph-blog", "ruleset": 0, "type": 1, "min_size": 1, "max_size": 10, "steps": [ { "op": "take", "item": -1, "item_name": "datacenter01" }, { "op": "chooseleaf_firstn", "num": 0, "type": "rack" }, { "op": "emit" } ] }
Sieht gut aus.
Der Pool rbd soll die Rule anwenden:
[root@box12 ~]# ceph osd pool set rbd crush_ruleset 0 set pool 0 crush_ruleset to 0
Funktioniert’s?
[root@box12 ~]# ceph osd map rbd test osdmap e421 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0,6], p4)
Das test Objekt wird weiterhin über die 3 Hosts verteilt.
Wir setzen die Replikation von 3 auf 2:
[root@box12 ~]# ceph osd pool get rbd size size: 3 [root@box12 ~]# ceph osd pool set rbd size 2 set pool 0 size to 2
Ceph verteilt die Objekte. Nur Geduld:
[root@box12 ~]# ceph -s cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3 health HEALTH_ERR 60 pgs are stuck inactive for more than 300 seconds 60 pgs peering 60 pgs stuck inactive 27 pgs stuck unclean recovery 3/45 objects degraded (6.667%) recovery 3/45 objects misplaced (6.667%) monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0} election epoch 82, quorum 0,1,2 box12,box13,box14 osdmap e424: 9 osds: 9 up, 9 in flags sortbitwise pgmap v150494: 270 pgs, 1 pools, 10942 kB data, 21 objects 150 GB used, 189 GB / 339 GB avail 3/45 objects degraded (6.667%) 3/45 objects misplaced (6.667%) 183 active+clean 35 peering 27 active+remapped 25 remapped+peering
Nach ‘ner Weile ist der Cluster wieder im OK Status:
[root@box12 ~]# ceph -s cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3 health HEALTH_OK monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0} election epoch 82, quorum 0,1,2 box12,box13,box14 osdmap e424: 9 osds: 9 up, 9 in flags sortbitwise pgmap v150497: 270 pgs, 1 pools, 10942 kB data, 21 objects 149 GB used, 189 GB / 339 GB avail 270 active+clean
Gucken wir uns nochmal die Verteilung der Objekte an:
[root@box12 ~]# ceph osd map rbd test osdmap e424 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0], p4)
Sieht besser aus.
Vielleicht nur ein Zufall. Wir stoppen OSD.0 auf box12. Die Daten sollten weiterhin jeweils zwischen beiden Racks repliziert werden:
[root@box12 ~]# systemctl stop ceph-osd@0 [root@box12 ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -6 0.33110 datacenter dc03 -1 0.33110 root datacenter01 -5 0.33110 datacenter datacenter02 -7 0.22073 rack rack1 -4 0.11037 host box14 6 0.03679 osd.6 up 1.00000 1.00000 7 0.03679 osd.7 up 1.00000 1.00000 8 0.03679 osd.8 up 1.00000 1.00000 -3 0.11037 host box13 3 0.03679 osd.3 up 1.00000 1.00000 4 0.03679 osd.4 up 1.00000 1.00000 5 0.03679 osd.5 up 1.00000 1.00000 -8 0.11037 rack rack2 -2 0.11037 host box12 0 0.03679 osd.0 down 0 1.00000 1 0.03679 osd.1 up 1.00000 1.00000 2 0.03679 osd.2 up 1.00000 1.00000
Der Cluster verteilt wieder neu… Nur Geduld:
[root@box12 ~]# ceph osd map rbd test osdmap e426 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4], p4) acting ([4], p4) [root@box12 ~]# ceph -s cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3 health HEALTH_WARN 96 pgs degraded 31 pgs stuck unclean 96 pgs undersized recovery 10/42 objects degraded (23.810%) 1/9 in osds are down monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0} election epoch 82, quorum 0,1,2 box12,box13,box14 osdmap e426: 9 osds: 8 up, 9 in; 96 remapped pgs flags sortbitwise,require_jewel_osds pgmap v150626: 270 pgs, 1 pools, 10942 kB data, 21 objects 149 GB used, 189 GB / 339 GB avail 10/42 objects degraded (23.810%) 174 active+clean 96 active+undersized+degraded
Nach einer Weile:
[root@box12 ~]# ceph -s cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3 health HEALTH_OK monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0} election epoch 82, quorum 0,1,2 box12,box13,box14 osdmap e429: 9 osds: 8 up, 8 in flags sortbitwise,require_jewel_osds pgmap v150925: 270 pgs, 1 pools, 14071 kB data, 22 objects 132 GB used, 168 GB / 301 GB avail 270 active+clean
Wir testen erneut:
[root@box12 ~]# ceph osd map rbd test osdmap e429 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,1], p4) acting ([4,1], p4)
Das Objekt liegt einmal in Rack1 und einmal in Rack2. Passt!
Noch nicht genug? Ihr habt Interesse noch mehr über Ceph zu erfahren? Dann besucht doch unsere Schulung: Ceph Schulung 😉
Weiterführendes: http://www.crss.ucsc.edu/media/papers/weil-sc06.pdf
0 Kommentare