Condividi tramite

Miglioramenti dell'accuratezza dell'ora per Windows Server 2016

Windows Server 2016 ha migliorato gli algoritmi che viene ora corretta e la condizione l'orologio locale per sincronizzare con l'ora UTC (Coordinated Universal Time). NTP (Network Time Protocol) utilizza quattro valori per calcolare l'offset dell'ora, in base ai timestamp del client richiesta/risposta e richiesta/risposta del server. Tuttavia, le reti sono rumorose e possono essere presenti picchi di dati dal NTP a causa della congestione della rete e altri fattori che influiscono sulla latenza di rete. Gli algoritmi di Windows Server 2016 calcolano la media di questo rumore utilizzando diverse tecniche che si traduce in un orologio stabile e accurato. L'origine che utilizziamo per l'accuratezza nel tempo fa riferimento anche a un'API migliorata che offre una migliore risoluzione. Grazie a questi miglioramenti, è possibile ottenere una precisione di 1 ms per quanto riguarda l'UTC in un dominio.

Hyper-V

Windows Server 2016 ha migliorato il servizio TimeSync Hyper-V. I miglioramenti includono un'ora iniziale più accurata sulla macchina virtuale (VM) per l'avvio o il ripristino della VM e la correzione della latenza di interrupt per gli esempi usati dal servizio Ora di Windows (W32time). Questo miglioramento consente di rimanere entro 10µs dall'host con una radice della media quadratica (che indica la varianza) pari a 50µs, anche in un computer con il 75% del carico. Per altre informazioni, vedi Architettura Hyper-V.

Nota

Carico è stato creato utilizzando benchmark prime95 e usando un profilo bilanciato.

Il livello strato che ospita i report al guest è più trasparente. In precedenza, l'host avrebbe rappresentato un strato predefinito pari a 2, indipendentemente dalla relativa accuratezza. Con le modifiche apportate in Windows Server 2016, l'host segnala uno Strato 1 maggiore dello Strato dell'host, con un conseguente miglioramento dell'ora per i guest virtuali. Lo Strato dell'host è determinato da W32Time in modo normale in base al relativo tempo di origine. I guest Windows Server 2016 aggiunti al dominio trovano l'orologio più accurato, piuttosto del valore predefinito all'host. Per questo motivo, è consigliabile disattiva manualmente il Provider servizi orari Hyper-V per computer che partecipano a un dominio in Windows Server 2012 R2 e versioni precedenti.

Monitoraggio

Sono stati aggiunti i contatori di Performance Monitor. Questi contatori consentono di stabilire, monitorare e risolvere accuratezza di tempo. Nella tabella seguente sono elencati i contatori.

Contatore Descrizione
Offset ora calcolata L'ora assoluta offset tra l'orologio di sistema e l'origine di tempo scelto, come calcolato dal servizio W32Time in microsecondi. Quando è disponibile un nuovo campione valido, il tempo calcolato viene aggiornato con la differenza di orario indicata nell'esempio. Questo tempo è l'offset effettivo dell'ora dell'orologio locale. W32Time avvia correzione orologio utilizzando questo offset e aggiorna l'ora calcolata tra gli esempi con offset dell'ora rimanenti che deve essere applicato in base all'orologio locale. Accuratezza orologio può essere rilevato tramite questo contatore delle prestazioni con un intervallo di polling bassa (ad esempio, 256 secondi o meno) e cercando il valore del contatore di dimensioni minori rispetto al limite di accuratezza orologio desiderato.
Regolazione di frequenza di clock La regolazione dell'orologio assoluto frequenza ottenuta al clock di sistema locale con W32Time in parti per miliardo. Questo contatore consente di visualizzare le azioni da W32Time.
Ritardo di andata e ritorno NTP Ritardo di andata e ritorno più recente riscontrato dal client NTP ricevere una risposta dal server in microsecondi. Questo ritardo è il tempo trascorso nel client NTP tra la trasmissione di una richiesta per il server NTP e la ricezione di una risposta valida dal server. Questo contatore consente di caratterizzare i ritardi esperti dal client NTP. Round trip più grande o variabile è possibile aggiungere calcoli ora NTP, che a sua volta potrebbero influire sull'accuratezza della sincronizzazione dell'ora tramite NTP di disturbo.
Numero di origine Client NTP Numero di origini dell'ora NTP attive utilizzate dal client NTP. Questo numero è un conteggio degli indirizzi IP distinti attivi dei server di riferimento ora che rispondono alle richieste del client. Questo numero potrebbe essere maggiore o minore di peer configurato, a seconda della risoluzione del DNS di nomi di peer e possibilità di copertura corrente.
Il Server NTP richieste in ingresso Numero di richieste ricevute dal server NTP (richieste/sec).
Risposte in uscita del Server NTP Numero di richieste di una risposta dal server NTP (risposte/sec).

I primi tre contatori destinati a scenari per la risoluzione dei problemi di accuratezza. Per maggiori informazioni, consultare la sezione Risolvere i problemi di accuratezza dell'ora e NTP più avanti in questo articolo. Gli ultimi tre contatori riguardano scenari server NTP e sono utile quando determinare il carico e la base delle prestazioni correnti.

Aggiornamenti della configurazione per ambiente

La tabella seguente descrive le modifiche apportate alla configurazione predefinita tra Windows Server 2016 e le versioni precedenti per ogni ruolo. Le impostazioni per Windows Server 2016 e Windows 10 Anniversary Update (build 14393) ora sono specifiche, pertanto vengono visualizzate come colonne separate.

