[SOLVED] CephFS ungleiche Datenverteilung

[Gorgon]

Hallo zusammen,
ich hoffe mir kann hier jemand bei CephFS weiter helfen:


Wie oben geschrieben habe ich das Problem, dass in meinem Proxmox Cluster mit CephFS die Daten auf den OSDs sehr ungleich verteilt werden. Im folgenden das Setup:


Aktuell 4 Server (5. ist in Planung). Jeder Server hat:

1x Intel X540-T2 Netzwerkkarte

1x Intel SSD DC P3700 400GB (Journal)

1x Perc H200 Raid-Controller

Anzahl X 600GB SAS 15k RPM HDDs

Ceph Version: ceph version 0.94.9 (fe6d859066244b97b24f09d46552afc2071e6f90)

Spoiler: Crush Map

# begin crush map

tunable choose_local_tries 0

tunable choose_local_fallback_tries 0

tunable choose_total_tries 50

tunable chooseleaf_descend_once 1

tunable straw_calc_version 1



# devices

device 0 osd.0

device 1 osd.1

device 2 osd.2

device 3 osd.3

device 4 osd.4

device 5 osd.5

device 6 osd.6

device 7 osd.7

device 8 osd.8

device 9 osd.9

device 10 osd.10

device 11 osd.11

device 12 osd.12

device 13 osd.13

device 14 osd.14

device 15 osd.15

device 16 osd.16

device 17 osd.17

device 18 osd.18

device 19 osd.19

device 20 osd.20

device 21 osd.21

device 22 osd.22

device 23 osd.23

device 24 osd.24

device 25 osd.25



# types

type 0 osd

type 1 host

type 2 chassis

type 3 rack

type 4 row

type 5 pdu

type 6 pod

type 7 room

type 8 datacenter

type 9 region

type 10 root



# buckets

host SRV-PROX-01 {

id -2 # do not change unnecessarily
# weight 3.300
alg straw
hash 0 # rjenkins1
item osd.0 weight 0.550
item osd.1 weight 0.550
item osd.2 weight 0.550
item osd.3 weight 0.550
item osd.4 weight 0.550
item osd.5 weight 0.550
}



host SRV-PROX-02 {

id -3 # do not change unnecessarily
# weight 1.600
alg straw
hash 0 # rjenkins1
item osd.6 weight 0.400
item osd.7 weight 0.400
item osd.8 weight 0.400
item osd.9 weight 0.400
}



host SRV-PROX-03 {

id -4 # do not change unnecessarily
# weight 8.000
alg straw
hash 0 # rjenkins1
item osd.10 weight 0.800
item osd.11 weight 0.800
item osd.12 weight 0.800
item osd.13 weight 0.800
item osd.14 weight 0.800
item osd.15 weight 0.800
item osd.16 weight 0.800
item osd.17 weight 0.800
item osd.18 weight 0.800
item osd.19 weight 0.800
}



host SRV-PROX-04 {

id -5 # do not change unnecessarily
# weight 3.300
alg straw
hash 0 # rjenkins1
item osd.20 weight 0.550
item osd.21 weight 0.550
item osd.22 weight 0.550
item osd.23 weight 0.550
item osd.24 weight 0.550
item osd.25 weight 0.550
}



root default {

id -1 # do not change unnecessarily
weight 16.200
alg straw
hash 0 # rjenkins1
item SRV-PROX-01 weight 3.300
item SRV-PROX-02 weight 1.600
item SRV-PROX-03 weight 8.000
item SRV-PROX-04 weight 3.300
}



# rules

rule replicated_ruleset {
ruleset 0
type replicated
min_size 1
max_size 10
step take default
step chooseleaf firstn 0 type host
step emit
}


# end crush map

Der Pool hat eine Size von 3/1

Die unterschiedlichen weights habe ich selbst eingestellt, um das Ceph am laufen zu halten. Es ist nämlich passiert, dass eine OSD zu 100% voll war. Allerdings waren viele andere OSDs gerade mal zu 70% voll. Genau hier liegt mein Problem:

Wie kann es sein, dass Crush in dem ziemlich homogenen Setup, die Daten auf den OSDs so ungleich verteilt?



Dass Crush versucht, nicht zu viele Daten auf dem SRV-PROX-03 zu halten, ist mir klar. Dieser hat ja eine viel höhere Festplattenanzahl als die anderen. Aber ich habe ja auch innerhalb eines Servers einen Auslastungsunterschied von bis zu 12%.

Kann man die Konfigs so verändern, dass die Daten gleichmäßiger verteilt werden, oder dass Crush selber merkt (wovon ich anfangs ausging), dass eine OSD fast voll ist und diese dann nicht mehr beschreibt?

Danke und Gruß
Dennis

 

[wolfgang]

Hi,

Aber ich habe ja auch innerhalb eines Servers einen Auslastungsunterschied von bis zu 12%

