Ändern der IP-Adressen in einem RAC Cluster unter Oracle 11g Release 2 (11.2.0.3)

Auftrund meines Umzugs ins neue Büro waren einige Konfigurationsänderungen meiner Infrastruktur notwendig. Klar, dass die Linux- und Windows Systeme sehr schnell angepasst waren, auch die virtuellen Maschinen machten keine Probleme. Etwas schwieriger gestaltete sich jedoch die Umstellung meines RAC-Clusters, denn mit der Änderung der Einträge in der /etc/hosts ist es nicht getan, da ist weit mehr notwendig.

Um Ihnen langwierige und schmerzvolle Erfahrungen zu ersparen, habe ich in diesem Artikel die wichtigen Punkte für eine erfolgreiche Umstellung aufgeführt. Eine hervorragende Unterstützung habe ich dabei in dem Artikel http://zhefeng.wordpress.com/2009/02/02/change-ip-address-for-oracle-rac-public-and-vip-interfaces gefunden.

Ausgangsbasis ist meine Datenbank RACVM1 auf dem Cluster gallier mit den Knoten asterix und obelix (siehe Blog „Oracle RAC 11.2.0.3 auf VMware ESXi„).

Die hosts-Datei sieht ursprünglich wie folgt aus:

# SCAN
192.168.151.60 gallier.carajandb.com gallier
# Public
192.168.151.61 asterix.carajandb.com asterix
192.168.151.62 obelix.carajandb.com obelix
# VIP
192.168.151.71 asterix-vip.carajandb.com asterix-vip
192.168.151.72 obelix-vip.carajandb.com obelix-vip
# Interconnect
31.10.151.61   asterix-priv.carajandb.com asterix-priv
31.10.151.62   obelix-priv.carajandb.com obelix-priv

Es sollen nur die Public IP-Adresse von 192.168.151.x auf 192.168.152.x geändert werden. Die Private Adressen für den Interconnect bleiben zunächst erhalten.

Anwendungen stoppen

Bevor wir mit der Umstellung anfangen, sollte zunächst die Datenbank heruntergefahren werden. Beim Betrieb von RAC-Datenbanken sollten Sie darauf achten, hierfür nicht den SQL*Plus zu verwenden sondern ausschließlich den Befehl srvctl (auch wenn er nicht gerade sprechend ist).

$ srvctl stop database -d RACVM1

Als nächstes werden alle weiteren Anwendungen (inklusive der VIP-Adressen) auf den Knoten gestoppt.

$ srvctl stop nodeapps -n asterix 
$ srvctl stop nodeapps -n obelix

Damit sollten alle Anwendungen bis auf ASM und Listener gestoppt sein. Überprüft werden kann das mit:

$ crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora.DATA.dg    ora....up.type ONLINE    ONLINE    asterix
ora....ER.lsnr ora....er.type ONLINE    OFFLINE
ora....N1.lsnr ora....er.type OFFLINE   OFFLINE
ora.asm        ora.asm.type   ONLINE    ONLINE    asterix
ora....SM1.asm application    ONLINE    ONLINE    asterix
ora....IX.lsnr application    ONLINE    OFFLINE
ora....rix.gsd application    OFFLINE   OFFLINE
ora....rix.ons application    OFFLINE   OFFLINE
ora....rix.vip ora....t1.type OFFLINE   OFFLINE
ora.cvu        ora.cvu.type   OFFLINE   OFFLINE
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE
ora....network ora....rk.type OFFLINE   OFFLINE
ora....SM2.asm application    ONLINE    ONLINE    obelix
ora....IX.lsnr application    ONLINE    OFFLINE
ora.obelix.gsd application    OFFLINE   OFFLINE
ora.obelix.ons application    OFFLINE   OFFLINE
ora.obelix.vip ora....t1.type OFFLINE   OFFLINE
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    asterix
ora.ons        ora.ons.type   OFFLINE   OFFLINE
ora.racvm1.db  ora....se.type OFFLINE   OFFLINE
ora....rod.svc ora....ce.type OFFLINE   OFFLINE
ora....est.svc ora....ce.type OFFLINE   OFFLINE
ora....st1.svc ora....ce.type OFFLINE   OFFLINE
ora....st2.svc ora....ce.type OFFLINE   OFFLINE
ora....ry.acfs ora....fs.type ONLINE    ONLINE    asterix
ora.scan1.vip  ora....ip.type OFFLINE   OFFLINE

Wer ganz sicher gehen will, sollte jetzt ein Backup der OCR und Voting Disk machen. Da an meiner Testdatenbank noch nicht viel kaputt zu machen war, habe ich darauf verzichtet.

