Синхронизация времени для виртуальных машин Linux в Azure

Статья
04/26/2023

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

Область применения: ✔️ Виртуальные машины Linux ✔️ Гибкие масштабируемые наборы ✔️ Универсальные масштабируемые наборы

Синхронизация времени важна для безопасности и корреляции событий. Иногда он используется для реализации распределенных транзакций. Точность времени в нескольких компьютерных системах достигается за счет синхронизации. На синхронизацию может влиять ряд факторов, включая перезагрузки и сетевой трафик между источником времени и получающим сведения о времени компьютером.

Платформа Azure основана на инфраструктуре, работающей под управлением Windows Server 2016. В Windows Server 2016 реализованы улучшенные алгоритмы коррекции времени и синхронизации локальных часов с временем в формате UTC. Функция "Точное время" в Windows Server 2016 значительно улучшила работу службы VMICTimeSync, которая регулирует точность времени в виртуальных машинах и на сервере. К числу улучшений относится более точное исходное время при запуске или восстановлении виртуальной машины, а также коррекция задержки при прерывании.

Примечание.

Краткий обзор службы времени в Windows можно получить в этом видео.

Дополнительные сведения см. в статье Точное время в Windows Server 2016.

Обзор

Точность часов компьютера оценивается по тому, насколько близки их показания к стандартному времени в формате UTC. Время UTC устанавливается по точным атомным часам, отклонение которых не превышает одной секунды за 300 лет. Однако для считывания времени UTC напрямую требуется специальное оборудование. Вместо этого со временем UTC синхронизируются серверы времени, к которым затем обращаются другие компьютеры. Таким образом достигается масштабируемость и надежность. На каждом компьютере выполняется служба синхронизации времени, которая знает, какие серверы времени следует использовать, и регулярно проверяет необходимость коррекции часов компьютера, при необходимости корректируя время.

Узлы Azure синхронизированы с внутренними серверами времени Майкрософт, которые получают время от принадлежащих Майкрософт устройств Stratum 1 с антеннами GPS. Виртуальные машины Azure могут получать точное время от узла (время узла) непосредственно с сервера времени или использовать эти способы в сочетании.

На автономном оборудовании операционная система Linux считывает показания аппаратных часов узла только при загрузке. После этого время отсчитывается с помощью таймера прерываний в ядре Linux. В такой конфигурации в показаниях часов со временем будут возникать отклонения. В более новых дистрибутивах Linux в Azure виртуальные машины могут использовать поставщик VMICTimeSync, входящий в состав служб интеграции Linux (LIS), чтобы чаще запрашивать актуальное время от узла.

Взаимодействие виртуальной машины с узлом также может влиять на показания часов. Во время обслуживания с сохранением памяти виртуальные машины приостанавливаются на срок до 30 секунд. Например, до начала обслуживания часы виртуальной машины показывают 10:00:00, и приостановка длится 28 секунд. Когда виртуальная машина возобновляет работу, ее часы по-прежнему показывают 10:00:00, то есть отстают на 28 секунд. Чтобы скорректировать это отклонение, служба VMICTimeSync отслеживает происходящее в узле и обновляет часы истинного времени в виртуальных машинах Linux.

При отсутствии синхронизации времени на часах виртуальной машины накапливались бы ошибки. Если существует только одна виртуальная машина, это может не быть значительным, если рабочая нагрузка не требует точной временного хранения. Но в большинстве случаев у нас есть несколько взаимосвязанных виртуальных машин, которые используют время для отслеживания транзакций, и время должно быть согласовано во всем развертывании. Если время в виртуальных машинах различается, могут иметь место указанные ниже последствия.

Проверка подлинности будет завершаться сбоем. Протоколы безопасности, такие как Kerberos, или технологии, зависящие от сертификатов, требуют согласования времени в системах.
Трудно выяснить, что произошло в системе, если журналы (или другие данные) не согласуются вовремя. Одно и то же событие будет представляться как произошедшее в разное время, что усложняет корреляцию.
Если часы идут неверно, могут происходить ошибки при выставлении счетов.

Варианты конфигурации

