(Jsem ve střetu zájmů: tento obor mě živí.)
Děkuji M. za zmínku o značce Meinberg :-) Mimochodem ten Geode na 500 MHz zvládne bez autentikace zodpovědět 10k NTP transakcí za sekundu. Slušně vychovaný NTP klient se ptá jednou za desítky sekund až jednotky minut (pseudonáhodný interval). Takže spíš stovky tisíc slušně vychovaných klientů. Ale jak M. a další správně píšou, zdaleka ne všichni NTP klienti jsou zdvořilí a inteligentní.
Geode má tu výhodu, že jak CPU tak zbytek čipsetu (sběrnice) jsou jednoduché jako koloběžka = má to krátké a deterministické latence, což je optimální podvozek, pokud Vám jde o přesnost, minimální jitter. Ntpd běžící na Geodovi s kvalitní GPSkou vidí jitter PPS vstupu běžně do 1 mikrosekundy = na hranici toho, co dokáže ntpq vůbec nahlásit. Dnešní výkonnější procesory s košatým stromem PCI-e sběrnic, message-signaled interrupty apod. může mít determinismus latence obsluhy IRQ citelně horší. Jinak se říká, že NTP dokáže za ideálních podmínek (nezatížený Ethernet, Linux a v něm plnohodnotný ntpd na klientu i serveru) dosáhnout přesnost cca 20-50 us.
Popravdě zmínku, že někdo zkouší load-balancovat NTP nějakým generickým "content switchem", to slyším prvně :-) U NTP jde o časování (minimální jitter, minimální rozptyl round-trip zpoždění) a u jednotlivé NTP asociace může mít smysl, aby transakce po sobě jdoucí se ptaly vždycky téhož upstream serveru. Pokud se totiž servery v clusteru trochu rozejdou, a ten balancing je per transaction (nikoli per NTP "session") tak to bude z klienta vypadat, jako že syntetický balancovaný server má hrozný jitter. Pravda je, že u load-balanced clusteru bych předpokládal, že servery budou mít mizivý vzájemný offset, protože budou někde pohromadě a budou mít optimálně shodný upstream zdroj...
Máte-li v síti nějaké NTP klienty, kteří jsou tupí a nevychovaní, a máte důvodné obavy, že by mohli vymazlené rádiem řízené servery na stratu 1 poslat za určitých okolností do kolen, není nic jednoduššího, než vyrobit pro ně 1-2 nebo více serverů na stratu 2. Linux, ntpd nebo Chrony (podle osobní libosti), pár řádek v konfiguraci, hotovo. Pokud pro stratum 2 použijete nějaké trochu výkonnější železo než je Geode, tak tyhle servery budou mít i lepší šanci ustát "DoS příval" než Geode nebo ARM apod. v rádiem-řízeném serveru. Kromě toho na "Meinberga" už případný "zombie útok zvlčilých SNTP klientů" především vůbec nedoputuje, což je hlavní cíl. Vanilkový ntpd tuším dodnes jede v jediném vlákně (a není úplně trivka to rozložit na víc jader) takže nemá smysl postavit na tuhle pozici 12jádrový Xeon. Ale ono i Core2Duo nebo nějaký moderní BayTrail ATOM tomu Geode natrhnou tričko (za cenu vyššího topného výkonu, pochopitelně).
Mimochodem Meinbergové dokázali to rozvláknění nějak pořešit po svém - prodávají nějaký vcelku béžový 1U server se svým vlastním Linuxem, který zvládne snad 320k Tps (80k jedním vláknem) a servíruje to softwarově. Kromě toho mají Meinbergové modul PTP grandmasteru s FPGA implementací PTPv2 nebo NTP - tenhle modul zvládne hardwarově odpovědět taky na cca 300k NTP Tps, při spotřebě asi 5W a při přesnosti časových značek někde v desítkách ns (dáno přesností GPS přijímače, který tomu dodává referenci = PPS a 10 MHz). Má to nějaké další technické nuance, každopádně cenovky jsou lehce astronomické.
Zpátky na zem. Tzn. nejlepší "NTP balancer" je IMO dedicated serveřík pro stratum 2 s Linuxem (nebo jestli má někdo radši BSD, vyjde to asi podobně). Nebo servery dva, aby se vzájemně zálohovaly. A nepotřebují mít mnoho jader.
Nabízí se nápad, vyrobit to stratum 2 ve virtuálu - tohle se už tuším tady probíralo, že tradičně NTP ve virtuálu je hřích, ale novější informace říkají, že už to v nových verzích hypervizorů není taková hrůza jako bývala. Osobně bych doporučil vyhradit "NTP virtuálu" celé CPU jádro, pokud už se tím chcete zabývat. A jako guest OS (nebo na holém železe) pro běh ntpd/Chronyho každopádně nějaký Linux. Jestli si pak ještě zkusíte hrát s podporou high-resolution timerů (nevím zda to pro ntpd má smysl) nebo zkusíte real-time kernel, to už je čistě na Vašem vkusu a zálibách. Ale i běžné distribuční jádro poskytne rozumnou službu.
Někdo taky provozuje stratum 2 na páteřních switchích LAN (větší Cisco apod.) - je asi věcí posouzení rizika, jestli to neohrozí management CPU přetížením.
Pokud nechcete dobročinně servírovat NTP do divokého internetu, tak v běžné firmě nebudete mít v síti pohromadě tolik klientů, aby položili třeba jenom toho Geode. Nějaké příhody z natáčení by se našly, když to výrobce SNTP klientů nevzal za správný konec... ale nemá cenu vláčet tyhle případy veřejně blátem. Tyhle historky slýchám i přímo od výrobců klientských krabiček a to v tom smyslu, že si z incidentu vzali správné ponaučení.
Meinbergovic proprietární NTP "cluster" (pro hloupé klienty, kteří umí v konfiguraci jenom 1 upstream NTP server) funguje do jisté míry analogicky jako HSRP/VRRP = servery si navzájem půjčují IP adresu (patrně nikoli MAC adresu). Ovšem aktivní je vždy pouze jeden Meinberg v clusteru. Tzn. pro rozkládání zátěže to použitelné není.
Tik a Tak u Cesnetu bývali tradičně hodně vytížení. Asi bych nedoporučoval, obracet se na ně přímo. Použijte třeba 5 aliasů z pool.ntp.org a on už si to Váš ntpd přebere.
V tom výpisu "ntpq -p" mě reach=377 nijak nešokuje,
to vypadá dobře. Reach je octal bitmaska posledních pár pokusů (NTP transakcí) proti dotyčnému upstream serveru. Spíš mě tam šokuje jitter 140 ms. Z pool.ntp.org běžně dostanu některý server se stabilním jitterem a ofsetem v nízkých jednotkách ms.
Plnohodnotný ntpd (nebo Chrony) si skutečně vybírá server nebo
malou skupinku serverů s navzájem blízkým ofsetem a co nejnižším rozptylem (jitterem). Takže pokud klientovi/klientům nebo "svému NTP serveru" nakonfigurujete větší počet upstream NTP serverů, dojde automaticky k rozložení zátěže mezi upstream servery i na té bázi, že přetížené servery mají horší jitter a z "volby" vypadnou jako první. Zátěž bude nakonec směřována přednostně na méně vytížené upstream stroje.
Druhou fajn vlastností plnohodnotné implementace NTP je, jak již zmíněno, detekce a
odmítnutí lhářů (falsetickers) - viz obrázek s titulkem "intersection interval". Jde o svého druhu algoritmus pro shlukovou analýzu na bázi konsezu kvóra a "outlier rejection". Věc jde dokonce tak daleko, že pokud přímo na serveru s GPS přijímačem dáte "refclock driveru" direktivu "prefer", aby "vžycky zvítězil", tak pokud vedle refclock driveru uvedete v konfiguraci také pár upstream NTP serverů z divokého internetu,
mohou ve "volbě" vytěsnit refclock driver včetně jeho "prefer" přídomku jakožto falsetickera, pokud se svým názorem na přesný čas zůstane osamocen (viz poslední odstavec v kapitole 5 na uvedeném odkazu).
Pokud budete někdy řešit nějakou redundantní NTP topologii uvnitř rozsáhlejší sítě, doporučuji držet se striktní hierarchie klient/server (master/slave). On ntpd umí nakonfigurovat i "peer to peer" asociaci, ale některé praktické zkušenosti říkají, že není radno konfigurovat to "do kruhu", kromě toho se pak taková konfigurace chová dost "automagicky" i na poměry ntp algoritmů. Striktní hierarchie je jistota.
Naopak pokud budete mít v lokální síti několik kvalitních rádiem řízených zdrojů, a budete o stratum níž pozorovat "clock hopping", tak vězte, že to ničemu nevadí.
Holé minimum (počet upstream serverů) pro outlier rejection (detekci manipulace) je patrně 3. Pokud máte v lokální síti 3 rádiem řízené NTP servery, mělo by to stačit. Podotýkám, že samotný GPS přijímač dokáže samozřejmě detekovat a přes NTP dál předávat chybové stavy, jako je ztráta příjmu z družic nebo hrubý pokus o manipulaci. A pokud by se nakonec někomu povedlo, přijímač GPS zmanipulovat ke skokové změně hlášeného času, tak se vzápětí sám vypne ntpd (nebo se vykašle na dotyčný refclock driver, pokud má nakonfigurované další upstream zdroje), protože ntpd si toho skoku taky všimne a považuje ho za vážnou chybu.
Zpět k tématu: pokud jde o "minimální počet pro outlier rejection"... servery z divokého internetu bývají na štíru s dostupností, takže má smysl požadovat 4 nebo víc upstream serverů. Lichý počet je možná teoreticky lepší, aby nemohlo dojít k "patu" - ale on skutečný počet upstream NTP asociací bude beztak po svém vandrovat mezi sudými a lichými čísly podle reálné dostupnosti nakonfigurovaných serverů, a v NTP poolu je zřejmě dost serverů s poměrně mizerným round-tripem a jitterem. Výpis ntpq na stroji, který bere čas z divokého internetu, je obvykle mnohem barvitější a zajímavější, než výpis ntpq v síti s několika lokálními rádiovými zdroji (v ntpq skoro samé nuly).
Ohledně PTPv2... ano připomíná to legendu o babylonské věži. Jednomu vendorovi PTP klientů (a třeba switchů) se konfigurací grandmastera ještě přizpůsobíte, ale v multi-vendor heterogenních sítích může být těžké najít společného jmenovatele.
Mimochodem na takové to domácí žvýkání PTPv2 doporučuji linuxptp a hardware i210 ev. i350 - případně může být zajímavé pohrát si s PPS vstupem nebo výstupem na GPIO pinech i210. Případně zavěsit jeho 25MHz krystal na vnější kvalitní referenci (GPS, Rubidium apod). Pokud pro to máte využití (vedle PTP třeba capturing provozu s přesnými časovými značkami - rozlišení v ns) tak si užijete třeba i dost zábavy.
39 Odpovědí
11075 Zhlédnutí