Ostatnio natknąłem się na wiele pytań dotyczących wirtualnych adresów IP (VIP) dla Oracle RAC. Mam nadzieję, że ten wpis na blogu pomoże rzucić nieco światła na to, czym jest VIP, jak działa i dlaczego Oracle RAC je wykorzystuje. Zanim przejdę dalej, powinienem wyjaśnić, że nie jestem specjalistą od sieci. W rzeczywistości sieci komputerowe to chyba mój najsłabszy punkt wszystkiego, co dzieje się w sklepach IT. Więc nie rzucaj mi się, jeśli nie zrozumiem całkowicie rzeczy związanych z siecią, w 100% dokładny. Wyjaśnię to w kategoriach, które dobrze mi służyły w mojej karierze DBA, zwłaszcza w pracy z Oracle RAC.
Większość ludzi jest zaznajomiona z łączeniem dowolnej aplikacji, SQL*Plus lub innej, z serwerem bazy danych o pojedynczej instancji. Na koniec ich żądanie połączenia jest wysyłane na określony adres IP. Na poniższym diagramie użytkownik końcowy chce połączyć się z 192.168.1.1, aby uzyskać dostęp do bazy danych. Żądanie sieciowe jest kierowane do przełącznika sieciowego, z którym połączony jest serwer bazy danych. Ten przełącznik przekazuje żądanie do serwera, który ma żądany adres IP.
Większość administratorów baz danych Oracle nie ma problemu ze zrozumieniem tej koncepcji. Życie staje się nieco bardziej skomplikowane po wdrożeniu RAC, ponieważ w klastrze jest wiele maszyn (węzłów). Na następnym diagramie mamy dwuwęzłowy klaster RAC, każdy węzeł ma inny adres IP.
Użytkownik końcowy nie dba o to, z którym węzłem jest połączona jego sesja. Użytkownik końcowy po prostu chce uzyskać dostęp do klastra. Wystarczy jeden węzeł. Konfiguracja TNSNAMES.ORA użytkownika końcowego może wymagać najpierw wypróbowania 192.168.1.1, a jeśli to nie zadziała, spróbuj zamiast tego 192.168.1.2. W ten sposób Oracle RAC zapewnia rozwiązanie o wysokiej dostępności.
Teraz dochodzimy do całego powodu używania wirtualnych adresów IP. Co się stanie, jeśli użytkownik końcowy próbuje uzyskać dostęp do pierwszego węzła (192.168.1.1), ale jest on niedostępny? Węzeł jest z jakiegoś powodu wyłączony. Użytkownik końcowy mógł łatwo połączyć się z węzłem 192.168.1.2. Jednak ze względu na sposób działania sieci TCP/IP może minąć nawet dziesięć minut, zanim połączenie sieciowe z adresem 192.168.1.1 przekroczy limit czasu przed uzyskaniem dostępu do 192.168.1.2. Długie oczekiwanie na limit czasu TCP/IP jest jedynym powodem, dla którego Oracle RAC wykorzystuje adresy VIP. Chcemy po prostu skrócić czas dostępu do innego węzła w klastrze, jeśli żądany węzeł będzie niedostępny.
Tradycyjny adres IP jest zwykle powiązany z kartą sieciową na serwerze. Administrator IT skonfiguruje serwer tak, aby zawsze używał tego konkretnego adresu IP i żadne inne urządzenia w sieci nie będą używać tego samego adresu IP. Uwaga:staram się to uprościć i unikać rejestracji DHCP i dzierżawy dla tych, którzy są zaznajomieni z tematami.
Wirtualny adres IP nie jest powiązany z kartą sieciową. Nie jest nawet zdefiniowany w systemie operacyjnym. VIP nie jest prawdziwym adresem IP, podobnie jak maszyna wirtualna nie jest prawdziwym systemem. Po prostu wydaje się, że jest prawdziwy dla tych, którzy go używają. Spójrzmy więc na nasz klaster z dwoma węzłami, ale tym razem ze zdefiniowanymi dla nich VIP-ami.
Nasze serwery nadal mają swoje zwykłe adresy IP, 192.168.1.1 i 192.168.1.2 odpowiednio dla NODE1 i NODE2. Te dwa węzły mają również powiązane z nimi adresy VIP. NODE1-VIP i NODE2-VIP są oznaczone odpowiednio jako adresy IP 192.168.1.11 i 192.168.1.12. Każdy węzeł w klastrze RAC ma swój zwykły adres IP i VIP. Warto również wiedzieć, że nazwa hosta i nazwy VIP są często zdefiniowane w systemie DNS, dzięki czemu nie musimy specjalnie zapamiętywać adresów IP.
Zauważ, że użytkownik końcowy prosi teraz o dostęp do jednego z VIP-ów. Jedynymi osobami, które powinny używać tych tradycyjnych adresów IP, są administratorzy IT, którzy muszą wykonywać pracę na serwerze. Użytkownicy końcowi i wszelkie aplikacje powinni łączyć się z VIP-em.
Pamiętasz, jak powiedziałem wcześniej, że VIP nie jest nawet zdefiniowany w systemie operacyjnym? Cóż, jeśli tak jest, to skąd wszystko wie, że VIP jest przypisany do tego węzła? Wszystko to jest obsługiwane przez Grid Infrastructure (GI). Po zainstalowaniu GI jeden z ekranów Oracle Universal Installer (OUI) poprosi o nazwy węzłów w klastrze (nazwy hostów) wraz z nazwą hosta wirtualnego. Poniższy zrzut ekranu pokazuje, jak wyglądała instalacja GI 11g, gdy prosiliśmy o te informacje (zrzut ekranu z dokumentacji Oracle).
Publiczna nazwa hosta jest konfigurowana w systemie operacyjnym przez administratora. Wirtualny adres IP nie jest skonfigurowany w systemie operacyjnym, ale infrastruktura Grid o tym wie. Aby zrozumieć, jak to działa, musimy nieco odejść i zrozumieć protokół rozpoznawania adresów (ARP).
Kiedy serwer jest uruchamiany i jego składniki sieciowe są inicjowane, protokół rozpoznawania adresów jest mechanizmem, który mówi przełącznikowi przed serwerem, aby przekierował cały ruch dla swojego adresu IP na adres MAC karty sieciowej. System operacyjny za pośrednictwem ARP nakazuje przełącznikowi przejście do NODE1 w przypadku żądań 192.168.1.1.
Po uruchomieniu infrastruktury sieciowej jednym z zadań startowych jest zrobienie czegoś podobnego. GI, za pośrednictwem ARP, mówi przełącznikowi, aby przeszedł do NODE1 dla wszystkich żądań NODE1-VIP (192.168.1.11). Dopóki GI nie uruchomi VIP-a, którego adres VIP nie może zostać przekierowany.
A teraz magiczna część… kiedy NODE1 ulegnie awarii, GI na innym węźle w klastrze wykryje awarię. Następnie GI wykona nową operację ARP, która poinformuje przełącznik o skierowaniu VIP do innego węzła w klastrze. Ponieważ VIP jest wirtualny, można go zmienić w locie. Na poniższym schemacie NODE1 nie powiodło się. Jego tradycyjny adres IP również nie jest już dostępny. GI ponownie przesłał adres VIP do pozostałego węzła w klastrze.
Ponowne ARP VIP można wykonać w kilka sekund. Użytkownik końcowy może doświadczyć krótkiej przerwy w komunikacji sieciowej między aplikacją a instancją bazy danych, ale jest to znacznie, znacznie mniej, niż gdybyśmy czekali na przekroczenie limitu czasu TCP/IP.
Oracle 11gR2 wprowadził odbiorniki SCAN. Klaster Oracle RAC może mieć maksymalnie trzy odbiorniki SCAN. Nazwa SCAN nadal znajduje się w DNS, ale DNS będzie zaokrąglał rozpoznawanie nazwy SCAN do jednego z maksymalnie trzech różnych adresów IP.
Na poniższym diagramie nasz dwuwęzłowy klaster ma teraz dwa odbiorniki SCAN. Użytkownik końcowy wysyła żądanie połączenia z my-scan.acme.com, a DNS rozpoznaje nazwę na 192.168.1.21 lub 192.168.1.22.
Jak pokazano powyżej, te dwa adresy VIP SCAN są przypisane do różnych węzłów w klastrze. Jeśli NODE1 ulegnie awarii, infrastruktura Grid przeniesie zarówno NODE1-VIP, jak i MY-SCAN (192.168.1.21) do działającego węzła w klastrze, za pomocą tej samej operacji ponownego ARP, o której mówiliśmy wcześniej. Nowsze detektory SCAN i ich VIP-y są obsługiwane w taki sam sposób, jak starzy VIP-y.
Podsumowując, wirtualne adresy IP służą do szybszego przełączania awaryjnego komunikacji sieciowej między aplikacją a węzłami w klastrze. System operacyjny używa protokołu rozpoznawania adresów, aby poinformować przełącznik sieciowy o kierowaniu połączeń do hosta. Grid Infrastructure wykorzystuje te same operacje ARP, aby przełącznik sieciowy wiedział, gdzie kierować ruch dla VIP i SCAN VIP. Jeśli węzeł ulegnie awarii, GI ponownie dokona ARP i SKANUJ VIP do innego węzła w klastrze.
