Fórum Root.cz
Hlavní témata => Server => Téma založeno: David1234 09. 01. 2019, 14:44:53
-
Ahoj, schováváte někdo NTP servery (např. stratum 2) za loadbalancery? Co jsem zjišťoval, tak to někteří dělají, já v tom ale vidím pouze spoustu nevýhod. Pokud tomu správně rozumím NTP protokol je navržen dostatečně robustně - počítá s výpadkem některého z NTP serverů a není potřeba řešit pomocí loadbalancingu, popřípadě protokol počítá s tím že některý ze serverů může vracet špatný čas a umí ho označit jako falseticker.
Je balancování NTP serverů hloupý nápad?
-
Pokud to není pro nějaké klienty jediný NTP server, tak je balancování zbytečné.
-
Proc lokalni NTP server?
Bezne staci pool.ntp.org
-
Používám tik.cesnet.cz a tak.cesnet.cz
-
Nechci se spoléhat na zdroje času v internetu, může se stát že pojedeme v "ostrovním režimu". Proto máme 2x HW NTP server s GPS anténou + kombinace s CZ NTP poolem z internetu.
Dále jsem zjistil že mít nakonfigurované pouze 2 NTP servery (viz tik a tak.cesnet.cz) není dobrý nápad. Pokud každý z nich vrací špatný čas, jak ntpd pozná který je špatný? Nepozná. Oba je hodí do falseticker stavu. RHEL doporučuje konfigurovat minimálně 4 NTP servery.
-
Podle mne je balancování NTP serverů loadbalancerem hodně špatný nápad, protože protokol NTP závisí na síťovém roundtripu a na předpokladu, že oba směry komunikace jsou stejně rychlé. Nedovedu si představit, jak tohle zajistit s loadbalancerem.
NTP klienti jsou přece postavení na tom, že se dotazují většího množství serverů a vyhodnocují přijaté odpovědi, takže podpora pro loadbalancing je přímo vestavěná v protokolu – a schovávat více serverů aby pro klienta vypadaly jako jeden je podle mne kontraproduktivní.
-
Pokud mas v LAN sve vlastni 2 NTP servery a veris v jejich spolehlivost, tak staci definovat tyto 2 servery a ntp daemon se s tim "popere" sam - proc pred ne davat loadbalancer, ktery muze prestat fungovat?
Ceho chces loadbalancerem dosahnout?
-
staci definovat tyto 2 servery a ntp daemon se s tim "popere" sam
Ano, popere se s tím tak, že se to bude úplně rozbité. Nikdy to nedělejte.
https://access.redhat.com/solutions/58025
http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.
-
Ano, system nepozna, ze ma server ntp spatny cas (protoze nema s cim porovnavat), ale bude ho slepe nasledovat.
V pripade, ze ale jeden ze serveru bude nedostupny, tak se "prepne" na druhy, nebo se pletu?
-
No to je ale případ že jeden server úplně vypadne. Co když oba poběží a každý bude vracet jiný čas? Jak poznáš ten správný? Pokud si do konfigurace ntpd nedáš vedle jednoho z těch dvou serverů slovíčko true (tím zase degraduješ algoritmus který vybírá ten nejlepší ntp server) spadnou oba do falseticker stavu.
-
No to je ale případ že jeden server úplně vypadne. Co když oba poběží a každý bude vracet jiný čas? Jak poznáš ten správný?
A jak by tahle situace měla nastat? Dokud se server nesyncne s referencí, měl by vracet stratum16 (unsynced), a pokud ne, rovnou bych ho nepoužíval. Nebo se pletu?
BTW použít load balancer? Pokud je potřeba vysoce dostupný čas, nebo je klientů opravdu hodně aby to jeden server nezvládal, tak to asi dává smysl (optimálně když ta F5 checkuje nejen odezvu, ale i stratum), ale těch use case bude asi dost málo.
Napadá mě v případě, že jsou klienti citliví na nedostupnost ntp (některé krabičky se opravdu začnou chovat dost podivně, když je jejich primární NTP dole nebo nevrací čas - typicky v Telco a v průmyslu - o autorech si můžeme myslet své, ale správná implementace NTP klienta nebejvá důvodem proč se to kupuje.)
-
Nebo se pletu?
Hele já ti nevím, o kus výš jsou dal dva linky na dokumentaci (ntpd + RedHat), která ti jasně sděluje, že to nebude správně fungovat.
Napadá mě v případě, že jsou klienti citliví na nedostupnost ntp
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization
Při rozdílu pět minut mezi klientem a serverem jseš v péérdeli. Jako fakt nevím, jestli to má smysl dál rozebírat.
správná implementace NTP klienta nebejvá důvodem proč se to kupuje
No, správnou implementací NTP klienta hlavně není "hoď si mincí", takže to - hrozně překvapivě - ani nedělá.
-
Použití klasického load balanceru kvůli rozložení zátěže, tak to bude asi hodně okrajový případ, kde by těch klientů muselo být tuny. Nějaké NTP servery na bázi AMD geode dává dvě tisícovky klientů a fláká se to.
Spíše se něco takového používá (a méme to tak i nasezeno), že řada klientů umí použít jen jeden nebo max 2 NTP servery a potřebuji tak stav, aby klienti měli dostupný správný čas na té jejich jendé/dvou IP. Pak balancery, který umí tu jednu/dvě IP přeposílát na fungující a správný NTP server se hodí. (Ano kupodivu dost často toto řešíme u beden nasazených v průmyslu, a to v naprosté většině umí klienti jen tupé SNTP, o plnohodnotném NTP si můžeme nechat zdát, jen některé nejnovější high end už tuší něco o PTPv2, ale každy v jiném profilu.)
Toto umí řada NTP server krabic i sama od sebe bez předřazení další bedny před sebe. Zkrátka mám v segmentu třeba 5 NTP serverů od Meinberga, je z nich setaven cluster s virtuální IP a dle pravidle si tu IP přebírá vhodný kandidát a klienti se dotazují na danou virtuální IP, která tak míří na něco funkčního. Pokud mám takové clustery 2, tak je celkem vyhráno. Inteligentní klienti, co umí použít naráz větší počet NTP serverů, tak jim člověk vrazí jako dva zdroje tyto virtuální IP a k tomu přihodí dalších pár přímých IP na fyzické NTP servery, které by za správného stavu obvykle neměly držet tu virtuální IP. A to je svátek, pokud máte v síti klienta, který umí aspoň i symetrický NTP signing pomocí SHA1 (takže se při security auditu může ukázat, že fakt aspoň něco to má nasazeno). :-)
-
Jouda: Mě se něco takového stalo. Přiznám se že jsem nekontroloval zda-li byl status synchronizace u obou serverů 377, ale mám za to že byl u obou. Viz https://access.redhat.com/solutions/2114411. Situace kdy každý server dává jiný čas je možná.
remote refid st t when poll reach delay offset jitter
==============================================================================
x172.20.47.49 .SSU. 1 u 30 64 177 205.404 -871.26 147.799
x172.20.39.49 .SSU. 1 u 44 64 377 203.392 136.998 141.543
Mám za to že v mém případě byl u obou stav synchonizace 377. Tak jsem si ověřit že to není dobrý nápad - mít na klientech nastavené pouze dva NTP servery a RHEL dokumentace to také potvrzuje (někdo výše už psal odkaz).
-
Ano, system nepozna, ze ma server ntp spatny cas (protoze nema s cim porovnavat), ale bude ho slepe nasledovat.
V pripade, ze ale jeden ze serveru bude nedostupny, tak se "prepne" na druhy, nebo se pletu?
ntpcku predhodis N serveru (rekneme 3), on si pravidelne cte vsechny, ale cas syncuje s tim, kterej ma nejmensi rozptyl (z tech dotupnych pochopitelne), pripadne umi i nektery servery vyhodit, pokud jich ma vic (nejakej pool) tak se pokusi navazat komunikaci s dalsim - trebas proto, ze jeho cas prilis ujizdi ... pricemz se naprosto bezne pokud mas pool v prubehu casu meni set serveru, se kterejma komunikuje.
Pokud mas dva, tak bude pouzivat ten presnejsi, pokud umre, tak proste ten druhej, easy.
...Co když oba poběží a každý bude vracet jiný čas....
Resis neexistujici problem, pokud nekomu staci nejaky ntp v siti (coz odpovida tem 2) tak mu je to jedno nebo to ma vyreseno jinak. A pokud mi skleroza slouzi, tak pokud mas (klidne i 5 a vic) ntp serveru, a jejich casy jsou diametralne jiny, tak je klient rejectne vsechny. Dokonce pokud si pamatuju tak i ten widli. Proste to bere jako vadnou konfiguraci a cas nesyncuje. Tusim ze se mi to povedlo docilit po nejakym update kernelu, kde soudruzi vylepsili zdroj casu tak, ze byl zcela nepouzitelnej (behem 10s to bylo schopny ujet o dalsich 10 mimo).
Proc lokalni NTP server?
Bezne staci pool.ntp.org
Treba nechce do internetu posilat seznam vseho co ma v siti, ze ... to je takovej zcela neobvyklej pozadavek v naprosto drtivy vetsine siti.
-
Nebo se pletu?
Hele já ti nevím, o kus výš jsou dal dva linky na dokumentaci (ntpd + RedHat), která ti jasně sděluje, že to nebude správně fungovat.
Moment - já tvrdil že když mám v síti dva NTP servery které tvrdí že je stratum < 16 a ukazují rozdílný čas, tak je něco hodně špatně, což by za normálního provozu nemělo nastat (a implicitně předpokládal, že to odchytí monitoring a někdo to bude řešit).
O tom, že když jsou dva stratum2 servery a jeden z nich kecá, tak s tím klient nic moc nenadělá se nehádám, to je jasné i bez odkazů.
Napadá mě v případě, že jsou klienti citliví na nedostupnost ntp
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization
Při rozdílu pět minut mezi klientem a serverem jseš v péérdeli. Jako fakt nevím, jestli to má smysl dál rozebírat.
[/quote]
To je zase o něčem jiném, to že 5 minut je průser netřeba rozepisovat, to ví každej. ;-)
Co jsem psal je, že když někdo restartuje (třeba kváli patchování, to je fuk) ntp takže to dejme tomu 5 minut neběží vůbec, a pak dalších 20 minut to vrací stratum16 než se sesynce, tak by to správně moc vadit nemělo, klientovi běží vlastní hodiny +- normálně, s driftem to počítá a do hodiny se to zase srovná podle ntp, pro běžné protokoly a situace je to dostatečné (i ty logy by na běžném serveru neměly ujet o víc než sekundu).
Já psal o tom, že občas se vyskytne vysoce specializovaná krabička, které když se tohle stane, tak dělá totální kraviny a tam dává smysl tam předhodit LB čistě kvůli HA. O běžných linux nebo windows stanicích řeč není.
No, správnou implementací NTP klienta hlavně není "hoď si mincí", takže to - hrozně překvapivě - ani nedělá.
No když hračka v šestimístné ceně v eurech po ztrátě spojení s NTP (kterej navíc jde nadefinovat jen jeden), aniž by se tomu čas reálně rozjel, začne posílat alarmy že je rozpadlé spojení s dejme tomu backendem (sorry NDA, o co konkrétně šlo nenapíšu), tak je tam špatně víc než jen házení mincí.
Nebo mnohem levnější hračka co má něco naměřit a odeslat, když jí neodpoví ntp tak jak očekává, tak ani nic neodečte.
Treba nechce do internetu posilat seznam vseho co ma v siti, ze ... to je takovej zcela neobvyklej pozadavek v naprosto drtivy vetsine siti.
Tak pustit klienta přímo na pool.ntp.org? To je vtipné zvlášť když se ten klient když je vypnutej časově rozjede a současně má zapnutou validaci dnssec. ;-)
-
(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 (http://www.ntp.org/ntpfaq/NTP-s-trouble.htm#Q-MON-REACH). 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 (http://doc.ntp.org/4.2.8p11/cluster.html) 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ářů (http://doc.ntp.org/4.2.8p11/select.html) (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 (http://doc.ntp.org/4.2.8p11/prefer.html#prefer), 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.
-
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. Nějak podvědomě mám pocit, že by to nemusel být úplně dobrý nápad ve smyslu dopadu na přesnost. Nijak systematicky jsem se ale tou problematikou nezabýval, takže se možná pletu.
Používám veřejné stratum 1 servery od CESNETu, CZ.NIC a UFE AVČR - Národní časové laboratoře a uvnitř LAN mám pár NTP serverů, které jsou na bare metal strojích.
-
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. Nějak podvědomě mám pocit, že by to nemusel být úplně dobrý nápad ve smyslu dopadu na přesnost. Nijak systematicky jsem se ale tou problematikou nezabýval, takže se možná pletu.
NTP ve virtuálu: jasně že to není správně, ale pro někoho má virtuálka zřejmě praktické výhody, takže se výrobci hypervizorů zřejmě dost snaží, aby to až tolik nebolelo. Ono se to tady už probíralo :-) (https://forum.root.cz/index.php?topic=17834.msg254147#msg254147) a možná ne jednou.
Používám veřejné stratum 1 servery od CESNETu, CZ.NIC a UFE AVČR - Národní časové laboratoře a uvnitř LAN mám pár NTP serverů, které jsou na bare metal strojích.
To mi přijde jako rozumná kombinace. Nezkoumal jsem, ale v téhle množině by měl být k nalezení alespoň jeden server, který nekolabuje přetížením. Konkrétně CZ.NIC si dává dost záležet na průchodnosti poskytované infrastruktury.
V rovině "zážitků z natáčení" (jedna paní povídala) jsem zaslechl o národním etalonu času v jedné východoevropské zemi, kde si postavili veřejný NTP server, a po zveřejnění IP adresy jim za nějakou dobu začla "záhadně" kolabovat IP konektivita do sídla dotyčného úřadu - příčinou byl právě nápor NTP dotazů zvenčí.
-
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. ...
Vmware host ma vlastni ntp a je doporuceny ho mit zaply. Klienstky hodiny se bydefault ridi hostem. Tudiz je to mozny, ale zbytecny, pokud to teda nechces provozovat jako ntp server.
-
O to mi právě jde - provozovat NTP server v dané lokalitě jako virtuál. Jde totiž o to, že z toho páru, který jsem zmínil výše, v tuto chvíli jeden je mimo provoz, protože není k dospozici vhodný hardware. Měl jsem to na Sun Fire V120, ale nějak začal kriplovat. Mimo to jsem ten stroj chtěl šetřit pro muzeální účely a nechtěl jsem, aby byl trvale v provozu. Mám tam ale dostatek kapacity ve virtualizaci.
Protože to je převážně hobby projekt, nový hradware na NTP server pořídím, až se naskytne vhodná příležitost - ve správné popelnici bude vyhozený vhodný hardware, který já ještě upotřebím.
A mám tam ještě NTP server na Mikrotiku, ale to se mi nelíbí. Router má routovat, ne dělat NTP server.
-
Pokud neni provoz (presnost) ntp serveru bussiness critical, tak provozu ve virtualu nic nebrani.
V tom pripade trochu nechapu proc porizujete vlastni specialni HW na NTP sluzbu, kdyz muzete pouzit NTP z hranicniho routeru site LAN (nebo z internetu) nebo z libovolneho fyzickeho stroje (stroju) synchronizovaneho proti internetu
-
K těm dvěma ntp serverům - Zkusil sesynchronizovat na testovacím serveru čas a zapnout ntpd s dvěma HW ntp servery (mají GPS anténu). Jak je možné že jsou plně synchronizované 377 ale ntpd je oba označil jako lháře? Zkoušel jsem porovnat časy které vrací skriptem (https://gist.githubusercontent.com/crashdump/5704286/raw/351511e82d427f7cae68bbba5bdb1323fb36ba01/compare-ntp-time.py) a časy vrací stejné. Kde je problém? Tušíte někdo kde může být zrada?
[root@server ~]#service ntpd stop
[root@server ~]#ntpdate -s clock-02.domain.tld
[root@server ~]#service ntpd start
[root@server ~]# ntpq -p 127.0.0.1
remote refid st t when poll reach delay offset jitter
==============================================================================
xclock-02.domain .ANT1. 1 u 26 64 377 4.478 -1.348 4.283
xclock-01.domain .ANT1. 1 u 21 64 377 3.993 -37.388 4.345
-
K těm dvěma ntp serverům--- ale ntpd je oba označil jako lháře? ... Tušíte někdo kde může být zrada?
Lidi, co si takhle přečíst konečně tu dokumentaci, na kterou tady už několikrát bylo odkazováno? Jak u blbejch na dvorku, skutečně.
-
Díky, již to tu zaznělo několikrát. Jde mi spíše o důvod proč jsou oba označení jako lháři, když vrací stejný čas (pokud je skript odkazovaný výše dostačující pro porovnání).
[root@server]# ./timecheck.py -v clock-01.domain.tld clock-02.domain.tld
Time received from clock-01.domain.tld = 1547113483 (Thu Jan 10 10:44:43 2019)
Time received from clock-02.domain.tld = 1547113483 (Thu Jan 10 10:44:43 2019)
Times match.
-
Pokud neni provoz (presnost) ntp serveru bussiness critical, tak provozu ve virtualu nic nebrani.
V tom pripade trochu nechapu proc porizujete vlastni specialni HW na NTP sluzbu, kdyz muzete pouzit NTP z hranicniho routeru site LAN (nebo z internetu) nebo z libovolneho fyzickeho stroje (stroju) synchronizovaneho proti internetu
Protože to je, do značné míry, cvičná LAN. Proto se v ní vyskytují a dějí věcí, pro které třeba ani není praktické opodstatnění.
Mimochodem, teď vidím, že jsem poněkud přehlédl odstavec o virtualizovaném NTP v tom dlouhém příspěvku nahoře.
-
Ten skript jde na sekundy? Tak to není dostatečně.
Ne, ty dva NTP servery nehlásí stejný čas, dle toho ntpq -p. :-)
To reach=377 je bitová mapa v osmičkové soustavě počtu úspěšných pokusů kontaktovat NTP server, 377 znamená, že se 10x po sobě (v intervalu 64 sekund) povedlo z NTP získat informaci o času. Dle měření je zhruba stejné dopravní zpoždění od obou serverů (delay) a navíc oba servery vykazují skoro stejný jitter dat. Při započtení všeho jsou ty servery od sebe dost ujetý dle toho offset o cca 36 milisekund, což je "nechutné". Takže čert ví, který ten server je ten správný. Při tomto stavu je primárním kritériem (co jsem zkoušel) ten jitter, pokud by byl od jednoho výrazně větší, tak se přikloní k tomu druhému serveru rovnou, ale oba servery mají stejný jitter, sekundárně podobné dopravní zpoždění, tak neví ke komu se přiklonit a zahodil raději oba. Tady by asi pomohla nucená preference u nastavení peera (odkaz na true parametr dříve tady někde zazněl).
-
Místo preference pomocí true jsem se rozhodl držet se doporučení - konfigurovat minimálně 4 ntp servery. Pořád mi ale vrtá hlavou ten rozdíl 36 milisekund, protože jde o hardwarové krabice (stejný výrobce i typ) které mají GPS anténu. Každá je fyzicky na jiném místě v Praze. Jak je možné že dávají tak rozdílný čas?
-
Nu, pokud je ten server, který se snažím synchronizovat, nějaký rozlítaný virtuál na desktopu, tak je možné, že něco takového naměří, pokud mu virtualizovaný vnitřní čas lokálně různě poposkakuje. To by se mšlo projevit létáním v delším časovém horizontu.
Jiná otázka je, jak skutečně je ten čas těch dvou GPS/NTP krabic od sebe. Pokud umí a můžeš, tak je nastavit jako vzájemný peer pro zálohu a uvidíš, jak uvidí sebe sama proti sobě a s jakou chybou.
Protože pro tak popsanou situaci je to asi moc.
Např:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* NTP1 .MRS. 1 u 115 128 377 0.187 1.207 0.091
+ NTP2 .PPS. 1 u 40 128 377 12.779 -0.534 0.194
+ NTP3 .PPS. 1 u 50 128 377 15.208 -0.638 0.177
NTP1 je NTP s integrovanou GPSkou ležící vedle linux klienta (Intel Atom HW). NTP2 je NTP server s externí GPS cca 30 km na východ od něj a NTP3 je NTP server s externí GPS ležící cca 120 km západně, komunikačně je k oběma asi stejně daleko 2x kolem celé ČR, což odpovídá tomu delay. Rozdíl časů offsetem si ty dvě vzdálené NTP2 a 3 odpovídají, rozdíl proti lokální bude tím, že ty vzdálené NTP mají GPS externí a mezi GPS a NTP je několik převodů optika/metalika, kde není kompenzováno toto dopravní zpoždění v nastavení NTP serverů a taktéž od antény GPSky k vlastnímu přijímači je to kus cesty.
Pokud vezmu virtuální linux servery (KVM, virtuál i hostitel CentOS7, kde na tom fyzickém serveru běží desítky dalších virtuálů) a tento pomocí ntpd se syncuje proti dvěma v LAN umístěným NTP/GPS, tak to v nich vypadá takto:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* 2NTP .PPS. 1 u 7 1024 377 0.177 -0.483 0.034
+ 1NTP .PPS. 1 u 37 1024 377 0.165 -0.484 0.041
-
@M.: díky za názorná čísla :-)
Koukám že ten výsledek ve virtuálu nevypadá vůbec špatně... jitter 35-40 mikrosekund. Hezké.
A ten první výpis, kde je záporný offset asi půl milisekundy... pokud by tam bylo v sérii několik relativně pomalejších opto-převodníků, tak by to snad i mohlo něco vysvětlovat. Kabeláž od GPS antény k přijímači bych nepodezíral, protože 5 ns na metr, a těch metrů anténního svodu nebude moc. I kdyby stometrový svod, pořád jsme na 500 nanosekundách, to je o tři řády míň než ta cca půl milisekunda.
Ale jestli je tam dopravní zpoždění nějakých 12 ms, tak by tam mohla být cca půl ms asymetrie (ntpd počítá se symetrickým přenosovým zpožděním). Mimochodem si myslím, že by to asi šlo i dokompenzovat - třeba argumentem "bias" na řádku v ntp.conf?
-
Nu, také mě to překvapilo, že to v těch virtuálech se na nich drží evidentně v desítkách us. Ale vysvětlení asi je, že to je rok starý HW a přestože je tam aktivně živých 20 virtuálů, tak počet fyzických jader cca odpovídá alokovanému počtu virtuálních CPU, takže se virtuál drží svého fyzického jádra a jede to takhle krásně ve virtuálu a taktéž na fyzickém HW pod tím (24 fyzických jader, virtálních 31, CentOS7 podklad i virtuál, KVM).
Pokud se podívám do racku vedle na historický HW, co má tak 7 let odslouženo, kde je 16 fyzickéch jader a o které soupěří aktivně běžících cca 30 virtuállů (podklad CentOS5, KVM, virtuály Slackware 10), tak už to je o řád horší (oba stejné NTP+externí GPSky v rámci LAN, 2NTP je jen o dva switche dál):
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* 2NTP .PPS. 1 u 12 1024 377 0.244 0.817 0.664
+ 1NTP .PPS. 1 - 8 64 377 0.224 0.062 0.460
A jak ta zátěž začne stoupat, tak to jde do kytek, lokalita na opačné straně ČR, 12 fyzických jader o které soutěží živých 50 virtuálů s CentOS6 podklad, KVM, virtuály Slackware 10, Zdrojem času jsou 3 NTP v LAN, dva sdílí jednu GPSku (NTP30 a NTP31), třetí ji má integrovánu:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+ NTP30 .PPS. 1 u 68 128 377 0.608 52.751 113.245
x NTP31 .GPS. 1 u 78 128 377 0.460 -122.04 126.707
* NTP32 .PPS. 1 u 78 128 377 1.869 56.161 114.396
To už odpovídá tomu, jak to ukazoval tazatel s těma dvměa NTP/GPS na dvou koncích Prahy. I zde je to rozlétáno a občas to některý NTP server vyhodí. Občas jsou čísla i horší, často i lepší. Přitom odjinud jsou ty 3 zdroje vidět v jedné lajně, pokud je to nazatížený stroj.
K tomu rozdílu půl ms u NTP ze tří lokalit, tak také souhlasím, že to je spíše dopad asymetričnosti linek a vlivu delay linky. Mnohem menší dopad má, že GPS není integrována v NTP a je tak od ní delší rozvod PPS s převodníky. Protože není nad jednoduchý pokus, že si v té jedné lokalitě připojím i něco s integrovanou GPS (NTP30-NTP32 odpovídá tomu výpisu výše i ze stejného času):
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
- NTP1 .MRS. 1 u 170 256 377 0.168 -0.505 0.467
* NTP2 .PPS. 1 u 101 256 377 12.818 -1.821 0.467
+ NTP30 .PPS. 1 u 104 256 377 15.083 -2.009 0.585
+ NTP31 .PPS. 1 u 160 256 377 15.771 -2.695 1.034
+ NTP32 .GPS. 1 u 161 256 377 15.029 -1.812 0.526
Takže je vidět i stádovitost vyhodnocení shluku, kdy už NTP dává přednost vzdálenému zdroji, jehož jitter, delay a ofset je nejlepší z toho shluku a odmítne lokální zdroj o rack vedle (NTP1 je M500/GPS). NTP2 je těch 120 km západ (M300/RDT a ext GPS167), NTP30 až NTP31 je 30 km východ, komunikačně o něco dále, než ten západ, přitom NTP30 (M300/GPS s použitým ext PPS, protože interní GPS kaput) a NTP31 (M300/RDT) mají společnou GPS167, jen do NTP30 je to 30 metrů PPS rozvodu a do druhého 3/4 km rozvodů a asi šesti převodů metalika/sklo cestou. NTP32 je s integrovanou GPS (M300/GPS), tyhle tři leží u sebe v kruhu cca 1 km. Všude je cca 20~40 metrů koaxu mezi anténou a GPS.
Takže ten offset dle toho opravdu padá spíše na nedokonalost IP trasy, než těch lokálních rozvodů. Biasem by to šlo asi poštelovat, pokud by se mi neměnil moc charakter vytížení IP tras, ale není k tomu asi reálný důvod, jen jsem si to zkusil, jak se to cca chová. :-)
-
@M. : ta poslední tabulka je boží :-) Tím Vás nechci nijak poňoukat k dalšímu popisování detailů Vaší sítě, myslím že jich bylo až dost... Vaše závěry jsou přesné. Já bych snad jenom zdůraznil, že je z toho hezky vidět, jak snadno by se mohlo stát, že partička upstream serverů, které mají offset zatížený shodnou systematickou chybou (sdílené úzké hrdlo v konektivitě s asymetrickou zátěží?) může přehlasovat objektivně mnohem přesnější blízký zdroj času :-)
Ony ty podrobnosti skutečně vyplavou na světlo až ve větší množině upstream serverů. Mimochodem všechny servery ve Vaší konfiguraci mají záporný offset. A ta "shluknutá skupina" co vyhrála hlasování má ofset asi o 1.5 ms zápornější než nešťastný outlier. Což by podle mého mělo znamenat, za jinak stejných okolností (pokud se asymetrie na linkách v čase nějak nezmění) že se "náš" ntpd bude snažit ten offset vynulovat postupným doladěním lokální časové základny. Tzn. v ustáleném stavu by "skupina co vyhrála hlasování" skončila rovnoměrně rozmístěná okolo ofsetu 0 a nešťastný NTP1 by skončil s reportovaným ofsetem asi +1.5 ms.
Taky jsem se sám ještě trochu poučil četbou dokumentace. Konkrétně jsem se napřed zajímal o přesný význam těch znamének na začátku řádku NTPq (http://doc.ntp.org/4.2.8p11/decode.html#peer). (Popisuje to asi třetí HTML tabulka od uvedeného relativního odkazu.) Vím dávno, že hvězdička na začátku znamená "vítěz" a plus na začátku znamená "finalista - účastník váženého průměru", ale co znamená třeba mínus? To je ten co musel z kola ven? No a zjistil jsem, že "outlier" (znaménko mínus = Váš případ) není totéž jako falseticker (znaménko "x"). Ten ověřovací a shlukovací algoritmus je totiž dvoukolový.
V prvním kole (tzv. clock select algorithm) (http://doc.ntp.org/4.2.8p11/select.html) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.
V druhém kole (tzv. clock cluster algorithm) (http://doc.ntp.org/4.2.8p11/cluster.html) dojde na jemnější shlukování - a outlier je server, který se dostal do druhého kola, ale jeho "interval pravděpodobných hodnot" (střední hodnota ofsetu +/- směrodatná odchylka jitteru) stojí mimo většinový shluk. A právě toto se stalo nejbližšímu serveru na stratu 1 :-D
Mám experimentálně nepotvrzený dojem, že rozdíl mezi oběma případy (fázemi vyhodnocení) bude v účinku klíčového slova "prefer". Jasný falseticker bude vyloučen i v případě, že má v konfiguraci slovo "prefer". Ale prostý outlier by s "prefer" argumentem patrně zvítězil :-)
Přiložím jeden screenshot. Zajímavé je, že lokální rádiem řízené hodiny nemají znaménko "o" (PPS peer), ale prázdné pole " " - což podle tabulky znamená "peer invalid". Tak mám dojem, že jsem ten screenshot típnul příliš brzy po startu stroje - ono chvíli trvá, než je refclock driver "spokojený". Patrně vstupní signál napřed chvíli sleduje a hledá případné nekonzistence, a ostatně jádro ntpd se refclock driveru taky ptá s delší periodou než 1/s. Nebo tam mají Meinbergové pod kapotou něco čemu nerozumím. Kromě toho se jednalo o hodně nový firmware na hodně starém hardwaru... A kromě toho dnešní Meinbergovic firmware už NEobsahuje dva pseudo-samostatné refclock drivery: pro ToD na sériovém UARTu driver "parse" + zvlášť PPS refclock 0, ale jenom jeden driver, který má podporu PPS integrovanou. Takže názvoslovně už nejedná o čistý PPS refclock. Hmm... na tohle se asi ještě zaměřím. Brzy bude příležitost.
Vlastně jsem chtěl ještě dodat, že interní GPS/PPS refclock má u Meinbergů (a zřejmě i jinde) vždycky právě prefer keyword. Resp. samostatný PPS refclock míval tradičně nějaké úplně specifické zacházejí, jako že "PPS má vždycky pravdu a vždycky offset 0".
-
Mám experimentálně nepotvrzený dojem, že rozdíl mezi oběma případy (fázemi vyhodnocení) bude v účinku klíčového slova "prefer". Jasný falseticker bude vyloučen i v případě, že má v konfiguraci slovo "prefer". Ale prostý outlier by s "prefer" argumentem patrně zvítězil :-)
To dává smysl. Volbou prefer správce dává najevo, že daný server je v něčem lepší, když všechno funguje tak jak má. Nelze ale zaručit, že to tak bude navždy, že ten server někdy v budoucnu kvůli nějaké chybě (ať už serveru nebo na trase) začne poskytovat špatná data. Takže vyřazování falsetickerů musí dělat software průběžně, protože správce to nemůže stihnout zachytit včas. Do druhého kola ale už postoupí jen kandidáti, kteří by měli být v pořádku a už jde jenom o to vybrat toho aktuálně nejlepšího – a tam dává smysl ruční zásah správce, který může mít informace, které ntpd není schopno zjistit.
-
Ano, "prefer" by mělo naznačit, co si přeji používat jako prioritní zdroj, který prošel prvním kolem výběru. Kdežto "true" je ještě drsnější, tím se snažím přebít zcela i ověřování spolehlivosti/stability.
Ale pokud jsem to pochopil správně, tak to mám zkusit. :-) Takže s pomocí soudku rumu, ať to lépe ubíhá....
Jak dám "prefer" na ten NTP1, tak dle očekávání se stane preferovaný zdroj a snaží se ho to sledovat, jak je ten zdroj blíže a stabilnější, tak se i ustálí hodnoty z dalších vzdálených zdrojů (ale něco bude i na vrub menšího víkendového zatížení IP tras):
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* NTP1 .MRS. 1 u 111 128 377 0.182 -0.056 0.076
+ NTP2 .PPS. 1 u 3 128 377 11.231 -0.086 0.068
+ NTP30 .PPS. 1 u 61 128 377 13.699 -0.335 0.121
+ NTP31 .PPS. 1 u 80 128 377 14.300 -0.306 0.317
+ NTP32 .GPS. 1 u 16 128 377 13.594 -0.311 0.071
Pokud to zkusím rozbít, že NTP1 má jen jako zdroj vnitřní referenci z GPS (žádný externí zdroj/NTP), stáhnu dobu platnosti nesync GPS (NTP Trusttime MRS=10sec) a vynutím cold boot GPSky a reboot CPU modulu, tak je vidět, že když to hlásí unsync stav (statum 16), tak se přepne na něco z dalších zdrojů:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
NTP1 .INIT. 16 u 22 128 360 0.184 0.626 0.104
* NTP2 .PPS. 1 u 87 128 377 11.262 0.502 0.407
+ NTP30 .PPS. 1 u 32 128 377 13.569 -0.122 0.248
+ NTP31 .PPS. 1 u 29 128 377 14.325 0.021 0.574
+ NTP32 .GPS. 1 u 98 128 377 13.465 0.572 0.455
Když se pak ntpd rozjede a GPS pozdržím pár dalšíma cold rebooty, tak se chytne ntpd interní reference a přejde na stratum 12, jak má nastaveno, tak už ho to "prefer" přitáhne klienta zpět (ale asi pomáhá, že dost udrží ta interní reference v té M500):
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* NTP1 127.0.0.1 12 u 81 128 340 0.184 0.626 0.111
+ NTP2 .PPS. 1 u 18 128 377 11.262 0.502 0.657
+ NTP30 .PPS. 1 u 89 128 377 13.569 -0.122 0.185
+ NTP31 .PPS. 1 u 87 128 377 14.325 0.021 0.432
+ NTP32 .GPS. 1 u 28 128 377 13.585 -0.106 0.319
A až se to pak rozjede a přejde to na referenci z GPSky, tak to na moment z NTP1 odpadne (asi to trochu v té chvíli poskočí) a po chvíli se to na NTP1 poctivě vrátí a tam už to pak drží, pokud do toho nehrabu:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
* NTP1 .MRS. 1 u 65 256 377 0.185 0.195 0.060
+ NTP2 .PPS. 1 u 81 256 377 11.269 0.127 0.105
+ NTP30 .PPS. 1 u 138 256 377 13.590 -0.050 0.072
+ NTP31 .PPS. 1 u 160 256 377 14.134 0.112 0.568
+ NTP32 .GPS. 1 u 90 256 377 13.552 -0.035 0.089
Z toho plyne, že pokud na nějaký upstream si dám "prefer", tak to má být něco, co by mělo mít vždy nějaký rozumný čas k dispozici, jinak mi to může slušně ujet, než odchylku přebije ten shlukový algoritmus a vyrazí to z 1. kola selekce pro nesmyslnost. :-)
Add nastavení uvnitř Meinberga - asi ve všech (kde jsme do toho nehrabal :-) ), tak mají na PPS/GPS vstupu natvrdo dáno současně prefer i true a osmi sekundový interval braní dat (min/maxpool 3):
server 127.127.8.0 mode 151 prefer minpoll 3 maxpoll 3 true # UNI Erlangen with PPS
K tomu screen shotu - dle výstupu "fpc" v horní části, tak to hlásí, že GPS je ještě v COLD BOOT stavu. Pokud jsem postřehl, tak po power on nedává PPS, dokud se GPS nechytne (respektive PPS asi z GPS chodí, ale ntpd je ignoruje), takže ntpq nehlásí stav "o" u toho GENERIC asi oprávněně (mě se to většinou chytá kolem 800~830 sec po cold bootu s anténou s plným výhledem). Pokud je WARM/COLD BOOT vyvolán za běhu, tak to PPS dává(akceptuje), pokud neuplyne doba důvěryhodnosti nesynchronizované GPS (defaultně tam mají 4 dny: fudge 127.127.8.0 time2 345600 # trust time value ).
Protože když je to syncnuté (a chytí se to na první pulz ke kterému jsou sériová data se sync příznakem), tak s interní GPS:
NTP1 ~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
oGENERIC(0) .MRS. 0 l 2 8 377 0.000 -0.001 0.004
Kde je externí zdroj PPS plus sériový string:
NTP31 ~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+GENERIC(0) .DCFa. 0 l 11 16 377 0.000 0.000 0.002
oPPS(0) .PPS. 0 l 6 16 377 0.000 -0.002 0.002
Ale asi jsme už dost přečerpali původního tazatele. :-)
Hm, jen si budu muset dobádat, proč mi na externí výstupy GPS modulu chodí sekundové pulzy v nesync stavu, přestože to mám zakázáno (Clock / GPS Clock / Enable Outputs / Pulses : If Sync). Nebo to tam někdo zase celé předrátoval a chodí zo z nějakých přesýpacích hodin...
-
@M.: hezky...
V tom prvním výpisu mě překvapuje, kam zmizel ten offset okolo 1.5 ms.
Protože round-trip delaye jsou jenom nepatrně nižší, než v předchozím výpisu (provoz přes den).
Případně by bylo zajímavé vědět, kolik z toho delaye je "stabilní základ" a kolik jde na vrub prodloužení front při silnějším provozu (potenciálně asymetrickém).
Přijde mi nepravděpodobné, že by ten rozdíl v delayích zmizel prostě jenom nastavením "prefer" objektivně nejbližšímu upstream serveru.
Cold boot má trvat v optimálním případě asi 12 minut, protože tak dlouho trvá přijetí úplného almanachu z družic (pokud v příjmu nejsou chyby). Meinberg nepodporuje stažení almanachu z Internetu (svého druhu assisted GPS, pokud se nepletu). Následuje "warm boot", který už může být docela rychlý - pokud se nepletu, v průběhu (nebo až na konci?) warm bootu už má přijímač poziční fix a čas. V zásadě se ještě čeká na konstalaci s použitelným DOP (tuším pod 2.5) = družice na "kolmých" směrech, aby se minimalizovala trigonometrická chyba v "průniku kulových ploch". V momentě kdy toto nastane, rozsvítí se stavová kontrolka GPSky zeleně. Pro potřeby NTP je to vše. Pokud je v systému PTP grandmaster, tak se ještě čeká na event "oscillator adjusted" - zmíněný oscilátor je sice v přijímači GPS, ale PTP grandmaster čeká na jeho plný závěs, teprve pak totiž začne v protokolu PTP deklarovat přesnost "<100 ns".
Takže oni Meinbergové cpou GPS refclocku dokonce "true"? No... ono to dává smysl, když přidat alternativní upstream NTP servery do konfigurace ntpd jde u MRS sestav už jenom oklikou, a primárním způsobem závěsu na upstream NTP server je cesta skrz MRS = podle záložního NTP se v případě výpadku příjmu družic (volně) dolaďuje oscilátor přijímače, o čemž ntpd na x86 CPU kartě nemá ani potuchy. Z mého pohledu je to škoda, padají tím totiž výhody toho "dvoukolového prosévacího algoritmu" (MRS tohle neumí) - v odůvodněných případech lze přesto upstream ntp servery do ntp.conf dodat ručně. Tzn. je dobré o těchto nuancích vědět a umět si vybrat. Ještě zkusím zjistit, jestli lze odstranit "true".
A ještě:
> Clock / GPS Clock / Enable Outputs / Pulses : If Sync
To se podle mého netýká interní PPSky pro CPU kartu. Toto se týká programovatelných pulzních výstupů, které jsou samostatně vyvedené ze šasi (na konektory na panelu). Resp. mohou být - jedná se o factory option. Tyto výstupy umí krmit přímo Meinbergovic karta přijímače, lezou z jejího FPGA. (V modulárních IMS sestavách se dále vyskytují přídavné karty jako CPE180, které mají vlastní podružný oscilátor a FPGA a programovatelné výstupy.)
-
Hmm... ještě jednou koukám na popis "clock select algoritmu" (http://doc.ntp.org/4.2.8p11/select.html) a řekl bych, že ten můj popis opsaný z prvního odstavce dokumentace zřejmě nesedí.
V prvním kole (tzv. clock select algorithm) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.
Odkazovaný HTML dokument mi přijde interně nekonzistentní, nebo přinejmenším hrubě zkratkovitý. Jsem z toho daněk.
-
V tom prvním kroku se napřed provede základní "sanity checking" nakonfigurovaných asociací, a následně se hledá "interval překryvu pro maximální počet asociací". Kdo se tohoto maximálně četného překryvu neúčastní, stane se falsetickerem...? Přesné blízké zdroje času dostanou pro potřeby tohoto algoritmu "rozhodnutím strany" určitý minimální rozptyl ("mindist", default 1 ms) aby získaly lepší "koaliční potenciál" a nevypadávaly rovnou jako falsetickers.
No a ve druhém kroku se jedná opět o jakýsi clustering, ale tentokrát nikoli prostým překryvem, ale iterativním odlupováním nejodlehlejších jedinců... dokud nenastane ukončující podmínka. Pokud správně chápu popis.
Poznatky ohledně "prefer" a "true" myslím platí beze změny.
-
Aha, že by si ani autoři NTPD nebyli zcela jisti, jak to vlastně funguje? :-)
Ale k tomu, že to přidání prefer na NTP1, že se to celé uklidnilo, tak to nebylo tím, ale víkendovým komunkačním klidem na IP trasách. Když jsem prefer z NTP1 vyhodil a nechal to být, tak dle očekávání preferovaný odcestoval na vzdálenou grupu, ale offset/jitter/delay byl v podstatě stejný, jak s prefer na NTP1:
remote refid st t when poll reach delay offset jitter
==============================================================================
+ NTP1 .MRS. 1 u 34 256 17 0.167 -0.069 0.007
* NTP2 .PPS. 1 u 37 256 17 11.477 -0.097 0.069
+ NTP30 .PPS. 1 u 32 256 17 13.732 -0.291 0.083
- NTP31 .PPS. 1 u 32 256 17 14.733 0.142 0.194
+ NTP32 .GPS. 1 u 29 256 17 13.727 -0.219 0.076
Když pak došlo k přetížení komunikačních tras pro vynucený traffic, tak je vidět, jak se u vzdálených NTP rozletěl delay a další, ale zvolen zůstal stejně "nejlepší" vzdálený NTP server a lokální NTP1 šel dokonce do outliner:
remote refid st t when poll reach delay offset jitter
==============================================================================
- NTP1 .MRS. 1 u 683 1024 377 0.253 0.134 0.011
+ NTP2 .PPS. 1 u 937 1024 377 23.953 -5.955 6.722
* NTP30 .PPS. 1 u 954 1024 377 13.742 -1.752 1.702
+ NTP31 .PPS. 1 u 946 1024 377 23.969 -4.364 4.484
+ NTP32 .GPS. 1 u 175 1024 377 23.168 -4.573 4.514
Po pominutí přenosu se to ustálilo zpět, prefer stále vzdáleně:
remote refid st t when poll reach delay offset jitter
==============================================================================
+ NTP1 .MRS. 1 u 969 1024 377 0.207 0.876 0.256
* NTP2 .PPS. 1 u 195 1024 377 11.405 0.706 0.230
- NTP30 .PPS. 1 u 214 1024 377 14.174 -0.866 0.030
+ NTP31 .PPS. 1 u 206 1024 377 15.319 0.922 0.182
- NTP32 .GPS. 1 u 455 1024 377 13.746 0.557 0.060
Takže podobně ucpané linky dokáží asi celkem to pak vyosit a přitáhnout úplně někam jinam. :-(
Add to, že Meinbergové dávají prefer i true u refclocku, tak u toho M500 s MRS (firmvare v6) je to asi pochopitelné, opravdu přidané externí NTP servery to nedá do ntp.conf, ale nějak si to šušní v té MRS částí (toho jsme si doteď ani nevšiml, z toho webksichtu to není na první pohled patrné, dostanu je tam leda přes textové "Edit Additional NTP Parameters").
Pokud se podívám na M300/GPS s v6 firmware, tak je tam prefer i true:
server 127.127.8.0 mode 151 prefer minpoll 3 maxpoll 3 true # UNI Erlangen with PPS
Ale přidané NTP servery do strká do ntp.conf a řeší to ntpd klasicky.
Pokud vermu M300/RDT s v6 firmware, tak to je stejné, použito prefer i true pro externí časový normál:
server 127.127.8.0 mode 151 prefer minpoll 3 maxpoll 3 true # UNI Erlangen with PPS
taktéž externí NTP servery obsluhuje klasicky ntpd.
Mám i pár M300/RDT ještě na v5 firmware, tam je použité jen prefer (a jiný stirng formát):
server 127.127.8.0 mode 130 prefer minpoll 4 maxpoll 4 # Meinberg Time String 9600/7E2 with PPS
Externí NTP klasicky obsluhované ntpd démonem (jinak ani nejde, ty M300/GPS a /RDT přeci jen mají jiný HW než M500 s MRS). Pohledemedo wekschichtů není nic, co by nastavitelnost true a prefer dovolovaly.
Je vidět, že to použití prefer a true asi prošlo historicky nějakým vývojem. :-)
-
@M.: díky za další podrobnou reakci :-)
Nepatrná grammar nazi korekce: ten co dostane v ntpq hvězdičku se oficiálně jmenuje "sys-peer" (ve shluku přesných kandidátů něco jako "čestný předseda"). "prefer" je fakt jenom argument v konfiguráku.
Na keyword "true" jsem se zeptal technické podpory. Vzhledem k tomu, jak je poslední týden zkouším z obtížných témat, odpověď možná nebude dneska ;-)
Tahle debata se mi strefila zrovna do nějakého pracovního úkolu, kde řeším distribuci času v nějaké rozsáhlejší WAN: na periferních lokalitách GPSkové NTP servery s backupem přes NTP na pár centrálních lokalit. "Prefer" keyword u lokálních GPS přijímačů vypadá jako hodně dobrá finta proti systematické asymetrii přenosového zpoždění u záložních NTP uplinků. Za normálních okolností lokální GPSka vyhraje volby i když s ostatními o fous nesouhlasí, ale není tím dotčeno její vyřazení jakožto falsetickera, pokud si začne moc vymýšlet (nesoulad se záložními NTP servery překročí jakousi hranici). V takové situaci si pak periferní lokality musí vystačit s přesností NTP over WAN, o kterém už víme, že může mít offset trochu zatížený asymetrií přenosových zpoždění - která závisí na zátěži ostatním provozem. Asi lepší než drátem do oka.
S tou asymetrií by možná trochu pomohla priorizace NTP provozu v queueingu na síťových elementech "na vstupu do úzkého hrdla" (což může a nemusí být problém v jiných ohledech, ať už se bavíme o L3 nebo o L2).
Kladivem na asymetrii je protokol IEEE1588 (PTP), pokud ho síťové elementy po cestě podporují (aktualizují pole "korekce" v PTP paketech). Tohle kladivo je bohužel docela drahé a jeho Best Master Clock Algorithm bohužel nedosahuje úrovně vychytralosti v třídění a kombinování více upstream zdrojů, kterou známe z NTP. On se bohužel PTP a jeho BMCA pohybuje s jitterem o tři-čtyři řády níž než NTP a asi tam při rozhodování hrají roli jiná hlediska, zejména rychlost konvergence, a třeba taky implementační jednoduchost klientů. Nemluvě o dosud probíhající evoluci PTP (a to "ve více vláknech" - viz ptp "profiles" a ani to zřejmě ještě není konec příběhu o babylónské věži).
-
Ohledně toho úkolu - ano, vypadá to, že u klientů je použití prefer u deifnice toho lokálního NTP dobrou volbou. Dle pokusů za posledních pár dnů, tak když mám lokální NTP server s "prefer", tak si ten lokální NTP server udrží "sys-peer" ( :-) ) stav i v případě, kdy vzdálené servery drží pohromadě v jedné lajně, což je dobře (i když spoje k dalším přetížím a ujedou v jedné lajně s ofsetem/delay/jitter celkem daleko). Nepoveldeo se mi ucpáváním tras vychýlit vzdálené NTP tak, aby to na ně přešlo, pokud lokální hlásil něco lepšího, jak stratum 16. Tím pádem je ale nutno mít ten lokální NTP syncovaný i odjinud, než jen ta lokální GPSka, protože ho to udrží i v případě, kdy jede z lokálníhch hodin bez extenrí reference (pokud je nastavneo, že ji má propagovat jako stratum 12 a validní stav). To samozřejmě platí pro stav, že klienti jsou inteligentní plnotuční NTP klienti, pokud je to něco SNTP tupého, tak ten zkusí a pokud dostane sync odpověd z něčeho, tak ji použije a dál nebádá, že další NTP server trvdí zcela něco jiného...
Souhlasím, že je vhondéí míd UDP/123 trochu popostrčeno v řízení provozu, pokud mám technolohii, co to umí.
Nu, PTPv2 vnímám jako trochu něco jiného. Jednak u něj se moc nepočítá s WAN provozem, spíše jen LAN. A hlavně ho vnímám, že má zajistit, aby všichni kleinti v dané sítí měli pokud možno stejný čas proti jendomu jasně danému zdroji (případně i stejný refereční frekvenční normál, pokud je to včetně SyncE), proto je ten algoritmus výběru grandmastera dost jinak, než u NTP. U PTP chci mít stejný čas s grandmasterem (a často ten nemusí mít čas platný se zbytkem světa), kdežto u NTP se snažím inteligentně přiblížit světovému času u všech klientů, ale každý klient může být dle své regulace někam trochu ujet. Takže PTP je spíše evoluce časových rozvodů na bázi IRIGu a podobných, kde se u NTP něčím málo inspirovali. Implementačně a v počtu profilů je PTPv2 bordel na N-tou, to je fakt ke smíření. :-)