Opis

Wtyczka do sprawdzania kondycji Nutanix NCC check_ntp weryfikuje konfigurację NTP maszyn CVM (kontroler VM) i hostów hiperwizora. Sprawdza również, czy w klastrze występują jakiekolwiek przesunięcia czasowe.

Wtyczka check_ntp zawiera wiele indywidualnych kontroli, które koncentrują się na określonych scenariuszach związanych z NTP:

• Synchronizacja czasu CVM/PCVM NTP — określa, czy CVM/PCVM może synchronizować czas z dowolnym ze skonfigurowanych serwerów NTP
• Synchronizacja czasu Hypervisor NTP (tylko AHV + ESXi) — określa, czy host jest w stanie zsynchronizować czas z dowolnym ze skonfigurowanych serwerów NTP

Uwaga: Sprawdzanie konfiguracji NTP, identyfikator sprawdzenia 103076 jest wycofane w wersji NCC 4.0.0.

Ta wtyczka działa również na Prism Central (PC), z wyjątkiem sprawdzania hiperwizora.

Ta wtyczka do sprawdzania stanu została wprowadzona w wersji 3.1 NCC i łączy wszystkie kontrole NTP z poprzednich wersji NCC. W Prism Central ta kontrola została wprowadzona w NCC w wersji 3.5.3. Funkcja ostrzegania tych kontroli została wprowadzona w NCC 3.6.2.

Możliwe przyczyny

Jeśli ta kontrola stanu zwróci wynik inny niż PASS, możliwe są następujące przyczyny:

• W klastrze nie ma skonfigurowanych serwerów NTP.
• Na hiperwizorze nie skonfigurowano żadnych serwerów NTP.
• Wszystkie lub niektóre serwery NTP skonfigurowane na hiperwizorze nie są takie same, jak te skonfigurowane na maszynach CVM lub PC VM.
• Skonfigurowany serwer NTP jest nieosiągalny lub nie odpowiada na zapytania NTP.
• Skonfigurowany serwer NTP nie jest niezawodny ani stabilny.
• Serwer NTP jest skonfigurowany z nazwą hosta, ale nie można go rozpoznać z powodu problemów z rozpoznawaniem DNS/nazw.
• Port NTP (UDP/123) nie jest otwarty.
• Czas w klastrze nie jest zsynchronizowany i jest przesunięty w przyszłość o co najmniej 5 sekund w porównaniu z rzeczywistym czasem na serwerach NTP.
• Serwer NTP przekazuje parametr, który klient NTP CVM lub PC VM uważa za nieodpowiedni do synchronizacji NTP, taki jak wysoka wartość dyspersji, przesunięcie, jitter, zasięg lub warstwa.
• Serwer NTP oparty na Windows (AD PDC), który domyślnie używa zegara lokalnego jako źródła czasu, będzie reklamował się jako mniej odpowiednie źródło NTP, umieszczając wartość rozproszenia wynoszącą 10 sekund w parametrze NTP tego serwera. W32time nie został zaprojektowany z precyzją wymaganą dla NTP i nie gwarantuje tolerancji lepszej niż +/- 5 minut.
• Usługa Genesis została niedawno ponownie uruchomiona, a synchronizacja NTP nadal oczekuje lub jeśli konfiguracja NTP została zmieniona, efekt może zająć trochę czasu. Zgodnie z protokołem NTP potrzeba około 5 minut (pięć dobrych próbek), zanim serwer NTP zostanie zaakceptowany jako źródło synchronizacji. Oczekiwanie i ponowne uruchomienie sprawdzania po 10-15 minutach może dać inny wynik, jeśli zapewniło to wystarczająco dużo czasu, aby zmiana zaczęła obowiązywać i została zsynchronizowana.

  Na przykład po ponownym uruchomieniu genesis polecenie ntpq pokazuje, że czas nadal synchronizuje się z .LOCL.

Następnie, po odczekaniu 10-15 minut, polecenie ntpq pokazuje teraz:

W związku z tym natychmiastowe ponowne uruchomienie testu zakończy się niepowodzeniem, ale ponowne uruchomienie go po pewnym czasie, powiedzmy 10-15 minutach, powinno zakończyć się POWODZENIEM.

Objawy i wpływ

