CEPH KEY MIGRATION: pvestad nicht verfügar?

G

grefabu

Renowned Member
May 23, 2018
268
20
83
52
Moin,

beim ausführen des KEY Rotate Scripts erhalte ich:

Code: 
root@prod-pve01:~# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --rotate-cluster-keys
INFO: This is a dry run. No Ceph key, cipher setting, or daemon will be changed. Session observations can update the migration journal.
FAIL: Could not verify 'aes256k' support for every service daemon:
  could not verify the installed Ceph version of mon. on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of mon. on node 'prod-pve02.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of mon. on node 'prod-pve03.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of mgr.prod-pve01 on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of mgr.prod-pve02 on node 'prod-pve02.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of mgr.prod-pve03 on node 'prod-pve03.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of osd.0 on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of osd.1 on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of osd.2 on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  could not verify the installed Ceph version of osd.3 on node 'prod-pve01.emt.local'; check that 'pvestatd' runs there
  and 14 more

Aber ein

Code: 
root@prod-pve01:~# ssh prod-pve01.emt.local pvestatd status
running

Sieht doch gut aus?
 
Das "check that pvestatd runs there" ist irreführend. Schau dir mal die Namen in der Fehlermeldung an: da stehen FQDNs (prod-pve01.emt.local), und das Skript vergleicht Ceph-Daemons über den Hostnamen aus den Metadaten mit den PVE-Node-Namen. Wenn deine Nodes im Cluster kurz heißen (prod-pve01), findet er keine gemeldete Ceph-Version und zeigt dir den pvestatd-Hinweis, obwohl der Daemon läuft.

Was sagt denn pvecm nodes bei dir, und was kommt bei

Code: 
ceph mon metadata | grep -i '"hostname"'
ceph osd metadata | grep -i '"hostname"'

raus? Wenn da überall der FQDN drinsteht und die Cluster-Nodes kurz sind, ist das die Ursache. Der Daemon schreibt die Metadaten beim Start basierend auf seinem Hostnamen. Das kommt meist von /etc/hostname mit FQDN zum Zeitpunkt des Ceph-Setups. Ich bin mir nicht sicher, ob das Skript das abfangen sollte. Falls sich der Verdacht bestätigt, wäre ein Bugreport sinnvoll.
 
Moin,

so einen mismatch habe ich schon vermutet.


Code: 
root@prod-pve01:~# pvecm nodes

Membership information
----------------------
    Nodeid      Votes Name
         1          1 prod-pve04
         2          1 prod-pve02
         3          1 prod-pve03
         4          1 prod-pve01 (local)
         5          1 prod-pve05

Code: 
root@prod-pve01:~# ceph mon metadata | grep -i '"hostname"'
        "hostname": "prod-pve01.emt.local",
        "hostname": "prod-pve02.emt.local",
        "hostname": "prod-pve03.emt.local",
        "hostname": "prod-pve04",
        "hostname": "prod-pve05",

Code: 
root@prod-pve01:~# ssh prod-pve01.emt.local hostname
prod-pve01.emt.local
root@prod-pve01:~# ssh prod-pve02.emt.local hostname
prod-pve02.emt.local
root@prod-pve01:~# ssh prod-pve03.emt.local hostname
prod-pve03.emt.local
root@prod-pve01:~# ssh prod-pve04.emt.local hostname
prod-pve04
root@prod-pve01:~# ssh prod-pve05.emt.local hostname
prod-pve05
 
Ja, das geht, aber schau dir vorher mal ceph osd tree an. Es kommt drauf an, wie die Host-Buckets im CRUSH heißen. Wenn die bei 01-03 auch mit FQDN drinstehen, wandern die OSDs beim Start nach dem Hostname-Wechsel in einen neuen Bucket. osd_crush_update_on_start ist ja per Default an, dann hast du ein fettes Rebalance am Hals. Falls ja, vorher ceph osd crush rename-bucket prod-pve01.emt.local prod-pve01 absetzen, das Rename behält die IDs und die Kinder, bewegt also nichts. Sind die Buckets schon kurz, passt's.

Der Rest geht unkompliziert: pro Node die /etc/hostname auf den kurzen Namen, in /etc/hosts die Zeile als <IP> prod-pve01.emt.local prod-pve01 stehen lassen, dann Reboot. Der PVE-Nodename ist bei dir ja sowieso schon kurz, an /etc/pve/nodes/ ändert sich also nichts. Vorher ceph osd set noout, immer nur einen Node und zwischendurch HEALTH_OK abwarten. Mon/mgr/osd schreiben beim Start ihre Metadaten neu. Danach sollte ceph mon metadata überall kurz sein und das Rotate-Script Ruhe geben.

Ich würd mit einem Node anfangen und danach erst mal schauen, ob die Metadaten wirklich umgesprungen sind, bevor du die anderen beiden machst.
 
  • Like
Reactions: grefabu
Code: 
root@prod-pve01:~# ceph osd tree | grep host
 -3         10.47958      host prod-pve01
 -5         10.47958      host prod-pve02
 -7         10.47958      host prod-pve03
 -9         10.47958      host prod-pve04
-11         10.47958      host prod-pve05

Na, dann sieht es ja nach einem kleineren Aufwand aus!
 
Vielleicht noch eine Frage:
Was bewirkt
Code: 
ceph osd set noout
, muss ich das nach dem Reboot wieder zurücksetzen?
 
noout sagt Ceph nur: markier mir keine OSD als out, auch wenn sie down ist. Ohne das Flag kippt ein OSD nach mon_osd_down_out_interval (default 600s) auf out und der Cluster baut die PGs woanders neu auf. Bei einem Reboot ist das unnötig, die Platten sind ja gleich wieder da.

Und ja, danach wieder weg mit ceph osd unset noout. Solange es gesetzt ist, steht der Cluster auf HEALTH_WARN mit "noout flag(s) set", das ist quasi die eingebaute Erinnerung. Wenn du's feiner haben willst, geht auch ceph osd set-group noout prod-pve01 nur für den einen Host, dann fährt der Rest normal weiter.
 
You must log in or register to reply here.
Top Bottom
Back