Zajištění dostupnosti a rozložení zátěže u řídicích systémů

Zajištění dostupnosti a rozložení zátěže u řídicích systémů

Článek srovnává technické prostředky pro zajištění maximální dostupnosti a spolehlivosti řídicích systémů a optimalizaci zátěže. Zabývá se technickými a programovými prostředky pro zajištění nepřetržité dostupnosti řídicích počítačů (24 hodin denně, sedm dní v týdnu) a vysvětluje rizika a obranu proti útokům typu DoS. Na tento příspěvek volně navazuje článek Použití inteligentních agentů pro zajištění dostupnosti a rozložení zátěže u řídicích systémů, ve kterém je ukázán příklad softwarového řešení dostupnosti řídicích počítačů v praxi.

1. Úvod

Skutečnost, že zejména u řídicích systémů bývá požadavek na dostupnost systému do značné míry v protikladu k požadavku na jeho spolehlivost, je dostatečně známa. Důvodem toho je, že systém, který má být spolehlivý, musí vykonávat množství redundantních kontrol a vnitřních testů; tím se podstatně zvyšuje pravděpodobnost, že bude objevena (skutečná nebo domnělá) chyba. Při detekci jakékoliv poruchy je někdy přirozenější a logičtější systém odstavit, přinejmenším do odstranění závady, než vědomě provozovat vadný systém. Naproti tomu požadavek na dostupnost je právě opačný: mnohdy je lépe provozovat vadný systém, který dává aspoň nějaké výsledky, byť vlivem chyb nespolehlivé, než systém odstavit a nemít výsledky žádné (i když zcela spolehlivě).

K této dvojici pohledů v poslední době ještě přistupuje pohled třetí, a to hledisko zátěže. Nečekaně velká zátěž může někdy působit jak proti spolehlivosti, tak i proti dostupnosti. Příkladem mohou být různé druhy útoků DoS (denial of service) na internetové servery. Problém a jeho řešení si ukážeme na příkladu, který vznikl v rámci řešení tzv. pultu centralizované ochrany (PCO) v bezpečnostní agentuře.

2. Problém dostupnosti

V mnoha situacích vystupuje požadavek na nepřerušenou dostupnost služeb zvlášť významně. Například bezpečnostní ústředny objektů, stacionárních i mobilních, jsou pomocí vhodných komunikačních kanálů svedeny do jediného bodu, tzv. pultu centralizované ochrany (PCO). Zde je trvalá obsluha, jež je schopna zajistit adekvátní reakci na nahlášené stavy objektů. Kdyby např. pro výpadek počítače nebyl včas vyhlášen požární poplach, mělo by to fatální následky nejen pro střežený objekt, ale i pro bezpečnostní agenturu samou (bezpečnostní agentury sice jsou pojištěny na ohromné částky, ale i jejich spoluúčast na pojistném plnění bývá obrovská, řádově až stovky milionů korun).

3. Problém DoS

Na příkladu PCO je rovněž zřejmé riziko nedostatečného rozložení zátěže. Asi není úplná náhoda, že mnohé útoky na střežené objekty byly vedeny právě v okamžiku, kdy signalizační zařízení „nevysvětlitelnou souhrou okolností“ právě mělo poruchu. Odtud už je jen krůček k úvaze, že by nepochybně bylo možné výskyt takové poruchy signalizace nejen sledovat, ale i přímo navodit. Vhodným způsobem by mohl být vyvolán současný výskyt velkého množství falešných poplachů, které by PCO zcela zahltily a učinily neprůchodným na delší dobu. To je princip útoku DoS.

4. Zálohování

Problém spolehlivosti, dostupnosti i rozložení zátěže se v současnosti nejčastěji řeší zálohováním. Ponechme stranou, že i „studená“ záloha může mít své opodstatnění: záložní server, který je zamčený ve skříni a není nikam připojen, je bezpečný proti přepětí v síti i proti úderu blesku – což nelze říci o žádné „horké“ záloze připojené k napájení a modemu. Při požadavku, aby se doba nedostupnosti omezila na minimum, patrně nebude možné uvažovat o jiné než o „horké“ záloze, tzn. o počítači, který bude trvale v chodu. Jsou zde dvě možnosti: pasivní horká záloha a aktivní horká záloha.

