Popis

Plugin pro kontrolu stavu Nutanix NCC check_ntp ověřuje konfiguraci NTP CVM (Controller VMs) a hostitelů hypervisoru. Také kontroluje, zda na clusteru nejsou nějaké časové posuny.

Plugin check_ntp obsahuje několik jednotlivých kontrol, které se zaměřují na konkrétní scénáře související s NTP:

• CVM/PCVM NTP synchronizace času – určuje, zda je CVM/PCVM schopen synchronizovat čas s některým z nakonfigurovaných NTP serverů
• Synchronizace času Hypervisor NTP (pouze AHV + ESXi) – určuje, zda je hostitel schopen synchronizovat čas s některým z nakonfigurovaných serverů NTP

Poznámka: Kontrola konfigurace NTP, kontrolní ID 103076 je v NCC verze 4.0.0 vyřazeno.

Tento plugin běží také na Prism Central (PC), s výjimkou kontroly hypervisoru.

Tento plugin pro kontrolu stavu byl představen ve verzi NCC 3.1 a konverguje všechny kontroly NTP z předchozích verzí NCC. Na Prism Central byla tato kontrola zavedena ve verzi NCC 3.5.3. Výstražná funkce těchto kontrol byla zavedena v NCC 3.6.2.

Možné příčiny

Pokud tato kontrola stavu vrátí výsledek, který neprošel, jsou možné následující příčiny:

• V clusteru nejsou nakonfigurovány žádné servery NTP.
• Na hypervizoru nejsou nakonfigurovány žádné servery NTP.
• Všechny nebo některé servery NTP nakonfigurované na hypervizoru nejsou stejné jako servery nakonfigurované na CVM nebo PC VM.
• Nakonfigurovaný server NTP není dosažitelný nebo neodpovídá na dotazy NTP.
• Nakonfigurovaný server NTP není spolehlivý ani stabilní.
• Server NTP je nakonfigurován s názvem hostitele, ale nelze jej vyřešit kvůli problémům s překladem DNS/názvů.
• Port NTP (UDP/123) není otevřený.
• Čas v clusteru není synchronizován a bylo zjištěno, že je v budoucnosti alespoň o 5 sekund ve srovnání se skutečným časem na serverech NTP.
• NTP server předává parametr, který klient NTP CVM nebo PC VM považuje za nevhodný pro synchronizaci NTP, jako je vysoká hodnota rozptylu, offset, jitter, dosah nebo stratum.
• Server NTP se Windows (AD PDC), který ve výchozím nastavení používá jako zdroj času své místní hodiny, se bude propagovat jako méně vhodný zdroj NTP tím, že do parametru NTP daného serveru zahrne hodnotu rozptylu 10 sekund. W32time není navržen s přesností požadovanou pro NTP a nezaručuje lepší toleranci než +/- 5 minut.
• Služba genesis byla nedávno restartována a synchronizace NTP stále čeká, nebo pokud byla konfigurace NTP změněna, efekt může nějakou dobu trvat. Podle protokolu NTP trvá asi 5 minut (pět dobrých vzorků), než je server NTP přijat jako zdroj synchronizace. Čekání a opětovné spuštění kontroly po 10–15 minutách může vést k jinému výsledku, pokud to poskytne dostatek času na to, aby se změna projevila a synchronizovala.

  Například po restartování genesis příkaz ntpq ukazuje, že čas se stále synchronizuje s .LOCL.

Poté, po 10-15 minutách, příkaz ntpq nyní zobrazuje:

Proto okamžité opětovné spuštění kontroly selže, ale opětovné spuštění po nějaké době, řekněme 10-15 minut, by mělo PROJÍT.

Příznaky a dopad

Pokud tato kontrola stavu vrátí výsledek, který neprošel, operace clusteru může být ohrožena různými příznaky/dopady, jako jsou:

• Uživatelé, kteří se nemohou přihlásit k webové konzoli Prism pomocí LDAP nebo jiných adresářových integrovaných služeb.
• Cluster se nemůže spustit nebo správně fungovat kvůli velkému časovému zkreslení po výpadku nebo údržbě.
• Nepřesné protokolování a sběr protokolů.
• Nepřesné výsledky kontroly stavu spoléhají na přesné časové rámce a korelaci událostí.
• Nesprávné a zkreslené grafy v Prism.
• Uživatelské virtuální počítače začínající na hostitelích hypervisoru s nepřesnými hodinami RTC (hodiny v reálném čase), což způsobuje zkreslení času hostujícího OS.
• Zálohovací softwarové produkty třetích stran, jako je Veeam nebo Commvault, mají potíže s interakcí s clusterem.
• Snímky vyprší příliš brzy nebo příliš pozdě, když čas mezi clusterem a vzdáleným místem není synchronizován

Spuštění kontroly NCC

Spusťte tuto kontrolu jako součást kompletních kontrol stavu NCC:

Nebo spusťte tuto kontrolu jednotlivě:

Kontroly můžete také spustit ze stránky Zdraví webové konzoly Prism: vyberte Akce > Spustit kontroly. Vyberte Všechny kontroly a klikněte na Spustit.

Ukázkový výstup

Pro stav: INFO

Pro stav: FAIL

Pro stav: ERR

Od NCC-4.0.0 pro stav: WARN

Výstupní zprávy

Poznámka : Kontrolní ID 103076 je ve verzi NCC 4.0.0 vyřazeno.

Řešení

U clusterů se systémem ESXi 7.0.3 sestavení 19193900 bude kontrola falešně pozitivní, i když jsou servery NTP nakonfigurované na hostiteli a uživatelském rozhraní Prism stejné.

Upgradujte na NCC-4.5.0.1, abyste zmírnili falešně pozitivní výsledek.

Obecné kroky pro odstraňování problémů

Pokud tato kontrola vrátí výsledek neprošel, zkontrolujte následující:

• Na clusteru (CVM/PCVM) A na hostitelích (hypervizory - AHV, ESXi, Hyper-V, XenServer) je nakonfigurován alespoň jeden, nejlépe však tři nebo více spolehlivých serverů NTP mimo cluster.
  • Pro konfiguraci NTP serverů na CVM a AHV viz Konfigurace NTP serverů v Prism Web Console Guide . (Konfigurace serverů NTP přes Prism aktualizuje jak CVM, tak hostitele AHV).
  • Chcete-li nakonfigurovat servery NTP na hostitelích ESXi, přečtěte si část Konfigurace protokolu NTP (Network Time Protocol) na hostitelích ESX/ESXi pomocí klienta vSphere (2012069) .
  • Chcete-li nakonfigurovat servery NTP na hostitelích Hyper-V, viz Konfigurace NTP na Hyper-V níže.
  • Doporučení, které servery NTP použít, naleznete v části Doporučení pro synchronizaci času .
• Seznam serverů NTP nakonfigurovaných na hypervizorech by měl být pokud možno stejný jako seznam serverů nakonfigurovaných na CVM.
• Pokud je server NTP nastaven pomocí FQDN nebo názvu hostitele, ujistěte se, že cluster dokáže přeložit IP adresu pro NTP FQDN se všemi nakonfigurovanými servery DNS Name Server. Neplatná konfigurace Name Serveru v Prism může bránit použití NTP serverů a vést k problémům se synchronizací času.
• Cílový port protokolu NTP (UDP 123) je otevřen pro cílové servery NTP prostřednictvím všech ACL/firewallů v síťové cestě mezi všemi CVM/hostiteli a servery NTP.
• Vyzkoušejte ping na servery NTP pomocí FQDN a IP adres, abyste vytvořili základní síťové připojení. Uvědomte si, že některé ACL/firewally mohou záměrně blokovat provoz ping (ICMP echo), ale stále povolují UDP/123, takže mějte na paměti, že nedosažitelný výsledek nemusí být nutně hlavní příčinou, ale možným vhledem do problémů s připojením k síti. Pro další ověření použijte následující krok.
• Bez ohledu na dosažitelnost serveru NTP pomocí příkazu ping v síti se ujistěte, že je v pořádku a odpovídá na aplikační vrstvě platnými a použitelnými dotazy NTP a že vrací přesné časové informace. Spuštěním následujícího příkazu můžete ověřit, zda dotazy NTP vracejí informace o čase:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Zkontrolujte stav synchronizace NTP na všech CVM a hostitelích pomocí postupu Kontrola výstupu příkazu "ntpq -pn" níže.
• Zkontrolujte konfiguraci NTP na všech hostitelích pomocí postupu Kontrola obsahu souboru ntp.conf níže.
• Tato kontrola může po nakonfigurování NTP vést k nevyhovujícímu výsledku, pokud čas ještě nebyl synchronizován s novou/aktualizovanou konfigurací NTP. Pokud byl server NTP přidán teprve nedávno a čas CVM se nepovažuje za budoucí čas (záporný posun od serveru NTP), může se tato kontrola spustit, dokud protokol NTP nenajde stabilní a vhodný zdroj NTP a CVM nebude mít úspěšně synchronizováno (~10 minut).
• Pokud nakonfigurované servery NTP samy nejsou spolehlivými zdroji vrstvy 0 (GPS/Atomové hodiny), musí mít nakonfigurovaný externí zdroj času vhodné vrstvy (0-3 je dobrý) a neměly by se synchronizovat s místními hodinami tento server nebo interní zdroj času.

