Vorgehensweise eines Release Upgrades im verteilten Monitoring

Hallo Forum,
wie geht ihr bei einem Release Upgrade im verteilten Monitoring vor?

Wir nutzen die Enterprise Version und die Agent-Bakery liegt natürlich auch auf der Main-Site.

Wir haben eine Main-Site als Cluster auf den CheckMK-Appliances laufen.

Dazu haben wir 5 weitere Sites auf verschiendenen VMs, welche mit dem verteilten Monitoring angebunden sind. Die Konfiguration der Main-Site wird auf die Slave-Sites gepusht.

Unsere bisherige Vorgehenweise war es alle Site zu stoppen und das Update zuerst auf der Main-Site zu installieren und diese wieder zu starten.

Danach wurde auf jeder einzelne Site das Update installiert und diese wieder gestartet.

Geht ihr auch so vor oder updatet ihr zuerst die Slave-Sites und zuletzt die Main?
Macht ihr die Updates alle kurz nacheinander oder schiebt ihr diese zum Teil auf mehrere Tage(egal Main-Site zuerst oder zuletzt)?

Wir hatten nämlich damals das Problem bei dem Update von 1.5.0 auf 1.6.0, dass einige Checks dann nicht mehr auf der Slave-Site ausgeführt werden konnten, weil diese auf Version 1.6.0 war aber die Main-Site noch auf 1.5.0 und die Checks der 1.5.0 Version auf die Slave Site pushte.

Hallo,

das Vorgehen hängt vom Release ab. Innerhalb eines Releases. 1.5px -> 1.5py mache ich erst ein Update auf die Zentrale Site, und anschliessend auf die Slaves.
Bei 1.5px -> 1.6 fahre ich alle Sites runter und beginne bei der Main Site. Nach dem diese gestartet ist werden nach und nach die Slaves auf 1.6 gebracht und hochgefahren.
Das sollte in den meisten Fällen passen.

Gruß, Christian

1 Like

Hallo Chrisitan,
danke für Ihre Rückmeldung.
Dann lag ich mit meinem Vorgehen gar nicht so verkehrt.
Werde es in Zukunft genauso wie Sie machen.

Gruß
Lars

1 Like