Pro pasivní zálohu je charakteristické, že oba počítače nejsou rovnocenné. Primární server A vykonává aplikační program, má tedy přístup ke všem potřebným zdrojům. Záložní server B nezpracovává aplikaci, ale periodicky kontroluje správnou činnost serveru A. Přitom nesmí rušit práci serveru A, proto může mít omezený přístup k některým zdrojům, a je tedy v jistém smyslu podřízen primárnímu serveru. Zjistí-li závadu serveru A, okamžitě se začne v síti propagovat jako primární server, čímž převezme jeho funkci. Je otázkou vhodné strategie, zda po obnovení funkce serveru A zůstane server B ve funkci primárního a server A ve funkci záložního serveru, nebo zda se oba servery vrátí k původnímu stavu.

Technické řešení obvykle obsahuje přesměrovač (redirector), který podle zvolené strategie směruje definovanou službu na server A nebo na server B. Bohužel, často se technické řešení nesprávně omezuje na to, jak přesměrovat požadavky na službu, např. požadavky přicházející po síti nebo z internetu. Později ukážeme, v čem je nedostatečnost takového přístupu a jak ji lze řešit.

U pasivní zálohy je nevýhodou skutečnost, že se záložní server nepodílí na poskytování služeb aplikace, přestože je v chodu, plně připojen (a opotřebovává se), a tudíž nezvyšuje výkon aplikace. Tuto nevýhodu odstraňuje uspořádání, při kterém redirector směruje požadavky na některý ze serverů dynamicky, podle jejich okamžitého zatížení. Uvedenému uspořádání se říká aktivní záloha neboli rozkládání zátěže. Pro prvek, který realizuje směrování, se vžilo označení LBS (Load Balancing Server). Každý nově příchozí požadavek je směrován na server, který je podle zvoleného algoritmu na řadě. Znamená to, že oba servery A i B jsou zcela rovnocenné, jeden není žádným způsobem nadřazen druhému.

Z vnějšího pohledu, např. z hlediska připojeného uživatele, není možné rozlišit, že jde o několik serverů. Většinou také není možné predikovat, na kterém stroji požadavek uživatele poběží. Proto se o celku hovoří jako o virtuálním serveru neboli o clusteru (obr. 1). Počet fyzických serverů může být větší než dva; v takovém případě se hovoří o serverové farmě.

5. Strategie rozložení zátěže

Strategií pro rozložení zátěže může být velký počet a mohou brát v úvahu např. počet spojení, počet klientů, zatížení serveru, cyklické směrování apod. Zátěž může být rozkládána na síťové, transportní či aplikační vrstvě OSI modelu a podle toho se směrují např. přicházející požadavky (requests), přicházející spojení apod. Nejznámější jsou tyto čtyři strategie: cyklické plánování, vážené cyklické plánování, plánování na nejmenší počet spojení a plánování na nejmenší vážený počet spojení.

5.1 Cyklické plánování
Při cyklickém plánování zátěže (round-robin scheduling) se zátěž rozděluje cyklicky. To znamená, že přicházející požadavky jsou postupně směrovány na servery A, B, C... A, B, C atd., aniž by se uvažovalo skutečné vytížení či jiné provozní charakteristiky. Jedinou výhodou této plánovací strategie je její jednoduchost.

5.2 Vážené cyklické plánování
Vážené cyklické plánování (weighted round-robin scheduling) se od předcházející strategie liší tím, že každému serveru je předem přidělena (konstantní) váha a četnost požadavků směrovaných na daný server je úměrná jeho váze. Tímto způsobem je možné vyrovnat zatížení několika serverů v případě, že jejich výkonnost není stejná. Jinak má tato plánovací strategie stejné výhody i nevýhody jako předcházející.