Ruolo Impostazione Windows Server 2016 Windows 10 Windows Server 2012 R2
Windows Server 2008 R2
Windows 10
Server autonomo/Nano Server
Server di riferimento ora time.windows.com ND time.windows.com
Frequenza di polling 64 - 1024 secondi ND Una volta alla settimana
Frequenza di aggiornamento del clock Una volta al secondo ND Una volta all'ora
Client autonomo
Server di riferimento ora ND time.windows.com time.windows.com
Frequenza di polling ND Una volta al giorno Una volta alla settimana
Frequenza di aggiornamento del clock ND Una volta al giorno Una volta all'ora
Controller di dominio
Server di riferimento ora PDC/GTIMESERV ND PDC/GTIMESERV
Frequenza di polling 64 -1024 secondi ND 1,024 - 32,768 secondi
Frequenza di aggiornamento del clock Una volta al secondo ND Una volta all'ora
Server membro di dominio
Server di riferimento ora Controller di dominio ND Controller di dominio
Frequenza di polling 64 -1024 secondi ND 1,024 - 32,768 secondi
Frequenza di aggiornamento del clock Una volta al secondo ND Una volta ogni 5 minuti
Client membro di dominio
Server di riferimento ora ND Controller di dominio Controller di dominio
Frequenza di polling ND 1,204 - 32,768 secondi 1,024 - 32,768 secondi
Frequenza di aggiornamento del clock ND Una volta ogni 5 minuti Una volta ogni 5 minuti
Guest Hyper-V
Server di riferimento ora Sceglie l'opzione migliore in base allo Strato dell'host e del server di riferimento ora Sceglie l'opzione migliore in base allo Strato dell'host e del server di riferimento ora Per impostazione predefinita, viene usato l'host
Frequenza di polling In base al ruolo precedente In base al ruolo precedente In base al ruolo precedente
Frequenza di aggiornamento del clock In base al ruolo precedente In base al ruolo precedente In base al ruolo precedente

Nota

Per Linux in Hyper-V, consultare la sezione Consentire Linux per usare ora host Hyper-V.

Impatto dell'aumento del polling e la frequenza di aggiornamento dell'orologio

Per fornire più esatta del tempo, che consentono di apportare piccole modifiche a più di frequente per aumentare i valori predefiniti per il polling di frequenze e gli aggiornamenti di orologio. Questa modifica causa un maggior traffico UDP (User Datagram Protocol)/NTP. Questi pacchetti sono piccoli, quindi dovrebbe esserci poco o nessun effetto sui collegamenti a banda larga. Il vantaggio è che l'ora deve essere migliore di un'ampia gamma di hardware e ambienti.

Per i dispositivi della batteria di backup, un aumento della frequenza di polling può causare problemi. I dispositivi alimentati a batteria non memorizzano l'ora mentre sono spenti. Quando si riprendono, potrebbero essere necessarie correzioni frequenti in base all'orologio. Un aumento della frequenza di polling causa l'instabilità dell'orologio e un maggiore utilizzo di energia. Consigliamo di non modificare le impostazioni predefinite di client.

I controller di dominio (DC) devono essere interessati minimamente anche con l'effetto moltiplicato degli aggiornamenti dei client NTP in un dominio di Active Directory. NTP dispone di un quantità consumo di risorse inferiore rispetto a un effetto marginale e altri protocolli. Si hanno più probabilità di raggiungere i limiti per altre funzionalità di dominio prima di essere interessati dalle impostazioni di aumento per Windows Server 2016. Active Directory usa NTP sicuro, che tende a sincronizzare il tempo in modo meno accurato rispetto a NTP semplice. È stato verificato che è possibile aumentare le prestazioni fino ai client a due Strati lontano dal controller di dominio primario (PDC).

Un piano conservativo, è necessario riservare fino a 100 richieste NTP al secondo per ogni core. Ad esempio, con un dominio costituito da quattro controller di dominio con quattro core, si deve essere in grado di servire 1600 richieste NTP al secondo. Se si dispone di 10.000 client configurato per sincronizzare l'ora ogni 64 secondi e le richieste vengono ricevute in modo uniforme nel tempo, si vedrà 10.000/64 bit o circa 160 richieste al secondo, distribuiti in tutti i controller di dominio. Questa cifra rientra facilmente nelle 1600 richieste NTP al secondo in questo esempio. Questi consigli di pianificazione sono prudenti e dipendono in gran parte dalla rete, dalla velocità del processore e dai carichi. Come sempre, stabilire e testare negli ambienti.

Se i controller di dominio vengono eseguiti con un considerevole carico della CPU, superiore al 40%, tale carico quasi sicuramente aggiungerà disturbi alle risposte NTP e vi saranno ripercussioni sulla precisione dell'ora nel dominio. Anche in questo caso, è necessario eseguire il test nell'ambiente per comprendere i risultati effettivi.

Misure di accuratezza ora

Per misurare l'accuratezza di tempo per Windows Server 2016, abbiamo utilizzato diversi strumenti, metodi e gli ambienti. È possibile utilizzare queste tecniche per misurare e ottimizzare l'ambiente e determinare se i risultati di accuratezza soddisfano i requisiti.

Metodologia

L'orologio di origine di dominio è costituita da due server NTP elevata precisione con hardware GPS. Abbiamo utilizzato anche un computer di test di riferimento separata per le misurazioni, che dispone di hardware GPS precisione elevata installato da un altro produttore. Per alcuni dei test, è necessario un orologio accurato e affidabile di origine da utilizzare come riferimento oltre l'orologio di origine di dominio.

Abbiamo utilizzato quattro metodi diversi per misurare l'accuratezza con le macchine fisiche e virtuali. Più metodi forniti mezzi indipendenti per convalidare i risultati.

  1. Misurare l'orologio locale, che è condizionato da w32tm contro il computer di test di riferimento che disponga di hardware GPS separato.

  2. Misura NTP ping dal server NTP per i client usando W32tm stripchart.

  3. Misura NTP ping dal client al server NTP usando W32tm stripchart.

  4. Misura Hyper-V risultante dall'host al guest usando TSC (Time Stamp Counter). Questo contatore viene condiviso tra le partizioni e l'ora di sistema in entrambe le partizioni. È stata calcolata la differenza tra l'ora di host e il tempo del client nella VM. Quindi abbiamo usato l'orologio TSC per interpolare l'ora dell'host rispetto al guest, in quanto le misurazioni non avvengono contemporaneamente. Inoltre, abbiamo usato l'orologio del volume segmentato nel tempo per tenere conto dei ritardi e della latenza nell'API.

