Synchronizace času doménových klientů

Re:Synchronizace času doménových klientů
« Odpověď #15 kdy: 07. 03. 2018, 06:57:27 »
K předchozímu viz např. zde bod 5.
Díky za výživný odkaz - pro mě osobně výživný od A do Z.

Konkrétně k bodu 5:
takže "bývaly doby, kdy DC běžící ve VM (Hyper-V) uměl přebírat čas od hostitele a distribuce času v doméně takto fungovala. Ty doby jsou pryč. Odteď si chce DC ve VM správcovat čas striktně sám, brát ho z upstream NTP serveru." Přestože je to obecně z hlediska časomíry ve virtualizovaném prostředí možné méně vhodná varianta, dodávám já.

Líbí se mi, jak distribuce času ve Windows doméně funguje bezpracně, samospádem, včetně krypto-ošetření. Dokonce mám pocit, že W32time s každou novou generací Windows trochu dospěje. Bravo. Tzn. jenom na okraj chci zmínit, že to může fungovat taky mimo doménu, dokonce jako časová serviska na NTP klientech (včetně DC!) nemusí být použita W32time, ale open-source ntpd (Windows build).

Každopádně pokud NTP klient běží ve VM, ať už je na bázi W32time nebo ntpd, týkají se ho obecné nectnosti virtualizovaného prostředí pokud se týče časomíry. K tématu existuje obecný whitepaper od Meinbergů - autor Martin Burnicki je jejich dlouholetý klíčový vývojář ovladačů pro Windows a Linux. Jeho univerzální driver pod Windows, co se chytí cca od NT po Win10 na všechen jejich hardware (ISA/PCI/USB) je takový nepravděpodobný drahokam. Ten člověk ví o čem mluví. A mluví o spojitosti běhu softwarové časové základny v guest OS, která záleží na "spojitosti virtualizace" (ideálně vyhrazené CPU jádro pro guesta) a zejména na přesnosti/spojitosti/spolehlivosti doručování interruptů HW časovače - což není zrovna triviální požadavek vzhledem k tomu, že guest nevlastní fyzický čipset, ve kterém se tyto časovače vyskytují (vlastní nanejvýš CPU TSC a LAPIC timer, což je myslím trochu málo, on totiž není časovač jako časovač.)

Tradiční moudro bývalo, že ve virtuálu stojí časomíra za vyliž. (Což se na nenáročném klientovi ještě zkousne, ale na NTP serveru ztuha.) Nějakou dobu už ale slýchám dovětek, že moderní verze hypervizorů v tomto směru učinily značný pokrok. Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.

Zcela souhlasím s tím, co už tady napsali jiní: bacha ať časovou základnu guesta nedolaďují na střídačku dva různé mechanismy. Pak se totiž "perou", přestane existovat jediná a jasná zpětnovazební dolaďovací smyčka.

Pokud se týče doladění skokem vs. spojitě, ta volba je samozřejmě kompromis, uvědomte si že při skokovém doladění může čas poskočit *dozadu*, což je v mnoha případech průser. V jiných případech je kriticky žádoucí, aby přesný čas seděl hned po doladění. Záleží na aplikaci = způsobu použití, oblasti nasazení. Je třeba si uvědomit, že pro volnoběh (softwarové) časové základny lokálního OS mezi dvěma "olíznutími upstreamu" je třeba dolaďovat frekvenci tohoto volnoběhu, a že nějaká reziduální nepřesnost bude nastávat pravidelně, ať už dolaďujeme výhradně spojitě nebo výhradně skokem.

Úplně přesnému času se lze přiblížit několika způsoby:
  • dodatečným hardwarem a třeba ještě specializovaným API, které z toho hardwaru bude tahat časové značky
  • slušně přesnou synchronizaci lokálního systémového času OS dokáže poskytnout PPS vstup, ale ten pod Windows pokud vím nelze na generickém PC HW zavést (pod Linuxem ano, skrz sériový či paralelní port, nebo skrz síťovku s HW podporou PTP)
  • což mi připomíná, že z hlavy nevím, jak často dolaďuje frekvenci SW časomíry OS Meinbergovic serviska běžící v přítomnosti Meinbergovic přesných HW hodin (PCI-e) - možná každou sekundu? Každopádně se to té systémové PPSce bude dost blížit
  • v národních laboratořích etalonu času se vyskytují extrémisti, kteří si fázově zavěsí centrální oscilátor PC motherboardu na vnější frekvenční normál, takže pak servosmyčka časomíry v OS rychle zkonverguje ke konkrétní hodnotě, která se dál už prakticky nemění (protože ten mizerný šutr na motherboardu už nevandruje)

Závěrem obligátní poznámka: softwarová systémová časomíra pod Windows má přesnost poměrně omezenou reálnou granularitou časových značek. Za starých časů to bývalo 15.6 ms (perioda scheduleru), tuším od Win7 je to 1 ms, netuším zda v nejnovějších 10/2016 se to třeba dál nezlepšilo. V Linuxu už drahně let není problém, aby ntpd vykazoval reziduální offset v nízkých jednotkách mikrosekund pokud má PPS, nebo cca 20-50 us pokud bere čas po nezatížené LANce od kvalitního stratum 1.


ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Synchronizace času doménových klientů
« Odpověď #16 kdy: 07. 03. 2018, 08:38:41 »
.....
Vaším příspěvkem se téma dostalo na další vyší úroveň a je vidět, že ladění času ve virtualizovaném prostředí není uplně tak triviální věc.
Pročítám teď ty odkazy a podstatnou informací pro mne je:
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.
kde se píše:
________________________________________________________________________________________________________
NTP server was not designed to run inside of a virtual machine. It requires a high resolution system clock, with response times to clock interrupts that are serviced with a high level of accuracy. NTP client is ok to run in some virtualization solutions.

Run NTP on the base OS of the machine, and then have your various guest OSes take advantage of the good clock that is created on the system. Even that may not be enough, as there may be additional tools or kernel options that you need to enable so that virtual machine clients can adequately synchronize their virtual clocks to the physical system clock.

___________________________________________________________________________________________________________
podobně se vyjadřují na tom whitepaperu co jste zmínil https://www.meinbergglobal.com/download/burnicki/time_synchronization_in_virtual_machines.pdf:
___________________________________________________________________________________________________________
Generally it is not advisable to run a VM as time server for other physical machines since the time
provided by such server is usually less accurate and provides significantly more jitter than a physical
machine acting as time server.

___________________________________________________________________________________________________________
Z toho tedy chápu, že bych neměl nechat virtuální stroj poskytovat časovou službu(být časovým serverem) kde čas vychází z jeho samotného.
Ok, ale jak je tomu v případě, že virtuální stroj si ten čas bere z upstreamu jako to mám já (tik.cesnet, tak.cesnet.cz) ?
Je "spolehlivé" vypnout na Hostu synchronizaci času pro Guesta a nechat Guesta si čas řídit z upstreamu?

díky
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Synchronizace času doménových klientů
« Odpověď #17 kdy: 07. 03. 2018, 08:49:22 »
tak jsem si znova precetl vas prispevek a je tam i odpoved na to co se ptám:
Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.

díky
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

Lol Phirae

Re:Synchronizace času doménových klientů
« Odpověď #18 kdy: 07. 03. 2018, 10:57:29 »
Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu

To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Synchronizace času doménových klientů
« Odpověď #19 kdy: 07. 03. 2018, 18:01:46 »
To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.
Učinil jsem tak, klienti jsou synchronizovaní, čas drží přesně
Jen by mě ještě zajímalo jak často si klient čmuchne k DC serveru pro čas, je to průběžně nebo jen při loginu?
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.


Re:Synchronizace času doménových klientů
« Odpověď #20 kdy: 07. 03. 2018, 18:04:04 »
@ZAJDAN: optimální pro DC (z hlediska servírování času) je běžet na holém železe.

Pokud správně chápu bod č.5 a ještě čerstvé osobní potvrzení od Lol Phirae, tak pokud DC musí běžet ve virtuálu, je v tomto specifickém případě vhodné, aby si řešil časomíru sám = DC ve virtuálu si sám bere upstream NTP z divokého internetu a servíruje dál doménovým klientům, na čas od HV (hostitele) kašle a je úkolem HV, aby guestovi časomíru pokud možno nemrvil přerušováním přiděleného procesorového času a rozhasením timer interruptu (což patrně konfiguračně neovlivníte).

Varianta, že DC ve virtuálu si bere čas od HV=hostitele, podle uvedených zdrojů reálně nefunguje. Je to ale specifický případ MS DC. Obecná rada je přesně opačná :-(

Slýchal jsem, že tik a tak jsou docela vytížení. Nevím zda W32time vezme pool.ntp.org = DNS round-robin load-balanced množina NTP serverů rozprostřená po zeměkouli. Pokud chcete jistotu, znamená to postavit nebo koupit 1-2 dedicated stratum 1 servery zavěšené na GPS (o fous horší varianta je DCF77). Se třemi a více NTP servery je to teoreticky odolné dokonce i proti manipulaci jednotlivého NTP serveru (outlier rejection).

Re:Synchronizace času doménových klientů
« Odpověď #21 kdy: 07. 03. 2018, 21:26:34 »
To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.
Učinil jsem tak, klienti jsou synchronizovaní, čas drží přesně
Jen by mě ještě zajímalo jak často si klient čmuchne k DC serveru pro čas, je to průběžně nebo jen při loginu?

Nedokážu najít v dokumentaci, zda to tak skutečně je, ale tipuji, že je blbost, aby w32time fungovala jenom při přihlášeném desktopu. Jsem si skoro jistý, že to funguje i ve stavu "žádný uživatel není přihlášený", pokud je daný stroj přiřazen v AD do domény. Technicky to dává velmi dobrý smysl.

Možná napoví následující úryvek z Vašeho výpisu:

w32tm /query /status
Last Successful Sync Time: 3/6/2018 10:09:33 AM
Poll Interval: 10 (1024s)

Nechte stroj nějakou dobu běžet bez přihlášeného uživatele, pak se přihlaste a zeptejte se uvedeným způsobem.

Není mi jasné, zda ten "poll interval" je pevný. V případě ntpd (parametry minpoll/maxpoll) je perioda dotazování v nějakém rozmezí pseudonáhodná.

Potkal jsem nějaká starší povídání o volbě zdroje času v rozsáhlejší konfiguraci domén (domain forest).
https://tigermatt.wordpress.com/2009/08/01/windows-time-for-active-directory/
https://blogs.msdn.microsoft.com/w32time/2007/09/04/keeping-the-domain-on-time/
Nevím kolik z toho je ještě dneska pravda. Např. jsem žil v domnění že w32time používá NTP i v rámci domény - ale uvedené zdroje mluví o microsoftím vlastním mechanismu NT5DS.

Lol Phirae

Re:Synchronizace času doménových klientů
« Odpověď #22 kdy: 07. 03. 2018, 23:10:45 »
Slýchal jsem, že tik a tak jsou docela vytížení. Nevím zda W32time vezme pool.ntp.org = DNS round-robin load-balanced množina NTP serverů rozprostřená po zeměkouli.

Ale jo, funguje.

Kód: [Vybrat]
> w32tm /query /computer:dc /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0127925s
Root Dispersion: 0.0570451s
ReferenceId: 0x59DDD2BC (source IP:  89.221.210.188)
Last Successful Sync Time: 07.03.2018 23:01:41
Source: 1.cz.pool.ntp.org,0x1
Poll Interval: 10 (1024s)

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Synchronizace času doménových klientů
« Odpověď #23 kdy: 08. 03. 2018, 09:26:35 »
...
Není mi jasné, zda ten "poll interval" je pevný. V případě ntpd (parametry minpoll/maxpoll) je perioda dotazování v nějakém rozmezí pseudonáhodná.
....
našel jsem k tomu nějakou dokumentaci a pokud to dobře chápu, tak se to dá nastavit v registru pomocí ruzných parametrů jsou tam i zmíněné Min Max Pool a třeba i UpdateInterval
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/windows-time-service/windows-time-service-tools-and-settings
zkusím se tím ještě pročíst
anglicky umím ale mám problém tomu rozumět na technické úrovi, konkrétně co dělá ten Mix MaxPool Interval
« Poslední změna: 08. 03. 2018, 09:33:05 od ZAJDAN »
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

Re:Synchronizace času doménových klientů
« Odpověď #24 kdy: 08. 03. 2018, 11:00:57 »
Grammar nazi poznámka:

"pool" [vyslov "půůůl"] znamená bazén, množina, kyblík něčeho předpřipraveného. Případně je to k vidění jako sloveso: něco si předem připravit / nahromadit / dlouhodobě průběžně společnými silami udržovat na hromadě pro sdílené použití. V našem případě množina NTP serverů od které chceme, aby nám vybrala nějaký náhodný server, kterého se máme ptát. (Třeba europalety se taky točí v nějakém sdíleném "poolu".)

"to poll" [vyslov "pollll"] znamená dotázat se. Klasicky přečíst jednorázově nějakou hodnotu z hardwaru. Nebo v tomto případě poslat dotaz upstream NTP serveru / vyžádat si od něj aktuální přesný čas. ("Opinion poll" je průzkum veřejného mínění.)

Odtud vysvětlivka k věci:

Poll interval = jak často se dotazovat.

Minpoll / maxpoll = v jakém rozmezí se má pohybovat poll interval. Přesněji, v případě ntpd se jedná o exponent v mocnině dvou. Takže "minpoll 6" znamená dotazuj se v intervalu ne kratším než 2^6=64 sekund. Reálně se ntpd ptá v intervalu pseudonáhodně zvoleném mezi 2^minpoll až 2^maxpoll [sekund].
http://doc.ntp.org/4.1.1/confopt.htm
Zda mají tyto pojmy shodný význam a datový typ v konfiguraci w32time, to nevím :-)

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Synchronizace času doménových klientů
« Odpověď #25 kdy: 08. 03. 2018, 15:30:20 »
Grammar nazi poznámka:

"pool" [vyslov "půůůl"] znamená bazén, množina, kyblík něčeho předpřipraveného. Případně je to k vidění jako sloveso: něco si předem připravit / nahromadit / dlouhodobě průběžně společnými silami udržovat na hromadě pro sdílené použití. V našem případě množina NTP serverů od které chceme, aby nám vybrala nějaký náhodný server, kterého se máme ptát. (Třeba europalety se taky točí v nějakém sdíleném "poolu".)

"to poll" [vyslov "pollll"] znamená dotázat se. Klasicky přečíst jednorázově nějakou hodnotu z hardwaru. Nebo v tomto případě poslat dotaz upstream NTP serveru / vyžádat si od něj aktuální přesný čas. ("Opinion poll" je průzkum veřejného mínění.)

omlouvám se, to byl překlep a zároveň děkuji za upřesnění na technické rovinně
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.