Jeśli ta kontrola stanu nie zwróci wyniku PASS, działanie klastra może być zagrożone różnymi symptomami/wpływami, takimi jak:

• Użytkownicy nie mogą zalogować się do konsoli internetowej Prism za pomocą LDAP lub innych zintegrowanych usług katalogowych.
• Klaster nie może się uruchomić lub nie działa prawidłowo z powodu znacznego przesunięcia czasowego po awarii lub konserwacji.
• Niedokładne rejestrowanie i zbieranie dzienników.
• Niedokładne wyniki kontroli stanu zależą od dokładnych ram czasowych i korelacji zdarzeń.
• Niepoprawne i przekrzywione wykresy w Pryzmacie.
• Maszyny wirtualne użytkowników uruchamiane na hostach hipernadzorcy z niedokładnymi zegarami RTC (zegarami czasu rzeczywistego) powodującymi przekrzywienie czasu systemu operacyjnego gościa.
• Oprogramowanie do tworzenia kopii zapasowych innych firm, takie jak Veeam lub Commvault, ma problemy z interakcją z klastrem.
• Migawki wygasają zbyt wcześnie lub zbyt późno, gdy czas między klastrem a lokalizacją zdalną nie jest zsynchronizowany

Przeprowadzanie kontroli NCC

Przeprowadź tę kontrolę jako część pełnej kontroli stanu NCC:

Lub uruchom to sprawdzenie indywidualnie:

Możesz także uruchomić testy ze strony Zdrowia konsoli internetowej Prism: wybierz Działania > Uruchom testy. Wybierz Wszystkie kontrole i kliknij Uruchom.

Przykładowe wyjście

Dla stanu: INFORMACJE

Dla stanu: NIEPOWODZENIE

Dla stanu: BŁĄD

Od NCC-4.0.0 wzwyż dla statusu: OSTRZEŻENIE

Komunikat wyjściowy

Uwaga : Identyfikator czeku 103076 został wycofany w wersji NCC 4.0.0.

Rozwiązanie

W przypadku klastrów z systemem ESXi 7.0.3, kompilacja 19193900, sprawdzenie da wynik fałszywie dodatni, nawet jeśli serwery NTP skonfigurowane na hoście i interfejsie użytkownika Prism są takie same.

Zaktualizuj do NCC-4.5.0.1, aby złagodzić fałszywie dodatni wynik.

Ogólne kroki rozwiązywania problemów

Jeśli to sprawdzenie zwróci wynik inny niż PASS, sprawdź następujące elementy:

• W klastrze (CVM/PCVM) ORAZ na hostach (hiperwizory - AHV, ESXi, Hyper-V, XenServer) skonfigurowano co najmniej jeden, a najlepiej trzy lub więcej niezawodnych serwerów NTP poza klastrem.
  • Aby skonfigurować serwery NTP w CVM i AHV, patrz Konfigurowanie serwerów NTP w Przewodniku po konsoli internetowej Prism . (Konfiguracja serwerów NTP przez Prism zaktualizuje zarówno CVM, jak i hosty AHV).
  • Aby skonfigurować serwery NTP na hostach ESXi, zobacz Konfigurowanie protokołu czasu sieciowego (NTP) na hostach ESX/ESXi przy użyciu klienta vSphere (2012069) .
  • Aby skonfigurować serwery NTP na hostach Hyper-V, zobacz Konfigurowanie NTP na Hyper-V poniżej.
  • Aby uzyskać zalecenia dotyczące używanych serwerów NTP, zobacz Zalecenia dotyczące synchronizacji czasu .
