Clustery
Jan Dušek, xdusek4@fi.muni.cz
Obsah
Clustery obecně
"A computer cluster is a group of locally connected computers that work together as a unit." -
Wikipedia.org
Terminologie
cluster - skupina počítačů většinou propojená rychlou datovou sítí (FastEthernet, Gigabit Ethernet)
uzel (node) - elementární výpočetní jednotka clusteru, jeden počítač
hlavní uzel (master node) - uzel, který stojí nad ostatními a provádí např. rozdělování úkolů;
existují typy clusterů bez hlavního uzlu
Výhody clusterů
- škálovatelnost - cluster lze rozšiřovat přidáváním dalších uzlů,
možnosti růstu obecného clusteru jsou omezeny pouze propustností sdílených komponent (hlavní uzel, propojovací síť)
- odolnost vůči výpadku (fault tolerance) - při výpadku jednoho uzlu přestane cluster tento uzel používat -
sníží se výpočetní výkon, ale cluster funguje dál (do doby výpadku
všech uzlů či do výpadku sdílené komponenty)
- vyšší výkon - paralelním zpracováním úkolu na více uzlech většinou dosáhneme vyššího výkonu
než kdyby měl úkol zpracovávat jediný server (případně zlepšíme poměr cena/výkon - standalone server
který zvládne daný úkol v požadovaném čase stojí X; skupina serveru, které zvládnou úkol distribuovaně
ve stejném čase stojí Y, přičemž Y může být výrazně nižší než X)
Nevýhody clusterů
- náročná správa
- úzká místa ve formě sdílených komponent
- clustery nemusí být vhodné pro každý typ aplikace (je nutná určitá granularita úkolů
a možnost zpracovávat je paralelně)
Load-balancing clustery
Clustery konstruované za účelem rozložení provozní zátěže na více počítačů
a tím zvýšení celkového výkonu.
Příkladem load-balancing clusteru může být třeba cluster webserverů. Na první
úrovni je rozdělující server (central switch), který přijímá požadavky od klientů
a zasílá je ke zpracování jednotlivým uzlům na druhé úrovni (viz např. IS MUNI - [9]).
Kritérium pro přidělení požadavku konkrétnímu uzlu může být například momentální
vytížení uzlu (požadavek zpracuje nejméně vytížený uzel) či geografická poloha uzlu
(požadavek zpracuje uzel, který je klientovi nejblíže).
Základní metody pro rozdělování zátěže jsou DNS Round Robin, Single-entry-point clustery a
jejich kombinace.
DNS Round Robin
Mějme www.domain.tld a tři webové servery (s třemi různými IP adresami), které
mají doménu obsluhovat.
- 3 stejné CNAME záznamy na 3 různé A záznamy - nutnost podpory ze strany DNS serveru
(jinak většinou považováno za chybu v konfiguraci, umí to např. BIND s option
multiple-cnames yes;)
srv1 IN A 10.0.0.1
srv2 IN A 10.0.0.2
srv3 IN A 10.0.0.3
www IN CNAME srv1.domain.tld.
IN CNAME srv2.domain.tld.
IN CNAME srv3.domain.tld.
- 3 stejné A záznamy na 3 různé IP adresy
www.domain.tld. 60 IN A 10.0.0.1
www.domain.tld. 60 IN A 10.0.0.2
www.domain.tld. 60 IN A 10.0.0.3
Problémy s falut-tolerance (co dělat když jeden uzel vypadne?) a s kešováním
DNS dotazů (řeší se nízkou hodnotou TTL).
Single-entry-point clustery
Hlavní uzel navenek reprezentuje cluster jako celek a tvoří tak vstupní bod, přes
který klienti transparentně přistupují ke službám clusteru.
softwarové řešení
Apache jako reverzní proxy
- jeden Apache server předřazený několika dalším webovým serverům - funguje pouze jako
reverzní proxy, tzn. přijímá požadavky a předává je webovým serverům ke zpracování,
případně kešuje odpovědi (mod_cache, mod_mem_cache)
- mod_proxy - viz [4] - přepisuje URL v obou směrech (požadavky i odpovědi)
- mod_rewrite - viz [5] - přepisuje url požadavku, sám o sobě nezohledňuje stavy jednotlivých uzlů za ním,
ale lze to ev. realizovat pomocí RewriteRule skriptu
Linux Virtual Server (LVS)
- jeden hlavní uzel přerozděluje požadavky dalším uzlům
- vysoká škálovatelnost - nástroje pro změny clusteru za běhu (přidání/odebrání uzlu)
- efektivni kombinace vysokého výkonu a vysoké dostupnosti - když už tam ty systémy jednou máme,
tak proč některé služby nenainstalovat na 2 uzly paralelně?
- IP Virtual Server (IPVS) - load-balancing na úrovni IP - každý uzel poskytuje tu samou sadu služeb
- Kernel TCP Virtual Server (KTCPVS) - application-level load balancing - je znám obsah požadavku a
lze se tak rozhodovat podle více kritérií - specializované uzly
- vše se děje v jádře - vysoká rychlost, odpadá nutnost neustále přepínat mezi user-space a jádrem
- HA démon na hlavním clusteru - monitoruje uzly, v případě výpadku uzlu změní load-balancing pravidla
- co s výpadkem hlavního uzlu? záložní hlavní uzel (přip. více uzlů) - monitoruje hlavní uzel a v případě výpadku
provede IP takeover a začne sám provádět load-balancing
- hlavní uzel udržuje stavové informace o klientech a uzlech zpracovávajících jejich požadavky -
tyto informace se při výpadku hlavního uzlu ztrácí - řešením je např. IPVS netfilter modul - IPVS syncmaster démon
zasílá (a na straně záložního hlavního serveru přijímá) UDP multicast zprávy o evidovaných spojeních; v případě
výpadku je většina stavových informací (ne všechny) dostupná v aktuální podobě na záložním hlavním uzlu
- Piranha (monitoring clusteru, heartbeating mezi hlavními servery, IPVS kernel kód)
- Keepalived (health-checking framework pro kontrolu uzlů, VRRPv2 stack pro HA hlavních uzlů)
- ldirectord (standalone démon monitorující dostupnost služeb jednotlivých uzlů - umí HTTP a HTTPS -
kontrola url, porovnání hashe výsledku)
hardwarové řešení
Cisco LocalDirector
- nad TCP/IP, 2 módy - directed / dispatch
- directed mód
- reálné IP adresy pro servery (uzly), 1 virtuální IP pro celý cluster - překlad adres
- u požadavků na virtuální IP LocalDirector změní dest.addr. na nějakou reálnou adresu
serveru, u odchozích dat změní reálnou source addr. na virtuálni adresu clusteru
- jednoduché na údržbu, rozložení zátěže je spíše statistické (bez možnosti rozkládat
zátěž podle aktuálního vytížení serverů), vyšší vytížení LD (kvůli nutnosti překladu adres
v obou směrech)
- dispatch mód
- stejná virtuální adresa je přiřazena každému reálnému serveru, překlad MAC adres
- všechny příchozí požadavky jdou na virt. adresu, LD jim pouze mění cílovou MAC adresu na adresu
nějakého serveru a posílá je dál
- odpovědi mají jakou source add. uvedenu virt. IP adresu
- překlad MAC adres je efektivnější než překlad IP adres (k překladu dochází pouze u příchozích paketů)
- více viz [2]
Kombinovaný přístup
- několik uzlů v clusteru, každý může fungovat jako vstupní bod a přeposílat
požadavky ke zpracování dalším uzlům
- stavové informace jsou dostupné všem uzlům
- např. Apache + mod_backhand (viz [3])
High Performance Computing (HPC) clustery
Clustery konstruované za účelem poskytnutí vysokého výpočetního výkonu.
SSI - Single System Image clustery
SSI je vlastnost systému, která před uživatelem skrývá distribuovanost a heterogennost dostupných prostředků
a pro uživatele vytváří iluzi jednoho jednotného systému. Uživatel tak u SSI clusteru víceméně neví o struktuře
clusteru, počtu a parametrech uzlů a vidí pouze cluster jako celek, jako jeden systém a také tak k němu
přistupuje.
- žádný hlavní uzel, distribuované prostředí
- uživatelé nevidí jednotlivé uzly
- netřeba měnit aplikace aby mohly využít potenciál clusteru
- automatický load-balancing, snadná správa
- openMosix, openSSI
openMosix
- dynamická migrace procesů - migruje pouze zásobník, registry a instruction pointer procesu
- stránkování na žádost - z domovského uzlu na uzel, který provádí zpracování procesu,
jsou přenášeny stránky pouze dojde-li k jejich výpadku
- memory ushering - migrace procesů z uzlů s nedostatkem volné paměti, aby se předešlo stránkování
- parallel file I/O - pokud proces provádí intenzivní I/O operace, je snaha přemigrovat ho na
uzel který vlastní data se kterými proces pracuje - I/O operace se pak provádějí lokálně a tedy mnohem rychleji
- vše v jádře, žádné externí knihovny
- transparentnost vůči uživateli a aplikacím
- stable zatím pouze pro jádra 2.4, 2.6 v CVS
- možno použít v kombinaci s OpenAFS
- procesy využívající sdílenou paměť nikdy nemigrují (to způsobuje problémy u spousty poměrně rozšířených aplikací: MySQL, Apache, Postgres, Javovské aplikace
využívající vlákna, ...)
Beowulf
Dnes už se takto označuje celá třída clusterů (Beowulf-class clusters). Beowulf cluster ("true Beowulf")
je cluster splňující násl.podmínky (definice převzata z [10]):
- uzly jsou vyčleněny pouze pro práci v Beowulf clusteru a pro nic jiného
- stejně tak propojující síť je vyhrazena jen pro Beowulf
- jednotlivé uzly jsou běžně dostupné komerční počítače (COTS - Commercial off-the-shelf) - tím se Beowulfy
odlišují od různých specializovaných řešení
- stejně tak síťová infrastruktura je COTS
- na všech uzlech běží open-source software (OS je většinou GNU/Linux - při paralelních výpočtech se totiž
často objevují problémy na úrovni jádra a TCP stacku a dostupnost zdrojových kódů velmi usnadňuje jejich
řešení)
- výsledný cluster je použit pro HPC
Beowulf cluster má většinou jeden hlavní uzel zde nazývaný "head/master node". Ten je většinou vybaven periferiemi
a slouží mj. k propojení vnitřní sítě clusteru s okolím. Často také plní funkci file serveru pro sdílená data
clusteru. Všechny uzly v clusteru jsou většinou identické (stejné CPU, paměť, chipset, ... - kvůli zjednodušení
predikce délky trvání daného výpočtu) a každý vždy v daný časový okamžik zpracovává nejvýše jeden výpočet
(calculation).
Beowulf clustery se používají pro specializované výpočty (nezřídka se celý cluster navrhuje přesně na míru
úkolu který bude vykonávat) a je nutné pro ně psát specializované aplikace. Zde je výrazný rozdíl oproti např.
openMosixu, kde vezmeme běžný "serial" program, který se např. rád forkuje do 10 procesů, koupíme 10 uzlů
a program poběží 10x ;-) rychleji.
High-Availability (HA) clustery
Clustery konstruované za účelem zvýšení dostupnosti služeb.
Existuje více uzlů schopných poskytovat danou službu. Za normálního stavu poskytuje službu pouze jeden
určitý uzel a v případě jeho výpadku přebírá poskytování služby některý z dalších uzlů.
IP takeover - aby bylo pro uživatele vše transparentní, je potřeba aby záložní uzel převzal IP adresu
původního uzlu. V extrémních případech možno rozšířit i na MAC takeover.
U stavových protokolů/služeb je potřeba synchronizovat stav na záložní uzly.
Heartbeat
2 uzly, sada služeb asociovaná s každým uzlem
Heartbeat démon prvního uzlu zjišťuje v daných intervalech stav druhého uzlu. Pokud druhý uzel ve stanovené době
na dotaz neodpoví (nebo pokud sám vyšle zprávu o změně svého stavu - např. při shutdownu), nastartuje první uzel
služby, které poskytoval druhý uzel a následně převezme jeho IP adresu. Toto celé platí i obráceně pro druhý uzel.
Doba výpadku pak odpovídá součtu doby nutné ke zjištění výpadku druhého uzlu (max. interval heartbeatů + timeout
pro odpověď) a doby nutné k nastartování potřebných služeb. Řádově jde o jednotky sekund až minut (v závislosti na
konfiguraci a množství a nárocích přebíraných služeb).
Konfigurace:
Na oba stroje nainstalujte heartbeat obvyklým způsobem.
/etc/ha.d/ha.cf
# interval mezi heartbeaty [s]
keepalive 1
# timeout na odpověď - pokdu druhý uzel neodpoví do této doby, je prohlášen za nefunkční a začne přebírání
deadtime 20
# co dělat po znovunastartování vypadlého uzlu?
# on - převzaté služby se vrací zpět na "domovský" uzel
# off - převzaté služby se nevrací, zůstanou na uzlu, který je převzal
# legacy - povolí vracení v systémech, které ještě plně nepodporují auto_failback
# (v předchozích verzích se tato direktiva jmenovala nice_failback a měla přesně opačnou sémantiku)
auto_failback on
# jak a kam se mají posílat heartbeaty?
# serial /dev/ttyS0
# bcast eth0
# pro stroj-beta:
ucast eth0 10.0.X.1
# jména uzlů - musí odpovídat 'uname -n'
stroj-alpha
stroj-beta
/etc/ha.d/haresources
# zde jsou definovány služby které v klidovém stavu poběží na každém uzlu
# čtyřtečka odděluje parametry předané startovacímu skriptu
# start.skripty se hledají v /etc/ha.d/resource.d/ a v /etc/init.d/
# pro jednoduchost je dobré mít obsah tohoto souboru stejný na obou uzlech
stroj-alpha IPaddr::10.0.X.2/24 apache
stroj-beta
/etc/ha.d/authkeys
# vzájemná autentizace obou démonů
auth 2
# 1 crc
2 sha1 retezec_pro_hashovaci_funkci_stejny_na_obou_uzlech
# 3 MD5 Hello!
Použitá literatura
[1] Round Robin DNS Load Balancing
[2] Cisco Local Director Abstract
[3] mod_backhand presentation
[4] Reverse Proxying With Apache 2.0
[5] Apache 1.3 URL Rewriting Guide
[6] High-Availability Linux Project
[7] root.cz - High Availability a Linux
[8] openMosix Cluster on Gentoo
[9] Technické vybavení Informačního systému Masarykovy univerzity v Brně
[10] Robert G. Brown, Engineering a Beowulf-style Compute Cluster