Clusterová podpora třívrstvé architektury informačních systémů

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Clusterová podpora třívrstvé architektury informačních systémů Bakalářská práce

Vedoucí práce: RNDr. Ing. Milan Šorm, Ph. D.

Tomáš Ruprich

Brno 2007

Děkuji RNDr. Ing. Milan Šormovi, Ph.D. za vedení, podporu a cenné připomínky při tvorbě této práce. Dále děkuji Ing. Patrikovi Serafinovičovi a Bc. Petru Dadákovi za kontrolu uvedených údajů a odbornou pomoc. Děkuji všem kolegům a spolupracovníkům, neboť bez jejich úsilí by tato práce nemohla být vypracována. A v neposlední řadě děkuji své rodině za všeobecnou podporu během studií.

Prohlašuji, že jsem tuto bakalářskou práci vytvořil samostatně dle pokynů vedoucího práce a za použití zdrojů, které jsou uvedeny v závěru práce. Práce vznikla v rámci řešení výzkumného záměru VZ MSM 6215648904/03/03/01.

V Brně dne 7. 1. 2007

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

4

Abstract Ruprich, T. Cluster support of three level architecture of information systems. Bachelor thesis. Brno, 2007. The bachelor thesis writes about using the cluster server solutions for running of the three level architekture of the infromation systems. First chapters consider detailed description of the self cluster server types. These pieces of knowledge are used at the end for the creation of complete cluster server with clustering on each layer. Thesis is underlaid by real implementations in University information system of Mendel University of Agriculture and Forestry Brno and eLearning information system ELIS.

Abstrakt Ruprich, T. Clusterová podpora třívrstvé architektury informačních systémů. Bakalářská práce. Brno, 2007. Práce pojednává o využití cluster serverových řešení pro provoz třívrstvých informačních systémů. Jednotlivé kapitoly se zabývají podrobným popisem samotných typů cluster serverů. Těchto poznatků je v závěru využito k vypracování komplexního cluster serveru s clusterovou podporou na všech vrstvách. Práce je podložena reálnými případy implementace v Informačním systému Mendelovy zemědělské a lesnické univerzity v Brně a eLearningovém informačním systému ELIS.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Uvedení do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 7

2 Architektury informačních systémů 2.1 Třívrstvá architektura . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9

3 High-availability cluster 11 3.1 Implementace high-availability serveru . . . . . . . . . . . . . . . . . 11 3.2 Ukázka konfigurace high-availability serveru . . . . . . . . . . . . . . 12 4 Load-balancing cluster 4.1 Typy loadbalancing serverů . . . . . . . . 4.2 Network address translation (LVS-NAT) . 4.3 Direct routing (LVS-DR) . . . . . . . . . . 4.4 IP tunneling (LVS-TUN) . . . . . . . . . . 4.5 Implementace loadbalancing clusteru . . . 4.6 Ukázka konfigurace loadbalancing serveru .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

15 15 15 17 18 19 20

5 High-preformance cluster

22

6 Tvorba komplexního třívrstvého cluster serveru 6.1 Hardwarová základna . . . . . . . . . . . . . . . . 6.2 Loadbalancer . . . . . . . . . . . . . . . . . . . . 6.3 Aplikační část serveru . . . . . . . . . . . . . . . 6.4 Databázová část serveru . . . . . . . . . . . . . .

. . . .

23 23 23 24 24

. . . .

25 25 26 26 27

8 Monitoring 8.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Systémové logy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 28 28 28

7 Zabezpečení serveru 7.1 Fyzické zabezpečení . . 7.2 Softwarové zabezpečení 7.2.1 Iptables . . . . 7.2.2 Nessus . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

9 Závěr 30 9.1 Ekonomické srovnání a shrnutí . . . . . . . . . . . . . . . . . . . . . . 30 9.2 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10 Literatura

32

OBSAH

6

Přílohy

33

A Fotografie – serverovna UIS

34

1

ÚVOD A CÍL PRÁCE

1 1.1

7

Úvod a cíl práce Uvedení do problematiky

Cluster server, nebo také virtuální server, je několik počítačů, které se navenek tváří jako jediný stroj. Tato implementace umožňuje výrazné zvýšení výkonu nebo dostupnosti služeb za nižší cenu než při využití jediného velmi výkonného serveru při zachování transparentnosti pro koncové uživatele. Ve své podstatě představuje cluster server rychlou lokální síť (v některých případech i o vzdálenou), tvářící se navenek jako jedniný uzel. Důvodů k zavedení cluster serveru je hned několik: • vysoká spolehlivost služeb, • navýšení výkonu, • využití staršího hardwaru, který by samostatně nebyl použitelný, • centrální správa, • cenová výhodnost. (Kopper, 2005) Současné třívrstvé informační systémy (dále jen IS) se stávají klíčovými prvky velkých organizací, stojí na nich většina rutinních operací celého orgánu. Některé společnosti jsou na svých IS kompletně postaveny a vychází z nich jejich činnost. Tím je na dostupnost IS kladen obrovský důraz, musí být funkční a dostupný neustále každý den v roce. Přesouváním čím dál většího množství operací na stranu IS jsou kladeny požadavky na stále vyšší výkon hardwaru, na kterém IS běží. Pro organizace čítající řádově tisíce lidí jsou v současné době jednotlivé stroje svým výkonem nedostačující. Jejich spojením v cluster server dochází k násobnému navýšení celkového výkonu za mnohem nižší cenu, než by byla za nákup nového supervýkonného stroje. Samostatný stroj jako hardwarová základna velkého IS se v současné době stává velmi rychle zastaralým a nepoužitelným. Využitím cluster serveru se však situace radikálně mění. Staré stroje mohou být nadále součástí clusteru na méně zatěžovaných pozicích, fungovat jako záložní stroje pro kritické komponenty clusteru, nebo je jim jednoduše přidělováno méně dat než výkonnějším strojům. Kombinací všech těchto prvků dochází k vytvoření robustního, vysoce funkčního řešení, avšak za mnohem nižší cenu. Škody způsobené výpadky se v případě dobře nakonfigurovaného cluster serveru limitně blíží nule. Náklady na pořizování nového hardware jsou přitom sníženy o cenu stále využívaných starých strojů.

