Sincronizzazione dell'ora per le macchine virtuali Linux in Azure

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Prendere in considerazione l'uso e il piano di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Si applica a: set di scalabilità uniformi di ✔️ macchine virtuali Linux ✔️ ✔️

La sincronizzazione dell'ora è importante per la sicurezza e la correlazione degli eventi. A volte viene usato per l'implementazione delle transazioni distribuite. La precisione dell'ora tra più sistemi di computer si ottiene con la sincronizzazione. La sincronizzazione può essere interessata da più fattori, tra cui i riavvii e il traffico di rete tra l'origine dell'ora e il computer che la recupera.

Azure è supportato da un'infrastruttura che esegue Windows Server 2016. Windows Server 2016 ha migliorato gli algoritmi usati per correggere l'ora e imporre all'orologio locale la sincronizzazione con l'ora UTC. La funzionalità dell'ora esatta di Windows Server 2016 ha notevolmente migliorato il modo in cui il servizio VMICTimeSync gestisce le macchine virtuali con l'host per l'ora esatta. I miglioramenti includono un'ora iniziale più accurata per l'avvio o il ripristino della macchina virtuale e la correzione della latenza di interrupt.

Nota

Per una rapida panoramica del servizio Ora di Windows, guarda questo video di panoramica generale.

Per altre informazioni, vedere Accurate time for Windows Server 2016 (Ora esatta per Windows Server 2016).

Panoramica

La precisione di un orologio del computer viene misurata in base a quanto l'orologio del computer si avvicina allo standard dell'ora UTC. L'ora UTC è definita da un campione multinazionale di orologi atomici precisi che possono essere sfalsati solo di un secondo in 300 anni. Tuttavia, leggere l'ora UTC direttamente richiede un hardware specializzato. Al contrario, i server di riferimento ora vengono sincronizzati con UTC e sono accessibili da altri computer in modo da garantire scalabilità e affidabilità. In ogni computer viene eseguito un servizio di sincronizzazione dell'ora che sa quali server di riferimento ora usare e verifica periodicamente se l'orologio del computer deve essere corretto e, se necessario, regola l'ora.

Gli host di Azure vengono sincronizzati con i server di riferimento ora interni di Microsoft che ricavano l'ora da dispositivi di strato 1 di proprietà di Microsoft, con antenne GPS. Le macchine virtuali di Azure possono dipendere dal proprio host per passare l'ora esatta (ora host) alla macchina virtuale oppure la macchina virtuale può ottenere direttamente l'ora da un server di riferimento ora o una combinazione di entrambi.

Nei componenti hardware autonomi il sistema operativo Linux legge solo l'orologio dell'hardware dell'host in fase di avvio. Successivamente, l'orologio viene gestito usando il timer di interrupt nel kernel di Linux. In questa configurazione l'orologio si desincronizza nel tempo. Nelle distribuzioni di Linux più recenti in Azure, le macchine virtuali possono usare il provider VMICTimeSync, incluso nei servizi di integrazione di Linux, per eseguire query in modo da aggiornare più spesso l'orologio dall'host.

Le interazioni delle macchine virtuali con l'host possono influire sull'orologio. Durante la manutenzione con mantenimento della memoria le macchine virtuali vengono messe in pausa fino a 30 secondi. Ad esempio, prima che inizi la manutenzione l'orologio della macchina virtuale indica 10:00:00 AM e dura 28 secondi. Quando l'esecuzione della macchina virtuale riprende, l'orologio della macchina virtuale indicherebbe ancora 10:00:00 AM, con un ritardo di 28 secondi. Per risolvere il problema, il servizio VMICTimeSync monitora ciò che accade nell'host e aggiorna l'ora del giorno nelle macchine virtuali Linux per compensare.

Senza il lavoro di sincronizzazione dell'ora, l'orologio della macchina virtuale può accumulare errori. Quando è presente una sola macchina virtuale, l'effetto potrebbe non essere significativo, a meno che il carico di lavoro non richieda un mantenimento del tempo estremamente accurato. Nella maggior parte dei casi, tuttavia, sono presenti più macchine virtuali interconnesse che usano il tempo per tenere traccia delle transazioni e il tempo deve essere coerente nell'intera distribuzione. Quando l'ora è diversa tra le macchine virtuali, si possono osservare gli effetti seguenti:

  • L'autenticazione ha esito negativo. I protocolli di sicurezza come Kerberos o la tecnologia dipendente dal certificato si basano sulla coerenza dell'ora tra i sistemi.
  • È difficile capire cosa è successo in un sistema se i log (o altri dati) non sono d'accordo sul tempo. Può sembrare che lo stesso evento si sia verificato in momenti diversi e questo rende difficile la correlazione.
  • Se orologio è disattivato, la fatturazione può essere calcolata in modo non corretto.