Poznámky:

• Je známo, že synchronizace clusteru Nutanix AOS/PC se zdrojem času založeným na Windows způsobuje po určitou dobu problémy. Viz KB 3851 Troubleshooting NTP Sync to Windows Time Servers .
  Nutanix doporučuje, abyste nesynchronizovali čas clusteru se zdroji času Windows . Místo toho použijte spolehlivé zdroje času mimo Windows . Viz Doporučení pro synchronizaci času v Prism Web Console Guide .
• Nepoužívejte server NTP jako zdroj pro cluster Nutanix a/nebo hypervizor, pokud je skutečným serverem NTP uživatelský virtuální počítač běžící jako host na stejném clusteru! To je nespolehlivé, nepředvídatelné při výpadcích a restartech uživatelského virtuálního počítače a clusteru a nedoporučuje se to.
• Servery NTP na hostitelích AHV nemusíte konfigurovat ručně. Konfigurace NTP serverů přes Prism/ncli aktualizuje jak CVM, tak hostitele AHV.
• Při použití webové konzoly Prism nebo ncli k přidání serverů NTP do clusteru AOS založeného na ESXi se servery NTP automaticky nepřidají do souboru /etc/ntp.conf hostitele. Po přidání serverů NTP do Prism musíte také ručně nakonfigurovat tyto servery NTP na hostitelích ESXi. Další informace o konfiguraci serverů NTP na hostitelích ESXi najdete v tématu Konfigurace Network Time Protocol (NTP) na hostitelích ESX/ESXi pomocí klienta vSphere (2012069) .
• Ve smíšeném klastru hypervizorů (AHV + ESXi), jak je uvedeno výše, budou hostitelé AHV konfigurováni pomocí Prism, ale musíte ručně nakonfigurovat servery NTP na hostitelích ESXi klastru smíšených hypervizorů.
• V clusteru Hyper-V ověřuje plugin check_ntp pouze konfiguraci CVM NTP. Nekontroluje NTP ani časovou konfiguraci hostitelů Windows Hyper-V, takže kontrola nevede ke stavu FAIL, pokud je hypervizor špatně nakonfigurován nebo není synchronizován se zdroji NTP a/nebo AD PDC. Ručně potvrďte, že hostitelé Hyper-V a řadiče domény mají zdravou časovou hierarchii Windows . AD PDC by měly používat spolehlivé upstream zdroje času NTP paralelně s CVM, potenciálně stejné servery NTP (viz další bod).
• V ideálním případě, aby se zjednodušilo porovnávání protokolů a zabránilo se složitému třídění problémů s časovou synchronizací, měly by všechny hypervizory a virtuální počítače Controller používat stejné servery NTP. Pokud hypervizory a řídicí virtuální počítače používají různé servery NTP, může tato kontrola stavu vytvořit výstup INFO, který zvýší povědomí a zajistí, že se jedná o vědomou a rozumnou konfiguraci na rozdíl od náhodné nesprávné konfigurace, a pro rychlé zdůraznění této skutečnosti během jakéhokoli jiného nesouvisejícího řešení problémů. pokud by k ní došlo kdykoliv během výroby clusterů.