W32tm è incorporato, ma gli altri strumenti utilizzati durante i test sono disponibili per il repository di Microsoft su GitHub come open source per i test e l'uso. Per maggiori informazioni su come usare gli strumenti per eseguire le misurazioni, consultare il Wiki sugli strumenti di calibrazione dell'ora di Windows.

I risultati del test illustrati di seguito sono un subset delle misure che è eseguita in uno degli ambienti di test. Viene illustrato l'accuratezza mantenuta all'inizio della gerarchia temporale e client del dominio figlio alla fine della gerarchia ora. Questi risultati vengono confrontati con le stesse macchine in una topologia 2012 sulla base per il confronto.

Topologia

Per il confronto, abbiamo testato le topologie basate su Windows Server 2012 R2 e Windows Server 2016. Entrambe le topologie sono costituiti da due computer host Hyper-V fisici che fanno riferimento a un computer Windows Server 2016 con GPS orologio hardware installato. Ogni host esegue tre guest a un dominio Windows, che vengono disposte in base alla topologia seguente. Le righe rappresentano la gerarchia ora e il protocollo/trasporto utilizzato.

Diagramma che mostra la topologia ora di Windows con un solo client di dominio figlio in esecuzione nel primo host Hyper-V.

Diagramma che mostra la topologia ora di Windows con due client di dominio figlio. Una viene eseguita nel primo host Hyper-V e un'altra viene eseguita nel secondo host Hyper-V.

Panoramica risultati grafici

I due grafici seguenti rappresentano l'accuratezza di tempo per due membri specifici di un dominio in base alla topologia precedente. Ogni grafico visualizza i risultati sovrapposti di Windows Server 2012 R2 e 2016, il che dimostra i miglioramenti in modo visivo. L'accuratezza è stata misurata dall'interno del computer guest rispetto all'host. I dati grafici rappresentano un sottoinsieme dell'intero set di test eseguiti e illustrano gli scenari del caso migliore e peggiore.

Diagramma che mostra la topologia ora di Windows con il server PDC del dominio radice e i server client di dominio figlio nel primo host Hyper-V chiamato.

Prestazioni di PDC dominio radice

Il PDC radice viene sincronizzato con l'host Hyper-V (tramite VMIC) che è un Windows Server 2016 con hardware GPS che ha dimostrato di essere accurato e stabile. Questo requisito è fondamentale per l'accuratezza di 1-ms, che viene visualizzata come area ombreggiata identificata dalla chiamata.

Diagramma che mostra il dominio radice.

Prestazioni del client del dominio figlio

Il client del dominio figlio è collegato a un PDC del dominio figlio che comunica al PDC radice. Anche l'ora è all'interno del requisito 1-ms.

Diagramma che mostra il client di dominio figlio.

Test sulla lunga distanza

Il grafico seguente confronta un hop di rete virtuale a sei hop di rete fisica con Windows Server 2016. Due grafici sono sovrapposti tra loro con trasparenza per visualizzare i dati sovrapposti. Hop di rete crescente significa una latenza maggiore e deviazioni di tempo maggiori. Il grafico viene ingrandito e vengono ingranditi anche i limiti 1-ms, rappresentati dall'area ombreggiata. Come può notare, il tempo è ancora all'interno di 1 ms con più hop. Lo spostamento è in negativo e questo dimostra un'asimmetria di rete. Ciascuna rete è diversa e le misurazioni dipendono da svariati fattori ambientali.

Diagramma che mostra il test a distanza prolungata.

Migliori pratiche per la misurazione accurata del tempo

Seguire queste migliori pratiche per la misurazione accurata del tempo.

Orologio origine solido

L'ora della macchina è corretta quanto l'orologio origine con il quale viene sincronizzata. Per ottenere 1 ms di accuratezza, è necessario avere hardware GPS o appliance per l'ora sulla rete a cui fare riferimento come orologio di origine master. L'utilizzo del valore predefinito di time.windows.com potrebbe non fornire un'origine ora stabile e locale. Via via che ci si allontana dall'orologio origine, la rete influisce sulla precisione. Un orologio di origine master in ciascun data center è necessario per una maggiore accuratezza.

Opzioni hardware GPS

Diverse soluzioni hardware possono offrire l'ora esatta. In generale, le soluzioni oggi sono basate su antenne GPS. Le soluzioni radio e modem dial-up utilizzano linee dedicate. Si collegano alla rete come un appliance o al PC, ad esempio Windows, tramite un PCIe o un dispositivo USB. Diverse opzioni forniscono livelli diversi di precisione e come sempre, i risultati dipendono dall'ambiente. Le variabili che influiscono sull'accuratezza includono disponibilità del GPS, stabilità e carico di rete e hardware del PC. Questi fattori sono tutti importanti quando si sceglie un orologio origine, che rappresenta un requisito per ottenere un'ora stabile e accurata.

Dominio e ora sincronizzazione

