Czy muszę uruchamiać serwer NTP na każdej maszynie wirtualnej?


18

Czy goście nie mogli w jakiś sposób odziedziczyć czasu systemowego hosta?

Nie ma sensu uruchamiać tego samego demona, aby uzyskać te same wyniki na tej samej maszynie wiele razy, ale nie znalazłem nic związanego z czasem podczas czytania artykułów KVM lub Xen. Rozumiem, że gość uruchamia hosta podczas rozruchu, ale może się wtedy rozpadać. Czy to jest poprawne ?



1
Zakładam, że masz na myśli klienta NTP?
Michael Hampton

1
@MichaelHampton: Tak, rozróżnienie między klientem NTP a serwerem nigdy nie było dla mnie jasne, ponieważ pakiet ntp zawsze zapewnia oba te elementy.
zimbatm

2
Powiązane z tym pytaniem: w przypadku Debiana i pochodnych openntppakiet ma znacznie większą wagę niż ntppakiet. Nie wiąże domyślnie, więc działa tylko jako klient, czego dokładnie tutaj potrzebujemy.
zimbatm

Odpowiedzi:


13

To jest poprawne. Należy zauważyć, że czas nie tylko „może” odpłynąć, ale również odpłynie z powodu faktu, że przerwy między przerwaniami timera (na których często opiera się pomiar czasu w systemie operacyjnym) są rozciągane i kompresowane, tak jak hiperwizor uznałby to za stosowne.

Często stosowanym obejściem na większości platform wirtualizacyjnych (usługi integracji Hyper-V, narzędzia VMWare) jest uruchamianie demona na gościu, który okresowo synchronizuje zegary z hostem VM. Jak zauważył Hauke ​​w komentarzu do twojego pytania, KVM zapewnia dodatkowo parawirtualizowany zegar, który wymagałby załadowania odpowiedniego sterownika do systemu-gościa.

Dalsza lektura:

Pomiar czasu w maszynach wirtualnych VMWare (vmware.com)
Synchronizacja zegara gości KVM (s19n.net)


Wielkie dzięki. Dla tych na EC2, Xen wydaje się również zapewniać źródło zegara: cat /sys/devices/system/clocksource/clocksource0/current_clocksource=> xen
zimbatm

Nadal zaleca się chronyd, nawet jeśli zegar kvm jest używany z hostem jako serwerem i maszyną wirtualną jako klientem.
akostadinov

21

W idealnym świecie goście maszyny wirtualnej zachowaliby idealny czas, a przynajmniej tak doskonały, jak zapewnia gospodarz. Niestety nie żyjemy w idealnym świecie.

Opierając się na moim doświadczeniu z praktycznie każdym hiperwizorem znanym człowiekowi, zawsze uruchamiam klienta NTP na maszynach wirtualnych, bez wyjątku. Moją zwykłą konfiguracją jest ntpd z opcją -g lub ntpdate rozpoczynający się tuż przed nim dla starych systemów, aby skrócić czas (który może być bardzo niezsynchronizowany podczas uruchamiania systemu).

KVM ma prawie idealną konfigurację z parawirtualizowanym zegarem czasu rzeczywistego ; goście z odpowiednim sterownikiem (przynajmniej najnowszym Linuksem) utrzymają czas, a także host. Ale nadal coś idzie nie tak: na przykład, host może nie działać z NTP, host może mieć niepoprawną strefę czasową, zegar hosta może być po prostu zły, itp.

VMware i Hyper-V znajdują się pośrodku. Każde z nich ma narzędzie przeznaczone do uruchamiania na gościu, które okresowo synchronizuje zegar z hostem, ale znowu jest to podatne na wszelkie istniejące problemy z zegarem hosta.

Goście na moim testowym serwerze Hyper-V również wykazywali dziwne zachowanie: nawet w przypadku usług integracyjnych zegar gościa dryfowałby szybciej niż 500 ppm, uniemożliwiając działanie ntpd ( uważa, że ​​zegar jest szalony, jeśli płynie szybciej niż ten ). Musiałem zmienić tych gości na chroniczne , co pozwala na dostosowanie tej wartości .

Xen jest najgorszy pod tym względem; nie ma absolutnie żadnej synchronizacji, a uruchomienie NTP u gości jest prawie wymagane. (Powiedziano mi, że bardzo najnowsze wersje Xen mają jakąś synchronizację, ale osobiście jeszcze z nią nie pracowałem).

Gorzej jest, gdy hiperwizor hosta nie jest pod twoją kontrolą, na przykład chmura publiczna. Jesteś na łasce dostawcy w odniesieniu do zegara hosta, a jeśli nie starają się go zsynchronizować, przegrywasz.

Mając to na uwadze, uruchamianie klientów NTP na maszynach wirtualnych jest prawie wymagane, jeśli potrzebujesz nawet pół-dokładnego zegara. Uwaga: Jeśli korzystasz z maszyn wirtualnych z systemem Windows, uzyskaj zewnętrznego klienta NTP, który stale dostosowuje zegar; niska wymówka dla klienta dostarczanego z systemem Windows dostosowuje zegar tylko raz w tygodniu , co jest całkowicie absurdalne.


Czy ntpdatewystarcza codzienne zadanie crona, czy musi to być demon NTTP?
AngerClown

4
Naprawdę potrzebujesz czegoś, aby zsynchronizować zegar w sposób ciągły, ponieważ może zejść wystarczająco daleko z synchronizacji w ciągu dnia, aby spowodować problemy. A niektóre programy nie lubią ustawiania zegara.
Michael Hampton

Problem z demonem NTTP polega na tym, że jego przeznaczeniem jest przede wszystkim zapewnienie czasu innym, a zatem przestanie działać, jeśli czas zbytnio się rozsuwa. Naprawdę chciałbym, aby istniało coś takiego jak ntpdate, które działałoby nieprzerwanie i nie wiązało żadnych portów.
zimbatm

1
@JonasPfenniger Jeśli ntpd nie działa, spróbuj użyć chrony (jak sugerowano powyżej). Można go dostroić nieco więcej niż ntpd, aby dostosować się do dziwnych scenariuszy, które widzimy na maszynach wirtualnych.
Michael Hampton

3
Chociaż zgadzam się z 95% tego, co powiedziałeś, chciałem tylko podkreślić, że klient Windows korzystający z NTP nie ogranicza się do jednej zmiany zegara na tydzień. Poniższy klucz reg pozwala efektywnie zdefiniować interwał aktualizacji: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\UpdateIntervalWartość jest definiowana w sekundach i zwykle jest ustawiona na 360000 (100 godzin), ale możesz ustawić ją na 900, aby synchronizować co 15 minut, jeśli twoje aplikacje są szczególnie wrażliwe na czas. Pamiętaj, aby później ponownie uruchomić usługę W32Time.
kayjay

3

Poleciłbym używać NTP, ponieważ jest dobrze znany i istnieje już od dłuższego czasu. Regulacja zegara nie jest trywialna. NTP rozwiązało ten problem.

Oficjalna linia VMware jest wykorzystanie jednego mechanizmu, z NTP korzystne , ponieważ jest bardziej drobnoziarnisty i wziąć mniejsze kroki, aby ustawić czas. Wewnętrzne rozwiązanie VMware wymaga większych kroków. Kiedy biegniesz, oboje mogą ze sobą walczyć. Wewnętrzne rozwiązanie VMware robi duży krok, a następnie NTP dostosowuje je i cofa nieco.

W praktyce jednak biegamy jednocześnie i nie widziałem jeszcze problemu.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.