1.2

Cíl práce

Cílem této práce je analyzovat možnosti využití clusterové architektury pro třívrstvé informační systémy, její výhody a nevýhody a poskytnout zjednodušený pohled do složité problematiky rozsáhlých cluster serverů.

1.2

Cíl práce

8

První část se zabývá jednotlivými typy cluster serverů, jejich základním popisem a rozborem účelu jejich využití. U jednotlivých případů jsou rozebrány příklady jejich typického použití v praxi. Druhá část se zabývá spojením těchto poznatků ve výstavbě cluster serveru jako základny rozsáhlého třívrstvého informačního systému. Závěrem jsou uvedeny a rozebrány nejnutnější prvky správy takového kritického serveru, tedy monitoring a zabezpečení, včetně používaných nástrojů a jejich krátkého popisu.

2

ARCHITEKTURY INFORMAČNÍCH SYSTÉMŮ

2

9

Architektury informačních systémů

Architekturou informačního systému se rozumí funkční základna celého systému, umožňující dosahovat cílů, pro které byl navržen. Na hodnocení architektury informačních systémů obecně se používají dva (resp. tři) pohledy – vertikální, horizontální a kombinace obou předchozích. • Vertikální struktura IS – představuje hierarchickou strukturu z hlediska poskytování služeb jednotlivým řídícím složkám podniku, zatímco • Horizontální struktura IS – představuje členění z pohledu organizační struktury podniku, tedy jeho jednotlivých orgranizačních složek a dává tak možnost k vytvoření jednoltivých subsystémů vrcholové úrovně. Při hlubším členění pak vznikají menší subsystémy v rámci těchto subsystémů (stromová struktura). V praxi je tohoto využito např. rozdělením zodpovědnosti a vedení určitých subsystémů na konkrétní osoby. • Horizontálně-vertikální struktura IS – využití kombinace obou výše zmíněných pohledů dává komplexní pohled na modulární informační systém se specifickými subsystémy a optimalizovaným pohledem na širokou základnu dat z hlediska jednotlivých úrovní řízení. Takový informační systém je pak možné jednoduše integrovat do celopodnikových potřeb a pro větší informační systémy je v současné době nutností. (Šorm, 2005)

2.1

Třívrstvá architektura

Třívrstvá architektura je současným nástupcem předchozí architektury dvouvrstvé. Dvouvrstvá architektura měla (stejně jako třívrstvá) několik podob v závislosti na jejím vývoji a použití. První model obsahoval veškerou aplikační logiku na klientské straně. Jako datových zdrojů vyžíval jednoduchých databází nebo souborů. Vzrůstající náročnost poskytovaných aplikací se však ukázala velkým problémem. Obzvláště proto, že datový tok mezi klientem a datovým úložištěm narůstal do stále větších objemů. Toto se podařilo vyřešit právě vsunutím další vrstvy mezi klienta a datový sklad. Tak vznikla třívrstvá architektura. Díky nově definované vrstvě je možné přesunout velkou část aplikační logiky na úroveň serveru. Tím došlo jednak k výraznému snížení přeneseného objemu dat a jednak k možnosti výrazně zrychlit komunikaci datové a aplikační vrstvy a náležitě toho využít v programovaných aplikacích.

2.1

Třívrstvá architektura

Obr. 1: Třívrstvá architektura

10

3

HIGH-AVAILABILITY CLUSTER

3

11

High-availability cluster

High-availability clustery jsou v současné době pravděpodobně nejpoužívanější skupinou cluster serverů. Jejich primárním významem je vylepšení dostupnosti služeb, které má server poskytovat. Toho je dosahováno použitím nezávislých uzlů, které vzájemně zálohují služby, které zajišťují. Nejčastější počet uzlů u čistých highavailability clusterů je dva, což je nejnižší počet pro zajištění redundance.

Obr. 2: High-availability cluster

Implementace takového clusteru spočívá v určení jednotlivých bodů možného selhání, zajištění jejich nezávislosti a vytvoření failover řešení.

3.1

Implementace high-availability serveru

High-availability server je používán jednak ve své čisté verzi, jednak v kombinaci s load-balancing serverem. Webový server univerzity (www.mendelu.cz) je nejtypičtějším využitím highavailability clusteru. Samotný webserver běží na dvou samostatných strojích. Primární server odpovídá na požadavky z klientské vrstvy, sekundární stroj poskytuje failover. Doménový záznam www.mendelu.cz je nasměrován na IP adresu univerzitního webserveru (195.178.72.103). Ta je obsluhována primárním serverem (znázorněno na obr. 2). Heartbeat běží jako démon na obou strojích. Mezi všemi stroji v highavailability clusteru 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í

3.2

Ukázka konfigurace high-availability serveru

12

server vyšle do sítě „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 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 (znázorněno na obr. 2).

Obr. 3: Výpadek primárního uzlu v případě high-availability clusteru

Web je generován z XML, což je hardwarově náročná operace, proto je prováděna na sekundárním serveru, který je v normálním stavu nevytížený. Pro servisní přístupy proto funguje zvlášť druhá IP (195.178.72.104), na niž je nasměrována doména beta.mendelu.cz. Na ni je nakonfigurován heartbeat „do křížeÿ tak, že v případě výpadku sekundárního serveru převezme tuto úlohu primární server. Vzniká tak jedinečné řešení, využívající jak hardwarového výkonu obou serverů, tak naprosto stabilního řešení v případě výpadku jednoho z obou uzlů.

3.2


High-availability řešení je realizováno pomocí softwaru zvaného heartbeat. Tento software umožňuje vysílání heartbeatů na mezi jednotlivými uzly serveru a navazování událostí na výpadky těchto uzlů. Nejtypičtějším případem této události je převzetí IP adresy sekundárním serverm a zaslání zprávy o výpadku administrátorovi. Obsah konfiguračního souboru /etc/ha.d/ha.cf pro www.mendelu.cz a beta.mendelu.cz:

3.2


13

logfacility local0 keepalive 2 deadtime 15 initdead 20 udpport 694 ucast eth1 192.168.2.1 ucast eth1 192.168.2.2 auto failback on node tubicka1.mendelu.cz node tubicka2.mendelu.cz respawn hacluster /usr/lib/heartbeat/ipfail Popis jednotlivých parametrů konfiguračního souboru /etc/ha.d/ha.cf: • logfacility – použitá facility pro syslog()/logger. • keepalive – jak často mají probíhat jednotlivé kontroly (heartbeaty) (ve vteřinách). • deadtime – doba, po které bude od poslední neúspěšné kontroly prohlášen uzel za mrtvý. • initdead – na některých systémech chvíli trvá, než se po rebootu nastartuje síť a systém začne odpovídat; initdead je doba po restartu, po kterou není brán zřetel na neúspěšné heartbeaty. • udpport – který UDP port používat pro broadcastovou/unicastovou komunikaci. • ucast – tento parametr se v konfiguračním souboru objevje tolikrát, kolik je uzlů v clusteru; každý výskyt se skládá z rozhraní, přes které jsou heartbeaty odesílány a IP adres cílového stroje. • auto failback – pokud je tato volba nastavena na hodnotu „onÿ, přejde heartbeat po výpadku primárního serveru a jeho opětovném naskočení opět na primární; v opačném případě zůstane u obsluhy sekundární server. • node – tento parametr se v konfiguračním souboru objevje tolikrát, kolik je uzlů v clusteru; každý výskyt obsahuje hodnotu uname -a (celé jméno stroje) konkrétního uzlu v clusteru. • respawn – parametr obsahuje název systémového uživatele, pod kterým se má provést příkaz v případě výpadku a cestu k tomuto příkazu. Obsah konfiguračního souboru /etc/ha.d/haresources pro www.mendelu.cz a beta.mendelu.cz: tubicka1.mendelu.cz IPaddr2::195.178.72.103 \ MailTo::[email protected]::www.mendelu.cz tubicka2.mendelu.cz IPaddr2::195.178.72.104 MailTo::[email protected]::beta.mendelu.cz

3.2


14

Popis jednotlivých parametrů konfiguračního souboru /etc/ha.d/haresources: • Konfigurační soubor obsahuje jeden řádek za každý uzel v cluster serveru. Prvním parametrem na řádku je celý název uzlu, uvedený v konfiguračním souboru /etc/ha.d/ha.cf v parametru node. Za tímto povinným parametrem následuje seznam prováděných operací. V našem případě jde o převzetí uvedené IP adresy v případě výpadku a zaslání informačního emailu administrátorům.

4

LOAD-BALANCING CLUSTER

4

15

Load-balancing cluster

Implementace těchto cluster serverů spočívá v průchodu veškeré komunikace jedním nebo více body, tzv. load-balancery, které rozdělují zátěž mezi jednotlivé koncové servery. Přestože je jejich primárním cílem zvýšení výkonu serveru, bývají nejčastěji provozovány v kombinaci s high-availability řešeními. O takovém cluster serveru se pak často hovoří jako o serverové farmě. Taková řešení mohou obsahovat desítky, stovky i tisíce uzlů, obzvláště v kombinaci s high-availability clusterem, kdy redundace je nutná na všech třech vrstvách systému. Centrálním strojem celého clusteru je loadbalancer, často nazývaný také direktor. 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 počítač, který jako jediný z celého cluster serveru 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).

4.1

Typy loadbalancing serverů

Jednotlivé typy loadbalancing serverů se liší především v metodě rozdělování příchozích požadavků na uzly uvnitř clusteru a komunikace s nimi. Jeden LVS může samozřejmě v případě potřeby využívat více různých metod. Tři v současné době standardizované a používané metody jsou: • Network address translation (LVS-NAT) • Direct routing (LVS-DR) • IP tunneling (LVS-TUN) LVS-NAT je metodou nejjednodušší. Metoda LVS-DR je svým cílem naprosto stejná, liší se však ve způsobu odpovědi na přijaté požadavky. LVS-TUN je metodou používanou převážně na nekritické domény a svým účelem se od předchozích dvou liší.

4.2

Network address translation (LVS-NAT)

V této konfiguraci využívá direktor schopnosti linuxového jádra (konkrétně iptables) překládat IP adresy a porty procházejících jádrem. Tato metoda je nazývána překlad síťových adres (Network address translation). Direktor přijímá požadavek od klienta na své VIP a přeposílá jej na jeden z reálných serverů na jeho RIP. Reálný server jej zpracuje a výsledek pošle na DIP loadbalanceru. Ten přepíše zdrojovou adresu na VIP a forwarduje pakety zpět na klienta. Tím je dosaženo toho, že klientský počítač nepozná, zda byl požadavek

4.2

Network address translation (LVS-NAT)

Obr. 4: Loadbalancer

16

4.3

Direct routing (LVS-DR)

17

vyřízen cluster serverem nebo samostatným strojem a nemusí se tím tedy vůbec zatěžovat.

Obr. 5: Network address translation (LVS-NAT)

LVS-NAT se vyznačuje několika základními vlastnostmi: • RIP jsou voleny podle RFC1918 (tzn. v jednom z rozsahů 10.0.0.0 až 10.255.255.255, 172.16.0.0 až 172.31.255.255 a 192.168.0.0 až 192.168.255.255), • direktor zpracovává veškerou komunikaci procházející v obou směrech mezi klientskými počítači a vnitřním prostředím cluster serveru, • vnitřní uzly používají DIP jako gateway pro komunikaci s klienty, • loadbalancer umí přepisovat čísla portů, tzn. požadavek, který direktor přijal na své VIP na jednom portu může být na RIP poslán na portu jiném, • reálné servery jsou naprosto nezávislé na použitém operačním systému. (Kopper, 2005)

4.3

Direct routing (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-DR se vyznačuje několika základními vastnostmi: • uzly uvnitř clusteru musí být na stejném segmentu sítě jako direktor, • RIP nemusí být voleny z privátních okuhů IP adres (tzn. nemusí podléhat přímo RFC 1918), • direktor zpracovává veškerou příchozí, nikoliv však odchozí komunikaci mezi klientem a cluster serverem, • vnitřní uzly běžně nepoužívají loadbalancer jako gateway pro komunikaci s klienty,

4.4

IP tunneling (LVS-TUN)

18

Obr. 6: Direct routing (LVS-DR)

• direktor nemůže měnit čísla portů, • na reálném serveru může být použit jakýkoliv oprační systém, který má možnost nakonfigurovat své síťové rozhraní, aby bylo zakázáno odpovídání na ARP dotazy na VIP, • při použití metody LVS-DR je možné použít více reálných serverů než při použití metody LVS-NAT, neboť loadbalancer není tolik zatěžován (veškerá odchozí komunikace jde už přímo). LVS-DR má však oproti LVS-NAT ještě jednu nespornou výhodu, která se týká výpadku loadalanceru. Reálné servery mají totiž běžné veřejné IP adresy a stávají se proto běžnými distribuovanými servery. Buď se tedy nechá zpracovávat požadavky jediný stroj, čímž bude sice snížen výkon celého systému, ale nedojde k výpadku celého systému, nebo se využije metody round-robin DNS. Tato metoda je sice nestandardní, avšak je funkční a v kritických případech využitelná. Spočívá v nasměrování jedné domény na více IP adres. Záznam v zónovém souboru tedy bude nějak vypadat takto: #round-robin DNS pro www.cluster.mydomain www.cluster.mydomain IN A 100.100.100.1 www.cluster.mydomain IN A 100.100.100.2, a reverzní záznam takto: 1 IN PTR www.cluster.mydomain 2 IN PTR www.cluster.mydomain. Výsledný efekt bude takový, že první požadavek půjde na stroj s IP 100.100.100.1, druhý požadavek na 100.100.100.2, třetí požadavek na další stroj, nebo po využití všech strojů opět na první. (Kopper, 2005)

4.4

IP tunneling (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.

4.5

Implementace loadbalancing clusteru

19

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.

Obr. 7: IP tunneling (LVS-TUN)

Základní vlastnosti metody LVS-TUN: • uzly uvnitř clusteru nemusí být na stejném segmentu sítě jako direktor, • RIP nemusí být voleny z privátních okuhů IP adres (tzn. nemusí podléhat přímo RFC 1918), • direktor zpracovává veškerou příchozí, nikoliv však odchozí komunikaci mezi klientem a cluster serverem, • vnitřní uzly nesmí používat direktor jako bránu pro komunikaci s klientem (výchozí brána nemůže být DIP, ale router, nebo podobné zařízení, které je na stejném segmentu sítě jako reálný server a odpoví přímo klientovi), • direktor nemůže měnit čísla portů, • na reálném serveru může být použit jakýkoliv oprační systém, který podporuje IP tunelování. Využití nachází metoda LVS-TUN především u geograficky velice vzdálených reálných serverů. To však velmi snižuje spolehlivost a rychlost koumunikace.

4.5

Implementace loadbalancing clusteru

Typickým využitím loadbalancing clusteru je server projektu ELIS (elis.mendelu.cz). Celý cluster server sestává dohromady z devíti strojů. VIP loadbalanceru je 195.178.72.180 a jako forwardovací metody využívá LVS-NAT. RIP pěti aplikačních serverů jsou proto z neveřejného rozsahu IP adres (10.0.0.0). Každý stroj je na svém druhém síťovém rozhraní připojen do databázové VLAN (10.0.1.0). Zde je umístěn databázový server, který je však pro direktora neviditelný. Z hlediska loadbalanceru jsou relevantní jen aplikační servery, to, jak dosahují vyřízení požadavků jej nezajímá. Databázový server je dále připojen do poslední, servisní VLAN (10.0.2.0). Do databázové i servisní VLAN je připojen monitorovací a zálohovací server, který se

4.6

Ukázka konfigurace loadbalancing serveru

20

tímto dostane přímo ke všem strojům uvnitř celého clusteru. Posledním strojem, připojeným taktéž do servisní VLAN je vývojářský server, na kterém probíhá vývoj a běží na něm vývojová verze projektu. Jednoznačnou výraznou slabinou serveru je v současné době loadbalancer. Při výpadku loadbalanceru dojde k odstavení celého systému. Logickým řešením této situace by bylo využití heartbeatu a vytvoření high-availability řešení na úrovni loadbalancerů. (Kopper, 2005)

4.6


Funkce loadbalanceru je zajištěna softwarem zvaným ldirector. Tento software udržuje dynamicky seznam aplikačních serverů, provádí kontroly jejich funkčnosti a pokud v závislosti na konfiguraci shledá nějaký server neschopným odpovídat na požadavky klientů, vyřadí jej. Příklad konfiguračního souboru /etc/ldirectord.conf: checktimeout=50 checkinterval=60 autoreload=yes quiescent=no virtual=195.178.72.180:80 real=10.0.0.1->10.0.0.255:80 masq fallback=10.1.0.1:81 masq service=http request="/ipvs.pl" receive="OKAY" scheduler=wrr persistent=600 netmask=255.255.255.255 protocol=tcp Popis jednotlivých parametrů konfiguračního souboru /etc/ldirectord.conf: • checktimeout – doba, po které bude uzel označen za mrtvý. • checkinterval – jak často mají probíhat kontroly jednotlivých uzlů. • autoreload – pokud nastaveno na hodnotu „yesÿ, kontroluje démon ldirectoru periodicky konfigurační soubor a v případě změny ji na sebe rovnou aplikuje. • quiescent – pokud nastaveno na hodnotu „noÿ, dochází v případě výpadku uzlu k okamžitému odstranění z IPVS tabulky (a přerušení veškerých spojení na tento uzel). V opačném případě je pouze nastavena váha (weight) uzlu na 0 (nejsou na něj přeposílány žádné požadavky). Může však docházet k tomu, že se server může pro některé klienty jevit jako nefunkční, neboť spojení je stále navázáno. • virtual – adresa virtuálního serveru (VIP – viz. výše), následována obsluhovaným portem.

4.6


21

• real – seznam všech aplikačních serverů. Syntaxe parametru real je následující: real=RIP:port gate|masq|ipip [weight]. Gate, masq a ipip jsou povinné a určují forwardovací metodu. Metoda gate znamená metodu LVS-DR, ipip LVSTUN a masq LVS-NAT. Váha stroje je volitelná a říká, jaké množství požadavků má být na klientský stroj posíláno. • fallback – adresa serveru, který bude sloužit jako fallback v případě výpadku všem uzlů. • service – služba, kterou kontrolujeme. • scheduler – metoda výběru aplikačního serveru. • persistent – po jakou dobu je udržováno spojení s klientem v tabulce uzlů. • netmask – síťová maska kontrolovaného uzlu. • protocol – protokol používaný pro kontroly.

5

5

HIGH-PREFORMANCE CLUSTER

22

High-preformance cluster

Cílem high-performance clusterů je poskytnout vyšší výkon rozdělením výpočetních úkonů mezi více různých uzlů uvnitř clusteru. Nejčastější použití nacházejí u náročných vědeckých a vesmírných výpočtů. Běžně jsou na nich pouštěny programy vytvořené přímo pro paralelní výpočetní úkony, nebo takové, kdy mezivýpočty provedené na jednom uzlu jsou využívány a ovlivňují výpočty na ostatních uzlech. Jejich využití pro účely webových informačních systémů je velmi řídké, neboť zde není potřeba paralelních výpočtů časově náročných operací, ale mnoha jednotlivých drobných uživatelských požadavků. Rozdělování zátěže je u tohoto typu serverů poněkud odlišné a řídí se jinými pravidly. Celý tento proces se nazývá Resource Management and Scheduling (RMS). RMS označuje celý děj rozdělování aplikačních požadavků mezi jednotlivé výpočetní uzly, za účelem maximalizace jejich průchodnosti a efektivního využití dostupných zdrojů. Software provádějící RMS sestává ze dvou komponent: • resource manager • resource scheduler Resource manager se zabývá vyhledáním a alokací výpočetního výkonu, autentizací, tvorbou procesů a jejich přesuny. Resource scheduler má na starosti řazení jednotlivých požadavků do fronty a zároveň vyhledávání a přidělování zdrojů. (Buyya, 1999)

6

TVORBA KOMPLEXNÍHO TŘÍVRSTVÉHO CLUSTER SERVERU

6 6.1

23

Tvorba komplexního třívrstvého cluster serveru Hardwarová základna

Jednotlivé typy cluster serverů mají velmi rozdílné způsoby využití, a i jednotlivé servery téhož typu se často dost liší. Proto odpovídá výběr hardwaru jednoznačně zaměření serveru. Obecně nejsilnějším strojem clusteru bývá databázový server. Jednak proto, že většinou obsluhuje více aplikačních strojů najednou, a jednak proto, že samotný databázový systém bývá velice hardwarově náročný. V případě menších clusterů pro řádově stovky uživatelů je v současné době ideální volbou víceprocesorový opteron 64-bitové architektury s dostatkem paměti a jako databáze postačí PostgreSQL nebo MySQL. V případě větších informačních systémů pro řádově tisíce až desetitisíce uživatelů se již vyplatí uvažovat o RISCových architekturách, které jsou sice mnohem cenově náročnější, avšak jejich výkon je násobně vyšší a jsou určeny právě pro vykonávání mnoha drobnějších databázových operací. Opensource databázový systém již v tomto případě nemusí postačovat a je vhodné porovnat cenové náklady za použití komerční databáze (např. Oracle) s výhodami, jež toto řešení přináší. Častým problémem je nedostatečný výkon databázového serveru, obzvláště u větších informačních systémů, neboť přidávání dalších strojů bývá neúnosným z hlediska správy serverů při zachování konzistence ukládaných dat a univerzálnosti celého řešení. Navyšování výkonu jednotlivých strojů je naopak cenově nevýhodné řešení, neboť od určité úrovně cena zařízení roste nesrovnatelně více než nárůst celkového výkonu. Řešením je v tomto případě přesun co největší části databázové zátěže na stranu aplikačních strojů (např. využití cache nejčastějších databázových výběrů na straně aplikačního serveru a následné snížení požadavků na databázové straně) Pokud mají aplikační servery provádět „pouzeÿ generování webových stránek, dá se jejich potřebný výkon jednoduše změřit a vyzkoušet. V současné době je opět nejlepším řešením z hlediska poměru cena/výkon 64-bitová architektura. Počet procesorů se bude zvedat s počtem uživatelů a prováděných operací. Paměťová zátěž nebývá v případě čistě aplikačních serverů nijak závratně vysoká.

6.2

Loadbalancer

Loadbalancer je jakýmsi hraničním prvkem na pomezí vnitřního a vnějšího světa z hlediska cluster serveru. Na straně jedné stojí klientské počítače, vysílající své požadavky na informační systém, reprezentovaný v tuto chvíli samotným loadbalancerem. Úlohou loadbalanceru je veškeré tyto požadavky zpracovat, předat adekvátním způsobem podle nadefinovaného schématu relevantním uzlům uvnitř clusteru a po obdržení odpovědi ji poskytnout zpět žadateli, jakoby ji zpracoval on sám. Loadbalancer je stěžejním prvkem celého serveru, takže je nutné zabezpečit jeho trvalou funkčnost. Toho docílíme použitím dvou loadbalancerů kontrolovaných

6.3

Aplikační část serveru

24

vzájemně pomocí již výše zmíněněého heartbeatu. V případě výpadku jednoho stroje tak dojde k okamžitému nahrazení jeho funkcí strojem sekundárním a administrátoři mají zpravidla dost času opravit první stroj, nebo jej nahradit za jiný.

6.3

Aplikační část serveru

Jednotlivé aplikační stroje tvoří samostantou interní VLAN zajišťující veškerou aplikační logiku. V případě nedostatkového výkonu databázového serveru zkusíme tvořit datovou cache nejčastěji vybíraných dat přímo na těchto strojích, abychom omezili přístupy do databáze. V případě potřeby mohou být jednotlivé aplikační stroje různých konfigurací, dokonce různých operačních systémů. V takovém případě je nutné správně nakonfigurovat váhy jednotlivých strojů, tedy jaké množství požadavků jim bude přidělováno.

6.4

Databázová část serveru

Navýšení výkonu databázové části clusteru je nejnáročnější etapou konfigurace celého serveru. V současné době poskytuje přímou podporu pro tvorbu databázového clusteru z nejčastěji používaných databázových systémů pouze MySQL a Oracle. Základním rysem databázového clusteru je to, že jde o jednu databázi, ke které může přistupovat více různých instancí. Každá instance běží na jiném stroji, čímž je opět dosaženo jednoduššího rozšiřování clusteru v případě potřeby většího výpočetního výkonu a zajištění dostupnosti dat i v případě výpadku některého databázového uzlu. Každý stroj musí být připojen minimálně jednou do lokální sítě, přes kterou se k němu budou moci připojit jednotlivé aplikační servery, minimálně jednou do privátní sítě, po které spolu komunikují jednotlivé uzly databázového clusteru (interconnect) a nakonec k datovému úložišti. Samotné datové úložiště může být network attached storage (NAS), storage area network (NAS) nebo SCSI disk. Databázový systém si pak udržuje tzv. lock database, tedy databázi informací o změnách prováděných nad společným datovým úložištěm, z důvodu konzistence databáze při současných žádostech o práci se stejnými daty.

7

ZABEZPEČENÍ SERVERU

7

25

Zabezpečení serveru

Zabezpečení serveru je v současné době nejdůležitějším úkolem většiny správců serverů a vůbec síťové infrastruktury. Útoky na servery můžeme rozdělit do dvou kategorií – útoky fyzické a útoky softwarové.

7.1

Fyzické zabezpečení

Fyzické útoky jsou dnes méně časté, než útoky softwarové, které jsou v podstatě na denním pořádku. Tento typ útoku probíhá nezávisle na nasazeném operačním systému a použitém programovém vybavení. Ideální fyzické zabezpečení serverovny by bylo mít ji umístěnu několik metrů pod zemí, zatavenou v pancéřové bedně bez možnosti přístupu, s napájením naprosto nezávislém na okolí, dokonale fungující klimatizací a takovým typem připojení, které není možné žádným způsobem narušit. Toto však v praxi naprosto není možné. Málokterá organizace si buď dostatečně uvědomuje potřebu takového typu zabezpečení, nebo má finanční možnosti nutné pro jeho realizaci. Zářným příkladem opaku je například firma Sun Microsystems, jejíž zabezpečení serverovny je v rámci reálných možností dle mého názoru ideální (foto viz Příloha X). Dále je potřeba umožnit správcům alespoň občasný přístup ke strojům, z důvodu upgradů a servisních prací. Zabezpečení proti přístupu neautorizovaných osob na serverovnu je nejdůležitější a řeší drtivou většinu možných fyzických útoků. Cílené napadení je prováděno za účelem zničení stroje a znepřístupnění poskytovaných služeb, nebo za účelem získání dat uložených na napadeném stroji. Jedinou možností, jak zabránit prvnímu typu útoku je znemožnit útočníkovi přístup do místnosti se strojem. V případě, že toto zabezpečení selže je nutné mít data jednak zazálohovaná (viz. kapitola Zálohování), a jednak mít zamezeny možnosti krádeže softwaru. K zamezení přístupu k samotným datům je nutné dodržet několik málo základních pravidel. Je nutné mít zamčený celý stroj a mít tak zamezenou možnost odnést celý server a dostat se ke vnitřním komponentám stroje, například baterii BIOSu. Dalšími dvěma pravidly, dnes už snad naprosto samozřejmými je mít zaheslovaný BIOS a zavaděč operačního systému. Zaheslováním BIOSu znemožníme změnu bootovacích parametrů stroje, tzn. neumožníme útočníkovi nabootovat z předpřipraveného CD, DVD nebo diskety a získat v podstatě neomezenou vládu nad celým strojem. Podobné možnosti často umožňuje i zavaděč, například použití unixového single user režimu. Posledním doporučovaným opatřením je mít šifrovaná data na disku, což znemožní, nebo alespoň výrazně ztíží útočníkovi získat data z ukradeného harddisku. Druhý typ fyzického útoku je necíleného charakteru. Jde o události nezaviněné (zpravidla) útočníkem, například výpadky proudu a připojení, přehřátí serverovny apod. Výpadky proudu řeší UPS a zdroje proudu nezávislé na dodávkách energie z veřejné sítě, např. dieslové agregáty (viz. níže). Výpadek připojení sítě bývá řešen více navzájem nezávislými typy připojení. Zálohou pro případ nouze je vytáčené

7.2

Softwarové zabezpečení

26

připojení pro přístup k serverům v při nemožnosti jiného řešení. Opatření proti přehřátí serverů je snad jen dobře fungující a nastavená klimatizace.

7.2 7.2.1

Softwarové zabezpečení Iptables

Iptables jsou bezesporu nejhojněji využívaný unixový bezpečnostní software. Jedná se totiž o nativní unixový firewall, jehož velká síla nyní spočívá jednak v opravdu dlouhém použivání obrovským množstvím špičkových odborníků, z čehož vyplívá několikanásobná kontrola zdrojových kódů a minimální děravost, jednak integrace iptables přímo do kernelu, což znemožňuje obejití pravidel iptables na aplikační úrovni a jednak obrovská robustnost celého řešení. Dobře nastavený firewall je dnes nezbytnou součástí každého stroje v síti, a to nejen serveru, u kterého to však platí dvojnásob. Firewall je systém, který brání lokální síť před veškerým nechtěným provozem přicházejícím z vnější sítě. Bývá umístěn v jediném bodě spojujícím vnitřní a vnější síť, což znamená, že jak příchozí tak odchozí komunikace je nucena projít přes pravidla firewallu. Iptables však kromě definování vstupních a výstupních pravidel umožňují definovat pravidla směrování. V případě cluster serverů je směrování využíváno vždy, a proto je tato vlastnost iptables velkou výhodou, neboť stanovení pravidel je následně velmi efektivní a robustní. Model správy iptables je velmi jednoduchý. Firewall je rozdělen do řetězců (chain), které pak obsahují vlastní pravidla chování k obsluhované komunikaci. Iptables obsahují v počáteční konfiguraci tři základní řetězce. Tyto řetězce jsou INPUT, FORWARD a OUTPUT. Jak již napovídají názvy jednotlivých řetězců, INPUT má na starosti příchozí pakety určené pro náš systém, FORWARD příchozí pakety, které však nemají cíl na našem systému a OUPUT veškerou odchozí komunikaci. Ve chvíli, kdy paket dorazí do jednoho z řetězců, prochází jedno po druhém všechna nadefinovaná pravidla. Pravidlo se skládá z několika parametrů, které definují vlastnosti paketu, pro které má být vykonána daná činnost. Základními parametry jsou například protokol, zdrojová a cílová adresa, zdrojový a cílový port a mnoho dalších. Pokud paket parametrům v pravidle vyhoví, je s ním provedena akce, která byla danému pravidlu nadefinována a paket je z řetězce vyřazen. Základními akcemi jsou DROP, REJECT a ACCEPT. DROP a REJECT jsou zamítnutí paketů, rozdíl je však v následné odpovědi. Zatímco DROP paket prostě zahodí, neodpovídá tedy vůbec, REJECT vyšle zpět informaci o zamítnutí paketu (Toho však bývá často zneužíváno pro různé varianty DoS útoků). Akce ACCEPT znamená přijetí paketu. Speciální akcí je pak LOG, kdy je informace o paketu zapsána do systémového logu. Tato akce je svým chováním zvláštní z toho důvodu, že po jejím provedení paket pokračuje v průchodu řetězcem. Pro paket, který nevyhoví žádnému pravidlu je provedena akce nastavená jako výchozí pro celý řetězec.

7.2

Softwarové zabezpečení

27

Kromě přednastavených řetězců je možné si zakládat řetězce vlastní, které usnadňují orientaci ve větších firewallech, čítajících řádově tisíce pravidel. Tyto řetězce jsou pak používány jako cílová akce daného paketu. Pro specializované akce zahrnující přepisování parametrů jednotlivých paketů a pokročilé přeposílání paketů, existuje ještě několik tzv. tabulek, obsahujících jednotlivé řetězce. Základní tabulkou, popsanou výše, je tabulka filter. Tabulkou užívanou pro změny parametrů paketů je mangle, pro navazování nových spojení mezi různými zdrojovými a cílovými stroji tabulka nat, a poslední tabulkou je raw, která umožňuje převážně tvořit výjimky na stopovacích pravidlech. 7.2.2

Nessus

Nessus je špičkový bezpečnostní software, dalo by se říci nejlepší na trhu open-source produktů, pro testování zabezpečení serveru. Nová verze Nessusu s novým jádrem však již bude pouze freeware, neboť společnost Tenable Network Security uzavřela zdrojové kódy. Děje se tak z důvodu nedodržování GPL licence komerčními firmami. Testování Nessusem probíhá po instalaci dvou částí – serveru a klienta. Server může být nainstalován na kterémkoliv stroji, na který mohou být po síti odesílány výsledky ke konečnému vyhodnocení. Samotné testování probíhá ze stroje, kde je nainstalován klient. Ten zkouší provádět nejznámější síťové útoky a získávat informace o nainstalovaném softwaru, otevřených portech a bezpečnostních dírách. Stačí zvolit cílové stroje a testy, které se mají provádět. U cluster serverů je obzvlášť vhodné provádět sérii testů jednak zvenku a jednak také zevnitř cluster serveru.

8

MONITORING

8 8.1

28

Monitoring SNMP

SNMP (Simple Network Management protocol) je asynchronní, transakčně orientovaný protokol, používaný pro získávání informací o událostech na síťových prvcích. V zásadě existují dvě možnosti využití SNMP. První varianta je vyžádaná kontrola stavu, druhou tvoří tzv. trapy, které jsou odeslány při výskytu konkrétní předem nadefinované události. Na straně jedné tak stojí tzv. SNMP klient, který požadavky vysílá, na straně druhé pak SNMP agent, který požadavky přijímá, zpracovává a odpovídá na ně. Aby se klient i agent mohli domluvit, musí dojít ke sjednocení identifikátorů označujících jednotlivé kontrolovatelné entity. To se děje za pomoci objektově orientované fatabáze MIB (Management Information Base). MIB je stromem objektů obsahujících další obejkty a třídy.

8.2

Nagios

Nagios je velmi mocný monitorovací nástroj, pomocí nějž je možné sledovat funkčnost síťových prvků a jednotlivých služeb, které poskytují. Je to důležité především u produkčních serverů, u kterých mohou výpadky znamenat vážné problémy. Nagios je vyvíjen primárně pro operační systém Linux, je však funkční pod drtivou většinou UNIXových systémů. Jeho provoz je postaven na běhu stejhnojmenného démona, který v pravidelných intervalech spouští kontroly na stroje a služby definované v konfiguračních souborech pomocí zvolených pluginů. Každá kontrola vrací stavové informace nagiosu, který reaguje upozorněním na email, ICQ nebo mobilní telefon administrátora. To umožní správci zjistit problém dřív, než začnou chodit stížnosti od klientů nebo koncových uživatelů.

8.3

Systémové logy

Jedním z nejdůležitějších momentů správy serverových systémů je sledování systémových logů. V případě velkého množství strojů však dochází ke značnému poklesu efektivity této činnosti, neboť jde řádově o desítky až stovky megabytů textu denně a to z mnoha různých strojů. Nutností je provádět kontroly v dostatečně krátkých časových intervalech, jednak proto, aby byla případná chyba zavčasu odhalena, jednak proto, aby nebyl útočníkovi dán čas k tomu, aby logy po svých pokusech náležitě upravil. Výrazného zefektivnění této činnosti tak dochází sběrem logů na centrálním monitorovacím stroji a následným čtením ne mnoha jednotlivých varovných zpráv, ale jedné souhrnné. Další výhodou distribuovaného sběru je nutnost kontrolovat zaplnění disku logy jen na jediném stroji, nikoliv na všech strojích celého serveru. Jednoznačně nejpoužívanějším nástrojem pro sběr logů je syslog. Výhodou je naprosto jednoduché a robustní použití na UNIX-like systémech. Na jednotlivých

8.3

Systémové logy

29

strojích uvnitř clusteru dochází k nastavení přeposílání systémových logů na centrální monitorovací server v konfiguračním souboru /etc/syslog.conf: *.* @192.168.0.1 Na serveru pak stačí povolit příjem služby syslog na firewallu. Výhodné je také použití libovolného nástroje pro třídění a filtraci logů, například syslog-ng. Ten umožňuje jednak třídění logů z různých strojů do svých vlastních adresářů v systému, a jednak umožňuje navázání jakékoliv systémové operace na událost příjmu zprávy. Pro třídění a filtraci zpráv umožňuje použití regulárních výrazů.

9

ZÁVĚR

9 9.1

30

Závěr Ekonomické srovnání a shrnutí

Jednoznačnou výhodou clusterserverového řešení je cena. Zatímco cenový nárůst za zvyšování výkonu přikoupením dalších uzlů je stále lineární, v případě výběru jednoho stroje s mnoha procesory dochází od určité úrovně k mnohém strmějšímu růstu. Samozřejmě při použití více strojů nedochází plnému růstu výkonu vzhledem k relativně vysoké režii, takže je třeba pro měření výkonu použít složitější metody než jen počet procesorů. Zmíněný cenový jev je vidět na následujícím srovnání: • Sun Fire X4600 (8 × 2, 6 GHz dual-core AMD, 16 × 400MHz 2048 MB RAM), cena 1 178 760,- Kč • 4× Sun Fire X2200 M2 (2 × 2, 6 GHz dual-core AMD, 4 × 667MHz 2048 MB RAM), cena 4 × 144 666,- Kč = 578 664,- Kč Ceny a konfigurace převzaty z http://www.64bit.cz/ Z uvedeného příkladu je vidět, že v případě nákupu čtyř dvouprocesorových serverů ušetříme při stejném počtu procesorů a stejné velikosti operační paměti polovinu celkové částky za nákup jednoho velmi výkonného stroje. To dává dostatečný prostor pro vyrovnání systémové režie na jednotlivých strojích. Další nespornou výhodou je právě stabilita serveru v případě selhání hardwaru. Jediný stroj je velmi náchylný na selhání procesoru, paměti, disku, nebo v podstatě jakékoliv jiné komponenty, což znamená u obou řešení výpadek stroje. V případě správně nakonfigurovaného cluster serveru však funkci neběžícího uzlu přebírá uzel sekundární, resp. zbylé identické uzly, v případě jediného stroje dojde k výpadku poskytované služby v řádu několika desítek minut až hodin. Nevýhodou clusterového řešení je větší náročnost na správu. Přestože jsou jednotlivé skupiny strojů identické, nebo velmi podobné, je stále třeba starat se o velké množství strojů. Také celková implementace celého systému je náročnější. Dalším negativem je celková prostorová, tepelná a energetická náročnost. Na tuto problematiku je třeba myslet již v době stavby serverovny, neboť zanedbání této skutečnosti může v budoucnu působit vážné potíže.

9.2

Závěr

Využití cluster serverů je obrovské a v současné době je trendem, kterým se svět hardwarové základny rozsáhlých informačních systémů ubírá. Na MZLU v Brně, která dala prostor k napsání této práce, je Univerzitní informační systém postaven na clusterserverovém řešení již pátým rokem a řešení je neustále zdokonalováno a upgradováno. A dá se říci, že dokud neskončí vývoj informačního systému a ostatních podpůrných subsystémů, bude pokračovat i vývoj systémové a hardwarové základny. Myslím, že se mi podařilo splnit všechny cíle, které jsem si po domluvě s vedoucím práce v počátcích vytyčil. Nejde však jen o teoretické shrnutí dané proble-

9.2

Závěr

31

matiky, ale také o dokumentaci stávajícího stavu systémového řešení Univerzitního informačního systému MZLU v Brně. Tato práce tak poskytuje všem zájemcům možnost něco se o této rozsáhlé a velmi perspektivní oblasti systémové administrace a správy serverů dozvědět.

10

10

LITERATURA

32

Literatura

Kopper, K. The Linux Enterprise Cluster. San Francisco: No Starch Press, 2005. ISBN 1-59327-036-4. Buyya, R. High Performance Cluster Computing: Architectures and Systems, Vol. 1. New Jersey: Prentice Hall, 1999. ISBN 0-13-013784-7. Ruprich, T., Los, M., Loučka, Z. Využití cluster serveru v konkurenčním prostředí. In MOTYČKA, A. Informatika XVII/2005 – Sborník příspěvků. Brno: Konvoj, 2005. ISBN 80-7302-110-2. Šorm, M. Využití principu skládání komponent při návrhu webového informačního systému. Disertační práce. Brno: MZLU v Brně, 2005. Hart, M., Jesse, S. Oracle database 10g high availability with RAC, Flashback & Data Guard. New York: McGraw-Hill/Osborne, 2004. ISBN 0-07-225428-9. Buyya, R. High Performance Cluster Computing: Programming and Applications, Vol. 2. New Jersey: Prentice Hall, 1999. ISBN 0-13-013785-5. Mack, J. LVS-HOWTO and LVS-mini-HOWTO [online]. c2003,2004,2005,2006, [cit. 2006-05-22]. Dostupný z . Šorm, M., Netrefová, H. University Information System Cluster at Mendel University of Agriculture and Forestry in Brno. In IT Innovation in a Changing World. Proceedings of the 9th International Conference of European University Information Systems. 1. vyd. Amsterdam: UvA, 2003, s. 286–288. ISBN 90-9017079-0. Greenwald, R., Stackowiak, R. Oracle Essentials : Oracle database 10g. Beijing: O’Reilly, 2004. ISBN 0-596-00585-7.

Přílohy

A

A

FOTOGRAFIE – SERVEROVNA UIS

Fotografie – serverovna UIS

Obr. 8: UIS cluster – shora: vývojářský server, loadbalancer, UPS

34

A


Obr. 9: UIS cluster – 14 aplikačních serverů

35

A


Obr. 10: UIS cluster – první databázový server

36

A


Obr. 11: UIS cluster – druhý databázový server

37

Clusterová podpora třívrstvé architektury informačních systémů

Recommend Documents