I membri del dominio utilizzano la gerarchia dei domini per determinare quali computer utilizzano come origine per sincronizzare l'ora. Ogni membro del dominio trova un altro computer con cui eseguire la sincronizzazione e lo salva come orologio origine. Ogni tipo di membro del dominio segue un diverso set di regole per un orologio di origine di sincronizzazione dell'ora. Il PDC nella radice della foresta è l'origine orologio predefinita per tutti i domini. Di seguito sono elencati diversi ruoli e descrizioni di livello elevato su come trovare un'origine:

  • Controller di dominio con ruolo PDC: questa macchina è l'origine ora autorevole per un dominio. Ha il tempo più accurato disponibile nel dominio. Deve essere sincronizzato con un controller di dominio nel dominio padre, tranne nei casi in cui il ruolo GTIMESERV è abilitato.
  • Qualsiasi altro controller di dominio: questo computer funge da un'origine dell'ora per i client e server membro del dominio. Un controller di dominio può sincronizzare con il PDC del dominio o qualsiasi controller di dominio nel dominio padre.
  • Server membro/client: questo computer è possibile sincronizzare con qualsiasi controller di dominio o il PDC del dominio o un controller di dominio o PDC del dominio padre.

Un sistema di punteggio in base ai candidati disponibili, viene utilizzato per trovare la migliore fonte di tempo. Il sistema prende in considerazione l'affidabilità dell'origine dell'ora e il relativo percorso. Questo controllo si verifica una volta quando il servizio orario è stato avviato. Se è necessario disporre di un controllo più preciso della modalità Sincronizza ora, è possibile aggiungere i server tempestivamente in posizioni specifiche o aggiungere caratteristiche di ridondanza. Per maggiori informazioni, consultare la sezione Specificare un servizio orario locale affidabile usando GTIMESERV.

Ambienti del sistema operativo misti (Windows Server 2012 R2 e Windows Server 2008 R2)

Sebbene sia necessario un ambiente di dominio di Windows Server 2016 puro per una maggiore accuratezza, esistono comunque dei vantaggi in un ambiente misto. La distribuzione di Windows Server 2016 Hyper-V in un dominio di Windows Server 2012 offre vantaggi ai guest grazie ai miglioramenti accennati in precedenza, ma solo se i guest sono anch'essi su Windows Server 2016. Un PDC Windows Server 2016 è in grado di offrire un'ora più accurata a causa di algoritmi migliorati; quindi, si stratta di un'origine più stabile. Poiché la sostituzione del PDC potrebbe non essere un'opzione applicabile, è possibile invece aggiungere un controller di dominio Windows Server 2016 con il ruolo GTIMESERV impostato; ciò garantirebbe un miglioramento dell'accuratezza per il dominio. Un controller di dominio Windows Server 2016 è in grado di offrire un'ora più accurata ai client ora downstream, tuttavia, questa è valida solo quanto la relativa ora NTP di origine.

Come indicato in precedenza, la frequenza di polling e l'aggiornamento dell'orologio sono stati modificati con Windows Server 2016. Queste frequenze possono essere modificate manualmente per il controller di dominio di livello inferiore o applicati tramite criteri di gruppo. Queste configurazioni non sono state testate, ma dovrebbero comportarsi correttamente in Windows Server 2008 R2 e Windows Server 2012 R2 e offrire alcuni vantaggi.

Versioni precedenti Windows Server 2016 presentavano dei problemi con la gestione accurata dell'orario, e ciò ha provocato la deviazione dell'ora di sistema immediatamente dopo una modifica apportata. Per questo motivo, ottenere frequentemente esempi da un'origine NTP accurata e condizionare l'orologio locale con i dati porta a una lieve deviazione negli orologi di sistema nel periodo di campionamento. Il risultato è una migliore gestione dell'orario nelle versioni del sistema operativo di livello inferiore. L'accuratezza migliore osservata è stata di circa 5 ms quando un client Windows Server 2012 R2 NTP, configurato con le impostazioni di elevata precisione, ha sincronizzato l'ora da un Windows Server 2016 NTP accurato.

In alcuni scenari che riguardano i controller di dominio guest Hyper-V TimeSync, gli esempi possono interrompere la sincronizzazione dell'ora di dominio. Questo problema non deve più sussistere per i guest Windows Server 2016 in esecuzione sugli host di Windows Server 2016 Hyper-V.

Per disabilitare il servizio TimeSync Hyper-V in modo che non fornisca più esempi a W32Time, impostare la seguente chiave del registro guest:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Consentire a Linux di usare l'ora host Hyper-V

Per i Guest Linux in esecuzione in Hyper-V, i client sono in genere configurati per utilizzare il daemon NTP per la sincronizzazione dell'ora rispetto al server NTP. Se la distribuzione Linux supporta il protocollo versione 4 TimeSync e il guest Linux ha abilitato il servizio di integrazione TimeSync, viene sincronizzato con l'ora dell'host. Questo scenario potrebbe comportare una gestione dell'orario incoerente se sono abilitati entrambi i metodi.

Per eseguire la sincronizzazione esclusivamente con l'ora dell'host, è consigliabile disabilitare la sincronizzazione dell'ora NTP con uno dei due metodi seguenti:

  • Disabilitare tutti i server NTP nel file ntp.conf.
  • Disabilitare il daemon NTP.

In questa configurazione, il parametro di riferimento ora è l'host. La frequenza di Polling è 5 secondi e la frequenza di aggiornamento dell'orologio è 5 secondi.

Per sincronizzare esclusivamente tramite NTP, è consigliabile disabilitare il servizio di integrazione TimeSync nel guest.

Nota

Il supporto per l'ora esatta con i guest Linux richiede una funzionalità supportata solo nei kernel Linux upstream più recenti. La funzionalità non è ancora ampiamente disponibile in tutte le distribuzioni Linux. Per maggiori informazioni sulle distribuzioni supportate, consultare la sezione Macchine virtuali Linux e FreeBSD supportate per Hyper-V in Windows.

Specificare un servizio orario locale affidabile usando GTIMESERV

È possibile specificare uno o più controller di dominio come orologi origine accurati utilizzando il flag Good Time Server GTIMESERV. Ad esempio, specifici controller di dominio dotati di hardware GPS possono essere contrassegnati come un GTIMESERV. Questo flag garantisce che il dominio faccia riferimento a un orologio in base all'hardware GPS.

