Sincronização de tempo para VMs Linux no Azure

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

Aplica-se a: ✔️ VMs do Linux ✔️ Conjuntos de dimensionamento flexíveis ✔️ Conjunto de dimensionamento uniformes

A sincronização de Data/Hora é importante para segurança e correlação de eventos. Às vezes, é usada para implementação de transações distribuídas. A precisão da hora entre vários sistemas de computador é obtida por meio da sincronização. A sincronização pode ser afetada por vários motivos, incluindo reinicializações e tráfego entre a fonte de tempo e o computador buscando a hora.

O Azure é apoiado pela infraestrutura que executa o Windows Server 2016. O Windows Server 2016 aprimorou os algoritmos usados para corrigir a hora e condicionar o relógio local a sincronizar com o UTC. O recurso Windows Server 2016 Accurate Time melhorou muito a forma como o serviço VMICTimeSync controla as VMs com o host para o tempo exato. Os aprimoramentos incluem um tempo inicial mais preciso no início da VM ou na restauração da VM e interrupção da correção de latência.

Observação

Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este vídeo de visão geral de alto nível.

Para obter mais informações, consulte Hora precisa para Windows Server 2016.

Visão geral

A precisão de um relógio de computador é medida na proximidade do relógio do computador com o padrão de hora UTC (Tempo Universal Coordenado). O UTC é definido por uma amostra multinacional de relógios atômicos precisos que só pode ser desligada em um segundo em 300 anos. Mas ler o UTC diretamente requer um hardware especializado. Em vez disso, os servidores de horário são sincronizados com o UTC e acessados de outros computadores para fornecer escalabilidade e robustez. Todo computador tem o serviço de sincronização de tempo em execução que sabe a que horas os servidores devem ser usados e verifica periodicamente se o relógio do computador precisa ser corrigido e ajusta o tempo, se necessário.

Os hosts do Azure são sincronizados para servidores de horário internos da Microsoft que usam dispositivos da Microsoft da Stratum 1, com antenas de GPS. As máquinas virtuais no Azure podem depender do host para passar a hora exata (hora do host) para a VM ou a VM pode obter a hora diretamente de um servidor de horário ou uma combinação de ambos.

No hardware autônomo, o sistema operacional Linux só lê o relógio de hardware do host na inicialização. Depois disso, o relógio é mantido usando o timer de interrupção no kernel do Linux. Nesta configuração, o relógio se deslocará com o tempo. Em distribuições mais recentes do Linux no Azure, as VMs podem usar o provedor VMICTimeSync, incluído nos serviços de integração do Linux (LIS), para consultar atualizações de relógio do host com mais frequência.

As interações da máquina virtual com o host também podem afetar o relógio. Durante a manutenção de memória preservando a manutenção, as VMs são pausadas por até 30 segundos. Por exemplo, antes de iniciar a manutenção, o relógio da VM exibe as 10:00:00 e dura 28 segundos. Depois que a VM for retomada, o relógio na VM ainda mostrará 10:00:00 AM, o que seria 28 segundos de folga. Para corrigir isso, o serviço VMICTimeSync monitora o que está acontecendo no host e atualiza o relógio de hora do dia nas VMs do Linux para compensar.

Sem a sincronização de data/hora, o relógio na VM acumularia erros. Quando há apenas uma VM, o efeito pode não ser significativo, a menos que a carga de trabalho exija uma cronometragem altamente precisa. Mas na maioria dos casos, temos várias VMs interconectadas que usam o tempo para rastrear transações, e a hora precisa ser consistente durante toda a implantação. Quando a hora entre as VMs for diferente, você poderá ver os seguintes efeitos:

• A autenticação falhará. Protocolos de segurança como Kerberos ou tecnologia dependente de certificado requerem que a hora esteja consistente em todos os sistemas.
• É muito difícil descobrir o que aconteceu em um sistema se os logs (ou outros dados) não corresponderem com a hora. O mesmo evento poderia parecer que ocorreu em momentos diferentes, dificultando a correlação.
• Se o relógio estiver desligado, a cobrança poderá ser calculada incorretamente.

Opções de configuração

A sincronização de tempo requer que um serviço de sincronização de tempo seja executado na VM do Linux, além de uma fonte de informações de tempo precisa com a qual é feita a sincronização. Normalmente, ntpd ou chronyd são usados como o serviço de sincronização de tempo, embora haja outros serviços de sincronização de tempo de software livre que também possam ser usados. A fonte de informação da hora precisa pode ser o host do Azure ou um serviço de tempo externo que é acessado pela Internet pública. Por si só, o serviço VMICTimeSync não fornece sincronização de tempo contínua entre o host do Azure e uma VM do Linux, exceto após pausas para manutenção do host, conforme descrito acima.