5.3 Plánování na nejmenší počet spojení
Plánování na nejmenší počet spojení (least connection scheduling) je dynamická plánovací strategie. Počítá okamžitou, v čase proměnnou zátěž serverů, vyjádřenou např. počtem aktivních spojení. Každé nové spojení je přesměrováno na server s nejmenším okamžitým zatížením, tzn. s nejnižším počtem aktivních spojení. U aplikací s malým nebo pomalu se měnícím provozem dává tato strategie velice dobré výsledky. Její slabinou však je způsob, jakým se počítají aktivní spojení: u každého komunikačního protokolu je definována určitá doba, po kterou protokol čeká na další data. Teprve v případě, že data do stanoveného času nepřijdou, je spojení ukončeno. To ovšem znamená, že za „aktivní“ se pokládá i takové spojení, které už fakticky aktivní není, ale ještě nedoběhl stanovený časový interval (timeout). Při malém provozu a za předpokladu rovnoměrného rozložení takovýchto neaktivních spojení to není na závadu, ale při rostoucích zátěžích tento stav už může vést k přetížení některého serveru.

5.4 Plánování na nejmenší vážený počet spojení
Plánování na nejmenší vážený počet spojení (weighted least connection scheduling) funguje na stejném principu jako předcházející strategie. Má s ní také podobné výhody a nevýhody. Podstatný rozdíl je pouze v tom, že každý ze serverů má předem stanovené určité váhové ohodnocení, kolik procent zátěže systému má přebírat. Nové příchozí spojení je proto přesměrováno na ten server, jehož kapacita právě má největší rezervu. Oproti prostému plánování na nejmenší počet spojení se tato plánovací strategie lépe vypořádá s problémem nestejně výkonných fyzických serverů v jednom clusteru. To z ní dělá nejčastěji používanou plánovací strategii.

6. Odolnost plánovacích strategií proti útokům DoS

Popsané plánovací strategie mohou účinně omezit útoky DoS. Zajímavé náměty k řešení plánovacích strategií jsou např. v [1]. Uvažujme nejprve klasické útoky DoS, jejichž cílem je zabránit poskytování služby. Útočník ze svého systému vysílá velké množství požadavků na služby, např. neustále iniciuje nová spojení se serverem. Přitom mu ale nejde o získání odpovědí, nýbrž snaží se přehnaným množstvím žádostí přetížit server natolik, aby došlo k jeho zahlcení tak, aby nebyl schopen poskytovat služby ani ostatním klientům. Proti tomuto druhu útoků pomůže mírná úprava plánovací strategie: požadavky, které v poslední době přišly od jednoho klientu, se nesměrují podle obecného principu (např. weighted least-connection scheduling), ale na vždy stejný server. Jde-li o řádný požadavek, uživatel tak dokonce získává výhodu rychlejší synchronizace obsahu. Jde-li o útok DoS, dojde sice k zahlcení jednoho fyzického serveru, ale ostatní servery pro ostatní uživatele pracují bez problémů dál.

Potenciální útočníci jsou si této možnosti dobře vědomi, a proto se v poslední době množí útoky typu DDoS – distribuovaný DoS. Při něm je útok iniciován z mnoha klientů současně, takže popsaná modifikovaná plánovací strategie je neúčinná. Vesměs přitom jde o nic netušící uživatele, kterým byl do počítače předem propašován virus nebo „trojský kůň„. V podstatě jedinou účinnou obranou proti DDoS jsou specializované firewally zařazené před LBS, viz [3]. Jejich podrobnější rozbor již přesahuje rámec tohoto článku. V mnoha případech je ostatně bezpečnost proti DDoS dostatečně zajištěna tím, že komunikace probíhá po soukromých kanálech, kam útočníci nemají přístup.

7. Technické prostředky