Další informace a osvědčené postupy týkající se synchronizace času clusteru Nutanix naleznete v části Synchronizace času clusteru v Prism Web Console Guide na portálu podpory Nutanix .

Konkrétní kroky při odstraňování problémů

• Pokud kontrola hlásí „INFO: Servery NTP nakonfigurované na hypervisoru xxxx se liší od serverů nakonfigurovaných v konfiguraci Zeus xxxx“, nakonfigurujte stejné servery NTP v clusteru i hypervizory.
• Pokud kontrola hlásí „FAIL: Vedoucí NTP se nesynchronizuje s žádným externím serverem NTP, protože čas clusteru je v budoucnosti vzhledem k externím serverům NTP: xxxx“, cluster mohl být spuštěn bez platného stavu synchronizace NTP a stahování zpětný čas CVM může ovlivnit operace s metadaty úložiště za letu. Chcete-li vyřešit tento konkrétní problém budoucího času CVM, přihlaste případ s podporou Nutanix pro další pomoc a neměňte ručně žádné datum/čas CVM.
• Pokud kontrola hlásí „FAIL: NTP leader se nesynchronizuje s žádným externím NTP serverem“, postupujte podle obecných kroků pro řešení problémů výše. V případě, že výše uvedené kroky problém nevyřeší, přihlaste případ s podporou Nutanix a poskytněte výsledky a jakýkoli výstup z obecného odstraňování problémů a aktuální konfigurace clusteru NTP.
• Pokud kontrola hlásí „FAIL: Hypervisor se nesynchronizuje s žádným serverem NTP“, postupujte podle výše uvedených obecných kroků pro řešení problémů . V případě, že výše uvedené kroky problém nevyřeší, postupujte podle následujících kroků:
  1. Na hostiteli restartujte službu ntpd pomocí níže popsaného postupu Restartování služby ntpd .
  2. Zkontrolujte, zda hostitel nyní synchronizuje čas s NTP pomocí níže uvedeného postupu Kontrola výstupu příkazu "ntpq -pn" . Nezapomeňte na synchronizaci počkat ~10 minut.
  3. Pokud se nesynchronizují všichni hostitelé správně, postupujte podle níže uvedeného postupu Kontrola obsahu souboru ntp.conf .
  4. Pokud problém stále není vyřešen, zvažte zapojení podpory Nutanix , poskytnutí výsledků a jakéhokoli výstupu z obecného odstraňování problémů a aktuální konfigurace clusteru NTP.