Historicamente, a maioria das imagens do Azure Marketplace com o Linux foram configuradas de uma destas duas maneiras:

• Nenhum serviço de sincronização de tempo está em execução por padrão
• O ntpd está em execução como o serviço de sincronização de tempo e sendo sincronizado com uma fonte de tempo NTP externa que é acessada pela rede. Por exemplo, as imagens do Ubuntu 18.04 LTS Marketplace usam ntp.ubuntu.com.

Para confirmar que o ntpd está sincronizando corretamente, execute o comando ntpq -p.

Algumas imagens mais atualizadas do Azure Marketplace com o Linux estão sendo alteradas para usar o chronyd como o serviço de sincronização de tempo, e o chronyd está configurado para sincronização com o host do Azure em vez de uma fonte de tempo NTP externa. O horário do host do Azure geralmente é a melhor fonte de tempo para sincronizar, pois é mantido de forma muito precisa e confiável e é acessível sem os atrasos de rede variáveis inerentes ao acesso a uma fonte de horário NTP externa pela internet pública.

O VMICTimeSync é usado em paralelo e fornece duas funções:

• Atualiza imediatamente o relógio de hora do dia da VM do Linux após um evento de manutenção do host
• Cria uma instância de uma fonte do relógio de hardware de PTP (Precision Time Protocol) do IEEE 1588 como um dispositivo /dev/ptp que fornece a hora precisa do dia do host do Azure. O chronyd pode ser configurado para sincronização com essa fonte de tempo (que é a configuração padrão nas imagens mais novas do Linux). As distribuições do Linux com o kernel versão 4.11 ou posterior (ou versão 3.10.0-693 ou posterior para RHEL/CentOS 7) dão suporte ao dispositivo /dev/ptp. Para versões anteriores do kernel que não dão suporte ao /dev/ptp para o tempo de host do Azure, só é possível a sincronização com uma fonte de tempo externa.

Evidentemente, a configuração padrão pode ser alterada. Uma imagem mais antiga configurada para usar o ntpd e uma fonte de tempo externa pode ser alterada para usar o chronyd e o dispositivo /dev/ptp para a hora do host do Azure. Da mesma forma, é possível configurar uma imagem usando a hora do host do Azure por meio de um dispositivo /dev/ptp para usar uma fonte de tempo NTP externa, se exigido pelo seu aplicativo ou carga de trabalho.

Ferramentas e recursos

Há alguns comandos básicos para verificar sua configuração de sincronização de tempo. A documentação para distribuição do Linux terá mais detalhes sobre a melhor maneira de configurar a sincronização de horário para essa distribuição.

Serviços de integração

Verifique se o serviço de integração (hv_utils) está carregado.

$ sudo lsmod | grep hv_utils

Você deve ver algo semelhante a isto:

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

Verificar Origem do Relógio PTP

Com versões mais recentes do Linux, uma fonte de relógio do PTP (Precision Time Protocol) correspondente ao host do Azure está disponível como parte do provedor VMICTimeSync. Em versões mais antigas do Red Hat Enterprise Linux ou CentOS 7.x, o Linux Integration Services pode ser baixado e usado para instalar o driver atualizado. Quando a origem do relógio PTP estiver disponível, o dispositivo Linux será do formato/dev/PTPx.

Veja quais fontes de relógio PTP estão disponíveis.

$ ls /sys/class/ptp

Neste exemplo, o valor retornado é ptp0, portanto, usamos isso para verificar o nome do relógio. Para verificar o dispositivo, verifique o nome do relógio.

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

Isso deve retornar hyperv, o que significa o host do Azure.

Em algumas VMs do Linux, você pode ver vários dispositivos PTP listados. Um exemplo é a Rede Acelerada, em que o driver Mellanox mlx5 também cria um dispositivo /dev/ptp. Como a ordem de inicialização pode ser diferente cada vez que o Linux é inicializado, o dispositivo PTP correspondente ao host do Azure pode ser /dev/ptp0 ou /dev/ptp1, o que dificulta a configuração de chronyd com a fonte de relógio correta. Para resolver esse problema, as imagens do Linux mais recentes têm uma regra udev que cria o symlink /dev/ptp_hyperv para qualquer entrada /dev/ptp que corresponda ao host do Azure. O Chrony sempre deve ser configurado para usar o /dev/ptp_hyperv link simbólico em vez de /dev/ptp0 ou /dev/ptp1.

Se você estiver tendo problemas em que o dispositivo /dev/ptp_hyperv não é criado, poderá usar a regra udev e as etapas abaixo para configurá-la:

OBSERVAÇÃO: a maioria das distribuições do Linux não deve precisar dessa regra udev, pois ela foi implementada nas versões mais recentes do systemd

Crie o arquivo de regras udev:

$ 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