Das ist normal das kann durch den crush Algorithmus passieren.

Das andere verhalten ist wie du schon richtig gesagt hast durch das nicht symmetrische verhalten bedingt und Ceph versucht die Kopien auf die Nodes zu verteilen.

Kann man die Konfigs so verändern, dass die Daten gleichmäßiger verteilt werden, oder dass Crush selber merkt (wovon ich anfangs ausging), dass eine OSD fast voll ist und diese dann nicht mehr beschreibt?

Nein das musst du manuell machen, wie du es gemacht hast.

 

[udo]

Hallo zusammen,
ich hoffe mir kann hier jemand bei CephFS weiter helfen:

Hi Dennis,
ich gehe mal davon aus, dass Du rbd und nicht cephfs meinst (wobei das für dies Problem irrelevant ist).

Wie oben geschrieben habe ich das Problem, dass in meinem Proxmox Cluster mit CephFS die Daten auf den OSDs sehr ungleich verteilt werden. Im folgenden das Setup:

Es ist extrem suboptimal einer OSD-Node 10 Platten und einer anderen nur 4 zu geben. Versuche aus der 10er-Node Platten auf die anderen zu verteilen (Platte für Platte - wenn Du eine weitere Node beraits bestellt hast, evtl. erst wenn die etwas Last abgenommen hat).
Ebenso sollte man ab 60-70% Füllgrad über weitere OSDs nachdenken (bei 60% und bei 70% bestellt haben).

Zum ungleich verteilen der OSDs: 12% ist nicht viel - da geht noch mehr Eine kleine Hilfe ist die richtige Anzahl von PGs - mit zuwenig PGs tendiert Ceph dazu die Unterschiede zu verstärken.

Normalerweise ist zum Umverteilen reweight besser, was aber nur wirkt bei unterschiedlich befüllten OSDs einer Node und nicht bei dem Ungleichgewicht der Nodes.

Udo

 

[Gorgon]

Danke für die schnellen Antworten.

Genau, es geht um rbd. Die Server sind momentan im Vollausbau, es kommen aber noch drei Server dazu. Die PGs hatte ich schon auf die endgültigen 42 OSDs berechnet (2048 PGs). Leider bieten unsere Server nur so wenige Festplattenschächte. Das ist das was wir zur Zeit da haben. Es werden noch zwei Server mit jeweils 6 OSDs und ein Server mit 4 OSDs dazu kommen. Hätte auch lieber eine homogene Anzahl an OSDs pro Node, aber wie soll ich dass der Geschäftsführung verklickern?

Schade eigentlich, ich war davon ausgegangen, dass rbd ,,schlauer" wäre und selber die Auslastung der OSDs korrigiert. So muss ich nun halt weiter zwischendurch die weights neu setzen... Danke euch nochmal!

 

[udo]

Danke für die schnellen Antworten.

Genau, es geht um rbd. Die Server sind momentan im Vollausbau, es kommen aber noch drei Server dazu. Die PGs hatte ich schon auf die endgültigen 42 OSDs berechnet (2048 PGs). Leider bieten unsere Server nur so wenige Festplattenschächte. Das ist das was wir zur Zeit da haben. Es werden noch zwei Server mit jeweils 6 OSDs und ein Server mit 4 OSDs dazu kommen. Hätte auch lieber eine homogene Anzahl an OSDs pro Node, aber wie soll ich dass der Geschäftsführung verklickern?

Hi Dennis,
das mit der Geschäftsführung ist doch relativ einfach - weil es benötigt wird, um ein produktionssicheres HA-Storage-System zu betreiben. Wenn man da frickelt, ist es weder produktionssicher, noch HA... weiss natürlich nicht, was Du den bereits "verkauft" hast

Schade eigentlich, ich war davon ausgegangen, dass rbd ,,schlauer" wäre und selber die Auslastung der OSDs korrigiert. So muss ich nun halt weiter zwischendurch die weights neu setzen... Danke euch nochmal!

Wegen "schlauer": Ceph ist in dem Fall schon dazu gezwungen die kleinen Nodes zu überfüllen - der crush ändert die Berechnung nicht anhand von Füllgrad (eigentlich gehören die Daten dahin, weil's aber eng ist lege ich sie mal woanders ab - wo sie keiner findet - so funktioniert es nicht).
Mit drei Replicas und vier Nodes, bleiben nicht viele Möglichkeiten die Daten zu verteilen - jeder 4MB-Chunk liegt auf drei Nodes. Mit jeden zusätzlichen Node wird sich die Verteilung aber entspannen.

Wenn Du nicht mehr Slots in einigen Nodes hast, solltest Du dort einfach größere Platten nehmen (m,E. gibt es doch inzwischen auch 1.2 TB SAS - zumindestens 900er). Dann kannst Du die 600er für die nächsten Nodes verwenden.

Udo