Sincronização de tempo para VMs Linux no Azure

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos ✔️ de escala flexíveis Conjuntos de balanças uniformes

A sincronização de tempo é importante para a segurança e a correlação de eventos. Às vezes, ele é usado para implementação de transações distribuídas. A precisão do tempo entre vários sistemas de computador é alcançada através da sincronização. A sincronização pode ser afetada por várias coisas, incluindo reinicializações e tráfego de rede entre a fonte de tempo e o computador que busca a hora.

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

Nota

Para obter uma visão geral rápida do serviço de Tempo do Windows, dê uma olhada neste vídeo de visão geral de alto nível.

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

Descrição geral

A precisão de um relógio de computador é medida de acordo com o quão próximo o relógio do computador está do padrão de tempo UTC (Tempo Universal Coordenado). O UTC é definido por uma amostra multinacional de relógios atómicos precisos que só podem ser desligados por um segundo em 300 anos. Mas, ler UTC diretamente requer hardware especializado. Em vez disso, os servidores de hora são sincronizados com o UTC e são acessados de outros computadores para fornecer escalabilidade e robustez. Cada computador tem um serviço de sincronização de tempo em execução que sabe a que horas os servidores usar 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 com servidores de tempo internos da Microsoft que tomam seu tempo de dispositivos Stratum 1 de propriedade da Microsoft, com antenas GPS. As máquinas virtuais no Azure podem depender de seu host para passar o tempo preciso (tempo do host) para a VM ou a VM pode obter diretamente o tempo de um servidor de tempo ou uma combinação de ambos.

Em 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 temporizador de interrupção no kernel Linux. Nesta configuração, o relógio irá desviar-se ao longo do tempo. Em distribuições Linux mais recentes 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 da preservação da memória, as VMs são pausadas por até 30 segundos. Por exemplo, antes do início da manutenção, o relógio da VM mostra 10:00:00 e dura 28 segundos. Depois que a VM for retomada, o relógio da VM ainda mostrará 10:00:00 AM, o que seria 28 segundos desligado. Para corrigir isso, o serviço VMICTimeSync monitora o que está acontecendo no host e atualiza o relógio de hora do dia em VMs Linux para compensar.

Sem a sincronização de tempo funcionando, 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 manutenção de tempo altamente precisa. Mas, na maioria dos casos, temos várias VMs interconectadas que usam o tempo para rastrear transações e o tempo precisa ser consistente durante toda a implantação. Quando o tempo entre VMs é diferente, você pode ver os seguintes efeitos:

• A autenticação falhará. Protocolos de segurança como Kerberos ou tecnologia dependente de certificado dependem da consistência do tempo em todos os sistemas.
• É difícil descobrir o que aconteceu em um sistema se os logs (ou outros dados) não concordarem com o tempo. O mesmo evento pareceria ter ocorrido em momentos diferentes, dificultando a correlação.
• Se o relógio estiver desligado, o faturamento pode ser calculado incorretamente.

Opções de configuração

A sincronização de tempo requer que um serviço de sincronização de tempo esteja em execução na VM Linux, além de uma fonte de informações de tempo precisas para sincronização. Normalmente, ntpd ou chronyd é usado como o serviço de sincronização de tempo, embora existam outros serviços de sincronização de tempo de código aberto que também podem ser usados. A fonte de informações de tempo precisas 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 Linux, exceto após pausas para manutenção do host, conforme descrito acima.

Historicamente, a maioria das imagens do Azure Marketplace com Linux foi configurada de duas maneiras:

• Nenhum serviço de sincronização de tempo está em execução por padrão
• O ntpd está sendo executado como o serviço de sincronização de tempo e sincronizando 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 se o ntpd está sincronizando corretamente, execute o ntpq -p comando.

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

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

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

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

Ferramentas e recursos

Existem alguns comandos básicos para verificar a configuração da sincronização de tempo. A documentação para distribuição Linux terá mais detalhes sobre a melhor maneira de configurar a sincronização de tempo 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

Verifique se há fonte de relógio PTP

Com versões mais recentes do Linux, uma fonte de relógio 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 fonte de 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, então 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, ou seja, o host do Azure.

Em algumas VMs Linux você pode ver vários dispositivos PTP listados. Um exemplo é para Accelerated Networking, 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 pode ser /dev/ptp1, o que dificulta a configuração chronyd com a fonte de relógio correta. Para resolver esse problema, as imagens Linux mais recentes têm uma udev regra que cria o link /dev/ptp_hyperv simbólico para qualquer /dev/ptp entrada correspondente ao host do Azure. Chrony deve sempre ser configurado para usar o /dev/ptp_hyperv link simbólico em vez de /dev/ptp0 ou /dev/ptp1.

Se você estiver tendo problemas com o /dev/ptp_hyperv dispositivo que não está sendo criado, você pode usar a regra e as udev etapas abaixo para configurá-lo:

NOTA: A maioria das distribuições Linux não deve precisar desta regra udev, pois ela foi implementada em versões mais recentes do systemd

Crie o arquivo de udev regras:

$ 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 udev regras com:

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

Cronia

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 PTP. Em vez de chrony, versões mais antigas do Linux usam o daemon Network Time Protocol (ntpd), que não suporta 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 link simbólico /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 mlx5 Mellanox.

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

Por padrão, o chronyd acelera ou diminui o relógio do sistema para corrigir qualquer desvio de tempo. Se a deriva se tornar muito grande, a cronia não consegue consertar a deriva. Para superar isso, o makestep parâmetro em /etc/chrony.conf pode ser alterado para forçar uma sincronização de tempo se o desvio exceder o limite especificado.

makestep 1.0 -1

Aqui, a cronia forçará uma atualização de tempo se o desvio 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 de tempo 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 desativá-lo usando:

$ sudo systemctl disable systemd-timesyncd

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

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

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

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

systemd

Nas versões SUSE e Ubuntu anteriores à 19.10, a sincronização de tempo é configurada usando systemd. Para obter mais informações sobre o Ubuntu, consulte Sincronização de tempo. Para obter mais informações sobre o SUSE, consulte a Seção 4.5.8 nas Notas de versão do SUSE Linux Enterprise Server 12 SP3.

cloud-init

As imagens que usam cloud-init para provisionar a VM podem usar a ntp seção para configurar um serviço de sincronização de tempo. Um exemplo de cloud-init instalando chrony e configurando-o para usar a fonte de 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

Você pode então basear64 a configuração de nuvem acima para uso na osProfile seção em um modelo 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 cloud-init para VMs Linux no Azure.

Próximos passos

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