Sincronizzazione dell'ora per le macchine virtuali Linux in Azure

Si applica a: ✔️ VM Linux ✔️ set di scalabilità flessibili ✔️ set di scalabilità uniformi

La sincronizzazione dell'ora è importante per la sicurezza e la correlazione degli eventi. In alcuni casi viene usata per l'implementazione di 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.

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. UTC è definito da un insieme multinazionale di orologi atomici di precisione che possono discostarsi di solo 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 sono sincronizzati con i server orari interni di Microsoft, che ottengono l'ora da dispositivi Stratum 1 di proprietà di Microsoft, dotati di 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 andrà alla deriva 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 correggere questo inconveniente, 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 solo una macchina virtuale, l'effetto può non essere significativo, a meno che il carico di lavoro richieda una misurazione del tempo estremamente precisa. Tuttavia, nella maggior parte dei casi sono disponibili più macchine virtuali interconnesse che usano l'ora per tenere traccia delle transazioni e l'ora deve essere coerente in tutta la 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 le ore non coincidono nei log o in altri dati. 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 una sincronizzazione temporale continua 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 è in esecuzione come servizio di sincronizzazione dell'ora e si sincronizza con una fonte temporale NTP esterna accessibile tramite la rete. Ad esempio, le immagini di Ubuntu 18.04 LTS del Marketplace usano ntp.ubuntu.com.

Per verificare che NTP esegua correttamente la sincronizzazione, usare il comando ntpq -p.

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 la migliore fonte di riferimento temporale con cui sincronizzarsi, perché è mantenuta con precisione e affidabilità ed è accessibile senza i ritardi di rete variabili tipici dell'accesso a un server di riferimento orario NTP esterno 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 temporale hardware IEEE 1588 Precision Time Protocol (PTP) come dispositivo /dev/ptp che fornisce l'ora del giorno precisa dall'host Azure. Chronyd può essere configurato per sincronizzarsi con questa origine temporale, che è 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 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.

È possibile modificare la configurazione predefinita. Un'immagine meno recente configurata per usare ntpd e una sorgente oraria esterna può essere modificata per utilizzare chronyd e il dispositivo /dev/ptp per l'ora 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 temporale PTP

Con le versioni più recenti di Linux, è disponibile un'origine temporale PTP (Precision Time Protocol) associata all'host Azure come parte del provider VMICTimeSync. Nelle versioni più datate di Red Hat Enterprise Linux 7.x i servizi di integrazione Linux possono essere scaricati e usati per installare il driver aggiornato. Quando la sorgente del clock PTP è disponibile, il dispositivo Linux ha il formato /dev/ptpx.

Visualizza quali sorgenti di clock 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

Questa operazione deve restituire hyperv, ovvero l'host di Azure.

In alcune macchine virtuali Linux potrebbero essere elencati più dispositivi PTP. Ad esempio, per la rete accelerata 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 /dev/ptp0 o /dev/ptp1, condizione che rende difficile configurare chronyd con l'origine dell'orologio corretta. Per risolvere questo problema, le immagini Linux più recenti includono una regola udev che crea il collegamento simbolico /dev/ptp_hyperv alla voce /dev/ptp che corrisponde all'host Azure. Chrony deve essere sempre configurato per usare il /dev/ptp_hypervcollegamento simbolico anziché /dev/ptp0 o /dev/ptp1.

Se si verificano problemi con il dispositivo /dev/ptp_hyperv che non viene creato, è possibile usare la regola udev 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 un udevfile di 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 O ricaricare le regole udev con:

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

chrony

In Ubuntu 19.10 (e versioni successive) e Red Hat Enterprise Linux 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 temporale dell'host Azure deve essere trattata come Stratum 2, il che a sua volta fa sì che il guest Linux si dichiari come Stratum 3. È possibile modificare l'impostazione stratum nella riga di configurazione se si desidera che il guest Linux si identifichi in modo differente.

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 correggerla. Per risolvere questo problema, è possibile modificare il parametro makestep in /etc/chrony.conf 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

Messaggi di sincronizzazione dell'ora correlati a systemd-timesyncd

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 tenterà di sincronizzare l'ora durante l'avvio, ma una volta avviato, chrony lo sostituirà e diventerà la sorgente predefinita per la sincronizzazione dell'ora.

Per altre informazioni su Ubuntu e NTP, vedere la sezione relativa alla sincronizzazione dell'ora.

Per altre informazioni su Red Hat e NTP, vedere la pagina relativa alla configurazione di NTP.

Per altre informazioni su chrony, vedere Uso di chrony.

systemd

Nelle versioni SUSE 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 SUSE, vedere Sincronizzazione dell'ora in SUSE.

cloud-init

Le immagini che usano cloud-init per effettuare il provisioning della macchina virtuale possono usare la sezione ntp per configurare un servizio di sincronizzazione dell'ora. Un esempio di cloud-init che installa chrony e lo configura per usare il clock PTP come origine temporale per le VM 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 codificare in base64 il cloud-config precedente per usarlo nella sezione osProfile di un modello ARM:

[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).