Abstrakt: Prúdové spracovanie vel'kých dát v distribuovanom prostredí prináša radu rôznych výziev. Jednou z nich je dosiahnutie vysokej dostupnosti (high availability), cˇo predstavuje zabezpecˇenie odolnosti distribuovaného výpocˇtu proti výpadku uzlov z dôvodu hardvérovej, cˇi softvérovej chyby, alebo výpadku spojenia medzi uzlami. Výpadky sú problematické, pretože ich následkom dochádza k narušeniu výpocˇtu - strate cˇasti medzivýsledkov a strate stavu havarovaného uzlu. To je vo väcˇšine prípadov neakceptovatel'né a je nutné za cˇat' spracovanie od za cˇiatku, cˇo predlžuje výslednú dobu spracovania a spotrebováva hardvérové prostriedky. V tomto cˇlánku zhrnieme súcˇasný stav poznania v oblasti dosiahnutia vysokej spol'ahlivosti pri prúdovom spracovaní dát a navrhneme spôsob rozšírenia systému D-Bobox o podporu vysokej dostupnosti. V poslednom cˇase je venovaná vel'ká pozornost' novej triede aplikácií - systémom pre spracovanie prúdových dát (stream processing systems - SPS) [ 1, 2, 3], ktoré musia spracovávat' obrovské objemy neustále prúdiacich dát s nízkou latenciou. Medzi takéto systémy môžeme zaradit' napr. spracovanie financˇných dát v reálnom cˇase, monitorovanie pacientov pomocou rôznych senzorov, sledovanie a vyhodnocovanie stavu dopravy atd'. Prúdové spracovanie sa ukazuje ako efektívny nástroj nielen pre spracovanie priebežne generovaných dát, ale aj vel'kých statických dát, ako napríklad sémantické databázy [4]. Zdroje dát SPS systémov a spracovanie jednotlivých prúdov dát môžu byt' distribuované, cˇo poskytuje priestor na škálovanie ich výkonu. Takéto systémy nazveme distribuované SPS - DSPS. Typickým postupom zvýšenia výkonu v distribuovanom systéme prúdového spracovania dát je pridanie d'alších serverov. To avšak zvyšuje riziko výpadku, ktorý negatívne ovplyvnˇuje výkon a spol'ahlivost' celého distribuovaného systému, pretože mnoho systémov požaduje presné (databáze) a pravidelné výsledky (vyhodnocovanie financˇných operácií, sledovanie pacientov). V efektívnom systéme sa preto stáva nevyhnutná prítomnost' komponenty pre vysokú dostupnost' (high availability - HA), ktorá umož nˇuje rýchle a korektné obnovenie a má minimálny dopad na bezvýpadkové spracovanie. K dosiahnutiu HA v distribuovaných systémoch prúdového spracovania dát je nutné poskytnút' sadu algoritmov, ktoré vykonávajú nasledujúce úlohy:
1. periodická a inkrementálna záloha (alebo replikácia) stavu uzlov, na ktorých prebieha výpocˇet
V tejto práci najprv v kapitole 2 definujeme typy
zotavenia podl’a [
Základná požiadavka kladená na algoritmy zotavenia je
schopnost’ maskovat’ výpadky z pohl’adu dát te cˇúcich
havarovaným uzlom. Majme uzol U, ktorý má množinu
obsahujúcu n vstupných prúdov dát (I1, .., In) a produkuje
výstupný prúd O. Výpocˇet e je postupnost’ udalostí ako
prijatie, spracovanie alebo vyprodukovanie n-tice dát.
Výsledkom výpocˇtu e na uzle U je prúd dát Oe. Typy
zotavenia [
Rollback recovery zarucˇuje, že výpadok nespôsobí stratu informácie. Podl’a typu dotknutých operátorov delíme rollback recovery d’alej na: • opakujúci pokial’ sa pri obnove opakovane generujú n-tice, ktoré sú zhodné s pôvodne odoslanými. • konvergujúci ak sú opakovane generované n-tice (z rovnakých dát), avšak tieto nie sú zhodné s pôvodnými, ale postupom cˇasu skonvergujú k n-ticiam behu bez výpadku. • divergujúci pokial’ sa n-tice generované po zotavení nikdy neskonvergujú k n-ticiam ktoré by boli generované pocˇas behu bez výpadku. Tento prípad typicky nastáva u nedeterministických operátorov. Precise recovery poskytuje najsilnejší spôsob zotavenia. Kompletne maskuje výpadok a zarucˇuje že výstup je rovnaký ako v prípade bezchybného behu. 2.1
Podl’a vplyvu na sémantiku obnovenia rozlišujeme štyri typy operátorov: obecný, deterministický, konvergujúci a opakovatel’ný . Typ plánu spracovania urcˇuje najobecnejší operátor, ktorý sa v nˇom vyskytuje.
Operátor nazveme deterministický ak produkuje rovnaký výstup stále, ked’ sa za cˇne výpocˇet v rovnakom stave a na rovnakej postupnosti vstupných dát na každom zo vstupov. Zdrojom nedeterminizmu môže byt’ napríklad závislost’ na cˇase, poradí príchodu dát medzi jednotlivými vstupmi, alebo použití nedeterministického spracovania (napríklad použitie náhodných veli cˇín).
Deterministický operátor je konvergentný pokial’ je schopný po reštarte schopný konvergentného zotavenia, ak obnovu zacˇína z prázdneho stavu a za pomoci opakovaného spracovania vstupných dát od urcˇitého bodu v cˇase.
Konvergentný operátor je opakovatel’ný ak je schopný po reštarte schopný opakovatel’ného zotavenia, ak obnovu zacˇína z prázdneho stavu a za pomoci opakovaného spracovania vstupných dát od urcˇitého bodu v cˇase. 3
Metódy HA Medzi základné prístupy dosiahnutia spol’ahlivosti spracovania v distribuovaných systémoch patria procesné páry (process-pairs) , logovanie a checkpointing. V nasledujúcich podkapitolách predstavíme základné algoritmy založené na týchto postupoch. Aj ked’ v základných variantoch nedosahujú všetky uvedené postupy precíznej obnovy, je možné ich na takúto úrove nˇ rozšírit’. Jedná sa hlavne o ošetrenie duplicitných stavov a zarucˇenie, že nedôjde k strate správ. Zabezpecˇenie proti strate riešia všetky metódy logovaním správ vo výstupných frontách dovtedy, kým nie je zarucˇené, že správa bola uložená alebo spracovaná. V prípade výpadku sa znovu posielajú takto zalogované správy. Ošetrenie duplicitných správ sa rôzni a preto je spomenuté podrobnejšie pri jednotlivých metódach.
Metóda passive standby [
Výhodou tohto prístupu je krátky cˇas potrebný na obnovenie výpocˇtu, ktorý zodpovedá opakovanému spracovaniu správ prijatých od posledného checkpointu, avšak za cenu spomalenia riadneho behu bez výpadkov z dôvodu vycˇlenenia (minimálne) polovice uzlov ako záložných a zvýšenej komunikácie primárnych ulov so záložnými. Dˇalšie zdržanie výpo cˇtu nastáva pri synchrónnom zálohovaní (primárny uzol neodosiela dáta dovtedy, kým nie sú uložene aj na záložnom uzle). Pri asynchrónnom zálohovaní naproti tomu hrozí strata dát a nekonzistentný stav ak nie je použitá dopl nˇujúca metóda na prevenciu straty dát. 3.2
Active standby je d’alším variantom process-pairs [
Výhodou active standby oproti passive variante je minimálny potrebný cˇas na obnovenie, pretože záložný uzol dostáva rovnaké správy, ktoré paralelne spracováva. To má avšak za následok nárast komunikácie o 100% . Dˇalšiu extra komunikáciu znamená potvrdzovanie prijatých správ, slúžiacich pre orezanie výstupných zásobníkov a v prípade nedeterministických operátorov posielanie rozhodovacích záznamov. 3.3
Klasické process pair prístupy majú vel’ký runtime
overhead (je nutné vycˇlenit’ aspo nˇ polovicu uzlov ako záložné
uzly) a vyžadujú nezanedbatel’né navýšenie komunikácie.
Upstream backup [
Hlavným problémom tohto prístupu je narastajúca vel’kost’ výstupných front, ktoré slúžia ako zálohy. Pre ich zmenšenie je definovaný ich orezávací protokol (queue trimming protocol), ktorý popisuje kedy môžu byt’ n-tice z jednotlivých výstupných front odstránené. Ciel’om je dosiahnut’ minimálnu množinu, ktorá bude dosta cˇujúca pre obnovenie stavu havarovaného uzlu. Orezávací protokol je založený na potvrdzovaní doru cˇenia, resp. spracovania ntic. Informácie o prijatí sú šírené spätne pomocou potvrdzovacích správ, pricˇom existuje niekol’ko úrovní týchto správ. Základná nultá úrovenˇ oznamuje, že daná n-tica bola prijatá príjemcom. Uzol, ktorý prijme potvrdenie nultej úrovne, spätne vyráta ktoré vstupné n-tice sa podiel’ali na vytvorení potvrdenej n-tice a pošle potvrdenie prvej úrovne. Uzol ktorý prijme potvrdenie prvej úrovne pre konkrétnu n-ticu od všetkých uzlov, kam bola odoslaná, môže následne odstránit’ túto a všetky logicky predchádzajúce n-tice. Pokial’ sa požaduje vyšší stupe nˇ zabezpecˇenia, iteratívne sa zvyšuje úrovenˇ potvrdenia a orezávanie prebieha pri prijatí najvyššej požadovanej úrovne.
Výhodou tohto prístupu je zmenšenie nadmerného využívania prenosového pásma, ked’že navyše používa iba potvrdzovacie správy, ktoré sú menšie než správy dátové a k extra prenosu dát dochádza len pri zasielaní n-tic po výpadku. Nevýhodou je neúmerne dlhšia doba potrebná na zotavenie, ked’že nový uzol musí znovu spracovat’ dostatok n-tic pre obnovenie svojho vnútorného stavu a náro cˇnost’ výpo cˇtu potvrdení vyšších úrovní. 3.4
Cooperative passive standby [
Plán(y) spracovania každého uzlu sú rozdelené do viacerých nezávislých HA jednotiek. Tieto sú následne rozdistribuované a vybalansované medzi viacerými servermi. Toto rozdelenie umož nˇuje rozložit’ zát’až zálohy jedného uzlu medzi skupinu uzlov a týmto docielit’ rýchlejšiu obnovu v prípade výpadku.
Zálohovanie prebieha po jednotlivých HA jednotkách na danom uzle, cˇo redukuje d´lžku blokovania výpo cˇtu spôsobené zálohovaním HA jednotky. Jemnejšia granularita záloh umož nˇuje využit’ vol’né cykly CPU daného uzlu, ked’ práve neprebieha výpo cˇet (napr. z dôvodu cˇakania na dáta) a týmto optimalizovat’ celkový výkon. Samotná záloha prebieha v dvoch krokoch: capture a paste. Pocˇas fázy capture dôjde na uzle k výberu HA jednotky, ktorá sa bude zálohovat’ a odoslaniu správy na záložný uzol s aktualizáciou stavu danej HA jednotky. Paste fáza prebieha na záložnom uzle, ktorý spracúva doru cˇené zálohovacie správy tak, že aktualizuje zodpovedajúci obraz checkpointu aplikovaním rozdielových informácii. Po ukoncˇení fázy paste je upovedomený odosielatel’ a môže dôjst’ k d’alšiemu kolu zálohy tejto HA jednotky.
Po výpadku uzlu preberú jeho úlohu uzly obsahujúce zálohy jeho jednotlivých HA jednotiek. Pocˇas obnovy dôjde k operácii paste a spracovaniu nespracovaných aktualizácii, pokial’ také sú. Dˇalej sú prepojeé vstupy z havarovaného uzla na záložné a spracované správy z výstupných front, ktoré boli odoslané havarovanému uzlu ale neobsahuje ich záloha. Rozdelenie úlohy havarovaného uzlu medzi viacero záložných znamená, že o cˇakávaný nárast zát’aže týchto záložných uzlov bude malý a oneskorenie výpocˇtu bude pod kontrolou.
Ak dôjde k obnoveniu havarovaného uzlu, tento je pripojený ako nový prázdny uzol a v rámci automatického vyvažovania zát’aže môže byt’ na neho prevedená cˇast’ úloh. Vytváranie jednotlivých HA jednotiek a ich rozdelenie na záložne servery môže prebiehat’ automaticky, bez nutnosti pevnej konfigurácie, cˇo umož nˇuje dynamické prispôsobenie sa aktuálnej situácii a rozloženiu zát’aže. 4
Bobox [
D-Bobox [ 10] je d’alším evolu cˇným krokom systému Bobox, ked’ k zvýšeniu efektivity spracovania vel’kých dát už neposta cˇuje lokálny paralelizmus a je nutné expandovat’ do distribuovaného prostredia. Zárove nˇ je snaha zachovat’ širokú použitel’nost’ takto rozšíreného systému a preto je budovaný s ohl’adom na efektívnu použitel’nost’ aj na bežne dostupnom hardvéri a nielen na špecializovaných výpocˇtových clustroch.
Základná schéma D-Boboxu je znázornená na obrázku 1. Uzly sú rozdelené na jeden hlavný - master uzol, ktorý prijíma požiadavku na úlohu, vytvára plán jej spracovania (frontend cˇast’), inicializuje podriadené - slave jednotky na spracovanie a (typicky) je aj ciel’om výsledkov spracovania. Podriadené uzly obsahujú štandardný backend z Boboxu a sú rozšírené o potrebnú distribucˇnú loObr. 2: Ukážka rozšírenia exeku cˇného plánu do distribuovaného prostredia pomocou hranicˇných krabicˇiek. a) Bobox plán pre výpocˇet na jednom uzle. b) Plán D-Boboxu, rozšírený o hrani cˇné krabicˇky (Boundary Box), ktoré zaist’ujú vzdialenú komunikáciu (prerušovane). giku. Vzdialená komunikácia je riešená pridaním špecializovaných hranicˇných krabicˇiek, ktoré sú do výsledného plánu pridávané za behu, tesne pred inicializovaním pracovných uzlov. Pridáva a konfiguruje ich distribucˇná riadiaca jednotka na primárnom uzle podl’a aktuálnej dostupnosti uzlov zúcˇastnˇujúcich sa výpocˇtu. Príklad takéhoto rozšírenia exekucˇného plánu ilustruje obrázok 2. 5
Každý z HA algoritmov spomenutých v predchádzajúcej kapitole je nasaditelný v systéme D-Bobox, avšak kladie rôzne požiadavky na samotný systém a poskytuje rôznu úrovenˇ transparentnosti z pohl’adu tvorby nových operátorov (krabicˇiek v systéme Bobox). V nasledujúcej diskusii neberieme do úvahy nedeterministické plány, ktoré pre všetky algoritmy vynucujú zo strany krabicˇiek podporu logovania nedeterministických rozhodnutí a tieto vhodným spôsobom reportovat’, cˇo znižuje požadovanú transparentnost’.
Upstream backup predstavuje najmenej blokujúci prístup a vyžaduje najmenšiu extra komunikáciu po cˇas behu bez výpadkov, avšak jeho nároky na ukladanie výstupných front môžu byt’ neúnosne vel’ké a cena obnovy uzlu v prípade výpadku je vel’ká z pohl’adu cˇasu aj potrebného výpocˇtového výkonu. Navyše predstavuje najmenej transparentný prístup, pretože jednotlivé operátory musia implementovat’ cˇasto netriviálne mapovania medzi výstupnými a vstupnými n-ticami, ktoré je potrené pre korektné fungovanie potvrdzovania a orezávacieho algoritmu na výstupné fronty. Preto je nevhodný pre Bobox, ktorý sa snaží maximálne skryt’ paraleliza cˇnú a distribucˇnú logiku z krabicˇiek za úcˇelom ich jednoduchého vývoja.
Active standby je naproti tomu maximálne transparentný a takéto spracovanie môže byt’ dokonca zachytené upraveným plánom spracovania, kde budú jednotlivé cˇasti spracovania zduplikované a výstupy paralelných vetiev budú smerované na špeciálnu systémovú krabicˇku, ktorá zabezpecˇí opätovné poslanie dát tak, aby po výpadku nedošlo k strate dát (ak výpocˇet v primárnej vetve zaostával za záložnou) a ani k produkcii duplicitných n-tic (ak výpocˇet v záložnej vetve zaostával za primárnou vetvou). Úlohou riadiacej cˇasti HA je v prípade výpadku nájst’ náhradný uzol za havarovaný, ktorý preberie úlohu záložného uzlu, zreplikovat’ na neho stav zo záložnej vetvy (po výpadku sa z nej stáva vetva primárna) a vhodne presmerovat’ komunika cˇné kanály. Tento HA algoritmus môže slúžit’ pre úlohy preferujúce minimálny cˇas zotavenia pred výkonom, pretože je nutné obetovat’ polovicu uzlov ako uzly záložné. Rovnaká nevýhoda platí pre passive standby algoritmus, ktorý navyše nedosahuje podobne rýchle obnovenia, z dôvodu opätovného spracovania správ ktoré nezachytil posledný checkpoint a spomalenia výpocˇtu pocˇas vykonávania zálohy. Z tohto dôvodu nie je táto možnost’ uvažovaná pre Bobox.
Kooperatívny variant passive standby patrí takisto medzi transparentné metódy a jeho výhodou je rozumne malý vplyv na bezporuchový beh a rýchlost’ zotavenia z výpadku. Preto poslúži ako základ pre integráciu HA v systéme D-Bobox.
Podpora HA je z pohl’adu umiestnenia rozdelená na dva cˇasti: lokálnu, umiestnenú na jednotlivých pracovných uzloch a globálnu, nachadzajúcu sa na primárnom uzle. Obe cˇasti sú reprezentované zodpovedajúcim managerom a riešia odlišné úlohy: lokálny manager rieši správu HA v kontexte jedného uzlu a globálny riadi HA na úrovni celého systému.
manager. Jeho zameraním je riešenie globálnych úloh ohl’adne poskytnutia spol’ahlivosti a efektívneho výpo cˇtu: riešenie výpadkov, rozvrhovanie záloh a spolupráca s vyvažovaním zát’aže.
V prípade výpadku je nutné informovat’ uzly držiace zálohy jednotlivých HA jednotiek havarovaného uzlu, aby vykonali paste operáciu dorucˇených aktualizácií, ak tak ešte nevykonali a prebrali výpocˇet havarovaných jednotiek. Pre pokracˇovanie výpocˇtu je ešte nutné presmerovat’ posielanie správ na záložné uzly a informovat’ upstream uzly, aby odoslali uložené správy zo svojich výstupných front pre obnovenie stavu výpocˇtu, ktorý nestihol byt’ zachytený posledným checkpointom.
Vzhl’adom na snahu o rozdelenie úlohy jedného uzlu na viac nezávislých HA jednotiek, ktoré sú distribuované na rôzne fyzické uzly, môžeme o cˇakávat’, že nárast zát’aže týchto uzlov po tom ako preberú úlohu havarovaného uzlu bude v akceptovatel’ných medziach. Po obnovení havarovaného uzlu je tento pripojený k výpocˇtu a môžu byt’ na neho dynamicky preplánované úlohy a zálohy, typicky z uzlov ktoré sú najviac vyt’ažené (avšak je možné nasadit’ rôzne stratégie zahr´nˇajúce napríklad lokalitu, cenu atd’.). Hlavným dôvodom, precˇo by sa HA manager mal snažit’ o vyrovnávanie zát’aže, je snaha dosiahnut’ rozumne malé a cˇasté zálohy všetkých uzlov. Pri nerovnomernej zát’aži nevyt’ažené uzly produkujú zálohy cˇastejšie cˇím pridávajú úlohy vyt’aženým uzlom. Tieto naopak, aby nezdržovali výpocˇet redukujú interval svojich záloh a zálohy vykonávané po dlhšom cˇase bývajú obecne drahšie a obnovenia pomalšie, pretože došlo k vä cˇším zmenám stavu, ktoré je treba pokryt’. Snaha o dynamické vyrovnanie zát’aže znižuje cenu checkpointov, ked’že tieto sú menšie a tak sa s väcˇšou pravdepodobnost’ou vojdú do vol’ných cyklov CPU a sú cˇastejšie cˇo skracuje cˇas obnovy, ked’že je nutné znovu spracovat’ menší po cˇet n-tic pre obnovenie stavu. Vyrovnávanie zát’aže dociel’uje HA manager dvoma spôsobmi: vhodným rozvrhovaním zálohovacích párov a spoluprácou s riadiacou distribucˇnou jednotkou, ktorá riadi vyvažovanie pomocou migrácie úloh.
Má za úlohu riešit’ HA úlohy spojené s konkrétnym uzlom medzi ktoré patrí: sledovanie dostupnosti susedov (upstream a downstream uzlov), správa HA jednotiek (delenie, zlucˇovanie) a plánovanie a vykonávanie operácií capture a paste.
Každý uzol sleduje dostupnost’ susedných uzlov s ktorými komunikuje. Pokial’ s nejakým susedným uzlom práve neprebieha komunikácia (netecˇú dáta), tak testuje jeho dostupnost’ pomocou dotazov v pravidelných intervaloch. Ak nejaký uzol prestane reagovat’, je po niekol’kých pokusoch (podl’a nastavenej tolerancie) prehlásený za havarovaný a jeho výpadok je oznámený globálnemu HA managerovi, ktorý sa ujme riadenia nápravy tohto výpadku.
Pocˇas behu bez výpadkov sú vykonávané operácie capture a paste. Capture má za úlohu zachytit’ zmenu stavu konkrétnej HA jednotky a jej odoslanie na záložný server. Operácia paste ma za úlohu aktualizovat’ obrazy záloh pomocou dorucˇených správ. Jednotlivé HA jednotky sú zálohované pomocou operácie capture nezávisle na sebe, zatial’ cˇo pocˇas operácie paste sa zálohy aktualizujú postupne podl’a poradia prijatých správ dovtedy, kým sú nejaké nespracované aktualizacˇné správy, alebo pokial’ nedôjde k preplánovaniu. Plánovanie operácií capture a paste má na starosti lokálny plánovacˇ. Tento môže implementovat’ rôzne stratégie za ú cˇelom rozumne zálohovat’, alebo minimalizovat’ blokovanie výpo cˇtu.
Pre úpravu granularity checkpointingu umožnuje lokálny HA manager delenie, resp. zlucˇovanie HA jednotiek. Delenie je možné v prípade, ak uzol pracuje s viacerými krabicˇkami (nie nutne priamo prepojenými). Zjemnením granularity, hlavne u plánov obsahujúcich viacero netriviálnych operácií, dôjde k rozdeleniu zát’aže zálohy a obnovenia na viacero záložných serverov. Naopak zlúcˇenie je vhodné pokial’ sa na uzle ocitne niekol’ko za sebou idúcich výpocˇtovo jednoduchých krabicˇiek, ktorých spojené vykonávanie nepredstavuje výrazný nárast zát’aže (skôr dôjde k rýchlejšiemu spracovaniu vd’aka lokalite vykonávania) a zmenši pocˇet HA jednotiek, ktoré je potrebné plánovat’. Tieto zmeny granularity sa musia vykonávat’ v spolupráci s globálnym HA managerom, ktorý musí novým HA jednotkám priradit’ uzly, kam sa budú zálohovat’ a naopak zabezpecˇit’ odstránenie záloh zrušených HA jednotiek.
HA na hranicˇných krabicˇkách musí pre garanciu precíznej obnovy podporovat’ logovanie výstupných správ a elimináciu duplicitných správ. Odchádzajúce správy sa logujú do doby, než je potvrdená ich záloha v HA jednotkách ktorým boli odoslané. Toto je nutné pre obnovenie stavu výpocˇtu po obnove z posledného checkpointu pomocou ich opakovaného spracovania. Vstupné hranicˇné krabicˇky musia taktiež pomocou identifikátorov správ filtrovat’ správy duplicitné, ktoré mohli pri opakovanom spracovaní vzniknút’ (havarovaný uzol mohol a nemusel vyprodukovat’ pôvodné správy pred svojím pádom).
Integrovanie spomenutých cˇastí poskytne základnú podporu vysokej dostupnosti v systéme D-Bobox. Táto môže byt’ následne rozširená o podporu nedeterministických operátorov za pomoci logovania ich rozhodnutí, alebo napríklad vylepšovaná pridaním rôznych stratégií pri plánovaní záloh, cˇi vyvažovaní zát’aže. 6
Záver V tomto cˇlánku sme prezentovali problém výpadku uzlu v distribuovaných systémoch prúdového spracovania dát, definovali typy obnovenia a prezentovali súcˇasné základné prístupy k dosiahnutiu vysokej dostupnosti týchto systémov. Následne sme rozobrali vhodnost’ jednotlivých prístupov pre systém D-Bobox a zvolili jeden z prístupov ako základný kame nˇ, na ktorom bude zavedená podpora vysokej dostupnosti v D-Boboxe a na cˇrtli možnosti jej integrácie do jednotlivých cˇasti D-Boboxu. 7