Beschrijving

De Nutanix NCC health check plugin check_ntp verifieert de NTP-configuratie van de CVM's (Controller VM's) en hypervisorhosts. Het controleert ook of er tijdafwijkingen zijn op het cluster.

De plug -in check_ntp bevat meerdere individuele controles die zich richten op specifieke NTP-gerelateerde scenario's:

• CVM/PCVM NTP-tijdsynchronisatie - bepaalt of de CVM/PCVM tijd kan synchroniseren met een van de geconfigureerde NTP-servers
• Hypervisor NTP-tijdsynchronisatie (alleen AHV + ESXi) - bepaalt of de host de tijd kan synchroniseren met een van de geconfigureerde NTP-servers

Opmerking: NTP-configuratiecontrole, controle-ID 103076 is buiten gebruik gesteld in NCC versie 4.0.0.

Deze plugin draait ook op Prism Central (PC), behalve de hypervisor check.

Deze health check-plug-in is geïntroduceerd in NCC versie 3.1 en convergeert alle NTP-controles van eerdere NCC-versies. Op Prism Central is deze controle geïntroduceerd in NCC versie 3.5.3. De signaleringsfunctie van deze controles is geïntroduceerd in NCC 3.6.2.

Mogelijke oorzaken

Als deze statuscontrole een niet-GESLAAGD resultaat retourneert, zijn de volgende mogelijke oorzaken:

• Er zijn geen NTP-servers geconfigureerd op het cluster.
• Er zijn geen NTP-servers geconfigureerd op de hypervisor.
• Alle of sommige NTP-servers die op de hypervisor zijn geconfigureerd, zijn niet dezelfde als de servers die op de CVM's of pc-VM's zijn geconfigureerd.
• Een geconfigureerde NTP-server is niet bereikbaar of reageert niet op NTP-query's.
• Een geconfigureerde NTP-server is niet betrouwbaar of stabiel.
• De NTP-server is geconfigureerd met een hostnaam, maar kan niet worden opgelost vanwege problemen met DNS/naamomzetting.
• NTP-poort (UDP/123) is niet open.
• De tijd op het cluster is niet synchroon en blijkt ten minste 5 seconden in de toekomst te liggen in vergelijking met de werkelijke tijd op de NTP-servers.
• De NTP-server geeft een parameter door die de NTP-client van CVM of PC VM ongeschikt acht voor NTP-synchronisatie, zoals een hoge dispersiewaarde, offset, jitter, bereik of stratum.
• Een op Windows gebaseerde NTP-server (AD PDC) die standaard zijn lokale klok als tijdbron gebruikt, zal zichzelf adverteren als een minder geschikte NTP-bron door een spreidingswaarde van 10 seconden op te nemen in de NTP-parameter van die server. W32time is niet ontworpen met de precisie die vereist is voor NTP en garandeert geen tolerantie van meer dan +/- 5 minuten.
• De genesis-service is onlangs opnieuw opgestart en NTP-synchronisatie is nog in behandeling, of als de NTP-configuratie is gewijzigd, kan het effect enige tijd duren. Volgens het NTP-protocol duurt het ongeveer 5 minuten (vijf goede samples) voordat een NTP-server wordt geaccepteerd als synchronisatiebron. Wachten en de controle na 10-15 minuten opnieuw uitvoeren kan een ander resultaat opleveren als dit voldoende tijd heeft gegeven om de wijziging door te voeren en te synchroniseren.

  Na het herstarten van genesis laat de opdracht ntpq bijvoorbeeld zien dat de tijd nog steeds wordt gesynchroniseerd met .LOCL.

Vervolgens, na 10-15 minuten te hebben gewacht, toont de ntpq-opdracht nu:

Daarom zal het onmiddellijk opnieuw uitvoeren van de controle mislukken, maar het opnieuw uitvoeren na enige tijd, laten we zeggen 10-15 minuten, zou GESLAAGD moeten zijn.

Symptomen en de gevolgen

Als deze statuscontrole een niet-GESLAAGD resultaat retourneert, loopt de clusterbewerking mogelijk verschillende symptomen/effecten, zoals:

• Gebruikers kunnen zich niet aanmelden bij de Prism-webconsole met behulp van LDAP of andere directory-geïntegreerde services.
• Cluster kan niet correct starten of functioneren vanwege een grote scheefheid in de tijd na een storing of onderhoud.
• Onnauwkeurige logboekregistratie en logboekverzameling.
• Onnauwkeurige resultaten van gezondheidscontroles zijn afhankelijk van nauwkeurige tijdframes en gebeurteniscorrelatie.
• Onjuiste en scheve grafieken in Prism.
• Gebruikers-VM's die beginnen op hypervisor-hosts met onnauwkeurige RTC (real-time klokken) waardoor de tijd van het gast-OS scheef loopt.
• Back-upsoftwareproducten van derden, zoals Veeam of Commvault, hebben problemen met de interactie met het cluster.
• Snapshots die te snel of te laat verlopen wanneer de tijd tussen een cluster en een externe site niet synchroon loopt

De NCC-controle uitvoeren

Voer deze controle uit als onderdeel van de volledige NCC Health Checks:

Of voer deze controle individueel uit:

U kunt de controles ook uitvoeren vanaf de Gezondheidspagina van de Prism Web-console: selecteer Acties > Controles uitvoeren. Selecteer Alle controles en klik op Uitvoeren.

Voorbeelduitvoer

Voor status: INFO

Voor status: MISLUKT

Voor Status: ERR

Vanaf NCC-4.0.0 voor status: WARN

Uitvoerberichten

Opmerking : Controle-ID 103076 is buiten gebruik gesteld in NCC versie 4.0.0.

Oplossing

Voor clusters met ESXi 7.0.3 build 19193900 geeft de controle een fout-positief resultaat, zelfs nadat de NTP-servers die zijn geconfigureerd op de host en Prism UI hetzelfde zijn.

Upgrade naar NCC-4.5.0.1 om de fout-positieve melding te verminderen.

Algemene stappen voor probleemoplossing

Als deze controle een niet-GESLAAGD resultaat oplevert, controleer dan het volgende:

• Er zijn ten minste één, maar bij voorkeur drie of meer betrouwbare off-cluster NTP-servers geconfigureerd op het cluster (CVM's/PCVM's) EN op de hosts (hypervisors - AHV, ESXi, Hyper-V, XenServer).
  • Zie NTP-servers configureren in de Prism Web Console Guide voor het configureren van NTP-servers op de CVM's en AHV. (Door NTP-servers via Prism te configureren, worden zowel de CVM's als de AHV-hosts bijgewerkt).
  • Zie Network Time Protocol (NTP) configureren op ESX/ESXi-hosts met behulp van de vSphere Client (2012069) om NTP-servers op ESXi-hosts te configureren .
  • Zie NTP configureren op Hyper-V hieronder om NTP-servers op Hyper-V-hosts te configureren .
  • Zie Aanbevelingen voor tijdsynchronisatie voor aanbevelingen over welke NTP-servers u kunt gebruiken.
• De lijst met NTP-servers die op de hypervisors zijn geconfigureerd, moet bij voorkeur dezelfde zijn als die op de CVM's.
• Als de NTP-server is ingesteld met behulp van de FQDN of de hostnaam, moet u ervoor zorgen dat het cluster het IP-adres voor de NTP FQDN kan herleiden tot alle geconfigureerde DNS-naamservers. Een ongeldige naamserverconfiguratie in Prism kan voorkomen dat de NTP-servers worden gebruikt en kan leiden tot tijdsynchronisatieproblemen.
• NTP-protocolbestemmingspoort (UDP 123) staat open voor de doel-NTP-servers via alle ACL's/firewalls in het netwerkpad tussen alle CVM's/hosts en de NTP-servers.
• Probeer de NTP-servers te pingen met behulp van FQDN en IP-adressen om basisnetwerkconnectiviteit tot stand te brengen. Houd er rekening mee dat sommige ACL's/firewalls opzettelijk ping-verkeer (ICMP-echo) kunnen blokkeren, maar nog steeds UDP/123 toestaan. Houd er dus rekening mee dat een onbereikbaar resultaat niet noodzakelijkerwijs de hoofdoorzaak is, maar mogelijk inzicht in netwerkverbindingsproblemen. Gebruik de volgende stap om verder te valideren.
• Ongeacht de bereikbaarheid van de NTP-server door te pingen op het netwerk, zorg ervoor dat deze in orde is en reageert op de applicatielaag met geldige en bruikbare NTP-query's en dat het nauwkeurige tijdinformatie retourneert. U kunt controleren of de NTP-query's tijdinformatie retourneren door de volgende opdracht uit te voeren:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Controleer de status van NTP-synchronisatie op alle CVM's en hosts met behulp van de onderstaande procedure De uitvoer van de opdracht "ntpq -pn" bekijken .
• Controleer de NTP-configuratie op alle hosts met behulp van de onderstaande procedure De inhoud van het bestand ntp.conf bekijken .
• Deze controle kan een niet-GESLAAGD resultaat opleveren nadat NTP is geconfigureerd als de tijd nog niet is gesynchroniseerd met de nieuwe/bijgewerkte NTP-configuratie. Als de NTP-server onlangs is toegevoegd en de CVM-tijd niet als toekomstig wordt beschouwd (negatieve offset van de NTP-server), kan deze controle worden uitgevoerd totdat het NTP-protocol een stabiele en geschikte NTP-bron heeft gevonden en de CVM heeft succesvol gesynchroniseerd (~10 minuten).
• Als de geconfigureerde NTP-server(s) zelf geen betrouwbare stratum 0-bronnen (GPS/Atomic Clock) zijn, moeten ze een externe tijdbron van geschikt stratum (0-3 is goed) geconfigureerd hebben en mogen ze niet synchroniseren met de lokale klok van die server of een interne tijdbron.