Reinicialize a Máquina Virtual OU recarregue as regras de udev com:

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

chrony

No Ubuntu 19,10 e versões posteriores, Red Hat Enterprise Linux e CentOS 8. x, o chrony é configurado para usar um relógio de origem do PTP. Em vez de chrony, as versões mais antigas do Linux usam o daemon de protocolo NTP (ntpd), que não dá suporte a fontes PTP. Para habilitar o PTP nessas versões, o chrony deve ser instalado e configurado manualmente (em chrony.conf) usando a seguinte instrução:

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

Se o symlink /dev/ptp_hyperv estiver disponível, use-o em vez de /dev/ptp0 para evitar qualquer confusão com o dispositivo /dev/ptp criado pelo driver Mellanox mlx5.

As informações de estrato não são automaticamente transmitidas do host do Azure para o convidado do Linux. A linha de configuração anterior especifica que a fonte do tempo de host do Azure deve ser tratada como Estrato 2, que, por sua vez, faz com que o convidado do Linux se reporte como Estrato 3. Você pode alterar a configuração de estrato na linha de configuração se quiser que o convidado do Linux se reporte de forma diferente.

Por padrão, o chronyd acelera ou reduz o relógio do sistema para corrigir qualquer descompasso de tempo. Se o descompasso se tornar muito grande, o chrony falhará ao corrigir o descompasso. Para superar isso, o parâmetro makestep em /etc/chrony.conf pode ser alterado para forçar uma sincronização de horário se a descompasso exceder o limite especificado.

makestep 1.0 -1

Aqui, o chrony forçará uma atualização de tempo se a descompasso for maior que 1 segundo. Para aplicar as alterações, reinicie o serviço chronyd:

$ sudo systemctl restart chronyd && sudo systemctl restart chrony

Mensagens de sincronização da hora relacionadas ao systemd-timesyncd

Em alguns casos, o serviço systemd-timesyncd ainda pode estar habilitado e tentando fazer uma sincronização após uma reinicialização, se você ainda estiver vendo mensagens no syslog semelhantes 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)

Você pode desabilitá-lo usando:

$ sudo systemctl disable systemd-timesyncd

Na maioria dos casos, systemd-timesyncd tentará durante a inicialização, mas uma vez que chrony for iniciado, ele substituirá e se tornará a fonte de sincronização de horário padrão.

Para obter mais informações sobre o Ubuntu e o NTP, consulte Sincronização de Horário.

Para obter mais informações sobre o Red Hat e NTP, consulte Configurar NTP.

Para mais informações sobre chrony, consulte Usando o chrony.

systemd

Em versões SUSE e Ubuntu anteriores a 19.10, a sincronização de horário é configurada usando o systemd. Para obter mais informações sobre o Ubuntu, consulte Sincronização de Horário. Para obter mais informações sobre o SUSE, consulte a seção 4.5.8 Notas de Versão do SUSE Linux Enterprise Server 12 SP3.

inicialização de nuvem

As imagens que usam cloud-init para provisionar a VM podem usar a seção ntp para configurar um serviço de sincronização da hora. Um exemplo de cloud-init instalando chrony e configurando-o para usar a origem do relógio PTP para VMs do 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

Em seguida, você pode usar base64 na configuração de nuvem acima para uso na seção osProfile em um modelo do ARM:

[Convert]::ToBase64String((Get-Content -Path ./cloud-config.txt -Encoding Byte))

"osProfile": {
  "customData": "I2Nsb3VkLWNvbmZpZwpudHA6CiAgZW5hYmxlZDogdHJ1ZQogIG50cF9jbGllbnQ6IGNocm9ueQogIGNvbmZpZzoKICAgIGNvbmZwYXRoOiAvZXRjL2Nocm9ueS9jaHJvbnkuY29uZgogICAgcGFja2FnZXM6CiAgICAgLSBjaHJvbnkKICAgIHNlcnZpY2VfbmFtZTogY2hyb255CiAgICB0ZW1wbGF0ZTogfAogICAgICAgIyMgdGVtcGxhdGU6amluamEKICAgICAgIGRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvY2hyb255LmRyaWZ0CiAgICAgICBsb2dkaXIgL3Zhci9sb2cvY2hyb255CiAgICAgICBtYXh1cGRhdGVza2V5IDEwMC4wCiAgICAgICByZWZjbG9jayBQSEMgL2Rldi9wdHBfaHlwZXJ2IHBvbGwgMyBkcG9sbCAtMgogICAgICAgbWFrZXN0ZXAgMS4wIC0x"
}

Para obter mais informações sobre cloud-init no Azure, consulte Visão geral do suporte de cloud-init para VMs do Linux no Azure.

Próximas etapas

Para obter mais informações, consulte Hora precisa para Windows Server 2016.