Jeg har været på tværs af en række spørgsmål om virtuelle IP-adresser (VIP) til Oracle RAC på det seneste. Jeg håber, at dette blogindlæg kan hjælpe med at kaste lidt lys over, hvad en VIP er, hvordan de fungerer, og hvorfor Oracle RAC udnytter dem. Før jeg går videre, bør jeg forklare, at jeg ikke er netværksspecialist. Faktisk er computernetværk nok mit svageste punkt af alt, hvad der foregår i it-butikker. Så lad være med at brænde mig, hvis jeg ikke får netværkstingene helt, 100% nøjagtige. Jeg vil forklare dette i termer, der har tjent mig godt i min DBA-karriere, især arbejdet med Oracle RAC.
De fleste mennesker er bekendt med at forbinde enhver applikation, SQL*Plus eller andre, til en enkelt-instans databaseserver. I sidste ende sendes deres forbindelsesanmodning til en bestemt IP-adresse. I vores diagram nedenfor ønsker slutbrugeren at oprette forbindelse til 192.168.1.1 for at få adgang til databasen. Netværksanmodningen bliver dirigeret til netværksswitchen, som databaseserveren er forbundet til. Denne switch sender anmodningen til den server, der har den anmodede IP-adresse.
De fleste Oracle DBA'er har ikke problemer med at forstå dette koncept. Livet bliver lidt mere kompliceret, når RAC er implementeret, da der er flere maskiner (noder) i klyngen. I det næste diagram har vi en RAC-klynge med to noder, hvor hver node har en forskellig IP-adresse.
Slutbrugeren er ligeglad med, hvilken node hans session er forbundet til. Slutbrugeren vil bare have adgang til klyngen. Begge noder vil være tilstrækkelige. Slutbrugerens TNSNAMES.ORA-konfiguration siger måske, at man skal prøve 192.168.1.1 først, og hvis det ikke virker, så prøv 192.168.1.2 i stedet. På denne måde leverer Oracle RAC en High Availability-løsning.
Nu kommer vi til hele årsagen til, at virtuelle IP-adresser skal bruges. Hvad hvis slutbrugeren forsøger at få adgang til den første node (192.168.1.1), men den er utilgængelig? Noden er nede af en eller anden grund. Slutbrugeren kunne nemt oprette forbindelse til 192.168.1.2 noden. Men på grund af den måde, TCP/IP-netværk fungerer på, kan det tage op til ti minutter for netværksforbindelsen til 192.168.1.1 at få timeout, før 192.168.1.2 bliver tilgået. Den lange ventetid på TCP/IP-timeout er den eneste grund til, at Oracle RAC udnytter VIP'er. Vi ønsker simpelthen at reducere tiden til at få adgang til en anden node i klyngen, hvis vores anmodede node ikke er tilgængelig.
En traditionel IP er normalt bundet til netværkskortet på serveren. IT-administratoren konfigurerer serveren til altid at bruge den specifikke IP-adresse, og ingen andre enheder på netværket vil bruge den samme IP. Bemærk:Jeg forsøger at gøre dette enkelt her og undgå DHCP og leasingregistrering for dem, der er bekendt med emnerne.
En virtuel IP-adresse er ikke bundet til netværkskortet. Det er ikke engang defineret i OS. VIP'en er ikke en rigtig IP-adresse, der ligner den måde, en virtuel maskine ikke er et rigtigt system. Det ser bare ud til at være rigtigt for dem, der bruger det. Så lad os se på vores to node-klynge, men denne gang med VIP'er defineret for dem.
Vores servere har stadig deres almindelige IP-adresser, 192.168.1.1 og 192.168.1.2 for henholdsvis NODE1 og NODE2. Disse to noder har også VIP'er tilknyttet. NODE1-VIP og NODE2-VIP er angivet som IP-adresser henholdsvis 192.168.1.11 og 192.168.1.12. Hver node i RAC-klyngen har sin almindelige IP-adresse og en VIP. Det kan også være en fordel at vide, at værtsnavnet og VIP-navnene ofte er defineret i DNS, så vi ikke skal huske IP-adresserne specifikt.
Bemærk, at slutbrugeren nu anmoder om at få adgang til en af VIP'erne. De eneste mennesker, der bør bruge disse traditionelle IP-adresser, er it-administratorer, der skal udføre arbejde på serveren. Slutbrugere og alle applikationer bør oprette forbindelse til VIP'en.
Husk, at jeg sagde tidligere, at VIP'en ikke engang er defineret i OS? Hvis det er tilfældet, hvordan ved alt så, at VIP'en er tildelt den node? Det hele håndteres af Grid Infrastructure (GI). Når GI er installeret, vil en af Oracle Universal Installer-skærmene (OUI) bede om navnene på noderne i klyngen (værtsnavnene) sammen med det virtuelle værtsnavn. Skærmbilledet nedenfor viser, hvordan 11g GI-installationen så ud, da man bad om disse oplysninger (skærmbillede fra Oracle-dokumentationen).
Det offentlige værtsnavn er konfigureret i OS af administratoren. Den virtuelle IP er ikke konfigureret i OS, men Grid Infrastructure kender til det. For at forstå, hvordan dette virker, er vi nødt til at gå lidt på opdagelse og forstå Address Resolution Protocol (ARP).
Når en server startes op, og dens netværkskomponenter initieres, er Address Resolution Protocol den mekanisme, der fortæller switchen foran serveren at dirigere al trafik til dens IP-adresse til MAC-adressen på dets netværkskort. OS, via ARP, fortæller switchen at gå til NODE1 for 192.168.1.1-anmodninger.
Når Grid Infrastructure starter, er en af dens opstartsopgaver at lave noget lignende. GI, via ARP, fortæller switchen at gå til NODE1 for alle NODE1-VIP (192.168.1.11) anmodninger. Indtil GI starter VIP'en kan denne VIP-adresse ikke omdirigeres.
Nu er her den magiske del...når NODE1 går ned, vil GI på en anden node i klyngen registrere udfaldet. GI vil derefter udføre en ny ARP-operation, der informerer switchen om at dirigere VIP'en til en anden node i klyngen. Fordi VIP'en er virtuel, kan den omdirigeres i farten. I diagrammet nedenfor har NODE1 fejlet. Dens traditionelle IP er ikke længere tilgængelig så godt. GI har gen-ARPet VIP'en til den resterende node i klyngen.
Gen-ARP'en af VIP'en kan udføres på få sekunder. Slutbrugeren kan opleve en kort pause i deres netværkskommunikation mellem applikationen og databaseinstansen, men det er meget, meget mindre, end hvis vi ventede på TCP/IP-timeouts.
Oracle 11gR2 introducerede SCAN Listeners. En Oracle RAC-klynge kan højst have tre SCAN-lyttere. SCAN-navnet er stadig i DNS, men DNS vil round-robine SCAN-navneopløsningen til en af op til tre forskellige IP-adresser.
I diagrammet nedenfor har vores to-node-klynge nu to SCAN-lyttere. Slutbrugeren foretager en forbindelsesanmodning til my-scan.acme.com, og DNS omsætter navnet til enten 192.168.1.21 eller 192.168.1.22.
Som det er vist ovenfor, er disse to SCAN VIP'er tildelt forskellige noder i klyngen. Hvis NODE1 går ned, vil Grid Infrastructure flytte både NODE1-VIP og MY-SCAN (192.168.1.21) til en overlevende node i klyngen gennem den samme re-ARP-operation, som vi talte om tidligere. De nyere SCAN-lyttere og deres VIP'er håndteres på samme måde som de gamle VIP'er.
For at opsummere, bruges virtuelle IP-adresser til at give hurtigere failover af netværkskommunikation mellem applikationen og noderne i klyngen. OS bruger Address Resolution Protocol til at lade netværksswitchen vide, hvordan forbindelserne skal dirigeres til værten. Grid Infrastructure brugere de samme ARP-operationer for at lade netværksswitchen vide, hvor trafikken skal dirigeres til VIP'en og SCAN VIP'en. Skulle en node gå ned, vil GI gen-ARP VIP og SCAN VIP til en anden node i klyngen.