Напоследък се сблъсках с редица въпроси относно виртуални IP (VIP) адреси за Oracle RAC. Надявам се, че тази публикация в блога може да помогне да се хвърли малко светлина върху това какво е VIP, как работят и защо Oracle RAC ги използва. Преди да продължа по-нататък, трябва да обясня, че не съм специалист по мрежи. Всъщност компютърната мрежа е може би най-слабата ми точка от всичко, което се случва в ИТ магазините. Така че не ме дразнете, ако не разбера изцяло мрежовите неща, 100% точни. Ще обясня това с термини, които са ми послужили добре в кариерата ми в DBA, особено работата с Oracle RAC.
Повечето хора са запознати с свързването на всяко приложение, SQL*Plus или други, към сървър на база данни с един екземпляр. В крайна сметка тяхната заявка за свързване се изпраща на конкретен IP адрес. В нашата диаграма по-долу крайният потребител иска да се свърже с 192.168.1.1 за достъп до базата данни. Мрежовата заявка се насочва към мрежовия комутатор, към който е свързан този сървър на база данни. Този превключвател предава заявката към сървъра, който има искания IP адрес.
Повечето DBA на Oracle нямат проблем с разбирането на тази концепция. Животът става малко по-сложен, когато се разположи RAC, тъй като в клъстера има множество машини (възли). В следващата диаграма имаме RAC клъстер с два възела, като всеки възел има различен IP адрес.
Крайният потребител не се интересува към кой възел е свързана сесията му. Крайният потребител просто иска достъп до клъстера. Всеки възел ще бъде достатъчен. Конфигурацията на TNSNAMES.ORA на крайния потребител може да каже първо да опитате 192.168.1.1 и ако това не работи, опитайте 192.168.1.2 вместо това. По този начин Oracle RAC предоставя решение за висока достъпност.
Сега стигаме до цялата причина да се използват виртуални IP адреси. Ами ако крайният потребител се опитва да получи достъп до първия възел (192.168.1.1), но той не е наличен? Възелът не работи по някаква причина. Крайният потребител може лесно да се свърже с възела 192.168.1.2. Въпреки това, поради начина на работа на TCP/IP мрежите, може да отнеме до десет минути, докато мрежовата връзка към 192.168.1.1 изтече, преди да бъде осъществен достъп до 192.168.1.2. Продължителното изчакване на TCP/IP е единствената причина Oracle RAC да използва VIP лица. Просто искаме да намалим времето за достъп до друг възел в клъстера, ако исканият от нас възел не е наличен.
Традиционният IP обикновено е свързан към мрежовата карта на сървъра. ИТ администраторът ще конфигурира сървъра винаги да използва този конкретен IP адрес и никакви други устройства в мрежата няма да използват същия IP. Забележка:Опитвам се да опростя това тук и избягвам DHCP и регистрацията за лизинг за тези, които са запознати с темите.
Виртуален IP адрес не е свързан с мрежовата карта. Дори не е дефинирано в ОС. VIP не е реален IP адрес, подобен на начина, по който виртуалната машина не е реална система. Просто изглежда истинско за тези, които го използват. Така че нека разгледаме нашия клъстер с два възела, но този път с дефинирани VIP за тях.
Нашите сървъри все още имат своите редовни IP адреси, 192.168.1.1 и 192.168.1.2 съответно за NODE1 и NODE2. Тези два възела също имат VIP лица, свързани с тях. NODE1-VIP и NODE2-VIP са обозначени като IP адреси съответно 192.168.1.11 и 192.168.1.12. Всеки възел в RAC клъстера има свой редовен IP адрес и VIP. Може също да е полезно да знаете, че името на хоста и VIP имената често се дефинират в DNS, така че да не се налага да помним конкретно IP адресите.
Забележете, че крайният потребител сега иска достъп до един от VIP. Единствените хора, които трябва да използват тези традиционни IP адреси, са ИТ администраторите, които трябва да извършват работа на сървъра. Крайните потребители и всички приложения трябва да се свържат с VIP.
Помните ли, че казах по-рано, че VIP дори не е дефиниран в операционната система? Е, ако случаят е такъв, тогава как всичко знае, че VIP е присвоен на този възел? Всичко това се обработва от Grid Infrastructure (GI). Когато GI е инсталиран, един от екраните на Oracle Universal Installer (OUI) ще поиска имената на възлите в клъстера (имената на хоста) заедно с името на виртуалния хост. Екранната снимка по-долу показва как изглеждаше инсталацията 11g GI, когато поискате тази информация (екранна снимка от документацията на Oracle).
Публичното име на хост се конфигурира в ОС от администратора. Виртуалният IP не е конфигуриран в ОС, но Grid Infrastructure знае за него. За да разберем как работи това, трябва да се отклоним малко и да разберем протокола за разрешаване на адреси (ARP).
Когато сървърът се стартира и неговите мрежови компоненти са инициирани, протоколът за разрешаване на адреси е механизмът, който казва на комутатора пред сървъра да насочи целия трафик за своя IP адрес към MAC адреса на неговата мрежова карта. ОС, чрез ARP, казва на превключвателя да премине към NODE1 за заявки 192.168.1.1.
Когато Grid Infrastructure стартира, една от задачите при стартиране е да направи нещо подобно. GI, чрез ARP, казва на превключвателя да премине към NODE1 за всички заявки NODE1-VIP (192.168.1.11). Докато GI стартира VIP, този VIP адрес не може да се маршрутизира.
Сега ето вълшебната част... когато NODE1 изпадне, GI на друг възел в клъстера ще открие прекъсването. След това GI ще извърши нова ARP операция, която информира превключвателя да насочи VIP към друг възел в клъстера. Тъй като VIP е виртуален, той може да бъде пренасочен в движение. В диаграмата по-долу NODE1 е неуспешен. Традиционният му IP вече не е наличен. GI пренастрои VIP на останалия възел в клъстера.
Повторното ARP на VIP може да бъде извършено за секунди. Крайният потребител може да изпита кратка пауза в мрежовата си комуникация между приложението и екземпляра на базата данни, но това е много, много по-малко, отколкото ако чакаме изчакване на TCP/IP.
Oracle 11gR2 представи слушателите на SCAN. Един Oracle RAC клъстер може да има най-много три SCAN слушатели. Името SCAN все още е в DNS, но DNS ще преобразува разделителната способност на SCAN имената към един от до три различни IP адреса.
На диаграмата по-долу нашият клъстер с два възела вече има два SCAN слушателя. Крайният потребител прави заявка за връзка към my-scan.acme.com и DNS разрешава името на 192.168.1.21 или 192.168.1.22.
Както е показано по-горе, тези два SCAN VIP са присвоени на различни възли в клъстера. Ако NODE1 падне, Grid Infrastructure ще премести както NODE1-VIP, така и MY-SCAN (192.168.1.21) в оцелял възел в клъстера, чрез същата операция за повторно ARP, за която говорихме по-рано. По-новите слушатели на SCAN и техните VIP лица се обработват по същия начин като стария стил VIP.
За да обобщим, виртуалните IP адреси се използват за осигуряване на по-бързо преминаване при отказ на мрежови комуникации между приложението и възлите в клъстера. Операционната система използва протокол за разрешаване на адреси, за да уведоми мрежовия превключвател за маршрутизиране на връзки към хост. Grid Infrastructure използва същите ARP операции, за да позволи на мрежовия превключвател да знае къде да маршрутизира трафика за VIP и SCAN VIP. Ако възел се спусне, GI ще пренастрои VIP и ще СКАНИРА VIP към друг възел в клъстера.