• Lista serwerów NTP skonfigurowanych na hiperwizorach powinna być taka sama jak lista skonfigurowana na CVM.
• Jeśli serwer NTP jest ustawiony przy użyciu nazwy FQDN lub nazwy hosta, upewnij się, że klaster może rozpoznać adres IP dla nazwy FQDN NTP względem wszystkich skonfigurowanych serwerów nazw DNS. Nieprawidłowa konfiguracja serwera nazw w Prism może uniemożliwić korzystanie z serwerów NTP i doprowadzić do problemów z synchronizacją czasu.
• Port docelowy protokołu NTP (UDP 123) jest otwarty dla docelowych serwerów NTP przez dowolne listy ACL/zapory ogniowe w ścieżce sieciowej między wszystkimi CVM/hostami a serwerami NTP.
• Spróbuj wysłać polecenie ping do serwerów NTP, używając nazwy FQDN i adresów IP, aby ustanowić podstawowe połączenie sieciowe. Należy pamiętać, że niektóre listy ACL/zapory ogniowe mogą celowo blokować ruch ping (echo ICMP), ale nadal zezwalają na UDP/123, dlatego należy wziąć pod uwagę, że nieosiągalny wynik niekoniecznie musi być główną przyczyną, ale możliwym wglądem w problemy z łącznością sieciową. Użyj następnego kroku, aby sprawdzić poprawność dalej.
• Niezależnie od osiągalności serwera NTP przez ping w sieci, upewnij się, że jest sprawny i odpowiada w warstwie aplikacji za pomocą prawidłowych i użytecznych zapytań NTP oraz że zwraca dokładne informacje o czasie. Możesz sprawdzić, czy zapytania NTP zwracają informacje o czasie, uruchamiając następujące polecenie:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Sprawdź stan synchronizacji NTP na wszystkich CVM i hostach, korzystając z poniższej procedury Przeglądanie danych wyjściowych polecenia „ntpq -pn” .
• Sprawdź konfigurację NTP na wszystkich hostach, korzystając z poniższej procedury Przeglądanie zawartości pliku ntp.conf .
• To sprawdzenie może dać wynik NIEPONUJĄCY po skonfigurowaniu NTP, jeśli czas nie został jeszcze zsynchronizowany z nową/zaktualizowaną konfiguracją NTP. Jeśli serwer NTP został niedawno dodany, a czas CVM nie jest uważany za czas przyszły (ujemne przesunięcie względem serwera NTP), ta kontrola może zostać uruchomiona, dopóki protokół NTP nie znajdzie stabilnego i odpowiedniego źródła NTP, a CVM nie pomyślnie zsynchronizowano (~10 minut).
• Jeśli skonfigurowane serwery NTP same w sobie nie są niezawodnymi źródłami warstwy 0 (GPS/zegar atomowy), muszą mieć skonfigurowane zewnętrzne źródło czasu odpowiedniej warstwy (0-3 jest dobre) i nie powinny być synchronizowane z lokalnym zegarem tego serwera lub wewnętrznego źródła czasu.

Uwagi:

• Wiadomo, że synchronizacja klastra Nutanix AOS/PC ze źródłem czasu opartym na Windows powoduje problemy przez pewien czas. Patrz KB 3851 Troubleshooting NTP Sync to Windows Time Servers .
  Nutanix zaleca, aby nie synchronizować czasu klastra ze źródłami czasu Windows . Zamiast tego używaj wiarygodnych źródeł czasu innych niż Windows . Zobacz Zalecenia dotyczące synchronizacji czasu w Przewodniku po Prism Web Console .