Nota

Maggiori informazioni sui flag di dominio sono reperibili nella documentazione del protocollo MS-ADTS.

TIMESERV è un altro flag di Servizi di dominio correlato che indica se un computer è attualmente autorevole, che può cambiare in caso di perdita di connessione da parte di un controller di dominio. Un controller di dominio in questo stato restituisce Unknown Stratum quando viene eseguita una query tramite NTP. Dopo aver tentato più volte, il controller di dominio registra System Event Time-Service Event 36.

Se si desidera configurare un controller di dominio come GTIMESERV, configurarlo manualmente usando il seguente comando. In questo caso, il controller di dominio usa un altro computer come l'orologio master. Questo computer potrebbe essere un appliance o un computer dedicato.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Nota

Per maggiori informazioni, consultare la sezione Configurare il servizio orario di Windows

Se il controller di dominio ha installato l'hardware GPS, usare i seguenti passaggi per disabilitare il client NTP e abilitare il server NTP.

Avviare disabilitando il client NTP e abilitare il server NTP usando queste modifiche chiave del registro:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

A questo punto, riavviare il servizio Windows Time:

net stop w32time && net start w32time

Infine, significa che il computer dispone di un'origine orario affidabile:

w32tm /config /reliable:yes /update

Per verificare che le modifiche sono state eseguite correttamente, eseguire i comandi seguenti che influiscono sui risultati mostrati qui:

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 su piattaforme virtuali di terze parti

Quando Windows viene virtualizzato, per impostazione predefinita, Hypervisor ha la responsabilità di fornire l'ora. I membri aggiunti al dominio devono tuttavia essere sincronizzati con il controller di dominio per consentire il corretto funzionamento di Active Directory. È consigliabile disabilitare la virtualizzazione dell'ora tra il guest e l'host di qualsiasi piattaforma virtuale di terze parti.

Scoprire la gerarchia

Poiché la catena dalla gerarchia temporale all'origine orologio master è dinamica in un dominio e viene negoziata, è necessario eseguire una query sullo stato di un particolare computer per comprenderne l'origine orario e la catena fino all'orologio di origine master. Queste informazioni consentono di diagnosticare problemi di sincronizzazione dell'ora.

Se si desidera risolvere i problemi relativi a un client specifico, il primo passaggio consiste nel comprendere la relativa origine orario utilizzando questo comando w32tm:

w32tm /query /status

Tra le altre cose, i risultati mostrano l'origine. L'origine indica con chi viene sincronizzato l'orario nel dominio. Questo è il primo passaggio di questa gerarchia orario della macchina. Successivamente, usare la voce di origine dal comando precedente e usare il parametro /stripchart per trovare l'origine dell'ora successiva nella catena.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Anch'esso utile, il comando seguente elenca ogni controller di dominio che trova nel dominio specificato e viene visualizzato un risultato che consente di determinare ogni partner. Questo comando include i computer che sono stati configurati manualmente.

w32tm /monitor /domain:my_domain

Usando l'elenco, è possibile tracciare i risultati tramite il dominio e comprendere la gerarchia, nonché l'offset dell'ora a ogni passaggio. Individuando il punto in cui la differenza di orario Ottiene peggiorare in modo significativo, è possibile individuare la radice di ora non corretto. Da qui, provare a comprendere perché tale orario non è corretto attivando la registrazione w32tm.

Usare Criteri di gruppo

È possibile usare Criteri di gruppo per ottenere una maggiore accuratezza, ad esempio assegnando i client per l'uso di server NTP specifici, o per controllare come sono configurati i sistemi operativi di versione precedente in caso di virtualizzazione. Di seguito è riportato un elenco di possibili scenari e impostazioni di criteri di gruppo pertinenti:

Domini virtualizzati: per controllare i controller di dominio virtualizzati in Windows Server 2012 R2 in modo che sincronizzino l'ora con il relativo dominio, anziché con l'host Hyper-V, è possibile disabilitare questa voce del registro. Per il PDC, non è opportuno disabilitare la voce perché l'host Hyper-V fornisce l'origine ora più stabile. La voce del registro richiede di riavviare W32Time dopo essere stata modificata.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Carichi sensibili accuratezza: per i carichi sensibili di accuratezza di orario, è possibile configurare gruppi di computer per impostare i server NTP e le relative impostazioni di tempo, ad esempio il polling e l'orologio di frequenza di aggiornamento. Questa attività viene in genere gestita dal dominio, ma per un maggiore controllo è possibile indirizzare macchine specifiche in modo da puntare direttamente in base all'orologio master.

Impostazione di Criteri di gruppo Nuovo valore
NtpServer ClockMasterName,0x8
MinPollInterval 6-secondi 64
MaxPollInterval 6
UpdateInterval 100 – una volta al secondo
EventLogFlags 3 – tutte le registrazioni speciali

Nota

Le impostazioni NtpServer e EventLogFlags si trovano in System\Windows Time Service\Time Providers usando le impostazioni Configura client NTP Windows. Le altre tre si trovano in System\Windows Time Service usando le impostazioni Configurazione globale.

Remoto carichi sensibili accuratezza remota : per i sistemi in domini di branch per istanza al dettaglio e il credito settore PCI (Payment), Windows utilizza le informazioni del sito corrente e DC Locator per trovare un controller di dominio locale, a meno che non esiste un manuale NTP ora origine configurata. Questo ambiente richiede 1 secondo di accuratezza, che utilizza più veloce convergenza sull'ora corretta. Questa opzione consente a W32Time di spostare l'orologio indietro. Se questo comportamento è accettabile e soddisfa le esigenze, è possibile creare i criteri seguenti. Come con qualsiasi ambiente, garantisce a test e linea di base della rete.

Impostazione di Criteri di gruppo Nuovo valore
MaxAllowedPhaseOffset 1, ma se più di un secondo, impostare l'orologio per correggere l'ora.

