GSM access LXI controller

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ v PRAZE Fakulta elektrotechnická Katedra měření Kontrolér systému LXI s GSM přístupem GSM access LXI controller Bakalářská práce Studijní program: Studijní obor: Vedoucí práce: Elektrotechnika a informatika Kybernetika a měření doc. Ing. Jaroslav Roztočil, CSc. Karel Němec PRAHA 2010

2 Čestné prohlášení autora práce Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. V Praze dne Podpis autora práce - 2 -

3 Abstrakt Tato bakalářská práce se zabývá aplikací prvků vysoké dostupnosti na LXI měřící systém. Uvádí základní principy, na kterých je vysoká dostupnost postavena a řeší návrh vysoce dostupného LXI systému s důrazem na softwarové vybavení

4 Abstract The main objective of this bachelor thesis is to apply fundamental aspects of high availability to LXI measurement system. The thesis introduces basic principles of high availability and provides design of concrete high availability solution for LXI system

5 - 5 -

6 OBSAH 1 ÚVOD VYMEZENÍ ZÁKLADNÍCH POJMŮ CÍL A OBSAH PRÁCE VYSOKÁ DOSTUPNOST ÚVOD ZÁKLADNÍ ASPEKTY NÁVRHU VYSOCE DOSTUPNÉHO SYSTÉMU HIGH AVAILABILITY CLUSTERING Failover clusters (Převzetí služby) Server farms (load-balancing clusters, replikace služby) NÁVRH VYSOCE DOSTUPNÉHO LXI SYSTÉMU ANALÝZA CHYBOVÝCH SCÉNÁŘŮ POUŽITÝ HA KONCEPT A HARDWEROVÉ PROSTŘEDKY SOFTWAROVÉ VYBAVENÍ Poznámky k portabilitě Požadavky na Watchdog SW Meziprocesní komunikace Rozhraní LXI kontroléru Komunikace mezi Watchdogem a LXI kontrolérem Komunikace mezi hlavním a záložním počítačem Detekce chybových stavů Řešení chybových stavů Zotavení systému po restartu jednoho z počítačů Monitorování systému ZÁVĚR POUŽITÉ ZDROJE A OBSAH PŘILOŽENÉHO CD

7 1 Úvod 1.1 Vymezení základních pojmů LXI (LAN extensions for Instrumentation) LXI je moderním nástupcem poměrně staré sběrnice GPIB (standard IEEE 488). Jedná se o standard, který definuje komunikační protokol mezi měřícími přístroji připojenými pomocí ethernetového rozhraní do lokální sítě LAN. Detailní popis LXI standardu lze nalézt na webových stránkách lxistandard.org. LXI systém LXI systém je měřící systém skládající se z určitého počtu LXI přístrojů a hostitelského počítače, na kterém je spuštěn SW (dále označovaný jako LXI kontrolér), který řídí proces měření a provádí sběr i zpracování naměřených dat (viz Obr. 1). Běžná dostupnost (normal availability) Jako běžně dostupné se označují systémy s omezenou možností detekce a řešení hardwarových i softwarových chyb, které mohou způsobit selhání systému. Vysoká dostupnost (high availability, HA) Vysoce dostupný systém implementuje různé mechanismy, kterými se snaží chybám předcházet, případně je detekovat a samostatně řešit. Snaží tak eliminovat výpadky systému, které jsou charakteristické právě pro běžně dostupné systémy

8 Obr 1: Blokové schéma LXI systému 1.2 Cíl a obsah práce Klasický LXI systém (schematicky znázorněn na Obr. 1) patří do kategorie běžně dostupných systémů a není tedy příliš robustní, protože má velmi omezenou možnost ochrany jak proti softwarovým, tak proti hardwarovým chybám. V případě, že nastane jakýkoli chybový stav na straně LXI kontroléru nebo jeho hostitelského počítače, systém pravděpodobně nebude schopen korektně pracovat a bude nutný zásah obsluhy. Oprava systému může být v závislosti na závažnosti chyby komplikovaná a časově náročná (výměna hardware). Pokud by byl LXI měřící systém součástí nějakého monitorovacího systému v průmyslovém procesu, znamená výpadek systému prakticky ztrátu dat, což může mít v některých případech závažné důsledky ať již ryze technické nebo ekonomické