Синхронизация времени требует, чтобы служба синхронизации времени выполнялись на виртуальной машине Linux, а также источник точных сведений о времени, с которыми следует синхронизировать. Обычно в качестве службы синхронизации времени используется ntpd или chronyd, хотя существуют и другие общедоступные службы синхронизации времени, которые также можно использовать. В качестве источника данных о точном времени можно использовать узел Azure или внешнюю службу времени, доступ к которой осуществляется через общедоступный Интернет. По себе служба VMICTimeSync не обеспечивает постоянную синхронизацию времени между узлом Azure и виртуальной машиной Linux, за исключением приостановки обслуживания узлов, как описано выше.

Традиционно большинство образов Azure Marketplace с Linux настраиваются одним из двух способов:

Служба синхронизации времени по умолчанию не запущена
Ntpd выполняется как служба синхронизации времени и синхронизируется с внешним источником времени NTP, доступ к которому осуществляется по сети. Например, в образах Marketplace Ubuntu 18.04 LTS используется сервер ntp.ubuntu.com.

Чтобы проверить правильность синхронизации ntpd, выполните команду ntpq -p.

Некоторые образы Azure Marketplace с Linux изменены с целью использования chronyd в качестве службы синхронизации времени, а chronyd настроен на синхронизацию с узлом Azure, а не внешним источником времени NTP. Время узла Azure обычно является лучшим источником времени для синхронизации, так как оно поддерживается точно и надежно, и доступно без задержек в сети переменных, присущих доступу к внешнему источнику времени NTP через общедоступный Интернет.

VMICTimeSync используется параллельно и выполняет две функции:

Немедленное обновление часов истинного времени виртуальной машины Linux после события обслуживания узла
Создание экземпляра источника истинного времени для аппаратного обеспечения по протоколу точного времени (PTP) IEEE 1588 в качестве устройства /dev/ptp, которое передает точное истинное время с узла Azure. Можно настроить синхронизацию chronyd с этим источником истинного времени (в новейших образах Linux эта конфигурация установлена по умолчанию). Дистрибутивы Linux с ядром версии 4.11 или новее (или версией 3.10.0-693 или новее для RHEL/CentOS 7) поддерживают устройство /dev/ptp. Для более ранних версий ядра, которые не поддерживают /dev/ptp для времени узла Azure, возможна только синхронизация с внешним источником времени.

Разумеется, конфигурацию по умолчанию можно изменить. Образ предыдущих версий, настроенный на использование ntpd и внешнего источника времени, можно настроить на использование chronyd и устройства /dev/ptp для передачи времени с узла Azure. Аналогично, образ, использующий время узла Azure через устройство /dev/ptp, можно настроить для использования внешнего источника времени NTP, если этого требуют приложения или рабочая нагрузка.

Инструменты и ресурсы

Есть ряд основных команд, позволяющих проверить конфигурацию синхронизации времени. Подробные сведения об оптимальных способах настройки синхронизации времени для определенного дистрибутива Linux можно найти в документации к нему.

Службы интеграции

Проверьте, загружена ли служба интеграции (hv_utils).

$ sudo lsmod | grep hv_utils

Должно отображаться примерно следующее:

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

Проверка источника времени PTP

В более новых версиях Linux в рамках поставщика VMICTimeSync доступен источник времени PTP, соответствующий узлу Azure. В более ранних версиях Red Hat Enterprise Linux или CentOS 7.x можно скачать службы интеграции Linux и использовать их для установки обновленного драйвера. Когда источник времени PTP доступен, устройство Linux отображается как /dev/ptpx.

Проверьте доступные источники времени PTP.

$ ls /sys/class/ptp

В этом примере возвращается значение ptp0. Мы используем его для проверки имени часов. Чтобы проверить устройство, определите имя часов.

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

Должно быть получено значение hyperv, означающее узел Azure.

На некоторых виртуальных машинах Linux может отображаться несколько устройств PTP. Один из примеров — для ускорения сети драйвер Mellanox mlx5 также создает устройство /dev/ptp. Поскольку порядок инициализации может отличаться при каждом запуске Linux, устройством PTP, соответствующим узлу Azure, может быть /dev/ptp0 или /dev/ptp1, что усложняет настройку chronyd с корректным источником истинного времени. Для решения этой проблемы в новых версиях образов Linux существует правило udev, которое создает символьную ссылку /dev/ptp_hyperv к той записи /dev/ptp, которая соответствует узлу Azure. Chrony всегда следует настроить для использования /dev/ptp_hyperv символьной связи вместо /dev/ptp0 или /dev/ptp1.

