Ceph spinnt nach host reinstall

[Ingo S]

Moin zusammen

Nachdem uns heute leider das Systemlaufwerk eines PVE/Ceph Hosts gestorben ist, habe ich besagten Server aus dem Cluster entfernt, sowohl PVE als auch CEPH.
Der Host taucht nirgendwo mehr auf.
Nach der Neuinstallation habe ich den Host wieder in den PVE Cluster eingefügt und anschließend über die GUI Ceph dort installiert. Dabei wurden keine Fehler gemeldet.

Wenn ich aber die OSDs neu anlegen will, erhalte ich eine Fehlermeldung:
root@vm-6:~# ceph-volume lvm prepare --bluestore --data /dev/sda --block.wal /dev/nvme0n1p1 --block.db /dev/nvme0n1p1 Running command: /usr/bin/ceph-authtool --gen-print-key --> RuntimeError: No valid ceph configuration file was loaded.
Ceph Status sagt mir:
root@vm-6:~# ceph status Error initializing cluster client: ObjectNotFound('RADOS object not found (error calling conf_read_file)')
Was ist denn da los?
Ich bin da jetzt ein wenig ratlos...
Einzig, durch die Neuinstallation von VM-6 unterscheidet sich die PVE-Version. VM-6 hat Version 7.1-6, alle anderen Hosts habe Verson 7.0-11.
Die installierte Ceph-Version ist aber identisch, 16.2.6 (pacific)

Hier die Config files des Clusters:

Spoiler: corosync.conf

root@vm-6:/etc/pve# cat corosync.conf
logging {
debug: off
to_syslog: yes
}

nodelist {
node {
name: vm-1
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.16.1
}
node {
name: vm-2
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.16.2
}
node {
name: vm-3
nodeid: 3
quorum_votes: 1
ring0_addr: 192.168.16.3
}
node {
name: vm-4
nodeid: 4
quorum_votes: 1
ring0_addr: 192.168.16.4
}
node {
name: vm-5
nodeid: 5
quorum_votes: 1
ring0_addr: 192.168.16.5
}
node {
name: vm-6
nodeid: 6
quorum_votes: 1
ring0_addr: 192.168.16.6
}
}

quorum {
provider: corosync_votequorum
}

