Kontinuita vyžaduje monitorování drobností

Ačkoliv je dnes k dispozici nepřeberné množství nástrojů pro správu a monitoring firemní infrastruktury, jejich nasaz...


Ačkoliv je dnes k dispozici nepřeberné množství nástrojů pro správu a
monitoring firemní infrastruktury, jejich nasazení není zdaleka vším, co musíte
pro zajištění plynulého běhu obchodních procesů udělat. Možná se běh vašeho
systému jeví jako bezproblémový jen proto, že jste špatně nastavili nebo
vypnuli některý z alarmů.
Kdysi jsem pracoval pro společnost, jež měla vyspělou farmu serverových systémů
s vyváženým zatížením (díky load balancing systému), kterou využívala pro
firemní adresář. Uživatelé začali hlásit čas od času, že se musejí autentizovat
dvakrát nebo musejí opětovně odeslat e-mail interním zaměstnancům.
Administrační konzole přitom ukazovala, že adresářová služba je on-line a v
pořádku. V dotazech uživatelů nebylo možné vypozorovat žádný vzor selhání, ale
frekvence telefonátů na helpdesk narůstala.
Až jeden bývalý školní administrátor nás nasměroval ke správnému řešení.
"Konzole pro správu neví všechno," upozornil. "Zkuste problém diagnostikovat
tak, jako kdybyste systém pro správu neměli." Takže jsme postupovali zastaralým
způsobem a sledovali problém zdola nahoru namísto shora dolů. A hle! Zjistili
jsme, že u jednoho ze serverů selhává řadič pevného disku a občas dochází k
poškození čtených dat.
Souvislý průběh obchodních procesů firmy a strategie obnovy v případě selhání
jsou založeny na předpokladu, že nejvyšší náklady způsobují ta selhání, jež
jsou nejvíce zjevná: jeden či více systémů, služeb nebo zařízení "odejde", tedy
přestane fungovat. Avšak tento systém již ze své povahy nevyhledává nebo
nezkoumá méně významné příznaky potíží.
Některé menší problémy se v průběhu času nahromadí nebo narostou prostě proto,
že nejsou sledovány. Ať již tyto drobnosti zůstanou nepovšimnuty proto, že
nemáme nikoho, kdo by se o ně staral, nebo proto, že se jejich monitorování
nezdá dostatečně důležité, mohou se v průběhu doby nakupit, narušit činnost
systému a v důsledku toho způsobit větší škody než velké problémy, jichž se
správci IT obávají nejvíce.
Než jeden z těchto plíživých stavů, který je pod rozlišovací schopností
monitorovacího systému, způsobí poplach, mohl již za sebou zanechat pěknou
spoušť. V případě serveru s poškozeným pevným diskem si řadič nebyl problému
vědom, takže žádné varování neposkytl. Zjistili jsme, že i kdyby varování
vydal, zůstalo by nevyslyšeno. Systém pro správu byl (špatně) nastaven tak, že
naslouchal pouze varovným zprávám pocházejícím z hlavního adresářového serveru
a systému pro load balancing. Za úrovní systému vyvažování zátěže neviděl nic.

Zamlženým sklem
Administrátoři často zmírňují nastavené prahy alarmů u systémů pro správu tak,
aby odesílaly méně upozornění. Než tedy začnete dělat cokoliv jiného, je třeba
obnovit defaultní nastavení a vyladit je na realističtější prahy citlivosti,
což znamená, že po určitou dobu budete zaplaveni varovnými zprávami.
A pokud se domníváte, že být bombardován nadbytkem informací je nedokonalý
proces, pak věřte, že je pořád radostnější v porovnání se stavem, kdy nemáte
informace žádné. Systém pro správu vyladěný pro "tiché" fungování je skvělým
zdrojem klidu, ale jedná se o falešné pohodlí. Tyto systémy jednoduše nevědí o
stavu některých součástí celého firemního řešení. Je proto nutné propojit tyto
neviditelné položky s vaším systémem správy nebo najít nějaký jiný způsob, jak
jejich stav sledovat. Pouhé prohledávání konzole kdykoliv, když si uživatel
postěžuje, není vždy efektivním řešením.
Většina podnikových produktů je pro potřeby správy dobře vybavena. Ale ne
všechno odpovídá podnikovým standardům. Produkty navržené pro využití v malých
a středních firmách nejsou předem nastaveny pro nezávislou správu. Firmy se
dvěma směrovači a osmi servery zřejmě nesáhnou po řešení typu OpenView. Firma
podobné velikosti bude pro vyladění využívat telnet, X Window nebo terminálové
služby. V současné době lze prakticky vše spravovat z prostředí webového
prohlížeče, ale každé zařízení má svůj vlastní styl rozhraní.
Ještě jsem neviděl směrovač nebo spravovaný přepínač, a to dokonce i v cenové
relaci koncových uživatelů, který by postrádal základní SNMP funkce. Pokud dané
zařízení nelze na dálku spravovat defaultně, pak jej lze pravděpodobně nastavit
tak, aby mohlo být monitorováno vašimi systémy pro správu, nebo jej dokonce s
jejich pomocí nastavovat. Při nedostatečném či žádném podávání reportů odhalíte
problémy až tehdy, když jsou dostatečně závažné na to, aby ovlivnily k nim
připojené zařízení, které je monitorováno. V té chvíli již může být zjištění
skutečného původu potíží velmi obtížné.
Samostatně se řídící či lokálně spravované systémy a software (sledují samy
sebe a někdy se sledují navzájem) jsou také potenciálním zdrojem problémů. Tyto
nástroje odvádějí skvěle svou práci při náhradě vadných systémů a periferií
novými, ale nejsou příliš nápomocné v případě kumulativních potíží, které
postupně vedou k selhání. Ve skutečnosti se podobné systémy často za/přepnou v
případě, že některé zařízení přestane odpovídat na ping nebo odesílat v
pravidelných intervalech heartbeat (tj. provádět nějakou periodickou akci). To
znamená, že při selhání dostanete rychlou odezvu, ale odhalení příčiny zůstává
na vás.
Existuje přitom bezpočet možných důvodů, proč nedostanete odpověď na ping nebo
není odeslán heartbeat. Nejde-li o vyhořelý zdroj nebo přerušené síťové
připojení, může za to být zodpovědná řada záhadných okolností či jejich
kombinace. Záhadu vyřešíte povolením veškerého logování a všech varování, která
systém dovoluje. Jakmile se to stane zavedeným zvykem, naučíte se odhalovat a
napravovat kumulativní problémy, které vedou k fail-overu (tj. přepojení).

