Inkonsistente PGs auf frischem Ceph-Cluster

[Ingo S]

Hallo zusammen

Ich habe in den letzten Tagen einen komplett neuen Proxmox Cluster mit Ceph erstellt. Wir hatten eine Reihe VMs die auf einem PVE 4.4 Cluster liefen, also fehlte noch ein Node.
Nachdem ich dann alle Nodes bis auf den einen der die VMs am laufen hielt Online hatte, Ceph installiert und die OSDs eingerichtet, habe ich die ganzen Maschinen von unserem alten Cluster auf den neuen verschoben. Zu dem Zeitpunkt liefen noch alle VMs auf einem NFS Storage.

Ich habe insgesamt 4 Maschinen mit Ceph. In jeder befinden sich 2 SSDs (insgesamt 8 x 512GB), 2 Hosts mit 6 HDDs sowie 2 Hosts mit 5 HDDs (insgesamt 24x 4TB).

Es gibt einen HDD-Pool und einen SSD Pool. Beide Pools haben size=3/2, der HDD Pool hat 1024PGs, der SSD Pool 256PGs, so sagte es der PGCalc.

Die Crushmap sieht zur Zeit so aus

Spoiler: Komplette Crushmap hier

# 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 chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class hdd
device 1 osd.1 class hdd
device 2 osd.2 class hdd
device 3 osd.3 class hdd
device 4 osd.4 class hdd
device 5 osd.5 class hdd
device 6 osd.6 class hdd
device 7 osd.7 class hdd
device 8 osd.8 class hdd
device 9 osd.9 class ssd
device 10 osd.10 class ssd
device 11 osd.11 class ssd
device 12 osd.12 class hdd
device 13 osd.13 class ssd
device 14 osd.14 class hdd
device 15 osd.15 class hdd
device 16 osd.16 class hdd
device 17 osd.17 class ssd
device 18 osd.18 class ssd
device 19 osd.19 class hdd
device 20 osd.20 class hdd
device 21 osd.21 class hdd
device 22 osd.22 class ssd
device 23 osd.23 class hdd
device 24 osd.24 class hdd
device 25 osd.25 class hdd
device 26 osd.26 class hdd
device 27 osd.27 class hdd
device 28 osd.28 class hdd
device 29 osd.29 class ssd

# 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 vm-1 {
    id -3        # do not change unnecessarily
    id -4 class hdd        # do not change unnecessarily
    id -12 class ssd        # do not change unnecessarily
    # weight 16.279
    alg straw2
    hash 0    # rjenkins1
    item osd.0 weight 3.638
    item osd.1 weight 3.638
    item osd.2 weight 3.638
    item osd.11 weight 0.464
    item osd.12 weight 3.638
    item osd.13 weight 0.464
    item osd.21 weight 0.800
}
host vm-3 {
    id -19        # do not change unnecessarily
    id -20 class hdd        # do not change unnecessarily
    id -21 class ssd        # do not change unnecessarily
    # weight 22.770
    alg straw2
    hash 0    # rjenkins1
    item osd.22 weight 0.465
    item osd.23 weight 3.640
    item osd.24 weight 3.640
    item osd.25 weight 3.640
    item osd.26 weight 3.640
    item osd.27 weight 3.640
    item osd.28 weight 3.640
    item osd.29 weight 0.465
}
datacenter Rathaus {
    id -9        # do not change unnecessarily
    id -10 class hdd        # do not change unnecessarily
    id -11 class ssd        # do not change unnecessarily
    # weight 39.049
    alg straw2
    hash 0    # rjenkins1
    item vm-1 weight 16.279
    item vm-3 weight 22.770
}
host vm-2 {
    id -5        # do not change unnecessarily
    id -6 class hdd        # do not change unnecessarily
    id -13 class ssd        # do not change unnecessarily
    # weight 22.759
    alg straw2
    hash 0    # rjenkins1
    item osd.3 weight 3.638
    item osd.4 weight 3.638
    item osd.6 weight 3.638
    item osd.10 weight 0.465
    item osd.14 weight 3.638
    item osd.15 weight 3.638
    item osd.16 weight 3.638
    item osd.17 weight 0.465
}
host vm-6 {
    id -7        # do not change unnecessarily
    id -8 class hdd        # do not change unnecessarily
    id -14 class ssd        # do not change unnecessarily
    # weight 19.121
    alg straw2
    hash 0    # rjenkins1
    item osd.5 weight 3.638
    item osd.7 weight 3.638
    item osd.8 weight 3.638
    item osd.9 weight 0.465
    item osd.18 weight 0.465
    item osd.19 weight 3.638
    item osd.20 weight 3.638
}
datacenter EWB {
    id -16        # do not change unnecessarily
    id -17 class hdd        # do not change unnecessarily
    id -18 class ssd        # do not change unnecessarily
    # weight 41.880
    alg straw2
    hash 0    # rjenkins1
    item vm-2 weight 22.759
    item vm-6 weight 19.121
}
root Langeoog {
    id -1        # do not change unnecessarily
    id -2 class hdd        # do not change unnecessarily
    id -15 class ssd        # do not change unnecessarily
    # weight 80.929
    alg straw2
    hash 0    # rjenkins1
    item Rathaus weight 39.049
    item EWB weight 41.880
}