9 Práce vznikla na základě požadavku aplikovat principy vysoké dostupnosti právě na LXI systém. Cílem práce je navrhnout SW vybavení pro LXI kontrolér, které implementuje aspekty vysoké dostupnosti a vyzkoušet ho na reálném LXI systému. Při vývoji softwarového vybavení bylo přihlédnuto k tomu, že bude systém případně prakticky využit v rámci monitorovacího systému centra alternativních zdrojů ČVUT v Herbertově, kde se využívají průmyslová PC s operačním systémem reálného času PharLap ETS. Práce je rozdělena na dvě časti. První část popisuje obecně pojem vysoké dostupnosti a vysvětluje základní principy, na kterých jsou vysoce dostupné systémy založeny. Druhá část práce je ryze praktická a prezentuji v ní své vlastní řešení, které aplikuje prvky vysoké dostupnosti na LXI systém. Pozornost je věnována zejména vývoji SW vybavení

10 2 Vysoká dostupnost 2.1 Úvod Vysoká dostupnost (high availability, HA) označuje schopnost systému omezit nebo dokonce eliminovat výpadky charakteristické pro běžné systémy. Pokud už k výpadku dojde, vysoce dostupný systém se musí automaticky zotavit a plně obnovit svou funkčnost a to v co nejkratším časovém intervalu. Podmnožinou vysoké dostupnosti je tzv. stálá dostupnost (continuous availability). Systémy implementující tuto vlastnost musí zprostředkovávat danou službu nepřetržitě. V podstatě každá komponenta takového systému musí být chráněna proti výpadku. Dostupnost je mírou toho, jak často nebo po jakou dobu systém zpřístupní uživateli danou službu a může se jednoduše vyjádřit jako poměr doby, kdy je služba, kterou systém poskytuje, dostupná a celkové doby, za kterou dostupnost měříme. Dostupnost je možné uvádět buď v procentech nebo absolutně. S pojmem dostupnost souvisí úzce pojem spolehlivost (reliability), který je definován jako pravděpodobnost, že systém bude pracovat v bezporuchovém stavu po daný časový interval. Spolehlivost systému znamená schopnost předejít chybám a eventuálně je správně detekovat. Často se uvádí v tzv. MTBF (Mean Time Between Failures) tato hodnota vyjadřuje střední dobu v hodinách, po kterou se očekává, že systém bude bezchybně pracovat. 2.2 Základní aspekty návrhu vysoce dostupného systému Při návrhu vysoce dostupného řešení je primárním cílem vytvořit systém takový, který je schopný ošetřit co největší množinu možných chybových stavů a zároveň kontinuálně zprostředkovávat danou klíčovou službu

11 Nejprve je třeba analyzovat daný existující běžně dostupný systém a zjistit, které chybové stavy nejvíce ohrožují činnost systému. V dalším kroku je třeba navrhnout řešení těchto chybových stavů tak, aby je byl systém schopen samostatně překonat a korektně pracovat i potom, co nastanou. Abychom splnili základní požadavky na vysoce dostupný systém, musí systém implementovat tři klíčové vlastnosti: Robustnost Jednoduchost Redundance Robustnost a jednoduchost systému spolu úzce souvisí. Musíme systém navrhnout tak, abychom minimalizovali pravděpodobnost výskytu chyb. Aby systém byl robustní, musí být tak jednoduchý, jak jen to je možné a zároveň jenom tak složitý, jak to požadavky na řešení problému vyžadují. V každém systému existuje nějaká komponenta, jejíž výpadek znamená automaticky výpadek celého systému (tyto komponenty se označují termínem SPOF Single Point Of Failure). Takovou komponentu je třeba nějakým způsobem chránit a jednou z možností, jak to zajistit, je právě redundance (do systému přidáme nadbytečnou komponentu, která v případě výpadku původní komponenty přebere její funkčnost). Na druhou stranu se systém při zvyšování úrovně redundance stává složitějším a méně robustím. Redundantní komponenty vytvářejí v systému nové závislosti a to vede vzniku nových potenciálních chybových stavů. Je tedy třeba využívat redundanci jenom u těch částí systému, kde je to bezpodmínečně nutné

