Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: ✔️ Maszyny wirtualne z systemem Linux ✔️ Elastyczne zestawy skalowania ✔️ Jednolite zestawy skalowania
Synchronizacja czasu jest ważna dla korelacji zabezpieczeń i zdarzeń. Czasami jest używany do implementacji transakcji rozproszonych. Dokładność czasu między wieloma systemami komputerowym jest osiągana przez synchronizację. Na synchronizację może wpływać wiele czynników, w tym ponowne uruchomienia i ruch sieciowy między źródłem czasu a komputerem pobierającym czas.
Platforma Azure jest wspierana przez infrastrukturę z systemem Windows Server 2016. W systemie Windows Server 2016 ulepszono algorytmy służące do korygowania czasu i dostosowywania zegara lokalnego tak, aby synchronizował się z UTC. Funkcja Dokładnego czasu systemu Windows Server 2016 znacznie poprawiła sposób działania usługi VMICTimeSync, która zarządza maszynami wirtualnymi z hostem w celu uzyskania dokładnego czasu. Ulepszenia obejmują dokładniejszy początkowy czas uruchamiania maszyny wirtualnej lub przywracania maszyny wirtualnej i poprawiania opóźnienia przerwań.
Uwaga
Aby uzyskać więcej informacji, zobacz Jak działa usługa czasowa systemu Windows. Informacje specyficzne dla systemu Windows Server 2016 można również znaleźć na stronie Dokładny czas dla systemu Windows Server 2016.
Overview
Dokładność zegara systemowego komputera ocenia się na podstawie tego, jak blisko wzorca czasu uniwersalnego koordynowanego (UTC) znajduje się ten zegar. UTC jest określany na podstawie międzynarodowego zbioru precyzyjnych zegarów atomowych, które mogą mylić się najwyżej o jedną sekundę na 300 lat. Jednak odczytywanie czasu UTC bezpośrednio wymaga wyspecjalizowanego sprzętu. Zamiast tego serwery czasu są synchronizowane z czasem UTC i są dostępne z innych komputerów w celu zapewnienia skalowalności i niezawodności. Każdy komputer ma uruchomioną usługę synchronizacji czasu, która wie, jakiego czasu używać serwerów i okresowo sprawdza, czy zegar komputera musi być poprawiony i dostosowuje czas w razie potrzeby.
Hosty Azure są synchronizowane z wewnętrznymi serwerami czasu firmy Microsoft, które pobierają czas z należących do firmy Microsoft urządzeń Stratum 1 wyposażonych w anteny GPS. Maszyny wirtualne na platformie Azure mogą albo korzystać z hosta do przekazywania dokładnego czasu (czas hosta) maszynie wirtualnej, albo bezpośrednio pobierać czas z serwera czasu, bądź też korzystać z połączenia obu tych metod.
Na sprzęcie autonomicznym system operacyjny Linux odczytuje tylko zegar sprzętu hosta podczas rozruchu. Następnie zegar jest utrzymywany przy użyciu czasomierza przerwań w jądrze systemu Linux. W tej konfiguracji zegar będzie się z czasem rozjeżdżać. W nowszych dystrybucjach systemu Linux na platformie Azure maszyny wirtualne mogą używać dostawcy VMICTimeSync uwzględnionego w usługach integracji systemu Linux (LIS), aby częściej wykonywać zapytania dotyczące aktualizacji zegara z hosta.
Interakcje maszyn wirtualnych z hostem mogą również mieć wpływ na zegar. Podczas konserwacji pamięci maszyny wirtualne są wstrzymywane przez maksymalnie 30 sekund. Na przykład przed rozpoczęciem konserwacji zegar maszyny wirtualnej pokazuje 10:00:00 i trwa 28 sekund. Po wznowieniu działania maszyny wirtualnej zegar na maszynie wirtualnej nadal będzie pokazywał godzinę 10:00:00, co oznacza, że będzie spóźniony o 28 sekund. Aby rozwiązać ten problem, usługa VMICTimeSync monitoruje, co dzieje się na hoście i aktualizuje zegar godziny dnia na maszynach wirtualnych z systemem Linux, aby zrekompensować.
Bez pracy synchronizacji czasu zegar na maszynie wirtualnej będzie gromadzić błędy. Gdy działa tylko jedna maszyna wirtualna, wpływ może być nieznaczny, chyba że obciążenie wymaga bardzo precyzyjnej synchronizacji czasu. Jednak w większości przypadków mamy wiele połączonych maszyn wirtualnych, które wykorzystują czas do śledzenia transakcji, a czas musi być spójny w całym wdrożeniu. Gdy czas między maszynami wirtualnymi jest inny, można zobaczyć następujące efekty:
- Uwierzytelnianie zakończy się niepowodzeniem. Protokoły bezpieczeństwa, takie jak Kerberos czy technologie oparte na certyfikatach, wymagają, aby czas był zsynchronizowany we wszystkich systemach.
- Trudno ustalić, co się stało w systemie, jeśli dzienniki (lub inne dane) nie zgadzają się na czas. To samo zdarzenie wyglądałoby tak, jakby miało to miejsce w różnych momentach, co utrudnia korelację.
- Jeśli zegar jest wyłączony, rozliczenia mogą być obliczane niepoprawnie.
Opcje konfiguracji
Synchronizacja czasu wymaga uruchomienia usługi synchronizacji czasu na maszynie wirtualnej z systemem Linux oraz źródła dokładnych informacji o czasie synchronizacji. Zazwyczaj ntpd lub chronyd jest używany jako usługa synchronizacji czasu, choć istnieją inne usługi synchronizacji czasu open source, które mogą być również używane. Źródłem dokładnych informacji o czasie może być host platformy Azure lub usługa czasu zewnętrznego, która jest dostępna za pośrednictwem publicznego Internetu. Sama usługa VMICTimeSync nie zapewnia ciągłej synchronizacji czasu między hostem platformy Azure i maszyną wirtualną z systemem Linux, z wyjątkiem przerw w konserwacji hosta zgodnie z powyższym opisem.
W przeszłości większość obrazów witryny Azure Marketplace z systemem Linux została skonfigurowana na jeden z dwóch sposobów:
- Usługa synchronizacji czasu nie jest domyślnie uruchomiona
- Ntpd działa jako usługa synchronizacji czasu i synchronizuje się z zewnętrznym źródłem czasu NTP, które jest dostępne za pośrednictwem sieci. Na przykład obrazy Marketplace dla Ubuntu 18.04 LTS korzystają z ntp.ubuntu.com.
Aby potwierdzić, że ntpd jest poprawnie synchronizowany, uruchom ntpq -p polecenie .
Niektóre obrazy z witryny Azure Marketplace z systemem Linux są zmieniane tak, aby używały usługi synchronizacji czasu chronyd, a chronyd jest skonfigurowany do synchronizacji z hostem Azure zamiast z zewnętrznym źródłem czasu NTP. Czas hosta platformy Azure jest zwykle najlepszym źródłem czasu do synchronizacji, ponieważ jest utrzymywany z dużą dokładnością i niezawodnością oraz jest dostępny bez zmiennych opóźnień sieciowych nieodłącznie związanych z dostępem do zewnętrznego źródła czasu NTP przez publiczną sieć Internet.
Funkcja VMICTimeSync jest używana równolegle i udostępnia dwie funkcje:
- Natychmiast aktualizuje zegar czasu maszyny wirtualnej z systemem Linux po zdarzeniu konserwacyjnym hosta
- Tworzy źródło sprzętowego zegara IEEE 1588 Precision Time Protocol (PTP) jako urządzenie /dev/ptp, które zapewnia dokładny czas z hosta platformy Azure. Chronyd można skonfigurować do synchronizacji z tym źródłem czasu (co jest domyślną konfiguracją w najnowszych obrazach systemu Linux). Dystrybucje systemu Linux z jądrem w wersji 4.11 lub nowszej (lub w wersji 3.10.0-693 lub nowszej dla systemu RHEL 7) obsługują urządzenie /dev/ptp. W przypadku wcześniejszych wersji jądra, które nie obsługują /dev/ptp dla czasu hosta platformy Azure, możliwa jest tylko synchronizacja z zewnętrznym źródłem czasu.
Konfigurację domyślną można zmienić. Starszy obraz skonfigurowany do używania ntpd i zewnętrznego źródła czasu można zmienić tak, aby używał chronyd i /dev/ptp urządzenia dla czasu hosta platformy Azure. Podobnie obraz korzystający z czasu hosta platformy Azure za pośrednictwem urządzenia /dev/ptp można skonfigurować do używania zewnętrznego źródła czasu NTP, jeśli jest to wymagane przez aplikację lub obciążenie.
Narzędzia i zasoby
Istnieją pewne podstawowe polecenia służące do sprawdzania konfiguracji synchronizacji czasu. Dokumentacja dystrybucji systemu Linux zawiera więcej szczegółowych informacji na temat najlepszego sposobu konfigurowania synchronizacji czasu dla tej dystrybucji.
Usługi integracji
Sprawdź, czy usługa integracji (hv_utils) jest załadowana.
$ sudo lsmod | grep hv_utils
Powinien zostać wyświetlony komunikat podobny do następującego:
hv_utils 24418 0
hv_vmbus 397185 7 hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc
Sprawdź źródło zegara PTP
W nowszych wersjach systemu Linux źródło zegara Precision Time Protocol (PTP) odpowiadające hostowi Azure jest dostępne w ramach dostawcy VMICTimeSync. W starszych wersjach oprogramowania Red Hat Enterprise Linux 7.x można pobrać usługi Integracji z systemem Linux i użyć ich do zainstalowania zaktualizowanego sterownika. Gdy źródło zegara PTP jest dostępne, urządzenie z systemem Linux ma postać /dev/ptpx.
Sprawdź, które źródła zegara PTP są dostępne.
$ ls /sys/class/ptp
W tym przykładzie zwracana wartość to ptp0, więc używamy jej do sprawdzania nazwy zegara. Aby sprawdzić urządzenie, sprawdź nazwę zegara.
$ sudo cat /sys/class/ptp/ptp0/clock_name
Powinno to zwrócić wartość hyperv, co oznacza host platformy Azure.
W niektórych maszynach wirtualnych z systemem Linux możesz zobaczyć wiele wymienionych urządzeń PTP. Jednym z przykładów jest to, że w przypadku funkcji Accelerated Networking sterownik Mellanox mlx5 również tworzy urządzenie /dev/ptp. Ponieważ kolejność inicjowania może być inna przy każdym uruchomieniu systemu Linux, urządzenie PTP odpowiadające hostowi platformy Azure może być /dev/ptp0 lub może to być /dev/ptp1, co utrudnia skonfigurowanie chronyd przy użyciu poprawnego źródła zegara. Aby rozwiązać ten problem, najnowsze obrazy systemu Linux zawierają regułę udev, która tworzy dowiązanie symboliczne /dev/ptp_hyperv do tego wpisu /dev/ptp, który odpowiada hostowi platformy Azure. Funkcja Chrony powinna być zawsze skonfigurowana tak, aby używała symlinku /dev/ptp_hyperv zamiast /dev/ptp0 lub /dev/ptp1.
Jeśli masz problemy z tym, że urządzenie /dev/ptp_hyperv nie jest tworzone, możesz skorzystać z reguły udev i poniższych kroków, aby je skonfigurować:
UWAGA: Większość dystrybucji systemu Linux nie powinna wymagać tej reguły udev, ponieważ jest ona zaimplementowana w nowszych wersjach systemd
udev Utwórz plik reguł:
$ 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
Uruchom ponownie maszynę wirtualną lub przeładuj reguły udev poleceniem:
$ sudo udevadm control --reload
$ sudo udevadm trigger --subsystem-match=ptp --action=add
chrony
W systemie Ubuntu 19.10 (i nowszych wersjach) i Red Hat Enterprise Linux 8.x funkcja chrony jest skonfigurowana do korzystania z zegara źródłowego PTP. Zamiast chrony starsze wersje systemu Linux używają demona protokołu czasu sieciowego (ntpd), który nie obsługuje źródeł PTP. Aby włączyć ptP w tych wersjach, chrony muszą być ręcznie zainstalowane i skonfigurowane (w pliku chrony.conf) przy użyciu następującej instrukcji:
refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2
Jeśli dostępne jest dowiązanie symboliczne /dev/ptp_hyperv, użyj go zamiast /dev/ptp0, aby uniknąć nieporozumień z urządzeniem /dev/ptp utworzonym przez sterownik Mellanox mlx5.
Informacje o stratum nie są automatycznie przekazywane z hosta platformy Azure do gościa z systemem Linux. Poprzedni wiersz konfiguracji określa, że źródło czasu hosta Azure ma być traktowane jako Stratum 2, co z kolei powoduje, że gość systemu Linux zgłasza się jako Stratum 3. Możesz zmienić ustawienie warstwy w wierszu konfiguracji, jeśli chcesz, aby gość systemu Linux zgłaszał się inaczej.
Domyślnie chronyd przyspiesza lub spowalnia zegar systemowy, aby naprawić dowolny dryf czasu. Jeśli dryf stanie się zbyt duży, chrony nie naprawi dryfu. Aby rozwiązać ten problem, makestep parametr w pliku /etc/chrony.conf można zmienić, aby wymusić synchronizację czasu, jeśli dryf przekroczy określony próg.
makestep 1.0 -1
W tym miejscu chrony wymusi aktualizację czasu, jeśli dryf jest większy niż 1 sekunda. Aby zastosować zmiany, uruchom ponownie usługę chronyd:
$ sudo systemctl restart chronyd && sudo systemctl restart chrony
Komunikaty synchronizacji czasu dotyczące systemd-timesyncd
W niektórych przypadkach usługa systemd-timesyncd może być nadal włączona i próbuje przeprowadzić synchronizację po ponownym uruchomieniu, jeśli nadal widzisz komunikaty w dzienniku systemowym, które wyglądają podobnie do:
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)
Można ją wyłączyć przy użyciu:
$ sudo systemctl disable systemd-timesyncd
W większości przypadków usługa systemd-timesyncd podejmie próbę synchronizacji czasu podczas uruchamiania systemu, ale po uruchomieniu usługi chrony to ona ją zastąpi i stanie się domyślnym źródłem synchronizacji czasu.
Aby uzyskać więcej informacji na temat systemów Ubuntu i NTP, zobacz Synchronizacja czasu.
Aby uzyskać więcej informacji o systemach Red Hat i NTP, zobacz Konfigurowanie NTP.
Aby uzyskać więcej informacji na temat chrony, zobacz Korzystanie z chrony.
systemd
W wersjach SUSE i Ubuntu przed wersją 19.10 synchronizacja czasu jest skonfigurowana przy użyciu programu systemd. Aby uzyskać więcej informacji na temat systemu Ubuntu, zobacz Synchronizacja czasu. Aby uzyskać więcej informacji na temat systemu SUSE, zobacz Synchronizacja czasu w systemie SUSE.
cloud-init
Obrazy używające cloud-init do aprowizacji maszyny wirtualnej mogą używać sekcji ntp do skonfigurowania usługi synchronizacji czasu. Przykład użycia cloud-init do zainstalowania pakietu chrony i skonfigurowania go do korzystania ze źródła czasu PTP dla maszyn wirtualnych z systemem 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
Następnie możesz zakodować powyższą konfigurację cloud-config w formacie Base64, aby użyć jej w sekcji osProfile w szablonie ARM:
[Convert]::ToBase64String((Get-Content -Path ./cloud-config.txt -Encoding Byte))
"osProfile": {
"customData": "I2Nsb3VkLWNvbmZpZwpudHA6CiAgZW5hYmxlZDogdHJ1ZQogIG50cF9jbGllbnQ6IGNocm9ueQogIGNvbmZpZzoKICAgIGNvbmZwYXRoOiAvZXRjL2Nocm9ueS9jaHJvbnkuY29uZgogICAgcGFja2FnZXM6CiAgICAgLSBjaHJvbnkKICAgIHNlcnZpY2VfbmFtZTogY2hyb255CiAgICB0ZW1wbGF0ZTogfAogICAgICAgIyMgdGVtcGxhdGU6amluamEKICAgICAgIGRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvY2hyb255LmRyaWZ0CiAgICAgICBsb2dkaXIgL3Zhci9sb2cvY2hyb255CiAgICAgICBtYXh1cGRhdGVza2V5IDEwMC4wCiAgICAgICByZWZjbG9jayBQSEMgL2Rldi9wdHBfaHlwZXJ2IHBvbGwgMyBkcG9sbCAtMgogICAgICAgbWFrZXN0ZXAgMS4wIC0x"
}
Aby uzyskać więcej informacji na temat pakietu cloud-init na platformie Azure, zobacz Omówienie obsługi pakietu cloud-init dla maszyn wirtualnych z systemem Linux na platformie Azure.
Dalsze kroki
Aby uzyskać więcej informacji, zobacz Dokładny czas dla systemu Windows Server 2016.