Na základě zkušeností s zaváděním eduroamu jsme dospěli k závěru, že monitoring postavený jen na kontrole stavu jednotlivých RADIUS serverů není dostatečný. Docházelo totiž k případům, kdy chyba v konfiguraci na některé z organizaci vedla k tomu, že se návštěvníci nemohli získat přístup k síti ale monitoring nás na toto neupozornil předem.
Ideální by asi bylo mít možnost instalovat do každé připojené instituce počítač s WiFi kartou a příslušným softwarovým vybavením. To by ale bylo dosti nákladné a administrativně jen velmi obtížně realizovatelné.
CESNETem implementované řešení používá k monitorování jediný k tomuto účelu vyhrazený počítač. Tento počítač je nezávislý na eduroam infrastruktuře a s jednotlivými RADIUS servery organizací zapojenými do eduroamu komunikuje přímo. Počítač, na kterém je monitoring provozován, vystupuje v podstatě v roli dalšího Access Pointu. Proto je nutné, aby měl přístup k RADIUS serveru organizace, který se běžně stará o vyřizování dotazů z AP.
Díky přímému přístupu ke koncovým RADIUS serverům a faktu, že pro testování se používají testovací účty všech zapojených institucí, se jedná o testování každého s každým, tedy o end2end monitoring. Výhodou tohoto monitoringu je kromě získání informací, kde mohou mít návštěvníci z některých institucí problém s přístupem, také to, že nezohledňuje transport dotazů mezi RADIUS serverem hostitelské a domácí instituce. Díky tomu bude tento monitoring použitelný i v případě, že v budoucnu dojde k vyřazení proxy serverů a komunikace mezi zapojenými institucemi bude probíhat přímo.
Nevýhodou tohoto způsobu monitorování je, že systém generuje podstatně vyšší zátěž než jak tomu bylo v minulosti. Zátěž se pochopitelně agreguje na proxy serverech, ale i koncové RADIUS servery organizací musí vyřídit nemalé množství dotazů.
Na obrázku je znázorněna situace z pohledu monitoringu. Pro monitoring není podstatné, že komunikace je realizována prostřednictvím NREN proxy RADIUS serverů. Také není moc podstatné, že některé instituce mají dva RADIUS servery a jiné jen jeden. Hrubě řečeno - monitorující systém má k dispozici seznam serverů a seznam testovacích účtů, testuje každý s každým a nic víc nepotřebuje.
To, že pro monitoring není podstatná znalost zapojení infrastruktury, je zjednodušení, které je přínosné pro výpočet generované zátěže. Implementovaný monitoring pochopitelně bere ohled na zapojení infrastruktury. Ve výpočtu zohledňuji pouze fakt, že dotaz s funkčním testovacím účtem stojí podstatně méně zdrojů, než dotaz s testovacím účtem, jehož domácí RADIUS server neodpovídá. To je dáno tím, že monitoring musí dlouho čekat než vyprší timeouty a RADIUS servery po cestě musí zkoušet opakovat dotazy na protějšek, který neodpovídá.
| RS | Počet monitorovaných RADIUS serverů. |
| TA | Počet testovacích účtů (test account). |
| Ng | Frekvence testování návštěv (guest). |
| Nl | Frekvence testování lokálním účtem. |
| Qm=Ng*(TA-1)+Nl | Počet dotazů, které monitoring pošle přímo RADIUS serveru. |
| Qt=Ng*(TA-1)+Nl+Ng(RS-1) | Celkový počet dotazů, které musí vyřídit RADIUS server organizace. Z toho Nl+Ng(RS-1) dotazů musí odbavit lokální AAI. |
| Qt=Ng*(TA+RS-2)+Nl | Celkový počet dotazů, které musí vyřídit RADIUS server organizace. |
| Qnren=RS*Ng(TA-1) | Počet dotazů, které musí zpracovat NREN RADIUS servery. |
Zátěž celé infrastruktury závisí na počtu zapojených organizací TA, počet RADIUS serverů je odvozen od počtu testovacích účtů: RS=1.5*TA. Ng=2, Nl=12. V časovém intervalu 1 hodiny se cizí účty testují 2x a vlastní (lokální) každých 5min. Po dosazení jsem dostal tato čísla:
| TA=20, RS=30 | TA=50, RS=75 | TA=500, RS=750 | TA=2000, RS=3000 | |||||
|---|---|---|---|---|---|---|---|---|
| server organizace | 108 | 0,03 | 258 | 0,07 | 2 508 | 0,70 | 10 008 | 2,78 |
| NREN servery | 1 140 | 0,32 | 7 350 | 2,04 | 748 500 | 207,92 | 11 994 000 | 3 331,67 |
Čísla v prvním sloupci představují absolutní počet vyřízených dotazů za hodinu, hodnota v druhém sloupci je přepočtena na vteřinu. Je třeba mít na paměti, že množství paketů bude o jeden řád vyšší. V tabulce jsou uvedeny EAP dotazy, což např. v případě PEAP-MSCHAPv2 znamená 10 RADIUS paketů na vyřízení. Chcete-li si s výpočty pohrát, je k dispozici OpenOffice Calc Sheet, který jsem použil.
Z čísel je tedy vidět, že pro koncové servery není monitoring žádným rizikem, problémy se objeví mnohem dříve na NREN RADIUS serverech. Reálné výkonnostní parametry v tento okamžik nemám k dispozici, ale očekávám, že systém je schopen vyřídit alespoň 1000 paketů za vteřinu.
Výše uvedené má zásadní podmínku v tom, že testování musí být v čase rovnoměrně rozprostřeno. To se zhruba daří splnit, jak ukazují grafy počtu testovacích procesů. Další informace o monitoringu jsou k dispozici v samostatném článku.
Na každém serveru organizace je monitorována řada služeb. Jejich význam, závislosti na ostatních službách dalších serverů a vzájemné závislosti jsou popsány dále. Na připojeném obrázku můžete vidět, jak Nagios tyto služby vizualizuje.
Naznačuje, u kterých služeb se neposílá notifikace.
Udává, kdy naposledy byla služba kontrolována. Pokud služba nemá splněnu některou ze závislostí, tak vůbec nejsou spouštěny její testy. Například když není povolen přístup pro ping z monitorovacího systému, tak se netestují žádné služby, ale Nagios stále zobrazuje poslední známý stav služby.
Udává, jak dlouho setrvává služba v HARD stavu. Například služba IPSEC měla poslední zaznamenaný výpadek před 18hodinami. To ale ještě neznamená, že došlo k notifikaci o výpadku. Detailnější informace jsou k dispozici po kliknutí na jméno služby a následně na "View Availability Report For This Service".
Jestliže je organizace připojena k eduroamu prostřednictvím několika serverů, tak se každý server monitoruje nezávisle. Aby bylo možné realizovat některé závislosti, bylo nutné nadefinovat virtuální servery, ty slučují všechny servery organizace v jediný. Služby definované na tomto serveru jsou přesnou kopií služeb na jednotlivých serverech organizací. Logika skrytá za těmito agregovanými službami zajišťuje, že služba přejde do CRITICAL stavu jedině když selžou všechny odpovídající služby na fyzických serverech. V případě, že je některý služba v jiném než OK stavu, má agregovaná služba stav WARNING.
Pro všechny služby na těchto serverech platí:
Původně se vytvářely virtuální servery podle toho, který realm obsluhovaly, to ale vedlo v k tomu, že virtuálních serverů bylo víc než bylo nezbytně nutné a díky tomu bylo i zbytečně mnoho služeb v systému. Používala se jména aggregated.<realm>. Nyní se generují jména virtuálních serverů na základě jmen serverů, ze kterých se virtuální server skládá. Například:
Monitoring monitoruje kromě serverů i systémové servery. Jedná se o
Gateway, zajišťuje připojení monitorovacího systému k Internetu. Každá služba, která můžete vyvolat notifikaci, závisí na GW/PING, což zajišťuje, že monitoring „neobšťastní“ všechny správce po výpadku konektivity monitoringu poštou.
NREN RADIUS servery zodpovědné za transport RADIUS paketů mezi organizacemi v rámci eduroam.cz, ale také zajišťují spojení s toplevel servery eduroamu. Monitorované služby:
Ping z NREN serveru na první, respektive druhý toplevel server.
RADIUS na NREN serveru. Testuje se pomocí lokálního účtu, takže výpadek skutečně znamená výpadek služby RADIUS na tomto serveru.
RADIUS na toplevel serverech. Zatím se testuje jen pomocí účtu v surfnet.nl, takže výpadek těchto služeb nutně nemusí znamenat, že došlo k výpadku národních serverů.
RACOON je daemon zodpovědný za výměnu šifrovacích tajemství pro IPSEC,
čas od času nemá svůj den a dostane se do dead-locku. Oba NREN servery se
samy kontrolují a v případě potřeby tuto službu restartují. Více
informací viz 
odkaz do archivu konference.
Pro snazší orientaci ve značném množství serverů a služeb jsou definovány skupiny, které slučují související objekty a usnadňují navigaci.
Skupiny služeb a serverů sice trochu usnadňují orientaci v množství dat, ale neumožňují vidět aktuální stav sítě najednou. Proto jsem vytvořil na Nagiosu nezávislou matici dostupnosti. V ní jsou na řádcích buď lokality nebo servery organizací a na sloupcích jsou uvedeny jednotlivé realmy. Díky tomu lze na téměř první pohled okamžitě zjistit, kde co nefunguje.
K matici je volný přístup, adresa je https://ermon.cesnet.cz/matrix/.
Jak už jsem zmínil několikrát výše, jádrem celého monitoringu je Nagios. Jeho webové rozhraní je k dispozici na adrese https://ermon.cesnet.cz/nagios/, přístup mají jen uživatelé, kteří mají účet v administrativní aplikaci a jsou správci nějakého realmu.
— Jan Tomášek 19.03.2008 16:25 připsány informace o testech BIG-PACKET a VCELKA-MAJA
— Jan Tomášek 22.06.2006 09:44 napsán text o aktuální implementaci
— Jan Tomášek 14.06.2006 17:34 napsán úvod a teoretický výpočet generované zátěže
CESNET, z. s. p. o.
Generála Píky 26
160 00 Praha 6
info@cesnet.cz
Tel: +420 234 680 222
GSM: +420 602 252 531
support@cesnet.cz
