V poslední době jsem se setkal s řadou otázek týkajících se virtuálních IP (VIP) adres pro Oracle RAC. Doufám, že tento příspěvek na blogu může pomoci osvětlit, co jsou VIP, jak fungují a proč je Oracle RAC využívá. Než půjdu dále, měl bych vysvětlit, že nejsem síťový specialista. Počítačové sítě jsou vlastně asi moje nejslabší stránka ze všeho, co se v IT obchodech děje. Takže mě neurážejte, pokud nedostanu všechny síťové věci úplně, 100% přesné. Vysvětlím to termíny, které mi dobře posloužily v mé kariéře DBA, zejména při práci s Oracle RAC.
Většina lidí zná připojení libovolné aplikace, SQL*Plus nebo jiné, k jednoinstančnímu databázovému serveru. Nakonec je jejich žádost o připojení odeslána na konkrétní IP adresu. V našem diagramu níže se koncový uživatel chce připojit k 192.168.1.1 pro přístup k databázi. Síťový požadavek je směrován do síťového přepínače, ke kterému je tento databázový server připojen. Tento přepínač předá požadavek serveru, který má požadovanou IP adresu.
Většina Oracle DBA nemá problém pochopit tento koncept. Život se trochu zkomplikuje, když je nasazen RAC, protože v clusteru je více strojů (uzlů). V dalším diagramu máme dvouuzlový cluster RAC, přičemž každý uzel má jinou IP adresu.
Koncovému uživateli je jedno, ke kterému uzlu je jeho relace připojena. Koncový uživatel chce pouze přístup ke clusteru. Každý uzel bude stačit. V konfiguraci TNSNAMES.ORA koncového uživatele může být uvedeno, že je třeba nejprve zkusit 192.168.1.1, a pokud to nefunguje, zkuste místo toho 192.168.1.2. Tímto způsobem Oracle RAC poskytuje řešení s vysokou dostupností.
Nyní se dostáváme k celému důvodu pro použití virtuálních IP adres. Co když se koncový uživatel pokouší o přístup k prvnímu uzlu (192.168.1.1), ale ten je nedostupný? Uzel je z nějakého důvodu mimo provoz. Koncový uživatel se mohl snadno připojit k uzlu 192.168.1.2. Vzhledem k tomu, jak sítě TCP/IP fungují, může trvat až deset minut, než síťové připojení k 192.168.1.1 vyprší, než bude přístup k 192.168.1.2. Dlouhé čekání na časový limit TCP/IP je jediným důvodem, proč Oracle RAC využívá VIP. Chceme jednoduše zkrátit čas pro přístup k jinému uzlu v clusteru, pokud by náš požadovaný uzel nebyl dostupný.
Tradiční IP adresa je obvykle vázána na síťovou kartu na serveru. Správce IT nakonfiguruje server tak, aby vždy používal tuto konkrétní IP adresu a žádná jiná zařízení v síti nepoužívala stejnou IP. Poznámka:Snažím se to zde zjednodušit a vyhnout se DHCP a registraci pronájmu pro ty, kteří jsou obeznámeni s tématy.
Virtuální IP adresa není vázána na síťovou kartu. Není to ani definováno v OS. VIP není skutečná IP adresa, podobně jako virtuální stroj není skutečný systém. Jen se zdá být skutečný pro ty, kteří jej používají. Podívejme se tedy na náš shluk dvou uzlů, ale tentokrát s pro ně definovanými VIP.
Naše servery mají stále své běžné IP adresy, 192.168.1.1 a 192.168.1.2 pro NODE1 a NODE2. Tyto dva uzly mají také spojené VIP. NODE1-VIP a NODE2-VIP jsou označeny jako IP adresy 192.168.1.11 a 192.168.1.12. Každý uzel v clusteru RAC má svou běžnou IP adresu a VIP. Může být také užitečné vědět, že název hostitele a jména VIP jsou často definována v DNS, takže si nemusíme konkrétně pamatovat IP adresy.
Všimněte si, že koncový uživatel nyní požaduje přístup k jedné z VIP. Jediní lidé, kteří by měli používat tyto tradiční IP adresy, jsou správci IT, kteří potřebují pracovat na serveru. Koncoví uživatelé a všechny aplikace by se měly připojit k VIP.
Pamatujete si, že jsem dříve řekl, že VIP není ani definován v OS? Pokud je to tak, jak pak všechno ví, že VIP je přiřazen k tomuto uzlu? To vše zajišťuje Grid Infrastructure (GI). Po instalaci GI se na jedné z obrazovek Oracle Universal Installer (OUI) zeptá na názvy uzlů v clusteru (názvy hostitelů) spolu s názvem virtuálního hostitele. Snímek obrazovky níže ukazuje, jak vypadala instalace 11g GI, když jste požadovali tyto informace (snímek obrazovky z dokumentace Oracle).
Veřejný název hostitele nastavuje v OS správce. Virtuální IP adresa není nakonfigurována v OS, ale infrastruktura Grid o ní ví. Abychom pochopili, jak to funguje, musíme trochu odbočit a porozumět protokolu ARP (Address Resolution Protocol).
Když je server spuštěn a jeho síťové komponenty jsou iniciovány, Address Resolution Protocol je mechanismus, který říká přepínači před serverem, aby směroval veškerý provoz pro jeho IP adresu na MAC adresu jeho síťové karty. OS prostřednictvím ARP říká přepínači, aby přešel na NODE1 pro požadavky 192.168.1.1.
Když se Grid Infrastructure spustí, jedním z jejích spouštěcích úkolů je udělat něco podobného. GI prostřednictvím ARP říká přepínači, aby přešel na NODE1 pro všechny požadavky NODE1-VIP (192.168.1.11). Dokud GI nespustí VIP, není tato VIP adresa směrovatelná.
Teď je tu ta kouzelná část...když NODE1 selže, GI na jiném uzlu v clusteru zaznamená výpadek. GI poté provede novou operaci ARP, která informuje přepínač, aby nasměroval VIP do jiného uzlu v clusteru. Vzhledem k tomu, že VIP je virtuální, lze jej přesměrovat za běhu. V níže uvedeném diagramu došlo k selhání NODE1. Jeho tradiční IP již také není k dispozici. GI znovu ARP převedl VIP na zbývající uzel v clusteru.
Re-ARPing VIP lze provést během několika sekund. Koncový uživatel může zaznamenat krátkou pauzu v síťové komunikaci mezi aplikací a instancí databáze, ale to je mnohem, mnohem méně, než kdybychom čekali na vypršení časového limitu TCP/IP.
Oracle 11gR2 představil SCAN Listeners. Cluster Oracle RAC může mít maximálně tři SCAN Listenery. Název SCAN je stále v DNS, ale DNS bude opakovat překlad názvu SCAN na jednu z až tří různých IP adres.
V níže uvedeném diagramu má náš dvouuzlový cluster nyní dva posluchače SCAN. Koncový uživatel zadá požadavek na připojení na my-scan.acme.com a DNS přeloží název buď na 192.168.1.21 nebo 192.168.1.22.
Jak je ukázáno výše, tyto dva SCAN VIP jsou přiřazeny k různým uzlům v clusteru. Pokud dojde k výpadku NODE1, infrastruktura Grid přemístí NODE1-VIP i MY-SCAN (192.168.1.21) do přežívajícího uzlu v clusteru prostřednictvím stejné operace re-ARP, o které jsme hovořili dříve. S novějšími posluchači SCAN a jejich VIP se zachází stejně jako se starými VIP.
Abychom to shrnuli, virtuální IP adresy se používají k zajištění rychlejšího převzetí služeb při selhání síťové komunikace mezi aplikací a uzly v clusteru. Operační systém používá protokol Address Resolution Protocol, aby informoval síťový přepínač, aby směroval připojení k hostiteli. Uživatelé Grid Infrastructure používají stejné operace ARP, aby síťový přepínač věděl, kam má směrovat provoz pro VIP a SCAN VIP. Pokud některý uzel selže, GI znovu ARP VIP a SKENUJE VIP na jiný uzel v clusteru.