Návrh IT infrastruktury pro provoz nadnárodního portálu

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh IT infrastruktury pro provoz nadnárodního portálu Diplomová práce

Vedoucí práce: Ing. Ludmila Kunderová

Bc. Tomáš Ruprich

Brno 2013

Vynechná strana pro zadání práce.

Děkuji vedoucí mé práce, Ing. Ludmile Kunderové, za vedení, podporu a cenné připomínky při tvorbě. Dále děkuji kolegům ze společnosti IS4U, s.r.o., především Mgr. Petru Dadákovi a Ing. Zdeňku Loučkovi za kontrolu uvedených údajů a odbornou pomoc. V neposlední řadě děkuji své úžasné rodině za všeobecnou podporu během studií.

Prohlašuji, že jsem tuto diplomovou práci vytvořil samostatně dle pokynů vedoucího práce a za použití zdrojů, které jsou uvedeny v seznamu zdrojů.

V Brně dne 14. 5. 2013

....................................................

5

Abstract Ruprich, T. Concept of IT infrastructure for running international portal. Diploma thesis. Brno, 2013. Thesis deals with theoretical background of the draft of comprehensive infrastructure for running highly available and scalable systems with support for international access. The second part uses these findings to develop a full proposal for deployment. An integral part of the work is basic comparison of own custom architecture with using the IaaS infrastructure.

Abstrakt Ruprich, T. Návrh IT infrastruktury pro provoz nadnárodního portálu. Diplomová práce. Brno, 2013. Práce pojednává o teoretických východiscích návrhu komplexní infrastruktury pro provoz vysoce dostupných a škálovatelných systémů s podporou nadnárodního přístupu. Těchto poznatků je pak v druhé části práce využito k vypracování plnohodnotného návrhu pro nasazení. Nedílnou součástí práce je základní srovnání vlastního řešení s pořízením infrastruktury formou IaaS.