L'impostazione MaxAllowedPhaseOffset si trova sotto System\Windows Time Service usando le impostazioni Configurazione globale.

Nota

Per maggiori informazioni su criteri di gruppo e le voci correlate, consultare la sezione Strumenti di Windows Time e le impostazioni dell'articolo in TechNet.

Considerazioni di Azure e Windows IaaS

Di seguito sono riportati alcuni punti da considerare per Iaas (Infrastructure as a service) di Azure e Windows.

Macchina virtuale di Azure: Active Directory Domain Services

Se la VM di Azure che esegue Active Directory Domain Services fa parte di una foresta Active Directory locale esistente, è necessario disabilitare TimeSync (VMIC). Questa azione consente a tutti i controller di dominio della foresta, sia fisici che virtuali, di usare una gerarchia di sincronizzazione una tantum. Per maggiori informazioni, consultare la sezione Esecuzione di controller di dominio in Hyper-V.

Macchina virtuale di Azure: Computer di dominio

Se si ospita un computer a un dominio a una foresta di Active Directory esistente, virtuale o fisica, la procedura consigliata è disattivare TimeSync per il guest e verificare che W32Time sia configurato per la sincronizzazione con un controller di dominio tramite la configurazione di tempo per Type=NTP5.

Macchina virtuale di Azure: Computer del gruppo di lavoro autonomo

Se la VM di Azure non è associata a un dominio e non è un controller di dominio, è consigliabile mantenere la configurazione dell'ora predefinita in modo che la VM si sincronizzi con l'host.

L'applicazione Windows richiede l'ora esatta

Di seguito alcune azioni che è possibile eseguire se l'applicazione Windows richiede l'ora accurata.

Timestamp API

I programmi che richiedono la massima accuratezza in relazione a UTC, e non il semplice trascorrere del tempo, devono usare l'API GetSystemTimePreciseAsFileTime. Usare questa API garantisce che l'applicazione ottenga l'orario di sistema, che è condizionato dal servizio Windows Time.

Prestazioni UDP

Se si dispone di un'applicazione che usa la comunicazione UDP per le transazioni ed è importante ridurre al minimo la latenza, esistono alcune voci correlate del registro che è possibile usare per configurare un intervallo di porte da escludere dal motore di filtro base. Questa azione migliora la latenza e aumenta la velocità effettiva. Tuttavia, le modifiche al Registro di sistema devono essere limitate agli amministratori esperti. Questa soluzione alternativa esclude le porte dalla protezione da parte del firewall. Per maggiori informazioni, consultare i riferimenti seguenti.

Per Windows Server 2012 e Windows Server 2008, si dovrà installare prima un hotfix. Per maggiori informazioni, consultare la sezione Perdita di datagrammi quando viene eseguita un'applicazione ricevitore multicast in Windows 8 e in Windows Server 2012.

Aggiornare driver di rete

Alcuni fornitori di rete dispongono di aggiornamenti di driver che migliorano le prestazioni per quanto riguarda la latenza di driver e memorizzare nel buffer i pacchetti UDP. Contattare il fornitore della rete per verificare se sono disponibili aggiornamenti per facilitare la velocità effettiva UDP.

Registrazione per scopi di controllo

Per garantire la conformità alle normative di tracciamento orario, è possibile archiviare manualmente i log w32tm, i log eventi e informazioni di Performance Monitor. In un secondo momento, le informazioni archiviate consente di attestare la conformità in un momento specifico in passato. I seguenti fattori vengono utilizzati per indicare l'accuratezza:

  1. Accuratezza orologio usando il contatore Performance Monitor Computed Time Offset. Questo contatore mostra l'orologio con l'accuratezza desiderata.
  2. Origine orologio per Peer Response from nei log w32tm. Dopo il testo del messaggio vi è l'indirizzo IP o VMIC, che descrive l'origine dell'orario e quella successiva nella catena di orologi di riferimento per la convalida.
  3. Stato della condizione dell'orologio usando i log w32tm per controllare che ClockDispl Discipline: \*SKEW\*TIME\* si stia verificando. Indica che lo stato indichi che w32tm al momento è attivo.

Registrazione degli eventi

Per ottenere la storia completa, sono necessario anche le informazioni del registro eventi. Raccogliendo il registro eventi di sistema e filtrando i dati in base a Time-Server, Microsoft-Windows-Kernel-Boot, Microsoft-Windows-Kernel-General, potresti riuscire a scoprire se esistono altri fattori che hanno modificato l'ora, ad esempio terze parti. Questi registri potrebbero essere necessari per escludere interferenze esterne. I criteri di gruppo possono influire sulle quali registri eventi vengono scritti nel log. Per maggiori informazioni, consultare la sezione precedente Usare criteri di gruppo.

Registrazione debug W32Time

Per abilitare w32tm per scopi di controllo, il comando seguente consente di abilitare una registrazione che visualizza gli aggiornamenti periodici dell'orologio e indica l'orologio di origine. Riavviare il servizio per abilitare la registrazione di nuovi.

Per maggiori informazioni, consultare la sezione Attivare la registrazione debug nel servizio di Windows Time.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Monitoraggio prestazioni

Il servizio Windows Time di Windows Server 2016 Windows espone i contatori delle prestazioni che può essere usati per raccogliere la registrazione per il controllo. Questi contatori possono essere registrati in locale o in remoto. È possibile registrare i contatori Computer Time Offset e Round Trip Delay. Come un contatore delle prestazioni, è possibile monitorarli in modalità remota e creare avvisi usando System Center Operations Manager. Ad esempio, è possibile utilizzare un avviso di allarme è quando l'Offset dell'ora si allontana dalla precisione desiderata. Per maggiori informazioni, consultare la sezione System Center Management Pack.

Esempio di tracciabilità Windows