Asi nejznámější a nejkomplexnější řešení nabízí izraelská firma Radeon [4]. Jde o jednoúčelová zařízení různých výkonů Web Server Director (WSD), LinkProof a FireProof. Sdružují v sobě nejen LBS, ale také firewall a další ochranné prostředky, takže slouží jako kvalitní komplexní ochranný systém. Přestože by název naznačoval, že jejich primárním určením je rozložení služeb při použití ve funkci webového serveru, ve skutečnosti je jejich použitelnost v praxi mnohem širší. Je to dáno skutečností, že směrování může probíhat na vrstvách 4 až 7 podle OSI. Tato zařízení zcela vyhovují požadavkům na spolehlivost, nepřetržitou dostupnost i bezpečnost v naprosté většině řídicích aplikací. Zařízení jsou konfigurovatelná z vlastního grafického prostředí prostřednictvím protokolu SNMP (Simple Network Management Protocol), který umožňuje jejich správu na dálku. Přes sériový port je lze konfigurovat, byť poněkud neobratně, z příkazové řádky. Zařízení neobsahují žádné citlivé součástky (pevné disky), a navíc je možné je sdružovat tak, aby se navzájem zálohovala. To je spolu s až gigabitovou datovou propustností předurčuje k použití ve velmi důležitých a zatížených systémech. Zařízení řady LinkProof kromě toho dovoluje realizovat plně distribuované systémy, jejichž serverové farmy (až desítky tisíc fyzických serverů) pracují se servery rozmístěnými na geograficky vzdálených místech. Naproti tomu zařízení řady FireProof nabízejí zvýšenou odolnost proti všem druhům útoků včetně DDoS, tzv. trojským koňům, virům (včetně Nimda a Code Red). Jedinou společnou nevýhodou těchto zařízení je jejich cena. Podle našich zjištění začíná cena WSD u patnácti tisíc amerických dolarů. To jej v současnosti činí nepoužitelným pro většinu malých firem a výrobních provozů.

Také společnost CISCO nabízí řešení LBS s využitím dvou řad zařízení. V řadě LocalDirector je možné směrovat na servery umístěné v tomtéž místě, řada DistributedDirector rozšiřuje možnosti o umístění serverů na různých lokalitách. Celkově se vlastnosti, výhody i nevýhody podobají těm, které jsou popsány u produktu WSD. Jen se zdá, že produkty CISCO jsou o něco méně výkonné z hlediska propustnosti, ale lépe konfigurovatelné. Protože jejich hlavní nevýhoda, vysoká cena, je stejně jako WSD činí nedostupnými pro většinu běžných aplikací, nebudeme se jimi zde blíže zabývat.

8. Programové prostředky

Protože vysoká cena hardwarových směrovačů nedovoluje v současné době realizovat dvouserverový cluster za cenu nižší než asi šest set tisíc korun, byla sledována cesta softwarového řešení. V tomto směru existuje mnoho možností. Na platformě Windows (Microsoft) je možné cluster realizovat poměrně jednoduše. Počínaje produktem Windows NT Server, Enterprise Edition 4.0, je v serverech od firmy Microsoft zabudována podpora clusterování (MSCS). Při provozování na doporučené hardwarové konfiguraci propojuje dva servery do jednoho clusteru s velkou dostupností a snadnou správou. (MSCS byl dříve znám pod kódovým označením Wolfpack.)

Na platformě Linux je situace méně přehledná, protože souběžně existuje mnoho projektů zabývajících se vytvořením clusteru pod platformou Linux. Společnou vlastností je, že potřebují přizpůsobení („záplatu„, patch) v jádru operačního systému. Z nekomerčních řešení je zajímavý zejména Linux Virtual Server, který je k dispozici na internetu [2] a popsán v [1]. Z komerčních jsou zajímavé FailSafe od SUSE [6] a TurboLinux Cluster Server [7] od australské společnosti TurboLinux. Druhý projekt je zajímavý tím, že dovoluje do clusteru zařadit servery pracující na různých platformách, např. Linux, HP-UX, IBM-AIX a Windows.

9. Problémy klasických řešení

