Mehr als ein Public Netzwerk mit der 11.2 Grid Infrastruktur

Mehr als ein Public Subnetz mit der 11gR2 Grid Infrastruktur

von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG

Früher besaßen Server nur eine Netzwerkkarte und waren somit nur über ein Subnetz erreichbar. Mit steigenden Anforderungen stieg die Anzahl der Netzwerkkarten und somit auch die Subnetze, über welche die Datenbanken erreichbar sind. Mittlerweile gehört die Erreichbarkeit von Datenbankservern über mehrere unterschiedliche Netze zur Standardausstattung in vielen Rechenzentren.

Viele Unternehmen nutzen dies, um ein gewisses Maß an Sicherheit zu gewährleisten. So haben Rechenzentren, neben dem eigentlichen "Public" Netz für die normalen Datenbankbenutzer, weitere Subnetze definiert: Häufig findet man eigene Adminstrationsnetze, über die die Server- und Datenbank-Administratoren auf die Server zugreifen. Zusätzlich versucht man hierüber auch den Zugriff auf die Datenbank zu steuern, indem man z.B. Netze für das Intranet und das Extranet bereitstellt oder bestimmte Ladeoperationen, die Data Guard Kommunikation oder ähnliches über eigene Netze abwickelt. Ein Beispiel aus der Praxis wäre z.B. der Zugriff auf ein Exadata System, bei dem bestimmte Server über Infiniband auf die Datenbankknoten zugreifen, anstatt über das Standard "Ethernet" Public Netz.

Ist dies bei Single Instanz Datenbanken recht einfach zu bewerkstelligen, indem pro Subnetz ein eigener Listener definiert wird, der die Clients vom jeweils entsprechenden Netz entgegennimmt, so gibt es im RAC bzw. Grid Infrastruktur Umfeld doch noch einiges mehr zu beachten, wie z.B. die Existenz der SCAN Listener oder die korrekte Weiterleitung (auch Routen genannt) der Verbindungsanfragen von Public Netz auf ein anderes Netzwerk-Segment. Beispielsweise ist es nicht wünschenswert, dass eine initiale Verbindung über das Infiniband Netzwerk plötzlich auf einem langsameren Public Netz landet oder im Extremfall überhaupt keine Verbindung zur Datenbank stattfinden kann.

Folgender Tipp gibt eine Anleitung wie die Funktion - korrektes Routing in der 11gR2 Grid Infrastruktur - konfiguriert werden kann.

Anmerkung: Bilder zum Tipp werden sichtbar, indem man mit der Maus über das Brillen Icon fährt.

Um das Bild wieder zu verkleinern, auf das Bild klicken.

Einzelschritte für das erfolgreiche Einrichten weiterer Subnetze

Grundlage: Richtige Installation

Anlegen eigener virtueller IP Adressen (VIPs) auf dem neuen Subnetz
Anlegen der Listener für die neuen VIPs
Vorbereitung der TNSNAMES.ORA auf den Servern für die Datenbank Parametrisierung
Listener Parameter der Datenbank für die richtige Lastverteiltung
Services für das "neue" Subnetz
TNSNAMES.ORA auf den Clients

Grundlage: Richtige Installation

Was ist denn bei der Installation zu berücksichtigen, wenn der Rechner mehrere Subnetze enthält?

Die eigentliche Installation unterscheidet sich nicht von einer Installation mit nur 2 Subnetzen (Public Netz und Interconnect Netzwerk): Der SCAN Name sollte auf dem offiziellen Public Netz (im DNS Server) definiert sein, genau wie die Public Hostnamen der Rechner. Alle weiteren verwendeten Netze sollten erst nach der Installation der Grid Infrastruktur bzw. der Datenbank Installation hinzugefügt werden. Deswegen setzt man die weiteren Netze bei der Installation einfach auf "Do Not Use", wie im Screenshot gezeigt.

Nach der Installation werden dann die weiteren Netzwerke definiert.

Anlegen eigener virtueller IP Adressen (VIPs) auf dem neuen Subnetz

Zur Verbindung mit einem Cluster sollten sogenannte virtuelle IP Adressen verwendet werden, da diese auf dem Cluster immer erreichbar sind und somit die Problematik eines TCP/IP Timeouts umgehen. Diese VIPs sind nun natürlich noch nicht auf den weiteren Netzwerken definiert und sollten dort angelegt werden. 1 VIP pro Clusterknoten wird unter dem Benutzer root angelegt:

# srvctl add vip -n bumucsvm1 -k 2 -A 192.168.245.11/255.255.255.0/eth2
# srvctl add vip -n bumucsvm2 -k 2 -A 192.168.245.12/255.255.255.0/eth2
# srvctl add vip -n bumucsvm3 -k 2 -A 192.168.245.13/255.255.255.0/eth2
# srvctl start vip -i 192.168.245.11
# srvctl start vip -i 192.168.245.12
# srvctl start vip -i 192.168.245.13

