VYSOKÁ ŠKOLA FINANČNÍ A SPRÁVNÍ, o.p.s. Fakulta sociálních studií Studijní obor: Aplikovaná informatika
Bakalářské studium kombinované
Zdeněk Kuběnka
Návrh a implementace systému s vysokou mírou dostupnosti Design and implementation of highly available system
BAKALÁŘSKÁ PRÁCE
Praha 2015
Vedoucí závěrečné práce: RNDr. Jan Lánský, Ph.D.
Poděkování Touto cestou bych chtěl poděkovat RNDr. Janu Lánskému, Ph.D. za jeho podnětné připomínky k této bakalářské práci a manželce za podporu, která byla velmi důležitá během psaní této práce a celého studia.
Prohlášení Prohlašuji, že jsem tuto závěrečnou práci vypracoval zcela samostatně a veškerou použitou literaturu a další podkladové materiály, které jsem použil, uvádím v seznamu literatury a že svázaná a elektronická podoba práce je shodná. Současně prohlašuji, že souhlasím se zveřejněním této práce podle § 47b zákona č.111/1998Sb., o vysokých školách a o změně a doplnění dalších zákonů (zákon o vysokých školách), ve znění pozdějších předpisů.
23.8.2015 Zdeněk Kuběnka
Abstrakt Bakalářská práce popisuje návrh a implementaci systému s vysokou mírou dostupnosti (HA). Práce ve své teoretické části pokrývá obecné vlastnosti HA architektury a řešení jak vysoké míry dostupnosti dosáhnout. Praktická část obsahuje detailní návrh po všechny úrovně HA architektury systému a současně implementaci systému pomocí volně dostupném software a software firmy Oracle.
Abstract This bachelor diploma thesis describes design and implementation of highly available systém (HA). The theoretical part of the thesis covers various aspects of HA architecture and possible solutions to achieve the high availability. The practical part covers the detailed design of all levels of HA architecture as well as implementation of such systém using freely available software and software produced by Oracle corporation.
Klíčová slova Vysoká dostupnost služeb, clustering, redundance, disaster recovery, systémová architektura, Linux, DRBD, OCFS2, Oracle Database, Oracle Fusion Middleware, Oracle Grid Infrastructure
Keywords High availability, clustering, redundancy, disaster recovery, system architecture, Linux, DRBD, OCFS2, Oracle Database, Oracle Fusion Middleware, Oracle Grid Infrastructure
Obsah 1
ÚVOD ..................................................................................................................... 1
2
SYSTÉMY S VYSOKOU MÍROU DOSTUPNOSTI (HA) ............................................................ 3
2.1
Definice požadavků na HA systémy .............................................................................................. 3
2.2
Definice HA systému ..................................................................................................................... 5
2.3
Obecné rysy návrhu HA systému .................................................................................................. 5
2.4
Počítačový hardware .................................................................................................................... 8
2.5
Datová úložiště ........................................................................................................................... 10
2.6
Operační systém, souborový systém .......................................................................................... 14
2.7
Middleware................................................................................................................................. 16
2.8
Aplikace ...................................................................................................................................... 18
2.9
Infrastruktura.............................................................................................................................. 19
3
CLUSTERING JAKO IDEÁLNÍ ŘEŠENÍ PRO HA ................................................................... 25
4
VIRTUALIZACE A JEJÍ POUŽITÍ V RÁMCI HA..................................................................... 32
4.1
Virtualizace hardware ................................................................................................................. 32
4.2
Virtualizace v rámci operačního systému ................................................................................... 33
4.3
Virtualizace datových úložišť ...................................................................................................... 33
4.4
Virtualizace na úrovni sítě .......................................................................................................... 35
4.5
Virtualizace služeb ...................................................................................................................... 35
5
UKÁZKOVÁ ŘEŠENÍ HA SYSTÉMŮ ................................................................................ 37
5.1
Oracle Exadata Machine ............................................................................................................. 37
5.2
Red Hat Cluster Suite .................................................................................................................. 38
6
ANALÝZA SYSTÉMU .................................................................................................. 40
6.1
Konceptuální schéma systému ................................................................................................... 40
6.2
Detailní analýza jednotlivých komponent system stacku a identifikace SPOF ........................... 42
7
NÁVRH HA SYSTÉMU ............................................................................................... 44
7.1
Databázové a middleware servery ............................................................................................. 44
7.2
Infrastruktura.............................................................................................................................. 45
7.3
Datové úložiště (pevné disky, souborové systémy) .................................................................... 47
7.4
Revalidace detailní analýzy ......................................................................................................... 47
8
IMPLEMENTACE SÍŤOVÉ INFRASTRUKTURY ..................................................................... 50
8.1
Síť – L2 - Ethernet ....................................................................................................................... 50
8.2
Síť – L3 – Internet Protocol ......................................................................................................... 51
8.3
Gateway a reverzní proxy ........................................................................................................... 52
8.4
Infrastrukturní služby DNS a NTP ................................................................................................ 53
9
IMPLEMENTACE DATOVÝCH ÚLOŽIŠŤ ............................................................................ 55
10 IMPLEMENTACE DATABÁZE A MIDDLEWARE ................................................................... 58 11 TESTOVÁNÍ ............................................................................................................. 62 12 ZÁVĚR ................................................................................................................... 66
1 Úvod První dekáda 21. století zaznamenala obrovský rozmach on-line služeb po celém světě. Dnes si již těžko dokážeme představit život bez přístupu k Internetu a skrz něj přístup k různým službám, které nám každý den ulehčují život; ať se jedná o on-line bankovnictví, elektronickou komerci, vyhledávací a znalostní systémy či i tak jednoduchou službu jako je e-mail. Kde ovšem došlo k největšímu rozmachu, je komerční sféra. Dnešní komerční svět se nese ve znaku globalizace, kde jsou podnikové informační systémy používány nonstop, protože mají své pobočky roztroušeny po celém světě. Jedním z požadavků těchto podniků je dostupnost firemních informačních systémů z kteréhokoliv místa na světě, v kteroukoliv pracovní dobu a v kterýkoliv den - tyto systémy jsou obecně označovány jako systémy s vysokou mírou dostupnosti, angl. high-availability systems (HA). V roce 2006 jsem se stal zaměstnancem firmy Oracle, přesněji její divize Oracle Managed Cloud Services, kde je mým úkolem správa a implementace ERP, BI, CRM a dalších systémů založených na platformě Oracle Database / E-business Suite / Fusion Middleware. Tyto systémy jsou podle SaaS/PaaS/IaaS modelu poskytovány zákazníkům po celém světě. Návrh HA architektury vyplývá z řízení kontinuity činnosti organizace (business continuity management - BCM). V rámci BCM se určí interní a externí hrozby v rámci organizace, jejich dopady na případné ztráty a jeho cílem je vytvořit takové postupy a prostředí, které umožní zajistit kontinuitu (a případnou obnovu) činnosti organizace. Jedním z výsledků tohoto procesu je návrh HA architektury. Při každém návrhu takové architektury je nutné jako první stanovit cíl dostupnosti systému, tzn. odpovědět na otázku: kdy a jak dlouho může být systém mimo provoz. Od této otázky se poté dále odvíjí celý návrh - jeho finanční, technická a procesní stránka. Jiné požadavky na míru dostupnosti bude mít systém, který je určen pro podnik mající své aktivity pouze v jasně ohraničené časové zóně (např. pouze na jednom kontinentě), a naprosto jiné požadavky bude mít podnik, mající aktivity po celém světě a tudíž vyžadující mnohem vyšší míru dostupnosti. Jedním z výborných zdrojů je kniha High Availability and Disaster Recovery [SCHMIDT] od německého autora Klaus Schmidt, který je dlouhodobým zaměstnancem Electronic Data Systems. Popisuje HA metodologii jak po stránce procesní a finanční, tak po 1
technické stránce na různých úrovních - operační prostředí (energetika, HVAC apod.), hardware, software, datová úložitě, síťová infrastruktura, aplikační infrastruktura apod. Současně se také dotýká tématiky disaster recovery, tzn. plánování havarijních procedur v HA architektuře. Jako další zdroje bych rád uvedl manuály jednotlivých výrobců softwarových prvků. Cílem mé bakalářské práce je navrhnout a implementovat HA systém podporující aplikační platformu Oracle Fusion Middleware a jehož architektura bude založená na komponentech běžně dostupných pro jednotlivce či malé podniky. Projekt budu popisovat pouze po technické stránce, nikoliv však po stránce finanční či obchodní. Bakalářská práce mi tak poslouží jako operačně-technický manuál pro implementaci HA systému. Samotnou implementaci tohoto systému provedu na virtualizovaném hardware. Vzhledem k faktu, že drtivá část literatury, ze které čerpám, je v anglickém jazyce a protože současně pro velké množství odborných termínů nemá ustálený překlad do českého jazyka, používám v této práci místy i anglickou terminologii. Práce je rozdělena na dvě části – v části teoretické se zabývám popisem HA architektury (kapitoly 2. až 5.), a v části praktické (kapitola 6) je popsána implementace HA systému jako takového.
2
2 Systémy s vysokou mírou dostupnosti (HA) 2.1 Definice požadavků na HA systémy Principy a technologie HA tvoří dnes nutnou součást všech ICT projektů, kde je nutné zajistit v rámci business continuity pokud možno nepřetržitou funkcionalitu systému, nebo alespoň zvýšit jeho dostupnost, minimalizovat rizika totálních výpadků služby a současně jasně definovat procesy a technologické postupy k minimalizaci těchto rizik. Nutnost implementovat HA systém vychází z požadavků plánování business continuity v dané organizaci, během něhož management řízení rizik v organizaci musí jasně definovat hrozby vyplývající z výpadku systému. Výpadkem systému se rozumí nedostupnost služby, popřípadě snížení funkcionality služby pod míru specifikovaných v SLA. Tyto rizika mohou být nejenom jasně kvantifikovaného finančního rázu ve formě nákladů na odstranění výpadku, ale i rázu nefinančního, například ztráta reputace organizace respektive obchodní značky organizace, ztráta certifikací a v neposlední řadě u opravdu významných systémů i ke ztrátě na majetku a životech. Při definování požadavků na HA systém je nutné položit několik základních otázek. Otázka první je, jaké poruchy systému mohou být řešeny transparentně, tzn. v kterých částech systému nesmí dojít k výpadku. Proti těmto poruchám musíme zavést dostatečnou úroveň ochrany před výpadkem. Otázka druhá se týká dočasného výpadku služeb. U nich musíme zjistit jejich případnou délku, (jednou denně, jednou týdně, měsíčně apod.). Dočasný výpadek služby nazýváme malým výpadkem služby (minor outage). Tento druh výpadku není pro organizaci fatální; nedochází k ztrátě dat, ale pouze k dočasné ztrátě funkcionality, tzn. konzumenti služby nemohou tuto službu používat po určitou dobu. Tento typ výpadku můžeme dále rozdělit na neplánovaný výpadek, vzniknuvší neplánovaně jako důsledek poruchy systému, nebo plánovaný výpadek, vzniknuvší například na základě potřeby údržby, který je předem známý, je známá jeho délka a předpokládaný čas obnovy. Otázka třetí je dlouhodobý výpadek služby, který se stává zřídkakdy, znamená vážné poškození funkcionality systému, ztráty dat apod. s velkým důsledkem na 3
fungování organizace. Tento výpadek služby nazýváme velkým výpadkem služby (major outage), popř. havárií systému (disaster). V případě takového výpadku služby popř. havárie musíme také definovat, kolik dat může být ztraceno (čtvrtá otázka). Pátá otázka pomáhá určit, které chyby systému jsou nepravděpodobné, a nevyžadují tedy ochranu, popřípadě řešení výpadku – takovými se tedy při návrhu nezabýváme. [SCHMIDT, str. 18] Odpovědí na první otázku je definování dostatečné ochrany před výpadkem služby. Účelem je zajistit takovou konfiguraci systému, aby případný uživatel vůbec nepostřehl výpadek jednotlivých komponent. Odpovědí na druhou otázku je jasně definovaný rozsah tolerance, kdy a jak často může k výpadku služby dojít tak, aby bylo vyhověno požadavkům na dostupnost systému definované v SLA; a v případě jejich nevyhovění i ztráty vyplývající z porušení SLA (např. pokuty, ztráta zákazníka). Odpovědí na třetí otázku je jasná definice velkého výpadku, resp. havárie systému. Musí jednoznačně určit, za jakých podmínek je možné vyhlásit havárii systému a uvést v činnost procesy, které zajistí zotavení systému z havárie (disaster recovery). Odpověď na čtvrtou otázku jednoznačně určuje, nakolik je nutné zajistit kontinuitu zpracování a uchovávání dat způsobem, aby byla zajištěna jejich ochrana před ztrátou; a nakolik je případná ztráta dat v souladu s podmínkami definovanými v SLA. Odpovědí na pátou otázku jednoznačně definujeme rizika, které nejsou řešeny v rámci služby jako takové, ať již je to pro jejich nízkou pravděpodobnost či vysokou nákladnost. Na základě těchto odpovědí jsme schopni u dané služby jasně definovat dvě základní oblasti, na které musíme brát zřetel:
high availability (HA) – vysoká dostupnost služby – toto téma pokrývá první a druhá otázka
disaster recovery (DR) – obnovení z havárie služby – toto téma pokrývá třetí otázka
V rámci mé bakalářské práce se zabývám hlavně technologickým řešením prvního, tzn. HA, ale dotknu se též okrajově tématu DR, který s ním úzce spojen.
4
2.2 Definice HA systému „Pojem HA můžeme definovat jako schopnost systému být imunní proti výpadkům menšího rozsahu nebo jeho obnovy z výpadku v krátkém časovém období pomocí automatizovaných prostředků.“ [SCHMIDT, str. 22]. Při návrhu HA systému musíme brát v úvahu následující faktory:
Identifikace potenciálních výpadků v systému.
Identifikace systému jako systému požadující HA architekturu
Možnosti automatizované ochrany či obnovy
Během identifikace potenciálních výpadků v systému musíme pečlivě analyzovat veškeré komponenty systému, definovat pravděpodobnost jejich výpadku, vyhodnotit pravděpodobné havarijní scénáře a následně určit nakolik jsou jednotlivé komponenty klíčové pro funkcionalitu systému. Dále musíme identifikovat, které systémy požadují HA architekturu – na základě požadavků na dostupnost systému vyplývající ze SLA určíme jednoznačně, zdali nutné systém navrhnout jako HA schopný. Pouze takové systémy, jejichž maximální délka výpadku je v řádu minut či hodin, je nutné navrhovat jako HA systémy. U systémů, kde je tolerovaný výpadek v řádu dnů či týdnů, nemá smysl jej takto navrhovat. Jako poslední krok musíme zjistit nakolik a jak jsme schopni technologicky zajistit automatickou ochranu funkcionality systému a jeho komponent před výpadkem, případně jakým způsobem je možné zajistit obnovu funkcionality systému automatizovaným způsobem.
2.3 Obecné rysy návrhu HA systému Společným rysem výpadků malého rozsahu je chybná funkcionalita popř. úplný výpadek jednotlivých komponent v systému, přičemž žádná z těchto komponent není nepostradatelná pro funkcionalitu systému jako takového. Systém tedy navrhujeme jako systém odolný proti chybám (fault tolerant system). Předpokládáme tedy, že žádná porouchaná komponenta systému nezpůsobí výpadek celého systému jako takového, čili identifikujeme a eliminujeme jedinečné místo výpadku pro celý systém, tzv. single point of failure – SPOF. V případě poruchy komponenty systému bude tento výpadek části systému omezen pouze na danou komponentu a nebude se dále propagovat do dalších částí systému. Při obnově funkcionality dané komponenty musíme dále zajistit nahrazení této komponenty bez 5
výpadku celého systému. „Při návrhu HA systému tedy používáme tedy čtyři hlavní metody, jak výše uvedené zajistit. Jsou jimi kategorizace vrstev systému (system stack), robustnost, redundanci a virtualizaci“ [SCHMIDT, str. 34, 52] Kategorizace vrstev systému nám umožňuje rozdělit jednotlivé komponenty na kategorie podle služeb, které poskytují, a současně definují jednotlivé závislosti na sobě. V rámci těchto kategorií identifikujeme nejenom hardware, software, infrastrukturu ale taktéž prostředí, v kterém se systém nachází a taktéž entity, které se systémem interagují (např. uživatelé, externí systémy apod.).
Obrázek 1 - System stack. Šipky naznačují závislosti jednotlivých komponent systému. Zdroj: SCHMIDT, str. 57
Robustnost systému zajistíme návrhem takového řešení, kdy použijeme pokud možno co nejjednodušší a nejvíce nezávislé prvky; přičemž u každého prvku eliminujeme ty funkcionality, které nepotřebujeme a zbytečně by vnášely nežádoucí složitost do systému. Aplikujeme zde tzv. KISS (keep it simple and stupid) princip. Redundancí se rozumí použití prvků v systému, které zajišťují stejnou funkcionalitu a schopností pokračovat v provozu i přes výpadek jednoho z prvků. Pouhé znásobení prvků v systému nám ale samotnou redundanci nezajistí; potřebujeme k tomuto navíc řídící prvek, který na základě monitorování vyhodnotí výpadek jednoho z prvků a provede jeho nahrazení prvkem záložním. Příkladem může být diskové pole v serveru – zde násobíme jednotlivé disky, ale ty samotnou redundanci nezajistí bez software (případně samostatného hardware - řadiče), které umožní jednotlivé disky mezi sebou zrcadlit, jejich stav monitorovat a v případě výpadku jednoho z disků jej nahradit jiným a data zreplikovat z disků zdravých. 6
Redundancí eliminujeme potenciální SPOF na nejnižší možnou míru na konceptuální úrovni jednotlivých komponent v systému, avšak málokdy se nám podaří SPOF naprosto eliminovat. V uvedeném případě diskového pole by byl SPOF pouze řadič, který je možné operativně vyměnit v relativně krátké době, ale za cenu výpadku celé služby, protože služba využívá data na daných discích, které jsou přístupné pomocí řadiče. Řešením by bylo použití samostatných datových úložišť se schopností plnohodnotné
replikace.
„Proto
zajistit
plnou
redundanci
je
velice
náročné.“ [SCHMIDT, str. 73]. Virtualizací docílíme oddělení jednotlivých prvků služby od technických prostředků, tím umožníme redundanci daného prvku služby případně jednodušší rychlou náhradu v případě výpadku; eliminujeme tím pevně danou závislost jednotlivých komponent služby v jednotlivých vrstvách systému. Typickým příkladem virtualizace je použití virtuálního počítače, které umožňuje spustit daný operační systém v předdefinované konfiguraci v rámci fyzického hardware, a v případě výpadku fyzického hardware je možné tento virtuální počítač spustit během velice krátké doby na jiném fyzickém hardware. Při návrhu je nutné uvědomit si, že při aplikaci výše uvedených principů se často dostaneme do konfliktu – na jednu stranu se snažíme zajistit co nejjednodušší architekturu, na straně díky redundanci vnášíme do systému složitost. Vyšší míra složitosti se pak projevuje v nákladech na implementaci a údržbu systému jako takového a navíc vnáší do celého konceptu další potenciální problémy a případné chyby. Proto musíme zvážit, které komponenty jsme nuceni navrhovat jako redundantní, a u kterých komponent se spolehneme na nízkou pravděpodobnost jejich výpadku a nutnosti nahrazení během výpadku celé služby při současném vyhlášení havarijního stavu (disaster recovery). Analýzu požadavků na HA systém provedeme pomocí několika kroků. Krokem prvním
je
identifikace
jednotlivých
konceptuálních
komponent
systému.
Komponentami se zde rozumí nejenom hardware, software, ale také uživatelé, kteří systém používají a fyzické prostředí, kde se jednotlivé prvky nachází. Druhým krokem je identifikace vazeb a vztahů mezi jednotlivými komponentami. Musíme brát v úvahu fakt, že systém, který navrhujeme, se skládá z několika vrstev – od uživatelské úrovně, přes aplikační úroveň, middleware či databázi, až po operační
7
systém a hardware. Krokem posledním je určení druhu potenciálních selhání a pokud možno pravděpodobnost jejich selhání Na základě těchto kroků identifikujeme potenciální SPOF a rozhodneme, jakým způsobem u jednotlivých komponent zajistíme jejich funkcionalitu, případně u jakých komponent akceptujeme jejich selhání s následkem selhání služby jako takové. V následující kapitole podrobněji popíši jednotlivé obecné typy komponent systém stacku, jejich funkcionalitu, možnosti selhání a jejich obnovu.
2.4 Počítačový hardware Hardwarové komponenty jsou základní stavební bloky počítačových systémů, proto zajištění před výpadky a schopnost zotavení z chyb je jedním z prvních úkolů, které je nutno v rámci HA architektury řešit. Díky tomuto požadavku je hardware nejvyspělejší součást HA architektury – na trhu je k dispozici velké množství hotových řešení, které zajišťují jak robustnost, tak redundanci. „Hardware je jedinou komponentou, u které je možné kvantifikovat spolehlivost. Je to také jediná oblast, kde je možné přesně spočítat pravděpodobnost výpadku.“ [SCHMIDT, str. 99]. Míra spolehlivosti je udávána výrobci v dokumentaci k danému hardware. Na základě těchto dat je možné jednoznačně definovat pravděpodobnost jeho selhání a současně zdroje, které jsou nutné k nápravě selhání. Hardwarové komponenty jsou vyrobeny kompozicí elektronických součástek (tranzistory, diody, kondenzátory, tištěné spoje, apod.) a jsou tak náchylné k poškozením vznikající díky fyzikálním vlivům jak při výrobě, tak při jejich provozu. Poškození elektronické součástky má většinou za následek chybnou funkcionalitu popř. úplný výpadek celé komponenty. Toto klade požadavek jak na vysoký důraz na kvalitu výroby tak na prostředí, v kterém jsou počítačové systémy provozovány. Při volbě jednotlivých komponent tedy musíme pečlivě volit výrobce jednotlivých komponent; a to nejen po stránce kvality komponenty, ale i podle schopnosti výrobce poskytnout adekvátní podporu. Počítačové systémy se skládají z několika základních součástí. Zdroj elektrického proudu mění střídavé napětí z elektrické sítě na stejnosměrné napětí vhodné pro napájení jednotlivých součástí počítače. Vstupně/výstupní zařízení umožňují komunikaci uživatele popř. jiného systému. Centrální procesorová jednotka (CPU) vykonává strojové instrukce, ze kterých jsou složeny programy;
8
součástí moderních CPU je také vyrovnávací paměť procesoru (cache). Sběrnice (system bus) propojuje vstupně-výstupní zařízení s procesorem. Datové úložiště slouží k uchovávání dat a programů. Rozdělujeme je na volatilní (RAM, cache), vyžadující nepřetržité napájení elektrickým proudem (po jeho přerušení se jejich obsah smaže) a nevolatilní – informace jsou uchovány i po přerušení napájení. Zdroje elektrického proudu jsou díky své jednoduchosti poměrně robustní zařízení, u kterých je možné jednoduchým způsobem zajistit redundanci. Většina serverových systémů obsahuje minimálně dvě nezávislé napájecí jednotky, které jsou průběžně monitorovány a je možné je vyměnit bez nutnosti přerušení napájení. Chybná funkcionalita je většinou zapříčiněna vadnými elektronickými součástkami, přehřátím (např. při nefunkčním odvětrávání) nebo přepětím na vstupu střídavého proudu. Doporučuje se také připojit každou jednotku k nezávislému zdroji střídavého proudu pro případ, kdy dojde k selhání dodávky elektrické energie. Za vstupní/výstupní zařízení považujeme jakékoliv zařízení, které je oddělitelnou součástí počítačového systému. Jsou to zařízení pro uživatelský vstup/výstup a zařízení pro komunikaci s ostatními systémy. Z hlediska návrhu HA architektury nás zajímají hlavně ty zařízení, jejichž nefunkčnost může ohrozit funkcionalitu celého systému, tzn. zařízení umožňující připojení k počítačové síti (síťové karty) nebo k datovému úložišti (řadiče, HBA). U nich se aplikuje princip redundance, tzn. každé zařízení je v rámci počítačového systému zduplikováno a ochrana před výpadkem je řešena na úrovni operačního systému. Sběrnice je u většiny počítačových systému je považována za SPOF – jedná se totiž o centrální součást počítačového systému a její redundanci není možné řešit jinak, než redundancí celého počítačového systému. U CPU toto již není tak jednoznačné – v případě jednoprocesorových systémů dojde při jeho poškození k havárii celého systému (jedná se tedy o SPOF); v případě víceprocesorových sice dojde sice k havárii systému, ale po restartu je mnohdy schopný pracovat v režimu, kdy je poškozený CPU systémem vyřazen a ten používá nadále ostatní CPU. Speciální konfigurace je tzv. hot-swappable CPU, kdy je možné poškozený CPU vyměnit za běhu. Schopnost výměny za běhu systému musí být podporován nejenom daným hardware (tzn. CPU, sběrnice, paměť apod.) ale také operačním systémem, který musí daný CPU izolovat a umožnit jeho fyzickou výměnu. Pokud jsou ale na daném CPU prováděny výpočetní úkony, dojde v případě
9
poškození minimálně k havárii aplikace, která daný CPU ve chvíli poškození používá. V případě, že CPU používá operační systém, dojde většinou k havárii celého systému. U volatilních datových úložišť (cache, RAM) dochází k chybám dvojího typu. Buď se jedná o chybnou funkcionalitu celého paměťového čipu, nebo vlivem fyzikálních jevů (elektromagnetické záření, radiace), může dojít v paměťovém čipu k změně polohy bitu a tím k změně celého obsahu paměti na dané adrese. V případě chyby druhého typu se u RAM spoléhá na schopnost opravy jednotlivých chyb. Toho je dosaženo pomocí tzv. ECC (Error Checking and Correcting), kdy pro daný paměťový blok je při zápisu dopočítáván kontrolní součet, a při každém čtení je prováděna kontrola, zdali kontrolní součet souhlasí s obsahem – v případě že nesouhlasí, je možné chybu pomocí opravného algoritmu napravit. V případě, kdy dojde k poškození paměťového čipu je situace problematičtější. V případě cache se může i nemusí jednat o SPOF, protože v dnešních systémech existují různé úrovně cache. Cache nejvyšší úrovně sdílí stejnou fyzickou součástku s CPU (resp. je součástí CPU); poškození takovéto cache má za následek výměnu celé součástky nesoucí jak CPU tak cache. U nižší úrovně je cache součástí sběrnice, takže její poškození má za následek havárii celého systému a nutnost výměny sběrnice. V případě RAM některé systémy používají redundanci, kde jednotlivé karty s paměťovými čipy pracují v tandemu a v případě detekované chyby systém danou kartu z tandemu odpojí; tuto je možné poté vyměnit za chodu. Podobné řešení je ale velice nákladné a proto se používá minimálně.
2.5 Datová úložiště Za nevolatilní datové úložiště se většinou považují pevné disky, flash paměti, diskety, optická média a magnetické pásky. Z hlediska HA architektury nás zajímají hlavně pevné disky. Pevné disky jsou zařízení sestávající se z elektroniky (řadiče disku) a dále jedné a více rotujících kruhových ploten z nemagnetického materiálu, na kterých je nanesena vrstva feromagnetického materiálu. Na každé straně této plotny je umístěna hlavička (head), která je upevněna na servomotor, jenž umožňuje vystavit hlavičku nad požadované místo nad plotnu. Hlavičky, plotny a servomotor jsou v hermeticky uzavřeném prostředí v atmosféře s vysokou mírou čistoty.
10
Hlavička zajišťuje zápis dat pomocí zmagnetizování oblasti, nad kterou se právě nachází. Čtení je prováděno pomocí téže hlavičky, kdy je zjištěna orientace magnetického dipólu dané oblasti. Zápis i čtení dat je prováděno na všech stranách ploten současně, vzniká tímto tedy jakýsi pomyslný válec (cylinder). Vystavením hlavičky nad určité místo na plotně vznikají tedy jakési kruhy, nazývané stopy (tracks). Ty jsou dále rozděleny na jednotlivé datové oblasti (sector) a do nich jsou zapisována data. Geometrie disku je tedy určena pomocí souřadnic cylindr-hlavičkasektor (CHS). Řadič disku řídí servomotor (tzn. vystavení hlavičky nad požadované CHS souřadnice), koordinuje zápis a čtení a současně provádí další operace, jako např. vytváření a verifikaci kontrolního součtu, označování chybných oblastí a jejich nahrazování záložními oblastmi. Původně byl řadič disku samostatnou součástí a disk byl pouze „hloupé“ zařízení připojené k diskovému řadiči, dnešní pevné disky ale obsahují jak fyzické součásti (servomotor, hlavičky, plotny) tak i řadič. Dříve měl každý řadič své specifické rozhraní (interface), s kterým komunikoval se systémovou sběrnicí; operační systém tedy přistupoval k datům přímým dotazem na požadované CHS souřadnice, postupem času došlo ke standardizaci těchto rozhraní – vznikly standardy PATA a jeho novější verze SATA, SCSI a jeho novější verze SAS, které definují jak komunikační protokol, tak fyzické připojení disků k HBA – kabely, napájení apod. Tyto standardy tedy umožňují v moderních discích odstínit fyzické vlastnosti disků (tzn. CHS), a používají adresování pomocí LBA. Řadič disku následně překládá LBA adresy interně na CHS pomocí firmware, který je něm obsažen. HBA je hardwarový adaptér, který zajišťuje komunikaci mezi diskem a systémovou sběrnicí. V dnešních počítačích se používají hlavně dva standardy – SATA, který používá protokol ATA a je používaný především v domácích počítačích a SAS, který používá komunikační protokol vyvinutý původně pro SCSI a je hlavně doménou serverů a průmyslových úložišť [CLEMENS, str. 124]. Díky své konstrukci sestávající se z pohyblivých součástí, nutnosti vysoké míry čistoty prostředí při výrobě a principu magnetického záznamu (schopnost uchovat orientaci magnetického dipólu klesá s narůstající teplotou) jsou pevné disky jednou z nejporuchovějších součástí počítače. Předpokládáme tedy u nich vysokou míru poruchovosti, s kterou je nutno v návrhu HA architektury počítat. U disku může docházet k několika druhům chyb. V prvním, méně kritickém případě, dojde k nemožnosti číst/zapisovat data do určitého sektoru. Toto v moderních discích již je
11
schopen do určité míry vyřešit samotný řadič disku, který transparentně alokuje poškozené sektory na sektory ze záložní oblasti. Tuto informaci poté uchovává v servisních sektorech disku. Systém je tedy od těchto chyb transparentně chráněn. V případě narůstajícího množství chyb tohoto typu je systém/uživatel upozorněn díky monitoringu disku (SMART) a je mu doporučena výměna. Horší případ nastane při úplném zničení, a to buď pohyblivých součástí (utržené hlavičky, rozsáhlé mechanické poškození plotny) či při zničení řadiče disku. Takovýto disk je nadále nepoužitelný a musí být nahrazen, přičemž data na takto poškozeném disku jsou většinou nenávratně ztracena. Z tohoto důvodu je nutné řešit ochranu před ztrátou dat pomocí redundance. „RAID je koncept, kdy dva a více disků jsou logicky svázány do tzv. pole, a toto pole je systému prezentováno jako jedno blokové zařízení. “ [TROPPENS, str. 22] Jedná se o ideální technologii pro HA architekturu, která tímto plně pokrývá tři základní požadavky – redundanci, robustnost a virtualizaci. Redundance je řešená zápisem dat současně na nejméně dva disky zároveň. Robustnost je zajištěna použitím standardizovaného protokolu - je možné použít jakýkoliv disk používající protokol řadiče nezávisle na jeho výrobci, fyzických vlastnostech, velikosti apod. Díky virtualizaci je systém plně odstíněn od diskového pole, tzn. je nezávislý na jeho struktuře (počtu disků, systém ochrany dat, monitoring apod.); HBA diskového pole poskytuje systému celé pole jako jedno blokové zařízení (popřípadě jeho logickou část). Distribuce dat uvnitř RAID pole se řídí podle tzv. RAID úrovní; přičemž je definovány několik základních typů. Při konfiguraci RAID 1 (zrcadlení – mirroring) dochází k zapisování stejných dat vždy na nejméně dva disky najednou, přičemž čtení probíhá z jednoho disku. V RAID 0 (rozkládání – stripping) konfiguraci jsou data zapisována nejméně na dva disky najednou, data však nejsou duplikována, ale rovnoměrně rozkládána mezi jednotlivé disky. Čtení probíhá z obou disků najednou. Rozkládání je též použito u RAIDu úrovně 3/4/5, data jsou zde zapisována nejméně na dva disky najednou, podobně jako u strippingu, ale navíc zde existuje třetí disk, na který je během ukládání prováděn výpočet parity (tzn. kontrolního součtu). V případě výpadku jednoho disku ze strippovaných disků je možné data dopočítat kombinací zbývajícího disku a paritních dat. V některých případech mohou být data při čtení verifikována pomocí paritních dat. Speciální formou konfigurace disků v poli je
12
JBOD – nejedná se o RAID v pravém slova smyslu, ale pouze o soubor disků, které dohromady tvoří jednu logickou jednotku. Přidáváním dalších disků je možné jednoduše zvyšovat kapacitu tohoto pole. Kombinací výše uvedených RAID úrovní vznikají další úrovně, např. RAID 0+1 umožňuje jak stripping tak mirroring. Jednotlivé úrovně sebou nesou své klady a zápory (viz. Tabulka 1).
Read
Write
Space
performance
performance
requirement
None
Good
Very good
Minimal
RAID 1
High
Poor
Poor
High
RAID 10
Very high
Very good
Good
High
RAID 4
High
Good
Very very poor
Low
RAID 5
High
Good
Very poor
Low
RAID 6
Very high
Good
Very very poor
Low
RAID level
Fault-tolerance
RAID 0
Tabulka 1 - RAID úrovně Zdroj: TROPPENS, str. 38
RAID je dnes řešen hardwarovým nebo softwarovým způsobem. V případě hardwarového RAIDu existuje samostatné hardwarové zařízení (specializovaný HBA adaptér), pomocí nějž jsou jednotlivé disky spravovány; monitorovány a současně je transparentně řešen výpadek disků v RAID poli; počítači je poté prezentováno toto pole jako jedno blokové zařízení. Toto hardwarové zařízení většinou obsahuje i vlastní cache, která je zálohována baterií. Typickým představitelem jsou SAS/SCSI řadiče firmy Adaptec. Výhodou je větší ochrana dat a vyšší výkonnost – o správu disků se stará specializovaný hardware a odnímá tak nutnost CPU se aktivně podílet na správě. Nevýhodou je vázanost datových struktur na přesný typ hardwarového zařízení – v případě poruchy řadiče je nutné vyměnit jej za jiný stejného typu. Takovéto zařízení jsou také finančně náročnější. Softwarový RAID umožňuje služby diskového pole bez finančních investic; disky jsou připojeny přímo na základní desce integrovaný HBA, který sám o sobě nezajišťuje funkcionality RAIDu, počítači je prezentovaný každý disk samostatně. Řízení RAID úrovní je ponecháno na software 13
pracující v rámci operačního systému. Typickým představitelem je Linux RAID (aka MD – multiple drive) nebo Logical Disk Manager ve Windows. Výhodou je přenositelnost (odpadá vazba na specifický typ hardware) a jak již bylo uvedeno, odpadají náklady na pořízení hardwarového zařízení. Také je nevýhodou nižší výkonnost, protože veškerou správu jednotlivých disků zajišťuje CPU počítače – toto je zvlášť markantní při RAID úrovních využívající výpočet paritních dat. Současně zde neexistuje ochrana při výpadku napájení; proto je u takovéto konfigurace doporučeno používat záložního zdroje napájení ve formě UPS.
2.6 Operační systém, souborový systém „Většina CPU operuje pod dvěma mody, mód jádra (kernel mode) a mód uživatele (user mode). V kernel mode CPU provádí veškeré instrukce své instrukční sady a používá veškerých prostředků hardware. Operační systém (resp. jádro operačního systému - kernel) je ve své podstatě software, který běží v kernel mode a zajišťuje přístup k celému hardware. Uživatelské programy naproti tomu běží v user mode; přičemž mají povoleno používat pouze podmnožinu instrukcí a mají omezený přístup k prostředkům hardware. Ve své podstatě veškeré instrukce, které zajišťují vstupně/výstupní operace a operace s pamětí, jsou v user mode zakázány. Pokud chce jakýkoliv program používat služby operačního systému, musí provést systémové volání (system call), pomocí něhož předá řízení kernelu. Ten požadavek zpracuje a výsledek předá zpět uživatelskému programu“ [TANENBAUM, str. 22]. Uživatelské programy nepřistupují k hardwarovým zařízením přímo, ale pomocí systémových volání. Kernel tyto systémové volání následně pomocí ovladače zařízení (device driver) překládá na instrukce, kterému to které zařízení rozumí. Typickým případem je čtení a zápis souborů na disk. Operační systém, který tato systémové volání obsluhuje, tak slouží jako abstraktní vrstva mezi programy a hardware. Další z funkcí operačního systému je správa paměti (alokace, dealokace a mapování operační paměti), správa procesů (vytváření, ukončování procesů, jejich monitoring a určování priority běhu) a správa zdrojů – při paralelním běhu více procesů je nutno spravovat konkurentní přístup těchto procesů ke sdíleným zdrojům (disk, tiskárna, síťový interface apod).
14
Jednou z nejdůležitějších funkcí kernelu je již zmiňované čtení a zápis souborů, které probíhá následujícím způsobem: Blokové zařízení (ať již samostatný disk či RAID pole, které je operačnímu systému prezentováno jako jednolité blokové zařízení) je rozděleno na jeden a více logických celků tzv. partition. Na partition je vytvořený souborový systém (filesystem), což je logická struktura souborů a adresářů. Ve své podstatě souborový systém obsahuje dvě základní části – oblast datovou, v níž jsou uložena data jednotlivých souborů, a oblast indexu (FAT u FAT16/FAT32/VFAT/exFAT, MFT u NTFS, inode-table u ext2/3/4 apod.), v níž jsou uloženy informace o těchto souborech (tj. název souboru/adresáře, jeho typ, velikost, informace o umístění souboru v datové oblasti souboru a další atributy). Uživatelský proces přistupuje k souborům a adresářům pomocí abstraktního souborového systému (na Unixu virtual file systém - VFS), který je nezávislý na typu souborového systému nacházející se na dané partition. Pokud chce provést čtení/zápis ze souboru, provede systémové volání a předá řízení kernelu. Kernel toto volání převezme, a pomocí ovladače souborového systému, který se na partition nachází (ext2, XFS, apod.) transparentně překládá požadavek z VFS na instrukce známé ovladači tohoto souborového systému. Pomocí ovladače posléze zjistí oprávnění přístupu k danému souboru a otevře jej pro čtení/zápis. Současně, pokud je to nutné, musí zajistit exkluzivitu pro čtení/zápis tomuto procesu, popřípadě řídit sdílený přístup z jiných procesů. Poté pomocí ovladače souborového systému provede čtení/zápis do jednotlivých bloků souborového systému, a provede aktualizaci indexové oblasti aby se shodovala s datovou oblastí, tzn. zapíše informace o velikosti, vlastníkovi, časové atributy souboru a další. V případě žurnálovacích souborových systémů také obsluhuje tzv. žurnál, což je sekvence změn, které jsou během zápisu prováděny. Pomocí žurnálu se zajišťuje konzistence a atomicita zapsaných dat.[TANENBAUM, od str. 281] S přibývajícími nároky na množství zpracovaných a ukládaných dat došlo k situaci, kdy kapacita pevných disků již nedostačovala a bylo nutné vyvinout metodu, jak tyto data spravovat bez omezení danou velikosti pevných disků. Byl proto vymyšlen koncept správy logických svazků (logical volume management - LVM). Jedná se o další abstrakční vrstvu mezi diskem a souborovým systémem. Pomocí
15
LVM je možné z několika disků vytvořit logický celek, který může být dále rozdělen na logické svazky a ty jsou systému prezentovány jako jednotlivá bloková zařízení, na kterých je možné přímo vytvořit souborový systém. Principelně se toto dá přirovnat k RAIDové úrovni JBOD. Postupem vývoje byly do LVM zakomponovány i další funkcionality, například různé úrovně RAIDu, možnost vytváření atomických obrazů (snapshots) apod. Existují souborové systémy, které již v sobě LVM/RAID funkcionalitu obsahují, např. BTRFS, ZFS a další. Dnešní
počítačové
systémy
mohou
obsahovat
mnoho
redundantních
komponent, ale některé nedokážou být plně redundantní. Například disk či síťové rozhraní může být redundantní; při jeho selhání může funkcionalitu nahradit jiný disk či jiné síťové rozhraní. Pří selhání CPU toto již není tak jednoduché; a to právě z důvodu kdy se kernel operačního systému nedokáže se selháním vypořádat a dojde k selhání operačního systému jako takového; a jediným způsobem je výměna defektního CPU (popř. izolace defektního CPU v případě multiprocesorového systému) a restart operačního systému a návazných služeb. Takovýto výpadek je pak ve své podstatě výpadek celého počítačového systému. Souhrnně můžeme identifikovat chyby hardware, kdy hardwarová komponenta není redundantní, nebo chyba v redundantní komponentě není korektně ošetřena a tato redundantní komponenta nefunguje, dále chyby operačního systému, kdy chybné plánování procesů může zahltit operační systém, může docházet k dead-locku, nebo procesy nenastartují korektně, případně dojde k chybě ve správě paměti apod., a v poslední řadě chyby v middleware/aplikacích – aplikace či middleware běžící v user mode mohou být chybně naprogramované, může docházet k memory leakům, deadlockům v komunikaci popř. jiným chybám aplikace, z nichž se aplikace nedokáže sama vzpamatovat.[SCHMIDT, str. 149] U všech tří případů je ideálním řešením použití clusteringu, popsaného v kapitole 3 popřípadě plné virtualizace, popsané v kapitole 4.
2.7 Middleware Dnešní IT služby jsou natolik komplexní ve své podstatě, že zřídkakdy jsou implementovány jedním programem, či jednou aplikací; ale sestávají se z desítky
16
komponent, které zajišťují jednotlivé funkcionality požadovaného IT systému. Některé z těchto komponent jsou vytvořeny přímo na míru požadavku, který je na IT systém vznesen (jedná se tedy o samostatné aplikace); jiné komponenty zajišťují standardizované funkce v IT systémech. Soubor takových komponent nazýváme middleware. Jejich společným prvkem je standardizace a znovupoužitelnost. „Jedná se tedy o vrstvu softwarových komponent ležící mezi operačním systémem a aplikací, která je nezávislá na dané aplikaci kterou podporuje, současně však vyžaduje specifickou konfiguraci, kterou daná aplikace vyžaduje“ [SCHMIDT, str. 189]. Middleware tedy:
zajišťuje funkce, které nejsou součástí operačního systému
poskytuje nezávislé standardizované služby, které mohou být použity mnoha aplikacemi
musí současně být adaptovány (konfigurovány) pro každou aplikaci a neexistují nezávisle tak jako infrastrukturní aplikace (popsány v kapitole 2.9.
Jsou případy, kdy se rozdíly mezi infrastrukturní aplikací stírají. Příkladem může být např. mail gateway, která může fungovat jako infrastrukturní aplikace v případě, že se např. jedná o samostatnou gateway zajišťující zpracování odchozích a příchozích emailů např. ve firemní síti. Ta samá gateway může být ale jako jedna z komponent middleware v případě, že aplikace postavená na middleware používá funkce dodávané mail gateway komponentou a tato komponenta je konfigurována výhradně pro tyto aplikace/middleware. Obecně známe následující typy různé typy software, které můžeme definovat jako middleware. Databázové servery zajišťují databázové služby, tzn. přístup k datům, která jsou uložena v databázových tabulkách. Veškeré operace nad databází jsou prováděny v transakcích, které zajišťují ACID (Atomicity/Consistency/Isolation/Durability) princip. Současně jsou vytvářeny tzv. undo a redo logy, pomocí kterých je atomicita zajištěna; undo logy zachycují stav před potvrzením transakce, redo logy zachycují stav po potvrzení transakce. Typickým příkladem databázového serveru je Oracle Database, MS SQL server, MySQL a další. Webové servery zajišťují uživatelský přístup k webové aplikaci pomocí značkovacího jazyka HTML pomocí HTTP/S protokolu, případně zajišťují přístup k nestrukturovaným binárním datům jako např. dokumenty či streamované služby. Typickým příkladem je MS Internet Information Server,
17
Apache webserver, Nginx server a další. Aplikační servery obsahují soubor komponent, které zajišťují business logiku aplikace, jsou znovupoužitelné a standardizované. Současně poskytují framework, pomocí kterého je aplikace naprogramována a také poskytují běhové prostředí, v kterém je aplikace nasazena, a bez kterého aplikace nemůže existovat. Typickým příkladem je Oracle Weblogic či GlassFish server. Servery zasílání zpráv (messaging servers) zprostředkovávají přenos stukturovaných či nestrukturovaných zpráv pomocí standardizovaného interface. Hlavní funkcí je umožnit přenos informací mezi na sobě nezávislými systémy a současně zajistit bezproblémové předání těchto informací bez jejich ztráty. Díky tomu není nutné tuto funkcionalitu řešit na úrovni aplikace. Typickým příkladem je IBM Websphere MQ či RabbitMQ. Transakční manažery umožňují aplikaci (či vícero aplikacím najednou) zpracovávat data v transakčním režimu; tzn. zabezpečit, že všechny akce buď budou vykonány a transakce skončí úspěšně, popř. nedojde k správnému vykonání všech akcí a transakce skončí neúspěšně a systém je následně uveden do výchozího stavu před spuštěním této transakce. Dnes jsou většinou transakční managery součástí aplikačních serverů. Podobně jako u operačních systémů se HA schopnosti nejčastěji zajišťují pomocí clusteringu.
2.8 Aplikace Všechny doposud popsané komponenty IT systému jsou nosným pilířem, které umožňují běh software, pomocí něhož uživatelé s IT systémem komunikují a který nazýváme aplikace. Uživatele nezajímá úroveň dostupnosti hardware a operačního systému, datových úložišť a middleware, uživatele zajímá dostupnost aplikace jako takové, a která je na těchto komponentech nižších úrovní závislá. Musíme proto pokud možno volit takové aplikace, které umožňují využívat HA schopnosti komponent, na kterých je aplikace postavena. Při výběru aplikace jsme tudíž omezeni na tři případy. V případě hotových (off-the-shelf) aplikací se jedná o běžně dostupné aplikace, které se pouze nainstalují a nakonfigurují; není k nim dodáván zdrojový kód a nelze je tedy měnit. Při výběru takovéto aplikace musíme klást důraz na HA schopnosti, které poskytují, popřípadě kompatibilitu s komponenty nižších úrovní, na kterých je aplikace závislá. U modifikovatelných aplikací (buy-and-modify) je
18
dodáván zdrojový kód a a jejich součásti jsou modifikovatelné programátory (ať již interními v rámci organizace, či externími ve formě outsourcingu), popřípadě je možné nad aplikací (mající uzavřený kód, ale poskytující adekvátní API) dovyvinout požadované funkcionality. Stejně jako v předchozím případě je nutné vzít při výběru potaz na kompatibilitu s HA řešením nižších úrovní; a v případě že aplikace není kompatibilní, je mnohdy možné její úpravou dané kompatibility dosáhnout. Posledním případem jsou aplikace vytvořené na míru. Takovéto aplikace organizace vyvine na míru svým požadavkům; vývoj je prováděn buď vlastními prostředky nebo je outsourcován. Je nasnadě, že při takovéto volbě můžeme již od začátku vývoje zajistit požadované HA funkcionality; nevýhodou ovšem jsou vysoké náklady na vývoj, testování a následnou podporu, která musí být k dispozici během celého životního cyklu aplikace a může tak tvořit nezanedbatelnou složku nákladů na IT systém. Nejhorší situace nastává, kdy náklady na vývoj vlastního software jsou neúměrně vysoké a trh neposkytuje aplikace prvních dvou typů se schopností pokrýt HA požadavky, které na IT systém máme. V takovém případě je nutné znova zvážit, nakolik je možné IT systém implementovat v HA režimu a případně akceptovat rizika, vycházející z nekompatibility aplikace a spolehnout se pouze na HA schopnosti nižších vrstev. [SCHMIDT, str. 215] V případě aplikace se snažíme primárně zajistit HA schopnost spoluprací s HA schopnostmi nižších vrstev, ať již pomocí middleware či operačního systému.
2.9 Infrastruktura Pod pojmem infrastruktura rozumíme soubor softwarových a hardwarových komponent, který je používán aplikacemi, middleware, operačním systémem a hardwarem; ale nejsou nedílnou součástí, naopak, existují mimo ně jako samostatné jednotky poskytující podpůrné služby. Těmito komponentami se rozumí především:
síť a hardwarové prostředky zajišťující provoz sítě
infrastrukturní síťové služby
síťové datové úložiště
systémy zálohování a obnovy
monitoring
19
Síť a hardwarové prostředky zajišťující provoz sítě Datové sítě jsou jednou ze základních komponent IT systémů; zajišťující propojení jednotlivých počítačů v rámci lokální sítě (LAN) a spojení uživatelů s aplikací v případě aplikačního modelu klient/server. Základem datové sítě je komunikační protokol využívající fyzickou strukturu sítě (kabeláž, aktivní a pasivní síťové prvky). Aby bylo možné systémy provozovat nezávisle na síťové topologii, bylo nutné vyvinout model, kdy jednotlivé komunikační mechanismy aplikací jsou nezávislé na přenosovém médiu. Tento model se nazývá OSI model (viz Obrázek 2); a definuje 7 úrovní, kdy každá úroveň vyšší vrstvy zajišťuje komunikaci pouze s úrovní nižší vrstvy.
Obrázek 2 - Diagram OSI modelu. Zdroj: http://tri-tel.com/wpcontent/uploads/sites/94/2013/10/osi_model.jpg
Na nejnižší úrovni (physical, data-link) se dnes používají tři základní technologie – ethernet, fibre channel a infiniband. „Ethernet je dnešní de-facto standard v LAN, používá CSMA/CD techniku, kdy ke sdílenému médiu přistupuje jeden a více prvků sítě.“ [STALLINGS, str. 472]. Každý prvek může vysílat data ve formě rámců (ethernet frame) o maximální délce 1500 byte kdykoliv chce a to pomocí jednoduchého harmonogramu: 1. pokud je médium nepoužívané, prvek může vysílat 2. pokud je médium používané, prvek naslouchá na médiu a vysílá jakmile se médium uvolní 20
3. v případě, že dva prvky začnou vysílat najednou, dojde k tzv. kolizi, tato je detekována a prvky po náhodně zvoleném čase se pokusí vysílat znova Protože se jedná o sdílené medium, je nutno identifikovat adresáta vysílaného frame; a proto je v hlavičce každého frame nutno uvést, kterému prvku je daný rámec adresován pomocí tzv. MAC adresy. Tento jej přečte; zatímco ostatní jej ignorují. Aktuálně jsou definované standardy pro 100Mbit, 1Gbit a 10Gbit Ethernet. Zařízení na ethernetové síti jsou mezi sebou pospojovány pomocí hardwarových zařízení pasivních prvků (hub) a prvků aktivních (switch). „Fibre channel je síť vyvinutá s důrazem na rychlost, výkonnost a odolnost a která poskytuje dvě základní služby. Službu I/O kanálu, umožňující přenášet data mezi buffery jednotlivých zařízení bez ohledu na to o jaká data se jedná; a současně schopný podporovat stávající architekturu I/O kanálů, např. již výše popsaný SCSI, a síťovou službu, která umožňuje multiplexovat datový tok mezi vícero zařízení, zajišťuje peer-to-peer konektivitu mezi jednotlivými porty (tzn. zařízeními) a schopnost kooperovat s komunikačními protokoly na vyšších vrstvách OSI modelu. Klíčové elementy fibre channelu jsou koncová zařízení, tzv. nodes; a síť samotnou, která se skládá z jednoho či více přepínačů (fabric switch) a nazýváme jí fabric.“ [STALLINGS, str. 499] Komunikace pak probíhá v peer-to-peer režimu mezi jednotlivými nody a switchi. Fibre channel se nejvíce používá pro průmyslové datové úložiště (SAN) a to hlavně pro svou schopnost mapovat SCSI protokol přímo na fibre channel rámce (daný počítač tak přistupuje k logickému disku v SAN systému stejně jako kdyby byl připojený lokálně), a současně pro schopnost multiplexování, kdy umožňuje existenci více než jedné cesty mezi počítačem a SAN úložištěm. „Infiniband je vysokorychlostní datová síť, která přímo nahrazuje (či je komplementem) systémové sběrnice v počítači. Umožňuje tak fyzicky oddělit jednotlivé hardwarové komponenty – např. HBA se může nacházet úplně vně počítače a to přímo jakou součást SAN serveru. Jeho největší výhodou je nízká latence, nízké využití CPU a vysoké přenosové rychlosti hlavně díky tzv. RDMA (Remote Direct Memory Access) – tedy přímému přístupu do stránek paměti počítače podobně jako to dělají hardwarové komponenty počítače“ [TROPPENS, str. 122].
21
„Vedle výše uvedených existuje ještě fibre channel over ethernet (FCoE). Ten umožňuje používání ethernetu jako přenosové technologie pro FibreChannel služby.“ [TROPPENS, str. 126]. Na síťové úrovni OSI modelu je dnes nejpoužívanější Internet Protocol (a jeho komplementy na úrovni transportní vrstvy, TCP a UDP) popřípadě jeho novější verze IPv6. Data na této vrstvě jsou přenášena pomocí datagramů, které obsahují zdrojovou adresu, cílovou adresu, informace o fragmentaci, informaci o životnosti datagramu (TTL) a v případě TCP i informace o opravě chyb a kontrole toku. Jednotlivé datagramy jsou mezi sítěmi směrovány pomocí tzv. směrovačů (routerů), přičemž každý router si udržuje interní informace o tom, do jakých sítí má směrovat datagramy ze skupiny cílových adres (tzn. daného IP subnetu). Každé zařízení v IP síti má přidělenou jednu či více IP adres o délce 32 bitů (v případě IPv6 o délce 128 bitů). Vedle transportních protokolů TCP a UDP existují ještě další protokoly nad IP, sloužící k servisním ůčelům IP sítě – IGMP a ICMP. Mapování IP protokolu na protokoly nižší vrstvy se děje pomocí ARP protokolu, který přiřazuje IP adresám síťové vrstvy MAC adresy v ethernetu. Na nejvyšší třech vrstvách OSI modelu se nachází relační (session), prezentační
a aplikační vrstva, pomocí níž jednotlivé aplikace mezi sebou
komunikují. Příkladem aplikační vrstvy je např. HTTP protokol sloužící přenos webového obsahu; příkladem prezentační vrstvy je např. SSL protokol sloužící k šifrování dat. Relační vrstva zajišťuje organizaci a synchronizaci komunikace – příkladem je např. NetBIOS či RPC. Infrastrukturní síťové služby Jedná se o soubor služeb, které zajišťují určitou funkci v rámci lokální sítě. Typickým představitelem je např. NTP,
který umožňuje klientům v síti
synchronizovat přesný čas; či DNS, který slouží k překladu lehce zapamatovatelných doménových názvů na IP adresu. Síťové datové úložitě (SAN/NAS) SAN/NAS sítě rozšiřují koncept datových úložišť popsaných v kapitole 2.5 tím, že poskytují centrální úložiště dat pro jednotlivé počítače. SAN/NAS úložiště je specializované hardwarové zařízení, které obsahuje velké množství pevných disků a pomocí specializovaného firmware poskytuje přístup klientům k těmto diskům. 22
Klienti jsou současně odstíněni od samotné konfigurace SAN/NAS úložiště, tzn. nemají informace o počtu disků, zajištění ochrany dat apod. Je tak aplikován jeden z HA principů – virtualizace. Samotné úložiště zajišťuje pomocí vlastních prostředků dostupnost dat, např. implementací různých úrovní RAIDu, duplikací řadičů, integrovaným zálohovacím systémem, systémem ochrany proti výpadku napájení (UPS), redundantní připojení do LAN a další. SAN (storage area network) úložiště funguje následovně: pomocí firmware (obsažen v SAN zařízení) jsou definovány logické jednotky (tzv. LUN), které jsou poté exportovány jako blokové zařízení. Komunikace s těmito jednotkami je zajištěna implementaci již výše zmíněného SCSI protokolu, který je mapován přímo na fibre-channel síť případně přes SCSI mapovaný na Internet Protocol (iSCSI). Klient připojí pomocí identifikátoru LUN dané blokové zařízení přímo v rámci operačního systému a přistupuje k nim jako k lokálnímu disku. Nevýhodou takového připojení je exkluzivita daného LUN pro klienta, který jej používá, popřípadě v připojení vícero klientů je nutné použít synchronizační mechanismus na straně klientů; jedině tak je možné dosáhnout integrity dat. Výhodou je vysoká rychlost a také možnost použít jakýkoliv souborový systém, protože ten je vytvořen na straně klienta, který k LUN přistupuje. NAS (network attached storage) naproti tomu neexportuje blokové zařízení jako samostatný LUN, ale exportuje souborový systém, který je na daném LUN již vytvořený. Klienti tedy nepřistupují k blokovému zařízení, ale jako k vzdálenému souborovému systému. Typickým příkladem je NFS používaný na Linuxech/Unixech nebo Samba/CIFS, používaný na Windows. Samotná synchronizace je zajišťována na úrovni úložiště; klienti ale musí zajistit, aby daná data nebyly mezi klientem a úložištěm cachovány, jinak je ohrožena konzistence dat Typickým představitelem SAN/NAS zařízení je např. NetApp Fabric-Attached Storage od firmy NetApp, či ZFS Storage Appliance od firmy Oracle. Systémy zálohování a obnovy Nutnost zálohování dat vychází nejenom z požadavků business continuity, ale i z požadavků právního rázu (zákonná retence dat). Zálohovací a obnovovací služby je možno implementovat jak vlastními silami (pomocí skriptů, snapshotů na úrovni LVM a jejich následných odzálohování mimo dané zařízení), tak pomocí standardizovaných dostupných nástrojů a to jak softwarových (specializovaný 23
software, např. Veritas Backup) tak hardwarových (specializovaná kazetopásková zařízení – tape silo). Monitoring Bez pravidelného monitoringu se moderní IT systém neobejde; správci systémů musí v kteroukoliv dobu znát stav všech komponent v systému, jejich výkonnost a dostupnost a současně v případě výpadku komponent či jejich snížené výkonnosti musí být náležitými kanály informováni. Bez monitoringu není např. možné zjistit, zdali systém vyhovuje míře dostupnosti definované v SLA. Monitoring je řešen specializovanými
softwarovými
prostředky
buď
proprietárním
nebo
standardizovaným způsobem (např. pomocí SNMP protokolu). Příkladem takového software je Nagios, Oracle Enterprise Manager Grid Control nebo HP OpenView. V případě infrastruktury zajišťujeme HA schopnosti buď úplnou redundancí, nebo clusteringem. V některých případech jsou tyto již ze své podstaty redundantní – příkladem může být DNS, kdy v rámci LAN může existovat více než jeden DNS server, který poskytuje stejnou funkcionalitu, a tyto servery jsou na sobě naprosto nezávislé.
24
3 Clustering jako ideální řešení pro HA Jak jsem již uvedl v kapitole 2.3, jeden z hlavních způsobů řešení HA je použití redundance. Vycházíme zde z principu, kdy každý prvek systému (ať se jedná o operační systém, middleware či datové úložiště), který může být SPOF, může být v případě výpadku nahrazen prvkem poskytující stejné funkcionality. Tento princip se nazývá clustering. Z pohledu HA je ideálním řešením takového stavu použití redundance na úrovni jednotlivých počítačů nesoucí sebou operační systém, middleware a jednotlivé aplikace. Zvýšíme tedy dostupnost pomocí redundance na úrovni jednotlivých počítačů tak, že sdružíme několik počítačů se stejným operačním systémem a službou (případně souborem služeb) do skupiny - clusteru, přičemž daná služba není vázána na specifický počítač, ale je zajišťována více počítači najednou. Každý takový počítač pak nazýváme uzlem clusteru (cluster node). Cluster je možné implementovat ve dvou variantách:
failover (high-availability) cluster – služby v případě výpadku jednoho počítače jsou zmigrovány na jiný počítač, kde jsou nastartovány
load-balancing cluster – služby jsou poskytovány na vícero počítačích současně, konzumenti služeb adresují služby volbou z jednoho z počítačů [VAN VUGT, str. 2]
Problémem clusteringu je skutečnost, že operační systém nemá žádné informace o druhu služeb, které jsou poskytovány. V případě bezstavových služeb se nejedná až tak o velký problém - např. u mail-gateway v případě přerušení komunikace klient znova naváže spojení, tentokrát s jiným serverem v clusteru, a email se podaří odeslat. V případě stavových služeb, jako např. připojení k databázi, dojde při přerušení spojení k ztrátě stavových informací dané relace (session); o tomto ale operační systém nemá žádné znalosti a není možné z jeho pohledu se s touto situací vypořádat. Z tohoto důvodu je nutno tento problém řešit na úrovni uživatelského procesu – např. v databázi po restartu operačního systému dojde v rámci obnovy z havárie k roll-backu započaté transakce. Otázkou tedy je, pro které typy služeb se více hodí failover cluster a pro které typy se hodí load-balancing cluster. Odpověd na ní se skrývá v software, který běží 25
jako uživatelský proces nad daným operačním systémem. V obecné rovině failover cluster je nutné použít tam, kde si aplikace drží stavové informace či používají relace (stateful aplikace) a nemají současně žádnou schopnost synchronizace mezi stejnou aplikací na jednotlivých fyzických počítačích; typickým příkladem je většina databázových systémů. Pokud se jedná o aplikace, kde není nutno udržovat stavové informace (stateless), je možné použít load-balancing; je tedy ideálním řešením např. pro webservery. Obrázek 3 ukazuje příklady typů aplikací a použití dvou různých typů clusteringu.
Obrázek 3 - Příklady aplikací pro fail-over a loadbalancing. Zdroj: SCHMIDT, str. 151
Při vytváření failover cluster řešení je nutné zajistit nezávislost na hardware; je tedy nutné zajistit aby v případě aktivace záložního systému byl tento systém schopen číst stejná data, používat stejnou IP adresu apod., jako původní systém, který zhavaroval. Proto je nutné oddělit aplikační prostředí od závislosti na operačním systému, a pokud možno oddělit závislost operačního systému na hardware. V druhém případě se tohoto dosahuje pomocí úplné virtualizace operačního systému; v případě havárie jednoduše spustíme obraz virtualizovaného operačního systému na jiném hardware (toto řešení je aplikovatelné v případě 26
active/passive clusteru; je nutné ale brát na paměti, že obraz virtuálního disku se nesmí nacházet na daném hardware, ale mimo něj, ideálně na SAN úložišti). V prvním případě je problém složitější – je nutné identifikovat, které zdroje daná aplikace používá, a tyto pokud možno oddělit od daného operačního systému. Příkladem může být závislost aplikace na datech uložených v souborovém systému či discích – pro tento případ použijeme řešení, kdy aplikace neukládá data na počítači, na kterém běží, ale na externím datovém úložišti (NAS/SAN). U failover clusteru rozeznáváme dva typy - active/passive a active/active cluster. Active/passive failover cluster je řešení, kde na daném počítači je poskytována pouze jedna služba, u které předpokládáme plné využití hardware, a který nemá být sdílen s žádnou jinou službou, protože by mohlo dojít k degradaci výkonu. Zde záložní počítač není vůbec využíván do té doby, než je na něj služba převedena. Takovéto řešení se také nazývá hot-spare či hot-standby. U active/active failover clusteru běží jak na primárním tak záložním počítači více různých či stejných služeb. V případě výpadku primárního počítače pro danou službu tato přemigruje na záložní počítač, který může být ale primárním počítačem pro službu jinou. Toto řešení je ideální v případě, kdy souběžný běh služeb nebude mít dopad na jejich výkonnost.[SCHMIDT, str. 154]
Obrázek 4 - Schéma active/active a active/passive clusteru. Zdroj: SCHMIDT, str. 156
Společným znakem failover clusterů je nutnost monitoringu a pokud možno automatizace převodu služeb; je nutné identifikovat stav, kdy daná služba popř. celý systém neplní svou roli a je nutné provést přesun služeb na jiný počítač. Toto je často realizován pomocí specializovaného cluster software, který zajišťuje jak monitoring,
27
tak proces přepnutí na záložní systém (tzn. failover). Celý proces je tak možné shrnout do následujících bodů: 1.
monitoring (zajišťuje cluster software) průběžně vyhodnocuje správnou funkcionalitu služby (tzn. dostupnost, chybovost či výkonnost)
2.
v případě, že daná služba neplní požadovanou úroveň funkcionality, je iniciován failover proces, kdy daná služba při chybovosti či sníženém výkonu je na primárním systému zastavena
3.
cluster software provede start služby na záložním systému, případně přemigruje lokální zdroje, které služba používá, z primárního systému na záložní
4.
poté, co je primární systém opět uveden do funkčního stavu, cluster software ukončí poskytování služeb na záložním systému a tyto služby přemigruje zpět na primární systém (fallback). Mnohdy se tento krok nepoužívá, namísto toho se předpokládá, že aktivovaný záložní systém se stává automaticky systémem primárním a z původně primárního systému se stává systém záložní
Ač se řešení failover clusteru zdá být ideálním, naráží zde na některé limity, které mohou zapříčinit úplný výpadek služby. Failover cluster může být závislý na sdíleném datovém úložišti - konzistence těchto dat na daném úložišti může být považována za SPOF.
Clusterovací systém zajišťuje správu jednotlivých uzlů v
clusteru; v případě chyby v něm dojde většinou k výpadku celého clusteru. Jedná se zde opět o SPOF. V případě, že komponenty neumožňují běh v cluster konfiguraci, nemá smysl pro ně navrhovat jakýkoliv failover cluster; jsou potom považovány za SPOF a je nutné je řešit jiným způsobem. V případě opravy, údržby, patchování či upgrade clusterovacího systému je prováděna údržba na všech počítačích v clusteru; při chybné údržbě, instalaci chybného patche či chybném upgrade může dojít k znefunkčnení celého systému. Málo clusterových techonologií umí aplikovat patche v rolling-patch / rolling-upgrade módu, což je případ, kdy jednotlivé uzly v clusteru fungují na jiné verzi software/patche.[SCHMIDT, str. 156]
28
Load-balancing cluster se uplatňuje nejvíce v případech, kdy daná služba nepoužívá žádné stavové či relační informace; tzn. při každém dotazu klienta vůči serveru dané služby je vytvořeno nové spojení, během kterého je požadavek vyřízen a spojení je ukončeno. Každé další nové spojení je nezávislé na předchozím. Současně musí být zajištěna nezávislost jednotlivých nodes v clusteru, tzn. klient nerozlišuje, na který node z clusteru se připojí - všechny nody v clusteru poskytují naprosto stejné služby. Typickým představitelem jsou webové služby, u nichž je HTTP požadavek ve své podstatě bezstavový, a tak může při každém požadavku být distribuován na kterýkoliv webserver v clusteru. Toto je použitelné hlavně v případě, kdy všechny webservery v clusteru poskytují statický obsah (tzn. obsah na dané URI je neměnná při každém požadavku). V případě dynamického obsahu, kdy obsah je generován jako výstup z databáze či aplikačního serveru, je použití load-balancingu většinou nemožné a musíme se spolehnout na load-balancing cluster na úrovni middleware případě použít failover-cluster. Dalším představitelém jsou adresářové služby – např. DNS nebo LDAP. Společnou vlastností těchto služeb je časté čtení dat a zřídkakdy jejich změna. Synchronizace dat je povětšinou zajišťována softwarem, který danou službu poskytuje (případně manuálně) a každá služba v rámci loadbalancingu může poskytovat data na sobě naprosto nezávisle.[SCHMIDT, str. 177] Kromě zajištění dostupnosti služeb je další z výhod load-balancingu schopnost distribuovat požadavky klientů na všechny nody v clusteru. Díky tomu je možné rovnoměrně rozprostřít zátěž mezi jednotlivé nody a zvýšit tak výkonnost dané služby. Při implementaci load-balancing řešení musíme brát v úvahu celý systém; například v případě dynamického webového obsahu samotný HTTP protokol je bezstavový, ale obsah je generován pomocí databázového či aplikačního serveru, který již může být stavový. Toto je nutné brát v potaz při návrhu celé architektury systému. Load-balancing můžeme implementovat následujícími způsoby:
load-balancing založený na transportní vrstvě IP
load-balancing založený na reverzní proxy
load-balancing založený na DNS
U prvního způsobu se klient nepřipojuje na službu přímo ale na router, za nímž cluster leží. Ten interně přemapuje požadavek pomocí NAT na jednotlivé nody clusteru. U reverzní proxy se klient opět nepřipojuje přímo na službu, ale na
29
specializovaný software, který umožňuje přeposílání požadavků na jeden z nodů v clusteru. Jedná se o load-balancing na aplikační úrovni, tzn. proxy musí umět komunikovat na stejném aplikačním protokolu, jako služba, kterou klient poptává. U posledního způsobu využíváme možnosti, kdy k danému doménovému jménu (hostname) můžeme přiřadit vícero IP adres; na které toto jméno budeme překládat; přičemž každá IP adresa reprezentuje jeden node v clusteru. Klient, který se na systém připojuje, při každém novém požadavku na DNS server obdrží soubor IP adres a použije první IP adresu v tomto souboru. Sekvence těchto IP adres se při každém DNS požadavku mění tak, aby byly postupně všechny adresy ze souboru použity. Tento přístup se nazývá round-robin. V prvních dvou případech load-balancingu ale zavádíme do systému další potenciální SPOF (router a reverzní proxy), které je nutno řešit; povětšinou se takto děje pomocí failover-clusteru. U DNS load-balancingu toto není nutné řešit, protože ze své podstaty v sobě DNS obsahuje failover řešení – každý DNS záznam by měl být zaveden jak v primárním tak v jednom a více sekundárních DNS serverech [RFC 2182]. U IP a reverse proxy load-balancingu se namísto software často používají specializovaná hardwarová zařízení, které pokrývají i další funkcionality, např. vzdálenou správu, monitoring, firewall apod. Typickým příkladem je např. BigIP od firmy F5 Networks nebo NetScaler od firmy Citrix. V praxi se mnohdy používá řešení, které v sobě zahrnuje jak load-balancing, tak failover cluster. V tomto případě zde narážíme na problematiku sdílení zdrojů; clusterovací software musí zajistit jak správu dostupnosti služeb, tak současně synchronizovat přístup k těmto sdíleným zdrojům. K tomuto se používá několika praktik [SCHMIDT, str. 160; GOPALAKRISHNAN, str. 56]. Cluster software, který běží na všech počítačích poskytujících danou službu, pravidelně kontroluje dostupnost jak jednotlivých služeb, tak funkcionalitu clusterového software na těchto počítačích; tato činnost je kontrolována pomocí neustálého dotazování se všech nodů v clusteru a nazývá se heartbeat. Toto je řešeno většinou pomocí datového připojení (tzv.
interconnect),
např.
pomocí
LAN,
případně
sekundárně
pomocí
specializovaného souboru či blokového zařízení na sdíleném datovém úložišti (tzv. quorum device). Může ale dojít k situaci, kdy je spojení interconnectu přerušeno a jednotlivé nody nemají informaci o stavu dostupnosti mezi sebou (tzv. split-brain syndrome). Zde se uplatňuje tzv. fencing, který zajistí izolaci daného node z clusteru
30
a současně ochranu sdílených prostředků před jejich nekorektním použitím např. neočekávaným konkurentním přístupem. Jeden ze způsobů fencingu je tzv. ST(O)NITH (Shoot The (Other) Node In The Head); kdy node, který opustí cluster, si je vědom nemožnosti synchronizovat přístup ke sdíleným zdrojům; a proto okamžitě přeruší veškeré vstupně/výstupní operace a provede okamžitý reboot či vypnutí systému; popřípadě ostatní přeživší nody eliminují nefunkční nude z clusteru – např. pomocí vzdáleného vypnutí pomocí IPMI interface či odříznutím síťové komunikace na switchi. Přeživší nody v clusteru se poté musí s touto situací vyrovnat použitím různých řešením, např. v případě databázového clusteru musí zpracovat undo a redo logy již nedostupného node, aby byla zajištěna konzistence dat v databázi.
31
4 Virtualizace a její použití v rámci HA V předchozí kapitole jsem pokryl jeden ze způsobů jak zajistit HA – redundanci. Poslední dva, robustnost a virtualizace, spolu úzce souvisí. Jak jsem již uvedl, robustnost IT systému zajistíme oddělením jednotlivých služeb do samostatných subsystémů, které zajistí požadovanou funkcionalitu, např. vyčleněním webserverů do samostatného clusteru, použitím specializovaného software či zařízení pro routing/load-balancing a jeho uzpůsobení do active/pasive failover clusteru. Toto nám ale neřeší problém závislosti jednotlivých složek technology stacku dané služby na sobě; tzn. například závislosti middleware na operačním systému. Pokud chceme oddělit jednotlivé vrstvy v rámci jedné služby musíme se uchýlit k jinému řešení a tou je virtualizace zdrojů. Virtualizací obecně rozumíme oproštění se od reálných komponent a jejich fyzických závislostí; namísto toho zavedeme jejich abstrakci. V případě virtualizace zdrojů se snažíme o jejich vzájemnou nezávislost v rámci technology stacku. Tzn. se snažíme např. oddělit závislost middleware od operačního systému na daném počítači a zajistit jeho přenositelnost na počítač jiný co nejjednodušším způsobem. V praxi se používá několik virtualizačních technik:
4.1 Virtualizace hardware „Tato technika nám umožňuje oddělit fyzický hardware od operačního systému za pomocí tzv. hypervizoru resp. Virtual Machine Monitor“ [TANNENBAUM, str. 472]. Jedná se o specializovaný software, který je na počítači nainstalován namísto operačního systému. Tento funguje jako hostitel pro tzv. virtuální stroje (Virtual Machine), v nichž je možné operační systém nezávisle provozovat. Každý virtuální stroj má k dispozici předdefinovaný set zdrojů (počet CPU, velikost RAM, virtuální pevné disky apod.), který operační systém používá transparentně stejným způsobem, jako kdyby byl spuštěn na fyzickém hardware. Operační systém tedy nepřistupuje přímo k fyzickému hardware, ale pomocí hypervizoru, který odchytává systémové volání a překládá jej dále na hardware, nad nímž běží. Výhodou je, že při poruše počítače, nad nímž hypervizor běží, je možné virtuální počítač přesunout na hypervizor běžící na jiném počítači a tam jej spustit (tento proces se nazývá 32
teleporting); při tomto je ale nutné zajistit, aby virtuální disk, který operační systém používá, byl umístěn mimo hardware, např. na SAN/NAS úložišti. Další výhodou je možnost sdílení jednoho fyzického počítače vícero virtuálními počítači, což přispívá ke snížení nákladů. Typickým představitelem takovéto virtualizační techonologie je VMWare GSX server nebo Oracle Virtualbox. Z pohledu HA architektury zde identifikujeme hypervizor a hardware jako SPOF, který je nutné řešit.
4.2 Virtualizace v rámci operačního systému „Úlohou operačního systému je mimo jiné řídit přístup ke hardwarovým zdrojům a správa procesů. Uživatelské procesy, spuštěné pod operačním systémem, mají pomocí systémových volání přístup ke všem hardwarovým zdrojům, které daný operační systém spravuje. Může tedy např. dojít ke stavu, kdy chybně naprogramovaný software si pro sebe alokuje takové množství paměti, že tím omezí nebo znemožní chod ostatním procesům. Řešením je použití tzv. kontajnerů, pomocí nichž vymezíme zdroje (RAM, počet jader CPU, CPU time apod.) a v tomto kontajneru aplikaci spustíme. I když aplikace sdílí zdroje operačního systému s jinými aplikacemi běžící mimo tento kontajner; aplikace uvnitř kontajneru může používat zdroje operačního systému pouze do takové míry, jaké jsou jí kontajnerem povoleny. Výhodou oproti virtualizaci hardware je sdílení operačního systému a tím nižší náklady na správu i chod.“ [SCHMIDT, str. 186] Typickým představitelem je zde Linux Containers, Solaris Zones nebo FreeBSD Jails. Kombinací kontajnerů a specializovaného software (např. Docker) lze docílit velice jednoduché instalace a konfigurace aplikací a současně zajistit přenositelnost mezi jednotlivými běžícími operačními systémy. Operační systém, v rámci kterého kontajnery běží, se dá považovat za SPOF.
4.3 Virtualizace datových úložišť V tomto případě se snažíme zrušit závislost souborového systému, na němž jsou umístěna data, od hardware, na kterém se souborový systém nachází (např. pevného disku). Jeden ze způsobů je použití již zmíněného LVM, který umožňuje transparentně přesouvat logická bloková zařízení, které nesou souborový systém,
33
mezi jednotlivými disky v počítači. Ještě vyšší úrovni virtualizace docílíme pomocí SAN, kdy data nenachází na samotném počítači, ale na SAN úložišti, který pomocí jednoznačného identifikátoru (LUN) poskytuje virtuální blokové zařízení, které počítač připojí pomocí sítě (iSCSI/fibrechannel), popřípadě SAN úložiště samotné poskytuje NAS služby, díky nímž počítač přímo připojí sdílený souborový systém (NFS/CIFS). [TROPPENS, str. 162]. Při kombinaci SAN/NAS úložiště a virtualizace operačního systému dosáhneme tak ideálního stavu, kdy počítačový hardware s nainstalovaným hypervizorem je vpodstatě pouze běhové prostředí, které je možné kdykoliv zaměnit při jeho poruše. Daný SAN je zde pak považován za SPOF.
Obrázek 5 - Princip virtualizace úložiště. Zdroj: [TROPPENS, str. 162]
34
4.4 Virtualizace na úrovni sítě OSI model popsaný v kapitole 2.9 sám o sobě umožňuje separaci síťové vrstvy (IP) od fyzické/data-link vrstvy (ethernet) a to pomocí ARP protokolu, který mapuje IP adresu na MAC adresu ethernet adaptéru v počítači (MAC adresa je
napevno
zapsaná ve firmware adaptéru a často ji není možné změnit). Tím se vpodstatě stává sama IP adresa virtuálním zdrojem, který je možné libovolně přenášet mezi ethernet adaptéry. Pokud bychom chtěli ale oddělit funkcionalitu ethernetu od fyzického adaptéru, je toto možné pouze vytvořením virtuálního ethernetového adaptéru. Toto zařízení potom spřažíme s fyzickým adaptérem do tzv. bondu; který replikuje ethernetové rámce mezi virtuálním a fyzickým adaptérem. „Z hlediska HA je nejzajímavější ten typ bondingu, kdy dva fyzické adaptéry (kde každý je na samostatné LAN) spřažíme k jednomu virtuálnímu adaptéru a na něj mapujeme IP adresu; zde je možné poté použít oba fyzické adaptéry ať již pro zvýšení přenosové rychlosti, či zálohování cesty – v případě výpadku jednoho fyzického adaptéru existuje stále aktivní cesta pomocí druhého fyzického adaptéru“ [VAN VUGT, str. 28]. Další možností, jak virtualizovat síťové prostředky je použití tzv. VLAN (Virtual LAN). Jak již vyplývá z architektury ethernetu, každý adaptér na dané LAN odchytává rámce, které na LAN prochází. VLAN technologie umožňuje na existující fyzické LAN vytvořit její virtuální podmnožinu, kde u každého ethernetového rámce na LAN síti je navíc přidávaný příznak (tzv. VLAN tag), ke které VLAN daný rámec patří. Adaptér poté nakonfigurujeme tak, že má přístup pouze k těm rámcům, jejichž VLAN tag se shoduje s tagem, který je v adaptéru nakonfigurovaný. Toto je vhodné hlavně v případe, kdy chceme z bezpečnostního hlediska jednotlivé VLAN od sebe oddělit, popř. při propojení vícero LAN pomocí switche/bridge chceme omezit přenos jednotlivých rámců z jedné LAN do druhé.
4.5 Virtualizace služeb Klienti přistupují ke službám typu klient/server pomocí jednoznačně určeného bodu přístupu. Tím může být např. u webového serveru URL, v případě mailserveru doménové jméno či IP adresa. Pokud použijeme jakýkoliv typ clusteringu (ať již
35
failover či load-balancing), musíme klienta odstínit od nutnosti znát, na který node z clusteru se ve skutečnosti připojuje. Tohoto docílíme pomocí virtualizace služby. Nejjednodušší cesta je oddělit závislost doménového jména (registrovaného v DNS) od IP adresy. V případě, že uživatele potřebujeme transparentně směrovat na jiný počítač v clusteru, není nic jednoduššího, než změnit DNS záznam tak, aby nově používal IP adresu požadovaného počítače. Je nutné zde ale upozornit na fakt, že každý záznam v DNS ma tzv. expirační dobu, po kterou je cachován (TTL). V tomto případě je nutné udržovat TTL co nejnižší, aby uživatel byl v požadovaném čase směrován na správnou IP adresu, na které je služba poskytována. Další možností je použítí tzv. virtuální IP adresy; kde služba je vždy provozována na jedné IP adrese, ta může být ale migrována mezi počítači v rámci LAN. Zde je nutné brát v úvahu fakt, že podobně jako DNS používá cachování, tak routery si po určitou dobu udržují interní seznam ARP tabulek zajišťující překlad IP adresy na MAC adresu. Také je nutné se ubezpečit, že dané počítače, mezi nimiž je IP adresa migrována, leží na stejném subnetu. IP based loadbalancing řeší problematiku expirace cache; ale vytváří zde SPOF ve formě routeru, který NAT poskytuje.
Obrázek 6 - Použití virtuální IP - služba je zde mapována na VIP 192.168.2.55. Zdroj: vlastní tvorba
36
5 Ukázková řešení HA systémů Na trhu existuje velké množství systémů, které aplikují HA principy. Některé pokrývají pouze specifickou oblast (datové úložitě, databáze), jiné zase zajišťují HA funkcionalitu celé architektury od aplikační vrstvy až po operační systémy. Jako ukázku jsem zvolil proprietární řešení databázového clusteru (Oracle Exadata Machine) a dále open-source řešení clusteru v rámci operačního systému Linux.
5.1 Oracle Exadata Machine Oracle Exadata Machine je integrovaný systém, který poskytuje služby databáze. Skládá se ze tří navzájem propojených komponent – databázových serverů, síťové infrastruktury a datových úložišť.
Obrázek 7 - Oracle Exadata Machine Zdroj: OSBORNE, str. 20
Principy HA architektury se zde uplatňují na několika úrovních: Databázové servery mohou být nasazeny jak samostatně (bez failover/loadbalancing schopností – single instance) tak v clusteru (Real Application Cluster). 37
Databázové servery využívají Automatic Storage Management clusteru, který zde reprezentuje LVM; samotná bloková zařízení jsou umístěna v datovém úložišti. Cluster managerem je zde Oracle Clusterware (obsažen v balíku Oracle Grid Infrastructure), který zajišťuje failover/loadbalancing pomocí metod virtuálních IP a DNS-based loadbalancingu. Grid Infrastructure také zajišťuje fencing, a to pomocí okamžitého rebootu databázového serveru. HA schopnosti na úrovni síťové vrstvy jsou zajištěny pomocí dvou infiniband switchů, které propojují databázový cluster s clusterem datového úložiště. Inteligentní datové úložiště je zde reprezentováno sadou serverů (cell server), které poskytují přístup k pevným diskům. Jednotlivé servery mezi sebou replikují pevné disky (obdoba RAID technologie) a tím zamezují vzniku SPOF na úrovni datového úložiště. Na rozdíl od klasické implementace tripletu databáze – síť – SAN vyniká Exadata svou schopností přesunout přímo některé databázové operace (SELECT z tabulek) na úroveň inteligentního úložiště. Tím se podstatně redukuje nutnost přenášet veškeré datové bloky z úložišť do databázových serverů – jsou přenášeny pouze relevantní záznamy z tabulek; vyhledávání záznamů je tak prováděno na samotných cell serverech. Toto je realizováno pomocí proprietárního protokolu iDB [OSBORNE].
5.2 Red Hat Cluster Suite RHCS je soubor softwarových komponent běžící pod operačním systémem Linux, a které umožňují zajistit škálování, load-balancing i fail-over. Jedná se o tyto komponenty.
Cluster Infrastructure – software pokrývající funkce cluster manageru (fencing, quorum zařízení, konfigurace clusteru apod.)
High-availability Service Management – zajišťuje failover služeb mezi cluster nody
Cluster Administration Tools – sada nástrojů sloužící k instalaci, správě a monitoringu clusteru
Linux Virtual Server – softwarový router, zajišťující IP based load-balancing
Nástroje zajišťující synchronizovaný přístup k datovým úložištím (volitelná součást) – GFS2, cLVM a GNBD (volitelná součást)
38
Obrázek 8 - Red Hat Cluster Suite Zdroj: RHCSI
39
6 Analýza systému V praktické části bakalářské práce jsem se rozhodl navrhnout a implementovat HA systém pro podporu aplikace Oracle Business Intelligence . Tato aplikace slouží jako analytický a reportingový nástroj pro podnikovou sféru, pomocí níž je možné reprezentovat data z datových skladů popř. z jiných zdrojů. Oracle BI je aplikace typu klient/server a je integrována na platformě Oracle Fusion Middleware, což je kombinace middleware a aplikačního serveru Oracle Weblogic. Jako datovou základnu zde používá Oracle Database 11g. Cílem je tedy HA systém navrhnout a posléze implementovat. Protože nedisponuji potřebným hardware pro servery a síťovou infrastrukturu, využiji zde virtualizace; celý systém je implementován ve formě virtuálních počítačů pomocí hypervizoru Oracle VirtualBox. Při návrhu a implementaci se ale budu snažit co nejvíce přiblížit stavu, kdy hardware není virtualizován. Taktéž nebudu řešit problematiku správy virtuálního hardware.
6.1 Konceptuální schéma systému Jak jsem uvedl v kapitole 2.3 teoretické části bakalářské práce, je nutno při návrhu systému kategorizovat jednotlivé komponenty system stacku; to nám umožní zachytit závislosti mezi nimi. Konceptuální model systému pokrývá následující závislosti mezi entitami (Obrázek 9):
aplikace – Aplikace Oracle Business Intelligence (BI), kterou uživatelé používají. Tato aplikace je integrována pomocí middleware
middleware – slouží jako běhové prostředí pro aplikaci, je realizován pomocí softwarového balíku Oracle Fusion Middleware (FMW)
databázový systém – Aplikace skrz middleware přistupuje k databázovému systému, který obsahuje data pro běh aplikace. Jako databáze je zde použitý RDBMS systém Oracle Database (DB)
operační systém – běhové prostředí, na kterém je middleware a databázový systém nainstalovaný
hardware – poskytuje prostředí pro běh operačního systému
40
infrastruktura – zahrnuje v sobě jak síťovou infrastrukturu, tak infrastrukturní služby (viz kapitola 2.9).
Vedle těchto entit, které jsou součástí (fyzickou či softwarovou), je nutno navíc zobrazit závislost externích entit, které jsou na systému závislé; jsou to:
uživatelé aplikace – koncoví konzumenti aplikace (ať již lidé, tak automatizované systémy, které data z aplikace čtou)
správa systému – administrátoři systému, kteří zajišťují jeho správu. Aplikace je záměrně vyjmuta, protože veškerá správa aplikace je prováděna pomocí middleware. Taktéž jsem vyjmul správu počítačového hardware, protože se jedná o systém běžící na virtuálních počítačích.
zdroj dat pro BI – aplikace Business Intelligence je analytická a reportingová aplikace určená pro data mining; proto potřebuje zdroj dat (datový sklad, externí služby jako SOAP apod.). V bakalářské práci se nebudu zabývat problematikou napojení na tento zdroj dat; ale pro úplnost je zde nutné tuto entitu zde uvést.
Pro úplnost by mělo být v diagramu uvedeno také prostředí, v kterém se nachází počítače a síťová infrastruktura. V případě nasazení na fyzickém hardware by se zde jednalo o místnost, kde je tento hardware umístěn. Protože se jedná o virtualizovaný hardware, prostředím, ve kterém počítače běží, je hypervizor Virtual Box.
Obrázek 9 - System stack Šipky naznačují závislost jedné entity na druhé Zdroj: vlastní tvorba
41
6.2 Detailní analýza jednotlivých komponent system stacku a identifikace SPOF V předchozí kapitole jsem rozdělil systém na jednotlivé entity. Jako další krok je nutné provést detailní analýzu technologických požadavků těchto entit a zaznamenat závislost na jiných entitách, resp. na službách těmito entitami poskytujících a identifikovat SPOF. Pro analýzu jsem použil dokumentaci k operačnímu systému [GHORI]1, databázovému systému [BRYLA], aplikačnímu serveru [ALAPATI], middleware [SHAFII] a pro analýzu síťové vrstvy jsem použil znalosti získané z knihy Data & Computer Communications [STALLINGS]. Schmidt ve svém díle High Availability and Disaster Recovery používá pro detailní analýzu diagramy vyjadřující závislost entity na jednotlivých službách a entitách, které tyto služby poskytují (pro každou entitu vytváří samostatný diagram závislostí), pro potřeby této práce jsem se ale rozhodl jít směrem vytvoření tabulky závislostí (Příloha A). Tabulka poskytuje informace o jednotlivých entitách, technologických požadavcích, které tyto entity vyžadují, služby, které tento požadavek pokryjí a v posledním sloupci jsou uvedeny entity, které dané služby poskytují. K tabulce bych uvedl pár důležitých vysvětlujících informací: Middleware i databáze vyžadují služby DNS a přesný čas; samy o sobě ale nejsou DNS/NTP klienty, ale provádí dotaz na operační systém (DNS resolving, čtení aktuálního času z hodin počítače); proto je závislou entitou operační systém, který zprostředkovává DNS resolving (je tedy závislý na DNS serveru) a současně zajišťuje přesný čas pravidelnou synchronizací vůči NTP serveru. Řádek 16 a 17 uvádí závislost databázového systému na souborovém či blokovém zařízení. Důvodem je, že Oracle Database umí ukládat data do datových souborů jak na souborový systém, tak přímo na bloková zařízení – k tomuto používá specializovaný LVM – Automatic Storage Management, který zajišťuje mimo jiné RAID funkcionality [viz BRYLA, od str. 76]. Rozhodl jsem se také rozdělit počítačový hardware na samostatné komponenty – počítač (tzn. CPU, RAM, systémová sběrnice, napájení apod), síťový adaptér a pevný disk. Jedná se sice o jednu entitu (server), ale z hlediska návrhu HA je vhodné je rozdělit – každá z těchto komponent 1
[GHORI] popisuje správu operačního systému Red Hat Linux 6; při implementaci jsem použil Oracle Enterprise Linux 6 a Centos 6, které z Red Hat Linux 6 vychází a jsou s ním v podstatě totožné
42
poskytuje jiný druh služeb. Záměrně jsem vynechal analýzu závislostí u entity „Správa systému“. V reálném nasazení většina serverů a infrastrukturních prvků (switche, routery, loadbalancery, datová úložitě apod.) poskytují samostatný přístup k zařízení pomocí separátního ethernet portu spojeného do tzv. management LAN, který zprostředkovává tzv. KVM – službu vzdálené konzole (kombinace obrazovka/klávesnice/myš), popř. je administrační rozhraní zajištěno jako webová aplikace přímo na tomto zařízení (příkladem je např. KVM a ILOM (Integrated Lights Out Management) u Oracle Exadata). V systému, který navrhuji a který je plně virtualizovaný, je administrační přístup řešen přímo pomocí konzolí hypervizoru k danému počítači. Tato tabulka nám též pomůže identifikovat SPOF v systému – jedná se o souhrn položek v posledním sloupci. Jsou to tedy následující položky:
Aplikace BI
Middleware FMW
Databázový systém
Operační systém
Infrastrukturní služba DNS
Infrastrukturní služba NTP
Infrastruktura – WAN/LAN gateway (router/firewall)
Infrastruktura – síť (TCP/IP)
Infrastruktura – ethernet
Infrastruktura – kabeláž / switche
Hardware (síťový adaptér)
Hardware (pevný disk)
Hardware (počítač)
43
7 Návrh HA systému Výstupem analýzy je v předchozí kapitole uvedený seznam entit, které mohou být SPOF. V této kapitole jsou popsány řešení eliminace SPOF tak, aby byla zajištěna co největší míra dostupnosti.
7.1 Databázové a middleware servery Aplikace a middleware Jak již bylo uvedeno, samotná aplikace BI je integrována v rámci middleware, který její chod zajišťuje. Z tohoto důvodu není nutné řešit HA na úrovni aplikace; bohatě dostačí řešit HA schopnost na úrovni middleware. Oracle Fusion Middleware (detailní informace o architektuře Fusion Middleware viz příloha C) je možné implementovat jak v kombinaci služby běžící na jednom serveru, tak v kombinaci load-balancer / failover clusteru [SHAFII]. Zde dochází k problému s administračním serverem - pouze jeden administrační server obsluhuje WebLogic doménu, které je rozprostřená v clusteru; jedná se tedy o potencionální SPOF. Databázový systém Oracle Database umožňuje běh v clusterovém režimu; a to pomocí cluster manager software Grid Infrastructure (detailní popis Oracle Database a Oracle Grid Infrastructure viz příloha D a E). Ten sám o sobě používá několik technik:
DNS based load-balancing pro SCAN (vyžaduje 3 IP adresy vázáné k jednomu doménovému jménu)
Virtuální IP pro databázové servery a SCAN
Fencing ve formě okamžitého rebootu cluster nodu
Synchronizaci mezi cluster nody pomocí interconnect – vyžaduje separátní vysokorychlostní LAN
Synchronizaci mezi cluster nody pomocí quorum zařízení (voting disk) – toto vyžaduje umístění na sdíleném datovém úložišti
44
Synchronizaci v přístupu k souborům obsahující databázová data – vyžaduje jejich umístění na sdíleném datovém úložišti
Rolling upgrade / Rolling patching – na jednotlivých cluster nodech je možné provozovat cluster software různé verze; přičemž upgradujeme / patchujeme jednotlivé nody clusteru v sekvenci. Současně je možné kdykoliv během rolling upgrade/patchingu se vrátit k předchozí verzi. V případě databázového clusteru není nutné implementovat software zajišťující
monitoring a failover jednotlivých uzlů v clusteru; toto v plné výši obsluhuje cluster software Grid Infrastructure [GOPALAKRISHNAN, str. 62]. Volitelnou komponentou zajišťující HA je Oracle Dataguard, který umožňuje vytvoření disaster-recovery řešení, kdy DR systém je replikován k danému času z primárního, a během chodu primární systém zasílá změnové logy (redo logy) z primárního do DR systému, který tyto diferenční logy aplikuje do naklonovaných databázových souborů. Tuto komponentu jsem se v návrhu rozhodl nepoužít. Hardware a operační systém Protože middleware a databázový systém bude implementován jako cluster, eliminujeme tím i SPOF na úrovni operačního systému a hardware samotného. Je ale nanejvýše vhodné zajistit techniku, která umožní rychlou obnovu hardware či operačního systému v případě jejich poruchy.
7.2 Infrastruktura Infrastrukturní služby DNS a NTP U těchto služeb využijeme jejich nativní schopnosti, kde každý operační systém, který službu NTP či DNS používá, umožňuje definovat více serverů (jak pro NTP tak pro DNS), které službu poskytují. DNS a NTP službu pokryjeme instalací dvou samostatných utility serverů, které tyto služby budou poskytovat. WAN/LAN gateway Klienti přistupují k aplikaci BI použitím webového prohlížeče – tzn. pomocí aplikačního protokolu. Aplikace musí mít jednotný vstupní bod – URL adresu. Protože middleware, nesoucí aplikaci, je clusterován, musíme zajistit transparentnost 45
tohoto clusteru z pohledu uživatele. Řešením bude použití reverzní proxy, která bude HTTP dotazy požadavky směrovat na jednotlivé nody databázového clusteru. Infrastrukturní služba DNS vyžaduje také spojení s DNS serverem mimo LAN, a to pro nutnost resolvingu těch doménových jmén, které nejsou zaregistrované v zónách obsluhovaných touto infrastrukturní službou. Taktéž infrastrukturní služba NTP vyžaduje spojení s NTP serverem vyšší úrovně, aby mohla pravidelně udržovat aktuální čas a dodávat jej NTP klientům. Z tohoto důvodu je nutné zajistit směrování na úrovni IP protokolu mezi LAN a WAN; tzn. zajistit služby implicitní brány (default gateway). Tato může být pouze jediná na daném IP subnetu. Jak službu implicitní brány, tak službu reverzní proxy zajistím použitím failover clusteru - implementuji dva gateway servery v failover cluster režimu; na straně WAN i LAN bude existovat virtuální IP, které budou migrovány mezi jednotlivými nody v clusteru. Infrastruktura – síť – Level 2 Na druhé úrovni OSI modelu použijeme ethernet LAN2. Eliminaci SPOF zajistím redundancí - mezi každým zařízením položím dvě separátní ethernet LAN; na straně zařízení použiji vždy dva ethernetové adaptéry (každý zapojený do jedné z těchto LAN) a sdružím je pomocí virtuálního ethernetového adaptéru, tzn použiji bonding – tento zajistí jak load-balancing tak failover. Infrastruktura – síť – Level 3 (IP) Na třetí vrstvě OSI modelu (IP síť) identifikuji dva potenciální SPOF - konektivita a směrovací služby IP vrstvy. U konektivity je SPOF eliminován již na úrovni vrstvy předešlé – ethernetu a to pomocí řešení popsaného v předchozím bodě. IP adresy jednotlivých zařízení budou vázány na virtuální ethernetový adaptér (bond). SPOF směrovací služby IP vychází z principu IP směrování – na každém subnetu může být pouze jedna implicitní brána. Tento SPOF bude řešen formou virtuální IP na straně LAN i WAN – viz WAN/LAN gateway.
2
V produkčních systémech se na této úrovni používají většinou dvě technologie – ethernet, nesoucí IP vrstvu, a FibreChannel, zajišťující přístup k datovým úložištím (SCSI v rámci FC). Hypervizor VirtualBox, pomocí něhož projekt implementuji, poskytuje pouze služby ethernetu; pokud bych chtěl použít i Fibre Channel, musel bych použít FCoE, což zbytečně komplikuje celou implementaci.
46
Infrastruktura – kabeláž/switch + hardware (síťový adaptér) Vzhledem k implementaci systému na virtuálních zařízení není nutné tuto vrstvu řešit; využijeme zde možnosti hypervizoru VirtualBox vytvářet separátní LAN a vytváření libovolného množství síťových adaptérů pro virtuální počítače.
7.3 Datové úložiště (pevné disky, souborové systémy) Na jednotlivých serverech (middleware, databáze) nebudeme řešit SPOF jednotlivých datových úložišť pro operační systém; toto řešíme clusterováním celého serveru. V rámci zajištění robustnosti centralizujeme úložiště pro middleware, databázový cluster a databázový software ve formě samostatného NAS/SAN serveru. Protože jak middleware tak databázový systém bude implementován v cluster režimu, je nutné zajistit sdílené úložiště, ke kterému budou mít přístup všechny nody z middleware/databázového clusteru. Pro SAN se použije protokol iSCSI; pro NAS služby se použije protokol NFS. Pro monitoring, správu a failover management jednotlivých služeb bude použit balík Pacemaker/Corosync, který je obsažen v Red Hat Linuxu.
7.4 Revalidace detailní analýzy V předchozích bodech jsem vyřešil SPOF na jednotlivých úrovních systém stacku zavedením specializovaných komponent; toto ale zavádí nové entity, které je nutné opětovně analyzovat a identifikovat potenciální SPOF. Podobně jako u první detailní analýzy jsem použil tabulku – viz Příloha B. Výsledkem je opět seznam potenciálních SPOF v posledním sloupci tabulky; některé byly již identifikovány v kapitole 6.2 a řešeny v kapitole 7. Nově přibyly následující entity:
Middleware – administrační server
Cluster manager software pro IP failover
Cluster manager software – Grid Infrastructure
Infrastruktura – NAS/SAN úložiště
Hardware (pevný disk)
NFS server 47
iSCSI target
Pro tyto buď akceptujeme SPOF nebo navrhneme řešení: Middleware – administrační server Administrační server, který spravuje jednotlivé aplikace a aplikační servery WebLogic může existovat pouze jako singleton v celém doménovém clusteru. Při instalaci je tedy nutno zvolit, na kterém node v clusteru bude administrační server umístěn, to nám ale vytváří SPOF. Řešením je definovat službu administračního serveru jako virtuální a pomocí virtuální IP ji migrovat mezi jednotlivými servery. Současně je potřeba sdílet konfiguraci administračního serveru mezi jednotlivými nody middleware clusteru; použijeme tedy schopností sdíleného úložiště NAS/SAN. Cluster manager software pro IP failover Jako cluster manager pro IP failover použiji software Keepalived, který zajistí jak monitoring (heartbeat) pomocí VRRP protokolu tak failover proces. Software Keepalived je velice jednoduché nainstalovat a nakonfigurovat; proto akceptuji tento software jako SPOF. Je nutné ale dostatečně otestovat funkcionalitu ve všech případech, kde je tento software nasazen. Cluster manager software – Grid Infrastructure Jedná se o vyspělý cluster manager, který zajišťuje velké množství funkcionalit. Z hlediska HA nás zajímá hlavně funkcionalita rolling upgrade/patching, která nám umožňuje provádět servisní zásahy na úrovni jednotlivých nodů clusteru bez nutnosti výpadku celého clusteru. Samotný cluster manager software je zde ale SPOF (např. při výpadku sdíleného úložiště pro quorum zařízení či totální výpadek interconnectu). Pokud bych chtěl eliminovat tento SPOF, je nutné vytvořit separátní cluster, který použiji jako standby cluster (disaster recovery);
a to pomocí
technologie Oracle Dataguard Infrastruktura – NAS/SAN úložiště (pevný disk, NFS server, iSCSI target) Použití centralizovaného úložiště vytváří potenciální SPOF, které je nutné řešit clusteringem, a to buď active/active clusterem nebo active/passive (hot standby) clusterem. Pevný disk v centralizovaném úložišti jako taktéž identifikován jako potenciální SPOF, který řeším redundancí pomocí RAID 1 technologie (zrcadlení 48
disků) – viz kapitola 2.5 NFS službu definuji jako virtuální a budu jí poskytovat pomocí virtuální IP. Souborový systém je nutné synchronizovat mezi nody clusteru NAS/SAN úložiště. U blokových zařízení (iSCSI) je nutné synchronizovat jejich obsah mezi nody clusteru NAS/SAN úložiště
49
8 Implementace síťové infrastruktury Během návrhu jsem identifikoval dvě entity v rámci síťové infrastruktury, které jsou potenciální SPOF určené k eliminaci – datovou síť samotnou (tzn. ethernet a IP) a infrastrukturní služby – služby gatewaye a reverzní proxy, a služeb DNS a NTP.
8.1 Síť – L2 - Ethernet Rozhodl jsem se implementovat sedm separátních LAN; prvních šest je seskupených do tří skupin (pro redundanci pomocí bondingu). Jedná se o skupiny internal, storage network a interconnect network. (viz. Příloha F) Internal network slouží pro komunikaci mezi jednotlivými servery (uzly databázového clusteru, uzly middleware clusteru, uzly gateway clusteru a utility servery) – realizováno dvojicí BP_INTLAN_A a BP_INTLAN_B. Jednotlivé servery, využívající sdílené úložiště, se k němu připojí pomocí samostatné sítě
- storage network (realizováno dvojicí BP_STRGLAN_A a
BP_STRGLAN_B). Důvody, proč jsem se rozhodl pro separaci od Internal LAN jsou následující: Vzhledem k množství přenášených dat po NFS a iSCSI protokolu je nutné tuto síť optimalizovat pro vysokou prostupnost. Jak NFS tak iSCSI používá TCP/IP3 spojení; přičemž maximální velikost TCP packetu je 64kbyte. Při převodu mezi vrstvou L3 a L2 OSI modelu dochází k dělení (fragmentaci) packetu na takovou velikost, aby se data vešly do ethernetového frame, jehož maximální velikost (MTU) je 1500 byte. Protože fragmentace zvyšuje režii pro přenos (pro jeden TCP packet je generováno veliké množství ethernet frame), jedním ze způsobem jak zvýšit přenosovou rychlost je snížit režii fragmentace implementací tzv. jumbo frame; což je speciální typ ethernetového rámce, umožňující nastavit MTU až 9000 byte. Druhý důvod je bezpečnostní – oddělením od Internal LAN zjednoduším implementaci NFS a iSCSI, protože není nutné používat jakékoliv bezpečnostní prvky (firewall na straně NAS/SAN úložiště, autentizace na úrovni protokolů apod).
3
NFS ve skutečnosti podporuje přenos dat jak po UDP, tak po TCP. Pro implementaci jsem zvolil variantu TCP, protože tento protokol zajišťuje opravu chyb a potvrzení správného transportu dat.
50
Použití separátní sítě pro cluster manager Grid Infrastructure je velice doporučováno kvůli zvýšení propustnosti a snížení nákladů na administraci [GOPALAKRISHNAN, str. 67]. Realizován je pomocí dvojice BP_ICONNECT_A a BP_ICONNECT_B a je nazván interconnect network. V případě WAN se jedná o ethernet LAN (nazvaná BP_WAN), která je umístěná mimo system stack; proto pro zjednodušení nepoužívám bonding ethernet adaptérů, předpokládám, že jakýkoliv failover na L2 vrstvě u WAN je řešen na straně poskytovatele WAN připojení. Na straně virtuálních počítačů je pro sítě Internal LAN, Storage LAN a Interconnect LAN nutné konfigurovat pomocí konzole hypervizoru dvojici ethernetových adaptérů pro každou z těchto tří LAN. Tyto dvojice jsou sdruženy v bondu. V případě Internal a Interconnect jsem zvolil paravirtualizovaný interface (virtio-net), které jsou připojeny k síti typu Internal network. Pro Storage LAN je nutné konfigurovat simulovaný adaptér typu Intel PRO/1000 MT Server; protože podle dokumentace k VirtualBoxu je možné použít jumbo frame pouze na simulovaných adaptérech od firmy Intel. Pro ethernetový adaptér na WAN straně použiji bridging s externí sítí, kterou pro potřeby tohoto projektu považuji za WAN. Ukázka nastavení adaptérů pomocí konzole hypervizoru je v příloze G.
8.2 Síť – L3 – Internet Protocol V předchozí kapitole jsem definoval čtyři samostatné sítě. Protože na všech je použitý IP protokol, je nutné přidělit IP adresy (popř. doménové jméno) zařízením v těchto sítí participující. Současně pro ty služby, které jsou virtualizovány formou virtuální IP, musí mít přidělenou vlastní IP adresu (VIP). Mapování vrstvy L3 na vrstvu L2 je provedeno pomocí virtuálních adaptérů; IP adresy tedy jsou alokovány na bond0, bond1 a bond2 adaptérech. Jediná WAN síť bude mapována přímo na ethernet adaptér – eth2, protože zde bonding neuplatňujeme. Adresní bloky jsou přiřazeny následovně:
Internal network – 10.0.1.0/255.255.255.0
Storage network - 10.0.2.0/255.255.255.0
51
Interconnect network - 10.0.3.0/255.255.255.0 a 169.254.0.0/255.255.0.04
WAN – 192.168.2.0/255.255.255.0
Pouze u sítě WAN a Internal network je nutné definovat implicitní bránu (default gateway):
Internal network – 10.0.1.1
WAN – 192.168.2.1
Detailní přehled IP adres a doménových jmen je uveden v příloze H. Konfigurace virtuálních bond síťových adaptérů je provedena následujícím stylem (např. pro eth0, eth1 jako slave a bond0 jako master): /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" ONBOOT=yes USERCTL=no TYPE=Ethernet MASTER=bond0 SLAVE=yes /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE="eth1" ONBOOT=yes USERCTL=no TYPE=Ethernet MASTER=bond0 SLAVE=yes /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE="bond0" IPADDR=10.0.1.2 NETMASK=255.255.255.0 NETWORK=10.0.1.0 BROADCAST=10.0.1.255 GATEWAY=10.0.1.1 ONBOOT=yes BOOTPROTO=none USERCTL=no BONDING_OPTS="mode=active-backup miimon=100 fail_over_mac=1 primary=eth0"
8.3 Gateway a reverzní proxy Pro služby reverzní proxy a gateway jsem se rozhodl použít dva samostatné servery (GW1 a GW2), dále reverzní proxy HAProxy a Keepalived software. Hardwarová konfigurace je následující:
Konfigurace VM: 1xCPU, 500 MB RAM, 8GB disk (port SATA 0), 3 ethernet interface (eth0, eth1, eth2)
4
Grid Infrastructure pro zvýšení redundance na interconnectu ještě navíc sám definuje set virtuálních IP adres a to z rozsahu 169.254.0.0/255.255.0.0 – tento mechanismus se nazývá HAIP (Highly Available IP) a není jej možné ovlivnit [GOPALAKRISHNAN, str. 98]
52
Operační systém: Oracle Enterprise Linux Server 6.6 UEK (64bit); Minimal install; SELinux disabled
FQDN: gw1.bp / gw2.bp
Routovací služby Na GW1 a GW2 jsem upravil sysctl.conf abych umožnil routing a nastavil implicitní bránu na VIP adresu 10.0.1.1 /etc/sysctl.conf net.ipv4.ip_forward=1
Reverzní proxy jako load-balancer Na GW1 a GW2 jsem nainstaloval a nakonfiguroval software HAProxy, který použiji jako reverzní proxy a nakonfiguroval (detailní popis konfigurace je uveden v příloze I:
Loadbalancer LBFMW – umožní uživatelům přistupovat na adresu a port 192.168.2.11:80 a tento je bude směrovat na middleware servery fmw1-3 port 7777, kde běží HTTP server.
Loadbalancer LBSTAT – umožní administrační přístup ke statistikám HAProxy na adrese http://10.0.1.1:80/stats
Na GW1 a GW2 jsem zajistil start HAProxy při startu systému. Virtuální VIP a adaptabilní routing Pro migraci virtuální IP routeru na straně INTLAN (10.0.1.1) a na straně WAN (192.168.2.11) jsem vybral software Keepalived. Tento umožňuje definovat v clusteru jeden MASTER server a několik BACKUP serverů (dle priority). Protože je nutné na GW1 i GW2 adaptabilně měnit směrovací tabulky na IP vrstvě, využil jsem možnosti, kterou poskytuje Keepalived – při fail-over i fall-back se spustí skript, které na daném počítači provede úpravu směrovacích tabulek. Detailní konfigurace Keepalived a ukázka skriptů viz příloha I.
8.4 Infrastrukturní služby DNS a NTP Pro infrastrukturní služby DNS a NTP jsem naimplementoval dva nezávislé servery (UTL1 a UTL2), na kterých je nainstalován software BIND poskytující službu DNS
53
a NTPd, který poskytuje služby protokolu přesného času NTP. Hardwarová konfigurace je následující:
Konfigurace VM: 1xCPU, 300 MB RAM, 8GB disk (port SATA 0), 2 ethernet interface (eth0, eth1 bond0)
Operační systém: Oracle Enterprise Linux Server 6.6 UEK (64bit); Minimal install; SELinux disabled
FQDN: utl1.bp / utl2.bp U služby DNS i NTP jsem využil faktu, že mohou být poskytovány samostatně
bez jakéhokoliv nutnosti clusteringu – každý NTP či DNS klient umožňuje v nastavení systému vložit více než jeden DNS/NTP server, které mohou být dotazovány. V případě, že primární v daném časovém intervalu neodpoví, bude automaticky klient dotazovat druhého serveru. Pro poskytování služby DNS jsem oba servery nastavil jako primární DNS server (tzn. ne v tandemu primární/záložní); jsou tedy na sobě naprosto nezávislé; mají však identickou konfiguraci. Oba servery obhospodařují zónu *.bp. Pro DNS resolving adres nespadající pod zónu *.bp používám přeposílání dotazu na DNS servery firmy Google (IP adresy 8.8.4.4 a 8.8.8.8). Do konfigurace pro zónu *.bp jsem zavedl adresy z tabulky uvedené v příloze H. Konfigurace NTP serverů je provedena obdobným způsobem; jako NTP servery vyšší úrovně strata využívám NTP služby firmy Cesnet (tik.cesnet.cz a tak.cesnet.cz) které poskytují NTP stratum 1. Detailní konfigurace DNS i NTP serverů je uvedena v příloze J. Aby klienti mohli využívat DNS a NTP služby, na serverech, které tyto služby používají, jsem nainstaloval balík ntpdate a současně upravit následující konfigurační soubory: /etc/ntp/step-tickers # List of servers used for initial synchronization. utl1.bp utl2.bp
/etc/resolv.conf search bp nameserver 10.0.1.11 nameserver 10.0.1.12
54
9 Implementace datových úložišť Implementaci datového úložiště jsem rozdělil na dvě samostatné jednotky, kde každé dvě jednotky jsou na obou serverech úložiště STOR1 a STOR2; první jednotkou je NAS služba, která je realizována pomocí protokolu NFS; druhou jednotkou je SAN služba, která je realizována pomocí protokolu iSCSI. NFS služba poskytuje centralizované úložiště se soubory pro middleware, databáze a databázového clusteru. Abych eliminoval SPOF pro NFS server, rozhodl jsem se vytvořit active/active NFS cluster (servery STOR1 a STOR2), který exportuje dvě virtuální IP, na kterých je NFS služba dostupná (10.0.2.103 a 10.0.2.104). Aby byl souborový systém exportovaný pomocí NFS služby dostupný nezávisle na tom, kde se jaká virtuální IP adresa nachází, je nutné použít techniku, kdy obsah blokového zařízení, na kterém se souborový systém pro NFS nachází, byl synchronizován mezi servery STOR1 a STOR2. Současně je nutné zvolit takový souborový systém, který umožňuje synchronní přístup k blokovým zařízením, které jsou sdílené mezi jednotlivými servery. Pro synchronizaci blokových zařízení mezi servery jsem zvolil software DRBD (Distributed Replicated Block Device), který umožňuje synchronizovat jak v active/active
tak
v active/passive
režimu.
Nakonfiguroval
jsem
DRBD
v active/active režimu tak, aby poskytoval zdroj (DRBD resource) r0, který používá blokové zařízení md0 RAID1 (mirror) na každém z dvou serverů STOR1 a STOR2 – tímto jsem vytvořil RAID1 mezi oběma servery. Pro souborový systém jsem zvolil OCFS2 (Oracle Cluster FileSystem), který poskytuje služby synchronizovaného souborového systému na sdílených blokových zařízeních. Po naformátování sdíleného blokového zařízení souborovým systémem OCFS2 jsem tento připojil na obou serverech STOR1 a STOR2 pod přípojný bod /nfs a nakonfiguroval NFS službu tak, aby tento zdroj exportoval do sítě 10.0.2.0/255.255.255.0 všem NFS klientům (tzn. databázovým a middleware serverům). Pro obsah databáze jsem použil jiný přístup – využil jsem schopností ASM (Automatic Storage Management), který je obsažen v Oracle Grid Infrastructure. ASM zajišťuje synchronní přístup k blokovým zařízením, takže není nutné řešit synchronizaci blokového zařízení na úrovni úložišť STOR1 a STOR2. Na každém
55
z těchto serverů jsem vytvořil blokové zařízení md1 RAID1 (mirror), které je pomocí iSCSI exportováno jako iSCSI target. Tyto iSCSI zdroje (z každého serveru jeden) jsou připojeny jako blokové zařízení /dev/sdd a /dev/sde na všechny databázové servery pomocí iSCSI initiatoru na těchto serverech. Jako poslední krok bylo nutné zajistit správu virtuálních IP. Protože ale na rozdíl od serverů GW1 a GW2 jsou virtuální IP závislé na dalších zdrojích (korektně synchronizované DRBD blokové zařízení, připojený bod souborového systému OCFS2 /nfs, aktivní služba NFS), pokusil jsem se využít softwarových balíků Pacemaker a Corosync (obsažen v Linux Red Hat). Jedná se o cluster manager, který umožňuje generovat seznam závislostí, registrovat jednotlivé služby (DRBD, OCFS2, NFS, virtuální IP) a zajistit jejich správu (spouštění ve správné sekvenci, verifikace závislostí apod.) a případně STONITH mechanismus. Bohužel, poté co jsem nakonfiguroval cluster manager a zajistil jím správu výše uvedených zařízení, při testování jsem zjistil, že pravidelně dochází k desynchronizaci DRBD zařízení; toto se přepne do active/passive režimu a není možné na serveru STOR2 zapisovat na OCFS2 souborový systém. Dle logů se zřejmě jedná o chybu v komponentně monitorující a obsluhující DRBD zařízení. Rozhodnul jsem se tedy cluster manager Pacemaker/Corosync opustit a služby DRBD,NFS a OCFS2 spravovat manuálně po startu serverů STOR1 a STOR2. Pro virtuální IP jsem použil již výše uvedený Keepalived, kde virtuální IP adresa 10.0.2.103 preferuje server STOR1 a adresa 10.0.2.104 server STOR2. Start služeb je tedy nutné provést manuálně v sekvenci DRBD OCFS2 NFS Keepalived; stop služeb v opačné sekvenci. Pacemaker/Corosync zajišťuje monitoring služeb DRDB, OCFS2 a NFS a jejich případnou deaktivaci a službu virtuální IP samotnou; ale protože jsem jej použít nemohl, vyřešil jsem toto jednoduchým skriptem, který kontroluje stav zařízení pro DRBD a služby OCFS2 a NFS. V případě výpadku jedné z těchto služeb je automaticky deaktivována služba Keepalived a tím dojde k přesunu virtuální IP na funkční server. Samotná hardwarová konfigurace serverů STOR1 a STOR2 je následující:
Konfigurace VM: 1xCPU, 2000 MB RAM
Disky: 8GB disk (port SATA 0) 2x 160GB disk (port SATA 3 a 4)
56
2x 6GB disk (port SATA 5 a 6)
Síťové karty eth0+eth1 bond1; MTU 9000
Operační systém: Oracle Enterprise Linux Server 6.6 UEK (64bit); Minimal install; SELinux disabled
FQDN: stor1.bp / stor2.bp Schéma databázového úložiště je uvedeno v příloze K; postup implementace
téhož v příloze J.
57
10 Implementace databáze a middleware Rozhodl jsem se pro middleware a databázový cluster použít systém tří uzlů a z to jednoduchého důvodu – při případném upgrade/patchování, které je u tohoto software poměrne riskantní a déletrvající záležitostí, je nutné deaktivovat uzel, na kterém budou tyto operace prováděny. V případě pouze dvou uzlů v clusteru nám tak vzniká dočasný SPOF. Použití tří uzlů v clusteru tento SPOF eliminuje. Pro databázový cluster jsem vytvořil databázové servery RAC1, RAC2 a RAC3 s následující konfigurací:
Konfigurace VM: 4xCPU, 8000 MB RAM
Disky: 8GB disk (port SATA 0) 8GB disk (port SATA 2) – odkládací prostor (SWAP)
Síťové karty eth0+eth1 bond0 eth1+eth2 bond1 eth3+eth4 bond2
Operační systém: Oracle Enterprise Linux Server 6.6 UEK (64bit); Minimal install; SELinux disabled
FQDN: rac1.bp / rac2.bp / rac3.bp Dále jsem připojil z centralizovaného úložiště OCFS2 souborový systém
pomocí NFS služby (příklad pro RAC1): /etc/fstab 10.0.2.103:/nfs/rac1/grid /grid nfs rw,bg,sync,intr,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=4,noac l,noac,tcp 0 0 10.0.2.103:/nfs/rac1/oracle /oracle nfs rw,bg,sync,intr,hard,timeo=600,wsize=32768,nfsvers=4,noacl,noac,tcp
Pro RAC2 jsem použil cestu /nfs/rac2; pro RAC3 jsem použil cestu /nfs/rac3; současně pro RAC2 a RAC3 jsem použil virtuální adresu 10.0.2.104 namísto 10.0.2.103. Přípojný bod /grid jsem použil pro sofware Oracle Grid Infrastructure a přípojný bod /oracle jsem použil pro Oracle Database. Dále jsem připojil pomocí iSCSI initiatoru z iSCSI targetu exportované blokové zařízení: [root@rac1 ~]# iscsiadm -m discovery -t sendtargets -p 10.0.2.101 10.0.2.101:3260,1 iqn.2015-08.bp.stor1:asmdisk1 [root@rac1 ~]# iscsiadm -m discovery -t sendtargets -p 10.0.2.102
58
10.0.2.102:3260,1 iqn.2015-08.bp.stor2:asmdisk2 [root@rac1 ~]# iscsiadm -m node -T iqn.2015-08.bp.stor1:asmdisk1 --login [root@rac1 ~]# iscsiadm -m node -T iqn.2015-08.bp.stor2:asmdisk2 --login [root@rac1 ~]# iscsiadm -m session tcp: [1] 10.0.2.101:3260,1 iqn.2015-08.bp.stor1:asmdisk1 (non-flash) tcp: [2] 10.0.2.102:3260,1 iqn.2015-08.bp.stor2:asmdisk2 (non-flash)
Na těchto discích jsem vytvořil partition /dev/sdc1 a /dev/sdd1; z nich jsem vytvořil samostatné ASM disky ASMDISK1 a ASMDISK2. Databázový cluster jsem poté nainstaloval pomocí grafického rozhraní Oracle Universal Installer a to s následujícími parametry:
Cluster name: BPCLUSPRI
SCAN: scan-primary
Cluster nodes: rac1 / rac1-vip, rac2 / rac2-vip, rac3 / rac3-vip
ORACLE_BASE=/grid/oraclebase
ORACLE_HOME=/grid/oracle/product/11204
Storage type: ASM
ASM Diskgroup: DATA (ASMDISK1 – iSCSI target na 10.0.2.101 + ASMDISK2 – iSCSI target na 10.0.2.102); Normal redundancy
Během instalace jsem zjistil, že Grid Infrastructure vyžaduje v případě „normal redundanci“ režimu tři reduntantní blokové zařízení pro uložení quorum zařízení a informačních souborů o konfiguraci clusteru (voting disk / OCR), na rozdíl od úložiště pro databázi, které vyžaduje pouze dvě redundantní zařízení; já jsem však poskytl pouze dvě – ASMDISK1 a ASMDISK2. Ideálním řešením tohoto problému by bylo vytvoření třetího úložiště STOR3, obsahující pouze iSCSI target; rozhodl jsem se ale pro jednodušší řešení – VirtualBox umožňuje vytvoření tzv. „shared disku“, které může být sdílené pomocí více virtuálních strojů. Takto vytvořený sdílený disk jsem namapoval jako ASMDISK3. Tento problém jsem identifikoval jako chybu v analýze při návrhové fázi. Po instalaci Oracle Grid Infrastructure a spuštění cluster manageru jsem nainstaloval pomocí grafického rozhraní Oracle Database s následujícími parametry:
DB nodes: rac1 / rac1-vip, rac2 / rac2-vip, rac3 / rac3-vip
ORACLE_BASE=/grid/oraclebase
ORACLE_HOME=/grid/oracle/product/11204
Název databáze: FMWDB
Po instalaci databáze jsem spustil databázové instance na všech třech uzlech a ověřil funkcionalitu. 59
Pro middleware cluster jsem vytvořil middleware servery FMW1, FMW2 a FMW3 s následující konfigurací:
Konfigurace VM: 4xCPU, 8000 MB RAM
Disky: 8GB disk (port SATA 0) 8GB disk (port SATA 2) – odkládací prostor (SWAP)
Síťové karty eth0+eth1 bond0 eth1+eth2 bond1
Operační systém: Oracle Enterprise Linux Server 6.6 UEK (64bit); Minimal install; SELinux disabled
FQDN: fmw1.bp / fmw2.bp / fmw3.bp Dále jsem připojil z centralizovaného úložiště OCFS2 souborový systém
pomocí NFS služby (příklad pro FMW1): /etc/fstab 10.0.2.103:/nfs/fmw1/fmw /fmw nfs rw,bg,sync,intr,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=4, noacl,noac,tcp 0 0 10.0.2.103:/nfs/fmwshared/ /fmwshared nfs rw,bg,sync,intr,hard,timeo=600,wsize=32768,nfsvers=4,noacl,noac,t cp
Obdobně jako u databázového clusteru FMW2 a FMW3 používají virtuální IP NFS služby 10.0.2.104. Speciálním případem je sdílený bod /fmwshared; tento je sdílený pro všechny uzly middleware clusteru – jsou do něj ukládány různé datové zdroje z Oracle Business Intelligence, které musí být dostupné ze všech uzlů. Poté jsem nainstaloval Oracle Fusion Middleware a Oracle Business Intelligence do přípojného bodu /fmw s následujícími parametry:
ORACLE_BASE=/fmw/oraclebase
MW_HOME=/fmw/mwhome
WL_HOME=/fmw/mwhome/wlserver
ORACLE_HOME=/fmw/orahome
ORACLE_COMMON_HOME=/fmw/oracle_common
Název domény: BPDOMAIN
Název FMW clusteru pro Business Intelligence: BI_CLUSTER – uzly fmw1, fmw2 a fmw3
Připojení na databázi: Gridlink pomocí SCAN: scan-primary.bp 60
Protože v rámci jedné FMW domény může existovat pouze jeden administrační server, nakonfiguroval jsem jej tak, aby naslouchal na virtuální IP adrese 10.0.1.24. Stejně jako v předchozích případech jsem použil Keepalived službu, aby danou adresu migrovala mezi uzly fmw1, fmw2 a fmw3, kde fmw1 je MASTER a fmw2 a fmw3 jsou BACKUP s prioritou 50 resp 20. Startování a ukončení administračního serveru se děje pomocí skriptů spouštěných pomocí Keepalived: /etc/keepalived/keepalived.conf notify_master /etc/keepalived/adminserver_start.sh notify_backup /etc/keepalived/adminserver_stop.sh
61
11 Testování Na závěr je nutné provést test všech služeb. Použil jsem tabulku z přílohy A a B a provedl jsem následující testy na entitách, které jsou dle analýzy potenciální SPOF. Test sítě je nutné provést na dvou úrovních OSI vrstvy – ethernetu (L2) a IP sítě (L3). U ethernetu test spočívá v deaktivaci jednoho z ethernet adaptérů z bond páru u všech serverů v síti. Tímto simulujeme výpadek switche na ethernetové vrstvě. Následně jsem pomocí programu ping ověřil dostupnost ostatních serverů na stejné LAN síti. Po opětovné aktivaci adaptérů jsem opět ověřil dostupnost. K otestování IP sítě jsem použil opět ping, a to proti virtuálním IP adresám, které jsou migrované pomocí Keepalived. Na MASTER node clusteru jsem vypnul službu Keepalived a ověřil pingem, že IP adresa korektně zmigrovala na záložní (BACKUP) systém. Po opětném nastartování služby na MASTER node jsem opět ověřil, že IP adresa zmigrovala zpět. Test úložiště jsem provedl na několika vrstvách. V poli RAID jsem označil jeden z disků (např. /dev/sdc1 v RAID poli /dev/md0) jako vadný; poté jsem zjistil stav DRBD úložiště a ověřil jeho funkcionalitu. Následně jsem pomocí nástroje mdadm tento vadný disk odpojil, inicializoval a znova připojil do RAIDU – tímto jsem simuloval jeho výměnu. Poté jsem ověřil opětné sestavení RAID pole. Další test spočívá ve vypnutí služby DRBD a OCFS2 na jednom ze serverů STOR1/STOR2 a opětovném zapnutí. DRBD po reaktivaci musí provést opětovné připojení na přeživší server a provést resynchronizaci. Test virtualizovaného NFS úložiště je proveden deaktivací služby Keepalived na jednom ze serverů STOR1/STOR2. Virtuální adresa pro NFS musí korektně zmigrovat na přeživší server a klienti (databázové a middletier servery) se musí opětovně připojit. V některých případech se klienti nebyli schopni znovu připojit na zmigrovanou IP adresu. Protože se jedná o active/active cluster, je nutné provést též test na split-brain a to přerušením konektivity mezi STOR1 a STOR2. DRBD a OCFS2 služba toto vyhodnotí jako split-brain a zakáže přístup k souborovému systému – nelze na něj zapisovat. Toto jsem ověřil; bohužel s různými výsledky – často zde nedošlo ke korektnímu odpojení souborového systému OCFS2. Na vině byly souborové zámky 62
NFS služby, které znemožnily odpojení souborového systému a deaktivaci DRBD zařízení. Poslední test úložiště – výpadek jednoho ze serverů – je proveden násilným vypnutím jednoho ze serverů STOR1/STOR2. Po vypnutí služby DRBD a OCFS vyhodnotí nepřístupnost serveru a Keepalived zmigruje virtuální IP na přeživší server. Po opětném zapnutí serveru a manuálním nastartování služeb DRBD, OCFS2, NFS a Keepalived se server sesynchronizoval a poskytoval nadále služby a virtuální IP adresa zmigrovala zpět. Protože se na vypnutém serveru nachází také iSCSI target pro jeden z ASM disků pro databázový cluster, je nutné též ověřit funkcionalitu databázového serveru. Ztráta ASM disku znamenala jeho vyřazení pro použití v databázovém clusteru – ASM služba jej označila za vadný, a bylo jej poté nutné znova manuálně přidat pomocí konfigurátoru ASM a nechat ASM aby jej sesynchronizoval. U databázového clusteru jsem provedl dva testy. První test, výpadek serveru, byl proveden jako v případě storage clusteru násilným vypnutím databázového serveru. Klienti se byli schopni opětovně připojit přes virtuální IP adresy SCAN na databázi. Současně jsem ověřil migraci virtuálních IP adres databáze (racX-vip a scan-primary) na přeživší nody databázového clusteru. Druhý test simuluje ztrátu spojení interconnectu. Deaktivoval jsem adaptéry pro bond2 na jednom ze serverů clusteru. Oracle Cluster Synchronization Daemon (v Grid Infrastructure) správně zjistil ztrátu spojení, provedl násilné ukončení databázové instance (shutdown abort) a restart serveru. Ostatní přeživší nody korektně reaplikovaly redo logy restartovaného node. Test formou výpadku serveru je nutné též provést u gateway a middleware clusteru. U middleware jsem po výpadku serveru ověřil dostupnost HTTP služby zbývajících node clusteru přes WAN adresu 192.168.2.11. V případě vypnutí serveru, na kterém se nachází admin server, jsem ověřil korektní migraci virtuální IP a start admin serveru na přeživším serveru v clusteru. U gateway clusteru jsem vypnul MASTER node GW1. Virtuální IP 10.0.1.1 a 192.168.2.1 korektně zmigrovaly pomocí Keepalived na BACKUP node GW2. Po migraci jsem také ověřil dostupnost HAProxy služby na WAN adrese 192.168.2.11. Po restartu GW1 jsem provedl kontrolu migrace virtuálních IP zpět na MASTER node a opětnou kontrolu přístupu na HAProxy z WAN.
63
Infrastrukturní služby DNS a NTP nejsou clusterovány, ale jsou řešeny redundantně. Ověřil jsem taktéž jejich funkcionalitu stejným způsobem jako u gateway clusteru – vypnutím jednoho ze serverů UTL1/UTL2. Klienti, kteří tyto služby používají, správně v případě nedostupnosti serveru UTL1 provedly dotaz na NTP/DNS službu na serveru UTL2. Výsledek testů jednotlivých komponent systému jsem zpracoval do následující tabulky: Počet
Počet
provedených
úspěšných
testů
testů
Síťová infrastruktura
12
12
100%
Gateway cluster - výpadek serveru
10
10
100%
12
12
100%
8
8
100%
24
8
33%
12
7
58%
10
7
70%
6
6
100%
6
5
83%
Komponenta
Infrastrukturní služby NTP a DNS výpadek serveru Storage cluster - výpadek disku z RAID pole Storage cluster - výpadek jedné z komponent DRBD, OCFS2 a NFS Storage cluster - virtuální služba NFS Storage cluster - split brain a výpadek serveru Databázový cluster - výpadek serveru a výpadek interconnectu Middleware cluster - výpadek serveru
% úšpěšnosti
Tabulka 2 – Výsledek testů Zdroj: vlastní
Z výsledků jasně vyplývá, že nejslabší článek celé architektury je jednoznačně centralizované úložiště. Při výpadku jedné z komponent DRBD, OCFS2 a NFS jsem dosáhl pouze 33% úspěšnosti. Toto je způsobeno hlavně vlastní implementací failover skriptu, kterým jsem nahradil nefunkční Pacemaker/Corosync. Síťová infrastruktura, gateway cluster a infrastrukturní služby vykázaly v testu 100% 64
úspěšnost a to díky velice jednoduché a odolné implementaci. Databázový cluster, který je sám o sobě poměrně složitý, též vykázal 100% úspěšnost (nepočítal jsem nutnost manuální opravy výpadku ASM disku při výpadku jednoho z iSCSI targetů – toto je známý fakt, s kterým se počítá). Je to hlavně díky robustnosti a kvalitě softwaru jako takového. Jeden chybný test v případě výpadku middleware clusteru byl způsoben nepovedenou migrací admin serveru na jiný cluster node.
65
12 Závěr Ve své bakalářské práci jsem si zadal za cíl navrhnout a naimplementovat HA systém pro Oracle Business Intelligence. V teoretické části jsem detailně popsal principy HA systémů a způsoby řešení zajištění vysoké dostupnosti na různých komponentách HA systému. V části praktické jsem na základě teoretických znalostí HA systém navrhl s ohledem na omezené možnosti virtualizovaného hardware. Při návrhu jsem se snažil co nejvíce přiblížit stavu, který je požadován pro úroveň kvality produkčního nasazení. Na všech úrovních a u všech komponent jsem při návrhu eliminoval veškeré SPOF, které během návrhu byly identifikovány. V implementační fázi jsem naimplementoval jednotlivé komponenty HA systému pomocí různých metod. Snažil jsem se přitom co nejvíce využít volně dostupného software (Keepalived, DRBD, OCFS2, operační systém Linux, Virtualbox) a dále software, ke kterému mám jako zaměstnanec firmy Oracle volný přístup pro neprodukční nasazení (Oracle Fusion Mideleware, Oracle Grid Infrastructure, Oracle Database). Jak jsem předpokládal, nejnáročnější byla implementace centralizovaného úložiště ve formě clusteru. Nemožnost použít cluster manager Pacemaker/Corosync a nutnost nasazení Keepalived si vynutilo nutnost manuální správy služeb a manuální monitoring a failover management. Na základě výsledku testů jsem vyhodnotil úložiště jako nejslabší bod celé architektury. Také se ukázalo být nemožné naimplementovat správný fencing a STONITH. Samotný DRDB a OCFS2 poskytuje možnost fencingu a STONITH mechanismu, který je v ideálním případě realizován odpojením serveru od zdroje elektrické energie; toto ale není možné na virtualizovaném hardware realizovat. Z tohoto důvodu by bylo vhodné při opětovném návrhu a implementaci prohlásit úložiště za akceptovatelný SPOF, které by bylo vhodné řešit formou disaster recovery. Taktéž jsem mnohdy narážel na technické možnosti hypervizoru (8-jádrový CPU, 64GB paměti, 2x500GB SSD v RAID0) – při spuštění databázového a middleware clusteru byly odezvy na aplikaci Business Intelligence velice pomalé. Z důvodu vysokého množství chyb centralizovaného úložiště a nízkého výkonu aplikace není možné takovýto systém považovat za vhodný pro produkční nasazení, 66
kde je vyžadována rychlá odezva a zabezpečení integrity dat. Takto postavený systém ale může být určen k výukovým nebo testovacím účelům; tedy v případech, kdy nám nezáleží na jeho stabilitě. Pokud bychom chtěli systém použít pro nasazení v produkčním režimu, bylo by nutné podstatně zvýšit jeho výkonnost, například použitím samostatného hardware na databázový a middleware cluster. Současně je nutné buď se spokojit s úložištěm, které bude považováno za akceptovatelný SPOF nebo jej zajistit formou průmyslového úložiště, toto však přesahuje možnosti jednotlivce a je citelným nákladem pro jakoukoliv malou firmu. Důvodem, proč jsem si zvolil HA jako téma mé bakalářské práce, bylo pochopit úskalí návrhu a implementace takového systému a vytvořit si manuál pro případné budoucí implementace do produkčního prostředí u zákazníků, kteří si nemohou dovolit investovat značné částky do hardwarových zařízení pro HA. První cíl (návrh) považuji za zdařilý a splněný, v případě cíle druhého, tj. implementace, musím bohužel konstatovat, že se mi nepodařilo jej z důvodu nestabilního úložiště splnit bezezbytku.
67
Seznam použité literatury SCHMIDT, Klaus. High availability and disaster recovery: concepts, design, implementation. Berlin: Springer, 2011. ISBN 9783642063794. TROPPENS, Ulf a Ulf TROPPENS. Storage networks explained: basics and application of Fibre Channel SAN, NAS, iSCSI, InfiniBand, and FCoE. 2nd ed. Hoboken, NJ: John Wiley, 2009, xxxvi, 564 p. CLEMENTS, Alan. Principles of computer hardware. 4th ed. New York: Oxford University Press, 2006, xv, 656 p. ISBN 9780199273133. TANENBAUM, Andrew S. Modern operating systems. Fourth edition /. xxvi, 1101 pages. ISBN 013359162x. STALLINGS, William. Data and computer communications. 6th ed. Upper Saddle River, N.J.: Prentice Hall, c2000, xx, 810 p. ISBN 0130843709. VAN VUGT, Sander. Pro Linux High Availability Clustering. New York, USA: Apress, 2014. 144 p. ISBN 978-1484200803. OSBORNE, Kerry, Randy JOHNSON a Tanel PÕDER. Expert Oracle exadata. New York : Distributed to the trade worldwide by Springer Science+Business Media: Apress, 2011, xxiv, 562 p. Expert's voice in Oracle. ISBN 9781430233930. GHORI, Asghar. Red Hat certified technician & engineer: exams RH202 and RH302 Red Hat Enterprise Linux 5. La Vergne, TN: A. Ghori, 2009. ISBN 9781615844302. SHAFII, Reza, Stephen LEE a Gangadhar KONDURI. Oracle Fusion middleware 11g architecture and management. New York: McGraw-Hill, c2011, xvii, 522 p. ISBN 9780071754170. BRYLA, Bob a Kevin LONEY. Oracle database 11g DBA handbook. Fully updated and expanded, Fully rev. New York: McGraw-Hill, c2008, xxi, 670 p. ISBN 0071496637. CARPENTER, Larry. Oracle data guard 11g handbook. New York: Oracle Press/McGraw-Hill, c2009, xxiii, 518 p. ISBN 0071621113. ALAPATI, Sam R. Oracle WebLogic server 11g administration handbook. New York: McGraw-Hill, c2012, xxvii, 494 p. ISBN 0071774254. JESSE, Scott, William BURTON a Bryan VONGRAY. Oracle database 11g release 2 high availability: maximize your availability with grid infrastructure,
68
Oracle real application clusters, and Oracle data guard. 2nd ed. New York: McGrawHill, c2011, xxxv, 515 p. ISBN 0071752080. GOPALAKRISHNAN, K a K GOPALAKRISHNAN. Oracle database 11g: Oracle real application clusters handbook. 2nd ed. New York: McGraw-Hill, c2012, xxii, 517 p. ISBN 0071752625.
Online zdroje: RHCSI, Red Hat Cluster Suite Introduction. Red Hat Enterprise Linux Product
documentation
[online].
[cit.
2015-08-01].
Dostupné
z:
https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/5/html/Cluster_Suite_Overview/s1-rhcs-introCSO.html RFC 2182: Selection and Operation of Secondary DNS Servers. NETWORK WORKING GROUP. IETF Tools. [online]. Červen 1997. [cit. 2015-07-29]. Dostupné z: https://tools.ietf.org/html/rfc2182 HAProxy documentation. HAproxy.org [online]. 2015 [cit. 2015-08-22]. Dostupné z: http://www.haproxy.org/#docs Ubuntu manpage - Keepalived: Manuálové stránky k programu Keepalived. Ubuntu
Manpages
[online].
2015
[cit.
2015-08-22].
Dostupné
z:
http://manpages.ubuntu.com/manpages/hardy/man5/keepalived.conf.5.html The DRBD User’s Guide. [online]. 2015 [cit. 2015-08-22]. Dostupné z: http://drbd.linbit.com/users-guide-8.4/ Red Hat Enterprise Linux 6 - documentation. Red Hat Customer Portal [online].
2015
[cit.
2015-08-22].
Dostupné
z:
https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/index.html Oracle Linux: OCFS2 - Oracle Cluster File System. Oracle Technology Network
[online].
2015
[cit.
2015-08-22].
Dostupné
z:
https://oss.oracle.com/projects/ocfs2/documentation/ Oracle VM VirtualBox - User Manual. Oracle VM VirtualBox [online]. 2015 [cit. 2015-08-22]. Dostupné z: https://www.virtualbox.org/manual/
69
Seznam příloh PŘÍLOHA A
DETAILNÍ ANALÝZA ZÁVISLOSTÍ ENTIT SYSTÉM STACKU NA SLUŽBÁCH....................... 71
PŘÍLOHA B
OPĚTOVNÁ DETAILNÍ ANALÝZA PO ZAVEDENÍ HA PRVKŮ ...................................... 72
PŘÍLOHA C
ARCHITEKTURA ORACLE FUSION MIDDLEWARE ................................................. 73
PŘÍLOHA D
ARCHITEKTURA ORACLE DATABASE ................................................................. 74
PŘÍLOHA E
ARCHITEKTURA ORACLE GRID INFRASTRUCTURE ................................................ 75
PŘÍLOHA F
SÍŤOVÁ INFRASTRUKTURA NA VRSTVĚ L2 – ETHERNET ......................................... 76
PŘÍLOHA G
UKÁZKA KONFIGURACE ETHERNET ADAPTÉRŮ V HYPERVIZORU .............................. 77
PŘÍLOHA H
SEZNAM IP ADRES A DOMÉNOVÝCH JMEN......................................................... 78
PŘÍLOHA I
KONFIGURACE GW1 A GW2 ........................................................................ 79
PŘÍLOHA J
KONFIGURACE UTL1 A UTL2 ........................................................................ 82
PŘÍLOHA K
DATOVÉ ÚLOŽIŠTĚ STOR1 A STOR2 - SCHÉMA ................................................ 85
PŘÍLOHA L
DATOVÉ ÚLOŽIŠTĚ STOR1 A STOR2 – POSTUP IMPLEMENTACE .......................... 86
70
Příloha A
Detailní analýza závislostí entit systém stacku na službách
71
Příloha B
Opětovná detailní analýza po zavedení HA prvků
72
Příloha C
Architektura Oracle Fusion Middleware
Oracle Fusion Middleware je middleware balík sestávající se z několika produktů poskytující různý druh podpůrných služeb – Aplikační server Weblogic a Oracle Application server, Java EE prostředí, business intelligence, kolaborace a správy obsahu (content management). Využívá různých otevřených standardů jako např. Java, SOAP, BPEL, XML a Java Messaging Services (JMS). Tento middleware balík umožňuje běh v clusterové konfiguraci. Jednotlivé služby běží jako instance serveru Weblogic v tzv. doméně. Každá doména je spravovaná jedním administračním serverem, který je singleton a jedná se defakto o administrační konzoli přístupnou přes webové rozhraní. V případě clusteru definujeme, jaké služby jsou spouštěny na jednotlivých serverech clusteru. Každý ze serverů, který nese tento middleware, spouští jeden NodeManager, který komunikuje s administračním serverem a řídí start, stop a deployment služeb na daném serveru.
73
Příloha D
Architektura Oracle Database
Oracle Database je databázový systém, který plně podporuje ACID funkcionality. Rozlišujeme zde dva základní prvky – instanci a databázi. Instancí nazýváme soubor procesů a jimi alokovanou paměť. Databází rozumíme soubor datových souborů, redo logů a řídících souborů (control file). Tyto datové souboru mohou být uloženy na souborovém systému, nebo uloženy na blokových zařízeních. Tyto jsou spravovány pomocí Oracle Automatic Storage Management, který zajišťuje služby LVM a který je součástí Oracle Grid Infrastructure. Oracle Database umožňuje běh jak v samostatném režimu, tak ve formě cluster databáze (Oracle Real Application Cluster) pomocí clusterového manageru Grid Infrastructure. Oracle Database také poskytuje schopnost běhu v primary-standby konfiguraci (pro fail-over / disaster recovery), kdy standby instance pravidelně aktualizuje obsah standby databáze pomocí redo logů zasílaných primární instancí.
74
Příloha E
Architektura Oracle Grid Infrastructure
Oracle Grid Infrastructure je komplexní balík který v sobě zahrnuje Oracle Clusterware (poskytuje služby cluster manageru) a Automatic Storage Manageru (poskytuje služby LVM pro zprostředkování přístupu k blokovým zařízením). Komunikace mezi jednotlivými uzly je zajištěna interconnectem (poskytuje heartbeat a výměnu databázové cache mezi jednotlivými databázovými instancemi), který je realizován IP sítí a pomocí quorum zařízení (tzv. voting disk). Konfigurace clusteru je ukládána ve specializované oblasti zvané Oracle Cluster Registry (OCR). Voting disk i OCR musí být přístupné všem uzlům clusteru (tzn. musí být na sdíleném úložišti na souborovém systému nebo v blokových zařízeních spravovaných pomocí ASM) a musí být redundantní. Jednotlivé Oracle Database instance používají sdílené úložiště - komunikují tedy s Oracle Clusterware, který spravuje přístup k sdílenému úložišti tak, aby nedošlo k poškození dat. Oracle Grid Infrastructure používá k migraci služeb mezi jednotlivými uzly dvou souborů virtuálních IP adres. Pro každý uzel definuje jednu virtuální IP, navíc definuje soubor tří virtuálních IP adres pro SCAN (Single Client Access Interface), které musí být sdruženy v jeden doménový název (používá zde DNS based loadbalancing). Virtuální IP SCANu jsou rozprostřeny na uzly serveru (v případě pouze dvou uzlů jsou na jednom z uzlů alokovány dvě virtuální IP pro SCAN, na zbývajícím jedna virtuální IP).
75
Příloha F
Síťová infrastruktura na vrstvě L2 – ethernet
76
Příloha G
Ukázka konfigurace ethernet adaptérů v hypervizoru
77
Příloha H
Seznam IP adres a doménových jmen
78
Příloha I
Konfigurace GW1 a GW2
Konfigurace HAProxy: yum install haproxy /etc/sysctl.conf net.ipv4.ip_nonlocal_bind=1 /etc/haproxy/haproxy.cfg global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend LBFMW bind 192.168.2.11:80 reqadd X-Forwarded-Proto:\ http default_backend LBFMW backend LBFMW 192.168.2.11:80 mode http balance roundrobin server fmw1 10.0.1.21:7777 check server fmw2 10.0.1.22:7777 check server fmw3 10.0.1.23:7777 check frontend LBSTATS bind 10.0.1.1:80 reqadd X-Forwarded-Proto:\ http default_backend LBSTATS backend LBSTATS 10.0.1.1:80 mode http stats enable stats uri /stats
Konfigurace Keepalived /etc/keepalived/keepalived.conf
79
global_defs { } vrrp_sync_group VG1 { group { WAN INTLAN } } vrrp_instance WAN { state MASTER interface eth2 virtual_router_id 1 priority 100 advert_int 1 authentication { auth_type PASS auth_pass heslo } virtual_ipaddress { 192.168.2.11/24 brd 192.168.2.255 dev eth2 } virtual_routes { 0.0.0.0/0 via 192.168.2.1 dev eth2 } } vrrp_instance INTLAN { state MASTER interface bond0 virtual_router_id 2 priority 100 advert_int 1 authentication { auth_type PASS auth_pass heslo } virtual_ipaddress { 10.0.1.1/24 brd 10.0.1.1 dev bond0 label bond0:0 } notify_master /etc/keepalived/notify_master.sh notify_backup /etc/keepalived/notify_backup.sh }
GW2 je nakonfigurována obdobně, rozdílné jsou pouze parametry: state BACKUP priority 50
Skripty notify_master.sh a notify_backup.sh jsou spouštěny v případe, kdy se GW1/2 stane MASTER/BACKUP a slouží k úpravě routovacích tabulek pro bond0 adaptér: /etc/keepalived/ notify_master.sh #!/bin/bash route del default gw 10.0.1.1 bond0 /etc/keepalived/notify_backup.sh #!/bin/bash route add default gw 10.0.1.1 bond0
Také jsem nakonfiguroval eth2 adaptér na GW1 a GW2 takto: /etc/sysconfig/network-scripts/ifcfg-eth2 DEVICE=eth2 ONBOOT=yes USERCTL=no
80
TYPE=Ethernet
Protože řízení brány pro síť 10.0.1.0/24 je nyní dynamicky prováděno Keepalived službou a skripty notify_master.sh a notify_backup.sh, vyjmul jsem z konfigurace bond0 adaptéru následující řádek: /etc/sysconfig/network-scripts/ifcfg-bond0 GATEWAY=10.0.1.1
81
Příloha J
Konfigurace UTL1 a UTL2
Konfigurace NTP serveru: /etc/ntp.conf driftfile /var/lib/ntp/drift server tak.cesnet.cz iburst server tik.cesnet.cz iburst
Test NTP služby: [root@utl1 ~]# ntpdc ntpdc> peers remote local st poll reach delay offset disp ======================================================================= *tak.cesnet.cz 10.0.1.11 1 64 3 0.01112 -0.187770 0.25089 =tik.cesnet.cz 10.0.1.11 1 64 3 0.00980 -0.192050 0.25090 ntpdc> sysinfo system peer: system peer mode: leap indicator: stratum: precision: root distance: root dispersion: reference ID: reference time: system flags: jitter: stability: broadcastdelay: authdelay:
tak.cesnet.cz client 11 2 -23 0.01112 s 0.25833 s [195.113.144.238] d97dca76.1e1defc5 Tue, Aug 18 2015 17:15:02.117 auth monitor ntp kernel stats 0.003006 s 0.000 ppm 0.000000 s 0.000000 s
Konfigurace DNS služby: /etc/named.conf options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; 10.0.1.0/24; }; allow-transfer {none; }; recursion yes; forwarders { 8.8.8.8; 8.8.4.4; }; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; };
82
## bp - ZONE + REV zone "bp" IN { type master; file "bp.zone"; }; zone "1.0.10.in-addr.arpa" { type master; file "1.0.10.in-addr.arpa.rev"; };
/var/named/bp.zone $TTL 1D @ IN SOA utl1. hostmaster.bp. ( 2011030202 ; Serial num 8H ; Refresh 2H ; Retry 2D ; Expire 1D) ; Minimum TTL bp.
IN
NS
utl1.
gwvip gw1 gw2
IN IN
IN A A
A 10.0.1.1 10.0.1.2 10.0.1.3
utl1 utl2
IN IN
A A
10.0.1.11 10.0.1.12
fmw1 fmw2 fmw3 fmwadmin
IN IN IN
A A A
10.0.1.21 10.0.1.22 10.0.1.23 10.0.1.24
A A A
10.0.1.51 10.0.1.52 10.0.1.53
IN
rac1 rac2 rac3
A IN IN IN
rac1-vip rac2-vip rac3-vip
IN IN IN
scan-primary scan-primary scan-primary
A A A IN IN IN
10.0.1.61 10.0.1.62 10.0.1.63 A A A
10.0.1.71 10.0.1.72 10.0.1.73
/var/named/1.0.10.in-addr.arpa.rev $TTL 1D 1.0.10.in-addr.arpa. IN SOA utl1.bp. 2011030202 ; Serial num 8H ; Refresh 2H ; Retry 2D ; Expire 1D) ; Minimum TTL NS utl1.bp. 1 2 3
IN IN IN
PTR PTR PTR
gwvip.bp. gw1.bp. gw2.bp.
11 12
IN IN
PTR PTR
utl1.bp. utl2.bp.
21
IN
PTR
fmw1.bp.
83
hostmaster.bp. (
22 23 24
IN IN IN
PTR PTR PTR
fmw2.bp. fmw3.bp. fmwadmin.bp.
51 52 53
IN IN IN
PTR PTR PTR
rac1.bp. rac2.bp. rac3.bp.
61 62 63
IN IN IN
PTR PTR PTR
rac1-vip.bp. rac2-vip.bp. rac3-vip.bp.
71 72 73
IN IN IN
PTR PTR PTR
scan-primary.bp. scan-primary.bp. scan-primary.bp.
Test DNS služby: [root@utl1 ~]# nslookup > www.seznam.cz Server: 10.0.1.11 Address: 10.0.1.11#53 Non-authoritative answer: Name: www.seznam.cz Address: 77.75.78.3 > > > scan-primary Server: 10.0.1.11 Address: 10.0.1.11#53 Name: scan-primary.bp Address: 10.0.1.73 Name: scan-primary.bp Address: 10.0.1.71 Name: scan-primary.bp Address: 10.0.1.72 > > > set type=PTR > 10.0.1.73 Server: 10.0.1.11 Address: 10.0.1.11#53 73.1.0.10.in-addr.arpa >
name = scan-primary.bp.
84
Příloha K
Datové úložiště STOR1 a STOR2 - schéma
85
Příloha L
Datové úložiště STOR1 a STOR2 – postup implementace
Konfigurace RAID /dev/md0 (/dev/md/nfs) a /dev/md1 (/dev/md/iscsi) mdadm -C /dev/md/nfs --level=raid1 --raid-devices=2 /dev/sdc1 /dev/sdd1 mdadm -C /dev/md/iscsi --level=raid1 --raid-devices=2 /dev/sde1 /dev/sdf1 /etc/mdadm/mdadm.conf ARRAY /dev/md/nfs metadata=1.2 name=stor1.bp:nfs UUID=646c33a7:1043f0db:3381db91:fefd9074 ARRAY /dev/md/iscsi metadata=1.2 name=stor1.bp:iscsi UUID=6b9212ac:1996fa87:6ff0c522:03a256f2
Konfigurace DRBD /etc/drbd.d/r0_md0_nfs.res resource r0 { protocol C; syncer { rate 1000M; } startup { wfc-timeout 15; degr-wfc-timeout 60; become-primary-on both; } net { protocol C; cram-hmac-alg sha1; shared-secret "BP"; allow-two-primaries; after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; } on stor1.bp { device /dev/drbd0; disk /dev/md/nfs; address 10.0.2.101:7788; meta-disk internal; } on stor2.bp { device /dev/drbd0; disk /dev/md/nfs; address 10.0.2.102:7788; meta-disk internal; } }
[root@stor1 ~]# drbdadm create-md r0 [root@stor1 ~]# drbdadm -- --overwrite-data-of-peer primary all [root@stor1 ~]# service drbd status drbd driver loaded OK; device status: version: 8.4.2 (api:1/proto:86-101) srcversion: D2C09D2CF4CCB8C91B02D14 m:res cs ro ds p mounted fstype 0:r0 SyncSource Primary/Secondary UpToDate/Inconsistent C ... sync'ed: 0.3% (153108/153464)Mfinish: 0:50:08 52,076 (52,076) K/sec [root@stor2 drbd.d]# service drbd status drbd driver loaded OK; device status: version: 8.4.2 (api:1/proto:86-101)
86
srcversion: D2C09D2CF4CCB8C91B02D14 m:res cs ro fstype 0:r0 Connected Secondary/Primary
ds UpToDate/UpToDate
p
mounted
C
[root@stor2 drbd.d]# drbdadm primary r0 [root@stor2 drbd.d]# service drbd status drbd driver loaded OK; device status: version: 8.4.2 (api:1/proto:86-101) srcversion: D2C09D2CF4CCB8C91B02D14 m:res cs ro ds p mounted 0:r0 Connected Primary/Primary UpToDate/UpToDate C
fstype
Konfigurace OCFS2 /etc/ocfs2/cluster.conf cluster: node_count = 2 name = nfs node: ip_port = 7777 ip_address = 10.0.2.101 number = 1 name = stor1 cluster = nfs node: ip_port = 7777 ip_address = 10.0.2.102 number = 2 name = stor2 cluster = nfs
mkfs.ocfs2 -L "nfs" /dev/drbd0 mkdir /nfs
/etc/fstab ## NFS - OCFS FILESYSTEM @DRBD DEVICE /dev/drbd0 /nfs ocfs2 noauto,noatime,nodiratime,_netdev
Konfigurace NFS /etc/exports /nfs 10.0.2.0/255.255.255.0(rw,sync,no_root_squash,fsid=1)
Konfigurace iSCSI /etc/tgt/targets.conf default-driver iscsi
backing-store /dev/md/iscsi write-cache off
87
0 0
[root@stor1 tgt]# tgt-admin --show Target 1: iqn.2015-08.bp.stor1:asmdisk1 System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 64391 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/md/iscsi Backing store flags: Account information: ACL information: ALL
88