# rules
rule replicated_rule {
    id 0
    type replicated
    min_size 1
    max_size 10
    step take Langeoog
    step chooseleaf firstn 0 type host
    step emit
}
rule ssd {
    id 1
    type replicated
    min_size 1
    max_size 10
    step take Langeoog class ssd
    step chooseleaf firstn 0 type datacenter
    step emit
}
rule hdd {
    id 2
    type replicated
    min_size 1
    max_size 10
    step take Langeoog class hdd
    step chooseleaf firstn 0 type datacenter
    step emit
}

# end crush map
Logs

Wir haben also zwei Standorte an denen sich jeweils zwei Server befinden. Es wird in kürze noch ein dritter Standort hinzu kommen.

Ich habe dann gesehen, das Ceph etwa 2/3 der PGs als active+clean+remapped angezeigt hat und zwar dauerhaft. Zu dem Zeit fehlte an einem Standord noch der eine VM Server auf dem die VMs noch liefen. Mein Gedanke war, okay, das kommt weil der eine Server halt noch fehlt, das wird sich erledigen wenn der Server auch noch in das Ceph integriert wird.
Ich habe dann angefangen, die VM Images auf das Ceph zu schieben, und den letzten Server in das Ceph einzubinden. Immerhin war der Ceph Status "Health OK"
Heute morgen nachdem der rebalance durch den neuen Server eigentlich durch sein sollte sehe ich dann folgendes:

root@vm-3:/#ceph health detail
HEALTH_ERR 93 scrub errors; Possible data damage: 33 pgs inconsistent; Degraded data redundancy: 195721/5411244 objects degraded (3.617%), 117 pgs unclean, 117 pgs degraded, 117 pgs undersized
OSD_SCRUB_ERRORS 93 scrub errors
PG_DAMAGED Possible data damage: 33 pgs inconsistent
[...]
PG_DEGRADED Degraded data redundancy: 195721/5411244 objects degraded (3.617%), 117 pgs unclean, 117 pgs degraded, 117 pgs undersized
[...]

Alle inkonsisten PGs verteilen sich bunt über verschiedene OSDs auf 3 Servern, der zuletzt hinzu gekommene Server enthält keinerlei inkonsistente OSDs.
Da die so viele verschiedene OSDs (vierzehn verschiedene) betroffen sind und diese sich auch über 3 Server verteilen, mag ich einen Hardware defekt schon fast ausschließen.

Meine Fragen:
1.) Wie bekomme ich diesen Kram jetzt wieder in einen konsistenten Status ohne Daten zu verlieren?
2.) Wie groß ist die Gefahr das mir der Ceph Cluster gleich ganz um die Ohren fliegt?
Achja, die OSDs verwenden Bluestore...

Achja ceph.conf wäre vielleich auch nicht schlecht:

Spoiler: ceph.conf

root@vm-1:/# cat /etc/ceph/ceph.conf
[global]
         auth client required = cephx
         auth cluster required = cephx
         auth service required = cephx
         cluster network = 192.168.15.0/24
         fsid = 39629f5b-df77-441a-a4f0-8fa7eb388c0f
         keyring = /etc/pve/priv/$cluster.$name.keyring
         mon allow pool delete = true
         osd journal size = 5120
         osd pool default min size = 2
         osd pool default size = 3
         public network = 192.168.15.0/24

[osd]
         keyring = /var/lib/ceph/osd/ceph-$id/keyring

[mon.vm-3]
         host = vm-3
         mon addr = 192.168.15.3:6789