Sind die VIPs mit Namen bekannt (zum Beispiel durch Auflösung in der /etc/hosts), können auch diese Namen verwendet werden. Das erhöht zusätzlich die Übersichtlichkeit:

# srvctl add vip -n sccloud021 -k 2 -A sccloud01net2vip/255.255.255.0/eth2
# srvctl add vip -n sccloud025 -k 2 -A sccloud02net2vip/255.255.255.0/eth2

crsctl stat res -t -w "TYPE co _vip_net2"
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.sccloud01net2vip.vip
      1        OFFLINE OFFLINE
ora.sccloud02net2vip.vip
      1        OFFLINE OFFLINE

# srvctl start vip -i sccloud01net2vip
# srvctl start vip -i sccloud02net2vip

Wichtig ist hierbei die Option -k, da diese angibt, um welches Netz es sich handelt. Das Public Netzwerk der Installation hat automatisch die Nummer 1. Dies ist auch an der ora.net1.network Cluster Resource erkennbar. Die weiteren Nummern können beliebig festgelegt werden, es emfpiehlt sich aber eine fortlaufende Nummer zu verwenden.

Bei der Erstellung der VIP wird automatisch auch die Netzwerk Resource in der Clusterware erzeugt. Ein separater Befehl ist hierfür nicht notwendig. Dies ist auch dem Befehl crsctl sichtbar:

$ crsctl stat res -t -w "(TYPE co cluster_vip) OR (TYPE = ora.network.type)"
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.net1.network
               ONLINE  ONLINE       bumucsvm1
               ONLINE  ONLINE       bumucsvm2
               ONLINE  ONLINE       bumucsvm3
ora.net2.network
               ONLINE  ONLINE       bumucsvm1
               ONLINE  ONLINE       bumucsvm2
               ONLINE  ONLINE       bumucsvm3
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.192_168_245_11.vip
      1        ONLINE  ONLINE       bumucsvm1
ora.192_168_245_12.vip
      1        ONLINE  ONLINE       bumucsvm2
ora.192_168_245_13.vip
      1        ONLINE  ONLINE       bumucsvm3
ora.bumucsvm1.vip
      1        ONLINE  ONLINE       bumucsvm1
ora.bumucsvm2.vip
      1        ONLINE  ONLINE       bumucsvm2
ora.bumucsvm3.vip
      1        ONLINE  ONLINE       bumucsvm3

Generell ist es auch möglich, VIPs auf dem Interconnect anzulegen. Dies kann zum Beispiel für Exadata sinnvoll sein, wenn ein Ladejob die Daten über Infiniband laden soll.

Anlegen der Listener für die neuen VIPs

Damit die Clients sich über die neuen VIPs verbinden können, ist ein Listener notwendig. Dieser kann mit dem Befehl srvctl angelegt werden oder einfacher über den NETCA. Es empfiehlt sich, den Listener in der Grid Infrastruktur und nicht im Datenbank Home zu konfigurieren. Der Listener muss hierbei auf einen anderen Port als die bereits existierenden Listener hören.

Anlegen der Listener mit dem NETCA

Oracle Net Services Configuration:
Oracle Net Configuration Assistant is launched from Grid Infrastructure home. 
Network configuration will be clusterwide.
Configuring Listener:LISTENER_NET2
bumucsvm1...
bumucsvm2...
bumucsvm3...
Listener configuration complete.
Oracle Net Listener Startup:
    Listener started successfully.
Oracle Net Services configuration successful. The exit code is 0

Alternativ ist das auch über die Kommandozeile möglich:

$ srvctl add listener -l listener_net2 -p 1522 -k 2
$ srvctl start listener -l listener_net2

Vorbereitung der TNSNAMES.ORA auf den Servern für die Datenbank Parametrisierung

Da die Verbindung zu einer RAC Datenbank immer über Services passiert, muss gewährleistet sein, dass diese sich dynamisch am Listener anmelden. Ganz nebenbei übermittelt der PMON nicht nur die verfügbaren Datenbank Services, sondern auch Informationen über die Auslastung des Servers für das Server seitige Loadbalancing. Damit nun diese Informationen nicht nur beim Default Listener ankommen, sondern auch bei den neu angelegten, werden die entsprechenden Datenbank Parameter angepasst. Dies geschieht ähnlich wie früher bei den Einstellungen für die REMOTE_LISTENER und LOCAL_LISTENER Parameter. Da aber die Eingabe der kompletten Connect Informationen sehr fehlerbehaftet ist und diese bei Policy Managed Datenbanken nicht fix sind, ist es empfohlen, diese Informationen zuerst in die TNSNAMES.ORA auf den Servern (im Datenbank Home) zu schreiben und in der Datenbank nur den Aliasnamen zu verwenden:

$ vi $ORACLE_HOME/network/admin/tnsnames.ora

listener_net2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.1X)(PORT = 1522))
  )

remotelist_net2 =
  (DESCRIPTION_LIST =
    (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.11)(PORT = 1522)))
    (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.12)(PORT = 1522)))
    (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.13)(PORT = 1522)))
  )

local_listener =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.165.244.XXX)(PORT = 1521))
  )

Die Aliasnamen für die lokalen Listener enthalten dabei jeweils die entsprechenden VIP Adresse des Knotens.

Listener Parameter der Datenbank für die richtige Lastverteiltung

Nun werden die Einstellungen in der TNSNAMES.ORA in den LISTENER_NETWORKS Parameter der Datenbank übernommen.

$ sqlplus sys/oracle@bumucsvm1-scan:1521/buvmrac as sysdba
SQL> ALTER SYSTEM SET LISTENER_NETWORKS =
  2  '((NAME=network1)(LOCAL_LISTENER=local_listener)(REMOTE_LISTENER=sccloud01-scan.de.oracle.com:1521))',
  3  '((NAME=network2)(LOCAL_LISTENER=listener_net2)(REMOTE_LISTENER=remotelist_net2))';

SQL> ALTER SYSTEM REGISTER;

REMOTE_LISTENER und LOCAL_LISTENER belässt man auf den Standardwerten, da diese Informationen von der Clusterware auch direkt geändert werden können (falls sich zum Beispiel der SCAN Name ändert).

Die Aufgabe des LISTENER_NETWORKS Parameters besteht einerseits darin, dass PMON die Services und Last Informationen weiteren Listenern mitteilt. Andererseits wird durch die Auflistung der einzelnen Netzwerke verhindert, dass es zu einer Cross-Registrierung kommt: Eine Verbindung über die neuen Listener wird nicht auf das Subnetz des "Public Netzwerk" Listeners weitergeleitet.

Der verwendete Name hat hierbei keinen direkten Bezug, sondern dient allein zur Unterscheidung.

Anmerkung: In der aktuellen Version (11.2.0.2) gibt es nur einen SCAN Listener pro Cluster. Deswegen kann die Notation mit dem SCAN Listener nur beim Public Netzwerk verwendet werden. In allen anderen Fällen müssen die einzelnen VIPs der Knoten in der TNSNAMES.ORA aufgelistet sein.

Services für das "neue" Subnetz

Werden nun Services für die Datenbank angelegt, wird eine Abhängigkeit auf ein Netz angegeben. Dies hat aber keine Auswirkungen darauf, bei welchen Listenern der Service registriert wird. Es dient vielmehr nur dazu, dass der Service gestartet wird, wenn auch das entsprechende Subnetz bzw. die entsprechende ora.netX.network Resource vorhanden und gestartet ist.

srvctl add service -s orcl_net2 -d buvmrac -k 2 -r "buvmrac1,buvmrac2,buvmrac3"
srvctl start service -s orcl_net2 -d buvmrac

Wie über lsnrctl status zu sehen ist, ist der orcl_net2 Service trotzdem bei jedem Listener registriert:

$ lsnrctl status listener
...
Service "orcl_net2" has 1 instance(s).
  Instance "buvmrac1", status READY, has 2 handler(s) for this service...

$ lsnrctl status listener_scan1
...
Service "orcl_net2" has 2 instance(s).
  Instance "buvmrac1", status READY, has 2 handler(s) for this service...
  Instance "buvmrac2", status READY, has 2 handler(s) for this service...
  Instance "buvmrac3", status READY, has 2 handler(s) for this service...

$ lsnrctl status listener_net2
Service "orcl_net2" has 2 instance(s).
  Instance "buvmrac1", status READY, has 2 handler(s) for this service...
  Instance "buvmrac2", status READY, has 1 handler(s) for this service...
  Instance "buvmrac3", status READY, has 1 handler(s) for this service...

TNSNAMES.ORA auf den Clients

Während die TNSNAMES.ORA auf den Clients im Public Netz dank SCAN ziemlich einfach aussieht, müssen die Clients auf den anderen Netzen, auf denen der SCAN nicht existiert, noch auf die alte Funktionalität der Serverliste zugreifen.

TNSNAMES.ORA für SCAN

ORCL_NET2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = sccloud01-scan.de.oracle.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_net2)
    )
  )

Alternative für SCAN für ältere Clients

ORCL_NET2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.165.244.242)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.165.244.243)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.165.244.244)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_net2)
    )
  )

TNSNAMES.ORA auf den anderen Netzen

ORCL_NET2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.11)(PORT = 1522))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.12)(PORT = 1522))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.245.13)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_net2)
    )
  )

Zurück zur Übersicht

Zurück zur Community-Seite