Aktuální vydání

celé číslo

03

2020

Veletrh Amper

Fórum automatizace a digitalizace

celé číslo

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

číslo 1/2004

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.

Obr. 1.

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

Obr. 2.

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

Level 0

Cílem této metody je zajistit vyšší výkon diskového pole oproti osamocenému disku tím, že se čtení i zápis dat rozloží mezi několik (typicky dva) paralelně pracujících disků. Každý disk tak ukládá a čte jen část dat, datový tok ze dvou disků je dvojnásobný oproti osamocenému disku. Polovina dat se uloží na jeden disk, druhá polovina na druhý disk. Proto je výhodné používat dva identické disky (jinak by ten rychlejší musel čekat na pomalejší, resp. z většího disku by se použila jen část kapacity, která by odpovídala menšímu disku). Tato metoda se nazývá stripping. Je zřejmé, že při ní nedochází k žádnému zálohování dat, je zaměřena na zvýšení propustnosti.

Level 1

Tato metoda naopak vůbec nezvyšuje datovou propustnost, ale zvyšuje bezpečnost dat jejich zálohováním. Metoda se nazývá zrcadlení – mirroring a spočívá v tom, že se stejná data zapíšou na (obvykle dva) disky současně. Tuto metodu dlouho a úspěšně používají servery Novell. Při selhání jednoho z disků zůstávají data dostupná na druhém disku. Za to se ovšem platí prostorem na disku – polovina kapacity diskového pole obsahuje data, druhá polovina jejich záložní kopii. Kapacita pole je tedy určena kapacitou nejmenšího disku. Na rychlosti se tato metoda neprojevuje, přístup je tak rychlý, jak je rychlý ten nejpomalejší disk v poli.

Level 1/0

Tato metoda se označuje level 0/1 nebo 1/0 nebo 10. Jde v podstatě o kombinaci předchozích dvou metod: data jsou rozdělena mezi několik disků (kvůli rychlosti, stripping), přičemž každý disk je současně zrcadlen (mirroring) na druhý, paralelně pracující disk. Tím se slučují výhody i nevýhody obou předchozích metod.

Level 2

Tato metoda vychází z level 0, ke které doplňuje dodatečnou ochranu dat pomocí kódování ECC (Error Checking and Correction). Vyžaduje však podporu ze strany pevných disků, proto se tato metoda komerčně nijak výrazněji nerozšířila.

Level 3

Tato metoda je zjednodušenou verzí level 2 a nejlépe je vhodná ke čtení dlouhých sekvenčních souborů (např. videa). Vedle N datových disků je zde jeden paritní disk, na který se ukládá redundantní informace. Lze si představit, že při osmi datových a jednom paritním disku by při zápisu jednoho bajtu informace se každý jeho bit paralelně zapisoval na jeden datový disk. Vedle toho by se funkcí XOR vytvořil paritní bit, který by se současně zapsal na pomocný disk. Kdyby na kterémkoliv disku nastala závada, z obsahu paritního a ostatních datových disků lze (opět funkcí XOR) vypočítat chybějící hodnotu. Tato metoda je pomalá při zápisu, protože je třeba z paritního disku číst redundantní informace a zase je na něj ukládat. Naproti tomu čtení je rychlé, protože data se čtou z datových disků paralelně. Tato metoda se příliš nerozšířila.

Level 4

Tato metoda používá inteligentní diskový řadič s vlastní pamětí a s vlastním procesorem. Pracuje se čtyřmi datovými disky a jedním, na který se ukládají kontrolní součty. Redundance tedy je 20 %. Nutnost přečíst a pak znovu zapsat kontrolní informaci zůstala nezměněna. V podstatě se velmi podobá metodě level 3, až na to, že data se mezi disky nerozdělují po jednotlivých bitech, ale po blocích. Bloky lze na discích hledat a číst nezávisle, čímž se při čtení velkého počtu krátkých dat zlepšuje efektivnost (výhodné pro databázové systémy). Naopak není vhodná pro transakční systémy, protože pro velké počty zápisů je diskové pole pomalé.

Level 5

