Come sincronizzare il tempo su macchine virtuali Windows ESXi in un secondo?

12

Sono uno sviluppatore e stiamo utilizzando Quartz.Net, libreria di pianificazione ampiamente utilizzata con archivio di supporto SQL per eseguire cluster di server di lavori (VM su cluster ESXI).

Quartz.Net richiede che il tempo sia sincronizzato tra le istanze del job server e consiglia di utilizzare NTP per esso.

Gli orologi devono trovarsi a meno di un secondo l'uno dall'altro.

I nostri amministratori di sistema utilizzano Windows NTP per sincronizzare l'ora con il controller di dominio. La sincronizzazione delle macchine virtuali con l'host ESXI è disattivata.

Continuano a insistere sul fatto che "entro un secondo" non è un requisito corretto e che non può essere soddisfatto senza dispositivi di sincronizzazione GPS hardware. Il loro SLA e livello di monitoraggio sono "entro 3 minuti".

Stiamo riscontrando un comportamento non sincronizzato delle istanze Quartz periodiche (una volta ogni 2-3 mesi) coerenti con il tempo non sincronizzato.

  1. È corretto per noi chiedere "entro il secondo" o dobbiamo abbandonare del tutto il quarzo?
  2. In caso affermativo, quali modifiche sono consigliate per la nostra configurazione?
windows  vmware-esxi  ntp  time-synchronization 
— Leotsarev
fonte
11
La sincronizzazione con un secondo non è nulla , anche sui server virtuali (che hanno notoriamente scarsa stabilità temporale da soli). Tre minuti?! Fare una risata. Non è possibile gestire una rete in questo modo.
— Lightness Races con Monica,

Risposte:

20

Questo è il 2018. Windows è in grado di mantenere i server sincronizzati entro 2 ms circa, come richiesto dai regolamenti MIFID II. Quindi, il tuo problema non è un problema.

I nostri amministratori di sistema utilizzano Windows NTP per sincronizzare l'ora con il controller di dominio. La sincronizzazione delle macchine virtuali con l'host ESXI è disattivata.

Perché? L'host può gestirlo molto meglio (essendo hardware) e ne hai molti meno. I tuoi amministratori di sistema si sparano al piede, poi si lamentano di sanguinare.

Continuano a insistere sul fatto che "entro un secondo" non è un requisito corretto e che non può essere soddisfatto senza dispositivi di sincronizzazione GPS hardware. Il loro SLA e livello di monitoraggio sono "entro 3 minuti".

VECCHIO - antico - Windows sincronizzato in quel lasso di tempo perché i biglietti Kerberos avevano una validità di 5 minuti.

Ma questo è, come ho detto, il 2018. Il settore finanziario ha requisiti abbastanza brutali in questi giorni e la SM lo ha gestito per - dal 2012, penso. Il 2016 lo ha reso pienamente operativo. La precisione dei millisecondi su Internet è un problema risolto - risolto 50 anni fa in realtà, per una connessione decente. NTP può gestirlo. Potrebbe essere necessario installare una scatola hardware economica se si desidera ridurre il traffico (ovvero creare la propria sorgente temporale NTP di livello 3), ma ciò non è nemmeno costoso.

È corretto per noi chiedere "entro il secondo" o dobbiamo abbandonare del tutto il quarzo?

È necessario programmare per problemi di tempo occasionali, come si farebbe con l'hardware. Ma "entro il secondo" è uno scherzo di un requisito: è banale incontrarsi in circostanze normali.

Alcuni riferimenti:

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/accurate-time

Regolamenti governativi come: precisione di 50 ms per FINRA negli Stati Uniti ESMA (MiFID II) negli Stati Uniti nell'UE.

Molti dettagli e istruzioni lì. Questa è una lettura davvero fantastica se devi risolvere questo problema. Potrebbe essere necessario aggiornare l'hypervisor: parlano di Hyper-V. VMWare dovrebbe essere in grado di fare lo stesso, ma non è sicuro di quanti anni ha la tua versione.

