Hallo zusammen,
TL;DR Uns macht momentan das aktivierte Journaling-Feature bei LX-Containern zu schaffen. Einerseits ist dies für den rbd-mirror Sync in einen Pool vom Master zu Slave cluster obligatorisch, andererseits hindert es Container im Master an einem (Neu)start
____________________________
Systemdaten:
Cluster: 2
Proxmox-Instanzen pro Cluster: 4
Ceph-Version: Nautilus (14)
Proxmox-Version: 6.1 mit neuesten Updates
OSD-Versionen: Alle 14.2.6
Szenario:
Wir haben einen Cluster zu einem Prod-Cluster auserkoren. Von diesem wurde ein one-way rbd-mirror in einen eigens dafür angelegten Pool auf dem Slave-Cluster konfiguriert (Nach offizieller Proxmox Dokumentation!). Für Images, welche gesynct werden sollen sind die Features "Exclusive-Lock" und "Journaling" bekanntermaßen Pflicht. Der Sync läuft einwandfrei.
Also wir nun am Wocheende das Katastrophenszenario getestet haben gelang das Promoten des Slave-Pools und das Spawnen der Images als LXC-Instanzen problemlos. Als wir dann jedoch das Katastrophenszenario wieder rückgängig machen, also die Slave-LXC-Instanzen deaktivierten und einfach wieder den Master-Cluster in Betrieb nehmen wollten, fiel uns auf, dass das Journaling-Feature, das (neu)starten eines LX-Containers verhindert. Dies haben wir gerade noch mehrmals getrennt von dem rbd-mirror Szenario getestet.
Lediglich das Journaling-Feature ist hier ausschlaggebend. Deaktiviert man es kann man einen Container ohne weiteres starten. Aktiviert man es wieder ist das Starten eines abgeschalteten Containers nicht mehr möglich.
Zuerst erhält man:
Dann
Dann mit einem lxc-start -F für eine genauere Fehlermeldung:
_________________________________
Wo genau leigt evtl. unser Denkfehler? Wenn wir keinen Denkfehler haben, erklärt uns bitte weshalb das Journaling-Feature für ein rbd-mirror Pflicht ist? Was tut es genau? Warum hindert es Container am (neu)start und gefährdet damit unserer bescheidenen Meinung nach das von uns erdachte Katastrophenszenario.
Danke
EDIT: Rechtschreibung
EDIT2: Wir sind auf 6.1 nicht auf 6.0
TL;DR Uns macht momentan das aktivierte Journaling-Feature bei LX-Containern zu schaffen. Einerseits ist dies für den rbd-mirror Sync in einen Pool vom Master zu Slave cluster obligatorisch, andererseits hindert es Container im Master an einem (Neu)start
____________________________
Systemdaten:
Cluster: 2
Proxmox-Instanzen pro Cluster: 4
Ceph-Version: Nautilus (14)
Proxmox-Version: 6.1 mit neuesten Updates
OSD-Versionen: Alle 14.2.6
Szenario:
Wir haben einen Cluster zu einem Prod-Cluster auserkoren. Von diesem wurde ein one-way rbd-mirror in einen eigens dafür angelegten Pool auf dem Slave-Cluster konfiguriert (Nach offizieller Proxmox Dokumentation!). Für Images, welche gesynct werden sollen sind die Features "Exclusive-Lock" und "Journaling" bekanntermaßen Pflicht. Der Sync läuft einwandfrei.
Also wir nun am Wocheende das Katastrophenszenario getestet haben gelang das Promoten des Slave-Pools und das Spawnen der Images als LXC-Instanzen problemlos. Als wir dann jedoch das Katastrophenszenario wieder rückgängig machen, also die Slave-LXC-Instanzen deaktivierten und einfach wieder den Master-Cluster in Betrieb nehmen wollten, fiel uns auf, dass das Journaling-Feature, das (neu)starten eines LX-Containers verhindert. Dies haben wir gerade noch mehrmals getrennt von dem rbd-mirror Szenario getestet.
Lediglich das Journaling-Feature ist hier ausschlaggebend. Deaktiviert man es kann man einen Container ohne weiteres starten. Aktiviert man es wieder ist das Starten eines abgeschalteten Containers nicht mehr möglich.
Zuerst erhält man:
Code:
root@proxmoxsm34:~# pct start 112233445
Job for pve-container@112233445.service failed because the control process exited with error code.
See "systemctl status pve-container@112233445.service" and "journalctl -xe" for details.
command 'systemctl start pve-container@112233445' failed: exit code 1
Dann
Code:
root@proxmoxsm34:~# journalctl -u pve-container@112233445
-- Logs begin at Sat 2020-01-25 12:03:35 CET, end at Mon 2020-01-27 09:57:04 CET. --
Jan 25 12:12:55 proxmoxsm34 systemd[1]: Starting PVE LXC Container: 112233445...
Jan 25 12:12:57 proxmoxsm34 systemd[1]: Started PVE LXC Container: 112233445.
Jan 25 12:18:24 proxmoxsm34 systemd[1]: pve-container@112233445.service: Succeeded.
Jan 27 09:36:11 proxmoxsm34 systemd[1]: Starting PVE LXC Container: 112233445...
Jan 27 09:36:12 proxmoxsm34 lxc-start[1873895]: lxc-start: 112233445: lxccontainer.c: wait_on_daemonized_start: 865 No such file or directory - Failed to receive the container state
Jan 27 09:36:12 proxmoxsm34 lxc-start[1873895]: lxc-start: 112233445: tools/lxc_start.c: main: 329 The container failed to start
Jan 27 09:36:12 proxmoxsm34 lxc-start[1873895]: lxc-start: 112233445: tools/lxc_start.c: main: 332 To get more details, run the container in foreground mode
Jan 27 09:36:12 proxmoxsm34 lxc-start[1873895]: lxc-start: 112233445: tools/lxc_start.c: main: 335 Additional information can be obtained by setting the --logfile and --logpriority options
Jan 27 09:36:12 proxmoxsm34 systemd[1]: pve-container@112233445.service: Control process exited, code=exited, status=1/FAILURE
Jan 27 09:36:12 proxmoxsm34 systemd[1]: pve-container@112233445.service: Failed with result 'exit-code'.
Jan 27 09:36:12 proxmoxsm34 systemd[1]: Failed to start PVE LXC Container: 112233445.
Dann mit einem lxc-start -F für eine genauere Fehlermeldung:
Code:
root@proxmoxsm34:~# lxc-start -F -f /etc/pve/local/lxc/112233445.conf --name test-tp --logpriority TRACE
lxc-start: test-tp: utils.c: safe_mount: 1212 No such file or directory - Failed to mount "/dev/pts/10" onto "/dev/console"
lxc-start: test-tp: conf.c: lxc_setup_dev_console: 1774 Failed to mount "/dev/pts/10" on "/dev/console"
lxc-start: test-tp: conf.c: lxc_setup: 3683 Failed to setup console
lxc-start: test-tp: start.c: do_start: 1338 Failed to setup container "test-tp"
lxc-start: test-tp: sync.c: __sync_wait: 62 An error occurred in another process (expected sequence number 5)
lxc-start: test-tp: start.c: lxc_abort: 1133 Function not implemented - Failed to send SIGKILL to 1983476
lxc-start: test-tp: start.c: __lxc_start: 2080 Failed to spawn container "test-tp"
lxc-start: test-tp: tools/lxc_start.c: main: 329 The container failed to start
lxc-start: test-tp: tools/lxc_start.c: main: 335 Additional information can be obtained by setting the --logfile and --logpriority options
_________________________________
Wo genau leigt evtl. unser Denkfehler? Wenn wir keinen Denkfehler haben, erklärt uns bitte weshalb das Journaling-Feature für ein rbd-mirror Pflicht ist? Was tut es genau? Warum hindert es Container am (neu)start und gefährdet damit unserer bescheidenen Meinung nach das von uns erdachte Katastrophenszenario.
Danke

EDIT: Rechtschreibung
EDIT2: Wir sind auf 6.1 nicht auf 6.0

Last edited: