Loadbalancing NTP serveru

David1234

Loadbalancing NTP serveru
« kdy: 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?



Roman

Re:Loadbalancing NTP serveru
« Odpověď #1 kdy: 09. 01. 2019, 14:56:45 »
Pokud to není pro nějaké klienty jediný NTP server, tak je balancování zbytečné.

Vilith

  • *****
  • 660
    • Zobrazit profil
Re:Loadbalancing NTP serveru
« Odpověď #2 kdy: 09. 01. 2019, 15:04:08 »
Proc lokalni NTP server?
Bezne staci pool.ntp.org

David

  • ***
  • 143
    • Zobrazit profil
Re:Loadbalancing NTP serveru
« Odpověď #3 kdy: 09. 01. 2019, 15:06:38 »
Používám tik.cesnet.cz a tak.cesnet.cz

David1234

Re:Loadbalancing NTP serveru
« Odpověď #4 kdy: 09. 01. 2019, 15:11:47 »
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.


Re:Loadbalancing NTP serveru
« Odpověď #5 kdy: 09. 01. 2019, 15:24:10 »
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í.

Vilith

  • *****
  • 660
    • Zobrazit profil
Re:Loadbalancing NTP serveru
« Odpověď #6 kdy: 09. 01. 2019, 15:26:48 »
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?


Lol Phirae

Re:Loadbalancing NTP serveru
« Odpověď #7 kdy: 09. 01. 2019, 15:57:18 »
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.

Vilith

  • *****
  • 660
    • Zobrazit profil
Re:Loadbalancing NTP serveru
« Odpověď #8 kdy: 09. 01. 2019, 16:10:28 »
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?

David1234

Re:Loadbalancing NTP serveru
« Odpověď #9 kdy: 09. 01. 2019, 16:17:02 »
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.

jouda

Re:Loadbalancing NTP serveru
« Odpověď #10 kdy: 09. 01. 2019, 20:16:00 »
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.)

Lol Phirae

Re:Loadbalancing NTP serveru
« Odpověď #11 kdy: 09. 01. 2019, 20:28:32 »
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á.

M.

Re:Loadbalancing NTP serveru
« Odpověď #12 kdy: 09. 01. 2019, 22:15:34 »
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). :-)

David1234

Re:Loadbalancing NTP serveru
« Odpověď #13 kdy: 09. 01. 2019, 22:52:47 »
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á.

Kód: [Vybrat]
     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).

j

Re:Loadbalancing NTP serveru
« Odpověď #14 kdy: 09. 01. 2019, 23:46:17 »
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.