— TomTom
fonte
FWIW, la conformità MiFID II nel settore finanziario [Regno Unito] è incredibilmente scarsa (le banche preferiscono pagare le multe irrisorie piuttosto che preoccuparsi di tutto ciò che hoo-har) ma tecnicamente hai ragione ovviamente.
— Lightness Races con Monica,
Non si tratta di conformità, si tratta di ABILITÀ di essere conformi. MS risolto molto tempo fa. In quanto tale, il "preciso di 3 minuti" che OP parla di scherzo di area.
— TomTom,
Sono d'accordo; questo era solo un lato.
— Lightness Races con Monica,
2
Sono con te che l'NTP è più che abbastanza veloce, ma VMware non consiglia di utilizzare i servizi di integrazione per sincronizzare il tempo, nella maggior parte dei casi (sebbene non in tutti) l'NTP normale fa un lavoro migliore e più veloce.
— HoD
Poiché il problema riguarda il tempo relativo tra i server, è possibile utilizzare NTP per sincronizzarli con switch di rete che a loro volta si sincronizzano con il proprio ISP, senza necessità di hardware aggiuntivo.
— Grahamj42,
6

È corretto per noi chiedere "entro il secondo" o dobbiamo abbandonare del tutto il quarzo?

Ci sono molte ottime ragioni per cui diversi stack di applicazioni necessitano di uno stretto controllo del tempo e ciò che Quartz chiede è tutt'altro che insolito.

In caso affermativo, quali modifiche sono consigliate per la nostra configurazione?

La soluzione migliore è fare in modo che ogni singola parte del sistema utilizzi NTP e puntarli alla stessa coppia di server NTP. Quindi gli host ESXi e le VM in esecuzione su di essi, tutti usando le stesse fonti NTP, lo stesso per qualsiasi altra cosa coinvolta. In questo modo, anche se i server NTP sono "fuori servizio", almeno ogni parte del sistema è aggiornata l'una con l'altra.

— Chopper3
fonte
4

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary

Supporto ad alta precisione per Windows 8.1 e 2012 R2 (o precedenti)

Le versioni precedenti di Windows (precedenti a Windows 10 1607 o Windows Server 2016 1607) non possono garantire tempi estremamente precisi. Il servizio Ora di Windows su questi sistemi:

  • Fornito l'accuratezza temporale necessaria per soddisfare i requisiti di autenticazione Kerberos versione 5

  • Fornito tempo vagamente accurato per client e server Windows uniti a una foresta Active Directory comune

Requisiti di precisione più rigorosi erano al di fuori delle specifiche di progettazione del servizio ora di Windows su questi sistemi operativi e non sono supportati.

Windows 10 e Windows Server 2016

La precisione temporale in Windows 10 e Windows Server 2016 è stata notevolmente migliorata, pur mantenendo la piena compatibilità NTP con le versioni precedenti di Windows. Nelle giuste condizioni operative, i sistemi che eseguono Windows 10 o Windows Server 2016 e le versioni più recenti possono fornire una precisione di 1 secondo, 50 ms (millisecondi) o 1 ms.

Precisione target: 1 secondo (1s)

Per ottenere la precisione 1s per una macchina target specifica rispetto a una fonte di tempo altamente accurata:

  • Il sistema di destinazione deve eseguire Windows 10, Windows Server 2016.

  • Il sistema di destinazione deve sincronizzare il tempo da una gerarchia NTP di server del tempo, che culmina in una fonte di tempo NTP altamente accurata e compatibile con Windows.

  • Tutti i sistemi operativi Windows nella gerarchia NTP sopra menzionati devono essere configurati come documentato nella documentazione Configurazione di sistemi per alta precisione.

  • La latenza cumulativa della rete unidirezionale tra destinazione e origine non deve superare i 100 ms. Il ritardo cumulativo della rete viene misurato aggiungendo i singoli ritardi unidirezionali tra coppie di nodi client-server NTP nella gerarchia che iniziano con la destinazione e terminano all'origine. Per ulteriori informazioni, consultare il documento di sincronizzazione temporale ad alta precisione.

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/configuring-systems-for-high-accuracy

— Greg Askew
fonte
In realtà, stiamo usando Windows 2012R2. Sembra che sia la radice del problema (insieme alla non sincronizzazione con l'host ESXI)
— Leotsarev
1
@Leotsarev: se si tratta di membri di dominio, non devono sincronizzarsi con l'host di macchine virtuali.
— Greg Askew,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.