[mon.vm-2]
         host = vm-2
         mon addr = 192.168.15.2:6789

[mon.vm-6]
         host = vm-6
         mon addr = 192.168.15.6:6789

 

[markusd]

Hi, man möge mich korrigieren,
aber ich würde mal vermuten bei einer pool-size von "drei" benötigst Du auch drei Server, auf die sich der jweilige Pool verteilen kann.
Du hast aber geschrieben, Du hast zwei Server je ssd-pool und hdd-pool.
Richtig?
Dann würde es temporär mit einer pool-size von "zwei" gehen.
Ist aber wirklich nicht empfehlenswert.
Liege ich richtig, benötigst Du noch je einen Server mit ssd`s /hdd`s oder musst hdd`s und ssd`s mischen.

Wie sind denn die Standorte mit einander angebunden?
10Gbit machen schon Sinn.

Gruß

Markus

 

[Ingo S]

Hallo

Nicht ganz richtig... Ich habe insgesamt 4 Server im Cluster, von denen sich jeweils zwei an einem Standort befinden. Auf allen Servern laufen jeweils zwei SSD-OSDs und 5-6 HDD OSDs. Es gibt also 8 SSD OSDs und 30 HDD OSDs

Es gibt einen Pool der dediziert nur HDDs zum Speichern der Objekte nutzt und einen Pool der nur die SSDs nutzt.

Die Server kommunizieren über 10GBit Ethernet, die Standorte sind mit 40GBit angebunden.

 

[Alwin]

Die 'crush rules' haben die Failure-Domain auf Datacenter, da es nur zwei Datacenter mit jeweils zwei OSD hosts gibt, kann kein Replica von 3 gefahren werden. Der dritte Standort wäre dringend von Nöten, da auch die Monitore gleich verteilt werden müssen um einen Ausfall eines Datacenter verkraften zu können.

 

[Ingo S]

Guten Morgen

Ich muss dieses Thema nochmal aufwärmen.
Unser Ceph läuft ganz gut, aber es tauchen immer noch "inconsistent pg's" auf. Meistens jeden Tag eine oder zwei neue, die ich dann mit "ceph pg repair ..." wieder in Ordnung bringe.

Ich habe mal mitgeschrieben welche PGs wo beschädigt werden:

VM-1      
    OSD.22  
    OSD.23    x
    OSD.24    x
    OSD.25  
    OSD.26    x
    OSD.27  
    OSD.28    xx
    OSD.29  

VM-2      
    OSD.0    xx
    OSD.1    xxxx
    OSD.2    x
    OSD.11  
    OSD.12    xxx
    OSD.13  
    OSD.21    x
       
VM-3      
    OSD.5  
    OSD.7    xxx
    OSD.8    x
    OSD.9  
    OSD.18  
    OSD.19  
    OSD.20  
    OSD.30    x

VM-6      
    OSD.3    x
    OSD.4    x
    OSD.6    x
    OSD.10  
    OSD.14  
    OSD.15    x
    OSD.16  
    OSD.17

Man sieht, dass die überwiegende Mehrzahl der Fehlerhaften PGs allem Anschein nach auf VM2 liegt.

Merkwürdigkeit1:
Wir hatten vor Ceph Luminous nicht eine einzige Fehlerhafte PG

Merkwürdigkeit2:
Die Vermutung liegt nahe, es könnte eine Hardware defekt sein. Wir haben aber keinerlei merkwürdiges Systemverhalten. Keine abgestürzten Prozesse, oder sonstige Auffälligkeiten. Die defekten PGs treten ja auch auf anderen Servern auf, nur nicht so häufig.

Ich bin sehr skeptisch was defekte Hardware angeht, weil alle Server relativ neu sind und wir damit auch in der Vergangenheit mit CEPH nicht ein einziges Problem mit defekten PGs hatten. Aber ich habe auch keine andere Idee was es sein könnte.

Wie kann ich das Problem genauer unter die Lupe nehmen?

 

[Alwin]

Was steht den in den Logdateien der jeweiligen OSDs? Laufen nur VMs oder auch Container?

 

[Ingo S]

So, ich habe jetzt die ganze Zeit auf weitere inkonsistente PGs gewartet, aber es ist nicht eine einzige mehr aufgetreten. Möglicherweise wurde das Problem mit einem Update behoben, sonst kann ich mir das nicht erklären.

Ich würde sagen, das hier hat sich damit erledigt.