totem {
cluster_name: Langeoog
config_version: 29
interface {
bindnetaddr: 192.168.16.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}

Spoiler: ceph.conf

root@vm-6:/etc/pve# cat 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
mon_allow_pool_delete = true
mon_host = 192.168.15.2 192.168.15.1 192.168.15.5
osd_journal_size = 51200
osd_pool_default_min_size = 2
osd_pool_default_size = 3
osd_scrub_begin_hour = 20
osd_scrub_end_hour = 6
public_network = 192.168.15.0/24

[client]
keyring = /etc/pve/priv/$cluster.$name.keyring

[mon.vm-1]
public_addr = 192.168.15.1

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

[mon.vm-5]
public_addr = 192.168.15.5

 

[mira]

Gibt es eine Ceph Config in /etc/ceph?

 

[Ingo S]

Nein...

root@vm-6:/# ls -ahl /etc/ceph/
total 12K
drwxr-xr-x  2 root root 4.0K Dec  2 10:58 .
drwxr-xr-x 89 root root 4.0K Dec  2 11:48 ..
-rw-r--r--  1 root root   92 Aug  9 14:41 rbdmap
root@vm-6:/#

Warum wurde die nicht bei der Einrichtung über die GUI angelegt bzw. verlinkt? Ich rieche da einen Bug

Reicht es, wenn ich die ceph.conf aus /etc/pve dahin verlinke oder muss da noch mehr gemacht werden?

 

[mira]

Verlinken sollte reichen. So sieht es bei mir aus:

-rw------- 1 ceph ceph 151 Oct 18 11:05 ceph.client.admin.keyring
lrwxrwxrwx 1 root root  18 Oct 18 11:05 ceph.conf -> /etc/pve/ceph.conf
-rw-r--r-- 1 root root  92 Apr 21  2021 rbdmap

Wurde denn der Node rebooted nach der Installation?

 

[Ingo S]

Nein, der Node wurde nicht neu gestartet. Es gab auch keine Aufforderung dazu. Meines wissens nach, war das in der Vergangenheit auch nie nötig.

Hmm...

root@vm-6:/# ls -ahl /etc/ceph/
total 16K
drwxr-xr-x  2 root root 4.0K Dec  2 14:15 .
drwxr-xr-x 89 root root 4.0K Dec  2 11:48 ..
-rw-------  1 root root   63 Dec  2 14:14 ceph.client.admin.keyring
lrwxrwxrwx  1 root root   12 Dec  2 14:15 ceph.conf -> ../ceph.conf
-rw-r--r--  1 root root   92 Aug  9 14:41 rbdmap
root@vm-6:/#
root@vm-6:/#
root@vm-6:/#ceph health
Error initializing cluster client: ObjectNotFound('RADOS object not found (error calling conf_read_file)')
root@vm-6:/#

 

[wigor]

ceph.conf -> /etc/pve/ceph.conf

sollte das sein, nicht

ceph.conf -> ../ceph.conf

ich meine, ich bin da auch schon mal drauf reingefallen.

 

[Ingo S]

Ich dussel... ich hab falsch verlinkt und vergessen, die Berechtigungen zu setzen...

 

[Ingo S]

Also für mich sieht es so aus, also ob Ceph auf dem neuen Node gar nicht richtig eingerichtet ist...
Wie kann das sein?

root@vm-6:/etc/ceph# ceph-volume lvm prepare --bluestore --data /dev/sda --block.wal /dev/nvme0n1p1 --block.db /dev/nvme0n1p1
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new 354455b6-9c08-42f0-97b8-3494076ae93a
 stderr: 2021-12-02T14:23:01.252+0100 7f11cb9fd700 -1 auth: unable to find a keyring on /etc/pve/priv/ceph.client.bootstrap-osd.keyring: (2) No such file or directory
 stderr: 2021-12-02T14:23:01.252+0100 7f11cb9fd700 -1 AuthRegistry(0x7f11c405b128) no keyring found at /etc/pve/priv/ceph.client.bootstrap-osd.keyring, disabling cephx
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 auth: unable to find a keyring on /var/lib/ceph/bootstrap-osd/ceph.keyring: (2) No such file or directory
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 AuthRegistry(0x7f11c405b128) no keyring found at /var/lib/ceph/bootstrap-osd/ceph.keyring, disabling cephx
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 auth: unable to find a keyring on /var/lib/ceph/bootstrap-osd/ceph.keyring: (2) No such file or directory
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 AuthRegistry(0x7f11c40604b0) no keyring found at /var/lib/ceph/bootstrap-osd/ceph.keyring, disabling cephx
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 auth: unable to find a keyring on /var/lib/ceph/bootstrap-osd/ceph.keyring: (2) No such file or directory
 stderr: 2021-12-02T14:23:01.256+0100 7f11ca79b700 -1 AuthRegistry(0x7f11ca79a0e0) no keyring found at /var/lib/ceph/bootstrap-osd/ceph.keyring, disabling cephx
 stderr: [errno 2] RADOS object not found (error connecting to the cluster)
-->  RuntimeError: Unable to create a new OSD id

 

[mira]

Gibt es denn Logs von der Installation?
Kommt der gleiche Fehler wenn im GUI oder über pveceph versucht wird eie OSD anzulegen?

 

[Ingo S]

Ich wüsste nicht, wo ich die logs von der Installation finde. Wenn die im Syslog sind, dann gucke ich ständig drüber weg, da finde ich sie jedenfalls nicht.

Über die GUI kann ich eine OSD anlegen. Ich mache das sonst aber grundsätzlich über die Konsole, da ich für jede OSD eine WAL.db auf einer Partition einer SSD habe. Das bekomme ich über die GUI nicht hin.
Echt merkwürdig. Ist nicht das erste Mal, das ich OSDs etc. auf einem neuen Host anlege, aber sowas ist mir noch nie passiert.

Idee: Das Script sucht ja den Keyring --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
Den gibt es aber so nicht, im ganzen Cluster nicht. Auf den "alten" nodes gibt es nur 2 keyrings, die so heißen, wie die beiden Storage Pools die wir angelegt haben.
Kann es sein, das in der PVE Version 7 irgendwas mit der Namensgebung der Keyring files geändert wurde? Muss ich vielleicht noch irgendwie den Storage Pool mit angeben, oder ihm neuerdings explizit den Namen des keyring mitteilen?

Das war in der PVE Version 6 auf jeden Fall nicht so...

 

[mira]

Mittlerweile sollte es möglich sein im GUI Partitionen auszuwählen für DB/WAL. Siehe https://bugzilla.proxmox.com/show_bug.cgi?id=2285
Also in PVE 7.1 sollte dies gehen.

 

[mira]

Noch eine Ergänzung, im Code legen wir die bootstrap Files beim Erstellen einer OSD an, sofern diese noch nicht existieren.
Das heißt, sobald das erste mal per GUI oder pveceph eine OSD erstellt wurde, sollte es auch über das Skript gehen.

 

[Ingo S]

Ich habe das ausprobiert. Auf VM-6, mit PVE 7.1-6 konnte ich tatsächlich auch die Partitionen auswählen. Das ist schonmal soweit OK.
Unter /var/lib/ceph liegt jetzt auch ein keyring.

Was ich nicht ganz verstehe: Woher kommen die Probleme jetzt auf einmal? Also: Sollten nicht bei der Installation von Ceph die bootstrap files gleich mit angelegt werden? und auch die Verlinkung zur Ceph-Config und der admin keyring unter /etc/ceph hat ja gefehlt und musste von mir manuell geradegebogen werden.
Ich habe wirklich nichts anderes getan als PVE installiert, die Netzwerkconfig aus dem Backup eingespielt, den Host in den PVE Cluster getan und anschließend über die GUI Ceph installiert. Das hat früher immer geklappt.

Kannst du vielleicht kurz erklären, was sich gegenüber PVE 6 geändert hat?
Ich würde mir gerne irgendwie sowas wie einen Handlungsstrang zusammenbasteln, nach dem ich einen kaputten Node wieder reparieren kann ohne mit Ceph und den OSDs ins straucheln zu geraten. Das hat mich jetzt nämlich quasi den ganzen Tag ab troubleshooting gekostet.
Danke

 

[Ingo S]

Irgendwie ist das schräg:

root@vm-3:/var/log# ceph df
--- RAW STORAGE ---
CLASS     SIZE    AVAIL     USED  RAW USED  %RAW USED
hdd     88 TiB   67 TiB   22 TiB    22 TiB      24.41
ssd     17 TiB  7.9 TiB  9.6 TiB   9.6 TiB      54.86
TOTAL  106 TiB   75 TiB   31 TiB    31 TiB      29.43
 
--- POOLS ---
POOL                   ID   PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
HDD_Storage             1  1024  8.7 TiB    2.77M   20 TiB  27.86     23 TiB
SSD_Storage             7   512  3.3 TiB    6.61M  9.6 TiB  85.31    606 GiB
device_health_metrics   8     1   34 MiB       43   67 MiB      0    5.0 TiB

Der SSD-Pool ist 17GiB groß. Davon sind 3,3GiB echte Daten. Aufgrund der Pool Size von 3 sind das dann 9,6TiB used insgesamt. Soweit okay. Aber warum sollen 9,6TiB von 17TiB eigentlich 85% Used und nur noch 606GB verfügbar sein?
17TiB - 9,6TiB = 7,4TiB
7,4TiB / 3 = 2,46 TiB
Es sollten doch also eigentlichnoch etwa 2,4TiB Speicherplatz nutzbar sein und nicht 606GiB?

Ich steh gerade völlig auf dem Schlauch!?

 

[mira]

Dies hängt von der Auslastung der OSDs ab. Dieses 85.31% Used deutet darauf hin, dass eine der OSDs dieses Pools zu 85.31% voll ist.
Bei Ceph, sobald eine der OSDs voll ist, ist der ganze Pool volll. Darum sollte man schauen, dass die OSDs immer sehr ähnlich belegt sind.

Ein ceph osd df sollte mehr Informationen diesbezüglich bieten.

 

[Ingo S]

Danke, das leuchtet ein
Über Nacht hat sich nach dem Rebalance auch alles etwas beruhigt.

Dennoch, OSD.4 ist immer signifikant voller, als die anderen OSDs des Pools. Alle OSDs haben aber einen reweight von 1.
Im Ceph Manager ist auch das Balancer Modul aktiviert, da sollte doch eigentlich die Verteilung recht gleichmäßig sein.

Wenn man sich mal die tatsächliche Verteilung mit ceph df ssd für den SSD Pool anguckt stellt man aber erhebliche Unterschiede fest.

root@vm-3:/var/log# ceph osd df ssd
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE   DATA     OMAP      META     AVAIL    %USE   VAR   PGS  STATUS
 4    ssd  1.45499   1.00000  1.5 TiB   930 GiB  928 GiB   3.9 MiB  1.9 GiB  560 GiB  62.43  1.77  140      up
20    ssd  1.45499   1.00000  1.5 TiB   890 GiB  888 GiB   1.8 MiB  2.0 GiB  599 GiB  59.76  1.70  137      up
35    ssd  1.45549   1.00000  1.5 TiB   826 GiB  824 GiB   1.8 MiB  2.1 GiB  665 GiB  55.40  1.57  140      up
 5    ssd  1.45499   1.00000  1.5 TiB   815 GiB  813 GiB   1.9 MiB  2.2 GiB  675 GiB  54.69  1.55  135      up
10    ssd  1.45549   1.00000  1.5 TiB   802 GiB  800 GiB   1.8 MiB  2.2 GiB  688 GiB  53.83  1.53  136      up
 2    ssd  1.45499   1.00000  1.5 TiB   763 GiB  761 GiB   1.5 MiB  1.7 GiB  727 GiB  51.19  1.45  119      up
 3    ssd  1.45499   1.00000  1.5 TiB   761 GiB  760 GiB   1.5 MiB  1.5 GiB  729 GiB  51.08  1.45  117      up
32    ssd  1.45549   1.00000  1.5 TiB   750 GiB  747 GiB   1.8 MiB  3.1 GiB  741 GiB  50.31  1.43  126      up
12    ssd  1.45549   1.00000  1.5 TiB   749 GiB  747 GiB   1.6 MiB  2.1 GiB  741 GiB  50.28  1.43  127      up
33    ssd  1.45549   1.00000  1.5 TiB   746 GiB  743 GiB   1.8 MiB  2.8 GiB  745 GiB  50.02  1.42  125      up
34    ssd  1.45549   1.00000  1.5 TiB   706 GiB  704 GiB   1.7 MiB  1.8 GiB  784 GiB  47.39  1.34  119      up
 0    ssd  1.45499   1.00000  1.5 TiB   685 GiB  683 GiB   1.5 MiB  2.3 GiB  805 GiB  45.98  1.30  115      up
                       TOTAL   17 TiB  9.2 TiB  9.2 TiB   22 MiB   26 GiB  8.3 TiB  52.68

Für den HDD Pool sieht es ähnlich aus. Da stimmt doch was nicht...

 

[mira]

Wie ist denn der Status des Balancers? ceph balancer status [0]
Grundsätzlich wird es nie eine komplett gleiche Auslastung der OSDs geben, auf Dauer sollte es aber keine zu großen Unterschiede geben. Da hier noch >35% frei sind, muss man sich deswegen auch noch keine Gedanken machen.


[0] https://docs.ceph.com/en/latest/rados/operations/balancer/

 

[Ingo S]

Der Balancer war bis gerade eben eingeschaltet.

root@vm-1:~# ceph balancer status
{
    "active": true,
    "last_optimize_duration": "0:00:00.004411",
    "last_optimize_started": "Fri Dec  3 11:12:15 2021",
    "mode": "upmap",
    "optimize_result": "Optimization plan created successfully",
    "plans": []
}

Im Moment schiebe ich allerdings PGs mit "reweight-by-utilization" hin und her um das wenigstens ein wenig gleichmäßiger zu gestalten.

Das das nie völlig gleichmäßig ist, ist klar. In der Beschreibung des ceph-mgr balancer moduls steht aber auch drin, das zumindest die verteilung der PGs "perfekt" ist, solange die Anzahl der OSDs ein Teiler der PG Anzahl ist.
Aber man sieht, das es zwischen der vollsten OSD zur leersten OSD einen Unterschied von fast 20% gibt. Das ist schon arg. Und es ist auch die OSD, die dann dafür gesorgt hat, das Ceph die "near full" bei 85% Meldung gegeben hat und teilweise kein weiteres backfilling machen wollte, während auf der zweiten SSD-OSD im gleichen Host gerade 60% belegt waren und andere OSDs im gleichen Datacenter ebenfalls um die 60% lagen. Auch die Zahl der PGs ist sehr unterschiedlich, was laut Beschreibung des Balancers eigentlich nicht sein sollte.
Über Nacht hat sich das dann alles etwas entspannt. Dennoch etwas blöde, weil ich teilweise echt Sorge hatte, das mir während des rebalance die "full ratio" zuschlägt.

 

[wigor]

ceph osd df tree

kann auch helfen. Vielleicht sind die OSD nicht so gleichmässig über die racks/hosts verteilt.

 

[Ingo S]

Doch, sind sie. So einfach ist es leider nicht

Je Host 2x SSD OSD, und alle 6 Hosts sind zu gleichen teilen auf beide "Datacenter" aufgeteilt.