Если у вас возникли проблемы с устройством /dev/ptp_hyperv , которое не создано, можно использовать udev правило и описанные ниже действия, чтобы настроить его:

ПРИМЕЧАНИЕ. Большинство дистрибутивов Linux не должны нуждаться в этом правиле udev, так как он был реализован в более новых версиях системных

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

Перезагрузите виртуальную машину ИЛИ перезагрузите udev правила с помощью:

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

chrony

В Ubuntu версии 19.10 и выше, Red Hat Enterprise Linux и CentOS 8.x для средства chrony настроено использование источника времени PTP. В старых выпусках Linux вместо chrony используется управляющая программа NTP (ntpd), которая не поддерживает источники PTP. Чтобы использовать PTP в этих выпусках, необходимо вручную установить и настроить chrony (в chrony.conf) с помощью следующей инструкции:

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

Если доступна символьная ссылка /dev/ptp_hyperv, используйте ее вместо /dev/ptp0, чтобы избежать возможных ошибок с устройством /dev/ptp, создаваемым с помощью драйвера Mellanox mlx5.

Сведения о Stratum не передаются автоматически с узла Azure на гостевой компьютер Linux. В приведенной выше строке конфигурации указывается, что источник времени узла Azure должен рассматриваться как Stratum 2, что, в свою очередь, приводит к тому, что гостевой компьютер Linux должен сообщать о себе как Stratum 3. Вы можете изменить параметр Stratum в строке конфигурации, если хотите, чтобы гостевой компьютер Linux мог сообщить о себе по-другому.

По умолчанию chrony ускоряет или замедляет работу системных часов, чтобы устранить смещение времени. Если смещение становится слишком большим, хрония не удается исправить смещение. Чтобы устранить эту проблему, можно изменить параметр makestep в файле /etc/chrony.conf так, чтобы принудительно вызывать синхронизацию времени при достижении заданного порога смещения.

makestep 1.0 -1

В нашем примере chrony будет обновлять время, если смещение превысит 1 секунду. Чтобы применить изменения, перезапустите службу chronyd:

$ sudo systemctl restart chronyd && sudo systemctl restart chrony

В некоторых случаях служба systemd-timesyncd может по-прежнему быть включена и пытаться выполнить синхронизацию при перезагрузке, если вы по-прежнему видите сообщения в системном журнале, которые выглядят примерно так:

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)

Его можно отключить с помощью:

$ sudo systemctl disable systemd-timesyncd

В большинстве случаев systemd-timesyncd будет пытаться во время загрузки, но после запуска хронии он перезаписывается и становится источником синхронизации времени по умолчанию.

Дополнительные сведения об NTP в Ubuntu см. в статье, посвященной синхронизации времени.

Дополнительные сведения об NTP в Red Hat см. в статье, посвященной настройке NTP.

Дополнительные сведения о chrony см. в разделе, посвященном использованию chrony.

systemd

В SUSE и Ubuntu версии 19.10 и ниже синхронизация времени настраивается с помощью systemd. Дополнительные сведения об Ubuntu см. в статье, посвященной синхронизации времени. Дополнительные сведения о SUSE см. в разделе 4.5.8 статьи с заметками о выпуске SUSE Linux Enterprise Server 12 с пакетом обновления 3 (SP3).

cloud-init.

Образы, использующие cloud-init для подготовки виртуальной машины, могут использовать ntp раздел для настройки службы синхронизации времени. Пример установки хронии cloud-init и его настройки для использования источника часов PTP для виртуальных машин 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

Затем можно использовать base64 выше cloud-config для использования в разделе в osProfile шаблоне ARM:

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

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

Дополнительные сведения об cloud-init в Azure см. в статье "Общие сведения о поддержке cloud-init для виртуальных машин Linux в Azure".

Следующие шаги