Opzioni di configurazione

La sincronizzazione dell'ora richiede che un servizio di sincronizzazione dell'ora sia in esecuzione nella macchina virtuale Linux, oltre a un'origine di informazioni accurate sull'ora in base alle quali eseguire la sincronizzazione. In genere, ntpd o chronyd viene usato come servizio di sincronizzazione dell'ora, anche se esistono anche altri servizi di sincronizzazione dell'ora open source che possono essere usati. L'origine di informazioni sull'ora accurate può essere l'host di Azure o un servizio ora esterno a cui si accede tramite la rete Internet pubblica. Di per sé, il servizio VMICTimeSync non fornisce la sincronizzazione in tempo continuativo tra l'host di Azure e una macchina virtuale Linux, tranne dopo le pause per la manutenzione dell'host, come descritto in precedenza.

Storicamente, la maggior parte delle immagini di Azure Marketplace con Linux è stata configurata in uno dei due modi seguenti:

  • Nessun servizio di sincronizzazione dell'ora è in esecuzione per impostazione predefinita
  • ntpd viene eseguito come servizio di sincronizzazione dell'ora e la sincronizzazione con un'origine ora NTP esterna a cui si accede tramite la rete. Ad esempio, le immagini di Ubuntu 18.04 LTS Marketplace usano ntp.ubuntu.com.

Per verificare che ntpd stia sincronizzando correttamente, eseguire il ntpq -p comando .

Alcune immagini di Azure Marketplace con Linux vengono modificate per usare chronyd come servizio di sincronizzazione dell'ora e chronyd è configurato per la sincronizzazione con l'host di Azure anziché con un'origine ora NTP esterna. L'ora dell'host di Azure è in genere l'origine dell'ora migliore da sincronizzare, perché viene mantenuta in modo accurato e affidabile ed è accessibile senza che la rete variabile ritardi intrinseci nell'accesso a un'origine temporale NTP esterna tramite Internet pubblico.

VMICTimeSync viene usato in parallelo e fornisce due funzioni:

  • Aggiorna immediatamente l'ora del giorno della macchina virtuale Linux dopo un evento di manutenzione host
  • Crea un'istanza di un'origine dell'orologio hardware I edizione Enterprise E 1588 Precision Time Protocol (PTP) come dispositivo /dev/ptp che fornisce l'ora esatta dell'host di Azure. Chronyd può essere configurato per la sincronizzazione con questa origine ora (ovvero la configurazione predefinita nelle immagini Linux più recenti). Le distribuzioni linux con kernel versione 4.11 o successiva (o versione 3.10.0-693 o successiva per RHEL/CentOS 7) supportano il dispositivo /dev/ptp. Per le versioni precedenti del kernel che non supportano /dev/ptp per l'ora dell'host di Azure, è possibile eseguire solo la sincronizzazione con un'origine ora esterna.

Naturalmente, la configurazione predefinita può essere modificata. Un'immagine precedente configurata per l'uso di ntpd e un'origine ora esterna può essere modificata per usare chronyd e il dispositivo /dev/ptp per l'ora dell'host di Azure. Analogamente, un'immagine che usa l'ora dell'host di Azure tramite un dispositivo /dev/ptp può essere configurata in modo da usare un'origine ora NTP esterna, se richiesto dall'applicazione o dal carico di lavoro.

Strumenti e risorse

Esistono alcuni comandi di base per controllare la configurazione della sincronizzazione dell'ora. La documentazione per la distribuzione di Linux include informazioni dettagliate sul modo migliore per configurare la sincronizzazione dell'ora per tale distribuzione.

Servizi di integrazione

Verificare se il servizio di integrazione (hv_utils) viene caricato.

$ sudo lsmod | grep hv_utils