• Nie używaj serwera NTP jako źródła dla klastra Nutanix i/lub hiperwizora, jeśli rzeczywisty serwer NTP jest maszyną wirtualną użytkownika działającą jako gość w tym samym klastrze! Jest to niewiarygodne, nieprzewidywalne w przypadku przestojów i ponownych uruchomień maszyn wirtualnych użytkowników i klastrów i niezalecane.
• Nie musisz ręcznie konfigurować serwerów NTP na hostach AHV. Skonfigurowanie serwerów NTP za pośrednictwem Prism/ncli zaktualizuje zarówno CVM, jak i hosty AHV.
• W przypadku używania konsoli internetowej Prism lub ncli do dodawania serwerów NTP w klastrze AOS opartym na ESXi, serwery NTP nie są automatycznie dodawane do pliku /etc/ntp.conf hosta. Po dodaniu serwerów NTP w Prism musisz również ręcznie skonfigurować te serwery NTP na hostach ESXi. Aby uzyskać więcej informacji na temat konfigurowania serwerów NTP na hostach ESXi, zobacz Konfigurowanie protokołu czasu sieciowego (NTP) na hostach ESX/ESXi za pomocą klienta vSphere (2012069) .
• W klastrze z mieszanym hiperwizorem (AHV + ESXi), jak wspomniano powyżej, hosty AHV będą konfigurowane przez Prism, ale należy ręcznie skonfigurować serwery NTP na hostach ESXi klastra z mieszanym hiperwizorem.
• W klastrze Hyper-V wtyczka check_ntp weryfikuje tylko konfigurację CVM NTP. Nie sprawdza NTP ani konfiguracji czasu hostów Windows Hyper-V, więc sprawdzenie nie skutkuje statusem FAIL, jeśli hiperwizor jest źle skonfigurowany lub nie jest zsynchronizowany ze źródłami NTP i/lub AD PDC. Ręcznie potwierdź, że hosty funkcji Hyper-V i kontrolery domeny mają zdrową hierarchię czasu Windows . AD PDC powinny używać niezawodnych nadrzędnych źródeł czasu NTP równolegle do CVM, potencjalnie tych samych serwerów NTP (patrz następny punkt).
• W idealnej sytuacji, aby uprościć porównywanie dzienników i uniknąć skomplikowanego segregowania problemów z synchronizacją czasu, hiperwizory i maszyny wirtualne kontrolera powinny korzystać z tych samych serwerów NTP. Jeśli hiperwizory i maszyny wirtualne kontrolerów używają różnych serwerów NTP, ta kontrola stanu może wygenerować dane wyjściowe INFO w celu podniesienia świadomości i upewnienia się, że jest to świadoma i rozsądna konfiguracja w przeciwieństwie do przypadkowej błędnej konfiguracji oraz szybkiego podkreślenia tego faktu podczas wszelkich innych niezwiązanych problemów zdarzenie, jeśli wystąpi w dowolnym momencie podczas tworzenia klastrów.

Aby uzyskać więcej informacji i najlepszych praktyk dotyczących synchronizacji czasu klastra Nutanix, zapoznaj się z sekcją Synchronizacja czasu klastra w Przewodniku po konsoli internetowej Prism w portalu wsparcia Nutanix .

Konkretne kroki rozwiązywania problemów

• Jeśli kontrola zgłosi „INFO: serwery NTP skonfigurowane na hiperwizorze xxxx różnią się od tych skonfigurowanych w Zeus config xxxx”, skonfiguruj te same serwery NTP w klastrze, jak i hiperwizory.
• Jeśli kontrola zgłosi „FAIL: Lider NTP nie synchronizuje się z żadnym zewnętrznym serwerem NTP, ponieważ czas klastra przypada w przyszłości w stosunku do zewnętrznych serwerów NTP: xxxx”, klaster mógł zostać uruchomiony bez prawidłowego stanu synchronizacji NTP i cofnięcie czasu CVM może wpływać na operacje metadanych przechowywania w locie. Aby rozwiązać ten konkretny problem z przyszłym czasem CVM, zarejestruj sprawę w dziale pomocy technicznej Nutanix w celu uzyskania dalszej pomocy i nie zmieniaj ręcznie żadnej daty/godziny CVM.
• Jeśli kontrola zgłosi „FAIL: lider NTP nie synchronizuje się z żadnym zewnętrznym serwerem NTP”, wykonaj powyższe ogólne kroki rozwiązywania problemów . Jeśli powyższe kroki nie rozwiążą problemu, zarejestruj sprawę w dziale pomocy technicznej Nutanix , dostarczając wyniki i wszelkie dane wyjściowe z ogólnego rozwiązywania problemów i bieżącej konfiguracji klastra NTP.
• Jeśli kontrola zgłosi „FAIL: The hypervisor nie synchronizuje się z żadnym serwerem NTP”, wykonaj powyższe ogólne kroki rozwiązywania problemów . Jeśli powyższe kroki nie rozwiążą problemu, wykonaj poniższe czynności:
  1. Na hoście uruchom ponownie usługę ntpd , korzystając z procedury Restartowanie usługi ntpd opisanej poniżej.
  2. Sprawdź, czy host synchronizuje teraz czas z NTP, korzystając z procedury Przeglądanie danych wyjściowych polecenia „ntpq -pn” poniżej. Pamiętaj, aby poczekać około 10 minut na synchronizację.
  3. Jeśli nie wszystkie hosty synchronizują się prawidłowo, wykonaj poniższą procedurę Przeglądanie zawartości pliku ntp.conf .
  4. Jeśli problem nadal nie został rozwiązany, rozważ skontaktowanie się z pomocą techniczną Nutanix , dostarczenie wyników i wszelkich danych wyjściowych z ogólnego rozwiązywania problemów i bieżącej konfiguracji klastra NTP.
• Jeśli kontrola zgłosi „FAIL: Ten CVM jest liderem NTP, ale nie synchronizuje czasu z żadnym zewnętrznym serwerem NTP” i potwierdzono, że serwer NTP został ustawiony:
  1. Skonfigurowane serwery NTP mogą być przeciążone i/lub celowo ograniczać liczbę żądań klientów NTP, aby odpowiedzieć w celu ochrony przed atakami DDoS (przypadkowymi lub w inny sposób), przez co nie odpowiadają na prawidłowe żądania NTP ze strony lidera NTP CVM. Możesz sprawdzić, czy Twój serwer NTP ogranicza szybkość żądań, sprawdzając plik dziennika usługi Genesis CVM pod kątem wpisu wiersza błędu zawierającego „ odpowiedź limitu szybkości z serwera ”:
     nutanix@cvm$ allssh "grep -A 1 -i 'limit szybkości' ~/data/logs/genesis.out | ogon"
     ...
     2018-12-12 11:03:14 BŁĄD node_manager.py:3941 Aktualizacja Systime z ntpdate nie powiodła się z powodu błędu: 1: 12 Dec 11:03:14 ntpdate[26695]: nnn101 odpowiedź limitu szybkości z serwera.
     2018-12-12 11:03:14 ntpdate[26695]: nie znaleziono serwera nadającego się do synchronizacji
     1. Jeśli nie kontrolujesz serwera NTP, którego dotyczy problem, usuń go z konfiguracji NTP Prism i dodaj inny, bardziej niezawodny serwer NTP.
     2. Jeśli kontrolujesz konfigurację źródłowego serwera NTP, rozważ dodanie wyjątków ograniczeń dla adresów IP CVM/hosta. Aby uzyskać szczegółowe informacje, zapoznaj się z dokumentacją własnego serwera NTP. Na przykład w usłudze ntpd opartej na systemie Linux następujący wiersz należy dodać do pliku /etc/ntp.conf serwera NTP, a następnie ponownie załadować:
        ograniczać maska
  2. Czas CVM może wyprzedzać czas serwera NTP, a usługa Genesis CVM celowo uniemożliwi synchronizację NTP. Można to dodatkowo wykazać w dziennikach Genesis CVM, których dotyczy problem, uruchamiając następujące polecenie i szukając ujemnego przesunięcia między źródłem CVM a NTP:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | ogon"
     Przykładowe wyjście:
     2019-02-03 22:42:11 INFORMACJE node_manager.py:2314 Wysyłanie zapytań do nadrzędnych serwerów NTP: 10.xx11
     2019-02-03 22:42:12 INFORMACJE node_manager.py:2334 Przesunięcie NTP: -89,328 sekund
     2019-02-03 22:42:12 INFORMACJE node_manager.py:2354 Czas wyprzedza zewnętrzny serwer NTP o 89,328 sekund, brak synchronizacji czasu podczas działania usług klastrowych
     2019-02-03 22:42:12 INFO node_manager.py:2230 Restart serwera NTP.
     2019-02-03 23:02:13 BŁĄD node_manager.py:2450 Zewnętrzny NTP nadal nie nadaje się do użytku (0)
     2019-02-03 23:02:13 OSTRZEŻENIE node_manager.py:2456 Wyłączanie nadrzędnych serwerów NTP
     2019-02-03 23:02:13 INFO node_manager.py:2202 Zatrzymanie serwera NTP.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Restart serwera NTP.
     2019-02-03 23:12:13 INFORMACJE node_manager.py:2314 Wysyłanie zapytań do nadrzędnych serwerów NTP: 10.xx11
     2019-02-03 23:12:13 INFORMACJE node_manager.py:2334 Przesunięcie NTP: -89,297 sekund
     
     W powyższym przykładowym wyniku klaster nie synchronizuje się z nowo dodanym serwerem NTP. W tej sytuacji serwer NTP działa 89 sekund za CVM i dlatego jest uważany za niezdatny do użytku jako źródło NTP.
     Ważne: jeśli czas CVM przypada w przyszłości, NIE NALEŻY ręcznie ustawiać zegara do tyłu ! Skontaktuj się z pomocą techniczną Nutanix w celu uzyskania pomocy i przekaż powyższe dane wyjściowe.
