Ich bin in letzter Zeit auf eine Reihe von Fragen zu virtuellen IP-Adressen (VIP) für Oracle RAC gestoßen. Ich hoffe, dass dieser Blogbeitrag dazu beitragen kann, etwas Licht ins Dunkel zu bringen, was ein VIP ist, wie er funktioniert und warum Oracle RAC ihn nutzt. Bevor ich weiter gehe, sollte ich erklären, dass ich kein Netzwerkspezialist bin. Tatsächlich ist die Computervernetzung wahrscheinlich mein schwächster Punkt bei allem, was in IT-Shops vor sich geht. Also flammen Sie mich nicht auf, wenn ich das Netzwerkzeug nicht vollständig und 100% genau verstehe. Ich werde dies in Begriffen erläutern, die mir in meiner DBA-Karriere gute Dienste geleistet haben, insbesondere bei der Arbeit mit Oracle RAC.
Die meisten Menschen sind damit vertraut, eine beliebige Anwendung, SQL*Plus oder andere, mit einem Einzelinstanz-Datenbankserver zu verbinden. Am Ende wird ihre Verbindungsanfrage an eine bestimmte IP-Adresse gesendet. In unserem Diagramm unten möchte der Endbenutzer eine Verbindung zu 192.168.1.1 herstellen, um auf die Datenbank zuzugreifen. Die Netzwerkanforderung wird an den Netzwerk-Switch weitergeleitet, mit dem dieser Datenbankserver verbunden ist. Dieser Schalter leitet die Anfrage an den Server weiter, der die angeforderte IP-Adresse hat.
Die meisten Oracle DBAs haben kein Problem damit, dieses Konzept zu verstehen. Das Leben wird etwas komplizierter, wenn RAC bereitgestellt wird, da es mehrere Maschinen (Knoten) im Cluster gibt. Im nächsten Diagramm haben wir einen RAC-Cluster mit zwei Knoten, wobei jeder Knoten eine andere IP-Adresse hat.
Dem Endbenutzer ist es egal, mit welchem Knoten seine Sitzung verbunden ist. Der Endbenutzer möchte nur Zugriff auf den Cluster. Jeder Knoten ist ausreichend. Die TNSNAMES.ORA-Konfiguration des Endbenutzers kann vorgeben, zuerst 192.168.1.1 zu versuchen, und wenn das nicht funktioniert, versuchen Sie stattdessen 192.168.1.2. Auf diese Weise stellt Oracle RAC eine Hochverfügbarkeitslösung bereit.
Jetzt kommen wir zum gesamten Grund für die Verwendung virtueller IP-Adressen. Was ist, wenn der Endbenutzer versucht, auf den ersten Knoten (192.168.1.1) zuzugreifen, dieser aber nicht verfügbar ist? Der Knoten ist aus irgendeinem Grund ausgefallen. Der Endbenutzer könnte sich problemlos mit dem 192.168.1.2-Knoten verbinden. Aufgrund der Funktionsweise von TCP/IP-Netzwerken kann es jedoch bis zu zehn Minuten dauern, bis die Netzwerkverbindung zu 192.168.1.1 abläuft, bevor auf 192.168.1.2 zugegriffen wird. Das lange Warten auf das TCP/IP-Timeout ist der einzige Grund für Oracle RAC, VIPs zu nutzen. Wir möchten einfach die Zeit für den Zugriff auf einen anderen Knoten im Cluster verkürzen, falls unser angeforderter Knoten nicht verfügbar sein sollte.
Eine traditionelle IP ist normalerweise an die Netzwerkkarte auf dem Server gebunden. Der IT-Administrator konfiguriert den Server so, dass er immer diese spezifische IP-Adresse verwendet und keine anderen Geräte im Netzwerk dieselbe IP verwenden. Hinweis:Ich versuche, dies hier einfach zu machen und die DHCP- und Lease-Registrierung für diejenigen zu vermeiden, die mit den Themen vertraut sind.
Eine virtuelle IP-Adresse ist nicht an die Netzwerkkarte gebunden. Es ist nicht einmal im Betriebssystem definiert. Die VIP ist keine echte IP-Adresse, ähnlich wie eine virtuelle Maschine kein echtes System ist. Es scheint nur für diejenigen, die es verwenden, real zu sein. Schauen wir uns also unseren Zwei-Knoten-Cluster an, aber dieses Mal mit dafür definierten VIPs.
Unsere Server haben immer noch ihre regulären IP-Adressen, 192.168.1.1 und 192.168.1.2 für NODE1 bzw. NODE2. Diesen beiden Knoten sind auch VIPs zugeordnet. NODE1-VIP und NODE2-VIP werden als IP-Adressen 192.168.1.11 bzw. 192.168.1.12 bezeichnet. Jeder Knoten im RAC-Cluster hat seine reguläre IP-Adresse und einen VIP. Es kann auch von Vorteil sein zu wissen, dass der Hostname und die VIP-Namen oft im DNS definiert sind, sodass wir uns die IP-Adressen nicht speziell merken müssen.
Beachten Sie, dass der Endbenutzer jetzt den Zugriff auf einen der VIPs anfordert. Die einzigen Personen, die diese herkömmlichen IP-Adressen verwenden sollten, sind IT-Administratoren, die Arbeiten auf dem Server ausführen müssen. Endbenutzer und alle Anwendungen sollten sich mit dem VIP verbinden.
Denken Sie daran, dass ich vorhin gesagt habe, dass die VIP nicht einmal im Betriebssystem definiert ist? Nun, wenn das der Fall ist, woher wissen dann alle, dass der VIP diesem Knoten zugewiesen ist? Dies alles wird von Grid Infrastructure (GI) gehandhabt. Wenn GI installiert ist, fragt einer der Oracle Universal Installer (OUI)-Bildschirme nach den Namen der Knoten im Cluster (die Hostnamen) zusammen mit dem virtuellen Hostnamen. Der folgende Screenshot zeigt, wie die 11g-GI-Installation aussah, als nach diesen Informationen gefragt wurde (Screenshot aus der Oracle-Dokumentation).
Der öffentliche Hostname wird vom Administrator im Betriebssystem konfiguriert. Die virtuelle IP ist nicht im Betriebssystem konfiguriert, aber Grid Infrastructure kennt sie. Um zu verstehen, wie das funktioniert, müssen wir ein wenig abschweifen und das Address Resolution Protocol (ARP) verstehen.
Wenn ein Server gestartet und seine Netzwerkkomponenten initiiert werden, ist das Address Resolution Protocol der Mechanismus, der den Switch vor dem Server anweist, den gesamten Datenverkehr für seine IP-Adresse an die MAC-Adresse seiner Netzwerkkarte zu leiten. Das Betriebssystem weist den Switch über ARP an, für 192.168.1.1-Anfragen zu NODE1 zu gehen.
Wenn Grid Infrastructure startet, besteht eine seiner Startaufgaben darin, etwas Ähnliches zu tun. GI weist den Switch über ARP an, für alle NODE1-VIP (192.168.1.11)-Anforderungen zu NODE1 zu gehen. Bis GI den VIP startet, ist diese VIP-Adresse nicht routbar.
Jetzt kommt der magische Teil … wenn NODE1 ausfällt, erkennt GI auf einem anderen Knoten im Cluster den Ausfall. GI führt dann eine neue ARP-Operation durch, die den Switch anweist, die VIP an einen anderen Knoten im Cluster zu leiten. Da das VIP virtuell ist, kann es spontan umgeleitet werden. Im Diagramm unten ist NODE1 ausgefallen. Seine traditionelle IP ist ebenfalls nicht mehr verfügbar. GI hat die VIP erneut auf den verbleibenden Knoten im Cluster umgeleitet.
Das Re-ARPing des VIP kann in Sekunden durchgeführt werden. Der Endbenutzer kann eine kurze Pause in seiner Netzwerkkommunikation zwischen der Anwendung und der Datenbankinstanz erleben, aber das ist viel, viel weniger, als wenn wir auf TCP/IP-Zeitüberschreitungen warten würden.
Oracle 11gR2 führte die SCAN-Listener ein. Ein Oracle RAC-Cluster kann höchstens drei SCAN-Listener haben. Der SCAN-Name befindet sich immer noch im DNS, aber DNS wird die SCAN-Namensauflösung auf eine von bis zu drei verschiedenen IP-Adressen verteilen.
Im Diagramm unten hat unser Zwei-Knoten-Cluster jetzt zwei SCAN-Listener. Der Endbenutzer stellt eine Verbindungsanfrage an my-scan.acme.com und DNS löst den Namen entweder in 192.168.1.21 oder 192.168.1.22 auf.
Wie oben gezeigt, werden diese beiden SCAN-VIPs unterschiedlichen Knoten im Cluster zugewiesen. Wenn NODE1 ausfällt, verschiebt Grid Infrastructure sowohl NODE1-VIP als auch MY-SCAN (192.168.1.21) auf einen überlebenden Knoten im Cluster, und zwar durch denselben Re-ARP-Vorgang, über den wir zuvor gesprochen haben. Die neueren SCAN-Listener und ihre VIPs werden genauso behandelt wie die alten VIPs.
Zur Erinnerung:Virtuelle IP-Adressen werden verwendet, um ein schnelleres Failover der Netzwerkkommunikation zwischen der Anwendung und den Knoten im Cluster bereitzustellen. Das Betriebssystem verwendet das Address Resolution Protocol, um den Netzwerk-Switch darüber zu informieren, dass er Verbindungen zum Host leiten soll. Die Grid-Infrastruktur verwendet dieselben ARP-Operationen, um dem Netzwerk-Switch mitzuteilen, wohin der Datenverkehr für das VIP und das SCAN-VIP geleitet werden soll. Sollte ein Knoten ausfallen, führt GI ein Re-ARP für den VIP durch und scannt den VIP auf einen anderen Knoten im Cluster.