• Pokud kontrola hlásí „FAIL: Tento CVM je vedoucí NTP, ale nesynchronizuje čas s žádným externím NTP serverem“ a ověřili jste, že byl NTP server nastaven:
  1. Nakonfigurovaný NTP server (servery) může být zahlcen a/nebo záměrně omezovat počet požadavků klienta NTP na odpověď, aby se ochránil před DDoS (náhodným nebo jiným), a proto nebude reagovat na platné požadavky NTP vedoucím CVM NTP. Můžete zjistit, zda váš NTP server omezuje rychlost požadavků tím, že zkontrolujete soubor protokolu služby CVM genesis, zda neobsahuje chybový řádek obsahující „ odpověď na omezení rychlosti ze serveru “:
     nutanix@cvm$ allssh "grep -A 1 -i 'limit rychlosti' ~/data/logs/genesis.out | tail"
     ...
     2018-12-12 11:03:14 ERROR node_manager.py:3941 Aktualizace systému pomocí ntpdate se nezdařila s chybou: 1: 12 Dec 11:03:14 ntpdate[26695]: nnn101 odezva na limit rychlosti ze serveru.
     2018-12-12 11:03:14 ntpdate[26695]: nenalezen žádný server vhodný pro synchronizaci
     1. Pokud neovládáte dotčený NTP server, odeberte jej z konfigurace NTP Prism a přidejte jiný, spolehlivější NTP server.
     2. Pokud ovládáte konfiguraci zdrojového serveru NTP, zvažte přidání výjimek omezení pro adresy IP CVM/hostitele. Podrobnosti naleznete v dokumentaci k vašemu NTP serveru. Například na linuxové službě ntpd by bylo nutné přidat následující řádek do souboru /etc/ntp.conf serveru NTP a poté jej znovu načíst:
        omezit maska
  2. Čas CVM může být před časem serveru NTP a služba genesis CVM záměrně zabrání synchronizaci NTP. To lze dále doložit v protokolech Genesis dotčeného CVM spuštěním následujícího příkazu a hledáním záporného offsetu mezi CVM a zdrojem NTP:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | tail"
     Příklad výstupu:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Dotazování na upstream servery NTP: 10.xx11
     2019-02-03 22:42:12 INFO node_manager.py:2334 Posun NTP: -89,328 sekund
     2019-02-03 22:42:12 INFO node_manager.py:2354 Čas je před externím NTP serverem o 89,328 sekund, čas se nesynchronizuje, když jsou spuštěny clusterové služby
     2019-02-03 22:42:12 INFO node_manager.py:2230 Restartování serveru NTP.
     2019-02-03 23:02:13 ERROR node_manager.py:2450 Externí NTP stále nepoužitelný (0)
     2019-02-03 23:02:13 VAROVÁNÍ node_manager.py:2456 Zakázání upstream serverů NTP
     2019-02-03 23:02:13 INFO node_manager.py:2202 Zastavení serveru NTP.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Restartování serveru NTP.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Dotazování na upstream servery NTP: 10.xx11
     2019-02-03 23:12:13 INFO node_manager.py:2334 NTP offset: -89,297 sekund
     
     Ve výše uvedeném příkladu výstupu se cluster nesynchronizuje s nově přidaným serverem NTP. V této situaci běží NTP server 89 sekund za CVM a je proto považován za nepoužitelný jako zdroj NTP.
     Důležité: Pokud je čas CVM v budoucnosti, NENASTAVUJTE hodiny ručně dozadu ! Požádejte o pomoc podporu společnosti Nutanix a poskytněte výše uvedený výstup.
• Pokud kontrola hlásí „ERR: Selhalo spuštění ntpq na hostiteli“: Spusťte následující příkaz na každém CVM a ujistěte se, že příkaz běží úspěšně.
  nutanix@cvm$ ntpq -pn

  Pokud se příkaz nezdaří nebo kontrola NCC znovu hlásí stav ERR, prozkoumejte moduly CVM, zda nemají volnou paměť. Přihlaste případ s podporou Nutanix pro další pomoc.

Kontrola výstupu příkazu " ntpq -pn "

Příkaz ' ntpq -pn ' je hlavní příkaz používaný touto kontrolou k identifikaci stavu synchronizace NTP CVM nebo hostitele.

Každý řádek výsledků bude ve formátu: (Pouze příklad výstupu. Skutečné adresy IP, řádky serverů NTP a související hodnoty se budou lišit v závislosti na individuální konfiguraci)

Kde remote je vzdálený peer nebo server, se kterým se synchronizuje. „127.127.1.0 LOCL“ je tento místní hostitel (zahrnut v případě, že nejsou k dispozici žádné vzdálené partnery nebo servery).

První znak zobrazený v tabulce je státní vlajka. Očekává se synchronizovaný stav reprezentovaný '*' jako prvním znakem jedné položky vzdáleného serveru NTP.

Poznámka: Trvá 10–15 minut, než se tento synchronizovaný stav objeví, pokud se služba genesis s rolí NTP leader nedávno změnila nebo byla změněna konfigurace serveru NTP.

