Jag har stött på ett antal frågor om virtuella IP-adresser (VIP) för Oracle RAC på sistone. Jag hoppas att det här blogginlägget kan bidra till att kasta lite ljus över vad en VIP är, hur de fungerar och varför Oracle RAC utnyttjar dem. Innan jag går vidare bör jag förklara att jag inte är en nätverksspecialist. Faktum är att datornätverk förmodligen är min svagaste punkt av allt som händer i IT-butiker. Så flamma mig inte om jag inte förstår nätverksgrejen helt, 100% korrekt. Jag kommer att förklara detta i termer som har tjänat mig väl under min DBA-karriär, särskilt när jag arbetar med Oracle RAC.
De flesta är bekanta med att ansluta vilken applikation som helst, SQL*Plus eller andra, till en databasserver med en enda instans. I slutändan skickas deras anslutningsbegäran till en specifik IP-adress. I vårt diagram nedan vill slutanvändaren ansluta till 192.168.1.1 för att komma åt databasen. Nätverksbegäran dirigeras till nätverksswitchen som den databasservern är ansluten till. Denna switch skickar begäran till servern som har den begärda IP-adressen.
De flesta Oracle DBA:er har inga problem med att förstå detta koncept. Livet blir lite mer komplicerat när RAC distribueras eftersom det finns flera maskiner (noder) i klustret. I nästa diagram har vi ett RAC-kluster med två noder, där varje nod har sin egen IP-adress.
Slutanvändaren bryr sig inte om vilken nod hans session är ansluten till. Slutanvändaren vill bara ha tillgång till klustret. Endera noden kommer att räcka. Slutanvändarens TNSNAMES.ORA-konfiguration kan säga att man ska prova 192.168.1.1 först och om det inte fungerar, prova 192.168.1.2 istället. På detta sätt tillhandahåller Oracle RAC en lösning med hög tillgänglighet.
Nu kommer vi till hela anledningen till att virtuella IP-adresser ska användas. Vad händer om slutanvändaren försöker komma åt den första noden (192.168.1.1) men den är otillgänglig? Noden är nere av någon anledning. Slutanvändaren kan enkelt ansluta till noden 192.168.1.2. Men på grund av hur TCP/IP-nätverk fungerar kan det ta upp till tio minuter för nätverksanslutningen till 192.168.1.1 att ta en timeout innan 192.168.1.2 kommer att nås. Den långa väntan på TCP/IP-timeout är den enda anledningen för Oracle RAC att utnyttja VIP:er. Vi vill helt enkelt minska tiden för att komma åt en annan nod i klustret om vår begärda nod skulle vara otillgänglig.
En traditionell IP är vanligtvis bunden till nätverkskortet på servern. IT-administratören kommer att konfigurera servern att alltid använda den specifika IP-adressen och inga andra enheter i nätverket kommer att använda samma IP. Obs:Jag försöker göra detta enkelt här och undvika DHCP och leasingregistrering för de som är bekanta med ämnena.
En virtuell IP-adress är inte bunden till nätverkskortet. Det är inte ens definierat i operativsystemet. VIP är inte en riktig IP-adress som liknar hur en virtuell maskin inte är ett riktigt system. Det verkar bara vara verkligt för dem som använder det. Så låt oss titta på vårt två nodkluster, men den här gången med VIP-definierade för dem.
Våra servrar har fortfarande sina vanliga IP-adresser, 192.168.1.1 och 192.168.1.2 för NODE1 respektive NODE2. Dessa två noder har även VIP:s kopplade till sig. NODE1-VIP och NODE2-VIP betecknas som IP-adresser 192.168.1.11 respektive 192.168.1.12. Varje nod i RAC-klustret har sin vanliga IP-adress och en VIP. Det kan också vara fördelaktigt att veta att värdnamnet och VIP-namnen ofta definieras i DNS så att vi inte behöver komma ihåg IP-adresserna specifikt.
Lägg märke till att slutanvändaren nu begär att få tillgång till en av VIP:erna. De enda som borde använda dessa traditionella IP-adresser är IT-administratörer som behöver utföra arbete på servern. Slutanvändare och alla applikationer bör ansluta till VIP.
Kom ihåg att jag sa tidigare att VIP inte ens definieras i operativsystemet? Om så är fallet, hur vet då allt att VIP är tilldelad den noden? Allt detta hanteras av Grid Infrastructure (GI). När GI är installerat kommer en av Oracle Universal Installer-skärmarna (OUI) att fråga efter namnen på noderna i klustret (värdnamnen) tillsammans med det virtuella värdnamnet. Skärmdumpen nedan visar hur 11g GI-installationen såg ut när man bad om den informationen (skärmdump från Oracle-dokumentationen).
Det offentliga värdnamnet konfigureras i operativsystemet av administratören. Den virtuella IP-adressen är inte konfigurerad i operativsystemet men Grid Infrastructure känner till det. För att förstå hur detta fungerar måste vi avvika lite och förstå Address Resolution Protocol (ARP).
När en server startas och dess nätverkskomponenter initieras, är Address Resolution Protocol mekanismen som säger åt switchen framför servern att dirigera all trafik för dess IP-adress till MAC-adressen på dess nätverkskort. OS, genom ARP, säger åt switchen att gå till NODE1 för 192.168.1.1-förfrågningar.
När Grid Infrastructure startar är en av dess startuppgifter att göra något liknande. GI, genom ARP, säger åt switchen att gå till NODE1 för alla NODE1-VIP (192.168.1.11) förfrågningar. Tills GI startar VIP-adressen går inte den att dirigera.
Nu här är den magiska delen ... när NODE1 går ner kommer GI på en annan nod i klustret att upptäcka avbrottet. GI kommer sedan att utföra en ny ARP-operation som informerar switchen att dirigera VIP:n till en annan nod i klustret. Eftersom VIP-en är virtuell kan den dirigeras om i farten. I diagrammet nedan har NODE1 misslyckats. Dess traditionella IP är inte längre tillgänglig också. GI har ARP om VIP till den återstående noden i klustret.
Åter-ARP av VIP kan utföras på några sekunder. Slutanvändaren kan uppleva en kort paus i sin nätverkskommunikation mellan applikationen och databasinstansen, men det är mycket, mycket mindre än om vi väntade på TCP/IP-timeout.
Oracle 11gR2 introducerade SCAN Listeners. Ett Oracle RAC-kluster kan ha högst tre SCAN Listeners. SCAN-namnet finns fortfarande i DNS men DNS kommer att runda SCAN-namnupplösningen till en av upp till tre olika IP-adresser.
I diagrammet nedan har vårt tvånodskluster nu två SCAN-lyssnare. Slutanvändaren gör en anslutningsbegäran till my-scan.acme.com och DNS löser namnet till antingen 192.168.1.21 eller 192.168.1.22.
Som visas ovan tilldelas dessa två SCAN VIP till olika noder i klustret. Om NODE1 går ner kommer Grid Infrastructure att flytta både NODE1-VIP och MY-SCAN (192.168.1.21) till en överlevande nod i klustret, genom samma re-ARP-operation som vi pratade om tidigare. De nyare SCAN-lyssnarna och deras VIP:er hanteras på samma sätt som de gamla VIP:erna.
För att sammanfatta, används virtuella IP-adresser för att ge snabbare failover av nätverkskommunikation mellan applikationen och noderna i klustret. OS använder Address Resolution Protocol för att låta nätverksväxeln veta att den ska dirigera anslutningar till värden. Grid Infrastructure-användare samma ARP-operationer för att låta nätverksväxeln veta var den ska dirigera trafik för VIP och SCAN VIP. Om en nod skulle gå ner kommer GI att ARP igen VIP och SCAN VIP till en annan nod i klustret.