Jde o velmi oblíbenou metodu, která je vylepšením metod level 3 a level 4. Rozdíl je v tom, že se redundantní informace neukládají na vyhrazený disk, ale jsou rozděleny mezi všechny disky. Promyšlené umístění sektorů a současné čtení všech pěti disků zabrání kolizím uvedeným v předchozí úrovni. Redundance je přibližně 25 %. Je nejvhodnější pro časté čtení krátkých bloků dat, tedy pro databázové aplikace a aplikace s transakčním zpracováním. V případě selhání jednoho disku se data mohou číst dál, i když poněkud pomaleji (rekonstrukce dat je spojena s výpočetní režií).

Level 6

Pracuje podobně jako level 5, s tím rozdílem, že nevytváří jednu, nýbrž dvě paritní informace. Proto je tato metoda odolná i proti selhání dvou libovolných disků v poli. Rychlost čtení je srovnatelná s level 5, zápis je poněkud pomalejší (je třeba vytvořit a zapsat dvě sady paritních informací).

Level 30, level 50

Jde o kombinované metody, které (podobně jako to dělá level 10) rozdělují data do několika paralelních proudů. Tyto proudy jsou zálohovány obdobně jako u metody level 3 nebo jako v případě metody level 5. Výsledná metoda vykazuje dobrou rychlost a je vhodná pro sekvenční čtení dat (level 30) nebo pro transakční operace (level 50). Celková úroveň zabezpečení je však horší než u level 6 nebo level 1.

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

Literatura:

[1] PUSTKA, M.: Rozkládání zátěže a zajištění dostupnosti systémů a služeb v počítačových sítích. In: Sborník přednášek z konference XXIV. Seminář ASŘ 2000 konaný 3. a 4. 5. 2000 na VŠB v Ostravě. Dostupné na http://www.fs.vsb.cz/akce/2000/asr2000/Sbornik/papers/pustka.pdf [cit. 18. 12. 2003].

[2] WENSONG ZHANG – SHIYAO JIN – QUANYUAN WU: Linux Virtual Server Project. On-line projekt podporovaný National Laboratory for Parallel & Distributed Processing Changsha. Dostupné na http://www.linux-virtualserver.org/linuxexpo.html [cit. 18. 12. 2003].

[3] LocalDirector Documentation. On-line firemní dokumentace Cisco Systems Inc., 2000. Dostupné na http://www.cisco.com/univercd/cc/td/doc/product/iaabu/localdir/ [cit. 18. 12. 2003].

[4] Radware WSD. On-line firemní dokumentace Radware, 2000. Dostupné na http://www.radware.com/content/products/wsd [cit. 18. 12. 2003].

[5] What’s New in Clustering for Windows Server 2003. On-line firemní dokumentace Microsoft, 2003. Dostupné na http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx [cit. 18. 12. 2003].

[6] MAROWSKY, L.: FailSafe SUSE Linux. On-line dokumentace společnosti SUSE, 2000. Dostupné na http://oss.sgi.com/projects/failsafe/ [cit. 18. 12. 2003].

[7] Why use Turbolinux Cluster Server 8? On-line firemní dokumentace společnosti TurboLinux, 2003. Dostupné na http://www.turbolinux.com/products/tlcs8/tlcs_2.html [cit. 18. 12. 2003].

[8] KERŠLÁGER, M.: Stručný úvod do terminologie RAID. Střední průmyslová škola strojní a elektrotechnická a Vyšší odborná škola, Liberec, 2003. Dostupné na http://www.pslib.cz/~kerslage/manuals/raid.html [cit. 18. 12. 2003].

[9] Jak funguje RAID? Redakční článek internetového časopisu Abitfun. Dostupné na http://abitfun.wz.cz/polozky/pojmy/co_je_to_raid.htm [cit. 18. 12. 2003].

[10] TurboHA 6 User Manual. On-line firemní dokumentace Turbolinux Inc., 2001. Dostupné na http://www.turbolinux.com.cn/products/data/TurboHA/tha6ug.pdf [cit. 18. 12. 2003].

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

Inzerce zpět