Opmerkingen:

• Het is bekend dat het synchroniseren van een Nutanix AOS/PC-cluster met een op Windows gebaseerde tijdsbron na verloop van tijd problemen veroorzaakt. Raadpleeg KB 3851 Problemen oplossen met NTP-synchronisatie naar Windows -tijdservers .
  Nutanix raadt aan om de tijd van een cluster niet te synchroniseren met Windows -tijdbronnen. Gebruik in plaats daarvan betrouwbare niet- Windows -tijdbronnen. Zie Aanbevelingen voor tijdsynchronisatie in de Prism Web Console Guide .
• Gebruik geen NTP-server als bron voor een Nutanix-cluster en/of hypervisor als de eigenlijke NTP-server een gebruikers-VM is die als gast op hetzelfde cluster draait! Dit is onbetrouwbaar, onvoorspelbaar bij het uitvallen en opnieuw opstarten van gebruikers-VM's en clusters, en wordt niet aanbevolen.
• U hoeft de NTP-servers op AHV-hosts niet handmatig te configureren. Door NTP-servers via Prism/ncli te configureren, worden zowel de CVM's als de AHV-hosts bijgewerkt.
• Wanneer de Prism-webconsole of ncli wordt gebruikt om de NTP-servers toe te voegen aan een op ESXi gebaseerd AOS-cluster, worden de NTP-servers niet automatisch toegevoegd aan het bestand /etc/ntp.conf van de host. Nadat u de NTP-servers in Prism hebt toegevoegd, moet u die NTP-servers ook handmatig configureren op de ESXi-hosts. Zie Configuring Network Time Protocol (NTP) on ESX/ESXi hosts using the vSphere Client (2012069) voor meer informatie over het configureren van NTP-servers op de ESXi-hosts.
• In een mixed-hypervisor-cluster (AHV + ESXi), zoals hierboven vermeld, worden AHV-hosts geconfigureerd via Prism, maar moet u de NTP-servers handmatig configureren op de ESXi-hosts van het mixed-hypervisor-cluster.
• Op een Hyper-V-cluster valideert de plug-in check_ntp alleen de CVM NTP-configuratie. De NTP- of tijdconfiguratie van de Windows Hyper-V-hosts wordt niet gecontroleerd, dus de controle resulteert niet in een FAIL-status als de hypervisor verkeerd is geconfigureerd of niet synchroon loopt met de NTP-bronnen en/of AD PDC. Bevestig handmatig dat de Hyper-V-hosts en domeincontrollers een gezonde Windows -tijdhiërarchie hebben. De AD PDC('s) moeten betrouwbare stroomopwaartse NTP-tijdbronnen parallel aan de CVM's gebruiken, mogelijk dezelfde NTP-servers (zie volgende punt).
• Idealiter zouden de hypervisors en de controller-VM's allemaal dezelfde NTP-servers moeten gebruiken om de vergelijking van logboeken te vereenvoudigen en ingewikkelde tijdsynchronisatieproblemen te voorkomen. Als de hypervisors en de controller-VM's verschillende NTP-servers gebruiken, kan deze statuscontrole een INFO-uitvoer produceren om het bewustzijn te vergroten en ervoor te zorgen dat dit een bewuste en redelijke configuratie is in tegenstelling tot een onbedoelde verkeerde configuratie en om dit feit snel te benadrukken tijdens andere niet-gerelateerde probleemoplossing evenement mocht het zich voordoen tijdens de productie van de clusters.

Raadpleeg Cluster Time Synchronization in de Prism Web Console Guide op de Nutanix Support Portal voor meer informatie en best practices rond Nutanix-clustertijdsynchronisatie.

Specifieke stappen voor probleemoplossing

• Als de controle meldt "INFO: de NTP-servers die zijn geconfigureerd op de hypervisor xxxx verschillen van die geconfigureerd in Zeus config xxxx", configureer dan dezelfde NTP-servers op het cluster en de hypervisors.
• Als de controle meldt "FAIL: De NTP-leider synchroniseert niet met een externe NTP-server omdat de tijd van het cluster in de toekomst ligt ten opzichte van de externe NTP-servers: xxxx", is het cluster mogelijk gestart zonder een geldige NTP-synchronisatiestatus en trekken de terugwaartse CVM-tijd kan van invloed zijn op metadatabewerkingen tijdens de vlucht. Om dit specifieke probleem van toekomstige CVM-tijd op te lossen, logt u een case in bij Nutanix Support voor verdere assistentie en wijzigt u geen CVM-datum/-tijd handmatig.
• Als de controle "FAIL: NTP-leider synchroniseert niet met een externe NTP-server" meldt, volgt u de algemene stappen voor probleemoplossing hierboven. Als de bovengenoemde stappen het probleem niet oplossen, log dan een case in bij Nutanix Support , met de resultaten en eventuele output van algemene probleemoplossing en huidige cluster NTP-configuratie.
• Als de controle meldt "FAIL: De hypervisor synchroniseert niet met een NTP-server", volgt u de algemene stappen voor probleemoplossing hierboven. Als de bovengenoemde stappen het probleem niet oplossen, volg dan de onderstaande stappen:
  1. Start op de host de ntpd -service opnieuw met behulp van de onderstaande procedure De ntpd-service opnieuw starten .
  2. Controleer of de host nu de tijd synchroniseert met NTP met behulp van de onderstaande procedure De uitvoer van de opdracht "ntpq -pn" bekijken . Wacht ongeveer 10 minuten op synchronisatie.
  3. Als niet alle hosts correct synchroniseren, volgt u de onderstaande procedure De inhoud van het bestand ntp.conf bekijken .
  4. Als het probleem nog steeds niet is opgelost, overweeg dan Nutanix Support in te schakelen en de resultaten en eventuele uitvoer van algemene probleemoplossing en de huidige NTP-configuratie van het cluster te verstrekken.
• Als de controle meldt "FAIL: This CVM is the NTP leader but is not syncing time with any external NTP server" en je hebt geverifieerd dat de NTP-server is ingesteld:
  1. De geconfigureerde NTP-server(s) kunnen overweldigd zijn en/of doelbewust het aantal NTP-clientverzoeken beperken om te reageren om zichzelf te beschermen tegen DDoS (per ongeluk of anderszins), waardoor ze niet reageren op geldige NTP-verzoeken door de CVM NTP-leider. U kunt onderzoeken of uw NTP-server de verzoeken beperkt door het logboekbestand van de CVM genesis-service te inspecteren op een foutregelinvoer met " snelheidslimietantwoord van de server ":
     nutanix@cvm$ allssh "grep -A 1 -i 'snelheidslimiet' ~/data/logs/genesis.out | staart"
     ...
     2018-12-12 11:03:14 ERROR node_manager.py:3941 Systime-update met ntpdate mislukt met fout: 1: 12 Dec 11:03:14 ntpdate[26695]: nnn101 snelheidslimiet reactie van server.
     2018-12-12 11:03:14 ntpdate[26695]: geen server geschikt voor synchronisatie gevonden
     1. Als u de betrokken NTP-server niet beheert, verwijdert u deze uit de NTP-configuratie van Prism en voegt u een andere, betrouwbaardere NTP-server toe.
     2. Als u de configuratie van de bron-NTP-server beheert, kunt u overwegen beperkingsuitzonderingen toe te voegen voor de CVM/host-IP's. Zie de eigen documentatie van uw NTP-server voor details. Op een op Linux gebaseerde ntpd-service moet bijvoorbeeld de volgende regel worden toegevoegd aan het bestand /etc/ntp.conf van de NTP-server en vervolgens opnieuw worden geladen:
        beperken masker
  2. CVM-tijd kan voorlopen op NTP-servertijd, en de genesis-service van CVM zal opzettelijk NTP-synchronisatie voorkomen. Dit kan verder worden aangetoond in de Genesis-logboeken van de getroffen CVM door de volgende opdracht uit te voeren en te zoeken naar een negatieve offset tussen CVM en NTP-bron:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | staart"
     Voorbeelduitvoer:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Query upstream NTP-servers: 10.xx11
     03-02-2019 22:42:12 INFO node_manager.py:2334 NTP-offset: -89,328 seconden
     2019-02-03 22:42:12 INFO node_manager.py:2354 Tijd loopt 89,328 seconden voor op externe NTP-server, tijd wordt niet gesynchroniseerd terwijl clusterservices actief zijn
     03-02-2019 22:42:12 INFO node_manager.py:2230 De NTP-server opnieuw opstarten.
     03-02-2019 23:02:13 FOUT node_manager.py:2450 Externe NTP nog steeds onbruikbaar (0)
     2019-02-03 23:02:13 WAARSCHUWING node_manager.py:2456 Upstream NTP-servers uitschakelen
     03-02-2019 23:02:13 INFO node_manager.py:2202 De NTP-server stoppen.
     03-02-2019 23:02:13 INFO node_manager.py:2230 De NTP-server opnieuw opstarten.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Query upstream NTP-servers: 10.xx11
     03-02-2019 23:12:13 INFO node_manager.py:2334 NTP-offset: -89,297 seconden
     
     In de voorbeelduitvoer hierboven wordt het cluster niet gesynchroniseerd met een nieuw toegevoegde NTP-server. In deze situatie loopt de NTP-server 89 seconden achter op de CVM en wordt daarom als onbruikbaar beschouwd als NTP-bron.
     Belangrijk: Als de CVM-tijd in de toekomst ligt, zet de klok dan NIET handmatig achteruit ! Neem contact op met Nutanix Support voor hulp en verstrek de bovenstaande uitvoer.
• Als de controle "ERR: Failed to run ntpq on the host" meldt: Voer de volgende opdracht uit op elke CVM en controleer of de opdracht goed wordt uitgevoerd.
  nutanix@cvm$ ntpq -pn

  Als de opdracht niet kan worden uitgevoerd of als de NCC-controle opnieuw een ERR-status meldt, onderzoekt u de CVM's op vrij geheugen. Meld een zaak aan bij Nutanix Support voor verdere hulp.

De uitvoer van de opdracht " ntpq -pn " bekijken

Het commando ' ntpq -pn ' is het hoofdcommando dat door deze controle wordt gebruikt om de NTP-synchronisatiestatus van de CVM of de host te identificeren.

Elke regel met resultaten heeft de indeling: (Alleen voorbeelduitvoer. Werkelijke IP's, rijen NTP-servers en gerelateerde waarden verschillen op basis van individuele configuraties)

Waar op afstand de externe peer of server wordt gesynchroniseerd. "127.127.1.0 LOCL" is deze lokale host (inbegrepen voor het geval er geen externe peers of servers beschikbaar zijn).

Het eerste teken dat in de tabel wordt weergegeven, is een staatsvlag. Er wordt een gesynchroniseerde status verwacht, weergegeven door de '*' als het eerste teken van een externe NTP-serververmelding.

Opmerking: het duurt 10-15 minuten voordat deze gesynchroniseerde status optreedt als de genesis-service met de rol van NTP-leider onlangs is gewijzigd of als de configuratie van de NTP-server is gewijzigd.

1. Voer de volgende opdracht uit vanaf één CVM om de NTP-status op alle CVM's te controleren:
   nutanix@cvm$ allssh ntpq -pn
   Het volgende voorbeeld is een goed resultaat: de CVM NTP-leider wordt gesynchroniseerd met een externe NTP-server en de andere CVM's worden gesynchroniseerd met de CVM NTP-leider.
   ================== 10.xx.xx.61 =================
   remote refid st t when 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 <--- Gesynchroniseerd met een geconfigureerde NTP-server 10.xx.xx.11
   127.127.1.0 .LOCL. 10 liter 27 uur 64 0 0,000 0,000 0,000
   ================== 10.xx.xx.62 =================
   remote refid st t when poll reach delay offset jitter
   =============================================== ===========================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Gesynchroniseerd met de CVM NTP-leider 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   remote refid st t when poll reach delay offset jitter
   =============================================== ===========================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Gesynchroniseerd met de CVM NTP-leider 10.xx.xx.61
   
   Hieronder ziet u een voorbeeld van een problematisch resultaat. De CVM NTP-leider is alleen gesynchroniseerd met zijn lokale klok:
   ================== 10.xx.xx.61 =================
   remote refid st t when poll reach delay offset jitter
   =============================================== ===========================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0.000 0.000 0.000 <--- CVM NTP leider alleen gesynchroniseerd met zijn lokale klok
   ================== 10.xx.xx.62 =================
   remote refid st t when poll reach delay offset jitter
   =============================================== ===========================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Gesynchroniseerd met de CVM NTP-leider 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   remote refid st t when poll reach delay offset jitter
   =============================================== ===========================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Gesynchroniseerd met de CVM NTP-leider 10.xx.xx.61
   
   Als IP '127.127.1.0' wordt gebruikt, betekent dit dat de CVM's alleen synchroniseren met de NTP-leider ('127.127.1.0' is een localhost-IP) en NIET wordt gesynchroniseerd met een externe NTP-server op het moment dat de controle werd uitgevoerd. uitgevoerd.
2. Voer de volgende opdracht uit vanaf één CVM om de NTP-status op alle hosts/hypervisors te controleren:
   nutanix@cvm$ hostssh ntpq -pn
   
   Het volgende voorbeeld is een goed resultaat. Alle hosts synchroniseren met dezelfde NTP-servers.
   ============= 192.xx.xx.1 ============
   remote refid st t when 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 when 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 when 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
   Als de NTP IP-adressen niet consistent hetzelfde zijn op alle hosts, controleer dan /etc/ntp.conf of ze een hostnaam/FQDN gebruiken die een pool van NTP-servers vertegenwoordigt. NTP-pools zijn samengesteld uit zeer veel round-robin DNS-vermeldingen, dus tijdens de initialisatie kan het DNS-antwoord dat aan elke host wordt gegeven wanneer ze de NTP-service starten, een ander IP-adres retourneren voor gebruik als een NTP-server.
3. Als u het volgende bericht ziet op een AHV-host wanneer u ntpq uitvoert :
   Er zijn geen associatie-ID's geretourneerd
   
   Controleer of u een AHV el6-kernel gebruikt door de volgende opdrachten uit te voeren:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]#cat /etc/nutanix-release
   
   Als u op een el6-kernel draait, ziet u een soortgelijke uitvoer als hieronder:
   el6.nutanix.20170830.151
   Om dit probleem tijdelijk op te lossen (tijdelijke oplossing), start u op de host de ntpd -service opnieuw met behulp van de onderstaande procedure De ntpd-service opnieuw starten en voert u deze NCC-controle opnieuw uit om te bevestigen.

   Upgrade AOS naar 5.5.8, 5.9.2, 5.10 of hoger om dit probleem permanent op te lossen.

4. Als u het volgende bericht ziet op een ESXi-host wanneer u ntpq uitvoert , betekent dit dat de ESXi/ESX-host de geconfigureerde NTP-server niet kan bereiken:
   Er zijn geen associatie-ID's geretourneerd
   Bevestig dat de tijd op alle hosts correct is en hetzelfde is met de opdracht hostssh date .

   Bevestig dat de NTP-server-IP's op de host zijn geconfigureerd met /etc/ntp.conf.

   Bevestig of de DNS-serverconfiguratie op de hosts correct is met de onderstaande opdracht:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli netwerk ip dns serverlijst >>> Controleren op enkele host
   nutanix@cvm$ hostssh "esxcli netwerk ip dns serverlijst" >>> Om alle host te controleren
   
   Om dit op te lossen, corrigeert u de DNS-serverconfiguratie met de volgende opdracht. U kunt ook de juiste DNS-configuratie toevoegen in Center:
   [root@Esxi:~]esxcli netwerk ip dns server toevoegen --server=
5. Als u het volgende bericht ziet op een AHV-host wanneer u ntpq uitvoert :
   Naam of dienst niet bekend
   Dit probleem kan worden veroorzaakt doordat de opdracht ntpq "localhost" niet kan omzetten in 127.0.0.1.

   Om dit probleem op te lossen, logt u een case in bij Nutanix Support met de resultaten en eventuele uitvoer van algemene probleemoplossing en de huidige NTP-configuratie van de host.

6. Mogelijk ziet u het volgende soort uitvoer wanneer u ntpq -pn uitvoert op PCVM:
   nutanix@PCVM:~$ ntpq -pn
   remote refid st t when 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 liter 29 64 277 0,000 0,000 0,000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   Zie de ntpq man-pagina voor meer informatie over het ntpq- commando.

De inhoud van het bestand ntp.conf bekijken

1. Bekijk de uitvoer van de opdracht ntpq -pn met behulp van de bovenstaande procedure .
2. Als niet alle AHV- of ESXi-hosts tijd synchroniseren met NTP, controleer dan de /etc/ntp.conf-bestanden van alle hosts.

   Hieronder staat een voorbeelduitvoer waarbij slechts 2 van de 3 hosts met succes synchroniseren met NTP.

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   beperken standaard kod nomodify notrap nopeer noquery
   beperken 127.0.0.1
   server 10.xx.xx.8
   driftbestand /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   beperken standaard kod nomodify notrap nopeer noquery
   beperken 127.0.0.1
   server 10.xx.xx.8
   driftbestand /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   knutselpaniek 0
   server 10.xx.xx.8
   driftbestand /var/lib/ntp/drift
   logbestand /var/log/ntp.log
   beperken 10.8.xx masker 255.255.255.0 nomodify notrap
   interface negeren jokerteken
   interface luisteren br0
   beperken 127.0.0.1
   beperk -6 ::1
   beperken standaard kod nomodify notrap nopeer noquery
   restrict -6 standaard kod nomodify notrap nopeer noquery
   monitor uitschakelen
   In de bovenstaande voorbeeldconfiguratie synchroniseren hosts 10.xx.xx.1 en 10.1xx.xx.2 met succes met NTP terwijl 10.xx.xx.3 faalt omdat het NTP-synchronisatie beperkt
3. Volg de bovenstaande algemene stappen voor probleemoplossing om dit op te lossen. Merk op dat AHV-hosts ook samen met CVM's worden geconfigureerd via Prism.
4. In het geval van een tijdelijk stroomopwaarts NTP- of verbindingsprobleem, start u de ntpd-service opnieuw op met behulp van de onderstaande procedure.
5. Wacht 5-10 minuten en voer de volgende opdracht uit vanaf een van de CVM's om te controleren of alle hypervisors nu synchroniseren met de NTP-server:
   nutanix@cvm$ hostssh ntpq -pn
6. Voer de NCC-controle opnieuw uit.
7. Als de bovengenoemde stappen het probleem niet oplossen, log dan een case in bij Nutanix Support , met de resultaten en eventuele output van algemene probleemoplossing en de huidige NTP-configuratie van het cluster.

   Opmerking: Op ESXi is bekend dat " interface listen br0 " die wordt vermeld in /etc/ntp.conf het bovenstaande probleem veroorzaakt. De regel moet worden verwijderd en de ntpd-service moet opnieuw worden gestart.

De ntpd/w32time-service opnieuw opstarten

Voer op AHV el6 of ESXi het volgende uit:

Op AHV el7-run:

Gebruik de opdracht om te controleren of de geïnstalleerde AHV-versie tot de el6- of el7-familie behoort:

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

Voer op Hyper-V het volgende uit:

NTP configureren op Hyper-V

Hyper-V 2016-hosts gebruiken de domeincontroller als NTP. Externe NTP-bronnen configureren op de Active Directory Domain Controller(s):

1. Open een opdrachtprompt op de DC met beheerdersmachtigingen.
2. Stop de tijdservice:
   C:\> net stop w32time
3. Stel de handmatige peerlijst externe servers in:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. Stel de verbinding in als betrouwbaar:
   C:\> w32tm /config /betrouwbaar:ja
5. Start de tijdservice weer op:
   C:\> net start w32time
6. Test de configuratie:
   C:\> w32tm /query /configuratie en w32tm /query /status

Extra informatie

• Nutanix KB 4519 - Origineel document in Nutanix Portal