Das Vorgehen beim Rolling OS Upgrades

Da während des Upgrades weiterhin Hochverfügbarkeit gewährleistet werden sollte, ist es empfehlenswert bei einem 2 Knoten Cluster temporär einen zusätzlichen Knoten hinzuzufügen, da ansonsten während des Upgrade nur noch ein Knoten verfügbar wäre. Als Beispiel dient hier ein Oracle RAC Cluster 11.2.0.3.2 auf Basis Oracle Linux 5.8 mit dem Ziel Oracle Linux 6.5 mit dem RHEL Kernel und ASMLib. Ein mögliches Vorgehen, wie ein solches Betriebssystem Upgrade von OL5 auf OL6 vorgenommen werden kann, gliedert sich in folgende einzelne Schritte.

Optional: Patchen des Clusters

Bevor das Betriebssystem Upgrade in Angriff genommen wird, sollte geprüft werden, ob die Voraussetzungen der Oracle Software für das neue OS auch gegeben sind. Ein wichtiger Bestandteil ist hier z.B. die Verwendung von ASMLIB und ASM Cluster Filesystem, weil beide Funktionen kernelabhängige Treiber beinhalten. Für ASMLIB muss lediglich die entsprechende Software vorher auf den OL6 Rechner installiert werden und die Funktion geprüft werden. Der Zugriff auf den gesharten Storage sollte selbstverständlich vorhanden sein, da dies die Voraussetzung dafü ist, einen neuen Knoten zum Cluster hinzuzufügen. Auch hier ist der temporäre Knoten von Vorteil, da solche Tatsachen unabhängig vom produktiven Cluster bereits festgestellt werden können.

Im Falle von ACFS gestaltet sich dies aber anders, da ACFS erst mit neueren Patchleveln Oracle Linux 6 unterstützt. Die Informationen findet man in MOS Note 1369107.1 "ACFS Support On OS Platforms (Certification Matrix)." Daher sollte in diesem Fall der Cluster erst auf den aktuellen PSU (11.2.0.3.9) gepatched werden.

In unserem Testfall wurde dies auf den bestehenden Knoten, inklusive Datenbank mit einem "oaptch auto" als Root durchgeführt, wie im Readme des PSUs beschrieben. Auch dies kann selbstverständlich Rolling passieren und sollte unabhängig vom eigentlichen OS Upgrade betrachtet und durchgeführt werden.

[root@orac-s1 11_2_0_3_9]# $ORACLE_HOME/OPatch/opatch auto /stage/11_2_0_3_9 -ocmrf /stage/rsp/ocm.rsp

Hinzufügen des Temporären Knoten

Entfernen von Knoten 1 aus dem Cluster

Man entfernt einen alten Knoten aus dem Cluster (um diesen mit dem neuen Betriebssystem neu zu installieren), in fast umgekehrter Reihenfolge

• Services und Instance Management
• "Löschen" der DB Software
• Löschen der Grid Infrastruktur

$ srvctl relocate service -d bazi -s s_bazi -i bazi1 -t bazi3 (-f)
$ srvctl modify service -d bazi -s s_bazi -a "bazi2" -i "bazi3" -n

[oracle@orac-s3 bin]$ cd $ORACLE_HOME/oui/bin
[oracle@orac-s3 bin]$ ./runInstaller -updateNodeList 
ORACLE_HOME=/opt/oracle/oracle_base/product/11.2.0.3 "CLUSTER_NODES={orac-s2, orac-s3}"
Starting Oracle Universal Installer...
...
'UpdateNodeList' was successful.

[root@orac-s1 ~]# olsnodes -s -t
orac-s1 Active  Unpinned
orac-s2 Active  Unpinned
orac-s3 Active  Unpinned

[root@orac-s1 ~]# cd $ORACLE_HOME/crs/install
[root@orac-s1 install]# ./rootcrs.pl -deconfig -force
Using configuration parameter file: ./crsconfig_params