6

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Omezující podmínky . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Metodická východiska práce 2.1 Cloud computing . . . . . 2.2 Distribuce služeb . . . . . 2.3 Architektura řešení . . . . 2.4 Postup řešení . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Teoretický základ práce 3.1 Virtualizace a výpočetní výkon . . . . . 3.1.1 Plná virtualizace . . . . . . . . . 3.1.2 Paravirtualizace . . . . . . . . . . 3.1.3 Virtualizace na úrovni operačního 3.1.4 Virtualizační software . . . . . . 3.2 Hardware . . . . . . . . . . . . . . . . . 3.3 Síťová topologie . . . . . . . . . . . . . . 3.3.1 Komunikace v rámci uzlu . . . . 3.3.2 Globální komunikace . . . . . . . 3.4 Úložiště . . . . . . . . . . . . . . . . . . 3.4.1 Typy datového úložiště . . . . . . 3.4.2 Vysoká dostupnost úložiště . . . . 3.5 Databáze . . . . . . . . . . . . . . . . . 3.5.1 Databázové schéma . . . . . . . . 3.5.2 Plnohodnotná instance . . . . . . 3.5.3 Replikace . . . . . . . . . . . . . 3.6 Doručení obsahu . . . . . . . . . . . . . 4 Vlastní práce 4.1 Poskytnutí výpočetního výkonu . 4.2 Návrh síťové topologie . . . . . . 4.2.1 Naplánování IP prostoru a 4.2.2 DHCP . . . . . . . . . . . 4.2.3 DNS . . . . . . . . . . . . 4.2.4 Loadbalancing . . . . . . . 4.2.5 IPsec VPN . . . . . . . . 4.3 Realizace úložiště . . . . . . . . . 4.3.1 DRBD . . . . . . . . . . . 4.3.2 Souborové úložiště . . . . 4.3.3 Blokové úložiště . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . systému (kontejnery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . interních VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

8 8 8 9

. . . .

11 11 12 13 15

. . . . . . . . . . . . . . . . .

17 17 18 18 19 19 20 21 25 28 31 31 32 33 33 33 34 36

. . . . . . . . . . .

39 39 42 42 44 46 50 52 54 55 57 58

7

OBSAH

4.4

4.5

Návrh 4.4.1 4.4.2 Návrh 4.5.1

řešení databázové vrstvy . . . Replikace . . . . . . . . . . . Databázové schéma . . . . . . řešení sítě pro doručení obsahu Caching engine . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 Srovnání vlastního řešení a nákupu formou služby 5.1 Metodika stanovení nákladů . . . . . . . . . . . . . 5.2 Náklady na vlastní infrastrukturu . . . . . . . . . . 5.3 Náklady na IaaS . . . . . . . . . . . . . . . . . . . 5.4 Interpretace výsledků . . . . . . . . . . . . . . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

58 59 62 62 62

. . . .

64 65 65 67 69

6 Diskuze 70 6.1 Klady a zápory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.2 Další vývoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7 Závěr

72

8 Literatura

73

Přílohy

75

A DNS

76

B IP anycasting v CDN sítích

79

1

ÚVOD A CÍL PRÁCE

1 1.1

8

Úvod a cíl práce Úvod

V roce 1965 popsal spoluzakladatel firmy Intel Gordon E. Moore trend, který říkal, že počet tranzistorů na integrovaném okruhu se každým rokem zdvojnásobí a tento trend bude trvat nejméně deset let. V roce 1975 upravil svůj předpoklad na zdojnásobení počtu tranzistorů každé dva roky. Tato jednoduchá prognóza se dodnes ukazuje až neuvěřitelně pravdivá a přestože existují skokové odchylky, v dlouhém období zůstává trend platným téměř ve všech odvětvích digitálních elektronických zařízení – od procesorového výkonu, paměťové kapacity přes snímací schopnosti optických zařízení. V neposlední řadě je nutné říci, že se tomu děje při zachování cenové hladiny, což odráží význam výroku v ekonomické a tržní oblasti a je často brán jako základ dlouhodobého plánování v oblasti výzkumu a vývoje. (Disco, van der Meulen, 1998) S růstem výkonu se úzce pojí i myšlenka abstrakce hardware, emulace hardware na aplikační vrstvě, využití nadbytečných zdrojů a rozdělení výpočetního výkonu jediného fyzického stroje, tedy jedním slovem virtualizace. Počátky virtualizace datujeme do brzkých 60. let 20. století, kdy v laboratořích CSC patřících IBM začíná vývoj CP/CMS (Control Program/Cambridge Monitor System) a brzy poté vzniká operační systém CP-40/CMS s podporou virtuální paměti a timesharingu (což se stává základem multitaskingu, jak jej známe dnes). V roce 1972 se dostáváme k dalšímu důležitému milníku, kterým je VM/370, opět z laboratoří IBM, se schopností spustit uvnitř operačního systému další operační systém. Postupný vývoj této oblasti probíhá až do konce milénia, kdy je uvedením Virtual PC pro Macintosh a VMware Virtual Platform pro architekturu IA-32 odstartován raketový rozvoj virtualizace v celosvětovém měřítku. V roce 2001 pak vychází první verze Virtual PC pro Windows a první serverová virtualizační platforma VMware pro architekturu x86. Tímto krokem ve světě počítačů definitivně končí éra, kdy virtualizace je pojmem používaný téměř výhradně na laboratorní půdě a je započat obrovský boom jedné z nejrychleji se vyvíjející oblasti ve světě IT. S rozvojem virtualizace a jejím pevným zařazením do základů každé moderní IT infrastruktury dochází také k významným změnám v návrhu serverové části. S využitím open-sourcových i komerčních řešení se i drobné projekty při vhodném návrhu mohou dostupností, robustností a výkonem srovnávat s enterprise projekty nadnárodních korporací.

1.2

Cíl práce

Cílem práce je návrh kompletní IT infrastruktury pro provoz nadnárodního webového portálu, návrh technické realizace popsaného řešení a ekonomické srovnání vlastní implementace s komerčně poskytovaným řešením.

1.3

Omezující podmínky

9

Práce je koncipována jako analýza technických potřeb a okolností nasazení obecného aplikačního řešení na bázi třívrstvé architektury s ohledem právě na univerzálnost použití a případnou možnost rozšíření řešení o komponenty umožňující poskytnutí infrastruktury interním vývojářům nebo externím subjektům formou služby. Od samotné programové složky je práce abstrahována, může se jednat o webový obchod, podnikovou či produktovou prezentaci, podporu zákazníků nebo také vnitropodnikový portál. Při realizaci je třeba brát zřetel především na následující kritéria: • Maximální dostupnost – vzhledem k množství přistupujících uživatelů má každý výpadek velký vliv a potenciální finanční ztráty mohou dosahovat vysokých částek. Při řešení je zapotřebí zajistit naprosto bezvýpadkové prostředí založené na redundanci nebo failoveru kritických komponent. • Škálovatelnost – řešení musí počítat s jednoduchým a efektivním způsobem navyšování výkonu jednotlivých komponent nebo celé infrastruktury. V případě prodejní akce, uvedení nového produktu, nebo jen neočekávané špičky je třeba mít možnost nárazového navýšení výkonu celého řešení při zachování plné dostupnosti. • Doručení obsahu – realizace musí být plně připravena na globální provoz. Rozmístění klientů po celém světě přináší problém doručení webového obsahu na velké vzdálenosti a s tím související zvýšenou dobu odezvy a výši datových přenosů. Součástí práce je orientační nacenění a srovnání realizace a provozu těchto služeb vlastními silami s nákupem formou služby od komerčního poskytovatele IaaS.

1.3

Omezující podmínky

Vzhledem k obsahové náročnosti a složitosti praktické realizace v případě naprosto obecného řešení jsem stanovil následující omezující podmínky simulující reálné požadavky zákazníka: • většina klientů přichází z Evropy a USA – dva hlavní uzly – San Francisco a Praha – inteligentní loadbalancing na základě polohy klienta – rozdělení zátěže v rámci uzlu • vysoká dostupnost – plná redundance databází v rámci uzlu – replikace dat v rámci uzlu – převzetí provozu druhým uzlem v případě výpadku prvního • nasazení v komerční serverovně – připojení do Internetu realizuje ISP – plná realizace jádra sítě je realizována ISP v běžně poskytovaném měřítku

1.3

Omezující podmínky

10

Realizační část práce bude navrhována na OS Linux. Vzhledem k drobným odlišnostem mezi jednotlivými distribucemi, např. používanými balíčkovacími systémy, se mohou některé příkazy týkat konkrétně prostředí RHEL a z něj odvozených produktů.

2

METODICKÁ VÝCHODISKA PRÁCE

2

11

Metodická východiska práce

2.1

Cloud computing

Cloud computing je obecný model používání počítačových technologií zahrnující abstrakci využívání dané služby od technické realizace. Jedná se o hardware, software a aplikace poskytované formou služby v prostředí Internetu. Cloud dostupný široké veřejnosti nazýváme veřejný cloud. Privátním cloudem pak nazýváme infrastrukturu využívanou výhradně pro potřeby firmy nebo organizace. Kombinace obou uvedených variant se nazývá hybridní cloud, kde privátní část se stará o vysokou dostupnost služeb v kombinaci s využitím služeb externího veřejného cloudu za účelem pokrytí hardwarových výpadků nebo špiček. (Gillam, 2010) Cloud computingová infrastruktura obecně podle Gillam (2010) pokrývá následující skupiny služeb: • Klíčové služby – zahrnují rozhodující a neopomenutelné mechanismy zajišťující plynulý a stálý provoz služeb. Patří sem především load balancing z důvodu rozdělení zátěže a odbourání úzkých míst v infrastruktuře, failover a replikace kvůli zajištění plynulého bezvýpadkového provozu a v neposlední řadě management služeb, poskytující možnost tvorby a správy ondemand zdrojů v reálném čase. • Management – z hlediska správy se v případě cloudu může jednat o velmi složitou hierarchii a vhodné podpůrné nástroje pro automatizovanou konfiguraci a deployment jsou naprosto zásadní komponentou. Druhou nutnou oblastí managementu je monitoring a reporting, jednak za účelem interního vyhodnocování dat, odhalení problému a také kvůli podrobným podkladům pro účtování, na druhé straně také jako způsob kontroly dodržení SLA (Service Level Agreement). Poslední podkategorií je pak poskytování samoobslužných služeb, nejčastěji formou API nebo předkonfigurovaného frameworku, což zvyšuje samoobslužnost některých částí týmu a přináší pokročilé možnosti v oblasti automatizace a plánování zdrojů některých procesů (typicky např. testování). • Bezpečnost – bezpečnost dat a infrastruktury obecně je pro mnoho společností nejvíce zvažovaným hlediskem přesunu do cloudu, neboť přesouvají data mimo vlastní infrastrukturu a ztrácejí plnou kontrolu nad všemi oblastmi správy. Pro zajištění optimálního zabezpečení je nutné především zajištění plného soukromí dat a na straně druhé definování a správa identit za účelem oprávněného přístupu, tedy autorizace a autentizace. Nedílnou součástí je pak nasazení šifrování, a to jak na úrovni přístupu ke službě, tak na úrovni vlastních dat. • Odolnost proti chybám – zajištění záložních dat nebo náhradní služby pro případ co možná nejrychlejšího zotavení z kritické chyby. • Data Governance – zajištění interoperability dat a služeb a také podpora migrace dat ať už mezi vnitropodnikovým prostředím a poskytovatelem nebo mezi jednotlivými poskytovateli.

2.2

Distribuce služeb

12

Jak vidno, jedná se o dosti složitý opis toho, co by měl cloud computing splňovat. Proto se mnoho zdrojů kloní k jednoduššímu vysvětlení, vycházejícímu přímo ze vzniku slova cloud. Obrázkem mraku (anglicky cloud) se totiž v síťových a infrastrukturních diagramech označují oblasti řešení, od kterých je konkrétní návrh abstrahován. Může se jednat o část návrhu ve správě někoho jiného, o část infrastruktury mimo firmu nebo kampus, prostě o všechno ostatní co není naše, ale je součástí funkčního celku (v síťových návrzích nejčastěji přímo Internet). (Velte, Velte, Elsenpeter, 2009) Pokud uvažujeme o rozsáhlejší infrastruktuře s nadnárodním spektrem poskytovaných služeb a různými více či méně oddělenými skupinami zaměstnanců nebo vývojářů, pak z hlediska infrastruktury je naším cílem vytvořit právě privátní cloud. Navrhnout infrastrukturu řešení tak, aby vzniklo plně škálovatelné, bezvýpadkové řešení, připravené pro interní ondemand požadavky týkající se výkonu a služeb, navržené s ohledem na požadavky na automatizaci a jednoduchý horizontální růst.

2.2

Distribuce služeb

Z hlediska formy distribuce služeb dělí Stanoevska a kol. (2010) využívanou nebo poskytovanou IT infrastrukturu do následujících skupin: • IaaS (Infrastructure as a Service) – poskytování úložiště a výpočetního výkonu formou služby. Nad standardizovanými rozhraními IaaS infrastruktury jsou následně modelovány PaaS a SaaS řešení. Místo čistého hardware je tak dodávána abstrahovaná vyšší vrstva výpočetního výkonu, typicky zapouzdřená jako unifikovaný zdroj virtualizačním software. • PaaS (Platform as a Service) – jedná se o abstraktní vrstvu mezi infrastrukturou (IaaS) a softwarovou aplikací (SaaS). PaaS nabízí prostředek pro vývojáře, který jim umožňuje vyvinout nad poskytnoutou platformou aplikaci bez nutnosti starat se o podléhající infrastrukturní vrstvu. Po uploadu kódu do platformy postavené nad standardizovaným IaaS rozhraním je následně postaráno na straně jedné o přístup k aplikaci, případné škálování v případě růstu, management aplikace a na straně druhé o stabilní základnu a standardizované rozhraní pro vývoj a následný provoz SaaS. • SaaS (Software as a Service) – jedná se o softwarový produkt, který je vlastněn, spravován a vzdáleně provozován poskytovatelem služby a poskytován formou úhrady za používání služby (nikoliv tedy nákupem software jako produktu). Jedná se o nejviditelnější vrstvu pro koncového zákazníka, protože právě koncový produkt na této vrstvě používá. Pro pořízení nemusí řešit žádné personální ani infrastrukturní problémy a zpravidla ani vstupní investici. Důležité je, že v prostředí cloudu jsou jednotlivé vrstvy úzce provázány a teprve dohromady tvoří funkční model. Obrovskou výhodou cloud computingu může být v komerčním prostředí právě cena. Běžným platebním modelem je totiž tzv. pay-asyou-go, tedy platba za to, co uživatel opravdu reálně využije, tedy např. výpočetní

2.3

Architektura řešení

13

výkon měřený množstvím procesorového času nebo počtem operací, množství přenesených dat atd. (Antonopoulos, Gillam, 2010) Tato práce se zabývá především infrastrukturním návrhem, vhodným pro nasazení formou IaaS. Vzhledem k rozsahu není možné zahrnout do práce oblasti týkající se automatizace, API a managementu, na navrženém řešení by však měly být realizovatelné.

2.3

Architektura řešení

Obecná architektura vyvíjeného IT řešení sestává podle Bruckner a kol. (2012) z jednotlivých dílčích komponent, na kterých je komponován výsledný systém. Tyto dílčí architektury jsou: • • • •

aplikační architektura, datová/informační architektura, softwarová architektura, technologická architektura.

Od vlastního aplikačního návrhu a řešení se práce abstrahuje, předmětem zájmu tedy zůstávají softwarová a technologická architektura. Architektura technologické infrastruktury zahrnuje především hardwarové komponenty (servery, síťové prvky) a komponenty základního programového vybavení (operační systémy, komunikační rozhraní). Softwarová architektura se oproti tomu zabývá konkrétními parametry a požadavky softwarového řešení (dostupnost, víceuživatelské řešení, dimenzování, modularita) a vlastním propojením funkčních komponent. Základním návrhem moderních informačních systémů a webových řešení obecně zůstává tzv. klient/server architektura. Tato dvouvrstvá architektura existuje ve své podstatě pouze ve dvou variantách podle umístění aplikační vrstvy. Pokud je aplikační vrstva na klientovi, nazýváme řešení tlustým klientem, pokud je na serverové straně, jedná se o tenkého klienta. Postupem času došlo k vývoji třívrstvé a nakonec obecně vícevrstvé architektury. Vícevrstvá architektura, často nazývaná také třívrstvá nebo n-vrstvá, umožňuje vyšší škálovatelnost, snazší správu a možnost širšího využití komponent. Třívrstvá architektura nabízí možnost realizace klient/server aplikací bez vazby na konkrétní technologii za využití standardních rozhraní poskytujících služby pro každou logickou vrstvu. Obecná třívrstvá architektura je zobrazena na obr. 1. (Sumathi, Esakkirajan, 2007) Pro návrh fyzické podoby výsledného řešení je potřeba definovat konkrétní služby na aplikační a databázové vrstvě. Definujme si tedy nad oběma vrstvami logické celky podle funkcionality konkrétních subsystémů. Logická infrastruktura je zobrazena na obr. 2. Aplikační vrstva: • Síťový přístup – bezpečnost a autorizace síťového přístupu

2.3

Architektura řešení

14

Obr. 1: Obecná třívrstvá architektura

– síťové služby – DNS, DHCP – site-to-site VPN – rozděluje provoz cílovým aplikacím v závislosti na požadavku a definovaných metrikách (zátěž) • Aplikace – obsluha požadavků zákazníků • Doručení statického obsahu – content delivery network (CDN) Datová vrstva: • Relační databáze – uchovávání dat v relačním databázovém systému – datová cache • Souborové úložiště – uchovávání velkoobjemových dat v souborovém systému Logický návrh řešení však stále slouží pouze jako vzor pro konkrétní fyzickou topologii. Ta již musí vycházet z konkrétních požadavků, které si pro náš účel uměle

2.4

Postup řešení

15

Obr. 2: Logický návrh infrastruktury třívrstvého systému

stanovíme tak, aby došlo k realizaci všech komponent rozebíraných v rámci této práce.

2.4

Postup řešení

Postup řešení vychází z popsaných skutečností a obecné architektury. Jednotlivé kroky získávání teoretických podkladů zahrnují: 1. virtualizace a výpočetní výkon • základní rozdělení virtualizačních technologií a prodkutů • poskytnutí výpočetního výkonu nad zvolenou virtualizační technologií 2. hardware • analýza požadavků na hardwarovou základnu v závislosti na cílových službách 3. síťová infrastruktura

2.4

Postup řešení

16

• možnosti fyzického zapojení řešení v datacentru • definování síťových služeb nutných pro provoz vnitřního prostředí • analýza kritických komponent komunikace klient/server 4. úložiště • definování způsobu přístupu k datům • zajištění neustálé dostupnosti uložených dat 5. databáze • způsoby zpřístupnění databázového systému • zajištění maximální dostupnosti databázové vrstvy • možnosti realizace failover řešení pro případ výpadku databázové komponenty 6. doručení obsahu • klasifikace typu obsahu • možnosti optimalizace doručení statického obsahu s ohledem na mezinárodní přístup Dalším krokem je návrh realizace jednotlivých komponent na základě získaných teoretických podkladů. Posledním bodem je pak srovnání řešení a ekonomické náročnosti navržené infrastruktury s komerčním poskytovatelem řešení IaaS.

3

TEORETICKÝ ZÁKLAD PRÁCE

3

17

Teoretický základ práce

3.1

Virtualizace a výpočetní výkon

Poskytnutí výpočetního výkonu je s rozmachem virtualizace serverových i desktopových řešení zřejmě nejklasičtějším příkladem nasazení služby abstrahované od technického řešení. Virtualizace v cloudu umožňuje poskytnout vysoce škálovatelné prostředí, přinášející uživateli široké možnosti volby potřebného rozsahu a parametrů vyžadované služby. Virtualizaci můžeme definovat jako způsob rozdělení hardwarových zdrojů do více exekučních prostředí za využití jedné nebo více metod hardwarového nebo softwarového partitioningu, time-sharingu, plné nebo částečné simulace, emulace, kvality služby a mnoha dalších. Virtualizaci nasazujeme ze tří hlavních důvodů: • konsolidace – zvýšení využití hardware; – jednodušší migrace; – více operačních systémů na jedné fyzické platformě; – realizace komplexních testovacích a vývojových prostředí; • spolehlivost – izolace softwarových chyb; – realokace existujících oddílů; – vytvořrní dedikovaných a ondemand oddílů pro překlenutí výpadku; • bezpečnost – izolace digitálních útoků; – aplikace specializovaných bezpečnostních nastavení pro jednotlivé oddíly. Vhodné je také zmínit, že na tomto místě hovoříme pouze o serverové virtualizaci. Vzhledem k prudkému rozvoji virtualizace téměř ve všech IT odvětvích došlo časem k potřebě rozlišovat především desktopovou, serverovou, síťovou, aplikační a virtualizaci storage. (Williams, 2007) Základem serverové virtualizace je architektura CPU. Nejrozšířenější architekturou v moderních počítačích je architektura x86, dnes často označovaná jako x86-32 a novější x86-64 pro 64-bitové procesory. Tato architektura využívá dva způsoby přístupu k paměti – reálný a chráněný režim. Reálný režim umožňuje adresovat paměť o maximální velikosti 1MB a v dnešních počítačích se používá pouze při startu systému, neposkytuje hardwarovou ochranu paměti a umožňuje neomezený přístup k paměti a periferiím. Oproti tomu chráněný režim (uvedený s procesorem 80286) přináší kromě podstatně vyšších limitů pro adresaci paměti také segmentaci procesů za účelem striktního vymezení jim přidělené paměti, hardwarovou podporu virtuální paměti a přepínání procesů. V chráněném režimu pak existují čtyři úrovně ochrany, tzv. kruhy, číslované od 0 do 3. Systémová paměť je segmentována a každý segment je přiřazen do konkrétního kruhu. Vnitřní kruh 0 má neomezenou kontrolu nad procesorem, oproti tomu

3.1

Virtualizace a výpočetní výkon

18

vnější kruh 3 je vyhrazen pro uživatelské aplikace a je provozován v restriktivním módu. Kruh 1 slouží k běhu interních procesů OS a kruh 2 se téměř nepoužívá. V současnosti je ve spojitosti s virtualizací model spíše zjednodušován na vnitřní kruhy 0, 1, 2 nazývané supervisor mode, ve kterém běží hypervizor a vnější kruh user mode pro uživatelské aplikace. Důvodem k této změně je skutečnost, že i virtuální operační systém vyžaduje ke svému provozu ”svůj” kruh 0. Z důvodu izolace hypervizoru od virtuálních systémů tedy dochází k přesunu kruhu 0 virtuálního OS směrem ven, tedy do jednoho z kruhů 1, 2 nebo 3. Prezentaci kruhu 0 virtuálnímu OS má na starosti Virtual Machine Monitor, zkráceně VMM. Na druhé straně pak VMM zajišťuje komunikaci s hardware. V závislosti na umístění VMM dělí Williams (2007) virtualizační software do dvou skupin: • Typ 1 – VMM běží přímo nad hardwarovou platformou, tedy na skutečném kruhu 0. Kruh 0 virtuálního OS pak běží na vyšším kruhu. Dochází tedy ke skutečné izolaci virtuálního stroje. • Typ 2 – VMM běží v operačním systému, většinou až jako uživatelská aplikace, tedy v kruhu 3. Dochází tedy pouze k logické izolaci. Virtualizační technologie dělí Hoopes (2009) do tří hlavních skupin – plná virtualizace, paravirtualizace a kontejnerová virtualizace. 3.1.1

Plná virtualizace

Základem plné virtualizace je běh kompletního systému uvnitř jiného. Jedná se o plnou abstrakci na úrovni systému, virtualizovaný systém tedy vůbec netuší, že běží uvnitř jiného. Plná virtualizace má díky tomu nejširší možnosti, co se virtualizovaného systému týče. Výhody: • Hlavní výhodou je právě úplná izolace hypervizoru od hostů. Virtuální operační systém tak může být instalován bez jakýchkoliv modifikací. • Díky plné abstrakci má zdaleka nejširší výběr podporovaných systémů pro hosty. Nevýhody: • Nutnost emulovat všechen hardware a tím pádem poskytovat abstrakční mezivrstvu pro všechny hardwarové funkcionality znamená fixní režii ve výkonu. • Vyžaduje hardwarovou podporu, například v případě procesorů AMD se jedná o AMD-V, v případě procesorů Intel pak o VT-x. 3.1.2

Paravirtualizace

Virtualizační technologie využívající pouze částečné abstrakce hardware za cenu nutné podpory API hypervizoru operačním systémem virtálního hosta. Výhodou

3.1

Virtualizace a výpočetní výkon

19

oproti plné virtualizaci je absence nutnosti emulace veškerých operací nad hardwarem. Nevýhodou je pak právě nemožnost kombinace různých operačních systémů na guestech a hypervizoru. Výhody: • Implementačně jednoduché prostředí. • Především pokud není k dispozici patřičná hardwarová podpora, tak se jedná o nejvýkonnější virtualizační řešení, především co se síťové vrstvy a I/O týče. Nevýhody: • Operační systém hosta nemůže běžet bez úprav, je zapotřebí mít podporu komunikace s API hypervizoru. • Z výše uvedeného důvodu není bez netriviálních úprav např. možné spustit Windows na Linuxovém hypervizoru a naopak. • Nízká přenositelnost hostů, úzká vazba na verzi a kompatibilitu jádra hypervizoru a jeho virtualizačního API. 3.1.3

Virtualizace na úrovni operačního systému (kontejnery)

Hypervizor i host sdílejí stejný operační systém, jedná se tak vlastně o několik izolovaných prostředí v rámci jednoho systému. Mezi jednotlivými kontejnery je však virtualizační mezivrstva, která umožňuje komunikaci s hostem a přiděluje mu systémové prostředky. Výhody: • Téměř nativní výkon hosta. • Host podporuje všechny hardwarové a systémové funkce jako hypervizor. • Údržba a správa jediného prostředí. Nevýhody: • Není možné kombinovat různé operační systémy. • Nižší úroveň izolace operačního systému hosta. • Nižší možnosti zabezpečení než u řešení s vyšší úrovní abstrakce. 3.1.4

Virtualizační software

Při výběru vhodného řešení je nutné zvážit klady a zápory jednotlivých řešení, výsledný výběr pak bude vždy vysoce individuální podle potřeb aktuálního projektu, případně i podle zvyklostí architekta řešení. Virtualizačních softwarů vhodných pro serverový provoz je v současné době k dispozici hned několik. Mezi nejnasazovanější jak je uvádí Turnbull, Matotek, Lieverdink (2009) patří: • VMware – přestože firma VMware nabízí volně nasaditelné produkty, portfolio pro enterprise a plnohodnotnou serverovou virtualizaci jsou ryze komerční.

3.2

•

•

•

•

3.2

Hardware

20

Avšak vzhledem k faktu, že VMware je hlavním hráčem na trhu s virtualizačními produkty, je vhodné zmínit jej i zde. KVM – primární virtualizační řešení na mnoha Linuxových distribucích. KVM má v Linuxovém světě obrovskou výhodu oproti všem ostatním konkurentům, a tou je přímá integrace s jádrem. Na rozdíl od ostatních produktů vyžadujích vlastní operační systém nebo instalovaných nad operačním systémem jako aplikace je KVM pouze dalším modulem kernelu. Z toho těží KVM především plnou integrovaností do Linuxového systému a snadnou interoperabilitou s libovolnými komponentami systému bez nutnosti nasazování proprietárních nástrojů a řešení. Podporuje pouze plnou virtualizaci. Xen – open source projekt původem z Univerzity v Cambridge nabídl při svém uvedení v té době originální pojetí virtualizace – paravirtualizaci – a tento směr zůstal jeho primárním zaměřením dodnes. Přesto zvládá Xen i plnou virtualizaci. OpenVZ – představitel kontejnerového přístupu k virtualizaci. Aplikace jsou spouštěny spíše v prostředí podobném chrootu, jen se jedná o operační systém. Nevýhodou je nutnost spuštění virtuálního operačního systému vždy a pouze na stejném jádře jako má hypervizor, naopak výhodami těsné integrace je rychlost, efektivita a stabilita. VirtualBox – poslední virtualizační software je vhodný spíše pro desktopovou virtualizaci a testovací účely. Jedná se o aplikaci v userspace systému, takže je velmi nenáročná na nasazení a jako jediná přímo podporuje běh na Windows i Linuxu. Nevýhodou je však právě nízký stupeň integrace s operačním systémem a aplikační emulace virtuálního systému.

Hardware

Důležitým faktorem pro nasazení řešení je také výběr hardware, na kterém vše poběží. Při využití virtualizace a dnešním výkonu serverů je zbytečné, aby každou službu pokrýval jeden nebo více vyhrazených fyzických strojů. Pro první fázi nasazení řešení je absolutně postačující, aby v každým uzlu byly umístěny dva fyzické servery s dostatečnými parametry. Při správném návrhu tak bude dosaženo plné dostupnosti i při výpadku jednoho fyzického serveru v rámci uzlu, případně při výpadku jednoho celého uzlu. Vhodnými kandidáty pro obecný návrh jsou pak servery splňující následující parametry: • • • • •

redundantní napájení, možnost osazení více procesory, podpora dostatečné kapacity vysokorychlostních pamětí RAM, více diskových slotů, podpora hot-swap disků,

3.3

Síťová topologie

21

• minimálně 2x 1Gbps NIC, pro pokročilejší infrastrukturu i 4x. V současné době se však jedná o relativně běžné požadavky, které splňuje velká množina produktů různých výrobců. Příkladem mohou být: • SuperServer 8026B-6RF 1 – výrobce Super Micro Computer, Inc.; – 2U rackmount; – až 4 procesory Intel Xeon série 7500 a E7-4800; – až 1TB RAM v 32 DIMM socketech; – až 6x 3.5” Hot-swap SAS/SATA pevný disk; – 2x hot swap redundantní zdroj; • ProLiant DL380p Gen8 Server 2 – výrobce Hewlett-Packard; – 2U rackmount; – až 2 procesory Intel Xeon E5-2600; – až 768GB RAM ve 24 DIMM socketech; – až 8x 2.5” nebo 3.5” SAS/SATA pevný disk; – 2x hot swap redundantní zdroj; • PowerEdge R820 3 – výrobce Dell; – 2U rackmount; – až 4 procesory Intel Xeon série E5-4600; – až 768GB RAM ve 24 DIMM socketech; – až 16x 2.5” SAS/SATA pevný disk; – 2x hot swap redundantní zdroj. Dva fyzické servery tohoto typu v rámci jednoho uzlu jsou postačující pro vytvoření a provoz infrastruktury navrhované v rámci této práce.

3.3

Síťová topologie

Základem zajištění vysoké dostupnosti a stability každé IT infrastruktury je vhodný síťový návrh. Síťové aplikace a systémy se pro mnoho společností staly kritickými a u některých na nich stojí samotná existence. Trendem poslední doby je manažerský cíl mít dostupnost služeb na úrovni 99,99 %. Mnozí si však neuvědomují, že tohoto cíle není možné dosáhnout především ve větších infrastrukturách bez nemalých finančních a personálních nákladů. Přesto se často jedná o částky nesrovnatelně nižší, než je výše ztráty v případě byť jen krátkého výpadku. Moderní síť musí splňovat 1

Zdroj: http://www.supermicro.com/products/system/2U/8026/SYS-8026B-6R.cfm [cit. 2013-03-25]. 2 Zdroj: http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/15351-15351-3328412-241644241475-5177957.html?dnr=1 [cit. 2013-03-25]. 3 Zdroj: http://www.dell.com/us/business/p/poweredge-r820/fs [cit. 2013-03-25].

3.3

Síťová topologie

22

náročné požadavky týkající se především škálovatelnosti, flexibility a dostupnosti, jak uvádí Arregoces, Portolani (2004): • Škálovatelnost – musí podporovat rychlý a bezešvý růst sítě bez potřeby výrazných změn. • Flexibilita – musí umožňovat nasazení nových služeb bez významných infrastrukturních zásahů. • Vysoká dostupnost – řešení nesmí mít tzv. single point of failure a musí umožňovat návrat k plnému provozu v minimálním pevně daném časovém intervalu (po kritické chybě). Zatímco jednoduchou funkční síť je možné zapojit během pár minut, dosažení plnohodnotných atributů potřebných v enterprise prostředí vyžaduje zahrnutí analytické a designové části před samotné nasazení. V průběhu let se postupnou prací síťových expertů vyvinul základní a nejrozšířenější model používaný v současných sítích, rozdělující síťovou topologii do diskrétních vrstev. Každá vrstva má vlastní účel a také definuje specifické funkcionality, umožňující výběr a implementaci optimální konfigurace pro dané nasazení. Tento přístup se nazývá hierarchická topologie a jak uvádí (Oppenheimer, 2010), typicky zahrnuje: • Core vrstva – nejvýkonnější high-end routery a switche optimalizované pro maximální dostupnost a výkon. Zprostředkovávají optimální transport do Internetu a mezi jednotlivými pobočkami nebo uzly. • Distribuční vrstva – routery a switche implementující definované síťové politiky týkající se bezpečnosti, směrování a rozdělování provozu. V malých a středních návrzích bývá core a distribuční vrstva často spojená. • Přístupová (access) vrstva – připojení koncových uživatelů a zařízení. V případě designu WAN sítě jsou pak zařízeními přístupové vrstvy hraniční routery připojovaných sítí.

Obr. 3: Obecná redundantní hierarchická topologie

3.3

Síťová topologie

23

Velkou výhodou hierarchického modelu je možnost kapacitního plánování a snadného rozšiřování na jednotlivých vrastvách bez nutnosti větších zásahů do existujícíc síťové topologie, zpravidla jen nákupem vhodného zařízení, zapojení na své místo a triviálním zásahem síťového administrátora. Striktní oddělení vrstev zase usnadňuje správu, každý element sítě má svou jasně definovanou roli, je elementární a snadno zdokumentovatelný. Striktní definice funkcionalit zase usnadňuje testování, neboť umožnuje definovat jasně dané postupy v případě problému, stejně tak je jednodušší detekce chyby a izolace dopadu případného incidentu. Důležitá je skutečnost, že hierarchický model je univerzální. Není využitelný jen na běžnou kampusovou nebo vnitroponikovou síť, ale také na sítě ISP a WAN. V tom případě se pouze mění role jednotlivých routerů. Jak je již naznačeno v popisu jednotlivých rolí, router který je core zařízením v kampusové síti, tak může vystupovat jako access zařízení v návrhu ISP. Deployment do existujícího datového centra samořejmě není vhodný pro plnohodnotný síťový návrh s plným rozlišením všech vrstev obecného modelu, respektive se dá říci, že vyšší vrstvy jsou realizovány provozovatelem datacentra. Obecný návrh takového řešení je tedy zjednodušen na přístupovou vrstvu v plné správě provozovatele řešení a agregační vrstvu, plně nebo částečně v režii poskytovatele housingu. Tento zjednodušený návrh je názorně vidět na obr. 4. (Arregoces, Portolani, 2004)

Obr. 4: Zjednodušený návrh topologie v rámci datacentra

Nad takto zjednodušenou topologií konkretizovanou za svým účelem je již možné definovat klíčové služby na jednotlivých vrstvách. Agregační vrstva zastává na 3. vrstvě primárně role týkající se IP konektivity koncových zařízení a na 2. vrstvě

3.3

Síťová topologie

24

pak redundantní mezivrstvu mezi přístupovou a agregační vrstvou. Klíčové funkce agregačních prvků na 3. vrstvě jsou: • Forwarding paketů na základě L3 informací mezi servery a zbytkem sítě. • Udržování aktuálních informací o routingu a reakce na dynamické změny v routování. • Zajištění plné dostupnosti bran pro servery. Na druhé vrstvě pak zajišťují agregační switche následující funkcionality: • Spanning Tree Protocol (STP) mezi agregační a přístupovou vrstvou kvůli eliminaci smyček v síti. • Případné rozšíření nad rámec STP, jako jsou například RPVST, Uplinkfast nebo Loopguard. Mnoho těchto rozšíření však může být závislých na výrobci daného zařízení. • VLANy pro logickou separaci provozu. • Další služby v závislosti na nasazení, jako jsou QoS, omezení šířky pásma, access listy, bezpečnostní rozšíření apod. Prvky na přístupové vrstvě zajišťují v zásadě pouze přímou konektivitu serverů, ta však musí být naprosto dokonale spolehlivá a bezvýpadková. Konektivitu na mezi přístupovou a agregační vrstvou zajišťuje: • EtherChannel mezi switchi na agregační vrstvě. Kanál je v trunk módu, zahrnujícím veškeré interní VLAN. • Jeden nebo více uplinků z každého access switche, opět konfigurovány jako trunky. • Redundantní zapojení síťových karet serverů s automatickým failoverem. Jak ovšem také uvádí Sakandar (2005), návrh přístupové vrstvy postavený na 2. vrstvě je sice nejklasičtějším, ale ne jediným možným. Za zvážení může stát alternativa s využitím 3. vrstvy u Access switchů. Důvodem k tomuto kroku je nejčastěji snaha zbavit se Spanning Tree Protokolu z důvodu jeho relativně pomalé konvergence a topologie se smyčkami, která může při nevhodné manipulaci způsobit nepříjemné síťové problémy. Výhody L2 přístupové vrstvy však většinou převládají. Servery stejné funkcionality jsou sjednoceny v jedné VLAN, stejně jako mohou mít v jejich VLAN vyveden interface servery, které s nimi potřebují přímo komunikovat – nejtypičtějším případem může být interface aplikačního stroje v databázové VLAN. Tyto servery mají následně vzájemnou L2 konektivitu a komunikují bez účasti prvků 3. vrstvy. Horizontální růst sítě je také flexibilnější a je relizován pouze přidáváním access switchů. Nedílnou součástí síťové vrstvy je pak posktytování síťových služeb, tedy především DNS a DHCP, firewalling, loadbalancing a definování služeb zajišťujících redundanci na síťové vrstvě místo redundance zajištěné aplikačně.

3.3

Síťová topologie

25

Návrh je tedy vhodné rozdělit na část týkající se komunikace v rámci jediného uzlu a na část týkající se globální komunikace. Ty zahrnují: • komunikace v rámci uzlu – interní komunikace v rámci uzlu, – klientský přístup ke konkrétnímu uzlu, • globální komunikace – interní komunikace mezi uzly, – výběr a směrování klienta ke konkrétnímu uzlu. 3.3.1

Komunikace v rámci uzlu

Navržení komunikace v rámci uzlu je závislé především na připojení a umístění uzlu. Zatímco pokud stavíme a realizujeme vlastní datacentrum, budeme pravděpodobně navrhovat komplexní třívrstvou architekturu se striktním oddělením vrstev a funkcionalit. Oproti tomu, pokud realizujeme menší řešení v rámci komerčního serverhousingu, případně dokonce využíváme nějaké formy pronájmu hardware nebo full-managed serverů, budeme vlastními silami realizovat pravděpodobně pouze jistou kombinaci access a distribuční vrstvy. Redundance na access vrstvě I u minimálního vlastního návrhu v rámci připojení v komerční servrovně je nutné zajistit základní odolnost proti výpadku síťového prvku nebo linky na access vrstvě. Jedinou možností jak toho dosáhnout, je zdvojení konektivity na uplinku koncového zařízení, tzv. multihoming. Koncový server je tak připojen na jeden nebo více prvků access vrstvy více síťovými porty. Tato konfigurace vyžaduje podporu na síťové kartě, nicméně v současnosti se jedná o samozřejmost. Jak uvádí Arregoces, Portolani (2004), většina výrobců umožňuje konfiguraci připojení více porty (často označovanou jako NIC teaming) třemi způsoby: • Fault tolerance – jeden port nebo karta je aktivní (přijímá a vysílá), zatímco ostatní porty jsou standby (nepřijímají ani nevysílají). Pokud aktivní port selže, jeho úlohu převezme jeden ze standby portů a sám se stane aktivním. • Load balancing – pouze jeden port přijímá, ale všechny zapojené porty vysílají. Pokud port který přijímá selže, jeho úlohu převezme jeden z ostatních portů. • Link aggregation – všechny zapojené porty dohromady tvoří jednu logickou linku s šířkou pásma odpoovídající součtu pásem jednotlivých linek. Názorně jsou jednotlivé varianty zobrazeny na obr. 5. VLAN Druhou oblastí, kterou je v rámci interního návrhu zvážit je rozvržení VLAN neboli virtuálních LAN. VLAN je definována jako logický segment lokální sítě (LAN), který je však fyzicky rozšířen přes rozsáhlejší síť. Pro připojení koncového systému

3.3

Síťová topologie

26

Obr. 5: Redundance na access vrstvě

do konkrétní VLAN je access port nadefinován s odpovídajícím číslem VLAN a veškerý provoz je následně již v hlavičkách druhé vrstvy tagován – do hlavičky jsou přidány 4 B s informací o číslu virtuální sítě. Pro koncový systém je tak zařazení do VLAN transparentní oproti běžnému zapojení. Nejběžnějším a nejpoužívanějším standardem VLAN je tagovací protokol IEEE 802.1Q. Pro komunikaci na agregačních linkách, kde je zapotřebí mít povolen provoz více VLAN se používá tzv. trunk, který umožňuje komunikaci všemi povolenými VLANami. Veškerá zařízení v rámci stejné VLAN tak mohou komunikovat jakoby byly částí stejného segmentu LAN nezávisle na fyzické topologii. (Dooley, 2009) K rozvržení VLAN existuje několik přístupů vhodných pro různě velké a nasazované infrastruktury. Pro naše použití je nejvhodnější rozdělení VLAN podle funkcí, vznikají tedy například databázová, aplikační nebo management VLAN. (Arregoces, Portolani, 2004) Kombinace duálně zapojených serverů a rozšíření VLAN mezi zapojenými switchi s sebou přináší vznik smyčky. Jak již bylo zmíněno výše, o tento problém se stará Spanning Tree Protocol, který zajistí zablokování redundantních linek a zamezí tak existenci smyčky. Síťové služby Cluster připravovaného rozsahu se již neobejde bez vlastních sady síťových služeb, především DHCP a DNS. DHCP zjednodušuje správu definovaných IP rozsahů a distribuci IP adres mezi uzly. DNS je pak využíváno jak pro interní sítě z důvodu překladů itnerních názvů strojů, tak z důvodu plných možností správy DNS informací dostupných klientům. DNS neboli Domain Name System je systém pro překlad mezi doménovými jmény a adresami. Používání názvů je pro člověka mnohem jednodušší než pama-

3.3

Síťová topologie

27

tování si číselných adres, proto byl zaveden hierarchický systém jejich dopředného i zpětného překladu. Doménu představuje jednoduše podstrom globálního jmenného prostoru. Kořenem stromu je tzv. kořenová doména, označovaná tečkou. Od kořene až po koncový uzel je vedena hierarchie unikátních jmenných označení oddělených tečkou. Přímo pod kořenem jsou tzv. domény nejvyšší úrovně, označované jako TLD (Top Level Domain). TLD jsou v zásadě dvojího druhu, tedy tematické nebo státní. Každá doména může být rozdělena na neomezený počet subdomén, které mohou být dále delegovány. (Liu, Albitz, 2009) Mechanismus si můžeme ukázat na příkladu univeriztní domény mendelu.cz.. Základ je tvořen kořenem, tedy ’.’. Kořenová doména běžbě nebývá uváděna a ve většině případů použití není nezbytná, nicméně pro administrátory a správce DNS serverů je její znalost a použití nutné. TLD je pak tvořena národní doménou České republiky, tedy cz. Subdoména mendelu je již ve správě univerzity jako organizace, na kterou je delegována správcem domény nejvyšší úrovně - CZ.NIC, z. s. p. o. Univerzita pak má možnost dále doménu dělit na subdomény a ty delegovat na jejich správce, příkladem by mohla být např. delegace domény pef.mendelu.cz na fakultní administrátory. Překlad probíhá prostřednictvím DNS serverů. Server na který je delegována správa dané subdomény se nazývá autoritativní a je zdrojem dat o dané doméně. Systém autoritativních serverů by sice byl teoreticky postačující, každý koncový klient by však musel začínat hledání od kořenového nameserveru. Z důvodu snížení zátěže na kořenové servery a zrychlení provozu na koncových systémech byl vyvinut systém tzv. caching nameserverů. Caching servery provedou po dotazu zjištění odpovědi za pomoci rekurze a získané údaje uloží na dobu specifikovanou TTL (time to live) do své interní paměti. Na tuto adresu se pak následně nemusí do uplynutí TTL dotazovat a vrací ji přímo (klient však může rekurzi vynutit). Popsaný systém umožňuje kromě poskytování informací klientům rozlišit také překlady interního jmenného prostoru od veřejného prostoru a s výhodou tak využít interní adresace pro management infrastruktury podobně, jakoby se jednalo o běžnou veřejnou síť. Vzhledem k tomu, že obě služby jsou kritické a musí být dostupné jak všem serverům v rámci uzlu, tak v případě DNS i klientům, je logickým krokem umístění těchto služeb na loadbalancery, u kterých je zajištěna plná dostupnost a které jsou dalším kritickým bodem dostupnosti celého řešení. Firewall Bezpečnost je ve světě počítačových systémů vždy komplikovanou záležitostí se dvěma protichůdnými pohledy. Vyšší míra zabezpečení komplikuje konfiguraci a ztěžuje následnou správu a běžnou práci se systémem. Naopak nedostatečné zabezpečení může mít za následek ztrátu citlivých dat, ztrátu kontroly či funkcionality a v nejzažším případě i nutnost obnovy celého systému. Nejběžnějším přístupem je umístění centrálního stroje, který připojuje jednu nebo více dedikovaných podsítí se sadami vnitřních strojů k vnější síti – ať už pod-

3.3

Síťová topologie

28

nikové nebo internetu. Jediný přístup dovnitř vyhrazené sítě je přes tento vyhrazený stroj. Tento model následně většinou počítá s maximálním zabezpečením na centrálním serveru, zatímco uvnitř platí podstatně méně důrazná bezpečnostní opatření, často býva síť považována za plně důvěryhodnou a je ostatním strojům v rámci stejné podsítě otevřená. Tento model výrazným způsobem zjednodušuje konfiguraci paketového filtru a snižuje zátěž na vnitřní komunikaci. Není samozřejmě možné opominout vnitřní bezpečnost úplně, ale rozdíl mezi zabezpečením komunikace různých typů z několika oddělených sítí může být ve velkých clusterech docela problém, centralizací vnějšího provozu je tento problém podstatně zjednodušen. Linux disponuje pokročilým stavovým firewallem zabudovaným přímo v jádře systému, bude tedy využit v řešení. 3.3.2

Globální komunikace

Na úrovni globální komunikace je nutné zabývat se především možnostmi rozdělení zátěže od klientů mezi koncové servery a dále zabezpečením komunikace jednak mezi jednotlivými uzly a jednak citlivé komunikace mezi klientem a serverem. Zabezpečení transportní vrstvy Zabezpečení transportní vrstvy je absolutní nutností u jakéhokoliv typu komunikace, při kterém jsou veřejnými sítěmi přenášeny citlivé informace. Typicky se jedná o autentizační údaje a e-commerce komunikaci. Nejčastěji používanou metodou zabezpečení komunikace je šifrování pomocí protokolu SSL nebo jeho následovníka TLS. Tyto protokoly zajišťují kontrolu integrity a šifrování přenášených dat, ověření serveru a volitelně další funkcionality jako jsou komprese a autentizace klienta. SSL/TLS zabezpečení využívá technik asymetrického šifrování za účelem bezpečné výměny klíčů, symetrického šifrování k zajištění důvěrnosti přenášených informací a MAC funkcí pro ověření integrity dat. V první fázi komunikace dojde k tzv. handshake, během kterého si obě strany vymění informace potřebné k ustavení komunikačního kanálu (verze protokolu, nastavení šifrování, atd.). S využitím těchto údajů dojde k ověření identity serveru, vytvoření a výměně klíče pro zabezpečení vlastní komunikace. Výhodou SSL/TLS protokolů je, že je možné je použít v zásadě pro jakoukoliv aplikaci postavenou nad transportními protokoly TCP/IP. Ověření klíčů však probíhá na straně aplikace, ta musí mít podporu pro tento typ komunikace. Není tedy možné nasadit SSL/TLS zapouzdření zcela transparentně pro jakoukoliv aplikační komunikaci. V našem případě se jedná především o zabezpečení komunikace s webserverem, tedy použití protokolu HTTPS místo HTTP tam kde je toho zapotřebí. Všechny běžně využívané webové servery šifrovanou komunikaci nativně podporují, využití SSL/TLS je tedy po zapnutí plně v rukou aplikace.

3.3

Síťová topologie

29

Rozdělení zátěže Loadbalancing je metoda rozdělení zátěže mezi více koncových zařízení, ať už se jedná o servery, síťová zařízení, prosté disky, nebo jakékoliv jiné zdroje. Důvodem je dosažení maximální propustnosti a optimalizace využití výpočetních zdrojů. Využití více koncových komponent je také častým prostředkem ke zvýšení dostupnosti. Metod a mechanismů pro dosažení loadbalancingu je mnoho, stejně jako možností jejich konfigurace tak, aby optimalizovala provoz přesně podle požadavků konkrétního řešení. V UNIXovém světě webových portálů je pravděpodobně nejrozšířenějším a nejucelenějším projektem Linux Virtual Server (dále jen LVS). Principem fungování LVS je umístění centrálního serveru pro veškerou komunikaci, takzvaného loadbalanceru. Ten na jedné straně obstarává veškerou komunikaci s klientem a dále rozděluje provoz rovnoměrně mezi jednotlivé aplikační servery ve vnitřním prostředí clusteru na straně druhé. Je to server, který jako jediný z celého clusteru musí mít nějakou VIP (Virtual IP) a který je na této IP viditelný z vnější sítě. Adresa, na které komunikuje s vnitřním prostředím clusteru se nazývá DIP (Director IP). Vnitřní síť pak obsahuje libovolnou strukturu tzv. reálných serverů, které obstarávají vlastní zpracovávání požadavků od klientů. Každý z těchto uzlů komunikuje s direktorem na své RIP (Real IP). Existují tři typy nasazení LVS: • LVS-NAT – tato metoda využívá běžného principu network address translation (NAT), kdy jedna skupina IP adres je mapována na jinou. V tomto případě přijde požadavek na VIP loadbalanceru, který vybere podle zvoleného scheduling mechanismu cílový server a na jeho RIP je odeslán požadavek. Odpověď je následně doručena zpět loadbalanceru, kde je přepsána zdrojová adresa odpovědi zpět na VIP. • LVS-DR – Metoda přímého směrování (direct routing) se od metody překladu síťových adres liší především v tom, že reálné servery uvnitř clusteru neposílají své odpovědi zpět na direktor, ale přímo na klienta. Klient tedy pošle svůj požadavek na VIP direktora, ten jej forwarduje na RIP reálného serveru. Tam je požadavek vyřízen a poslána odpověď přmo na klientský počítač. Jako zdrojová adresa odpovědi je ponechána adresa VIP, takže klient si nadále myslí, že komunikoval s jediným strojem, zatímco svůj požadavek poslal na jeden a odpověď dostal od jiného. • LVS-TUN – Tato metoda nachází využití v případě, že nechceme mít všechny reálné servery na stejném segmentu sítě jako direktor. Využito je k tomu IP tunelování, které je integrovanou součástí linuxového jádra. Technika forwardování paketů je při využití této metody v podstatě stejná jako u metody LVS-DR, avšak je vylepšena o možnost zapouzdření požadavků přicházejících z klientských počítačů, takže mohou být doručovány na vnitřní uzly cluster serveru, které nejsou na stejné podsíti nebo VLAN. V navrhovaném řešení jsou pro reálné servery vyhrazeny neveřejné IP adresy

3.3

Síťová topologie

30

a servery jsou v rámci uzlu umístěny do jedné sítě, takže je plně vyhovující varianta LVS-NAT. Komunikace mezi uzly Mezi jednotlivými uzly je třeba zajistit bezpečený komunikační kanál pro přenos citlivých informací a management. Na rozdíl od zabezpečení transportní vrstvy mezi klientem a serverem je zde však nežádoucí jednak nutnost podpory na straně aplikace a jednak navazování point-to-point tunelu. Typ zabezpečení na této úrovni musí být zcela transparentní, což znemaná, že musí být přítomen na jedné z nižších vrstev komunikace, než mezi aplikační a transportní. Zároveň nesmí být vytvářen a navazován nový tunel při každém novém spojení mezi dvěma vzdálenými zařízeními z důvodu časové i výkonové náročnosti prováděných úkonů. Pro veškerou komunikaci mezi dvěma uzly musí být stále dostupný a trvale navázaný komunikační kanál. Popsaný způsob spojení se nazývá site-to-site VPN, tedy privátní síť určená ke komunikaci mezi dvěma vzdálenými lokacemi. Site-to-site VPN jsou klasifikovány podle několika hledisek: • VPN provozované providerem – typy VPN provozované na úrovni ISP. Koncový zákazník (v tomto případě například provozovatelm infrastruktury v rámci datacentra) není schopen tyto typy VPN realizovat bez spolupráce se svým poskytovatelem služby. • VPN provozované zákazníkem – zákazník si VPN nasazuje, provozuje a spravuje sám. V závislosti na síťové vrstvě, na které VPN funguje pak dělíme VPN na: • L2VPN – VPN realizované na druhé vrstvě, např. VPWS, VPLS a IPLS, • L3VPN – VPN na třetí síťové vrstvě, např. BGP/MPLS, VR, IPsec, GRE a IPin-IP, kde L2VPN jsou převážně typu provozovaného providerem. Koncový zákazník většinou nemá přímou L2 konektivitu na geograficky vzdálené lokality. Pro nasazení VPN je podle Lewis (2006) vhodné zvážit mnoho faktorů, zahrnujících především: • bezpečnost – jaké poskytuje možnosti šifrování a autentizace, • podporované topologie – jaké síťové topologie podporuje a jak snadná je na nasazení, • point-to-point nebo multipoint – je s jedním nastavením možné spojení pouze dvou bodů, nebo je možné s jednou konfigurací řešit připojení any-to-any, • geografická dostupnost – jsou geograficky (a síťově) vzdálené lokality dostupné po internetu, nebo jen za využití sítě providera, • podpora protokolů – zda umožňuje transport libovolného protokolu, • podpora QoS – podpora prioritizace síťového provozu.

3.4

Úložiště

31

Podle zadaných kritérií vychází pro náš případ použití ideálně IPsec, který je point-to-point s komunikací přes navázané P2P tunely, neumožňuje použití libovolného protokolu (nicméně pro naše použití nic jiného než rodinu IP protokolů nepotřebujeme), umožňuje spojení přes libovolnou IP síť, nemá přímou podporu multicastu, podporuje QoS a poskytuje excelentní bezpečnostní mechanismy. Pokud bychom nutně potřebovali podporu multicastu nebo jiných protokolů než rodiny IP, můžeme zvážit použití GRE VPN, která je v ostatních ohledech srovnatelná, nicméně poskytuje podstatně nižší úroveň zabezpečení.

3.4

Úložiště

Poskytnutí prostoru pro uložení dat dostupných následně odkudkoliv se již dříve ukázalo velmi lukrativním krokem a poskytování této služby tedy logicky zapadá neoddělitelně do portfolia nutných služeb. Zavádíme termín Storage as a Service (neplést s akronymem SaaS, Software as a Service), definující prostor na úložišti třetí strany, poskytnutý koncovému uživateli, pro kterého je tato varianta výhodnější z hlediska finančního, kapitálového, nebo z důvodu nedostaku technického personálu, schopného potřebnou infrastrukturu implementovat a spravovat. V našem případě pak znamená oddělení storage jako samostantou funkční i fyzickou doménu, poskytovanou dle potřeby ostatním komponentám komplexní infrastruktury. (Velte, Velte, Elsenpeter, 2009) Obrovskou výhodou přístupu typu Storage as a Service, i v prostředí privátního cloudu, je především dostupnost dat. Data jsou uložena na několika fyzických serverech místo dedikovaného úložiště používaného při tradičním uložení dat. (Mahmood, Hill, 2011) 3.4.1

Typy datového úložiště

Základem každého provozu týkajícího se ukládání dat a I/O obecně je initiator (zdroj, klientská část komunikace) na jedné straně a cíl (serverová část kominikace) na straně druhé. Tyto dva základní prvky existují u každého zmíněného typu úložiště. Initiator zahajuje I/O operace, které vyžadují odpověď cíle. Z hlediska názvosloví je vhodnější zavedení pojmenování zdroj . cíl, než server . klient, neboť entita označovaná jako server z hlediska jednotlivých vrstev globální architektury zde může stát na obou stranách komunikace, případně může fungovat současně jako zdroj i cíl. Cíl může být jak uvádí (OpenStack Foundation, 2013) blokového, souborového, objektového nebo obecně servisně orientovaného typu. • Blokové úložiště – data jsou vystavena na základě nízkoúrovňového rozhraní, např. SCSI nebo ATA, které je dostupné po síti. Blokové úložiště je často považováno za synonymum SAN (storage area network). Klienti přistupují k datům skrze operační systém na úrovni blokového zařízení, dostupného na definovaném mount-pointu stejně jako kdyby přistupovali k lokálnímu zařízení.

3.4

Úložiště

32

Tento přístup nabízí z hlediska přístupu nejuniverzálnější typ úložiště. Protože je k němu přistupováno stejně jako k fyzickému zařízení, je koncový uživatel kromě vlastní práce s daty odpovědný také za nízkoúrovňové operace jako je vytvoření oddílů a filesystemu. Právě uvedené chování ke vzdálenému blokovému zařízení jako k lokálnímu však má za následek jeho největší nevýhodu, a to nemožnost využití jako sdíleného úložiště bez využití mechanismů, které toto umožňují – z Open Source např. DRBD. • Souborové úložiště – soubory jsou dostupné pomocí některého protokolu distribuovaného filesystemu. Souborové úložiště bývá označováno jako NAS (network attached storage). Klienti přistupují k datům přes operační systém na souborové úrovni, tedy připojením vzdáleného souborového systému, např. NFS, CIFS nebo GFS. Nevýhodou přístupu je fakt, že operační systém musí umožňovat podporu použitého filesystemu na klientech. • Objektové úložiště – k souborům je přistupováno pomocí aplikačního protokolu, nejčastěji HTTP s typickým využitím REST API. Veškerý přístup k datům je realizován na aplikační úrovni – operační systém si přítomnosti vzdáleného úložiště není vůbec vědom. Podobně jako objektové úložiště s využitím HTTP protokolu je stejným způsobem na aplikační úrovni možné realizovat komunikační schéma optimalizované pro konkrétní nasazení. Objektové úložiště je však ze své podstaty pouze aplikační nádstavbou nad jedním ze dvou předchozích řešení a z infrastrukturního hlediska nemá zásadní význam. 3.4.2

Vysoká dostupnost úložiště

K dosažení vysoké dostupnosti u storage, podobně jako u ostatních komponent, je primárním cílem odstranění tzv. single point of failure, tedy byť jediného bodu, jehož selhání má za následek nedostupnost služby. V případě úložiště je dosažení tohoto cíle složitější o zajištění konzistence dat. Odstranění single point of failure v případě storage zahrnuje následující body: • Samotný server nebo specializované zařízení musí být vybaven dvěma síťovými kartami z důvodu síťové redundance, • nepřerušitelný zdroj napájení (UPS), v ideálním případě také redundantní zdroje napájení a generátor proudu, • replikace dat . lokální nebo vzdálená replikace dat jako ochrana proti ztrátě celého zařízení.

3.5

Databáze

3.5

33

Databáze

Nejběžnějším a také současně zdaleka nejrozšířenějším datovým úložištěm jsou relační databázové systémy díky možnosti rychle a efektivně ukládat, modifikovat a přistupovat k datům. V naší realizaci a clusterech obecně nacházejí další uplatnění díky elegantnímu sdílenému přístupu k datům, neboť například sdílený souborový systém není pro tento typ operace zdaleka tak vhodný, přestože masově nasazované implementace se dnes běžně vyskytují (OCFS, GFS, VMFS). Pro návrh relační databáze jsem vzhledem k jeho možnostem a majoritnímu podílu nasazení v řešeních tohoto typu vybral open-source databázový server MySQL. Pro náš případ použití přicházejí v úvahu dva základní způsoby přístupu k realizaci relační databáze: • databázové schéma, • plnohodnotná instance. Oba přístupy mají své výhody a nevýhody a jejich nasazení je třeba zvážit podle potřeb vývojářů a realizace celého výsledného řešení. Nic samozřejmě nebrání kombinaci obou variant (což je u velkých systémů také nejčastější). 3.5.1

Databázové schéma

Databázovým schématem v tomto případě myslíme sadu tabulek v databázovém systému s vlastní oddělenou sadou oprávnění, to vše však v rámci jedné běžící databázové instance. Toto nasazení se hodí pro logické oddělení skupin tabulek pro jednotlivé logické subsystémy projektu. 3.5.2

Plnohodnotná instance

U nadnárodních projektů a obecně projektů velkého rozsahu se oproti předchozímu případu setkáváme s velmi různorodými požadavky na výkon, parametry a úroveň přístupu k databázi. Realizace je možná dvěma způsoby: • Více databázových procesů na jednom operačním systému – přístup řízen buď vlastními sockety nebo síťovými porty. Výhodou je oddělení konfigurace • Více plnohodnotných systémů vyhrazených pro provoz databáze – tento model s výhodou využívá virtuálních serverů dále. Výhodou je možnost ponechat odpovědným správcům nebo vývojářům plný přístup až na úrovni operačního systému a absolutní oddělení hw prostředků. Nevýhodou je větší režie systémových prostředků. Obrovskou výhodou tohoto modelu je rozšířená možnost správy, škálovatelnost výkonu a oddělení správy jednotlivých databázových instancí již na úrovní systému. Není proto problémem poskytnout některým vývojářským nebo administrátorským skupinám plná oprávnění nad databázovým serverem nebo celým systémem, zatímco

3.5

Databáze

34

menší skupiny bez potřebného personálního zabezpečení využívají databázi jen na úrovni DDL nebo dokonce pouze DML operací. 3.5.3

Replikace

Databázová replikace je základním prvkem realizace velkých enterprise řešení. Replikace umožňuje nakonfigurovat jeden nebo více serverů jako repliky jiného, udržující data synchronizovaná s master serverem. Využití replikace je základem nejen vysokého výkonu systému, ale všech strategií týkajících se vysoké dostupnosti, škálovatelnosti, disaster-recovery, zálohování, analýzy, data warehousingu a mnoha dalších. (Schwartz, Zaitsev, Tkachenko, 2012) Replikací se podle Schwartz a kol. (2008) můžeme zabývat obecně z několika důvodů: • Distribuce dat – replikace dat obvykle není příliš náročná na šířku přenosového pásma a dá se nastartovat i zastavit dle libosti. Jako taková je vhodná ke kopírování dat do geograficky oddělené lokace, např. jiného datacentra. Vzdálené repliky mohou dokonce pracovat za přerušovaného spojení, nicméně pokud chceme při replikaci dosáhnout co nejměnšího zpoždění, potřebujeme stabilní linku s nízkou latencí. • Load balancing – replikace může pomoci rozdělit požadavky na čtení mezi více serverů, což je obzvláště výhodné u aplikací s intenzivním čtením. Základní load balancing je nenáročný na implementaci a je možné ho docílit s pár změnami v kódu. V malém měřítku je možné využít velmi zjednodušených mechanismů jako natvrdo zakódovaných IP adres nebo round robin DNS. Je však samozřejmě možné zvolit více sofistikovaný přístup, například síťového loadbalancingu, který může zajistit např. již dříve zmiňovaný The Linux Virtual Server. • Zálohování – replikace je významným pomocníkem při zálohování, přestože není plnohodnotnou náhradou záloh. • Vysoká dostupnost – replikace může pomoci odstranění databázového serveru jako ”single point of failure” provozu aplikace. Dobře nastavený failover systém s využitím replik může významně snížit dobu výpadku. • Testování upgradů – běžnou praxí je příprava repliky s upgradovanou verzí databázového serveru a následné ověření fungování dotazů před upgradem všech ostatních instancí. MySQL má z hlediska replikace relativně široké možnosti, i když kvalit komerčních systémů (např. Oracle) nedosahuje. MySQL replikace se skládá v zásadě ze tří kroků: 1. Master zaznamená změny ve svých datech do binary logu. 2. Replika si zkopíruje binary log master repliky do svého relay logu. 3. Replika provede události z relay logu nad svými vlastními daty.

3.5

Databáze

35

Každý uvedený krok je samozřejmě komplexní úkon. Zápis změn do binary logu probíhá v rámci každé transakce, při které dojde k libovolné změně dat. Teprve po zapsání všech událostí do binary logu dojde ke commitu transakce. Následuje kopie dat z binary logu do relay logu na repliku. Na replice proto vzniká separátní proces zvaný I/O slave thread, který si otevře klientské spojení na mastera a pomocí speciálního voláni binlog dump přečte události z binary logu. Signalizaci nových změn na masteru provádí sám master, replika se tedy periodicky neptá, ale čeká na informaci, že má zahájit synchronizaci. O poslední krok se stará opět vyhrazený proces, zvaný SQL slave thread. Ten čte události z relay logu repliky a přehrává je znovu na replice, čímž synchronizuje data podle masteru. Dokud stíhá SQL slave thread držet krok s I/O slave threadem, zůstává obvykle obsah relay logu v paměti, takže za běžného provozu dochází k velmi nízkému overheadu. Z hlediska chování rozlišujeme repliku jako master a jako slave. Různé kombinace master a slave chování replik umožňují tvorbu různých topologií, podle požadavků výsledného systému. Základní topologie jsou: • Jeden master a 1-n slave replik – základní a nejjednodušší model, slave repliky jsou na sobě nezávislé a všechny se připojují k master replice. Topologie je výhodná především v případě, že probíhá málo zápisů, ale mnoho čtení z databáze. Požadavky na čtení je totiž možné rozdělit mezi slave repliky a nevzniká výrazná zátěž způsobená přenosy změn na slave repliky. • Master-master v active-active módu – známá též jako dualmaster nebo obousměrná replikace. Zahrnuje dva servery, které jsou oba nakonfigurovány jak jako master, tak jako slave toho druhého. Obecně může při této konfiguraci dojít k mnoha problémům, především z důvodu konfliktních změn, ke kterým může na obou master replikách dojít. • Master-master v active-passive módu – jedná se o obdobu předchozího řešení, která řeší hlavní problémy active-active varianty. Jedna z master replik je i přes konfiguraci jako master pouze read-only (pasivní) replika. Vzhledem ke shodným konfiguracím je možné jednoduchým způsobem přepínat aktivní a pasivní roli mezi servery a tato varianta je tím pádem pro většinu instalací nejvhodnější z hlediska výpadku, zálohování i údržby. • Master, distribution master a slave repliky – řešení pro systémy, kde není majoritním typem provozu čtení, ale dochází k intenzivním zápisům. Zápisy, především s více slave replikami, mohou master repliku citelně vytížit. Proto je vyhrazena jedna slave replika, která je jediná synchronizovaná s master replikou a s ní jsou synchronizovány ostatní slave repliky. Dochází tak k rozdělení zápisu, replikace a čtení mezi specializované servery v rámci MySQL clusteru.

3.6

3.6

Doručení obsahu

36

Doručení obsahu

Klientská vrstva v tomto případě zahrnuje celý svět, což je zesložitění oproti projektům cíleným téměř výhradně na lokální uživatele. Pro doručení obsahu i k geograficky velmi vzdáleným uživatelům je třeba zvážit: • limity datacenter pro mezinárodní přenosy; • čas potřebný pro doručení obsahu z datacentra k logicky nejvzdálenějším klientům. V tomto případě je běžné rozdělení zdroje statického a dynamického obsahu – je možné oddělit doručení obsahu s krátkou nebo nulovou platností (dynamického obsahu) od doručení statického, ale zpravidla objemově náročnějšího obsahu. Obzvláště v poslední době se objevilo mnoho poskytovatelů tzv. CDN (Content Delivery Network), tedy sítí pro doručení obsahu, tento případ je pro jejich nasazení ideální. Termín Content Delivery Network (CDN) označuje službu, zajišťující distribuci především statického nebo multimediálního obsahu velkému množství klientů. CDN se stará především o: • přesměrování požadavku klienta nejbližšímu použitelnému CDN cache serveru; • doručení obsahu klientovi; • získání a distribuce obsahu ze zdrojového serveru na distribuovaných webserverech; • zajištění vysoké dostupnosti spravovaného obsahu. Realizace CDN vlastními silami je dokonce i pro většinu velkých společností buď finančně nebo technicky příliš náročná, proto je toto odvětví v poslední době velmi oblíbenou komerční službou. V případě realizace vlastními silami se nejedná o nijak složitou záležitost, CDN síť lze vystavět na kešovací proxy za využití některého z mechanismů výběru nejbližšího serveru. Jak uvádí Buyya a kol. (2008) závislosti na způsobu zpracování požadavku se CDN sítě dělí do následujících skupin: • Global Server Load Balancing (GSLB) – GSLB metoda je založena na rozmístění GSLB web switchů, které zajišťují vlastní load balancing na koncové cache servery. Na rozdíl od lokálního load balancingu, kdy loadbalancer zná informace o všech přímo napojených uzlech a podle definovaných metrik provádí výběr reálného serveru, zde je každý GSLB server vybaven plnou sadou informací o celé síti a IP adresách všech cache serverů. Tuto vlastnost u GSLB označujeme jako Global awarness. Z hlediska klienta se pak GSLB server chová jako Smart authoritative DNS, tedy v závislosti na stavu koncových cache serverů a umístění klienta vrátí nejvhodnější IP adresu koncového uzlu. • DNS-based request routing – metoda je založena na klasickém mechanismu round-robin DNS load balancingu, kdy jedno doménové jméno ukazuje na seznam IP adres. DNS server na požadavek vrátí celý seznam adres a klient

3.6

37

Doručení obsahu

si jednu adresu ze seznamu vybere. Jako příklad běžného nasazení slouží například překlad doménového jména google.com (obr. 6). Obrovskou výhodou tohoto přístupu je jednoduchost a transparentnost. Nevýhodou je pak absence vyšší inteligence při výběru oprtimálního koncového uzlu. # dig google.com ;; QUESTION SECTION: ;google.com. A~;; ANSWER SECTION: google.com. google.com. google.com. google.com. google.com. google.com. google.com. google.com. google.com. google.com. google.com.

IN 300 300 300 300 300 300 300 300 300 300 300

IN IN IN IN IN IN IN IN IN IN IN

A~173.194.39.96 A~173.194.39.102 A~173.194.39.100 A~173.194.39.99 A~173.194.39.101 A~173.194.39.98 A~173.194.39.105 A~173.194.39.104 A~173.194.39.97 A~173.194.39.103 A~173.194.39.110

Obr. 6: DNS round-robin na příkladu google.com

• HTTP redirection – metoda založená na vložení informace o cílovém serveru do HTTP hlaviček odpovědi ze serveru. HTTP redirect pak řekne klientovi, kde nalezne cílový obsah. Velkou nevýhodou této metody je netransparentnost a režie vyvinutá na dvojitou komunikaci se serverem – jednou s webserverem, který vrátí potřebný HTTP redirect a následně s vlastním cache serverem. • URL rewriting – mechanismus používá algoritmus pro výběr cache serveru již ve chvíli dynamického generování stránky. Pomocí modifikace URL pro statický obsah doručí klientovi kompletní stránku již s konkrétními odkazy na vybraný cache server. Výhodou této metody je, že je možné i za běžného provozu plně a přitom transparentně řídit loadbalancing na koncové cache servery. Zároveň může jeden klient dostat přiděleno i více cache serverů a zátěž se tak ještě více rozloží – s výhodou lze tedy využít kombinace s metodou DNS-based requestroutingu popsanou výše. • Anycasting – podstatou IP anycastingu je přidělení jedné IP adresy více uzlům. Routery v rozdílných sítích tedy drží routovací informace o jim nejbližších fyzických uzlech. Tyto koncové uzly, přestože jsou geograficky i síťově naprosto oddělené, však sdílí stejnou IP adresu. Rozšířením tohoto modelu je tzv. application-level anycast, kde IP anycastovou metodou jsou adresovány anycast resolvery, tedy DNS servery nejblíže klientovi, které následně provedou překlad

3.6

Doručení obsahu

38

Obr. 7: URL rewriting na příkladu www.seznam.cz, zobrazeno pomocí Nástrojů pro vývojáře Chrome

dotazovaného doménového jména na IP adresy opět vybrané podle zvolené metriky (výkon a zátěž koncových uzlů). Princip fungování tohoto mechanismu je takový, že IP anycastová adresa je propagována do intranetu nebo internetu z více routerů. Propagace je v rámci jednoho ISP možná buď za využití interního routovacího protokolu uvnitř jeho autonomního systému, nebo globálně v celém Internetu za využití protokolu BGP. Názorný příklad použití tohoto mechanismu je uveden v příloze B. • CDN peering – model založený na symetrickém spojení mezi všemi koncovými uzly držícími požadovaná data. Nejběžnější je model s centrálním registrem uložených dat, kterému všechny zapojené koncové uzly propagují informace o uložených datech a naopak se ptají, který uzel drží data která právě požadují. Tento model je s výhodou využíván především v uzavřených sítích, kde jsou ukládána lokální nebo velkoobjemová data, např. výzkumných sítích. Pro veřejné webové portály nejsou příliš využívány.

4

VLASTNÍ PRÁCE

4

39

Vlastní práce

4.1

Poskytnutí výpočetního výkonu

Vzhledem k obecnosti návrhu jsem pro realizaci vybral KVM, jakožto řešení přímo integrované do Linuxového jádra nabízející plnou abstrakci. Veškeré funkční servery v návrhu běží jako virtuály. To se může zdát zbytečné z hlediska režie a u jednoduchého portálu i z hlediska složitosti realizace a údržby. S rostoucími požadavky a infrastrukturou se však více práce z úvodních fází vrátí v situaci, kdy je potřeba přidávat výkon, separovat služby uvnitř clusteru nebo třeba rozšířit infrastrukturu o další vrstvu nebo komponentu. Prvním krokem před samotnou instalací je vždy kontrola hardwarové podpory virtualizace na procesoru: • technologie VT-x u procsorů Intel grep vmx /proc/cpuinfo • AMD grep svm /proc/cpuinfo Pokud ani jedna z technologií není na procesoru dostupná, nebyl procesor vyroben s podporou plné virtualizace a bylo by možné využít pouze paravirtualizaci nebo kontejnery. Instalace KVM je sama o sobě jednoduchá, jak už bylo popsáno výše, jedná se o modul do jádra OS Linux. Potřebné moduly se instalují do systému příkazem: yum install kvm případně je možné instalaci rozšířit o volitelné balíky s utilitami a rozšiřujícími funkcemi: yum install virt-manager libvirt libvirt-python python-virtinst Balík libvirt obsahuje API pro interakci s hypervizorem a asi nejdůležitější nástroje xm a virsh pro cli správu a řízení virtuálních strojů. Rozšíření libvirtpython obsahuje API libvirt pro aplikace psané v jazyce Python, python-virtinst s utilitou virt-install slouží k vytváření virtuálních strojů. Balík virt-manager pak obsahuje grafický nástroj pro manipulaci s virtuální infrastrukturou. Nyní je třeba zavést nově instalované moduly do jádra, o to se postará buď reboot, který může být ve fázi instalace vhodnou volbou, pokud jsme například zároveň instalovali nový kernel, nebo je to možné provést na běžícím systému příkazy: modprobe kvm-intel modprobe kvm-amd

4.1

Poskytnutí výpočetního výkonu

40

samozřejmě v závislosti na instalovaném procesoru. V tuto chvíli by měly být potřebné moduly zavedeny v jádře, což je možné ještě zkontrolovat použitím příkazu lsmod: /sbin/lsmod | grep kvm Před vytvořením prvního virtuálu je potřeba nastartovat službu libvirtd a pro produkční prostředí také zajistit její spouštění při startu systému: service libvirtd start chkconfig libvirtd on S takto nachystaným systémem by již bylo možné pustit se do instalace guestů. Předtím je ještě v tomto případě vhodné zvážit síťovou konfiguraci hypervizoru a guestů. KVM přistupuje k síťování virtuálních hostů dvěma základními způsoby: • Virtuální síť – defaultní způsob síťování, virtuální stroje dostávají přidělovány adresy z interních rozsahů od interního DHCP hypervizoru, hypervizor následně provádí překlad síťových adres. Jedná se o jednodušší konfiguraci, ovšem na druhou stranu s běžnými omezujícími vlastnostmi NATu, např. při komunikaci směrem zvenku na virtuálního guesta. • Sdílené fyzické zařízení – dedikování síťového rozhraní virtuálnímu stroji pomocí síťového bridge. Jedná se o náročnější konfiguraci s rozsáhlejšími možnostmi a bez omezení, která si sebou přináší NAT, často se tedy používá v pokročilejších infrastrukturách a zařízeních s více síťovými kartami. Výhodou je, že je možné nakonfigurovat podporu VLAN. Nevýhodou je pak právě sdílení fyzického zařízení. Přestože je nad fyzickým zařízením ještě abstrakční vrstva, není z bezpečnostního hlediska vhodný provoz například více virtuálů bez plné kontroly administrátora se sdílenou síťovou kartou. Konfigurace s NATem by pro základní návrh byla postačující, zaveďme však druhou metodu kvůli podpoře VLAN pro pozdější síťový návrh. Prvním krokem by mělo být vypnutí NetworkManageru a ponechání plného řízení sítě na systému: chkconfig NetworkManager off chkconfig network on service NetworkManager stop service network start Pokud nejsou nakonfigurované VLAN interface v systému, bude nutné je nastavit. Síťové připojení hypervizoru na tomto portu tedy počítá s konfigurací korespondujícího portu na switchi jako typ trunk. Zapnutí podpory VLAN provedeme sérií příkazů

4.1

Poskytnutí výpočetního výkonu

41

modprobe 8021q vconfig set_name_type VLAN_PLUS_VID_NO_PAD a samotné vytvoření VLAN interface pro VLAN25 nad fyzickým rozhraním eth1 ifconfig eth1 0.0.0.0 up vconfig add eth1 vlan25 Pokud vše proběhlo v pořádku, budou vidět správné informace ve speciálním systémovém souboru /proc/net/vlan/config: cat /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD vlan25 | 25 | eth1 Následně je potřeba vytvořit bridge pro virtální guesty. Pro nadefinované rozhraní vlan25 je nutné provést úpravu síťového konfiguračního souboru /etc/sysconfig/network-scripts/ifcfg-vlan25. Bridge pro přehlednost nazveme br25, ať koresponduje s číslem VLAN: DEVICE=vlan25 ONBOOT=yes BRIDGE=br25 a obdobným způsobem je pak vytvořen konfigurační soubor pro bridge: DEVICE=br25 TYPE=Bridge ONBOOT=yes DELAY=0 Až jsou tímto způsobem nakonfigurovány všechny potřebné interface, je potřeba provést restart síťe pro načtení nových konfigurací a povolit tento typ komunikace na firewallu: iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT service iptables save service iptables restart Na novou síťovou konfiguraci musí být připraven i libvirtd, takže ještě restart služby service libvirtd restart

4.2

42

Návrh síťové topologie

S takto nakonfigurovanou sítí už nic nebrání vytvoření virtuálního guesta pomocí nástroje virt-install, který jsem instalovali výše. virt-install --accelerate --hvm --connect qemu:///system \ --network bridge:br25 --name template1 --ram=1024 \ --vcpus 2 --os-type linux --os-variant rhel6 \ --file=/var/lib/libvirt/images/template1.img --vnc --hvm Pokud jsou všechny předchozí kroky správně provedeny, měl by být vidět jednak běžící virtuální host: \# virsh list Id Name State ---------------------------------1 template1 running a také odpovídající přiřazení k nakonfigurovanému bridgi: brctl show bridge name br25

bridge id 8000.000000000000

STP enabled no

interfaces vlan25 vnet1

Z takto připraveného virtuálního hosta nyní vytvořím šablonu připravenou na klonování při potřebě nového stroje, aby nebylo potřeba vždy znovu procházet procesem samotné instalace, stažení aktualizací a základní konfigurace. Z takto vytvořené šablony je pak samozřejmě možné vytvářet další šablony ke konkrétnějším účelům, například mít tuto generickou šablonu a od ní odvozenou šablonu aplikačního serveru, databázového serveru apod. Jakmile je vlastní šablona nainstalována a potřebnými interními úpravami customizována, je možné provést klonování příkazem: virt-clone --original app-template --name app1 \ --file=/var/lib/libvirt/images/app1.img Nad takto vytvořenou virtuální infrastrukturou je pak možné budovat snadno spravovatelné a škálovatelné servery jako základ celého řešení. Výhodou nástrojů z rodiny libvirt je snadná manipulace z příkazové řádky a existence API, s nimiž je možné vyvinout i pokročilou automatizační a administrační vrstvu.

4.2 4.2.1

Návrh síťové topologie Naplánování IP prostoru a interních VLAN

Rozvržení interních VLAN vychází z funkčních oblastí zařazení jednotlivých komponent. Do návrhu je nutné zařadit následující oblasti:

4.2

• • • •

Návrh síťové topologie

43

aplikační – aplikační servery; databázová – databázové servery; datová – servery poskytující datové úložiště; servisní – pouze servisní přístup a management.

Pro interní adresaci bude použit privátní rozsah třídy A, tedy 10.0.0.0/8. Jednotlivé VLAN budou rozděleny na úrovni druhého oktetu podle uzlu a podle funkce. Následně ve třetím oktetu budou číslovány VLAN stejného uzlu a stejné funkcionality. Implicitně budou zakládány se síťovou maskou 255.255.255.0. Tímto způsobem dojde k takovému rozdělení, aby zůstal připraven dostatečný prostor pro dynamický růst VLAN v případě potřeby a také pro přidávání dalších VLAN v případě hlubšího členění, např. v případě potřeby dvou oddělených aplikačních VLAN. Jak již bylo zmíněno v teoretické části práce, vhodné je zvážit při zařazení do VLAN potřebu přímé komunikace na druhé vrstvě. To v našem návrhu celkem jasně nastává v případě aplikačních a databázových serverů. Nepředpokládá se, že by aplikační servery fungovaly bez připojení k databázi. Řešením je, že aplikační server má interface v aplikační VLAN za účelem aplikační komunikace s loadbalancerem a druhý interface v databázové VLAN za účelem přímé komunikace s databází. S tím souvisí také naplánování IP prostoru, databázovou vrstvu je v dříve naplánovaném rozvržení možné rozšířít na dvojnásobný rozsah kvůli dvojnásobnému počtu rozhraní. V případě přidání další oddělené funkční VLAN, např. druhé aplikační VLAN pro oddělení prezentací od serverů obsluhujících administrační rozhraní, je díky dostatečné rezervě v rámci interního rozsahu vhodné nechat volno i pro případné rozšiřování. Pokud aplikační VLAN přiřadíme adresu 10.1.0.0/24, pak druhou aplikační VLAN zřídíme podle uvážení např. jako 10.1.8.0/24. Tímto způsobem zůstává 7× /24 rozsah jako rezerva první VLAN. Vznikají tu sice prázdné prostory mezi jednotlivými podsítěmi, ale rezerva je zde opravdu velká. Řešením by bylo zakládat sítě hned za sebou a v případě potřeby růstu je přeadresovat na konec volného adresního prostoru. Číslování VLAN se pak snaží navázat na logické rozdělení adresního rozsahu. Čísla VLAN se standardně mohou pohybovat od 1-1024, takže je na první pohled vidět, že možných sítí v rozsahu 10.0.0.0/8 je více než můžeme označit VLAN (65536 VLAN po 256 IP adresách). Než abychom ale vytvořili takové množství malých VLAN, budou se spíše v případě natolik velkého růstu některé VLAN rozrůstat do rezervních prostorů naznačených v předchozím odstavci. Trojciferné číslo označující VLAN tedy zvolíme ve formátu <0-9 číslo uzlu><0-9 číslo funkcionality><0-9 číslo VLAN>. Názorně je způsob rozdělení zachycen v tabulce:

4.2

44

Návrh síťové topologie

Funkcionalita Uzel Praha Supernet Praha Servisní Aplikační Příklad druhé aplikační Databázová Datová Uzel San Francisco Supernet San Francisco Servisní

VLAN

Adresa sítě

Maska

Počet hostů

100 110 1 11 120 130

10.0.0.0 10.0.0.0 10.1.0.0 10.1.8.0 10.2.0.0 10.3.0.0

255.240.0.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.254.0 255.255.255.0

254 254 254 510 254

200

10.16.0.0 10.16.0.0

255.240.0.0 255.255.255.0

254

Adresace tímto způsobem tedy pokrývá rezervy pro růst jak přidáním dalších uzlů, tak pro přidávání dalších VLAN na jednotlivých funkčních vrstvách a nakonec také pro další funkční vrstvy. Jednotlivé existující VLAN mají prostor pro rozšiřování bez nutnosti přečíslování nebo přesunů. Logické rozdělení interního rozsahu je zobrazeno na obr. 8.

Obr. 8: Návrh interních VLAN

4.2.2

DHCP

DHCP neboli Dynamic Host Configuration Protocol je nástroj především pro dynamickou konfiguraci parametrů sítě, kromě toho však umí poskytnout klientovi doplňkové informace.

4.2

Návrh síťové topologie

45

Jak jsem již zmínil v teoretické části, vhodným prvkem pro umístění DHCP serveru jsou loadbalancery. Případně je možné ve větších nasazeních nachystat pro DHCP a ostatní síťové služby samostatný stroj. Služby jsou tak poskytovány vždy v rámci aktuálního uzlu. Instalace DHCP je jednoduchá, zařídíme rovnou i spouštění služby po startu stroje: yum install dhcp chkconfig dhcp on Soubor /etc/sysconfig/dhcpd obsahuje konfigurační volby démona, pro nás je především nutné uvést zde seznam rozhraní, na kterých démon naslouchá a na kterých je služba poskytována. V tomto případě to bude seznam všech VLAN: DHCPDARGS="vlan100 vlan110 vlan120 vlan130" Konfigurace DHCP pro konkrétní VLAN pak bude vypadat následovně: subnet 192.168.1.0 netmask 255.255.255.0 { # doménové jméno option domain-name "app.praha.customer.org"; # adresa brány option routers 10.0.0.1; # broadcastová adresa option broadcast-address 10.0.0.255; # adresa DNS serveru option domain-name-servers 10.0.0.1 # kolik sekund bude přidělená adresa rezervována, poté # musí klient zažádat o~novou default-lease-time 86400; # po jakou maximální dobu bude adresa rezervována max-lease-time 604800; # způsob logování log-facility local7; # Definice fixních adres host app1 { hardware ethernet 00:11:22:33:44:55; fixed-address 10.0.0.1; } # Volitelně můžeme nastavit dynamický rozsah, pokud chceme, # aby nenakonfigurovaná zařízení také dostala IP adresu range 10.0.0.200 10.0.0.250; }

4.2

Návrh síťové topologie

4.2.3

46

DNS

DNS serverů pod některou z otevřených licencí existuje relativně velké množství, dalece nejrozšířenějším však zůstává BIND (Berkeley Internet Name Daemon). BIND má velmi široké možnosti nasazení a dá se o něm říci, že je de-facto sám standardem, nebo je s ním minimálně velmi úzce spjat. Pro realizaci DNS služby bude proto použit DNS server BIND. Jak již bylo popsáno v teoretické části, provoz DNS rozdělíme na veřejnou a interní službu. Zatímco veřejné DNS poskytuje potřebné informace klientům v Internetu, aby byli schopni zadáním adresy do prohlížeče přistoupit na požadovanou stránku, interní DNS usnadňuje management zavedením snadno zapamatovatelných jmen do infrastruktury. Přestože logický systém adresace usnadňuje orientaci v interním adresním prostoru, především u rozsáhlejších infrastruktur může vhodné mapování jmen usnadnit jejich identifikaci. Pro potřeby návrhu předpokládejme doménu customer.org. Počítáme s realizací dvou uzlů, v Praze a San Franciscu, subdomény tedy budou praha.customer.org a sf.customer.org. Tímto způsobem oddělím jednoznačně a logicky první aplikační stroj app1 v Praze od aplikačního stroje app1 v San Franciscu, každý uzel si tedy zachovává číselnou řadu od 1 a doménová jména zůstávají unikátní. Instalace BINDu a podpůrných klientů je provedena následující sadou příkazů: yum -y install bind bind-libs bind-utils chkconfig named on service named start Hlavní konfigurační soubor démona named je členěn do několika významových sekcí. Důležité jsou především sekce options s obecnými konfiguračními volbami celého serveru a potom zone se sadami záznamů pro adresaci v jednotlivých zónách. V sekci options je k provozu potřeba několik povinných voleb ohledně umístění pracovních souborů ve filesystemu a potom zakázání rekurzivního vyhledávání. Rekurzi chceme povolit pouze pro vnitřní rozsahy. 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"; recursion no; bindkeys-file "/etc/named.iscdlv.key"; }; Při běžném designu není potřeba, aby klient resolvoval přímo adresy hostů v rámci vnitřní infrastruktury a tento návrh s touto variantou ani nepočítá. Interní

4.2

Návrh síťové topologie

47

adresy tedy chceme resolvovat pouze z definovaných vnitřních sítí. Novější verze BINDu mají tu výhodu, že podporují tzv. view, které umožňují na základě definice access listu odpovídat podle toho, kdo se ptá. Pro kombinaci interních i externích zón tedy stačí jen jediný nameserver. Pro interní zóny je zapotřebí nadefinovat access list, podle kterého je následně vybrán view. Pro externí klienty není view nutný, neboť je k dispozici vestavěný any. acl "internal_hosts" { 10.0.0.0/8; 127.0.0.1; }; Založený access list je následně použit v sekcích view, které zároveň obsahují konfigurace jednotlivých interních a externích zón. Interní view obsahuje povolení rekurze, ke kterému potřebuje definici kořenových nameserverů. Pro oddělení interního rozsahu v doménových názvech jsem zvolil prefix in před označení uzlu, konkrétně tedy in.praha.customer.org. Druhou často používanou variantou je pak zavedení ryze interní domény, např. v našem případě praha.local. view "internal" { match-clients { internal_hosts; }; recursion yes; notify no; // kořenové nameservery zone "." { type hint; file "db.root"; }; // vlastní zóna zone "in.praha.customer.org" { type master; file "internal/named.in.praha.customer.org"; }; zone "in.sf.customer.org" { type master; file "internal/named.in.sf.customer.org"; }; }; Externím klientům naopak na rozdíl od interních zakazujeme rekurzi. Rozhodně zde není chtěné, aby se našich nameserverů mohli všichni ptát na libovolnou adresu

4.2

Návrh síťové topologie

48

v Internetu. Pro externí klienty je na druhou stranu zapotřebí rozdělení zátěže na základě jejich polohy na nejbližší uzel. Variant realizace je více, pro menší infrastruktury je nejvhodnější a nejsnažší cestou konfigurace DNS s podporou GeoIP směrování. Plugin bind-geoip1 umožňuje definovat match klientů pro view na základě zjištěné geolokace klienta (Pro nasazení patche je třeba buď zabudovat patch do rpm, nebo BIND překompilovat ze zdrojových kódů). Jako vodítko pro směrování na jednotlivé uzly použiji běžně komerčně používané rozdělení regionů: • EMEA – uzel Praha, • Asia Pacific – uzel Praha, • Americas – uzel San Francisco. Plugin využívá MaxMind databází, dostupné jsou jak komerční, tak volné databáze . Nevýhodou databází je, že nepodporují přímo regiony, je tak potřeba směrovat explicitně podle států. Pro případ, kdy IP adresa nebude dohledána v GeoIP databázi bude sloužit ještě poslední catchall view s univerzální konfigurací. Konfigurace BINDu s podporou GeoIP směrování tedy bude vypadat následovně3 : 2

view "external-emea-ap" { match-clients { geoip_countryDB_countryCode_EU; geoip_countryDB_countryCode_AP; } recursion no; zone "customer.org" { type master; file "external/named.emea-ap-customer.org"; }; }; view "external-americas" { match-clients { geoip_countryDB_countryCode_Americas; }; recursion no; zone "customer.org" { type master; file "external/named.americas-customer.org"; }; }; view "external" { 1

Dostupné z https://code.google.com/p/bind-geoip/ Volně dostupné databáze jsou ke stažení na adrese http://dev.maxmind.com/geoip/legacy/geolite 3 Z důvodu rozsahu uvádím pouze označení regionu, plnou konfiguraci na základě národních kódů dle ISO 3166 je možné najít v příloze A 2

4.2

Návrh síťové topologie

49

match-clients { any; }; recursion no; zone "customer.org" { type master; file "external/named.customer.org"; }; }; Vlastní mapování doménových jmen na IP adresy je pak v jednotlivých zónových souborech. Záznamy v zónovém souboru se dělí na direktivy a záznamy týkající se zdrojů, tzv. RR (resource records). Direktivy říkají serveru aby nad zónovou prováděl definované akce nebo přiřazují zóně specifická nastavení. RR pak definují parametry zóny a přiřazují identity vlastním hostům. (Red Hat Enterprise Linux Deployment Guide, 2006) Direktiva $ORIGIN říká, že všechny následující RR neuvedené s plnou cestou (tedy kořenovou doménou ”.” na konci) dostanou uvedenou příponu. Direktiva $TTL nastavuje defaultní Time to Live pro celou zónu. Nejdříve interní překlady pro potřeby správy, příklad na aplikační VLAN uzlu Praha (soubor internal/named.in.praha.customer.org): $ORIGIN in.praha.customer.org. $TTL 86400 @ IN SOA ns1.customer.org. hostmaster.customer.org. ( 2013010100 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN IN

NS NS

ns1.customer.org. ns2.customer.org.

ns1 ns2

IN IN

A A

10.0.0.1 10.0.0.2

app1 app2

IN IN

A A

10.1.0.1 10.1.0.2

A nakonec vlastní IP záznamy pro externí zóny. Z regionu EMEA a Asia Pacific budou klienti směrováni do adresního rozsahu 100.0.0.0/24 a ze severní i jižní Ameriky pak do rozsahu 101.0.0.0/24. Vzhledem k tomu, že může dojít k přístupu z IP adresy nepokryté GeoIP databází, ponecháme poslední fallback rozsah s oběma

4.2

Návrh síťové topologie

50

adresami a provedeme DNS round robin loadbalancing. TTL u apexu (kořene spravovaného doménového stromu, v tomto případě customer.org.) ponechávám záměrně velmi malé. Na nameservery bude sice vyvíjena větší zátěž a klienti se budou častěji dotazovat, ale umožní to v případě zásadního výpadku velmi rychlé přepnutí na funkční uzel. Při výpadku celé Prahy je pak možné automatizovaně přepnout DNS tak, aby směrovalo klienty pouze na uzel San Francisco. • external/named.emea-ap.customer.org ... $ORIGIN customer.org. 300 IN A 100.0.0.1 ns1 IN A 100.0.0.253 ns2 IN A 100.0.0.254 www IN CNAME customer.org. ... • external/named.americas-customer.org ... $ORIGIN customer.org. 300 IN A 101.0.0.1 ns1 IN A 101.0.0.253 ns2 IN A 101.0.0.254 www IN CNAME customer.org. ... • external/named.customer.org ... $ORIGIN customer.org. 300 IN A 100.0.0.1 300 IN A 101.0.0.1 ns1 IN A 100.0.0.253 IN A 101.0.0.253 ns2 IN A 100.0.0.254 IN A 101.0.0.254 www IN CNAME customer.org. ... 4.2.4

Loadbalancing

Loadbalancing neboli rozdělení zátěže je další z nutných síťových služeb. Pro potřeby tohoto návrhu bude postačovat loadbalancing na koncové webové servery v rámci jednoho uzlu, použitá metoda je LVS-NAT, jak již bylo zmíněno v teoretické části. Mezi open source řešeními hraje nejvýznamnější roli software IPVS (IP Virtual Server), součást projektu Linux-HA, a realizační část je postavena na něm. Obrovskou výhodou je, že využívá standardních mechanismů UNIXových systémů a implemen-

4.2

Návrh síťové topologie

51

tuje loadbalancing ne na aplikační, ale na transportní vrstvě pomocí funkcí integrovaných v jádře. Nad IPVS pak pracuje ldirectord, který kontroluje stav reálných serverů a v závislosti na jejich dostupnosti spravuje IPVS. Instalace obou komponent: yum install ipvsadm heartbeat-ldirectord chkconfig ldirectord on Do souboru /etc/sysctl.conf je potřeba vložit následující řádek, aby bylo zapnuté forwardování paketů na úrovni jádra operačního systému: net.ipv4.ip_forward = 1 A následuje již jen vlastní konfigurace ldirecotru. Nejdříve jsou uvedeny direktivy obecné konfigurace chování ldirectoru, checkinterval pro interval mezi jednotlivými kontrolami a checktimeout pro označení neodpovídajícího reálného serveru za nedostupný. Za nimi je pak konfigurace samotného směrování požadavků a kontrol, která začíná direktivou virtual, u níž je uvedena veřejná adresa serveru. Následují adresy reálných serverů s definicí metody směrování a případnými konfiguracemi vah pro případ, že by reálné servery nebyly stejně výkonné. Obsluhujeme službu HTTP po protokolu TCP a rozdělení zátěže provádíme pomocí weighted round robin. Konfigurace uzlu Praha tedy bude vypadat následovně: checktimeout=15 checkinterval=30 virtual=100.0.0.1:80 real=10.1.0.1->10.1.0.3:80 masq 8 service=http request="/" scheduler=wrr protocol=tcp Problémem této konfigurace však zůstává případ výpadku loadbalanceru. V takové situaci by muselo dojít k přepnutí na druhý uzel v DNS, jak bylo již uvedeno výše. Loadbalancer se v rámci uzlu stará o veškeré kritické služby, takže bez něj není provoz uzlu možný. Z důvodu failoveru jsou však v infrastrukturním návrhu v každém uzlu loadbalncery dva. O jejich automatické přepnutí se postará další z rodiny Linux-HA produktů, Heartbeat. Heartbeat periodicky kontroluje dostupnost hostů a v případě výpadku dokáže vyvolat přesun IP adresy, případně navíc jinou akci. Veřejná IP adresa je obsluhována primárním serverem. Heartbeat běží jako démon na obou loadbalancerech. Mezi všemi nimi pak běhají tzv. .heartbeaty. (údery srdce), které informují backup o stavu primárního stroje. V případě, že primární server přestane posílat, sekundární server vyšle do sítě tzv. gratuitous arp paket (bezdůvodný ARP paket). Jde o paket, který oznamuje vazbu mezi IP a MAC adresou, aniž by zdrojový stroj obdržel požadavek na vyslání takové informace. Tím oznámí ostatním strojům, že IP adresa

4.2

52

Návrh síťové topologie

webserveru je nasměrována na jiné zařízení v síti – síťovou kartu záložního stroje. Heartbeat na backupu zároveň inicializuje virtuální síťové rozhraní obsluhující tuto IP adresu. (Šorm, 2007) V souboru /etc/ha.d/ha.cf definujeme potřebné časovače pro chování heartbeatu a oba sledované uzly: keepalive deadtime warntime initdead auto_failback node node

2 15 5 60 off lb1.in.praha.customer.org lb2.in.praha.customer.org

Vysvětlení konfiguračních voleb: • keepalive, deadtime, warntime, initdead – časovače pro interní komunkaci Heartbeatu; • auto failback – vypnutí návratu do původní konfigurace po odstranění překážek v dostupnosti; • node – specifikace účastnících se uzlů. Zatímco heartbeaty chodí po interních (nebo i externích) adresách vyhrazených jednotlivým hostům, adresa která musí být dostupná trvale je zřízena jako virtuální a existuje tedy vždy jen na jednom serveru. Ve veřejné i interní síti jsem již při návrhu DNS zvolil adresu .1 jako virtuální, adresy .253 a .254 pak adresují přímo konkrétní stroj. Definice resource v souboru /etc/ha.d/haresources: lb1.in.praha.customer.org IPaddr::100.0.0.1/24/eth0 \ IPaddr::10.0.0.1/24/eth1 MailTo::[email protected] dhcpd Tento záznam zajišťuje konfiguraci lb1.in.praha.customer.org jako primární server pro obě virtuální adresy. V případě výpadku pak dojde k migraci virtuálních adres podle /etc/ha.d/ha.cf, poslání emailu s upozorněním na adresu [email protected] a nastartování služby DHCP na sekundárním serveru. DHCP je takto definováno z toho důvodu, že zatímco ostatní služby mohou běžet pernmanentně na obou uzlech, DHCP server musí v síti běžet jen jednou. 4.2.5

IPsec VPN

IPsec slouží v návrhu pro propojení mezi uzly po nezabezpečené síti (Internetu), za použití zabezpečeného tunelu. IPsec VPN může být buď typu host–to–host, nebo network–to–network, v tomto případě bude použita druhá varianta. Navázání IPsecového spojení se skládá ze dvou fází. V první fázi se uzel snaží iniciovat spojení s druhou stranou, ta ověří údaje poskytované připojujícím se uzlem

4.2

Návrh síťové topologie

53

a vzájemně se dohodnou na parametrech spojení a metodě autentizace. Ve druhé fázi jsou vytvořeny mezi oběma uzly tzv. SA (Security Association), je vytvořena SA databáze s informacemi o spojení, tedy použitém šifrování, parametrech bezpečné výmeny klíčů atd. Balík pro podporu IPsec se nazývá ipsec-tools a obsahuje potřebné knihovny, konfiguraci, démony a sadu utilit pro práci. Instalace probíhá následovně: yum install ipsec-tools chkconfig racoon on Úplně nejčistějším řešením by samozřejmě bylo, umístit IPsec bránu na server vyhrazený jen pro tuto funkcionalitu. Pro potřeby návrhu ji však umístím na jiný server v servisní VLAN, loadbalancer, s výhodou využijeme heartbeatované adresy pro zachování plné dostupnosti VPN i v případě výpadku jednoho loadbalanceru. Prvním krokem realizace je vytvoření síťového rozhraní pro komunikaci mezi IPsec routery. Na jedné straně se rozhraní musí jmenovat ipsec0, na straně druhé pak ipsec1. Soubor musí obsahovat adresy bran na obou stranách, adresy sítí, které budou po VLAN komunikovat, veřejnou adresu vzdáleného uzlu a způsob ověření uzlu pro fázi 1, v tomto případě sdílený klíč. Konfigurační soubor pro ipsec0 rozhraní na Pražském uzlu bude /etc/sysconfig/network-scripts/ifcfg-ipsec0: TYPE=IPSEC ONBOOT=yes IKE_METHOD=PSK SRCGW=10.0.0.1 DSTGW=10.16.0.1 SRCNET=10.0.0.0/12 DSTNET=10.16.0.0/12 DST=101.0.0.1 Pro fázi 1 je použito sdíleného klíče, oba uzly tedy musí mít v konfiguračním souboru /etc/sysconfig/network-scripts/keys-ipsec0 staticky nastaven stejný klíč pro navázání komunikace: IKE_PSK=6NjzfiKy2nywd1El Konfigurace samotného IPsecového spojení je pak umístěna v /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour; encryption_algorithm 3des, blowfish 448, rijndael;

4.3

Realizace úložiště

54

authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate; } remote 101.0.0.1 { exchange_mode main; my_identifier address; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } proposal_check obey; } Tímto způsobem je provedena základní konfigurace IPsec VPN pro komunikaci mezi uzly. Pro vyšší úrověň zabezpečení je vhodné přejít z mechanismu sdílených klíčů na certifikáty. Přenosy většího množství dat skrz VPN může také být hardwarově náročné, obzvlášť u více uzlů a více VPN mezi nimi je pak vhodné zvážit nasazení hardwarového VPN koncentrátoru s hardwarovou podporou IPsecovými mechanismy přímo v hardware a oddělení od dalších komponent návrhu.

4.3

Realizace úložiště

Prvním krokem realizace je návrh a implementace přístupu k nízkoúrovňovému úložišti, tedy samotným diskům. Pro obecný návrh jsem zvolil replikaci již na této vrstvě, a to z toho důvodu, že není třeba řešit ji zvlášť pro každý typ požadovaného úložiště na vyšší vrstvě. Z oblasti open-source slouží k tomuto účelu DRBD (Distributed Replicated Block Device). Ten umožňuje definování logických blokových zařízení nad fyzickými blokovými zařízeními, zkráceně řečeno umožňuje podobnou funkcionalitu jako RAID1, ovšem po síťové vrstvě. Nad takto zřízeným úložištěm již lze bez větších obtíží realizovat poskytování jednotlivých zlužeb, tedy souborového, blokového a objektového úložiště. Nejjednodušší síťové souborové úložiště je na Linuxu realizovatelné pomocí distribuovaného souborového systému NFS (Network File System). NFS umožňuje připojit filesystem na vzdáleném počítači jakoby byl lokální na vlastním systému. Následně je možné přistupovat přímo k souborům na vzdáleném filesystemu. Výhodou je možnost přístupu různých systémů na síti ke stejným souborům, aniž by musely držet vlastní kopie. (Petersen, 2010) K nasazení blokového úložiště na tomto řešení se přímo nabízí využití protokolu iSCSI (Internet Small Computer System Interface). Protokol umožňuje přenos SCSI

4.3

Realizace úložiště

55

příkazů po IP síti a tím pádem pracovat se SAN stejným způsobem, jako s lokálními disky. Díky své dostupnosti a především cenové výhodnosti oproti Fibre Channel řešením se velmi rychle stal masově rozšířeným jak mezi distributory softwarových řešení, tak mezi výrobci hardware. 4.3.1

DRBD

Pro nasazení DRBD potřebujeme čisté nenaformátované blokové zařízení – pro zjednodušení fyzický disk na každém participujícím serveru. 1. Instalace DRBD yum install drbd kmod-drbd 2. Konfigurace DRBD je prováděna v konfiguračním souboru /etc/drbd.conf a je shodná na obou strojích: resource data1 { disk { on-io-error detach; resync-rate 100M; } net { protocol C; } on fs1.in.praha.customer.org { volume 0 { device /dev/drbd0; disk /dev/sdb; meta-disk internal; } address 10.3.0.1:7789; } on fs2.in.praha.customer.org { volume 0 { device /dev/drbd0; disk /dev/sdb; meta-disk internal; } address 10.3.0.2:7789; } } Vysvětlení konfiguračních voleb: • resource – Označení logického svazku. • protocol – DRBD umožňuje volbu protokolu A, B nebo C. Protokol C je synchronní replikační protokol pro replikaci na lokální síti. • resync-rate – Omezení šířky pásma pro synchronizaci, aby nedošlo k zahlcení plné šířky pásma. • on-io-error – Určuje chování v případě hlášení I/O chyb na nižší vrstvě. Detach je volba pro odpojení nízkoúrovňového zařízení. • device – Jméno výsledného DRBD logického zařízení.

4.3

Realizace úložiště

56

• disk – Fyzické blokové zařízení určené k replikaci. • meta-disk – Určení, kde budou ukládána metadata. V případě internal bude použit prostor na konci replikovaného disku. • address – Adresa určená ke komunikaci v rámci DRBD clusteru. V případě, že se jeví vzdálená replikace jako vhodnější, zůstává celá konfigurace vlastně shodná, až na změnu protokolu DRBD a případné vyladění timerů a šířky pásma do optimálních provozních podmínek. 3. Pro práci s DRBD slouží příkaz drbdadm. Pomocí něj provedeme na obou strojích založení logického svazku: drbdadm create-md data1 4. Opět na obou strojích je zapotřebí nastartovat DRBD démona a zařídit spouštění i po restartu stroje: service drbd start chkconfig drbd on 5. Pomocí čtení ze speciálního souboru /proc/drbd je možné ověřit stav služby na obou uzlech. V této fázi jsou oba uzly konfigurovány jako secondary, tedy nedochází k synchronizaci. Provedeme tedy nastavení primárního uzlu a zahájíme synchronizaci: drbdadm -- --overwrite-data-of-peer primary repdata V /proc/drbd je opět možné sledovat stav synchronizace. Nyní by měla být nastavena replikace, není však jednoduše možné na vyšších vrstvách automaticky řídit připojení k primárnímu uzlu – stále jsou pro úložiště definovány dvě samostatné IP adresy. Proto je zapotřebí vyřešit automatický failover pro případ výpadku uzlu. K tomuto účelu slouží součást Linux-HA projektu Heartbeat, o kterém se již psalo ve spojitosti s failover řešením loadbalancerů. Ten zajistí přesun primární role DRBD a jedinou IP adresu vázanou na tuto roli, na které budou služby dostupné v síti pro všechny klienty. 1. Instalace heartbeat: yum install heartbeat 2. Provedení konfiguračních změn v souboru /etc/ha.d/ha.cf: keepalive 2 deadtime 15 warntime 5 initdead 60 auto_failback off node fs1.in.praha.customer.org node fs2.in.praha.customer.org 3. Definice resource v souboru /etc/ha.d/haresources: fs1.in.praha.customer.org drbddisk::data1 \ IPaddr::10.3.0.1/24/eth0 MailTo::[email protected]

4.3

Realizace úložiště

57

Tento zápis zařídí kontrolu jednak logického svazku data1 definovaného v konfiguraci DRBD a dostupnosti IP adresy 10.1.3.1. Primárním uzlem pro běh služeb zůstává host fs1.in.praha.customer.org. 4. A nakonec už jen nastartování služby. service heartbeat start chkconfig heartbeat on Nevýhodou této konfigurace je absence rozdělení zátěže. Veškeré I/O operace probíhají na primárním stroji, druhý stroj slouží pouze pro zápis replikovaných dat a jako failover pro případ výpadku prvního stroje. Odstranění této nevýhody vyžaduje buď podstatně složitější konfiguraci, nebo je možné řešit ji elegantně vytvořením několika DRBD svazků a rozdělením primární/sekundární role pro jednotlivé svazky na různé uzly. 4.3.2

Souborové úložiště

NFS je stále standardní součástí Linuxových instalací a s tím jde ruku v ruce jednoduchost jeho instalace a konfigurace. Filesystemy dostupné ostatním počítačům jsou vedeny v konfiguračním souboru /etc/exports. O startování NFS se postará dvojice příkazů chkconfig nfs on service nfs start která zajistí startování souvisejících démonů: • rpc.nfsd – přijímá požadavky od vzdálených klientů a překládá je na požadavky pro lokální filesystem; • rpc.mountd – provádí požadované operace na připojení a odpojení filesystemu; • rpc.statd – zprostředkovává zamykání filesystemu v případě restartu vzdáleného systému; • rpm.idmapd – mapuje uid a gid na jména. (Petersen, 2010) Před spuštěním NFS je však ještě potřeba vytvořit filesystem na blokovém zařízení připraveném na DRBD. Výběr filesystemu závisí na konkrétním použití, pro obecný návrh můžeme ponechat stále nejrozšířenější ext3. mkfs.ext3 -j -L data1 /dev/drbd0 Tímto příkazem zajistíme vytvoření ext3 filesystemu s podporou žurnálování a labelem data1 nad logickým DRBD svazkem. Vzhledem k tomu, že NFS musí exportovat lokálně připojený filesystem, musíme ještě vytvořený filesystem připojit, např. do adresáře /mnt/nfs: mount /dev/drbd0 /mnt/nfs/data1

4.4

Návrh řešení databázové vrstvy

58

Takto založený a připojený filesystem již můžeme exportovat přes konfigurační soubor /etc/exports. Ten je v obecném formátu: [volby] Konfigurace pro připojení z aplikačních serverů tedy bude vypadat následovně: /mnt/nfs/data1 app1.in.praha.customer.org(rw,sync) \ app2.in.praha.customer.org(rw,sync) \ app3.in.praha.customer.org(rw,sync) Po provedení změn v konfiguračním souboru není potřeba restartovat NFS démony, ale informovat NFS o změnách pomocí příkazu: exportfs -r -a -v 4.3.3

Blokové úložiště

V terminologii iSCSI se server nazývá iSCSI target a klient je nazýván iSCSI initiator. Oba mohou být jako softwarového, tak hardwarového typu. Server má nadefinovány logické jednotky zvané LUN, kterými jsou identifikovány jednotlivá SCSI zařízení v systému. Pro iSCSI initiator slouží k identifikaci blokového zařízení IQN (iSCSI Qualified Name), které je ve formátu ¡typ¿.¡datum¿.¡reverzní název autority¿:¡identifikátor zařízení¿. Je potřeba nainstalovat balík utilit pro vytvoření iSCSI targetu, běžící démon se pak jmenuje tgtd: yum install scsi-target-utils chkconfig tgtd on service tgtd start Konfigurace svazku probíhá jednoduše přiřazením IQN vybranému fyzickému zařízení, v tomto případě drbd svazku vytvořenému dříve, v konfiguračním souboru /etc/tgt/targets.conf. Volitelně je možné přidat ověření uživatele nebo specifikaci povolených klientů: backing-store /dev/drbd1 incominguser drbd1 drbd1pass

4.4

Návrh řešení databázové vrstvy

Pro realizaci se v závislosti na stanovených podmínkách jako nejvhodnější jeví varianta s master-master active-passive replikací na úrovni uzlu. Pro účely maximální škálovatelnosti bude realizována read replika, při zvýšené zátěži nebo očekávaných špičkách je read repliky možné přidávat velmi jednoduše v relativně neomezeném množství.

4.4

Návrh řešení databázové vrstvy

59

Pro samotná data bude použito schéma oddělené od ostatních, realizaci ukážu na příkladu statistických dat v odděleném schématu. Provozování více oddělených instancí nemá při nasazení replikace smysl, neboť všechny výhody tohoto modelu jsou již pokryty replikací. Konečný návrh databázové vrstvy je následující:

Obr. 9: Návrh databázové vrstvy

4.4.1

Replikace

Prvním krokem pro konfiguraci replikace je založení potřebných účtů. Pro naše potřeby se bude jednat o účet replicator a je nutné založit ho na všech uzlech. Následující kroky jsou prováděny na uzlu Praha, v San Franciscu jsou kroky analogické. mysql> grant replication slave, replication client on *.* to \ replicator@’10.2.0.0/255.255.255.0’ identified by ’replpass’; Na obou masterech je nutné změnit typ logování na binary a každému serveru přiřadit unikátní server id. Server id jsou voleny tak, aby odpovídaly číslování v síti a jsou vidět na obr. 9. Pokud by se jednalo o jednoduchou master-slave replikaci, tak by tyto změny byly postačující. Pokud však chceme master-master, musí být obě master repliky zároveň nakonfigurovány i jako slave. Úpravy my.cnf na db1.in.praha: log_bin = mysql-bin server_id = 11 relay_log = mysql-relay-bin log_slave_updates = 1 Po změně konfigurace je vždy nutný restart démona mysqld a potom je již možné zkontrolovat stav příkazem SHOW MASTER STATUS:

4.4

Návrh řešení databázové vrstvy

60

mysql> SHOW MASTER STATUS; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.001 | 0 | | | +---------------+----------+--------------+------------------+ Konfigurace passive mastera je podobná, pouze je přidána volba read only = 1. log_bin = mysql-bin server_id = 12 relay_log = mysql-relay-bin log_slave_updates = 1 read_only = 1 Konfigurace slave repliky je stejná jako u passive masteru: log_bin = mysql-bin server_id = 13 read_only = 1 relay_log = mysql-relay-bin log_slave_updates = 1 V tuto chvíli jsou nakonfigurované všechny tři MySQL servery v rámci Pražského uzlu a můžu zapnout samotnou replikaci. Oba master uzly fungují současně jako master a současně jako slave. Na db1.in.praha tedy zadám: mysql> CHANGE MASTER TO MASTER_HOST=’db2.in.praha.customer.org’, MASTER_USER=’replicator’, MASTER_PASSWORD=’replpass’, MASTER_PORT=3306, MASTER_LOG_FILE=’mysql-bin.001’, MASTER_LOG_POS=0, MASTER_CONNECT_RETRY=10; a na db2.in.praha: mysql> CHANGE MASTER TO MASTER_HOST=’db1.in.praha.customer.org’, MASTER_USER=’replicator’, MASTER_PASSWORD=’replpass’, MASTER_PORT=3306, MASTER_LOG_FILE=’mysql-bin.001’, MASTER_LOG_POS=0, MASTER_CONNECT_RETRY=10;

4.4

Návrh řešení databázové vrstvy

61

Nyní je hotová master-master topologie, pasivní replika je odlišná pouze konfigurací read only = 1 v my.cnf. Při zápisu změn na db1 tak dojde k již vysvětlenému zápisu změn do binary logu a skrz proces replikace do relay logu na db2. Tam jsou opětovně aplikovány uložené dotazy a zapsány do binary logu. Db1 zde sice dostane na závěr celého kolečka provedené změny zase zpátky do vlastního relay logu, nicméně protože se shoduje ID serveru, jsou tyto operace ignorovány. Pro zapnutí read repliky již není na masteru třeba nic dalšího, stačí zapnout na novém slave serveru replikaci. Toto je výhodné zejména proto, že přidání další read repliky nevyžaduje žádný krok na master serveru a také to usnadňuje změnu master serveru v případě servisní odstávky nebo jakékoliv případné údržby. mysql> CHANGE MASTER TO MASTER_HOST=’db2.in.praha.customer.org’, MASTER_USER=’replicator’, MASTER_PASSWORD=’replpass’, MASTER_PORT=3306, MASTER_LOG_FILE=’mysql-bin.001’, MASTER_LOG_POS=0, MASTER_CONNECT_RETRY=10; Stav repliky je možné opět zkontrolovat, tentokrát příkazem SHOW SLAVE STATUS (zkrácený výstup): mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: db2.in.praha.customer.org Master_User: replicator Master_Port: 3306 Connect_Retry: 3 Master_Log_File: mysql-bin.001 Read_Master_Log_Pos: 0 Relay_Log_File: mysql-relay-bin.001 Relay_Master_Log_File: mysql-bin.001 Slave_IO_Running: No Slave_SQL_Running: No Exec_Master_Log_Pos: 0 Seconds_Behind_Master: 0 Řádky Slave IO Running a Slave SQL Running informují o tom, že samotná replikace zatím neběží. Po kontrole konfigurace již tedy stačí jen samotné zapnutí: mysql> START SLAVE;

4.5

Návrh řešení sítě pro doručení obsahu

4.4.2

62

Databázové schéma

Podle návrhu založím oddělené schéma pro vlastní webové aplikace a pro servisní databázi se statistikami a provozními daty: mysql> create database web; mysql> grant select, insert, update on web.* to \ [email protected]/255.255.255.0. identified by .webpass.; mysql> create database statistics; mysql> grant all on statistics.* to [email protected]/255.255.255.0 \ identified by .statpass.; mysql> flush privileges;

4.5

Návrh řešení sítě pro doručení obsahu

Přestože existuje mnoho variant, squid je stále zřejmě nejrozšířenějším nasazovaným proxy serverem a po mnoha letech vývoje jsou jeho možnosti obrovské. Na mnoho jednoduchých úkolů je však právě z toho důvodu zbytečné nasazovat rozsáhlý a složitý squid, pro CDN jsem však vybral právě jej. Pro realizaci systému pro doručování obsahu bude potřeba několik samotných cache serverů a z důvodu redundance i několik cílových origin serverů držících vlastní zdrojová data. Každý cache server disponuje veřejnou IP adresou, na kterou jsou směrovány doménová jména použitá v aplikačním kódu jako zdroj obsahu z cache. Z obr. 10 je vidět, že adresace je připravena pro DNS-based round-robin rozložení zátěže mezi jednotlivé cache servery. Samotné origin servery již veřejnou adresou nedisponují, jsou přístupné pouze jako zdroj dat pro cache servery. Metoda distribuce požadavků na cache servery se nijak neliší od směrování na jednotlivé uzly pomocí DNS, jak bylo popsáno v kapitole 4.2.3. 4.5.1

Caching engine

Od CDN očekáváme, že bude v rámci běžného provozu naprosto transparentní. Prvním krokem, který je potřeba udělat, je změna standardního portu squidu z 3128 na standardní port webového serveru 80. Volba accel pak zapíná chování jako reverzní proxy. Ve starších verzích squidu by byla potřeba ještě volba vhost, nicméně od verze 3.2 je již toto chování při použití accel implicitní. http_port 80 accel V závislosti na obsluhovaném objemu dat a přiděleném výkonu je zapotřebí zvážit velikost paměti vyhrazené na cache. To je samo o sobě úkolem pro pravidelnou podrobnou analýzu a optimalizaci během provozu celého řešení. Jak uvádí ([email protected], 2013), do začátku vystačí obecné doporučení, že zhruba polovina fyzické paměti serveru by měla optimálně padnout na součet cache mem

4.5

Návrh řešení sítě pro doručení obsahu

63

Obr. 10: Veřejná adresace reálných CDN uzlů

a 10MB za každý 1 GB obsahu v cache. Pokud tedy fyzický server, na kterém bude squid umístěn disponuje 4 GB fyzické paměti a předpokládáme do začátku obsluhu např. 50 GB dat, mohu s klidem nastavit cache mem na 1,5 GB. cache_mem 1536 MB Vzhledem k tomu, že seznam origin serverů a doménových jmen pro obsluhu statického obsahu může být velmi dynamický a u velkých systémů je pravděpodobné, že nebude obsluhován pouze manuálně, ale s pomocí vlastní obslužné aplikace, je vhodné připravit i CDN servery pro práci s vhodně strukturovanou konfigurací, ideálně již připravenou pro případné nasazení generátoru nebo napojení na servisní aplikaci. K tomuto účelu slouží ideálně volba include pro linkování externích konfiguračních souborů. include /etc/squid/dynamic/*.conf Adresář /etc/squid/dynamic pak bude obsahovat jeden soubor pro každou sadu adres obsluhujících obsah z cache a jemu přiřazenou sadu origin serverů.

5

5

SROVNÁNÍ VLASTNÍHO ŘEŠENÍ A NÁKUPU FORMOU SLUŽBY

64

Srovnání vlastního řešení a nákupu formou služby

Vlastní řešení nemusí být v každém případě to nejvhodnější, rozhodně ne po stránce finančních a personálních nákladů. V současné době existuje na trhu velké množství poskytovatelů všech forem služeb, od IaaS, SaaS po PaaS, a to od nadnárodních organizací, po drobné lokální poskytovatele. Mezi největší světové hráče patří: • Amazon Web Services (AWS) – AWS poskytuje asi nejkomplexnější sadu služeb, postavených na několika moderních datacentrech po celém světě. Základem jeho IaaS tvoří rodiny služeb Elastic Compute Cloud (EC2 – výpočetní výkon, loadbalancery), Relational Database Service (databázové služby) a Simple Storage Service (datové úložiště), doplněné o DNS, CDN, monitorovací služby, autoscaling, privátní VPN, to vše s moderním a robustním API. Na vlastní infrastruktuře je pak nabízena také sada PaaS a SaaS služeb. • Windows Azure – Firma Microsoft je druhým gigantickým hráčem na trhu. Přestože poskytuje univerzální infrastrukturní služby, celkem logicky se orientuje především na vlastní produkty. Databáze je tedy postavena ryze na Microsoft SQL Serveru, velká část managementu a API počítá s použitím .NET, storage je poskytováno opět pouze formou SQL serveru. • Google’s Compute Engine (GCE) – Infrastruktura Googlu se teprve dostává do stadia dostupnosti široké veřejnosti, nedá se tedy říci, že by se jednalo o zavedeného velkého hráče. Google má všsk podobně jako Amazon obrovské výpočetní zdroje po celém světě a když už byl nucen vyvinout plnohodnotnou cloudovou infrastrukturu pro sebe, proč ji nenabízet komerčně. Potenciál je stále velký a Google může zásadním způsobem změnit rozvržení sil na trhu. V tuto chvíli poskytuje samozřejmě výpočetní výkon, storage a databázi, jeho největší potenciál je však v oblasti PaaS služeb pro již nyní velmi širokou vývojářskou základnu. • Rackspace – Rackspace je ryze infrastrukturní poskytovatel, který staví především na kvalitě svých služeb a starosti o zákazníka. Z hlediska IaaS pokrývá vše co je na trhu dostupné a doplňuje to širokou nabídkou managed služeb a podpory. Rackspace jde navíc velmi rychle kupředu a spektrum jeho služeb se stále rozšiřuje. • Savvis – Savvis je poskytovatel orientující se především na enterprise klientelu. Řadou akvizicí a investic různých bezpečnostních, telekomunikačních a jiných IT společností vznikl nadnárodní poskytovatel chlubící se více než 50 datacentry pro poskytování globálních služeb. Savvis se navíc může chlubit opravdu vysokou mírou dostupnosti a spolehlivosti služeb, na které zakládá také své výsadní místo mezi ostatními providery. Výhodou také je, že Savvis investuje a otevřeně podporuje interoperabilitu mezi jednotlivými providery. • Eucalyptus – Eucalyptus není poskytovatelem služby jako ostatní, jedná se totiž o open source řešení pro nasazení privátního cloudu. Vzorem jeho funkcionalit je AWS, na mnoha částech s Amazonem také spolupracuje. Jedním z posledních

5.1

Metodika stanovení nákladů

65

příkladů je například spolupráce na vzájemné kompatibilitě API. Pro mnoho subjektů to může být vhodný první krok k přesunu své infrastruktury na cloud.

5.1

Metodika stanovení nákladů

Náklady na vlastní infrastrukturu zahrnují: • Pořizovací náklady – náklady na hardware; – mzdové náklady architekta řešení; – mzdové náklady systémového administrátora; • Provozní náklady – náklady na hosting; – mzdové náklady na provoz; Pro odhadní výpočet nákladů bude použita v prvním případě minimální navrhovaná varianta, tedy dva servery navržené v kapitole věnované hardware, umístěné v komerční servrovně, ve druhém případě pak varianta čtyřnásobná, tedy celkem osm serverů. Pro výpočet nákladů na provoz hardware bude použit reálný ceník předního českého provozovatele datacentra – Master Internet, s.r.o. Průměrné mzdy pro výpočet mzdových nákladů budou stanoveny z dat poskytovaných Českého statistického úřadu, časové náročnosti jednotlivých úkonů jsou stanoveny odhadem. Náklady na pořízení infrastruktury formou IaaS budou stanoveny dle platného ceníku poskytovatele Amazon AWS. Vzhledem k absenci jednorázových pořizovacích nákladů u pořízení formou služby bude vypočítáno více variant s různou délkou provozu služby. Přepočty mezi cenami budou stanoveny podle převodního kurzu ČNB ze dne 1. 4. 2013. Kurz USD pro stanovené datum je 20,072 Kč/USD. 1

5.2

Náklady na vlastní infrastrukturu

Pořizovací cena serveru HP ProLiant DL380p Gen8, specifikace 670854-S01 v požadované konfiguraci zahrnuje 2 : 1

Zdroj: http://www.cnb.cz/cs/financni trhy/devizovy trh/kurzy devizoveho trhu/ denni kurz.jsp [cit. 2013-04-01]. 2 Zdroj: http://h10010.www1.hp.com/wwpc/us/en/sm/WF06b/15351-15351-3328412241644-241475-5177957-5204394-5204395.html?dnr=1 [cit. 2013-04-01].

5.2

66

Náklady na vlastní infrastrukturu

Komponenta Chasis, 2 CPU Intel Xeon E5-2640, 16 GB RAM, 1Gb Ethernet Adapter 4 Porty 8× WD VelociRaptor WD1000CHTZ 2.5” 1TB 10k rpms 8× HP 16GB (1x16GB) DDR3-1600 ECC RAM Celkem

Cena 1

82 275 8× 3 832 2 8× 5 876 3 82 275 + 30 656 + 47 008 = 159 939 Kč

Výsledná pořízená konfigurace tedy zahrnuje celkem 12 jader Intel Xeon E52640 o taktovací frekvenci 2,50 GHz, 108 GB RAM a 8 TB čisté diskové kapacity. Servery se pořizují dva, takže to celé násobeno dvěmi. Jako síťové prvky budou zcela postačující 24 portové switche s 1Gb porty, například HP 2530-24G, v ceně 15 609 Kč4 . Náklady na hosting vycházejí z ceníku Brněnského datacentra společnosti Master Internet, s.r.o. 5 Výsledná cena se skládá z nákladů na prostor v racku, síťovou konektivitu a energii. Vybrané servery jsou výšky 2U, síťové prvky pak každý 1U. Servery mají duální zdroje o výkonu 460 W. Zdroje bývají běžně spíše naddimenzované, aby kryly případné navýšení výkonu, obecně se udává očekávaný odběr mezi 50-60% výkonu zdroje. V tomto případě je maximální odběr jednoho procesoru 95 W 6 , odběr jednoho disku při zátěži 5,10 W 7 . Celkem se tedy jedná o 231 W na komponentách s největší spotřebou, něco navíc odeberou větráky, deska a paměti. Celkem by tedy střední hodnota odhadu měla odpovídat, 920 W × 55% dělá celkem 506 W. Switch má pak maximální odběr 48 W 8 . Celkový maximální odběr by se tedy měl pohybovat odhadem kolem 1100 W. Účel Cena Prostor v racku – celkem 6U 2 × 2140 + 2 × 740 Kč Síťová konektivita – dual Gold line 900 Kč Energie 1100 × 4, 80 = 5280 Kč Celkem 11 940 Kč 1 Zdroj: http://h10010.www1.hp.com/wwpc/us/en/sm/WF06b/15351-15351-3328412241644-241475-5177957-5204394-5204395.html?dnr=1 [cit. 2013-05-19]. 2 Zdroj: http://www.alfacomp.cz/php/product.php?eid=10514007H1TW1YT1RII [cit. 201305-19]. 3 Zdroj: http://www.atcomp.cz/zbozi/hp-16gb-1x16gb-ddr3-1600-ecc-ram-z820-/detail.aspx ?p=z:282020 [cit. 2013-05-19]. 4 Zdroj: http://www.alza.cz/hp-procurve-2530-24g-d415927.htm [cit. 2013-05-19]. 5 Zdroj: http://www.master.cz/konfigurator/ [cit. 2013-05-19]. 6 Zdroj: http://ark.intel.com/products/64591/ [cit. 2013-05-19]. 7 Zdroj: http://www.wdc.com/global/products/specs/?driveID=1200&language=13 [cit. 2013-05-19]. 8 Zdroj: http://h17007.www1.hp.com/us/en/networking/products/switches/HP 2530 Switch Series/ index.aspx#J9776A [cit. 2013-05-19].

5.3

Náklady na IaaS

67

Celkové náklady na hardware a jeho provoz jsou tedy součtem nákladů na oba servery, oba switche a dále měsíčních provozních nákladů za požadovanou dobu. • Horizont 1 rok P1 = 2× 159 939 + 2× 15 609+12× 11 940 = 494 376 Kč • Horizont 3 roky P3 = 2× 159 939 + 2× 15 609 + 36× 11 940 = 780 936 Kč Výši mzdových nákladů pro návrh a realizaci řešení je možné určit pouze na základě stráveného času. Můj odhad pro realizaci zahrnuje následující položky: • analýza a návrh infrastruktury – 2 týdny • tvorba infrastruktury – 4 týdny • testování – 2 týdny Analýza a návrh zahrnují práce architekta, tvorba a testování pak činnost systémového administrátora. Průměrné platy na zmíněných pozicích činily v roce 2010 dle údajů ČSÚ 55 541 Kč u projektantů a analytiků a 35 333 u technických pracovníků. Průměrný meziroční růst platu v oblasti IT je mezi lety 2002 – 2010 6,6% 1 . Vzhledem k tomu, že se jedná o hrubou mzdu, je nutné spočítat superhrubou mzdu, která představuje skutečné mzdové náklady zaměstnavatele. Odvody zaměstnavatele na sociálním a zdravotním pojištění zaměstnanců tvoří 34% hrubé mzdy. P = [ ( 55 541 * 6, 62 * 0,5 ) + ( 35 333 * 6, 62 * 1,5 ) ] * 34 % = 112 990 Kč Výsledkem odhadovaných nákladů včetně mezd je tedy částka 607 366 Kč pro dobu provozu 1 rok a 893 926 Kč pro dobu provozu 3 roky. Částka neobsahuje mzdové náklady na provoz, ty jsou však přítomny u obou srovnávaných variant a částky jsou tedy srovnatelné.

5.3

Náklady na IaaS

Náklady na pořízení formou IaaS v případě Amazon AWS je možné počítat buď ondemand, nebo s předplacením na určitý interval. Vzhledem k tomu, že počítáme minimálně s ročním provozem, budou výpočty probíhat s cenami za předplacené intervaly. Předplacené tarify jsou hrazeny částečně jednorázovou platbou při rezervaci a následně sníženou hodinovou sazbou za provoz. Na výběr je zpravidla ze tří variant podle předpokládané délky provozu, nižší provoz znamená nižší počáteční platbu ale větší hodinové poplatky a naopak. Vzhledem k předpokladu trvalého provozu je brána v potaz varianta pro maximální zátěž. Procesorový výkon definuje Amazon v jednotkách ECU (EC2 Compute Unit), které jsou ekvivalentem procesoru o taktovací frekvenci 1.0 - 1.2 GHz typu 2007 1

Zdroj: http://www.czso.cz/csu/redakce.nsf/i/mzdy it odborniku v ceske republice/ $File/2 ito platy 11.pdf [cit. 2013-05-19].

5.3

Náklady na IaaS

68

Opteron nebo 2007 Xeon. Tři ECU tak velmi zhruba odpovídají jednomu jádru Intel Xeon E5-2640, celkový počet ECU odpovídající vlastní infrastruktuře je tedy 72. Pro výkonové srovnání mezi oběma variantami je zapotřebí zvolit vhodnou infrastrukturu odpovídající hardware v předchozí kapitole. 1. 2× RDS Large MultiAZ – MultiAZ databáze značí, že je v provozu vždy ostrá databáze s pasivní replikou a automatickým failoverem, instance tedy běží dvakrát – 4× 4 ECU a 7 GB RAM; 2. 14× EC2 Large – 14× 4 ECU a 7,5 GB RAM; 3. 2× ELB loadbalancer; Vzorec pro výpočet ceny bude následující: Pi = [P 0 + i × (P H × 24 × 365)] × 20, 072 • • • • • •

P – výsledná cena i – počet let P0 – vstupní cena rezervace PH – hodinová sazba 365 – počet dní v roce 20,072 – kurz USD/CZK

Do vzorce nyní budou dosazeny hodnoty jednotlivých komponent v horiznotech 1 a 3 roky. 1. RDS Large MultiAZ – horizont 1 rok P1 = [1560 + 1 × (0, 314 × 24 × 365)] × 20, 072 = 86 523,17 Kč 2. RDS Large MultiAZ – horizont 3 roky P3 = [2400 + 3 × (0, 236 × 24 × 365)] × 20, 072 = 172 660,94 Kč 3. EC2 Large – horizont 1 rok P1 = [676 + 1 × (0, 087 × 24 × 365)] × 20, 072 = 28 865,95 Kč 4. EC2 Large – horizont 3 roky P3 = [1028 + 3 × (0, 07 × 24 × 365)] × 20, 072 = 57 558,47 Kč Jak je vidět z výsledků, cena provozu s tříletým závazkem odpovídá 2/3 ceny tří po sobě jdoucích jednoletých závazků, snížení ceny je tedy značné. Celkové ceny komponent jsou součtem vypočítaných hodnot v množstvích odpovídajících požadovanému výkonu. • Horizont 1 rok P = (2 × 86523, 17) + (14 × 28865, 95) = 577 169,64 Kč • Horizont 3 roky P = (2 × 172660, 94) + (14 × 57558, 47) = 1 151 140,46 Kč

5.4

5.4

Interpretace výsledků

69

Interpretace výsledků

Z ryze cenového hlediska a za předpokladu, že se nemýlí provedené odhady, tedy vychází cenově lépe vlastní řešení a lépe bude vycházet i u všech větších infrastruktur. Oproti tomu u měnších instalací pravděpodobně bude vycházet lépe pořízení formou služby, neboť bude nižší návratovost některých vstupních nákladů a tvorby řešení. Směrodatný je především výsledek v delším časovém horizontu, neboť se rozpouštějí vysoké vstupní náklady pro pořízení vlastní infrastruktury. V delším období začnou do vlastní infrastruktury vstupovat náklady na obnovu a upgrade, které u pronajaté infrastruktury odpadají. Velmi lišit se u obou variant může výše nákladů na provoz a správu. Jejich výše pravděpodobně bude mírně ve prospěch IaaS, ovšem neznamená to, že s touto formou pořízení infrastruktury odpadají. Naopak při odpovědné práci v oblasti analýzy a návrhu a důsledné realizaci mohou být náklady na správu vlastní infrastruktury velmi nízké.

6

DISKUZE

6 6.1

70

Diskuze Klady a zápory

Výhodou práce je zaměření i na oblasti nadnárodního provozu, neboť pro některé typy nasazení není ryze lokální datacentrum nejvhodnější. Především rozdělení statického obsahu snižuje výrazně zátěž na koncové servery a mezinárodní datové přenosy. Na druhou stranu více datacenter přináší novou řadu problémů v případě zápisu dat. Zatímco read only přístup na webový portál postavený na navrženém řešení neskýtá žádné problémy oproti jednouzlovému řešení, změny v datech pocházející od klientů nebo z vývoje musí být ošetřeny na aplikační vrstvě. Škálovatelnost řešení je druhou silnou stránkou návrhu, neboť umožňuje plně horizontální růst bez potřeby větších zásahů do architektury. Až při velmi výrazné růstu pak může vyvstat potřeba dělit infrastrukturu na dále logicky oddělené celky a rozdělení tematických oblastí nebo skupin klientů mezi ně. Jedním z problémů práce je nedostatečně hluboké pokrytí některých oblastí pro komplexní rozbor možností, které se v různých situacích a implementacích mohou nabízet. V tomto rozsahu bylo možné pouze stručně představit teoretická východiska a navrhnout jednu z cest. Zpracovávaná problematika je však takové hloubky, že ani násobně větší rozsah by spolehlivě a dostatečně nepokryl všechny potřebné oblasti. Největším kandidátem na rozšíření je problematika síťové infrastruktury, která pokrývá skutečně pouze základ a počítá s větší částí realizovanou provozovatelem datacentra, ve které je řešení umístěno. Negativem práce je, že se zabývá stavbou celého řešení pouze nad vlastními komponentami, navíc na bázi open source. Na druhou stranu volba ryze komerční varianty zpravidla není cenově nejvýhodnější – přestože v mnoha aspektech nejvýhodnější být může, především při nedostatku kvalifikované pracovní síly. Celkově optimálním řešením však v majoritním množství případů zůstává kombinace vlastního řešení s využitím komerčních komponent tam, kde vlastní realizace by přinášela příliš mnoho práce nebo nákladů. Typickým příkladem na zpracovávaném textu je tvorba vlastní CDN sítě. Jedná se o relativně složitou problematiku na návrh, provoz i správu, především protože je třeba řešit vhodnou serverovou základnu v několika zemích po celém světě. Oproti tomu komerčních poskytovatelů CDN existuje značné množství, od menších společností s individuálními službami po masová řešení využívaná dokonce i nadnárodními korporacemi, pro které by stavba vlastní sítě mohla znamenat ryze režijní náklady.

6.2

Další vývoj

Práce pokrývá řešenou oblast komplexně, nicméně je plně abstrahována od aplikační vrstvy. Vhodným rozšířením by byly kapitoly týkající se problematiky nasazení a vývoje aplikací. Navržená infrastruktura také může být vhodnou základnou pro poskytování privátního nebo komerčního PaaS řešení.

6.2

Další vývoj

71

Vhodný by byl také rozvoj oblastí týkajících se managementu, monitoringu a především bezpečnosti. Přestože je řešení navrženo s ohledem na plné zabezpečení všech komponent, bezpečnostní aspekty jsou jednou z nejdůležitějších oblastí jeho provozu a měla by jim být věnována maximální pozornost.

7

7

ZÁVĚR

72

Závěr

S příchodem virtualizace se zásadním způsobem změnil model návrhu infrastruktury pod webovými systémy a po relativně dlouhé éře poskytování prostoru pro webové projekty formou hostingů se objevuje služba do té doby relativně neznámá, tedy pronájem všech potřebných infrastrukturních komponent formou služby. Podobně jako odběr služby od komerčního poskytovatele může být variantou realizace vlastního řešení. To však musí splňovat základní parametry nutné pro provoz v enterprise prostředí. První část práce se snaží uvést obecně do problematiky poskytování infrastruktury jako služby. Druhá část navazuje popsáním teoretických východisek jednotlivých komponent, na kterých staví realizační část práce. Vzhledem k faktu, že realizace podobného řešení je sama o sobě nákladná, dlouhodobá a odborně náročná záležitost, je závěr věnován odhadu ekonomického srovnání vlastní infrastruktury s pořízením formou IaaS. Výstupem práce je návrh kompletního infrastrukturního řešení, které splňuje všechny vytyčené cíle – je snadno škálovatelné a umožňuje tak bezproblémový růst, je vysoce dostupné a zůstává plně dostupné i v případě kritické chyby kterékoliv komponenty a zohledňuje problematiku provozu nadnárodních řešení. Realizace je plně postavena na open source řešeních bez nutnosti jakékoliv investice do programového vybavení.

8

8

LITERATURA

73

Literatura

Antonopoulos, N., Gillam, L. Cloud Computing: Principles, Systems and Applications. Springer. 2010. ISBN 1849962405. Agesen, O. Software and Hardware Techniques for x86 Virtualization [online]. [cit. 2013-04-02]. Dostupný z . Arregoces, M., Portolani, M. Data center fundamentals. Cisco Press, 2004. ISBN 1587050234. Bruckner, T., Voříšek, J., Buchalcevová, A., a kol. Tvorba informačních systémů. Grada Publishing a.s., 2012. ISBN 8024741539. Buyya, R., Pathan, M., Vakali, A. Content delivery networks. Springer. 2008. ISBN 354077887X. Disco, C., van der Meulen, B. Getting new technologies together: studies in making sociotechnical order. Walter de Gruyter. 1998. ISBN 311015630X. Dooley, K. Designing Large Scale LANs. O’Reilly Media, Inc., 2009. ISBN 0596551894. Gillam, L. Cloud Computing. Springer, 2010. ISBN 1849962413. Hoopes, J. Virtualization for Security: Including Sandboxing, Disaster Recovery, High Availability, Forensic Analysis, and Honeypotting. Syngress. 2009. ISBN 0080879357. [email protected] http://wiki.squid-cache.org/SquidFaq/SquidMemory/ [online]. [cit. 2013-05-08]. Dostupný z . Lewis, M. Comparing, Designing, And Deploying Vpns. Adobe Press, 2006. ISBN 1587051796. Liu, C., Albitz, P. DNS and BIND. O’Reilly Media, Inc., 2009. ISBN 0596553404. Mahmood, Z., Hill, R. Cloud computing for enterprise architectures. Springer. 2011. ISBN 1447122364. OpenStack Foundation Storage: objects, blocks, and files [online]. [cit. 2013-04-21]. Dostupný z . Oppenheimer, P. Top-Down Network Design. Pearson Education, 2010. ISBN 1587140012. Petersen, R. Fedora 13: Administration, Networking, and Security. Surfing Turtle Press. 2010. ISBN 1936280027. Red Hat, Inc. Red Hat Enterprise Linux Deployment Guide [online]. [cit. 2013-04-25]. Dostupný z . Sakandar, B. Cisco LAN Switching Fundamentals. Cisco Press, 2005. ISBN 1587050897.

8

LITERATURA

74

Schwartz, B., Zaitsev, P., Tkachenko, V., Zawodny, J. D., Lentz, A., Balling, D. J. High Performance MySQL: Optimization, Backups, Replication, and More. O’Reilly Media, Inc. 2008. ISBN 0596554753. Schwartz, B., Zaitsev, P., Tkachenko, V. High Performance MySQL: Optimization, Backups, and Replication. O’Reilly Media, Inc. 2012. ISBN 1449332498. Stanoevska, K., Wozniak, T., Ristol, S. (Eds.) Grid and Cloud Computing. Springer, 2010. ISBN 0071626956. Sumathi, S., Esakkirajan, S. Fundamentals of Relational Database Management Systems. Springer. 2007. ISBN 3540483977. Ruprich, T. Clusterová podpora třívrstvé architektury informačních systémů. Bakalářská práce. Brno: MZLU v Brně, 2007. Tiso, J., Schofield, M. D., Teare, D. Designing Cisco Network Service Architectures (ARCH). Cisco Press, 2011. ISBN 1587142880. Turnbull, J., Matotek, D., Lieverdink, P. Pro Linux System Administration. Apress. 2009. ISBN 1430219130. Velte, T., Velte, A., Elsenpeter, R. Cloud Computing: A Practical Approach. McGraw Hill Professional, 2009. ISBN 0071626956. Williams, D. Virtualization with Xen(tm): Including XenEnterprise, XenServer, and XenExpress: Including XenEnterprise, XenServer, and XenExpress. Syngress. 2007. ISBN 0080553931.

Přílohy

A

A

DNS

76

DNS

view "external-emea-ap" { match-clients { // Evropa geoip_countryDB_countryCode_EU; geoip_countryDB_countryCode_AL; geoip_countryDB_countryCode_BA; geoip_countryDB_countryCode_BG; geoip_countryDB_countryCode_CH; geoip_countryDB_countryCode_CZ; geoip_countryDB_countryCode_DK; geoip_countryDB_countryCode_ES; geoip_countryDB_countryCode_FO; geoip_countryDB_countryCode_FX; geoip_countryDB_countryCode_GI; geoip_countryDB_countryCode_HR; geoip_countryDB_countryCode_IE; geoip_countryDB_countryCode_IT; geoip_countryDB_countryCode_LT; geoip_countryDB_countryCode_LV; geoip_countryDB_countryCode_MD; geoip_countryDB_countryCode_MT; geoip_countryDB_countryCode_NO; geoip_countryDB_countryCode_PT; geoip_countryDB_countryCode_SE; geoip_countryDB_countryCode_SJ; geoip_countryDB_countryCode_SM; geoip_countryDB_countryCode_VA; // Asia Pacific geoip_countryDB_countryCode_AP; geoip_countryDB_countryCode_AF; geoip_countryDB_countryCode_AU; geoip_countryDB_countryCode_BD; geoip_countryDB_countryCode_BN; geoip_countryDB_countryCode_CC; geoip_countryDB_countryCode_CX; geoip_countryDB_countryCode_GE; geoip_countryDB_countryCode_ID; geoip_countryDB_countryCode_IN; geoip_countryDB_countryCode_IQ; geoip_countryDB_countryCode_JO;

geoip_countryDB_countryCode_AD; geoip_countryDB_countryCode_AT; geoip_countryDB_countryCode_BE; geoip_countryDB_countryCode_BY; geoip_countryDB_countryCode_CS; geoip_countryDB_countryCode_DE; geoip_countryDB_countryCode_EE; geoip_countryDB_countryCode_FI; geoip_countryDB_countryCode_FR; geoip_countryDB_countryCode_GB; geoip_countryDB_countryCode_GR; geoip_countryDB_countryCode_HU; geoip_countryDB_countryCode_IS; geoip_countryDB_countryCode_LI; geoip_countryDB_countryCode_LU; geoip_countryDB_countryCode_MC; geoip_countryDB_countryCode_MK; geoip_countryDB_countryCode_NL; geoip_countryDB_countryCode_PL; geoip_countryDB_countryCode_RO; geoip_countryDB_countryCode_SI; geoip_countryDB_countryCode_SK; geoip_countryDB_countryCode_UA;

geoip_countryDB_countryCode_AE; geoip_countryDB_countryCode_AM; geoip_countryDB_countryCode_AZ; geoip_countryDB_countryCode_BH; geoip_countryDB_countryCode_BT; geoip_countryDB_countryCode_CN; geoip_countryDB_countryCode_CY; geoip_countryDB_countryCode_HK; geoip_countryDB_countryCode_IL; geoip_countryDB_countryCode_IO; geoip_countryDB_countryCode_IR; geoip_countryDB_countryCode_JP;

A

77

DNS

geoip_countryDB_countryCode_KG; geoip_countryDB_countryCode_KP; geoip_countryDB_countryCode_KW; geoip_countryDB_countryCode_LA; geoip_countryDB_countryCode_LK; geoip_countryDB_countryCode_MN; geoip_countryDB_countryCode_MV; geoip_countryDB_countryCode_NP; geoip_countryDB_countryCode_OM; geoip_countryDB_countryCode_PK; geoip_countryDB_countryCode_QA; geoip_countryDB_countryCode_SA; geoip_countryDB_countryCode_SY; geoip_countryDB_countryCode_TJ; geoip_countryDB_countryCode_TM; geoip_countryDB_countryCode_TW; geoip_countryDB_countryCode_VN;

geoip_countryDB_countryCode_KH; geoip_countryDB_countryCode_KR; geoip_countryDB_countryCode_KZ; geoip_countryDB_countryCode_LB; geoip_countryDB_countryCode_MM; geoip_countryDB_countryCode_MO; geoip_countryDB_countryCode_MY; geoip_countryDB_countryCode_NZ; geoip_countryDB_countryCode_PH; geoip_countryDB_countryCode_PS; geoip_countryDB_countryCode_RU; geoip_countryDB_countryCode_SG; geoip_countryDB_countryCode_TH; geoip_countryDB_countryCode_TL; geoip_countryDB_countryCode_TR; geoip_countryDB_countryCode_UZ; geoip_countryDB_countryCode_YE;

} recursion no; zone "customer.org" { type master; file "external/named.emea-ap-customer.org"; }; }; view "external-americas" { match-clients { // Severni a~jizni Amerika geoip_countryDB_countryCode_AG; geoip_countryDB_countryCode_AN; geoip_countryDB_countryCode_AW; geoip_countryDB_countryCode_BL; geoip_countryDB_countryCode_BO; geoip_countryDB_countryCode_BS; geoip_countryDB_countryCode_CA; geoip_countryDB_countryCode_CO; geoip_countryDB_countryCode_CU; geoip_countryDB_countryCode_DO; geoip_countryDB_countryCode_FK; geoip_countryDB_countryCode_GF; geoip_countryDB_countryCode_GP; geoip_countryDB_countryCode_GY;

geoip_countryDB_countryCode_AI; geoip_countryDB_countryCode_AR; geoip_countryDB_countryCode_BB; geoip_countryDB_countryCode_BM; geoip_countryDB_countryCode_BR; geoip_countryDB_countryCode_BZ; geoip_countryDB_countryCode_CL; geoip_countryDB_countryCode_CR; geoip_countryDB_countryCode_DM; geoip_countryDB_countryCode_EC; geoip_countryDB_countryCode_GD; geoip_countryDB_countryCode_GL; geoip_countryDB_countryCode_GT; geoip_countryDB_countryCode_HN;

A

78

DNS

geoip_countryDB_countryCode_HT; geoip_countryDB_countryCode_KN; geoip_countryDB_countryCode_LC; geoip_countryDB_countryCode_MQ; geoip_countryDB_countryCode_MX; geoip_countryDB_countryCode_PA; geoip_countryDB_countryCode_PM; geoip_countryDB_countryCode_PY; geoip_countryDB_countryCode_SV; geoip_countryDB_countryCode_TT; geoip_countryDB_countryCode_UY; geoip_countryDB_countryCode_VE; geoip_countryDB_countryCode_VI; }; recursion no;

geoip_countryDB_countryCode_JM; geoip_countryDB_countryCode_KY; geoip_countryDB_countryCode_MF; geoip_countryDB_countryCode_MS; geoip_countryDB_countryCode_NI; geoip_countryDB_countryCode_PE; geoip_countryDB_countryCode_PR; geoip_countryDB_countryCode_SR; geoip_countryDB_countryCode_TC; geoip_countryDB_countryCode_US; geoip_countryDB_countryCode_VC; geoip_countryDB_countryCode_VG;

zone "customer.org" { type master; file "external/named.americas-customer.org"; }; }; view "external" { // sem spadne zbytek, neprovadim specificke smerovani match-clients { any; }; recursion no; zone "customer.org" { type master; file "external/named.customer.org"; }; };

B

B

IP ANYCASTING V CDN SÍTÍCH

79

IP anycasting v CDN sítích

Tento výpis jasně ilustruje, jak se liší vyhodnocení serveru se statickým obsahem z České republiky a ze San Francisca. V obou případech dostane klient ve stránce URL s hostem static.example.org. V obou případech se jedná o CNAME na reálnou adresu cache serveru – abcdef.cloudfront.net. V obou případech ji vrátil nameserver s IP adresou 207.171.170.1. Nicméně k zásadnímu rozdílu dochází když se podíváme, kudy požadavek na nameserver putuje – zde okamžitě zjišťujeme, že se jedná evidentně o dva různé fyzické uzly v oddělených sítích. Každý nameserver pak vrací jinou sadu záznamů pro koncový uzel (tedy dochází ještě ke kombinaci s DNS-based request-routingem). Důkazem je také následné trasování požadavku z USA na IP adresy vrácené v obou vzdálených částech světa (viz obr. 12) – 12 hopů za necelých 11 ms a 21 hopů za 151 ms je významný rozdíl.

B

80

IP ANYCASTING V CDN SÍTÍCH

adresa v odkazu na statický obsah v kódu stránky: adresa reálného cache serveru: nameserver resolvující cache server: Lokace klienta: Dotaz na static.example.org

Nameserver, který nám vrátil adresy abcdef.cloudfront.net Cesta k nameserveru ns-01.cloudfront.net

Lokace klienta: Dotaz na static.example.org

Nameserver, který nám vrátil adresy abcdef.cloudfront.net Cesta k nameserveru ns-01.cloudfront.net

static.example.org abcdef.cloudfront.net ns-01.cloudfront.net

Česká republika ;; QUESTION SECTION: ;static.example.org. IN A ;; ANSWER SECTION: static.example.org. 83508 IN CNAME abcdef.cloudfront.net. abcdef.cloudfront.net. 60 IN A 216.137.57.163 abcdef.cloudfront.net. 60 IN A 216.137.57.245 abcdef.cloudfront.net. 60 IN A 216.137.57.16 abcdef.cloudfront.net. 60 IN A 216.137.57.19 cloudfront.net. 172797 IN NS ns-01.cloudfront.net. cloudfront.net. 172797 IN NS ns-02.cloudfront.net. ;; Received 247 bytes from 207.171.170.1#53(ns-01.cloudfront.net) in 297 ms traceroute to 207.171.170.1 (207.171.170.1), 30 hops max, 40 byte packets 1 r98-bm.cesnet.cz (195.113.224.129) 2.897 ms 2.887 ms 2.887 ms 2 pe-ant.net.vutbr.cz (147.229.252.201) 3.829 ms 4.007 ms 4.178 ms 3 gw-ant.net.vutbr.cz (147.229.253.234) 2.769 ms 3.164 ms 3.564 ms 4 r98-bm.cesnet.cz (147.229.252.17) 0.874 ms 0.992 ms 1.095 ms 5 prag-b3-pos4-0.telia.net (213.248.77.117) 4.178 ms 4.187 ms 4.190 ms 6 win-bb2-link.telia.net (213.155.131.68) 9.624 ms 9.569 ms 9.528 ms 7 ffm-bb2-link.telia.net (80.91.246.30) 22.274 ms 22.277 ms 22.225 ms 8 ffm-b10-link.telia.net (213.155.134.137) 22.266 ms 22.518 ms 22.305 ms 9 a100row-ic-152178-ffm-b10.c.telia.net (80.239.160.34) 22.764 ms 22.594 ms 22.776 ms 10 ns-01.cloudfront.net (207.171.170.1) 22.565 ms 22.533 ms 22.506 ms

USA – San Francisco ;; QUESTION SECTION: ;static.example.org. IN A ;; ANSWER SECTION: static.example.org. 86308 IN CNAME abcdef.cloudfront.net. abcdef.cloudfront.net. 57 IN A 205.251.203.49 abcdef.cloudfront.net. 57 IN A 205.251.203.61 abcdef.cloudfront.net. 57 IN A 205.251.203.81 abcdef.cloudfront.net. 57 IN A 205.251.203.109 cloudfront.net. 172797 IN NS ns-01.cloudfront.net. cloudfront.net. 172797 IN NS ns-02.cloudfront.net. ;; Received 247 bytes from 207.171.170.1#53(ns-01.cloudfront.net) in 2 ms traceroute to 207.171.170.1 (207.171.170.1), 30 hops max, 40 byte packets 1 ip-10-161-44-2.us-west-1.compute.internal (10.161.44.2) 0.746 ms 0.846 ms 0.984 ms 2 ip-10-1-4-1.us-west-1.compute.internal (10.1.4.1) 0.489 ms 0.646 ms 0.650 ms 3 ip-10-1-2-1.us-west-1.compute.internal (10.1.2.1) 0.494 ms 0.637 ms 0.639 ms 4 216.182.236.75 (216.182.236.75) 0.631 ms 0.947 ms 0.947 ms 5 205.251.229.232 (205.251.229.232) 6.823 ms 6.835 ms 6.833 ms 6 205.251.229.216 (205.251.229.216) 2.601 ms 2.135 ms 2.474 ms 7 205.251.230.93 (205.251.230.93) 2.326 ms 2.320 ms 2.305 ms 8 ns-01.cloudfront.net (207.171.170.1) 2.291 ms 2.285 ms 2.278 ms

Obr. 11: Použití anycastu pro směrování provozu

B

IP ANYCASTING V CDN SÍTÍCH

Obr. 12: trasování uzlu vráceného v ČR a v USA z uzlu v San Franciscu

81