Adressen in der Oracle Konfiguration ändern

Als nächstes sollte man sich die derzeitige Konfiguration der Adapter ansehen (den Befehl vipca gibt es in 11.2 nicht mehr, da ja mit der SCAN-Adresse gearbeitet wird. Merkwürdigerweise existiert im $ORACLE_HOME/bin aber noch die Datei vipca, sie ist allerdings leer).

$ oifcfg getif
eth1  31.10.151.0  global  cluster_interconnect
eth0  192.168.151.0  global  public

Wie bereits erwähnt sollen die Public IP-Adressen (also asterix, obelix, asterix-vip und obelix-vip) geändert werden. Auch wenn es mich hier einige Überwindung gekostet hat, es funktioniert tatsächlich, zunächst den Eintrag für eth0 zu löschen und dann wieder neu anzulegen:

$ oifcfg delif -global eth0
$ oifcfg setif -global eth0/192.168.152.0:public

Jetzt müssen noch die VIP-Adressen geändert werden. Natürlich erst nach einer entsprechenden Überprüfung:

$ srvctl config nodeapps -a
Network exists: 1/192.168.151.0/255.255.255.0/eth0, type static
VIP exists: /192.168.151.71/192.168.151.71/192.168.151.0/255.255.255.0/eth0, hosting node asterix
VIP exists: /192.168.151.72/192.168.151.72/192.168.151.0/255.255.255.0/eth0, hosting node obelix

… und jetzt die Änderung:

# srvctl modify nodeapps -n asterix -A 192.168.152.0/255.255.255.0/eth0
# srvctl modify nodeapps -n obelix -A 192.168.152.0/255.255.255.0/eth0

… und natürlich die Überprüfung:

# srvctl config nodeapps -a
Network exists: 1/192.168.152.0/255.255.255.0/eth0, type static
VIP exists: /192.168.152.71/192.168.152.71/192.168.152.0/255.255.255.0/eth0, hosting node asterix
VIP exists: /192.168.152.72/192.168.152.72/192.168.152.0/255.255.255.0/eth0, hosting node obelix

Änderung der Betriebssystem-Konfiguration

Jetzt können die /etc/hosts Dateien entsprechend modifiziert werden, so dass sie anschließend so aussehen:

# SCAN
192.168.152.60 gallier.carajandb.com gallier
# Public
192.168.152.61 asterix.carajandb.com asterix
192.168.152.62 obelix.carajandb.com obelix
# VIP
192.168.152.71 asterix-vip.carajandb.com asterix-vip
192.168.152.72 obelix-vip.carajandb.com obelix-vip
# Interconnect
31.10.151.61   asterix-priv.carajandb.com asterix-priv
31.10.151.62   obelix-priv.carajandb.com obelix-priv

Die letzte Änderung betrifft dann die Linux Netzwerk-Einstellungen. Ob Sie hierfür das Tool Network Connections benutzen oder die Einträge in /etc/sysconfig/network-scripts manuell editieren, bleibt Ihnen überpassen.

Als Beispiel der Eintrag in ifcfg-eth0 für asterix:

TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.152.61
PREFIX=24
GATEWAY=192.168.152.1
DNS1=192.168.152.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME=eth0
UUID=d04279f7-dd5a-40fa-ace8-d50fd62f50d7
ONBOOT=yes
HWADDR=00:0C:29:67:66:D5

Beim manuellen Anpassen müssen Sie außerdem noch das Default Gateway in /etc/sysconfig/network ändern.

Ein guter Tipp in dem Artikel war auch, für die ssh-Verbindungen zwischen den Systemen die Datei known_hosts entsprechend anzupassen.

Restart mit neuer Konfiguration

Jetzt kann, wenn Sie die Änderungen am Netzwerk manuell durchgeführt haben, das Netzwerk auf beiden Systemen einmal durchgestartet werden.

# service network restart

Last but not least wird dann der crs-Daemon auf beiden Knoten gestoppt und anschließend wieder gestartet.

# crsctl stop crs 
# crsctl start crs

Zum Abschluss würde ich empfehlen, bei Maschinen einmal durchzustarten um zu verifizieren, dass die Ressourcen nach einem Reboot auch wieder gestartet werden. Da Sie die Datenbank gestoppt haben dürfen Sie zum Abschluss auch diese wieder starten – aber bitte mit dem Befehl srvctl!

$ srvctl start database -d RACVM1

Ansonsten wünsche ich viel Erfolg bei der Umstellung und über Kommentare würde ich mich freuen.