12 2.3 High availability clustering V souvislosti s organizací činnosti počítačů se slovo cluster používá pro skupinu počítačů, které zajišťují jednu činnost, resp. službu. Cluster lze velmi efektivně použít v rámci vysoce dostupného systému jako prostředek redundance na úrovni hostitelského počítače, který poskytuje klíčovou službu systému. Základní myšlenkou vysoce dostupných clusterů je umožnit pohyb klíčové služby z jednoho hostitelského počítače v clusteru na jiný nebo poskytovat službu na všech počítačích clusteru. Ojedinělé selhání počítače by tak poskytovanou službu nemělo ohrozit. Existují dva základní koncepty vysoce dostupných clusterů tzv. failover clusters a server farms (load-balancing clusters) Failover clusters (Převzetí služby) Koncept failover clusters je založen na principu migrace klíčové služby systému z jednoho počítače clusteru na druhý. Implicitně službu poskytuje počítač označovaný jako tzv. primární uzel, ostatní počítače clusteru (sekundární uzly) pouze monitorují stav primárního uzlu. v případě, že dojde k výpadku primárního uzlu, jeden ze sekundárních uzlů převezme jeho identitu a začne službu poskytovat Server farms (load-balancing clusters, replikace služby) U tohoto konceptu všechny počítače clusteru poskytují danou službu. Pokud nějaký z počítačů selže, služba bude pořád dostupná na ostatních uzlech clusteru

13 3 Návrh vysoce dostupného LXI systému Jak už bylo zmíněno v úvodní kapitole, cílem návrhu je upravit běžně dostupný LXI systém tak, aby byl schopen eliminovat různé hardwarové i softwarové chybové stavy a udržet tak proces měření v chodu. 3.1 Analýza chybových scénářů Klíčovým bodem systému, který je potřeba chránit, je jistě LXI kontrolér. Výpadek kontroléru nebo nějaký jeho vnitřní chybový stav (segmentation fault, memory leak apod.) způsobí pravděpodobně výpadek celého systému. Samotný kontrolér je pak závislý na stavu operačního systému a svého hostitelského počítače. Pád operačního systému nebo chyba hardware, která v něj nakonec vyústí, znamená také výpadek celého systému. Tyto dva chybové stavy jsem pokládal za nejpravděpodobnější a systém je navržen tak, aby je dokázal efektivně vyřešit. Dalším chybovým stavem, který může systém ochromit, je selhání routeru nebo ethernetového switche, který je využit pro připojení LXI přístrojů do systému. Chyby na straně těchto zařízení jsou ale považovány za výjimečné a proto je při návrhu neuvažuji

14 3.2 Použitý HA koncept a hardwarové prostředky Základní myšlenkou bylo přidat do klasického LXI systému redundantní (záložní) počítač, který by v případě poruchy na hlavním počítači okamžitě převzal jeho identitu a udržel tak proces měření v chodu. To odpovídá HA konceptu failover clusters, který je založen na principu migrace klíčové služby (u navrhovaného systému se jedná o LXI kontrolér) v případě poruchy z původního hostitele (hlavní počítač) na jiného, u kterého se předpokládá, že se nachází v bezporuchovém stavu. Jádrem navrhovaného systému jsou tedy dvě standardní či průmyslová PC, která společně s připojenými LXI přístroji tvoří ethernetovou síť. Zároveň je nutné zajistit, aby stav systému mohl být vzdáleně monitorován. V návrhu jsem uvažoval dvě možnosti GSM síť a internet. Oba počítače tedy sdílejí přístup k internetu a jsou propojeny s GSM modemem sběrnicí standardu RS-485. Výsledný hardwarový model navrhovaného systému je schématicky znázorněn na Obr