Dai file di log w32tm, si desidera convalidare due tipi di informazioni. La prima è un'indicazione che il file di log è attualmente un orologio condizione. Questa indicazione dimostra che l'orologio è stato condizionato dal servizio Windows Time all'ora contestata.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Il punto principale è che si visualizzano messaggi preceduti dal prefisso ClockDispln Discipline, che prova che W32Time interagisce con l'orologio di sistema.

Successivamente, è necessario trovare l'ultimo report nel log prima dell'ora contestata che segnala il computer di origine utilizzato come l'orologio di riferimento. Questa informazione potrebbe corrispondere a un indirizzo IP, a un nome computer o al provider VMIC, il che indica che viene eseguita la sincronizzazione con l'host per Hyper-V. L'esempio seguente fornisce l'indirizzo IPv4 10.197.216.105:

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Ora che è stato convalidato il primo sistema della catena ora di riferimento, è necessario analizzare il file di log nell'origine ora di riferimento e ripetere gli stessi passaggi. Questo processo continua finché non viene visualizzato un orologio fisico, ad esempio GPS o un'origine ora nota come NIST. Se l'orologio di riferimento è hardware GPS, potrebbero essere necessari anche i log dal prodotto.

Considerazioni per la rete

Gli algoritmi di protocollo NTP presentano una dipendenza da simmetria della rete. L'aumento del numero di hop di rete, la probabilità di asimmetria cresce. Per questo motivo, è difficile prevedere quali tipi di accuratezza verranno visualizzati negli specifici ambienti in uso.

Per valutare l'accuratezza di ambienti e creare linee di base è possono utilizzare Performance Monitor e i nuovi contatori ora di Windows in Windows Server 2016. Inoltre, è possibile eseguire la risoluzione dei problemi per determinare l'offset corrente di qualsiasi computer della rete.

Sono disponibili due standard generale per ora esatta in rete:

Per impostazione predefinita, per le macchine non appartenenti al dominio, Windows supporta NTP semplice (RFC2030). Per computer appartenenti al dominio, utilizziamo un NTP sicuro chiamato MS SNTP, che sfrutta i segreti dominio negoziato che forniscono un vantaggio di gestione rispetto NTP autenticato descritto in RFC1305 e RFC5905.

I protocolli appartenenti e non appartenenti al dominio richiedono la porta UDP 123. Per maggiori informazioni sulle procedure consigliate NTP, fare riferimento a Bozza IETF migliori pratiche su Network Time Protocol.

RTC (Reliable hardware clock)

Windows non tiene conto del tempo che passa, a meno che non vengono superati determinati limiti, ma piuttosto disciplina l'orologio. Ciò significa che w32tm regola la frequenza dell'orologio a intervalli regolari, utilizzando l'impostazione Clock Update Frequency, che dà come valore predefinito una volta al secondo con Windows Server 2016. Se l'orologio è indietro, accelera la frequenza. Se è avanti, rallenta la frequenza. Tuttavia, durante tale intervallo di tempo tra le rettifiche di frequenza dell'orologio dell'hardware è sotto controllo. Se si verifica un problema con il firmware o il clock hardware, l'ora del computer può diventare meno accurata.

Questo scenario rappresenta un altro motivo per cui è necessario testare e stabilire nel proprio ambiente. Se il contatore delle prestazioni Computed Time Offset non si stabilizza all'accuratezza desiderata, si consiglia di verificare che il firmware sia aggiornato. Come in un altro test, è possibile scoprire se l'hardware duplicato restituisce lo stesso problema.

Risoluzione dei problemi relativi all'accuratezza degli orari e NTP

È possibile utilizzare la sezione Discover the hierarchy per comprendere l'origine dell'ora corretta. Osservando la differenza di orario, trovare il punto della gerarchia in cui l'ora differisce di più dalla relativa origine NTP. Dopo aver compreso la gerarchia, è opportuno provare a comprendere perché tale origine orario non riceve l'ora esatta.

Concentrandosi sul sistema l'orario diverso, è possibile utilizzare i seguenti strumenti per raccogliere maggiori informazioni che consentono di determinare il problema e trovare una soluzione. Il riferimento UpstreamClockSource è l'orologio individuato tramite w32tm /config /status:

  • Log eventi di sistema
  • Abilitare la registrazione tramite w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
  • chiave del registro w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
  • Tracce di rete locale
  • Contatori delle prestazioni (dal computer locale o UpstreamClockSource)
  • W32tm /stripchart /computer:UpstreamClockSource
  • PING UpstreamClockSource per comprendere la latenza e il numero di hop per origine
  • Tracert UpstreamClockSource
Problema Sintomi Risoluzione
L'orologio TSC locale non è stabile. Utilizzo di Perfmon - Computer fisico: sincronizzazione dell'orologio stabile dell'orologio, ma non è ancora vedere che ogni 1-2 minuti di 100us diversi. Aggiornare il firmware o verificare che un hardware diverso non visualizzi lo stesso problema.
Latenza di rete. Lo stripchart w32tm visualizza RoundTripDelay di più di 10 ms. Variazione del ritardo causare rumore di dimensioni pari alla metà del tempo di round trip, ad esempio, un ritardo che è in una sola direzione.

UpstreamClockSource è hop multipli, come indicato dal comando PING. Durata (TTL) dovrebbe essere vicino a 128.

Usare Tracert per trovare la latenza in ogni hop.		 Trovare un orologio di origine più vicina per volta. Una soluzione consiste nell'installare un orologio di origine nello stesso segmento o scegliere manualmente orologio di origine geograficamente più vicino. Per uno scenario di dominio, aggiungere un computer con il ruolo GTimeServ.
Impossibile raggiungere in modo affidabile l'origine NTP. W32tm /stripchart restituisce in modo intermittente il messaggio "Richiesta scaduta". L'origine NTP non risponde.
L'origine NTP non risponde. Controllare i contatori Perfmon per risposte in uscita del Server NTP conteggio di origine Client NTP, richieste in arrivo del Server NTP e determinare le modalità di utilizzo rispetto alle linee di base. Usando i contatori delle prestazioni di server, se il carico è stato modificato in riferimento alle linee di base.

