Ultimamente mi sono imbattuto in una serie di domande sugli indirizzi IP virtuali (VIP) per Oracle RAC. Spero che questo post sul blog possa aiutare a far luce su cos'è un VIP, come funzionano e perché Oracle RAC li sfrutta. Prima di andare oltre, dovrei spiegare che non sono uno specialista di reti. In effetti, le reti di computer sono probabilmente il mio punto più debole di tutto ciò che accade nei negozi di informatica. Quindi non infiammarmi se non ottengo completamente le cose di rete, accurate al 100%. Lo spiegherò in termini che mi sono stati utili nella mia carriera di DBA, in particolare lavorando con Oracle RAC.
La maggior parte delle persone ha familiarità con la connessione di qualsiasi applicazione, SQL*Plus o altro, a un server di database a istanza singola. Alla fine, la loro richiesta di connessione viene inviata a un indirizzo IP specifico. Nel diagramma seguente, l'utente finale desidera connettersi a 192.168.1.1 per accedere al database. La richiesta di rete viene instradata allo switch di rete a cui è connesso il server di database. Questa opzione passa la richiesta al server che ha l'indirizzo IP richiesto.
La maggior parte dei DBA Oracle non ha problemi a comprendere questo concetto. La vita diventa un po' più complicata quando viene distribuito RAC poiché sono presenti più macchine (nodi) nel cluster. Nel diagramma successivo, abbiamo un cluster RAC a due nodi, ogni nodo ha un indirizzo IP diverso.
All'utente finale non interessa a quale nodo è connessa la sua sessione. L'utente finale vuole solo accedere al cluster. Entrambi i nodi saranno sufficienti. La configurazione di TNSNAMES.ORA dell'utente finale potrebbe dire di provare prima 192.168.1.1 e se non funziona, provare invece 192.168.1.2. In questo modo Oracle RAC fornisce una soluzione ad alta disponibilità.
Ora veniamo all'intero motivo per cui devono essere utilizzati gli indirizzi IP virtuali. Cosa succede se l'utente finale tenta di accedere al primo nodo (192.168.1.1) ma non è disponibile? Il nodo è inattivo per qualche motivo. L'utente finale può facilmente connettersi al nodo 192.168.1.2. Tuttavia, a causa del funzionamento delle reti TCP/IP, possono essere necessari fino a dieci minuti prima che la connessione di rete a 192.168.1.1 scada prima che si acceda a 192.168.1.2. La lunga attesa di timeout TCP/IP è l'unico motivo per cui Oracle RAC sfrutta i VIP. Vogliamo semplicemente ridurre il tempo per accedere a un altro nodo nel cluster nel caso in cui il nostro nodo richiesto non fosse disponibile.
Un IP tradizionale è solitamente associato alla scheda di rete sul server. L'amministratore IT configurerà il server in modo che utilizzi sempre quell'indirizzo IP specifico e nessun altro dispositivo sulla rete utilizzerà lo stesso IP. Nota:sto cercando di semplificare le cose qui ed evitare DHCP e la registrazione del leasing per coloro che hanno familiarità con gli argomenti.
Un indirizzo IP virtuale non è associato alla scheda di rete. Non è nemmeno definito nel sistema operativo. Il VIP non è un vero indirizzo IP simile al modo in cui una macchina virtuale non è un vero sistema. Sembra essere reale per coloro che lo usano. Quindi diamo un'occhiata al nostro cluster a due nodi, ma questa volta con i VIP definiti per loro.
I nostri server hanno ancora i loro indirizzi IP regolari, 192.168.1.1 e 192.168.1.2 rispettivamente per NODE1 e NODE2. Questi due nodi hanno anche VIP associati. NODE1-VIP e NODE2-VIP sono indicati rispettivamente come indirizzi IP 192.168.1.11 e 192.168.1.12. Ogni nodo nel cluster RAC ha il proprio indirizzo IP regolare e un VIP. Può anche essere utile sapere che il nome host e i nomi VIP sono spesso definiti in DNS in modo da non dover ricordare gli indirizzi IP in modo specifico.
Si noti che l'utente finale ora richiede di accedere a uno dei VIP. Le uniche persone che dovrebbero utilizzare questi indirizzi IP tradizionali sono gli amministratori IT che devono eseguire lavori sul server. Gli utenti finali e tutte le applicazioni devono connettersi al VIP.
Ricordi che ho detto prima che il VIP non è nemmeno definito nel sistema operativo? Bene, se è così, allora come fa tutto a sapere che il VIP è assegnato a quel nodo? Tutto questo è gestito da Grid Infrastructure (GI). Quando GI è installato, una delle schermate di Oracle Universal Installer (OUI) chiederà i nomi dei nodi nel cluster (i nomi host) insieme al nome host virtuale. La schermata seguente mostra l'aspetto dell'installazione di 11g GI quando si richiedono tali informazioni (schermata della documentazione Oracle).
Il nome host pubblico è configurato nel sistema operativo dall'amministratore. L'IP virtuale non è configurato nel sistema operativo ma l'infrastruttura di rete lo sa. Per capire come funziona, dobbiamo divagare un po' e comprendere l'Address Resolution Protocol (ARP).
Quando un server viene avviato e i suoi componenti di rete vengono avviati, Address Resolution Protocol è il meccanismo che indica allo switch davanti al server di instradare tutto il traffico per il suo indirizzo IP all'indirizzo MAC della sua scheda di rete. Il sistema operativo, tramite ARP, dice allo switch di passare a NODE1 per le richieste 192.168.1.1.
All'avvio di Grid Infrastructure, una delle sue attività di avvio è eseguire qualcosa di simile. GI, tramite ARP, dice allo switch di passare a NODE1 per tutte le richieste NODE1-VIP (192.168.1.11). Fino a quando GI non avvia il VIP, l'indirizzo VIP non è instradabile.
Ora ecco la parte magica... quando NODE1 si interrompe, GI su un altro nodo nel cluster rileverà l'interruzione. GI eseguirà quindi una nuova operazione ARP che informa lo switch di instradare il VIP a un altro nodo nel cluster. Poiché il VIP è virtuale, può essere reindirizzato al volo. Nel diagramma seguente, NODE1 non è riuscito. Anche il suo IP tradizionale non è più disponibile. GI ha re-ARPed il VIP al nodo rimanente nel cluster.
Il re-ARPing del VIP può essere realizzato in pochi secondi. L'utente finale potrebbe riscontrare una breve pausa nella comunicazione di rete tra l'applicazione e l'istanza del database, ma questo è molto, molto meno che se si attendessero i timeout TCP/IP.
Oracle 11gR2 ha introdotto gli SCAN Listener. Un cluster Oracle RAC può avere al massimo tre SCAN Listener. Il nome SCAN è ancora in DNS, ma il DNS eseguirà il round-robin della risoluzione del nome SCAN su uno dei tre diversi indirizzi IP.
Nel diagramma seguente, il nostro cluster a due nodi ha ora due listener SCAN. L'utente finale effettua una richiesta di connessione a my-scan.acme.com e il DNS risolve il nome in 192.168.1.21 o 192.168.1.22.
Come mostrato sopra, questi due SCAN VIP sono assegnati a nodi diversi nel cluster. Se NODE1 si interrompe, Grid Infrastructure trasferirà sia NODE1-VIP che MY-SCAN (192.168.1.21) a un nodo sopravvissuto nel cluster, attraverso la stessa operazione di re-ARP di cui abbiamo parlato in precedenza. I nuovi ascoltatori SCAN e i loro VIP vengono gestiti allo stesso modo dei VIP vecchio stile.
Per ricapitolare, gli indirizzi IP virtuali vengono utilizzati per fornire un failover più rapido delle comunicazioni di rete tra l'applicazione ei nodi nel cluster. Il sistema operativo utilizza il protocollo di risoluzione degli indirizzi per consentire allo switch di rete di instradare le connessioni all'host. Grid Infrastructure utilizza le stesse operazioni ARP per far sapere allo switch di rete dove indirizzare il traffico per il VIP e lo SCAN VIP. Se un nodo si interrompe, GI eseguirà nuovamente l'ARP VIP e SCAN VIP su un altro nodo nel cluster.
