Monitoring eduroam.cz je zajištován ze serveru monitoring.eduroam.cz. Jádro monitorovacího systému je realizováno pomocí nagiosu.
Na základě předchozích zkušeností 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.
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ý stroj. Tento stroj je nezávislý na eduroam infrastruktuře a s jednotlivými RADIUS servery organizací zapojenými do eduroamu komunikuje přímo. Stroj, na kterém je monitoring provozován, vystupuje v podstatě v roli dalšího Access Pointu (klienta). 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 end2end monitoring. Dříve, když bylo méně připojených institucí, bylo testování nastaveno v režimu každý s každým, tento přístup mohl umožnit kompletní test všech a generovat kompletní přehledovou matici. S narůstajícím počtem připojených organizací jsme museli z toho režimu ustoupit a vybrat k testování pouze vybranou skupinou institucí.
Výhodou 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.
Pokud není váš RADIUS a realm v seznamu mezi testovanými v monitoringu, zkontrolujte jestli je váš RADIUS aktivovaný v administrativní aplikaci.
Nevýhodou způsobu monitorování každého s každým bylo, že systém generoval 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 vybraných serverů a seznam vybraných testovacích účtů, a tento výběr testuje na všech institucích.
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 vybraných monitorovaných RADIUS serverů. |
| TA | Počet vybraných testovacích účtů (test account). |
Zátěž celé infrastruktury závisí na počtu zapojených organizací. Dalším faktorem je frekvence testů, ale ta je nějak stanovená a není přímo žádoucí, aby se měnila kvůli včasnému podchycení problému.
Celkový počet testů se dá odvodit jako součet (TA * počet připojených) a (počet připojených * RS).
| TA=20, RS=30 | TA=50, RS=75 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| počet připojených organizací | 100 | 250 | 500 | 750 | 1000 | 100 | 250 | 500 | 750 | 1000 |
| celkový počet testů | 5 000 | 7 500 | 15 000 | 22 500 | 30 000 | 12 500 | 31 250 | 62 500 | 93 750 | 125 000 |
Celkový počet testů ve spodním řádku představuje absolutní počet vyřízených dotazů za dobu frekvence testů. 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í.
Z čísel je tedy vidět, že pro koncové servery není monitoring žádným rizikem.
Výše uvedené má zásadní podmínku v tom, že testování musí být v čase rovnoměrně rozprostřeno.
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 icinga tyto služby vizualizuje.
Při rozkliknutí konkrétní služby se dostaneme na detailní informace. Last check 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 icinga stále zobrazuje poslední známý stav služby, který bude typicky delší než frekvence testu.
V záložce History v detailu služby je zobrazena kompletní historie stavů služby včetně poslední změny stavu. Z poslední změny stavu lze odvodit, jak dlouho je daná služba v současném stavu.
.cz-f který zajistí že Access-Request je větší než 1500B, tj. k fragmentaci UDP paketu. Navíc se testuje s účtem big-test@cesnet.cz s velkým Access-Acceptem který opět zajistí fragmentaci UDP paketu.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.
Servery jsou seskupeny podle realmu registrovaného v administrativní aplikaci.
Služby jsou seskupeny podle svého názvu.
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