• Jeśli kontrola zgłosi „ERR: Nie udało się uruchomić ntpq na hoście”: Uruchom następujące polecenie na każdym CVM i upewnij się, że polecenie działa pomyślnie.
  nutanix@cvm$ ntpq -pn

  Jeśli wykonanie polecenia nie powiedzie się lub kontrola NCC ponownie zgłosi stan ERR, sprawdź CVM pod kątem wolnej pamięci. Aby uzyskać dalszą pomoc, zarejestruj sprawę w dziale pomocy technicznej Nutanix .

Przeglądanie danych wyjściowych polecenia „ ntpq -pn ”.

Polecenie „ ntpq -pn ” jest głównym poleceniem używanym przez tę kontrolę do identyfikacji stanu synchronizacji NTP CVM lub hosta.

Każdy wiersz wyników będzie miał format: (Tylko przykładowe dane wyjściowe. Rzeczywiste adresy IP, wiersze serwerów NTP i powiązane wartości będą się różnić w zależności od indywidualnych konfiguracji)

Gdzie zdalny to zdalny element równorzędny lub serwer, z którym jest synchronizowany. „127.127.1.0 LOCL” to ten lokalny host (dołączany w przypadku braku dostępnych zdalnych urządzeń równorzędnych lub serwerów).

Pierwszy znak wyświetlany w tabeli to flaga stanu. Oczekiwany jest stan zsynchronizowany, reprezentowany przez „*” jako pierwszy znak jednego wpisu zdalnego serwera NTP.

Uwaga: Wystąpienie tego stanu synchronizacji zajmuje 10-15 minut, jeśli usługa genesis z rolą lidera NTP została ostatnio zmieniona lub konfiguracja serwera NTP została zmodyfikowana.

1. Aby sprawdzić stan NTP we wszystkich CVM, uruchom następujące polecenie z jednego CVM:
   nutanix@cvm$ allssh ntpq -pn
   Poniższy przykład jest dobrym wynikiem - pokazuje, że lider CVM NTP jest zsynchronizowany z zewnętrznym serwerem NTP, a pozostałe CVM są zsynchronizowane z liderem CVM NTP.
   ================== 10.xx.xx.61 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   +10.xxx.xxx.21 10.xx.xx.15 4 u 654 1024 377 0,812 -1,026 0,429
   +10.xxx.xxx.22 10.xx.xx.15 4 u 997 1024 377 0,830 -0,998 0,533
   +10.xxx.xxx.10 10.xx.xx.15 4 u 409 1024 377 1.365 -1.159 5.158
   *10.xxx.xxx.11 10.xx.xx.15 4 u 579 1024 377 1,626 -1,055 0,326 <--- Zsynchronizowane ze skonfigurowanym serwerem NTP 10.xx.xx.11
   127.127.1.0 .LOCL. 10 l 27h 64 0 0,000 0,000 0,000
   ================== 10.xx.xx.62 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Zsynchronizowane z liderem CVM NTP 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Zsynchronizowane z liderem CVM NTP 10.xx.xx.61
   
   Poniżej znajduje się przykład problematycznego wyniku. Lider CVM NTP jest synchronizowany tylko z zegarem lokalnym:
   ================== 10.xx.xx.61 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0,000 0,000 0,000 <--- Lider CVM NTP zsynchronizowany tylko z zegarem lokalnym
   ================== 10.xx.xx.62 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Zsynchronizowane z liderem CVM NTP 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Zsynchronizowane z liderem CVM NTP 10.xx.xx.61
   
   Jeśli używany jest adres IP „127.127.1.0”, oznacza to, że CVM synchronizują się tylko z liderem NTP („127.127.1.0” to adres IP lokalnego hosta) i NIE synchronizują się z żadnym zewnętrznym serwerem NTP w momencie sprawdzania wykonane.