15 Obr 2: HW model systému 3.3 Softwarové vybavení Esenciální součástí je HA systému je software (dále označovaný jako Watchdog SW), který ovládá LXI kontrolér, umožňuje detekci a řešení chyb a podává hlášení o stavu systému. Tomu je věnována následující podkapitola Poznámky k portabilitě SW implementující prvky vysoké dostupnosti byl napsán v jazyce C a pro přístup k prostředkům operačního systému využívá rozhraní Win32 API. To umožňuje poměrně snadnou migraci programu na operační systém reálného času PharLap ETS, který podporuje rozsáhlou podmnožinu funkcí Win32 API

16 Komunikaci mezi procesy řeší SW pomocí knihovny WinSock (součást Win32 API). Použití nadstavbových knihoven jiných stran 1 mírně zjednodušuje implementaci, 4 zároveň ale často přináší významné problémy s portabilitou. SW lze modifikovat i tak, aby byl spustitelný na unixových distrubucích. Klíčová je náhrada funkcí Win32 API (např. jejich ekvivalenty v rozhraní POSIX). Použití socketových funkcí je prakticky stejné (rozhraní knihovny WinSock je založené na 5 původní unixové implementaci firmy BSD kalifornské univerzity v Berkeley). Obr 3: SW model systému 1 Např. TCP Support Library v NI LabWindows/CVI

17 3.3.2 Požadavky na Watchdog SW Klíčovou službou, kterou chceme chránit, je LXI kontrolér. Abychom mohli detekovat různé chybové stavy, musíme vytvořit SW vrstvu, která bude LXI kontroléru nadřazená (viz. Obr.3), bude ho ovládát a zprostředkovávat komunikaci mezi hlavním a záložním počítačem - takovou vrstvu tvoří právě instance navrhovaného Watchdogu. Watchdog se dále musí starat o to, aby byl LXI kontrolér v chodu právě na jednom z počítačů. Pokud kontorolér nepracuje ani na jednom z počítačů nebo se nějakým nedopatřením stane, že pracují oba (nastává tzv. brainsplit), musí Watchdog situaci řešit. Watchdog implementuje následující body: Komunikace s LXI kontrolérem a s tím spojená schopnost dektekce chybových stavů kontroléru Ovládání vnitřních stavů LXI kontroléru, ukončení kontroléru (bezpečně zasláním signálu i zabitím procesu), restart kontroléru Komunikace mezi hlavním a záložním počítačem a s tím spojená schopnost detekce výpadku počítače; předávání informace o stavu podřízeného LXI kontroléru Řešení chybových stavů restartem kontroléru nebo převzetím služby Podávání hlášení o celkovém stavu systému (Syslog server, GSM) Schopnost rozlišit výpadek jednoho z počítačů od výpadku instance Watchdogu Těmto vlastnostem se budu podrobně věnovat v následujících podkapitolách

18 3.3.3 Meziprocesní komunikace Pro zasílání zpráv mezi procesy (ať už se jedná o komunikaci mezi Watchdogem a LXI kontrolérem nebo mezi instancemi Watchdogu spuštěnými na hlavním a záložním počítači) využívá Watchdog sokety. Otázkou je, zda použít protokol TCP nebo UDP. Protokol TCP garantuje bezpečnost a kvalitu spojení a také to, že data budou obdržena v tom pořadí, ve kterém byla odeslána. UDP tento komfort nezajišťuje, na druhou stranu je ale rychlejší a nepoměrně méně náročný na výkon sítě. Zvolil jsem protokol TCP, protože Watchdog pomocí soketových zpráv ovládá LXI kontrolér a je zásadní, aby kontrolér tyto zprávy v pořádku přijal a zpracoval Rozhraní LXI kontroléru Aby mohl Watchdog LXI kontrolér ovládat, musí kontrolér implementovat dva vnitřní stavy (je buďto pasivní nebo aktivní) a také musí být schopen zpracovat množinu nadefinovaných zpráv, které umožňují přechod z jednoho stavu do druhého (viz Obr. 4). Watchdog musí mít možnost ukončit proces LXI kontroléru vynuceně, což lze provést voláním Win32 API funkce TerminateProcess(). To se týká chybových stavů, kdy nelze kontrolér ukončit jiným způsobem. Při použití TerminateProcess() nelze hovořit o korektním ukončení procesu, protože tato funkce mimo jiné negarantuje uvolnění synchronizačních prostředků Win32 API jako jsou mutexy nebo kritické sekce. Tento problém je podrobně popsán v dokumentaci API a je zmíněn i v [6]