1. Chcete-li zkontrolovat stav NTP na všech CVM, spusťte následující příkaz z jednoho CVM:
   nutanix@cvm$ allssh ntpq -pn
   Následující příklad je dobrým výsledkem – ukazuje, že vedoucí CVM NTP je synchronizován s externím serverem NTP a ostatní CVM jsou synchronizovány s vedoucím CVM NTP.
   =================== 10.xx.xx.61 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   +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 <--- Synchronizováno s nakonfigurovaným serverem 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 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Synchronizováno s vedoucím CVM NTP 10.xx.xx.61
   =================== 10.xx.xx.63 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Synchronizováno s vedoucím CVM NTP 10.xx.xx.61
   
   Níže je uveden příklad problematického výsledku. CVM NTP leader je synchronizován pouze s místními hodinami:
   =================== 10.xx.xx.61 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0,000 0,000 0,000 <--- CVM NTP leader synchronizovaný pouze s místními hodinami
   =================== 10.xx.xx.62 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Synchronizováno s vedoucím CVM NTP 10.xx.xx.61
   =================== 10.xx.xx.63 =================
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Synchronizováno s vedoucím CVM NTP 10.xx.xx.61
   
   Pokud se používá IP '127.127.1.0', znamená to, že CVM se synchronizují pouze s NTP leaderem ('127.127.1.0' je localhost IP) a NEsynchronizuje se s žádným externím NTP serverem v době kontroly. provedeno.
2. Chcete-li zkontrolovat stav NTP na všech hostitelích/hypervizorech, spusťte z jednoho CVM následující příkaz:
   nutanix@cvm$ hostssh ntpq -pn
   
   Následující příklad je dobrým výsledkem. Všichni hostitelé se synchronizují se stejnými servery NTP.
   ============== 192.xx.xx.1 ============
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *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 ============
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *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 ============
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   *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
   Pokud IP adresy NTP nejsou konzistentně stejné u všech hostitelů, zkontrolujte /etc/ntp.conf , zda nepoužívají název hostitele/FQDN, který představuje skupinu serverů NTP. Fondy NTP se skládají z velkého množství záznamů DNS typu round-robin, takže v době inicializace může odpověď DNS poskytnutá každému hostiteli při spuštění služby NTP vrátit jinou adresu IP pro použití jako server NTP.
3. Pokud se na hostiteli AHV při spuštění ntpq zobrazí následující zpráva:
   Nebyla vrácena žádná ID přidružení
   
   Potvrďte, zda používáte jádro AHV el6 spuštěním následujících příkazů:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   Pokud používáte jádro el6, uvidíte výstup podobný níže:
   el6.nutanix.20170830.151
   Chcete-li tento problém dočasně vyřešit (řešení), na hostiteli restartujte službu ntpd pomocí níže uvedeného postupu Restartování služby ntpd a poté znovu spusťte tuto kontrolu NCC pro potvrzení.

   Chcete-li tento problém trvale vyřešit, upgradujte AOS na 5.5.8, 5.9.2, 5.10 nebo novější.

4. Pokud se na hostiteli ESXi při spuštění ntpq zobrazí následující zpráva, znamená to, že hostitel ESXi/ESX nemůže dosáhnout nakonfigurovaného serveru NTP:
   Nebyla vrácena žádná ID přidružení
   Potvrďte, že čas na všech hostitelích je správný a stejný pomocí příkazu hostssh date .

   Pomocí /etc/ntp.conf ověřte, zda jsou adresy IP serveru NTP na hostiteli nakonfigurovány.

   Pomocí níže uvedeného příkazu ověřte, zda je konfigurace serveru DNS na hostitelích správná:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli síť ip dns seznam serverů >>> Kontrola na jednom hostiteli
   nutanix@cvm$ hostssh "esxcli network ip dns server list" >>> Chcete-li zkontrolovat všechny hostitele
   
   Chcete-li tento problém vyřešit, opravte konfiguraci serveru DNS pomocí následujícího příkazu. Případně přidejte správnou konfiguraci DNS v centru:
   [root@Esxi:~]esxcli síť ip dns server add --server=
5. Pokud se na hostiteli AHV při spuštění ntpq zobrazí následující zpráva:
   Jméno nebo služba nejsou známy
   Tento problém může být způsoben tím, že příkaz ntpq není schopen přeložit "localhost" na 127.0.0.1.

   Chcete-li tento problém vyřešit, přihlaste případ s podporou Nutanix , která poskytne výsledky a jakýkoli výstup z obecného řešení problémů a aktuální konfigurace hostitele NTP.

