Jiří Chudoba: Gridové služby a IPv6
Jiří Chudoba z fyzikálního ústavu Akademie věd ČR začal nejdříve obecně o superpočítačích: Velké urychlovače v CERNu generují velké datové toky, to nás vede k potřebě velké informatické infrastruktury.
Tak vznikla EGI, což je celoevropská federace poskytovatelů gridů. CESNET v této iniciativě tvoří tzv. národní grid. V EGI je jsou zapojeny stovky výpočetních center z 56 zemí a obsluhuje 270 000 jader CPU, 140 petabajtů diskového prostoru a podobné množství prostoru na páskách.
Největší grid v ČR je na právě Fyzikálním ústavu AV ČR – celkem 3860 jader CPU a 1,8 PB diskového prostoru. Motivace pro zavádění IPv6 byla trochu jiná, než třeba u nově budovaného gridu v Bosně a Hercegovině, kde IPv4 adresy jednoduše nejsou. My sice máme hodně výpočetních serverů, ale ty jsou všechny v privátní síti a veřejně dostupnou adresu nepotřebují. Máme ale datové servery, které veřejnou adresu potřebují, aby uživatelé zvenčí mohli k datům přistupovat.
To způsobovalo problémy, protože veškerá komunikace mezi výpočetními a datovými servery musela procházet centrálním směrovačem, který až čtyřicetigigabitové špičky těžko zvládal. Zatím jsme přijali řešení, že datové servery jsou připojeny jak k privátní, tak k veřejné síti a výpočetní servery k ním mají statický záznam ve směrovací tabulce, takže provoz prochází pouze switchem,
popsal detaily technického řešení Chudoba.
Zavedení IPv6 však také není bez problémů, přestože v rámci EGI funguje pracovní skupina IPv6 už několik let. Typickým problémem je automatická konfigurace IP adres serverů: Ve velkém středisku potřebujeme pevné IP adresy pro každý server. Manuální konfigurace by byla v tak velkém objemu problematická, stejně tak bezestavová autokonfigurace, která by například neumožnila výměnu síťové karty.
Byla proto zvolena metoda přidělování adres pomocí DHCPv6, kde se klient představí unikátním identifikátorem DUID. Tam je zase problém, že je více možností, jak DUID vygenerovat. Nakonec jsme skončili na možnosti DUID-LL.
Jednotlivé servery se tedy identifikují pouze svou MAC adresou.
Další problém představuje automatická instalace serveru pomocí PXE. Neexistuje totiž implementace PXE pro IPv6, a i kdyby existovala, není přesně jasné, jak se bude chovat vzhledem k DHCPv6 serveru, neboť DUID v podobě souboru uloženého na disku není pro PXE přístupný. Proto instalují servery z privátní IPv4 sítě a teprve po instalaci je IPv4 vypnuto a servery používají jen IPv6 adresu.
Naopak bez větších problémů fungovaly dohledové služby jako Nagios, MRTG, syslog či netflow. Závěrem Jiří Chudoba konstatoval, že přestože mnoho komponent běží dobře na IPv6, stále se gridové služby bez IPv4 neobejdou.
Vladimír Veselý: LISP – nová směrovací architektura
V další přednášce Vladimír Veselý z FIT VUT v Brně představil nový protokol LISP, který má řešit některé problémy současného internetu. V současné době je IP adresa jak identifikátorem koncového bodu, tak i lokátorem. Adresování tedy odráží síťovou topologii. To fungovalo dobře před 20 lety, dnes máme požadavky jako mobilitu uživatele nebo multihoming, což dnes bez BGP není možné. Při přechodu od jednoho providera ke druhému dnes obvykle musíme přečíslovávat, chceme-li multihoming, potřebujeme vlastní IP adresy a BGP.
Tím se štěpí adresní rozsahy a narůstá počet záznamů v Default-free zone.
Cílem protokolu LISP je oddělit lokační a identifikační funkci IP adres. Dělá to tak, že rozděluje adresní prostor na dva oddělené IP prostory. První z nich, zvaný Endpoint Identifier (EID) slouží pouze k identifikaci a jsou do něj připojené koncové body (tedy servery a klienti). Síť směrovačů pak používá adresní prostor Routing Locator (RLOC), kde IP adresa slouží pouze pro lokalizaci. Celý protokol funguje na principu zapouzdřování. Paket je vytvořen v EID prostoru se zdrojovým a cílovým EID identifikátorem, přičemž jako EID je možné použít IPv4 nebo IPv6 adresy. Pokud cílový EID nepatří do stejného EID prostoru jako zdrojový, je doručen na hraniční směrovač oblasti, který vykonává funkci Ingress Tunnel Router (ITR). Tam se IP hlavičkám předřadí LISP hlavička a celé se to zapouzdří do UDP protokolu (to pro snadný průchod NATy a firewally) s IPv4 nebo IPv6 hlavičkou s RLOC adresami. V RLOC prostoru se paket doručí na Egress Tunnel Router (ETR) cílového EID prostoru, který vnější hlavičky odstraní a doručí paket koncovému zařízení. Protokol LISP je zcela nezávislý na typu adres v RLOC a EID prostoru, takže je možno na jejich místě použít všechny čtyři možné kombinace IPv4 a IPv6.
Aby takováto síť mohla fungovat, musí mít směrovač ITR ve své paměti map-cache uloženo, jakou adresu má ETR pro daný EID prostor. Pro dané EID tam může být více záznamů s různou prioritou, tím se řeší záloha, nebo i se stejnou prioritou, pak dochází k rozložení zátěže. K naplnění této paměti se používá postup analogický k DNS, kdy se ITR ptá Map resolveru na to, prostřednictvím které RLOC adresy je možné se spojit s danou EID adresou. Resolver tento dotaz doručí až na Map server, kterému ETR směrovače hlásí, jakou mají adresu a jaké EID adresy jsou jejich prostřednictvím dostupné.
Vladimír Veselý také uvedl několik příkladů, kde se může LISP hodit. Typický příklad pro multihoming je mobilní telefon. Ten má dvě síťová rozhraní – WiFi a 3G a v současné době používá vždy jen jedno z nich. Takovému zařízení, místo aby používalo IP adresu jako identifikátor i lokátor, bude přidělen unikátní EID identifikátor a jako RLOC budou vnímány adresy jednotlivých síťových rozhraní. Takže zařízení bude moci komunikovat zároveň pomocí 3G i WiFi,
vysvětlil Veselý a dodal, že LISP byl také úspěšně nasazen v Koreji a Japonsku jako náhrada přechodového mechanizmu pro IPv6.
Beta síť LISPu běží několik let přibližně ve třiceti zemích na několika stovkách míst. Pro EID používá vyhrazené adresy z rozsahů 153.16.0.0/16 a 2610:00d0::/32. Protokol je implementován jak v zařízeních Cisco, tak i v softwarových směrovačích na bázi Linuxu a FreeBSD.
Martin Straka: DNSSEC validátor
Martin Straka z laboratoří CZ.NIC nejprve v rychlosti vysvětlil hrozbu podvodného přesměrování, proti které DNSSEC pomáhá bojovat. Poté byl představen DNSSEC validátor, doplněk pro internetové prohlížeče, který dokáže vizualizovat stav DNSSECu pro danou doménu, včetně neexistujících. Celé jádro doplňku je napsáno v jazyce C, nezávisle na interních funkcích prohlížeče. Stav se pak zobrazuje pomocí barevných klíčků v adresním řádku, nebo v případě Internet Exploreru na nástrojové liště.
V současné době existují dvě verze validátoru. Ta první je založena na knihovně ldns a namísto validace spoléhá na příznak AD od rekurzivního resolveru. Verze pro Firefox, Chrome a Internet Explorer se liší vzhledem i funkčností, finální je pouze ta pro Firefox. U ostatních chybí cache nebo kontrola IP adresy, na kterou se prohlížeč připojil.
Představená druhá verze doplňku má zmíněné nedostatky odstranit. Na rozdíl od předchozí je založena na knihovně libunbound a namísto důvěry v příznak AD provádí skutečné ověření pravosti podpisů. Dokáže se chovat i jako rekurzivní resolver, takže může fungovat i když skutečný DNS server DNSSEC nepodporuje. Doplněk opět podporuje Firefox, IE a Chrome, a podpora by měla být ve všech třech prohlížečích rovnocenná. Stejně tak je ve všech třech prohlížečích implementována kontrola, zda se prohlížeč skutečně připojuje na tu adresu, kterou validátor validuje.
Závěr patřil budoucnosti projektu: Chtěli bychom do budoucna do validátoru přidat podporu pro protokol DANE. Zvažujeme také podporu pro mobilní platformy, nebo více prohlížečů. Neměl by být problém doplněk připojit i k prohlížečům Safari, Opera, nebo SeaMonkey,
dokončil svou přednášku Martin Straka.
Bedřich Košata: DSCng – moderní systém pro monitorování DNS provozu
V dalším příspěvku laboratoří CZ.NIC byl představen systém DSCng. Pokud provozujete DNS servery a zajímáte se, co se na nich děje, pravděpodobně používáte nástroj DSC. Ten byl vytvořen před mnoha lety pod BSD licencí, ale dlouho nebyl udržován a jeho vlastnictví bylo v roce 2011 předáno sdružení DNS-OARC, kterého je CZ.NIC členem. Rozhodli jsme se, že by bylo dobré s tím systémem něco provést,
začal svou přednášku Bedřich Košata. Systém DSC se skládá ze dvou základních komponent. První je sběrač (collector), který je umístěn v blízkosti DNS serverů a sbírá pomocí knihovny pcap DNS data, která agreguje a každou minutu posílá druhé komponentě, předvaděči (presenter). Ten sbírá data od sběračů, dále je zpracovává a ukládá na disk v podobě textových souborů. S nimi pak pracují CGI/Perl skripty, které renderují HTML stránky s PNG obrázky a umožňují data procházet.
Rozhodli jsme se, že v současné době se vůbec nebudeme věnovat sběrači, ten funguje relativně dobře a splňuje naše očekávání. Spíše se snažíme vylepšit uživatelské rozhraní předvaděče,
popisuje Košata koncepci nového systému DSCng. Nový předvaděč by měl v souladu s moderními trendy používat HTML5 a Javascript, vytvářet interaktivně grafy na straně klienta a umožnit propojení s jinými nástroji pomocí API. Stávající DSC je hodně zaměřeno na aktuální provoz. Není problém získat data za aktuální hodinu, den či týden. Když chcete vidět jeden měsíc, už si musíte chviličku počkat a chcete-li cokoli delšího, narazíte na limit programu.
Pro vývoj nového předvaděče byl použit pythonový webový framework Django, data jsou namísto textových souborů uložena v databázi PostgreSQL. Největší problém, který bylo potřeba vyřešit, je samotná velikost dat. Desítky serverů nám za 5 let vygenerovaly cca. 20 GB textových souborů. Když se ta data nahrají do databáze, vznikne při našem současném způsobu ukládání asi 50 GB velká databáze. Když jsme to zkoušeli trochu naivnějším způsobem, dostali jsme se asi na 250 GB. Když pak potřebujete z takhle velké databáze vykreslit například graf provozu za 5 let, trvalo by to velmi dlouho a klient by dostal zbytečně mnoho dat.
Z těchto důvodů do databáze ukládají předgenerované agregované hodnoty. Podle toho, jak velkou úroveň přiblížení uživatel zvolí, je optimálně i zvolena agregovaná hodnota z databáze tak, aby klient dostal vždy přibližně tisíc hodnot, protože víc hodnot stejně v grafu není možné zobrazit.
Na závěr Bedřich Košata vyzval uživatele systému DSC k vyzkoušení DSCng, i když v tuto chvíli negarantuje, že v průběhu vývoje nedojde ke změně struktury databáze. Jakmile budeme mít stabilní vydání, počítáme s tím, že budeme dodávat skripty pro změnu struktury. V současné době při změně vždy celou databázi vymažeme a naimportujeme znovu z původních DSC dat.
(Foto Jiří Průša, CZ.NIC)
ČLÁNKY DO MAILU