19 Pokud je kontrolér aktivní, pracuje s LXI systémem (provádí odběr a zpracování naměřených dat, ukládání na pevný disk apod.). Pokud je kontrolér pasivní, s měřícím systémem nepracuje a pouze čeká na další instrukce. Obr 4: Diagram stavových přechodů LXI kontroléru Komunikace mezi Watchdogem a LXI kontrolérem Proces LXI kontroléru spouští jemu nadřazená instance Watchdogu a jako parametr příkazové řádky mu předává číslo portu, na kterém spolu budou komunikovat. Watchdog se v rámci TCP komunikace chová jako server a naslouchá na daném portu, LXI kontrolér je klientem a k Watchdogu se připojuje (viz Obr. 5). 7 Watchdog kontroléru v daných časových intervalech zasílá požadavek, aby mu kontrolér odpověděl a dal mu tím najevo, že je v pořádku. Kontrolér ihned po zpracování zprávy odpovídá

20 Obr 5: Vytvoření TCP spojení Watchdog-LXI kontrolér Jako rámec zprávy jsem zvolil jeden bajt. V případě řídících signálů a dotazu na stav, které zasílá Watchdog LXI kontroléru, zabírá celý bajt identifikační číslo zprávy. Tyto zprávy jsou tedy odlišeny hodnotou v rozsahu ID zprávy Popis 0x00 0x80 0x81 0x82 Dotaz na stav LXI kontroléru Přechod kontroléru do aktivního stavu (run) Přechod kontroléru do pasivního stavu (stop) Ukončení kontroléru (terminate) Tab 1: Řídící zprávy pro LXI kontrolér

21 Odpověď LXI kontroléru na dotaz na stav je strukturována jinak. Nejvýznamnější bit zprávy (msb) podává informaci o tom, v jakém stavu se kontrolér nachází (aktivní/pasivní), ostatních sedm bitů tvoří tzv. deskriptor. Interpretace deskriptoru závisí na samotném LXI kontroléru může se jednat o hodnotu, která určuje, jakou význačnou operaci kontrolér v okamžiku odeslání zprávy vykonává nebo může jít o identifikátor vnitřních chybových stavů kontroléru apod. Každopádně může deskriptor výrazně pomoci při analýze chyb a havarijních situací. Obr 6: Struktura odpovědi LXI kontroléru na dotaz na stav Komunikace mezi hlavním a záložním počítačem Komunikaci mezi hlavním a záložním počítačem zprostředkovávají instance Watchdogu, které jsou na nich spuštěné. Instance Watchdogu, jejíž podřízený LXI kontrolér je aktivní, má výsadní postavení a je označena jako Watchdog master, druhá instance je označena jako Watchdog slave. V rámci TCP komunikace se Watchdog master chová jako server, slave jako klient. Při uvádění systému do chodu se master spouští jako první a čeká, až se k němu slave připojí. Do té doby je master schopen fungovat autonomně. Slave se po spuštění pokouší k masterovi připojit pokud se mu to nepodaří, podá hlášení a ukončí se

22 Jakmile se spojení podaří navázat, začnou spolu instance Watchdogu komunikovat. V daných časových intervalech si předávají zprávy (dále označované jako heartbeat zprávy), kterými podávají informaci o svém stavu (už přijetí zprávy představuje pro adresáta informaci o tom, že je odesilatel v pořádku) a stavu podřízeného LXI kontroléru. Výměnu heartbeat zpráv schematicky popisuje Obr. 7. Obr 7: Schématické znázornění heartbeatu Kromě heartbeat zpráv využívá Watchdog ještě jeden typ zprávy pro přechod podřízeného kontroléru do aktivního stavu (zpráva pro převzetí kontroly). Rámcem watchdogových zpráv jsou dva bajty. První bajt představuje hlavičku zprávy, která určuje, o jakou zprávu se jedná, druhý podává informaci o stavu podřízeného LXI kontroléru a má stejnou stejnou strukturu jako odpověď kontroléru na dotaz na stav (MSB stav kontroléru, ostatní bity deskriptor)

