Memo an mich selbst: Sollte es vorkommen, das ceph health detail der Meinung ist, das inkonsistente Placementgroups vorhanden sind: cool bleiben!
Wenn man es nicht auf die lange Bank schiebt und sich die Doku dazu gut angesehen hat, dann wird man recht schnell fündig wie man der Sache Herr werden kann.
Zunächst einmal findet man heraus, welche PGs kaputt sind:
ceph health detail
HEALTH_ERR 2 scrub errors; Possible data damage: 2 pgs inconsistent
OSD_SCRUB_ERRORS 2 scrub errors
PG_DAMAGED Possible data damage: 2 pgs inconsistent
pg 9.9d is active+clean+inconsistent, acting [2,12,23]
pg 9.fe is active+clean+inconsistent, acting [15,23,2]Man sieht hier, das die PGs mit den IDs 9.9d und 9.fe einen weg haben.
Anschließend startet man die Heilung:
ceph pg repair 9.9d
ceph pg repair 9.feGar nicht so schwer, oder?
Ich habe mir in meinem Proxmox-Cluster drei Knoten abgestellt, auf denen ich gern ein Backup der laufenden VMs erstellen möchte. Da mir hier die Performance nicht ganz so wichtig ist, ich aber gleichzeitig maximale Skalierbarkeit und Verfügbarkeit haben möchte, ist der Schritt zu Ceph eigentlich ein logischer.
Dummerweise hat Proxmox dieses Szenario nicht so interpretiert wie ich es gern hätte, sodass sie nur vorsehen ganze Festplatten für Ceph zu nutzen. Mein Setup ist aber viel cooler, denn ich habe auf dem Server, welcher 8 HDDs bestitzt ein ZFS Raid1 über ALLE Plattengespannt, sodass absolut jede Festplatte ausfallen kann ohne das das System kaputt geht. Dazu nutze ich allerdings nur 40GB als Partition - der Rest kann als Backup Platz genutzt werden.
Dafür muss man aber ein wenig Handarbeit leisten.
Auf allen Hosts muss Ceph installiert werden, damit sie es nutzten können.
pveceph installAnschließend kann man seinen Ceph Cluster einfach erstellen - ich nutzte als Netzwerk das ohnehin schon vorhandene Backup Netzwerk:
pveceph init --network 192.168.199.0/24Nun muss man sich die ClusterID notieren: grep -i fsid /etc/pve/ceph.conf
Damit Ceph funktionieren kann, braucht es mindestens einen, idealerweise aber mehrere Monitore. Ich nutze dazu meine 3 Backup Knoten und initialisiere sie als Monitor
pveceph createmonNun wird es ernst. Ich bin ein fauler Admin. Daher habe ist bei mir möglichst viel einheitlich, damit ich automatisieren kann. In meinem Fall wird auf jeder Festplatte eine 4. Partition erstellt und für Ceph genutzt. Ich benutzt noch eine Paket, das zusätzlich installiert werden muss um eindeutige UUIDs zu erstellen:
apt-get install uuid-runtimeAnschließend kann es losgehen mit der Vorbereitung
PARTITION=4
PTYPE=4FBD7E29-9D25-41B8-AFD0-062C0CEFF05D
CLUSTERID=
for i in a b c d e f g h
do
OSD_UUID=$(uuidgen -r)
sgdisk -d $PARTITION /dev/sd$i
sgdisk --largest-new=$PARTITION --change-name="$PARTITION:ceph data" --partition-guid=$PARTITION:$OSD_UUID --typecode=$PARTITION:$PTYPE -- /dev/sd$i
done
partprobe
for i in a b c d e f g h
do
OSD_UUID=$(uuidgen -r)
ceph-disk prepare --filestore --cluster ceph --cluster-uuid $CLUSTERID --osd-uuid $OSD_UUID --fs-type xfs /dev/sd$i$PARTITION
ceph-disk activate /dev/sd$i$PARTITION
doneDieser Schritt dauert ein wenig. Man sollte allerdings zusehen können, die die OSDs im Proxmox auftauchen. Zur Sicherheit würde ich einen Reboot des Servers ausführen. Kontrollieren kann man übrigens auch über die CLI
ceph osd tree
ceph statusQuellen und Links: