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ů

Nevýhody clusterů


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.

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

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

  1. softwarové řešení

    Apache jako reverzní proxy

    Linux Virtual Server (LVS)

  2. hardwarové řešení

    Cisco LocalDirector

Kombinovaný přístup


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.

openMosix

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]):

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