2. Aby sprawdzić stan NTP na wszystkich hostach/hiperwizorach, uruchom następujące polecenie z jednego CVM:
   nutanix@cvm$ hostssh ntpq -pn
   
   Poniższy przykład to dobry wynik. Wszystkie hosty synchronizują się z tymi samymi serwerami NTP.
   ============= 192.xx.xx.1 ============
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.15 218.1xx.xx.70 2 u 822 1024 377 96,679 12,968 3,105
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 27 1024 377 0,609 -23,479 4,167
   ============= 192.xx.xx2 ============
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 8 1024 157 2,513 3,510 2,980
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 253 1024 377 0,665 -8,794 5,203
   ============= 192.xx.xx.3 ============
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 184 1024 377 96.566 17.003 4.010
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 394 1024 377 0.659 -18.181 5.601
   Jeśli adresy IP NTP nie są konsekwentnie takie same na wszystkich hostach, sprawdź plik /etc/ntp.conf , czy używają one nazwy hosta/FQDN reprezentującej pulę serwerów NTP. Pule NTP składają się z bardzo wielu okrągłych wpisów DNS, więc w czasie inicjalizacji odpowiedź DNS przekazywana każdemu hostowi podczas uruchamiania usługi NTP może zwrócić inny adres IP do wykorzystania jako serwer NTP.
3. Jeśli zobaczysz następujący komunikat na hoście AHV podczas uruchamiania ntpq :
   Nie zwrócono żadnego identyfikatora powiązania
   
   Potwierdź, czy używasz jądra AHV el6, uruchamiając następujące polecenia:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   Jeśli pracujesz na jądrze el6, zobaczysz wynik podobny do poniższego:
   el6.nutanix.20170830.151
   Aby tymczasowo rozwiązać ten problem (obejście), uruchom ponownie usługę ntpd na hoście, korzystając z poniższej procedury Ponowne uruchamianie usługi ntpd , a następnie ponownie uruchom tę kontrolę NCC, aby potwierdzić.

   Aby trwale rozwiązać ten problem, zaktualizuj AOS do wersji 5.5.8, 5.9.2, 5.10 lub nowszej.

4. Jeśli zobaczysz następujący komunikat na hoście ESXi podczas uruchamiania ntpq , oznacza to, że host ESXi/ESX nie może połączyć się ze skonfigurowanym serwerem NTP:
   Nie zwrócono żadnego identyfikatora powiązania
   Potwierdź, że czas na wszystkich hostach jest poprawny i taki sam za pomocą polecenia hostssh date .

   Potwierdź, że adresy IP serwera NTP są skonfigurowane na hoście za pomocą pliku /etc/ntp.conf.

   Potwierdź, czy konfiguracja serwera DNS na hostach jest poprawna za pomocą poniższego polecenia:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli network ip dns server list >>> Aby sprawdzić na pojedynczym hoście
   nutanix@cvm$ hostssh „esxcli network ip dns server list” >>> Aby sprawdzić wszystkie hosty
   
   Aby rozwiązać ten problem, popraw konfigurację serwera DNS za pomocą następującego polecenia. Ewentualnie dodaj poprawną konfigurację DNS w Centrum:
   [root@Esxi:~]esxcli ip sieci esxcli serwer dns dodaj --server=
5. Jeśli zobaczysz następujący komunikat na hoście AHV podczas uruchamiania ntpq :
   Nazwa lub usługa nieznana
   Przyczyną tego problemu może być to, że polecenie ntpq nie może przekształcić adresu „localhost” w adres 127.0.0.1.

   Aby rozwiązać ten problem, zarejestruj sprawę w dziale pomocy technicznej Nutanix , dostarczając wyniki i wszelkie dane wyjściowe z ogólnego rozwiązywania problemów i bieżącej konfiguracji hosta NTP.

6. Po uruchomieniu ntpq -pn na PCVM możesz zobaczyć następujące dane wyjściowe:
   nutanix@PCVM:~$ ntpq -pn
   zdalna refid st t, gdy odpytywanie osiągnie jitter opóźnienia przesunięcia
   ================================================== ============================
   x10.48.147.26 .GNSS. 1 u 30 64 377 0,910 -4549,1 22,565
   x10.65.140.26 .GNSS. 1 u 58 64 377 0,251 -4527,7 15,504
   *127.127.1.0 .LOCL. 10 litrów 29 64 277 0,000 0,000 0,000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   Więcej informacji na temat polecenia ntpq można znaleźć na stronie podręcznika ntpq .