Nejasné světlo lepší než žádné
Problematické jsou neprůhledné aplikace, které se hlásí "zeleným světlem",
pokud běží, zatímco v případě selhání nebo restartu neřeknou nic. Existují
pouze dva způsoby, jak podobný software sledovat: chovat se jako klient nebo
použít nástroj na úrovni operačního systému.
Simulování klienta je krok o úroveň vyšší než jednoduchý heartbeat typu "živý,
nebo mrtvý". Například pokud chcete mít pod dohledem poštovní službu, která
postrádá vhodné rozhraní pro monitorování, můžete využít rozhraní nástroje nebo
systému pro správu, který pravidelně vyžaduje připojení k dané poštovní službě.
Podobné základní testy považuji za nedostatečné, protože nedokáží
diagnostikovat méně nápadné potíže. Namísto základního testu požadavek/přijetí
požadavku v rámci dané služby je lépe využít simulovaných klientů, kteří
provedou typickou transakci a umožní ověřit její úspěšné dokončení. Každý
takový test poskytne informace o aktuálním stavu služby, a pokud dojde k jeho
zhoršení, záznamy periodických testů vám poskytnou informace, které mohou
nabídnout výchozí bod pro zahájení diagnostiky. Narostla časová odchylka mezi
odesláním a doručením? Vyskytla se sporadická selhání při doručení? Pokud si
prohlédnete rozšířené hlavičky zpráv, vidíte něco neobvyklého?

V operačním systému
Neexistuje-li žádný praktický způsob, jak sledovat danou aplikaci, nejlepší
alternativou je sledovat operační systém pod ní, tj. na němž běží. Nejznámějším
nástrojem pro monitorování operačního systému Windows je pravděpodobně
Performance Monitor od Microsoftu, a ten byste měli využívat často, ne-li
nepřetržitě na všech Windows serverech, které používáte.
Nelze vyjmenovat všechny způsoby, jimiž lze sledovat, zaznamenávat události a
diagnostikovat Unix. Součástí každého unixového jádra je mapa symbolů, v nímž
jsou uvedeny názvy a umístění příslušných nastavení a statistik týkajících se
běžících systémů. Existují pravděpodobně stovky nástrojů, které tato data
shromažďují a analyzují. Některý z nich byste měli využít.
Sledování statistik na úrovní operačního systému má jen jeden háček: Musíte
zjistit, co hledáte. Hlavní statistiky, jako je využití paměti nebo chyby sítě,
jsou samozřejmostí. Naučte se procházet statistiky na detailnější úrovni, pokud
ty obecnější naznačují problém.

Kontrolujte svoje logy
Neexistoval a možná ani nebude existovat automatizovaný nástroj, který by zcela
nahradil logy a pár vycvičených očí. Prozkoumání těchto záznamů je vždy poučné.
Při prohlížení logů je například možné identifikovat systémy se zablokovanou
pamětí (chipkill), neustále narůstající počet měkkých (tedy opravených) chyb
disku či SCSI sběrnice, které k zachování stability musely snížit svou
rychlost. Procházení logů by mělo patřit mezi pravidelné činnosti vás nebo vámi
pověřeného zaměstnance. Dá se pochopit, že zřejmě nejdříve vyzkoušíte všechno
ostatní.
Ale přesto může být nejlepším způsobem k odhalení drobných mezer ve fungování
vašeho IT textový editor. Využívání textového editoru by se mělo stát součástí
praktik zaměřených na odhalení drobnějších, snadno napravitelných problémů
ještě dříve, než přerostou v problémy velké.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.