23 Obr 8: Struktura watchdogové zprávy Detekce chybových stavů Uvažoval jsem následující chybové stavy: Chyba na straně LXI kontroléru cokoliv, co způsobí, že kontrolér nebude schopen korektně pracovat a odpovídat na požadavek na stav Pád operačního systému Výpadek počítače (hardwarová chyba) Výpadek instance Watchdogu Základní myšlenkou pro detekci těchto chyb je fakt, že jsou všechny spojené s přerušením komunikace mezi jednotlivými uzly v systému. Za běhu systému neustále probíhá komunikace mezi Watchdogem a jemu podřízeným LXI kontrolérem a zároveň mezi sebou komunikují i obě instance Watchdogu. Jakmile instance Watchdogu přestane přijímat zprávy ať už od LXI kontroléru nebo od svého protějšku na vzdáleném počítači je evidentní, že nastala nějaká chyba. Mechanismus detekce je tedy v principu stejný pro všechny uvedené chyby. Pro hlídání komunikace používá Watchdog časovač, který po překročení časového limitu určeného pro odpověď vyvolá chybovou událost. Při prvním odeslání zprávy je časovač spuštěn, při přijetí zprávy je resetován. Jakmile kontrolér (resp. Watchdog) přestane komunikovat, příslušný časovač nebude resetován a po uplynutí daného časového limitu zavolá funkci, která chybový stav obslouží

24 Při prvním výskytu chyby Watchdog pouze podá varovné hlášení a znovu zašle dotaz na stav (resp. heartbeat zprávu). Pokud ani potom neobdrží odpověď, začne chybový stav řešit. Obr 9: K principu hlídání komunikace Přerušení komunikace sice umožňuje sice chyby odhalit, ale některé z nich nedokáže rozlišit. v případě, že dojde k výpadku instance Watchdogu, která dohlíží na aktivní kontrolér, druhá instance bude situaci interpretovat tak, že došlo k výpadku protějšího počítače a začne chybový stav řešit, což může mít ve výsledku fatální následky. Tyto chybové stavy lze rozlišit na základě toho, že při výpadku počítače dochází k přerušení síťového připojení. Stav síťového připojení lze monitorovat pomocí protokolu ARP stačí vyslat ARP dotaz na IP adresu protějšího počítače a pokud není vrácena příslušná MAC adresa, spojení je přerušeno

25 Pro zaslání ARP dotazu má Win32 API funkci SendARP(): DWORD SendARP( in IPAddr DestIP, in IPAddr SrcIP, out PULONG pmacaddr, inout PULONG PhyAddrLen ); Prvním argumentem je dotazovaná IP adresa, druhým IP adresa odesilatele dotazu. Třetí argument je výstupní, jedná se o pole typu ULONG reprezentující získanou fyzickou adresu. Poslední argument specifikuje počet bajtů načtené adresy Řešení chybových stavů Tato kapitola je věnována tomu, jak Watchdog řeší konkrétní chybové stavy. Výpadek LXI kontroléru V podstatě nejméně závažnou chybou vůbec je chyba na straně pasivního LXI kontroléru - při této chybě je systém fakticky v pořádku (měření řídí aktivní kontrolér). Instance Watchdogu detekuje, že jí podřízený kontrolér neodpovídá a pokusí se ho restartovat. Pokud proces LXI kontroléru stále běží, ukončí ho vynuceně voláním TerminateProcess() a znovu spustí. Závažnějším problémem je chyba aktivního kontroléru. Stejně jako u výpadku pasivního kontroléru se Watchdog kontrolér pokusí restartovat, současně ale přejde do pasivního stavu a zašle protějšímu Watchdogu zprávu pro převzetí kontroly. Ten zprávu zpracuje a zaktivuje svůj podřízený kontrolér tím dochází k převzetí služby. Při přebírání služby se mění postavení Watchdogu slave se stává masterem a naopak