Popsané technické prostředky představují nynější špičku technických řešení, se kterými lze při správné aplikaci současně dosáhnout v podstatě nepřerušitelného chodu aplikace i vysokých výkonů. Vedle značné ceny je ale jejich nevýhodou také to, že nabízejí obecné, univerzální řešení. To jako takové nemůže reflektovat mnohé specifické problémy konkrétní aplikace, např. se synchronizací dat. Vzniká otázka, jak vhodně ukládat data, která zapisuje jeden server, aby byla k dispozici dalším serverům. Uvedený problém je relativně rozsáhlý a musí se řešit s ohledem na typ služby, technické a programové možnosti. Technické prostředky typu LBS tuto otázku přímo neřeší.

Softwarové řešení má podstatnou výhodu v nižší ceně. Ve srovnání s řešením technickými prostředky představuje pro servery určitou dodatečnou režii, takže jejich výkon je o poznání nižší. To ovšem pokládáme za menší problém než to, že softwarové řešení, jakkoliv cestou zálohování zvyšuje dostupnost i spolehlivost, přece jen ponechává velké množství nezálohovaných (a nezálohovatelných) prvků. Výsledná dostupnost a spolehlivost systému jsou proto obecně nižší než u hardwarového řešení.

9.1 Dostupnost a synchronizace dat
Představme si, že na serveru běží databázová aplikace, která vyřizuje objednávky od klientů. Každá vyřízená objednávka současně znamená změnu v databázi, která musí reflektovat např. změnu stavu zásob a musí být v krátké době přístupná všem serverům. Obvyklá cesta je, že všechny servery sdílejí společné úložiště dat, např. diskové pole (obr. 2). Je všeobecně vžitým bludem, že tím je dokonale zajištěna dostupnost služeb celého clusteru. Omyl spočívá v tom, že dostupnost serverů i dat na discích sice zajištěna je, ale není vyřešeno zálohování toku dat mezi servery a diskovým polem. Ze zkušenosti je známo, že propojení mezi servery a diskovým polem se obvykle realizuje pomocí rozhraní SCSI (Small Computer System Interface). Toto propojení je nejslabším a nejnebezpečnějším místem diskového pole. Samotný kabel je dosti citlivý k rušivým vlivům a navíc je propojení realizováno přes několik kabelových konektorů. Kdo zažil, co dokážou způsobit špatné zakončovací rezistory (anebo uklízečka, která smetákem zachytí za kabelový konektor), ví přesně, o čem je řeč. Dále toto řešení vůbec nebere v potaz otázku periferních zařízení. Například se vůbec nezabývá případem, že by se příkaz z clusteru nezobrazil na monitoru operačního pracovníka. Přitom právě závada tohoto druhu reálně může snadno nastat, ať už selháním komunikace po lokální síti, chybou softwaru na operátorském pracovišti nebo poruchou operátorského počítače.

Bezpečnější alternativou k jednomu společnému diskovému poli je, aby každý server měl svá data uložena lokálně (popř. též v diskovém poli) a aby se sdílení dat mezi servery řešilo s využitím softwaru, např. prostřednictvím replikace databází.

Pokládáme za správné na tomto místě vyvrátit ještě jeden vžitý omyl. Mnoho správců informačních systémů žije v domnění, že čím větší číslo X se vyskytuje v označení úrovně RAID-X, tím lepší a bezpečnější je zálohování dat. Úměrně tomu nastavují pracovní režim svých diskových polí a v praxi tak dokazují známou tezi, že největší nebezpečí počítačovým systémům hrozí zevnitř. Význam označení RAID (Redundant Array of Independent Disks) podle [8] a [9] je v tab. 1.

Tab. 1. Metody RAID

10. Odolnost proti chybám a selháním softwaru

Prozatím jsme mlčky předpokládali, že řídicí systém je třeba zabezpečit hlavně proti závadě hardwaru a základního softwaru. Poruchy hardwaru jsou sice fatální, ale vyskytují se poměrně zřídka. Chyby základního softwaru jsou daleko častější. Většinou jsme proti nim bezbranní. Riziko chyby operačního systému, databázového stroje a podobných fundamentálních prvků lze podstatně snížit pouze jejich vhodným výběrem už ve fázi návrhu systému. Navíc obranné mechanismy LBS v sobě zahrnují alespoň základní testy funkčnosti operačních systémů a základního softwaru.

