Ik ben de laatste tijd een aantal vragen tegengekomen over Virtual IP (VIP)-adressen voor Oracle RAC. Ik hoop dat deze blogpost enig licht kan werpen op wat een VIP is, hoe ze werken en waarom Oracle RAC er gebruik van maakt. Voordat ik verder ga, moet ik uitleggen dat ik geen netwerkspecialist ben. In feite is computernetwerken waarschijnlijk mijn zwakste punt van alles wat er in IT-winkels gebeurt. Dus maak me geen zorgen als ik de netwerkdingen niet helemaal begrijp, 100% nauwkeurig. Ik zal dit uitleggen in termen die me goed van pas zijn gekomen in mijn DBA-carrière, vooral door te werken met Oracle RAC.
De meeste mensen zijn bekend met het verbinden van een applicatie, SQL*Plus of andere, met een single-instance databaseserver. Uiteindelijk wordt hun verbindingsverzoek naar een specifiek IP-adres gestuurd. In ons onderstaande diagram wil de eindgebruiker verbinding maken met 192.168.1.1 om toegang te krijgen tot de database. Het netwerkverzoek wordt doorgestuurd naar de netwerkswitch waarmee die databaseserver is verbonden. Deze schakelaar geeft het verzoek door aan de server die het gevraagde IP-adres heeft.
De meeste Oracle DBA's hebben er geen probleem mee om dit concept te begrijpen. Het leven wordt een beetje ingewikkelder wanneer RAC wordt geïmplementeerd, omdat er meerdere machines (knooppunten) in het cluster zijn. In het volgende diagram hebben we een RAC-cluster met twee knooppunten, waarbij elk knooppunt een ander IP-adres heeft.
Het maakt de eindgebruiker niet uit op welke node zijn sessie is aangesloten. De eindgebruiker wil alleen toegang tot het cluster. Elk knooppunt is voldoende. De TNSNAMES.ORA-configuratie van de eindgebruiker kan zeggen dat je eerst 192.168.1.1 moet proberen en als dat niet werkt, probeer dan 192.168.1.2. Op deze manier biedt Oracle RAC een High Availability-oplossing.
Nu komen we bij de hele reden voor het gebruik van virtuele IP-adressen. Wat als de eindgebruiker toegang probeert te krijgen tot het eerste knooppunt (192.168.1.1) maar niet beschikbaar is? Het knooppunt is om de een of andere reden niet beschikbaar. De eindgebruiker kan eenvoudig verbinding maken met het 192.168.1.2-knooppunt. Vanwege de manier waarop TCP/IP-netwerken werken, kan het echter tot tien minuten duren voordat de netwerkverbinding met 192.168.1.1 een time-out heeft voordat toegang tot 192.168.1.2 wordt verkregen. De lange wachttijd voor TCP/IP-time-out is de enige reden voor Oracle RAC om gebruik te maken van VIP's. We willen gewoon de tijd verkorten om toegang te krijgen tot een ander knooppunt in het cluster als ons gevraagde knooppunt niet beschikbaar is.
Een traditioneel IP-adres is meestal gebonden aan de netwerkkaart op de server. De IT-beheerder zal de server configureren om altijd dat specifieke IP-adres te gebruiken en geen enkel ander apparaat in het netwerk zal hetzelfde IP-adres gebruiken. Opmerking:ik probeer dit hier eenvoudig te maken en DHCP- en leaseregistratie te vermijden voor degenen die bekend zijn met de onderwerpen.
Een virtueel IP-adres is niet gebonden aan de netwerkkaart. Het is niet eens gedefinieerd in het besturingssysteem. De VIP is geen echt IP-adres, vergelijkbaar met de manier waarop een virtuele machine geen echt systeem is. Het lijkt gewoon echt voor degenen die het gebruiken. Laten we dus eens kijken naar ons cluster met twee knooppunten, maar deze keer met VIP's die voor hen zijn gedefinieerd.
Onze servers hebben nog steeds hun normale IP-adressen, respectievelijk 192.168.1.1 en 192.168.1.2 voor NODE1 en NODE2. Aan deze twee knooppunten zijn ook VIP's gekoppeld. NODE1-VIP en NODE2-VIP worden respectievelijk aangeduid als IP-adressen 192.168.1.11 en 192.168.1.12. Elk knooppunt in het RAC-cluster heeft zijn normale IP-adres en een VIP. Het kan ook handig zijn om te weten dat de hostnaam en de VIP-namen vaak worden gedefinieerd in DNS, zodat we de IP-adressen niet specifiek hoeven te onthouden.
Merk op dat de eindgebruiker nu vraagt om toegang tot een van de VIP's. De enige mensen die deze traditionele IP-adressen zouden moeten gebruiken, zijn IT-beheerders die werkzaamheden op de server moeten uitvoeren. Eindgebruikers en alle applicaties moeten verbinding maken met de VIP.
Weet je nog dat ik eerder zei dat de VIP niet eens is gedefinieerd in het besturingssysteem? Als dat het geval is, hoe weet dan alles dat de VIP aan dat knooppunt is toegewezen? Dit wordt allemaal afgehandeld door Grid Infrastructure (GI). Wanneer GI is geïnstalleerd, vraagt een van de Oracle Universal Installer (OUI)-schermen om de namen van de knooppunten in het cluster (de hostnamen) samen met de virtuele hostnaam. De onderstaande schermafbeelding laat zien hoe de 11g GI-installatie eruitzag toen om die informatie werd gevraagd (schermafbeelding uit Oracle-documentatie).
De openbare hostnaam wordt door de beheerder in het besturingssysteem geconfigureerd. Het virtuele IP-adres is niet geconfigureerd in het besturingssysteem, maar Grid Infrastructure is hiervan op de hoogte. Om te begrijpen hoe dit werkt, moeten we een beetje afdwalen en het Address Resolution Protocol (ARP) begrijpen.
Wanneer een server wordt opgestart en de netwerkcomponenten worden gestart, is het Address Resolution Protocol het mechanisme dat de switch voor de server vertelt om al het verkeer voor zijn IP-adres naar het MAC-adres van zijn netwerkkaart te leiden. Het besturingssysteem vertelt via ARP de switch om naar NODE1 te gaan voor 192.168.1.1-verzoeken.
Wanneer Grid Infrastructure start, is een van de opstarttaken om iets soortgelijks te doen. GI vertelt via ARP de switch om naar NODE1 te gaan voor alle NODE1-VIP (192.168.1.11) verzoeken. Totdat GI de VIP start, kan dat VIP-adres niet worden gerouteerd.
Nu is hier het magische deel ... wanneer NODE1 uitvalt, zal GI op een ander knooppunt in het cluster de storing detecteren. GI voert dan een nieuwe ARP-bewerking uit die de switch informeert om de VIP naar een ander knooppunt in het cluster te routeren. Omdat de VIP virtueel is, kan deze on-the-fly worden omgeleid. In het onderstaande diagram is NODE1 mislukt. Het traditionele IP-adres is ook niet langer beschikbaar. GI heeft de VIP opnieuw ARP naar het resterende knooppunt in het cluster gestuurd.
De re-ARPing van de VIP kan in seconden worden bereikt. De eindgebruiker kan een korte pauze ervaren in de netwerkcommunicatie tussen de applicatie en de database-instantie, maar dit is veel, veel minder dan wanneer we zouden wachten op TCP/IP-time-outs.
Oracle 11gR2 introduceerde de SCAN Luisteraars. Een Oracle RAC-cluster kan maximaal drie SCAN-listeners hebben. De SCAN-naam staat nog steeds in DNS, maar DNS zal de resolutie van de SCAN-naam afronden naar een van maximaal drie verschillende IP-adressen.
In het onderstaande diagram heeft ons cluster met twee knooppunten nu twee SCAN-listeners. De eindgebruiker doet een verbindingsverzoek aan my-scan.acme.com en DNS zet de naam om in 192.168.1.21 of 192.168.1.22.
Zoals hierboven wordt weergegeven, worden die twee SCAN-VIP's toegewezen aan verschillende knooppunten in het cluster. Als NODE1 uitvalt, verplaatst Grid Infrastructure zowel NODE1-VIP als MY-SCAN (192.168.1.21) naar een overlevend knooppunt in het cluster, via dezelfde re-ARP-bewerking waar we het eerder over hadden. De nieuwere SCAN-luisteraars en hun VIP's worden op dezelfde manier behandeld als de oude VIP's.
Om samen te vatten:virtuele IP-adressen worden gebruikt om een snellere failover van netwerkcommunicatie tussen de toepassing en de knooppunten in het cluster te bieden. Het besturingssysteem gebruikt het Address Resolution Protocol om de netwerkswitch te laten weten om verbindingen naar de host te routeren. Grid Infrastructure gebruikt dezelfde ARP-bewerkingen om de netwerkswitch te laten weten waar het verkeer voor de VIP en de SCAN VIP moet worden gerouteerd. Als een node uitvalt, zal GI de VIP opnieuw ARPen en VIP SCANNEN naar een andere node in de cluster.