26 Obr 10: Převzetí služby po výpadku aktivního LXI kontroléru V tom případě, že z nějakého důvodu nebude k Watchdog masterovi připojen slave, funguje master autonomně a výpadek kontroléru řeší jeho restartem. Funguje tedy jako klasický softwarový watchdog. Pád operačního systému (výpadek počítače) Pád operačního systému znamená současný výpadek kontroléru i instance Watchdogu. Tuto chybu Watchdog řeší analogicky jako u výpadku kontroléru převzetím služby, pokud se chyba týká počítače s aktivním kontrolérem (viz Obr.11). Při pádu OS na počítači s pasivním kontrolérem Watchdog pouze podá hlášení

27 Obr 11: Převzetí služby při výpadku hostitelského počítače aktivního LXI kontroléru Výpadek Watchdogu Výpadek Watchdogu je jedním z nejzávažnějších chybových stavů, které v systému mohou nastat. Fakticky tato chyba neznamená výpadek klíčové služby (oba počítače jsou v pořádku, jeden z kontrolérů je aktivní), ale způsobí ztrátu spojení mezi hlavním a záložním počítačem (přestože síťové spojení je v pořádku) a tím systém ztrácí veškeré prvky vysoké dostupnosti. Watchdog SW musí být co nejrobustnější a nejjednodušší, aby se minimalizovala pravděpodobnost, že tato situace nastane

28 Obr 12: Vznik brainsplitu při nesprávném ošetření výpadku instance Watchdogu Výpadek instance Watchdogu, jejíž podřízený kontrolér je aktivní, druhá instance nesmí interpretovat jako výpadek počítače. Pokud by se tak stalo, došlo by k převzetí služby a pasivní kontrolér by byl aktivován oba kontroléry by tedy byly v chodu (brainsplit) a pracovaly by s měřícím systémem. Tato situace je schématicky znázorněna na Obr. 12. Problém je možné řešit tak, že systém odliší výpadek instance Watchdogu od výpadku celého počítače (viz. Detekce chybových stavů) a nebude na něj reagovat jinak než pouhým hlášením. Navrhovaný systém implementuje jiné řešení. Jakmile dojde k výpadku instance Watchdogu, jí podřízený kontrolér detekuje přerušení TCP spojení a okamžitě se ukončí. Potom může dojít k bezproblémovému převzetí služby. v takové situaci si systém uchová alespoň některé HA prvky, protože Watchdog master potom funguje jako klasický softwarový watchdog

29 Brainsplit v bezporuchovém stavu Watchdog musí umět řešit situace, kdy jsou z nějakého důvodu aktivní obě instance kontroléru, i když je jinak systém v pořádku. v takovém případě Watchdog slave přepne podřízený kontrolér do pasivního stavu. Pokud se mu to nepodaří, kontrolér restartuje Zotavení systému po restartu jednoho z počítačů Po restartu jednoho z počítačů musí být systém schopen obnovit komunikaci mezi počítači (resp. instancemi Watchdogu). Watchdog si v systémovém registru uchovává informaci o tom, jestli má po spuštění operačního systému nabíhat jako master nebo jako slave. Implicitně se instance Watchdogu po restartu spouští vždy jako slave, protože předpokládá, že došlo k úspěšnému převzetí služby a druhá instance Watchdogu je masterem. v takovém případě se slave po spuštění pokusí k masterovi připojit pokud se mu to podaří, je komunikace obnovena a systém je znovu plně funkční, pokud ne, ukončí se a podá hlášení. V případě, že master funguje autonomně (slave není připojen), nabíhá po restartu opět jako master, nikoli jako slave, který autonomně pracovat nemůže (vyžaduje připojení k masterovi)