6. Při spuštění ntpq -pn na PCVM můžete vidět následující druh výstupu:
   nutanix@PCVM:~$ ntpq -pn
   remote refid st t když poll reach delay offset jitter
   ==================================================== ==============================
   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 l 29 64 277 0,000 0,000 0,000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   Další informace o příkazu ntpq naleznete na manuálové stránce ntpq .

Kontrola obsahu souboru ntp.conf

1. Zkontrolujte výstup příkazu ntpq -pn pomocí výše uvedeného postupu .
2. Pokud ne všichni hostitelé AHV nebo ESXi synchronizují čas s NTP, zkontrolujte soubory /etc/ntp.conf všech hostitelů.

   Níže je ukázkový výstup, kde se pouze 2 ze 3 hostitelů úspěšně synchronizují s NTP.

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============== 10.xx.xx.1 ============
   omezit výchozí kód nomodify notrap nopeer noquery
   omezit 127.0.0.1
   server 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============== 10.xx.xx.2 ============
   omezit výchozí kód nomodify notrap nopeer noquery
   omezit 127.0.0.1
   server 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   drátenická panika 0
   server 10.xx.xx.8
   driftfile /var/lib/ntp/drift
   logfile /var/log/ntp.log
   omezit 10.8.xx maska 255.255.255.0 nomodify notrap
   rozhraní ignorovat zástupný znak
   rozhraní poslouchat br0
   omezit 127.0.0.1
   omezit -6 ::1
   omezit výchozí kód nomodify notrap nopeer noquery
   omezit -6 výchozí kod nomodify notrap nopeer noquery
   vypnout monitor
   Ve výše uvedené ukázkové konfiguraci se hostitelé 10.xx.xx.1 a 10.1xx.xx.2 úspěšně synchronizují s NTP, zatímco 10.xx.xx.3 selhává, protože omezuje synchronizaci NTP
3. Chcete-li tento problém vyřešit, postupujte podle výše uvedených obecných kroků pro odstraňování problémů . Všimněte si, že hostitelé AHV se také konfigurují spolu s CVM přes Prism.
4. V případě přechodného upstream NTP nebo problému s připojením restartujte službu ntpd pomocí níže uvedeného postupu.
5. Počkejte 5–10 minut a spusťte následující příkaz z jednoho z CVM, abyste zkontrolovali, zda se všechny hypervizory nyní synchronizují se serverem NTP:
   nutanix@cvm$ hostssh ntpq -pn
6. Spusťte znovu kontrolu NCC.
7. Pokud výše uvedené kroky problém nevyřeší, přihlaste případ s podporou Nutanix a poskytněte výsledky a jakýkoli výstup z obecného odstraňování problémů a aktuální konfigurace clusteru NTP.

   Poznámka: Na ESXi je známo, že výše uvedený problém způsobuje " interface listen br0 " uvedený v /etc/ntp.conf . Řádek by měl být odstraněn a služba ntpd restartována.

Restartování služby ntpd/w32time

Na AHV el6 nebo ESXi spusťte:

Při běhu AHV el7:

Chcete-li zkontrolovat, zda nainstalovaná verze AHV patří do rodiny el6 nebo el7, použijte příkaz:

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

Na Hyper-V spusťte:

Konfigurace NTP na Hyper-V

Hostitelé Hyper-V 2016 používají řadič domény jako NTP. Chcete-li nakonfigurovat externí zdroje NTP na řadiči domény Active Directory:

1. Otevřete příkazový řádek na DC s oprávněními správce.
2. Zastavte službu času:
   C:\> net stop w32time
3. Nastavte ruční seznam partnerských externích serverů:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” “
4. Nastavte připojení jako spolehlivé:
   C:\> w32tm /config /reliable:yes
5. Spusťte zálohování časové služby:
   C:\> net start w32time
6. Otestujte konfiguraci:
   C:\> w32tm /query /konfigurace a w32tm /query /stav

dodatečné informace

• Nutanix KB 4519 - Původní dokument na portálu Nutanix