News zu Oracle

Oracle Clusterware modifiziert Rebootverhalten ab Version 19.13

Diverse Ereignisse im Cluster (u.a. Ausfall des Interconnects, Crash des ocssd-Prozesses) führen zu einer Node Eviction, die wiederum mit einem Reboot der betrof­fenen Server einher­gehen kann. Wenn der Reboot die Ursache der Eviction behebt, gliedern sich die Server anschließend wieder selbständig in den Cluster ein. Dazu müssen seit Patchlevel 19.13 weitere Vorkehrungen im Betriebssystem getroffen werden.

Freeze vs. Reboot

Mit Patchlevel 19.13.0.0.211019 (Release Update 10/2021) haben wir festge­stellt, dass ein betrof­fener Node einfriert statt zu rebooten. Die Folge davon wäre, dass sich die betrof­fenen Server nicht wieder selbständig in den Cluster integrieren, sondern per Remote Management Interface oder vor Ort im Serverraum manuell neu gestartet werden müssen.

Die nötige Erklärung liefert die My Oracle Support Doc ID 2821641.1:
We enabled kernel crash dump in 19.13 for some specific scenarios. Hence CSSD agent uses ‘echo c’ instead of ‘echo b’. If the kdump is not confi­gured, the system will appear hung and will not reboot because default “kernel.panic” parameter is set to 0.

Daraus folgt, dass ein Clusterserver ab Patchlevel 19.13 mit aktivem kdump laufen und/oder den Kernelparameter kernel.panic=1 gesetzt haben muss.

Folgender shell-Befehl muss mindestens für eine der Komponenten „kdump“ oder „kernel.panic“ mit „ist aktiv“ antworten. Dann ist auch mit Patchlevel 19.13 oder höher ein korrektes Rebootverhalten bei einer Node Eviction gegeben:

((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")

Beispiel eines betrof­fenen Systems:

# ((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")
kdump ist nicht aktiv
kernel.panic ist nicht aktiv

Beispiel eines NICHT betrof­fenen Systems:

# ((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")
kdump ist nicht aktiv
kernel.panic ist aktiv

Fazit

Um ein sauberes Rebootverhalten auch mit Grid Infrastructure 19.13 und höher sicher­zu­stellen, ist es dringend empfohlen, den erwähnten Test auszu­führen und bei Bedarf die Betriebssystemkonfiguration entspre­chend anzupassen. Nur so ist auch bei einer vorüber­ge­henden Störung im Clusterbetrieb, die zu einer Node Eviction führt, ein stabiler Clusterbetrieb ohne manuellen Eingriff sichergestellt.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email