Faktem zůstává, že drtivou většinu selhání řídicích systémů má na svědomí nedokonalý, resp. nedokonale odladěný aplikační software. Za daného stavu věcí to není nic překvapujícího: prozatím nebyly do praxe zavedeny žádné široce použitelné metody návrhu a testování bezchybného softwaru a o principu design by correctness si lze nechat jen zdát, stejně jako před třiceti lety. Základní software je sice dlouhodobě vyzkoušen velkým množstvím uživatelů, ale z toho nikterak nevyplývá, že někdo otestoval právě ten aspekt, který je pro danou aplikaci klíčový. Ovšem aplikační software nesplňuje ani to. Aplikační programy, zejména pro účely řízení, se vesměs píšou „na míru„ dané aplikaci a jsou to neopakovatelné originály. Dále se často tvoří v časové tísni, takže možnost jejich dlouhodobého testování je spíše iluzí. A navíc praxe ukazuje, že jen výjimečně se podaří nějaký technologický provoz rozběhnout přesně tak, jak předpokládal projekt. Většina aplikačních programů je zatížena menší či větší improvizací, a tak zkonstruovat dobrý a spolehlivý test, že aplikace pracuje správně, je stále spíše otázkou programátorské invence, umění a náhody než promyšleného designu.

Jako jednoduchý příklad je možné uvést řešení aplikačního softwaru pro PCO. Asi by nebylo obtížné hlídat správnou funkci operačního systému a databázového stroje. Zjistit, zda na daném serveru aplikace „zamrzla„, také není neřešitelná otázka. Ale spolehlivě ověřit, že nejen „žije„, ale také dává správné výsledky, je v podstatě nesplnitelný úkol. Z hlediska praxe je přitom úplně jedno, zda selže ohlášení požáru, a tak požární družstvo vůbec nevyjede, anebo zda sice vyjede, ale někam zcela jinam, kam ho odeslala chyba v aplikaci. (Přísně vzato, tento druhý případ je dokonce ještě horší – vedle potenciální velké nebezpečnosti také proto, že planý výjezd musí někdo zaplatit.) Jakousi nejistou naději, že aplikace funguje správně, může dát zpětná vazba. Ta však má pro řídicí aplikace jen malou cenu, protože už jen post mortem ověří, že závada skutečně nastala (když do dvou hodin k požáru nikdo nepřijel, asi došlo k nějaké chybě).

Je zřejmé, že hlavním cílem u aplikačního softwaru by mělo být nalezení takové metodiky, která by dokázala v minimálně krátké době lokalizovat vzniklé závady, ale také opravit chyby, které do dat závady zavlekly, a to všechno pokud možno bez přerušení chodu systému.

11. Použití inteligentních agentů

Popsané problémy se obvykle řeší cestou zálohování. Cílem tohoto článku je naznačit, že tato cesta v mnoha případech v praxi není optimální, a že vhodnou kombinací návrhu technických prostředků a softwaru lze docílit podstatně kvalitnějších výsledků, a to dokonce jen za zlomek původně uvažované ceny. Klíčem k tomu je metoda využití agentů, která v počítačové technice začíná získávat oblibu. V navazujícím článku v příštím čísle bude podrobně ukázáno, jak je možné optimalizovat všechna tři hlediska současně.

Doc. Ing. Josef Kokeš, CSc.,
(kokes@fsid.cvut.cz),
Josef Kokeš
(agenti@pepak.net)

Doc. Ing. Josef Kokeš, CSc. (1952), docent na strojní fakultě ČVUT, habilitoval v oboru kybernetika – specializuje se na softwarové otázky umělé inteligence.
Josef Kokeš (1978), student pátého ročníku oboru informatika na VŠE – zajímá se o každé programování, které není rutinou.

Článek lektoroval: prof. Ing. Vladimír Mařík, DrSc.,
FEL ČVUT v Praze