Keine Verbindung zur Datenbank mit ODA KVM Network Bridge

Viele benutzen inzwischen Oracles KVM Lösung auf der ODA (Oracle Database Appliance). Robotron z.B. nutzt Linux VMs auf den ODA Lite Modellen für die eigenen Softwarelösungen, um Applikationsserver(-teile) auf den ODAs der Kunden laufen zu lassen (Oracle nennt diese Vorgehensweise "Solution-in-a-Box"). Aber es gibt natürlich auch andere Kunden, bei denen Robotron lediglich Systemintegrator ist, die aber ebenfalls KVM auf ihren ODAs nutzen möchten.

Es existiert ein Blog Post von Tammy (kvm-on-oda), den man als Basis nutzen kann, um KVM zu enablen und zu konfigurieren.

Die entsprechenden Blog-Teile sind einfach zu handeln, aber es gibt einen Punkt, der etwas kritisch ist. Es handelt sich dabei um die Netzwerk Konfiguration für KVM auf den ODAs. Die beste Lösung ist das Einrichten einer Netzwerk Bridge. Ruggero hat in einem Blog post der selbst Teil von Tammys blog ist, beschrieben, wie man die verschiedenen Netzwerktypen enabled/einrichtet.

NAT oder MacVTap sollte man nicht verwenden, deshalb ist der Bereich "Bridged networking (aka "shared physical device")" der richtige, um das Netzwerk einzurichten.

Wichtig ist, dass man während der (nachträglichen) Einrichtung des Netzwerkes Zugriff auf die "Host redirection" Funktion des ILOMS besitzt. Wenn die Konfiguration der Bridge misslingt, kann es ggfs. dazu kommen, dass man die Netzwerkverbindung zur ODA verliert (und man kann auch nicht wie an einer ODA HA einen internen connect durchführen).

Nachdem man die Konfiguration anhand des Blogs durchgeführt hat und sich wieder an der ODA über die konfigurierte Bridge mit ssh anmelden kann, wir man feststellen, dass man sich nicht mehr an die Datenbanken auf der ODA verbinden kann. Warum das so ist? Es fehlt im Beispiel von Ruggero leider ein kleiner aber wichtiger Schritt: Die Konfiguration der Clusterware als Grid Benutzer. Deutlich wird das, wenn man den Listener stoppt/startet - der Listener wird Fehler werfen und nicht mehr starten.

Was also ist noch zu tun? Die Clusterware Network Konfiguration muss angepasst werden. Dies ist mit wenigen Schritten möglich.

Der Listener gehört (im Normalfall) zum Netzwerk 1, das kann man herausfinden durch

$ srvctl config listener
Name: LISTENER
Type: Database Listener
Network: 1, Owner: grid
Home: <CRS home>
End points: TCP:1521
Listener is enabled.
Listener is individually enabled on nodes:
Listener is individually disabled on nodes:

Danach prüft man die Konfiguration:

$ srvctl config network
Network 1 exists
Subnet IPv4: 10.214.0.0/255.255.248.0/btbond1, static
Subnet IPv6:
Ping Targets:
Network is enabled
Network is individually enabled on nodes:
Network is individually disabled on nodes:

Wie man sieht, ist das Netzwerk noch gegen btbond1 konfiguriert und nicht, wie es sein sollte, gegen die neu erstellte Bridge pubbr0.

Deshalb muss noch folgendes ausgeführt werden (natürlich mit IP-Adresse/Subnet der ensprechenden ODA):

$ srvctl modify network -netnum 1 -subnet 10.214.0.0/255.255.248.0/pubbr0 

Nachdem der Befehlt ausgeführt wurde, sieht die Netzwerkkonfiguration so aus, dass die IPv4 Konfiguration von btbond1 nach pubbr0 geändert wurde.

$ srvctl config network
Network 1 exists
Subnet IPv4: 10.214.0.0/255.255.248.0/pubbr0, static
Subnet IPv6:
Ping Targets:
Network is enabled
Network is individually enabled on nodes:
Network is individually disabled on nodes:

Am Besten ist es nun die ODA zu restarten, um zu testen, das alles auch nach einem Restart richtig funktioniert (als Shortcut reicht auch nur den Listener zu restarten):

$ srvctl stop listener
$ srvctl start listener

Das war es - jetzt kann das Device wie vorgesehen als Bridge sowohl für die Datenbanken als auch für die KVM-Umgebung genutzt werden.