Esistono rete i problemi di congestione?
Controller di dominio che non usano l'orologio più accurato. Modifiche nella topologia o orologio master aggiunto di recente. W32tm /Resync. /rediscover
Gli orologi client sono la deviazione. Servizio ora evento 36 nel registro eventi di sistema e/o di testo nel file di log che indica che il contatore NTP Client Time Source Count sarà da 1 a 0. Eseguire la risoluzione dei problemi dell'origine upstream e comprendere se si stanno verificando problemi di prestazioni.

Base tempo

La base è importante per comprendere le prestazioni e accuratezza della rete e confrontarla con quella futura, quando si verificano problemi. È opportuno definire una linea di base per il PDC radice o qualsiasi computer contrassegnato con GTIMESRV. Sarebbe inoltre consigliabile stabilire il PDC in ogni foresta. Infine, scegliere tutti i controller di dominio o le macchine che dispongono di caratteristiche interessante, ad esempio la distanza o carichi elevati e linea di base critici tali.

È utile inoltre eseguire la baseline di Windows Server 2016 rispetto a 2012 R2. Tuttavia, si dispone solo dello strumento w32tm /stripchart, che è possibile usare per eseguire un confronto, perché Windows Server 2012 R2 non dispone di contatori delle prestazioni. Selezionare due computer con le stesse caratteristiche o aggiornare un computer e confrontare i risultati dopo l'aggiornamento. Il supplemento Windows ora misurazioni contiene ulteriori informazioni su come eseguire misure dettagliate tra 2016 e 2012.

Usando tutti i contatori di prestazioni W32Time, raccogliere i dati per almeno una settimana. Questi dati garantiscono che si dispone di un numero sufficiente di un riferimento all'account per i diversi nella rete nel tempo e un numero sufficiente di un'esecuzione per avere la certezza che la precisione del tempo è stabile.

Ridondanza del server NTP

Per la configurazione del server NTP manuale con macchine non appartenenti al dominio o PDC, con più di un server è una misura buona ridondanza in caso di disponibilità. È inoltre possibile fornire una migliore accuratezza, supponendo che tutte le origini siano accurate e stabili. Tuttavia, se la topologia non è ben progettata o le origini orario non sono più stabili, l'accuratezza potrebbe essere inferiore, pertanto prestare attenzione. Il limite dei server a orario supportato a cui W32Time può fare manualmente riferimento è 10.

Secondi di compensazione

Il periodo di rotazione della terra varia nel tempo a causa di eventi climatici e geologici. In genere, la variazione è di circa un secondo ogni due anni. Ogni volta che la variazione dall'ora atomica diventa eccessiva, viene inserita una correzione di un secondo (per eccesso o per difetto), nota come secondo intercalare. Questo inserimento viene eseguito in modo che la differenza non supera mai 0,9 secondi. Questa correzione viene annunciata sei mesi prima che venga effettivamente apportata. Prima di Windows Server 2016, il servizio orario di Microsoft non era consapevole dei secondi di compensazione, ma si basava sul servizio orario esterna. Con una precisione di maggior tempo di Windows Server 2016, Microsoft sta lavorando in una soluzione più adatta per il problema secondo intercalare.

Seeding sicuro dell'ora

W32time in Server 2016 include una funzionalità per Secure Time Seeding. Questa funzionalità determina l'ora corrente approssimativa dalle connessioni SSL in uscita. Questo valore relativo all'ora viene usato per monitorare il clock di sistema locale e correggere gli errori particolarmente evidenti. Per altre informazioni su questa funzionalità, leggi questo post di blog. Nelle distribuzioni con una o più origini ora affidabili e computer ben monitorati che includono il monitoraggio delle differenze di orario, è possibile scegliere di non usare la funzionalità di seeding sicuro dell'ora e basarti invece sull'infrastruttura esistente.

Per disabilitare la funzionalità di ripristino accelerato del database:

  1. Usare Criteri di gruppo per gestire SecureTimeSeeding. Consultare la sezione che fa riferimento all'impostazione UtilizeSslTimeData: Learn: Policy CSP - ADMX_W32Time.

  2. In alternativa, è possibile impostare manualmente il valore del registro. Impostare il valore di configurazione del registro UtilizeSSLTimeData su 0 in un computer specifico

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f

  3. Se non si riesce a riavviare il computer immediatamente, è possibile notificare W32Time dell'aggiornamento di configurazione. Questa notifica interrompe il monitoraggio e l'applicazione dell'ora in base ai dati temporali provenienti dalle connessioni SSL.

    W32tm.exe /config /update

  4. Il riavvio del computer rende immediatamente effettiva l'impostazione e interrompe la raccolta dei dati temporali dalle connessioni SSL. La seconda parte comporta un sovraccarico ridotto e non dovrebbe incidere sulle prestazioni.

  5. Per applicare questa impostazione in un intero dominio, imposta il valore UtilizeSSLTimeData nell'impostazione Criteri di gruppo W32time su 0 e pubblicare l'impostazione. Quando l'impostazione viene prelevata da un client di Criteri di gruppo, viene inviata una notifica a W32Time, che interromperà il monitoraggio e l'applicazione dell'ora in base ai dati temporali SSL. La raccolta dei dati temporali SSL si interrompe al riavvio di ogni computer. Se il dominio include tablet o portatili slim e altri dispositivi, è opportuno escludere tali computer dalla modifica dei criteri. Questi dispositivi alla fine esauriranno la batteria e avranno necessità della funzionalità Secure Time Seeding per impostare l'ora esatta in fase di bootstrap.