30 Monitorování systému Navrhovaný systém je vzdáleně monitorován pomocí Syslog serveru. Syslog Syslog je standardem (RFC 3164 The BSD syslog protocol) pro příjem a ukládání programových zpráv, který v současnosti spravuje skupina IETF. Umožňuje separovat software, který zprávy generuje od toho, který je ukládá, zpracovává a analyzuje (Syslog server). Aplikace v případě potřeby zašle Syslog serveru textovou zprávu s informací o tom, jaká na její straně nastala událost. Syslog server k ní připojí čas, kdy byla zpráva přijata a celý záznam uloží do log souboru a případně zobrazí. Zprávy jsou ryze textové a jejich struktura vypadá takto: <PRIORITY> HEADER MESSAGE, kde PRIORITY je celočíselná hodnota od 0 do 191 určující závažnost zaznamenané události (jednotlivé úrovňě definovány standardem), HEADER obsahuje časový údaj a IP adresu odesilatele a MESSAGE představuje popis události. Konkrétní zpráva může tedy vypadat například takto: <12>Jul 10 12:00: Backup computer down Výhodou Syslog serveru je, že jeden stroj může monitorovat události aplikací na neomezeném počtu strojů v celé síti. Pokud dojde k nějaké závadě, lze okmažitě zjistit, kde nastala a o jaký konkrétní chybový stav se jedná

31 KIWI Syslog server Existuje celá řada SW nástrojů, které implementují funkčnost Syslog serveru. Pro testování navrhovaného systému jsem využil volně dostupnou verzi programu KIWI Syslog server pro platformu Windows ( která umožňuje přijem a odesílání zpráv pomocí protokolu TCP i UDP. Příchozí zprávy program ukládá na disk a zobrazuje v GUI v přehledné tabulce. Obr 13: Ukázka GUI aplikace Kiwi Syslog server

32 4 Závěr Watchdog SW, který vnáší do LXI systému prvky vysoké dostupnosti, byl úspěšně realizován. Software je napsán v jazyce C a pro přístup k systémovým prostředkům využívá rozhraní Win32 API. Rozsah projektu je přibližně 2500 řádek (42kB). Projekt byl kompilován ve vývojovém prostředí Microsoft Visual Studio 6.0. Watchdog SW implementuje všechny vlastnosti, které byly v návrhu podrobně rozebrány. Umožňuje komunikaci mezi hlavním a záložním počítačem, je schopen detekovat a řešit uvedené chybové stavy převzetím služby a může být použit i na samostatném počítači jako klasický softwarový watchdog. Informace o význačných událostech v systému posílá na Syslog server. Možnost podávání hlášení pomocí GSM byla zpracována pouze teoreticky. Při testování na reálném LXI systému byl využit modelový LXI kontrolér vytvořený v prostředí NI LabWindows/CVI Zdrojové soubory a popis funkčnosti použitého kontroléru lze najít na přiloženém CD

33 5 Použité zdroje [1] SCHMIDT, Klaus. High Availability and Disaster Recovery: Concepts, Design, Implementation. 1 st ed. Springer, s. ISBN: [2] VARGAS, Enrique. High availability fundamentals. Sun BluePrints OnLine. November Dostupné na WWW: < [3] PIRKL, Josef. Síťové programování pod Windows a programování Internetu. 2.vyd. České Budějovice : KOPP, s. ISBN [4] OSTERLOH, Heather. TCP/ IP - Kompletní průvodce. 1. vyd. Praha : SoftPress, s. ISBN [5] RICHTER, Jeffrey. Windows pro pokročilé a experty. 1. vyd. Praha : ComputerPress, s. ISBN: [6] KOCOUREK, Petr; kolektiv autorů. Číslicové měřící systémy. Praha : Vydavatelství ČVUT, s. ISBN: [7] HEROUT, Pavel. Učebnice jazyka C. 4. vyd. České Budějovice : KOPP, s. ISBN: [8] MSDN Library. Dostupné na WWW: <

34 A Obsah přiloženého CD Přiložené CD je rozděleno do několika adresářů: bp Tato bakalářská práce ve formátu PDF. Watchdog_SW/source Zdrojové soubory Watchdog SW ve formě projektu vývojového prostředí MS Visual Studio 6.0. Watchdog_SW/manual Manuál k programu ve formátu PDF. Watchdog_SW/bin Watchdog SW s přiloženým konfiguračním nastavením. LXIController/descr Popis použitého modelového LXI kontroléru ve formátu PDF. LXIController/source Zdrojové soubory kontroléru ve formě projektu NI LabWindows/CVI. LXIController/bin Modelový LXI kontrolér. KIWI_syslog Instalační soubor pro aplikaci KIWI Syslog server a manuál v PDF