Successfully deconfigured Oracle clusterware stack on this node

[root@orac-s3 ~]# olsnodes -t -s
orac-s1 Inactive  Unpinned
orac-s2 Active    Unpinned
orac-s3 Active    Unpinned

[root@orac-s3 11.2.0.3]# crsctl delete node -n orac-s1
CRS-4661: Node orac-s1 successfully deleted.

[root@orac-s3 11.2.0.3]#  olsnodes -t -s
orac-s2 Active  Unpinned
orac-s3 Active  Unpinned

[oracle@orac-s3 bin]$ ./runInstaller -updateNodeList ORACLE_HOME=/opt/grid/11.2.0.3 
"CLUSTER_NODES={orac-s2, orac-s3}" CRS=TRUE -silent
Starting Oracle Universal Installer...
..
'UpdateNodeList' was successful.

Hinzufügen von Knoten 1 zum Cluster

Nun kann der Knoten neu mit Oracle Linux 6 installiert werden. Sobald der Knoten mit dem alten Hostnamen unter OL6 zur Verfügung steht, kann der Knoten dem Cluster wieder beitreten. Dabei ist wichtig, dass diesmal die Erweiterung (also die Befehle "addnode") vom neuen temporären Knoten (orac-s3) durchgeführt werden, da man hierduch die Relink Schritte überspringen kann. Damit besteht das Hinzufügen des neuen Clusterknotens (neben der Vorbereitung von ASMLIB und preinstall Paket) nur noch aus folgenden Schritten:

• SSH Setup
• Addnode GI HOME
• Addnode DB Home
• Instanz und Services erweitern

[oracle@orac-s3]$ $ORACLE_HOME/oui/prov/resources/scripts/sshUserSetup.sh -user oracle 
-hosts "orac-s1 orac-s2 orac-s3" -advanced -noPromptPassphrase

[oracle@orac-s3]$ cluvfy stage -pre nodeadd -n orac-s1

[oracle@orac-s3]$ cd $ORACLE_HOME/oui/bin
[oracle@orac-s3]$ export IGNORE_PREADDNODE_CHECKS=Y
[oracle@orac-s3]$ ./addNode.sh "CLUSTER_NEW_NODES={orac-s1}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={oracv-s1}"


[root@orac-s1]# /opt/oracle/oraInventory/orainstRoot.sh
[root@orac-s1]# /opt/grid/11.2.0.3/root.sh

[root@orac-s1]# srvctl start filesystem -d /dev/asm/acfs-80
[root@orac-s1]# crsctl stat res -t

[oracle@oracl-s3]$ $ ./addNode.sh -silent "CLUSTER_NEW_NODES={orac-s1}"

[root@orac-s1]# /opt/oracle/oracle_base/product/11.2.0.3/root.sh

[oracle@oracl-s3]$ dbca
[oracle@oracl-s3]$ srvctl modify service -d bazi -s s_bazi -a "bazi3" -i "bazi1" -n
[oracle@oracl-s3]$ srvctl relocate service -d bazi -s s_bazi -i bazi3 -t bazi1

Entfernen und Hinzufügen von Knoten 2

Das gleiche Vorgehen wie bei Knoten 1 nun auch für Knoten 2: Erst entfernen und dann neu hinzufügen. Danach sind alle Knoten auf OL6, und der temporäre Knoten kann nun entfernt werden.

Fazit

Letztendlich sind alle Bestandteile, die für ein Rolling OS Upgrade benötigt werden, in der Dokumentation enthalten. Allerdings macht sich eine gründliche Vorbereitung bezahlt, insbesondere bestimmte Vorarbeiten, wie das Prüfen auf falsche Berechtigungen oder das Prüfen auf neue benötigte Versionen. Hierbei kann insbesondere auch die Hinzunahme eines temporären Knotens hilfreich sein, da dadurch viele Dinge in Erscheinung treten, bevor sie Auswirkung auf die Produktion oder das laufende Cluster haben.

Nützliche Links und Referenzen