Dovrebbe essere visualizzata una schermata simile alla seguente:

hv_utils               24418  0
hv_vmbus              397185  7 hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc

Verificare l'origine dell'orologio PTP

Con le versioni più recenti di Linux, un'origine dell'orologio PTP (Precision Time Protocol) corrispondente all'host di Azure è disponibile come parte del provider VMICTimeSync. Nelle versioni più datate di Red Hat Enterprise Linux o CentOS 7.x i servizi di integrazione Linux possono essere scaricati e usati per installare il driver aggiornato. Quando l'origine dell'orologio PTP è disponibile, il dispositivo Linux sarà nel formato /dev/ptpx.

Verificare quali origini di orologio PTP sono disponibili.

$ ls /sys/class/ptp

In questo esempio il valore restituito è ptp0 e può essere usato per verificare il nome dell'orologio. Per verificare il dispositivo, controllare il nome dell'orologio.

$ sudo cat /sys/class/ptp/ptp0/clock_name

Deve restituire hyperv, ovvero l'host di Azure.

In alcune macchine virtuali Linux potrebbero essere elencati più dispositivi PTP. Un esempio è relativo alla rete accelerata che il driver Mellanox mlx5 crea anche un dispositivo /dev/ptp. Poiché l'ordine di inizializzazione può essere diverso ogni volta che si avvia Linux, il dispositivo PTP corrispondente all'host di Azure potrebbe essere o potrebbe essere /dev/ptp0/dev/ptp1, che rende difficile la configurazione chronyd con l'origine dell'orologio corretta. Per risolvere questo problema, le immagini Linux più recenti hanno una udev regola che crea il collegamento /dev/ptp_hyperv simbolico a qualsiasi /dev/ptp voce corrisponda all'host di Azure. Chrony deve essere sempre configurato per l'uso del /dev/ptp_hyperv collegamento simbolico anziché di /dev/ptp0 o /dev/ptp1.

Se si verificano problemi con il /dev/ptp_hyperv dispositivo non creato, è possibile usare la udev regola e i passaggi seguenti per configurarlo:

NOTA: la maggior parte delle distribuzioni linux non deve avere questa regola udev perché è stata implementata nelle versioni più recenti di systemd

Creare il udev file delle regole:

$ sudo cat > /etc/udev/rules.d/99-ptp_hyperv.rules << EOF
ACTION!="add", GOTO="ptp_hyperv"
SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
LABEL="ptp_hyperv"
EOF

Riavviare la macchina virtuale OPPURE ricaricare le udev regole con:

$ sudo udevadm control --reload
$ sudo udevadm trigger --subsystem-match=ptp --action=add

chrony

In Ubuntu 19.10 e versioni successive, Red Hat Enterprise Linux e CentOS 8.x, chrony è configurato per l'uso di un orologio di origine PTP. Invece di chrony, le versioni precedenti di Linux usano il daemon del protocollo ora di rete (ntpd), che non supporta le origini PTP. Per abilitare PTP in tali versioni, chrony deve essere installato e configurato manualmente (in chrony.conf) usando l'istruzione seguente:

refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2

Se il collegamento simbolico /dev/ptp_hyperv è disponibile, usarlo invece di /dev/ptp0 per evitare confusione con il dispositivo /dev/ptp creato dal driver Mellanox mlx5.

Le informazioni di stratum non vengono trasmesse automaticamente dall'host di Azure al guest Linux. La riga di configurazione precedente specifica che l'origine dell'ora dell'host di Azure deve essere considerata stratum 2, che a sua volta fa in modo che il guest Linux possa segnalare se stesso come Stratum 3. È possibile modificare l'impostazione stratum nella riga di configurazione se si vuole che il guest Linux venga visualizzato in modo diverso.

Per impostazione predefinita, chronyd accelera o rallenta l'orologio di sistema per correggere eventuali deviazioni temporali. Se la deriva diventa troppo grande, chrony non riesce a correggere la deriva. Per ovviare a questo problema, il makestep parametro in /etc/chrony.conf può essere modificato per forzare una sincronizzazione temporale se la deriva supera la soglia specificata.

makestep 1.0 -1

In questo caso, chrony forza un aggiornamento temporale se la deriva è maggiore di 1 secondo. Per applicare le modifiche riavviare il servizio chronyd:

$ sudo systemctl restart chronyd && sudo systemctl restart chrony

In alcuni casi, il servizio systemd-timesyncd potrebbe ancora essere abilitato e tentare di eseguire una sincronizzazione al riavvio, se vengono ancora visualizzati messaggi in syslog simili a:

systemd-timesyncd[945]: Network configuration changed, trying to establish connection.
Aug  1 12:59:45 vm-name systemd-timesyncd[945]: Network configuration changed, trying to establish connection.
Aug  1 12:59:45 vm-name systemd-timesyncd[945]: Network configuration changed, trying to establish connection.
Aug  1 12:59:45 vm-name systemd-timesyncd[945]: Network configuration changed, trying to establish connection.
Aug  1 12:59:45 vm-name systemd-timesyncd[945]: Network configuration changed, trying to establish connection.
Aug  1 12:59:45 vm-name systemd-timesyncd[945]: Synchronized to time server 185.125.190.56:123 (ntp.ubuntu.com)

È possibile disabilitarla usando:

$ sudo systemctl disable systemd-timesyncd

Nella maggior parte dei casi, systemd-timesyncd proverà durante l'avvio, ma dopo l'avvio di chrony sovrascriverà e diventerà l'origine di sincronizzazione dell'ora predefinita.

Per altre informazioni su Ubuntu e NTP, vedere Sincronizzazione dell'ora.

Per altre informazioni su Red Hat e NTP, vedere Configurare NTP.

Per altre informazioni su chrony, vedere Uso di chrony.

systemd

Nelle versioni SU edizione Standard e Ubuntu precedenti alla 19.10 la sincronizzazione dell'ora viene configurata usando systemd. Per altre informazioni su Ubuntu, vedere Sincronizzazione dell'ora. Per altre informazioni su SU edizione Standard, vedere la sezione 4.5.8 in SU edizione Standard Note sulla versione di Linux Enterprise Server 12 SP3.

cloud-init

Le immagini che usano cloud-init per effettuare il provisioning della macchina virtuale possono usare la sezione per configurare un servizio di sincronizzazione dell'ora ntp . Esempio di installazione di chrony e configurazione di cloud-init per l'uso dell'origine dell'orologio PTP per le macchine virtuali Ubuntu:

#cloud-config
ntp:
  enabled: true
  ntp_client: chrony
  config:
    confpath: /etc/chrony/chrony.conf
    packages:
     - chrony
    service_name: chrony
    template: |
       ## template:jinja
       driftfile /var/lib/chrony/chrony.drift
       logdir /var/log/chrony
       maxupdateskew 100.0
       refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2
       makestep 1.0 -1

È quindi possibile basare 64 sulla configurazione cloud precedente da usare nella osProfile sezione in un modello di Resource Manager:

[Convert]::ToBase64String((Get-Content -Path ./cloud-config.txt -Encoding Byte))
"osProfile": {
  "customData": "I2Nsb3VkLWNvbmZpZwpudHA6CiAgZW5hYmxlZDogdHJ1ZQogIG50cF9jbGllbnQ6IGNocm9ueQogIGNvbmZpZzoKICAgIGNvbmZwYXRoOiAvZXRjL2Nocm9ueS9jaHJvbnkuY29uZgogICAgcGFja2FnZXM6CiAgICAgLSBjaHJvbnkKICAgIHNlcnZpY2VfbmFtZTogY2hyb255CiAgICB0ZW1wbGF0ZTogfAogICAgICAgIyMgdGVtcGxhdGU6amluamEKICAgICAgIGRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvY2hyb255LmRyaWZ0CiAgICAgICBsb2dkaXIgL3Zhci9sb2cvY2hyb255CiAgICAgICBtYXh1cGRhdGVza2V5IDEwMC4wCiAgICAgICByZWZjbG9jayBQSEMgL2Rldi9wdHBfaHlwZXJ2IHBvbGwgMyBkcG9sbCAtMgogICAgICAgbWFrZXN0ZXAgMS4wIC0x"
}

Per altre informazioni su cloud-init in Azure, vedere Panoramica del supporto cloud-init per le macchine virtuali Linux in Azure.

Passaggi successivi

Per altre informazioni, vedere Accurate time for Windows Server 2016 (Ora esatta per Windows Server 2016).