VYSOKÁ ŠKOLA FINANČNÍ A SPRÁVNÍ, o.p.s.

Transkript

1 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.

2 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.

3 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ů Zdeněk Kuběnka

4 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.

5 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

6 Obsah 1 ÚVOD SYSTÉMY S VYSOKOU MÍROU DOSTUPNOSTI (HA) Definice požadavků na HA systémy Definice HA systému Obecné rysy návrhu HA systému Počítačový hardware Datová úložiště Operační systém, souborový systém Middleware Aplikace Infrastruktura CLUSTERING JAKO IDEÁLNÍ ŘEŠENÍ PRO HA VIRTUALIZACE A JEJÍ POUŽITÍ V RÁMCI HA Virtualizace hardware Virtualizace v rámci operačního systému Virtualizace datových úložišť Virtualizace na úrovni sítě Virtualizace služeb UKÁZKOVÁ ŘEŠENÍ HA SYSTÉMŮ Oracle Exadata Machine Red Hat Cluster Suite ANALÝZA SYSTÉMU Konceptuální schéma systému Detailní analýza jednotlivých komponent system stacku a identifikace SPOF NÁVRH HA SYSTÉMU Databázové a middleware servery Infrastruktura Datové úložiště (pevné disky, souborové systémy) Revalidace detailní analýzy IMPLEMENTACE SÍŤOVÉ INFRASTRUKTURY Síť L2 - Ethernet Síť L3 Internet Protocol... 51

7 8.3 Gateway a reverzní proxy Infrastrukturní služby DNS a NTP IMPLEMENTACE DATOVÝCH ÚLOŽIŠŤ IMPLEMENTACE DATABÁZE A MIDDLEWARE TESTOVÁNÍ ZÁVĚR... 66

8 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 . 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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). RAID level Fault-tolerance Read performance Write performance Space requirement RAID 0 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 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

21 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

22 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

23 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 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

24 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 ů 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

25 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

26 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

27 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: 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

28 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

29 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