Dovolím si volně navázat na blogpost kolegy Zdeňka Brůny, který se před časem pokusil přiblížit problematiku generování a podepisování .CZ zóny pomocí lidsky pochopitelné metafory. I já bych rád poodkryl jednu z oblastí správy DNS, tentokrát zdokonalování monitoringu jednotlivých nodů našeho anycastu. Představme si, že provozujeme řetězec obchodů, poboček, a zajímá nás, jestli opravdu zaměstnanci pracují a pobočky mají otevřeno. Kontrolu můžeme dělat interně, tedy aby nám zaměstnanec nebo nějaký systém vždy po určitém intervalu odpovídal. To může zdatnější zaměstnanec nafixlovat, aby to vypadalo, že vše funguje, jak má. Ve skutečnosti ale zaměstnanci budou už doma s nohama na stole. Během toho budou naštvaní zákazníci zlověstně ťukat a lomcovat s dveřmi pobočky a pak psát nerudné komentáře, že je zavřeno, i když má být otevřeno. Ideální řešení by bylo, kdybychom měli někoho, kdo pravidelně půjde, vezme za kliku dveří a zkontroluje, že je otevřeno. Případně zburcuje manažera pobočky nebo nahlásí nefunkční pobočku firmě, která zmíněný řetězec provozuje.
Tento scénář lehce ilustruje naši situaci s DNS anycastem a jeho geograficky vzdálenými lokalitami. Centrálním monitoringem lze částečně kontrolovat, zda na serveru vše lokálně funguje. Částečně z toho důvodu, že kontrola probíhá lokálně. Tedy DNS dotaz na anycast provede monitorovaný DNS server a centrální monitoring se pak ptá na výsledek této kontroly. Takovýto lokální DNS dotaz však neputuje stejnou cestou jako dotaz z Internetu. Interně se tak vše může tvářit v pořádku, ale situace může být reálně docela jiná.
Jak si ale domluvíte lokálního „fachmana“, který bude pravidelně zkoušet funkčnost lokality, když jsou rozesety po celém světě? Tento problém lze vyřešit například pomocí pronájmu virtuálního serveru v blízkosti nodů anycastu. Blízkost je v tomto případě myšlena ta síťová, ne fyzická. Bude-li virtuální server ve stejném datacentru jako DNS nod, je šance, že dotaz půjde přímo do nejbližší lokality, protože je právě síťově blízko. V případě, že to bude jiné datacentrum s jiným IX uzlem a tranzitem a budou upraveny routovací metriky, dotaz pak do místního DNS nodu nemusí vůbec dorazit. Tento problém lze částečně eliminovat pomocí RIPE sond, kterých je velké množství a stačí si pak jen vybrat tu vhodnou. Se sondami už máme zkušenost, protože pomocí nich monitorujeme anycast jako celek.
Sondy z projektu RIPE atlas mimo jiné umožňují posílat pravidelně ping, HTTP nebo právě DNS dotazy na definované nameservery. Po světe jsou rozesety tisíce takových sond, které pro vás za RIPE kredity provedou potřebný dotaz. Vybrat vhodné sondy, specifikovat potřebný dotaz a vytvořit pravidelné měření je pak otázka pár kliknutí ve webovém prohlížeči. Je potřeba říct, že kredity je nejdříve potřeba získat a jedním ze způsobů pravidelného přírůstku je například hostování sondy ve vlastní síti. Možnosti měření, co se týče četnosti nebo počtu sond, jsou limitovány právě počtem dostupných kreditů.
Figure 1: Vytvoření měření pro A anycast v RIPE Atlasu
Vytvořili jsme tedy měření na všechny naše lokality ve světě, kromě tuzemska, a pro každé měření jsme kvůli redundanci využili dvě sondy. Tyto sondy se ptají s příznakem NSID, což je identifikátor jednotlivých DNS serverů, podle kterého kontrolujeme, z jaké lokality sonda dostala odpověď. Redundance sond zajistí, že v případe výpadku nebo změně routingu u jedné z nich, by stále minimálně jedna měla fungovat. Samozřejmě čím víc redundantních sond tím líp. Sondy jsou momentálně nastavené tak, aby se ptaly každých 10 minut. Výstupy měření je možné vidět na stránkách RIPE Atlasu, což ale pro strojové zpracování není úplně vhodné. I na to ale v RIPE mysleli a připravili python knihovny pro získání výstupů měření.
Pokud vás nezajímají technické detaily provedení, přeskočte tento a následující odstavec a pokračujte směle dále. Nástroj je napsán v pythonu a lze ho spustit jako konzolovou nebo webovou (flask) aplikaci. V obou případech načítá dva konfigurační soubory. První popisuje všeobecné nastavení NSID, Hidden Master serveru pro kontrolu SOA a dobu, po jakou je výsledek dotazu validní. Bez kontroly na validitu dotazu by byl brán jako validní i týden starý dotaz s korektním NSID. To se může stát, například pokud sonda přestane fungovat. Druhý je csv soubor, který obsahuje informace o měření (ID měření, název lokality, anycast a HW typ lokality). K získání výsledků těchto měření pak využíváme již zmíněné python knihovny, a to konkrétně RIPE Atlas Cousteau a RIPE Atlas Sagan.
Tyto vstupy obdrží/získá jak webová tak i konzolová aplikace. U konzolové aplikace je možné ještě specifikovat formát výstupu – jestli na výstup chceme stav pouze jedné nebo všech lokalit. Výpisu jedné lokality využíváme pro monitoring, abychom spárovali jednotlivé servery s danou lokalitou a check byl co nejvíce přehledný a jasný. Běh webové aplikace je zajištěn webovým serverem, modulem uwsgi a systemd. Systemd zajišťuje chod uwsgi aplikace, která obdržené dotazy z webového serveru překládá do formátu pro anymon aplikaci a ta následně vrací příslušný výstup v podobě vygenerované html stránky.
Figure 2: Náhled na hlavní stránku Anymonu s plánovaně odstavenou chilskou lokalitou.
Měření RIPE Atlasu a RIPE Atlas python knihovny jsme dali dohromady a vytvořili nástroj Anymon, který zpracuje výstup z měření, porovná NSID dotaz s předpokládaným NSID, zkontroluje časovou validitu a poskytne výstup pro monitoring. Ten pak přes aktivní kontroly pozoruje výstupy OK/FAIL a obstarává notifikace. Kromě toho jsme také vytvořili webové rozhraní s detailními výsledky měření, takže je možné zobrazit verzi protokolu, konfigurace lokality (stack/standalone) atd. Kromě toho jsme využili SOA dotazu, což přes web umožňuje pozorovat, jestli je zóna koherentní. Samotné SOA (případně verzi zóny) standardně kontrolujeme naším interním monitoringem, ale Anymon nám umožňuje kontrolu zvenčí. Od výpadku DNS nodu k odeslání notifikace administrátorům může uběhnout více jak 10 minut. Doba je spjatá s četností dotazování RIPE sondami. Sondy se ptají v pravidelném intervalu a pokud se dotázaly těsně po výpadku, čeká se na další dotaz. Výsledek měření sond je následně zpracován s časovou prodlevou, také je třeba připočíst dobu, než se monitoring dotáže na výstup Anymonu, a následné odeslání notifikace monitoringem.
Díky Anymonu tedy víme, zda jsou naše firemní pobočky opravdu otevřené, mají čerstvé veškeré zboží a nabízí ho zákazníkům. S kontrolou nám pomáhají nezdolní „fachmani“ v podobě RIPE sond. V případě, že na nás pobočka hraje levou, zprostředkují report, a to nejen ohledně stavu otevřeno/zavřeno, ale s veškerými detaily. Samozřejmě místa pro vylepšení tu jsou. Vidíme je rozhodně ve zvýšení četnosti pokládání DNS dotazů a ve větším počtu samostatných sond, respektive více nezávislých kontrolorů chcete-li.