====== end2end monitoring ======
===== Úvod =====
Na základě zkušeností s zaváděním //eduroam//u 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 //eduroam//u 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.
===== Zátěž generovaná monitoringem =====
{{ :cs:spravce:monitoring:end2end_monitoring:maluvka-pro-vypocet-zateze-monitoringu.png?250|Náčrtek situace s pohledu monitoringu}}
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á.
==== Odvození teoretické zátěže ====
|**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.|
==== Vypočtená teoretická zátěž ====
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
{{:cs:spravce:monitoring:end2end_monitoring:vypocet-zateze-radius-serveru.ods|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í
[[https://ermon.cesnet.cz/HotSaNIC/apps/rad_eap_test.html|grafy
počtu]] testovacích procesů. Další informace o
[[:cs:spravce:monitoring:uvod|monitoringu]]
jsou k dispozici v samostatném článku.
===== Služby monitorované na serverech připojených organizací =====
==== ====
{{ :cs:spravce:monitoring:end2end_monitoring:sluzby_monitorovane_na_serveru_organizace.png?250|Služby monitorované na serveru organizace}}
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.
=== Ikona přeškrtlé trumpetky ===
Naznačuje, u kterých služeb se **ne**posílá notifikace.
=== Sloupec "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 Nagios stále zobrazuje
poslední známý stav služby.
=== Sloupec "Duration" ===
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
[[http://wiki.eduroam.cz/lib/exe/detail.php?id=spravce%3Amonitoring%3Aend2end_monitoring&cache=cache&media=spravce:monitoring:end2end_monitoring:service_availability_report.png|"View
Availability Report For This Service"]].
==== PING ====
* testuje se odpověď na ICMP echo request
* závisí na **gw/PING**
* CRITICAL-HARD stav nastává po **10**ti pokusech, tj. max po 5+9*1=**14 minutách** od výpadku
* normální perioda testování je **5 minut**
* v případě výpadku se testuje každou **1 minutu**
* notifikace se **posílají** správcům serveru a správcům eduroam.cz
==== IPSEC ====
* tato služba je testována jen na RADIUS serverech, které tvoří infrastrukturu a jsou připojeny pomocí IPSEC, není k dispozici u serverů sloužících jen pro monitoring
* testuje se odpověď na ICMP echo request skrz IPSEC tunel
* test se spouští přes vzdálené volání pomocí nrpe na radius1.eduroam.cz
* závisí na:
* **PING**
* **radius1.eduroam.cz/PING**
* **radius1.eduroam.cz/RACOON**
* CRITICAL-HARD stav nastává po **10**ti pokusech, tj. max po 5+9*1=**14 minutách** od výpadku
* normální perioda testování je **5 minut**
* v případě výpadku se testuje každou **1 minutu**
* notifikace se **posílají** správcům serveru a správcům eduroam.cz
==== RADSEC ====
* tato služba je testována jen na RADIUS serverech, které tvoří infrastrukturu a jsou připojeny pomocí RADSEC, není k dispozici u serverů sloužících jen pro monitoring
* testuje zda jsou navázána RADSEC spojení oběma směry
* test se spouští přes vzdálené volání pomocí nrpe na radius1.eduroam.cz
* závisí na:
* **PING**
* **radius1.eduroam.cz/PING**
* CRITICAL-HARD stav nastává po **10**ti pokusech, tj. max po 5+9*1=**14 minutách** od výpadku
* normální perioda testování je **5 minut**
* v případě výpadku se testuje každou **1 minutu**
* notifikace se **posílají** správcům serveru a správcům eduroam.cz
==== BIG-PACKET ====
* test přenosu fragmentovaných UDP paketů
* závisí na **domácím realmu**
* test se provádí s účtem big-packet@cesnet.cz což je specielní účet s velkým Access-Acceptem. Pokud testovaný server zvládne tento paket doručit na ermon, tak to znamená že je schopen přijmnout (z národního RADIUSu) ale i odeslat (na ermon) fragmentový UDP paket.
* CRITICAL/WARNIG-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **12 hodin**
* notifikace se posílají pro CRITICAL (timeout) a WARNING (access-reject) stavy
==== VCELKA-MAJA ====
* test přeposílání vnitřní EAP identity, více viz [[
https://random.cesnet.cz/mailman/private/eduroam-admin/2008-February/000624.html|email v eduroam-admin listu]], [[ http://archiv.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/|technická zpráva]]
* závisí na **domácím realmu**
* CRITICAL-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **12 hodin**
* notifikace se posílají pro CRITICAL (timeout) a WARNING (access-reject) stavy
==== domácí realm ====
* domácí realm je ten, pro který je server koncovým
* domácích realmů může být na jednom serveru definováno několik
* tento test testuje, jestli na serveru **funguje RADIUS** server
* závisí na **PING**
* CRITICAL-HARD stav nastává po **3** pokusech, tj. max po 5+10*(3-1)=**25 minutách** od výpadku
* normální perioda testování je **5 minut**
* v případě výpadku se testuje každých **10 minut**
* notifikace se **posílají** správcům serveru, správcům realmu a správcům eduroam.cz
==== realmy ostatních organizací ====
* tento test simuluje návštěvu uživatele z cizí organizace
* závisí na:
* **PING**, tj. jestli je server živý
* **IPSEC**, tj. jestli má server živé spojení alespoň s jedním RADIUS serverem. Tato podmínka se uplaťnuje, jen když tento server tvoří eduroam.cz infrastrukturu.
* **domácí realm**, tj. jestli na serveru funguje RADIUS
* **domácí server testovaného realmu/testovaný realm**, tj. jestli domácímu serveru příslušnému k tomuto realmu funguje RADIUS
* CRITICAL-HARD stav nastává po **3** pokusech, tj. max po 180+120*(3-1)=**420 minutách = 7 hodinách ** od výpadku
* normální perioda testování je **180 minut**
* v případě výpadku se testuje každých **120 minut**
* notifikace se **ne**posílají
==== CALLING-STATION-ID ====
* test že SP posílá vyplněný RADIUS atribut Calling-Station-Id
* týká se pouze serverů, které jsou napojeny na národni RADIUS přímo
* test je implementován na základě dat z logů národního RADIUS serveru, podklady pro sondu se **aktualizují jednou za hodinu**
* CRITICAL/WARNIG-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **3 hodiny**
* notifikace se neposílají 1x za 2 dny pro CRITICAL stav
==== OPERATOR-NAME ====
* test že SP posílá vyplněný RADIUS atribut Operator-Name, testuje se existence a syntaktická správnost
* týká se pouze serverů, které jsou napojeny na národni RADIUS přímo
* test je implementován na základě dat z logů národního RADIUS serveru, podklady pro sondu se aktualizují **jednou za hodinu**
* CRITICAL/WARNIG-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **3 hodiny**
* notifikace se neposílají 1x za 2 dny pro CRITICAL stav
==== CHARGEABLE-USER-IDENTITY ====
* test že SP posílá vyplněný RADIUS atribut Chargeable-User-Idenity
* test probíhá z CESNETích RADIUS serverů pomocí testovacího účtu organizace
* CRITICAL/WARNIG-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **3 hodiny**
* notifikace se neposílají 1x za 2 dny pro CRITICAL stav
==== FAKE-UID ====
* Test že IdP vynucuje shodu vnější a vnitřní identity. Jako vnější (anonymní) identita se použije anonXXX@realm.cz a jako vnitřní pak testovací účet organizace. IdP takový požadavek na ověření nesmí vyhodnotit pozitivně. IdP které nepodporuje Chargeable-User-Identity nesmí povolit žádnou anonymní identitu (tj. ani anonymous@realm.cz), viz [[https://www.eduroam.cz/cs/roamingova_politika|Technické požadavky a doporučení pro členy federace eduroam.cz]].
* [[https://random.cesnet.cz/mailman/private/eduroam-admin/2016-November/001141.html|více informací]]
* řešení: [[https://www.eduroam.cz/cs/spravce/pripojovani/radius/freeradius2#kontrola_shody_vnejsi_a_vnitrni_eap_identity|FreeRADIUS v2]], [[https://www.eduroam.cz/cs/spravce/pripojovani/radius/freeradius3#kontrola_shody_vnejsi_a_vnitrni_eap_identity|FreeRADIUS v3]]
* test probíhá z ermona
* CRITICAL/WARNIG-HARD nastává po **3** neúspěných pokusech
* normální perioda testování je **24 hodin**
* v případě výpadku se testuje každé **3 hodiny**
* notifikace se posílají 1x za 2 dny pro CRITICAL stav
===== Agregované neboli virtuální servery =====
{{ :spravce:monitoring:end2end_monitoring:sluzby_monitorovane_na_agregovanem_serveru.png?250|Služby monitorované na agregovaném serveru}}
Jestliže je organizace připojena k //eduroam//u 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í:
* CRITICAL-HARD stav nastává po **1** pokusu
* normální perioda testování je **1 minuta**
* v případě výpadku se testuje každou **1 minutu**
* notifikace se **ne**posílají
==== Tvorba jmen virtuálních serverů ====
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.. 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:
* radius.cesnet.cz => radius.cesnet.cz
* radius1.cesnet.cz + radius2.cesnet.cz => radius1_AND_radius2.cesnet.cz
* radius1.cesnet.cz + radius2.cesnet.cz + radius3.cesnet.cz => radius1_AND_radius2_AND_radius3.cesnet.cz
* radius.etest.cesnet.cz + radius.cesnet.cz => radius.etest_AND_radius.cesnet.cz
* radius.cesnet.cz + radius.ces.net => radius.cesnet.cz_AND_radius.ces.net
===== Systémové servery =====
Monitoring monitoruje kromě serverů i systémové servery. Jedná se o
==== GW ====
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.
==== radius1 a radius2.eduroam.cz ====
NREN RADIUS servery zodpovědné za transport RADIUS paketů mezi
organizacemi v rámci //eduroam.cz//, ale také zajišťují spojení s
toplevel servery //eduroam//u. Monitorované služby:
=== PING ===
=== PING-etlr1 a PING-etlr2 ===
Ping z NREN serveru na první, respektive druhý toplevel server.
=== RADIUS ===
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-etlr1 a RADIUS-etlr2 ===
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 ===
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 FIXME odkaz do archivu konference.
===== Skupiny služeb a serverů =====
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 serverů ====
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?hostgroup=gw&style=detail|Gateway]] systémové servery
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?hostgroup=Unsorted+servers&style=detail|Unsorted]] servery, které nepatří do žádné jiné skupiny. Jestliže je server v téhle skupině, téměř jistě není pořádně dokonfigurován.
* semikwin2003s.cesnet.cz je pokusný Win2003 server určený k pokusům s IPsec na Windows.
* cyrus.cesnet.cz slouží pro dočasné napojení IP telefonie k eduroam infrastruktuře
* Everyone at , agreguje servery zodpovědné za určitý realm, například [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?hostgroup=cesnet.cz&style=detail|Everyone at cesnet.cz]]
==== Skupiny služeb ====
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?servicegroup=%40cesnet.cz&style=detail|Realm cesnet.cz at everywhere]] zobrazuje, jak se uživatelé s realmem cesnet.cz budou ověřovat na jednotlivých RADIUS serverech, tj. institucích.
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?servicegroup=IPSEC&style=detail|IPSEC at everywhere]]
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?servicegroup=IPSEC-radius1.eduroam.cz&style=detail|IPSEC-radius1.eduroam.cz at everywhere]]
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?servicegroup=IPSEC-radius2.eduroam.cz&style=detail|IPSEC-radius2.eduroam.cz at everywhere]]
* [[https://ermon.cesnet.cz/nagios/cgi-bin/status.cgi?servicegroup=PING&style=detail|PING at everywhere]]
===== Matice dostupnosti =====
{{ :spravce:monitoring:end2end_monitoring:matice_dostupnosti.png?250|Matice dostupnosti}}
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/]].
===== Nagios =====
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.
====== ======
--- //[[http://staff.cesnet.cz/~semik|Jan Tomášek]] 19.03.2008 16:25// připsány informace o testech BIG-PACKET a VCELKA-MAJA\\
--- //[[http://staff.cesnet.cz/~semik|Jan Tomášek]] 22.06.2006 09:44// napsán text o aktuální implementaci\\
--- //[[http://staff.cesnet.cz/~semik|Jan Tomášek]] 14.06.2006 17:34// napsán úvod a teoretický výpočet generované zátěže