Rychlokurz: Monitorování databázových systémů

Informace do databází nestačí jen uložit, ale je třeba zajistit i optimalizovaný způsob uchování či relevanci dat.

Administrátoři IT systémů se v současnosti musejí vyrovnávat (například z důvodů postupující globalizace a propojování systémů) se vzrůstajícími tlaky na zvýšení spolehlivosti systémů, zkrácení doby odstávek a výpadků, prodloužení doby mezi výpadky či odstávkami, rozšiřování rozsahu zpracování, zpracování většího objemu a nových zdrojů a formátů dat, zrychlení zpracování, využití nových technologií, celopodnikové a celosvětové propojování systémů a zvýšení využití existujících zdrojů (hardwarových, softwarových, operativních, organizačních i lidských), například ve vzrůstání počtu systémů připadajících na jednoho administrátora.

Reakce na tyto tlaky se projevuje v potřebě administrátorů:

• Lépe využívat existující zdroje (tedy znát dostupné zdroje a jejich využití, získat informace o stavu a využití rychle a jednoduše, umět vybrat z množství informací ty důležité, měřit výkonnost systémů, plánovat správu systému, například aktualizací hardwaru a softwaru, či plánovat využití dostupných kapacit).
• Najít lepší cesty řešení problémů (předcházet problémům, respektive výpadkům, přejít od reaktivních postojů k proaktivním, rychle nalézt problematická místa, rychleji řešit problémy).
• Řešit správu komplexně (zvýšit zastupitelnost jak hardwarových, tak lidských zdrojů, snižovat náklady na trénink a zavádění systémů, provádět měření například v rámci dohod o poskytování služeb (SLA), sledovat stav různých systémů z jednoho místa či používat nástroje, které umožní jednoduchou správu systémů).

Tyto problémy a potřeby jsou tím palčivější, čím větší mají dosah, čím více uživatelů se dotýkají nebo čím kritičtějších systémů se týkají. V centru mnoha podnikových systémů se nachází databázový systém, ať už se jedná o transakční nebo server pro datový sklad. Většinou jde o systémy využívající velmi vyspělé technologie zahrnující zajištění vysoké dostupnosti (HA), redundanci hardwaru/softwaru, replikaci nebo distribuované prostředí.

Jedním z hlavních problémů spojených s databázemi je mimo jiné otázka optimalizace fyzického uložení dat v databázi a případný odsun nepoužívaných dat na levnější (vzdálenější) paměťová média.

Specifičtějším důvodem pro sledování transakčních databázových systémů je pak třeba porozumění tomu, zda v databázích nedochází ke konfliktu mezi čtenáři a zapisovateli dat. Pro datové sklady jde o řešení lepšího rozložení nebo uspořádání dotazů a přípravu agregovaných dat spolu se sledováním využití (potřebnosti) existujících dat.

Možnosti sledování
Pokud se zaměříme na databázové systémy, existují v podstatě tři možnosti sledování – využití existujících nativních nástrojů, vývoj vlastních nástrojů nebo použití specializovaných monitorovacích nástrojů.

Každý databázový server poskytuje jako svou součást nástroje pro sledování běhu a výkonu systému, ať již zcela jednoduché nebo sofistikovanější. Nevýhodou je, že část informací se objevuje v okně serveru, část v různých žurnálech (obvykle textových souborech), část lze získat z příkazové konzole příkazy SQL a některé informace jde dokonce získat pouze z operačního systému (zabrané místo na disku, využití paměti a CPU).

V případě prostředí skládajícího se z více databázových serverů různých dodavatelů vzniká problém, že nativní nástroje poskytují různá uživatelská rozhraní, využívají různé technologie a obvykle nejsou spolu schopny komunikovat.

Snaha o spojování informací z různých zdrojů a přesnější zaměření sledování pak vede k vývoji vlastních skriptů nebo nástrojů pro sledování. Toto řešení má zjevné výhody, jako například možnost sledovat právě potřebné parametry, ale podle názoru autora převažují nevýhody (použití pouze pro interní potřebu, nutnost spravování a udržování…). Výsledek pak obvykle naráží na různá omezení v podobě kvality dat, funkcionality, výkonnosti, stability či možností uživatelské spolupráce.

Architektura monitorovacích nástrojů
Většina monitorovacích nástrojů používá jednu ze dvou architektur – buď se jedná o dvouúrovňovou typu klient-server, nebo o tříúrovňovou typu klient-server-agent. Klient zde zastupuje uživatelské rozhraní a má svou vlastní konfiguraci (nastavení sledovaných parametrů). Využití víceúrovňové architektury umožňuje nasazení téměř libovolného počtu klientů bez zvýšení zatížení sledovaných systémů.

Server je odpovědný za komunikaci s klienty, bezpečnostní kontroly, směrování zpráv a komunikaci s dalšími servery. V dvouúrovňové architektuře je zodpovědný i za sběr dat ze sledovaných systémů.

Softwaroví agenti jsou prvky nezávislé na serveru, v rámci jednotlivých sledovaných systémů sbírají data a v určených intervalech je zasílají serveru. Další agenti mohou zodpovídat za udržování historických informací, analýzu získaných dat na základě zadaných pravidel a zasílání výstrah podle požadavku uživatele.

Budoucí vývoj monitorování
Budoucí vývoj v oblasti monitorování pravděpodobně povede ke spolupráci či spojování monitorovacích a řídících systémů (Enterprise Management System) – jedná se například o řešení IBM Tivoli, Hewlett-Packard OpenView či Hughes - a ke spojování s nativními nástroji pro sledování databázových systémů. Je možné očekávat větší přechod od monitorování ke správě zdrojů, schopnosti auditování a přebírání auditovacích informací ze sledovaného systému.

V rámci schopností monitorovacích nástrojů budou brzy zřejmě dostupné funkce automatické predikce vývoje situace, schopnost učení se ze situace a akcí uživatele, aplikace fuzzy logiky, možnosti víceúrovňového monitorování a monitorování procesu monitorování. Pravděpodobné je i využití více forem komunikace, například ICQ, telefonní hovory, hlasové ovládání, rozšíření spolupráce s více reportovacími nástroji a automatický tisk či ukládání reportů – snímkování stavu monitorovaných systémů.

Autor je zaměstnancem firmy Anywhere.

V rozšířené podobě, včetně obrázků a přehledu funkcí monitorovacích nástrojů, lze tento článek najít v tištěném Computerworldu 9/2008.