Przeglądanie zawartości pliku ntp.conf

1. Przejrzyj dane wyjściowe polecenia ntpq -pn , korzystając z powyższej procedury .
2. Jeśli nie wszystkie hosty AHV lub ESXi synchronizują czas z NTP, sprawdź pliki /etc/ntp.conf wszystkich hostów.

   Poniżej znajduje się przykładowy wynik, w którym tylko 2 z 3 hostów pomyślnie synchronizują się z NTP.

   nutanix@cvm$ hostssh kot /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   ogranicz domyślny kod nomodify notrap nopeer noquery
   ogranicz 127.0.0.1
   serwer 10.xx.xx.8
   plik dryfu /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   ogranicz domyślny kod nomodify notrap nopeer noquery
   ogranicz 127.0.0.1
   serwer 10.xx.xx.8
   plik dryfu /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   panika 0
   serwer 10.xx.xx.8
   plik dryfu /var/lib/ntp/drift
   plik dziennika /var/log/ntp.log
   ogranicz maskę 10.8.xx 255.255.255.0 nomodify notrap
   interfejs ignoruje symbole wieloznaczne
   interfejs nasłuchuje br0
   ogranicz 127.0.0.1
   ogranicz -6 ::1
   ogranicz domyślny kod nomodify notrap nopeer noquery
   ogranicz -6 domyślny kod nomodify notrap nopeer noquery
   wyłącz monitor
   W powyższej przykładowej konfiguracji hosty 10.xx.xx.1 i 10.1xx.xx.2 pomyślnie synchronizują się z NTP, podczas gdy 10.xx.xx.3 nie działa, ponieważ ogranicza synchronizację NTP
3. Aby rozwiązać ten problem, wykonaj powyższe ogólne kroki rozwiązywania problemów . Należy pamiętać, że hosty AHV są również konfigurowane wraz z CVM przez Prism.
4. W przypadku przejściowego problemu z nadrzędnym NTP lub łącznością uruchom ponownie usługę ntpd, wykonując poniższą procedurę.
5. Odczekaj 5-10 minut i uruchom następujące polecenie z jednego z CVM, aby sprawdzić, czy wszystkie hiperwizory synchronizują się teraz z serwerem NTP:
   nutanix@cvm$ hostssh ntpq -pn
6. Ponownie uruchom sprawdzanie NCC.
7. Jeśli powyższe kroki nie rozwiążą problemu, zarejestruj sprawę w dziale pomocy technicznej Nutanix , dostarczając wyniki i wszelkie dane wyjściowe z ogólnego rozwiązywania problemów i bieżącej konfiguracji klastra NTP.

   Uwaga: w przypadku ESXi powyższy problem był znany z tego, że w pliku /etc/ntp.conf wymieniony był komunikat „ interfejs Listen br0 ”. Linię należy usunąć i zrestartować usługę ntpd.

Ponowne uruchomienie usługi ntpd/w32time

Na AHV el6 lub ESXi uruchom:

Na biegu AHV el7:

Aby sprawdzić, czy zainstalowana wersja AHV należy do rodziny el6 czy el7, użyj polecenia:

 [root@AHV]# unazwa -r
4.19.84-2.el7.nutanix.20190916.410.x86_64

W Hyper-V uruchom:

Konfigurowanie NTP na Hyper-V

Hosty Hyper-V 2016 używają kontrolera domeny jako NTP. Aby skonfigurować zewnętrzne źródła NTP na kontrolerach domeny Active Directory:

1. Otwórz wiersz polecenia na kontrolerze domeny z uprawnieniami administracyjnymi.
2. Zatrzymaj usługę czasu:
   C:\> net stop w32time
3. Ustaw ręczne serwery zewnętrzne z listą równorzędnych:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. Ustaw połączenie jako niezawodne:
   C:\> w32tm /config /reliable:yes
5. Uruchom kopię zapasową usługi czasu:
   C:\> net start w32time
6. Przetestuj konfigurację:
   C:\> w32tm /query /configuration i w32tm /query /status

Dodatkowe informacje

• Nutanix KB 4519 - Oryginalny dokument w portalu Nutanix