News zu Oracle

Oracle Clus­ter­wa­re mo­di­fi­ziert Re­boot­ver­hal­ten ab Version 19.13

Diverse Er­eig­nis­se im Cluster (u.a. Ausfall des In­ter­con­nects, Crash des ocssd-Prozesses) führen zu einer Node Eviction, die wiederum mit einem Reboot der be­trof­fe­nen Server ein­her­ge­hen kann. Wenn der Reboot die Ursache der Eviction behebt, gliedern sich die Server an­schlie­ßend wieder selb­stän­dig in den Cluster ein. Dazu müssen seit Patch­le­vel 19.13 weitere Vor­keh­run­gen im Be­triebs­sys­tem getroffen werden.

Freeze vs. Reboot

Mit Patch­le­vel 19.13.0.0.211019 (Release Update 10/2021) haben wir fest­ge­stellt, dass ein be­trof­fe­ner Node einfriert statt zu rebooten. Die Folge davon wäre, dass sich die be­trof­fe­nen Server nicht wieder selb­stän­dig in den Cluster in­te­grie­ren, sondern per Remote Ma­nage­ment Interface oder vor Ort im Ser­ver­raum 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 con­fi­gu­red, the system will appear hung and will not reboot because default “kernel.panic” parameter is set to 0.

Daraus folgt, dass ein Clus­ter­ser­ver ab Patch­le­vel 19.13 mit aktivem kdump laufen und/oder den Ker­nel­pa­ra­me­ter kernel.panic=1 gesetzt haben muss.

Folgender shell-Befehl muss min­des­tens für eine der Kom­po­nen­ten „kdump“ oder „kernel.panic“ mit „ist aktiv“ antworten. Dann ist auch mit Patch­le­vel 19.13 oder höher ein korrektes Re­boot­ver­hal­ten 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 be­trof­fe­nen 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 be­trof­fe­nen 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 Re­boot­ver­hal­ten auch mit Grid In­fra­struc­tu­re 19.13 und höher si­cher­zu­stel­len, ist es dringend empfohlen, den erwähnten Test aus­zu­füh­ren und bei Bedarf die Be­triebs­sys­tem­kon­fi­gu­ra­ti­on ent­spre­chend an­zu­pas­sen. Nur so ist auch bei einer vor­über­ge­hen­den Störung im Clus­ter­be­trieb, die zu einer Node Eviction führt, ein stabiler Clus­ter­be­trieb ohne manuellen Eingriff sichergestellt.

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

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email