Leírás

A Nutanix NCC állapotellenőrző beépülő modul check_ntp ellenőrzi a CVM-ek (vezérlő virtuális gépek) és a hypervisor gazdagépek NTP-konfigurációját. Azt is ellenőrzi, hogy vannak-e időeltolódások a fürtön.

A check_ntp beépülő modul több egyedi ellenőrzést tartalmaz, amelyek konkrét NTP-vel kapcsolatos forgatókönyvekre összpontosítanak:

• CVM/PCVM NTP-idő szinkronizálás – meghatározza, hogy a CVM/PCVM képes-e szinkronizálni az időt bármelyik konfigurált NTP-kiszolgálóval
• Hypervisor NTP-idő szinkronizálás (csak AHV + ESXi) – meghatározza, hogy a gazdagép képes-e szinkronizálni az időt bármelyik konfigurált NTP-kiszolgálóval

Megjegyzés: Az NTP-konfiguráció ellenőrzése, az 103076-os ellenőrzési azonosító megszűnt az NCC 4.0.0-s verziójában.

Ez a beépülő modul Prism Centralon (PC) is fut, kivéve a hypervisor ellenőrzést.

Ezt az állapotellenőrző bővítményt az NCC 3.1-es verziójában vezették be, és a korábbi NCC-verziók összes NTP-ellenőrzését konvergálja. A Prism Centralon ezt az ellenőrzést az NCC 3.5.3-as verziójában vezették be. Ezen ellenőrzések riasztási funkciója az NCC 3.6.2-ben került bevezetésre.

Lehetséges okok

Ha ez az állapotellenőrzés nem PASS eredményt ad vissza, a következők lehetségesek:

• Nincsenek konfigurálva NTP-kiszolgálók a fürtben.
• Nincsenek NTP-kiszolgálók konfigurálva a hypervisoron.
• A hypervisoron konfigurált NTP-kiszolgálók mindegyike vagy némelyike nem egyezik meg a CVM-eken vagy a PC-s virtuális gépeken beállítottakkal.
• A konfigurált NTP-kiszolgáló nem érhető el, vagy nem válaszol az NTP-lekérdezésekre.
• A konfigurált NTP-kiszolgáló nem megbízható és nem stabil.
• Az NTP-kiszolgáló gazdagépnévvel van konfigurálva, de a DNS/névfeloldási problémák miatt nem lehet megoldani.
• Az NTP-port (UDP/123) nincs nyitva.
• A fürtben eltöltött idő nincs szinkronban, és legalább 5 másodperccel a jövőben van az NTP-kiszolgálókon eltöltött idővel összehasonlítva.
• Az NTP-kiszolgáló olyan paramétert ad át, amelyet a CVM vagy a PC VM NTP-ügyfele alkalmatlannak tart az NTP-szinkronizáláshoz, például nagy diszperziós értéket, eltolást, jittert, elérést vagy réteget.
• A Windows -alapú NTP-kiszolgáló (AD PDC), amely alapértelmezés szerint a helyi órát használja időforrásként, kevésbé alkalmas NTP-forrásként hirdeti magát, és 10 másodperces diszperziós értéket ad meg a kiszolgáló NTP-paraméterében. A W32time-t nem az NTP-hez szükséges pontossággal tervezték, és nem garantálja a +/- 5 percnél jobb tűréshatárt.
• A genesis szolgáltatás nemrég indult újra, és az NTP-szinkronizálás még mindig függőben van, vagy ha az NTP-konfiguráció megváltozott, a hatás eltarthat egy ideig. Az NTP protokoll szerint körülbelül 5 percbe telik (öt jó minta), amíg egy NTP-kiszolgálót elfogadnak szinkronizálási forrásként. Az ellenőrzés 10-15 perc elteltével történő várakozása és újbóli futtatása eltérő eredményt eredményezhet, ha ez elegendő időt biztosított a módosítás érvénybe lépéséhez és szinkronizálásához.

  Például a genesis újraindítása után az ntpq parancs azt mutatja, hogy az idő még mindig szinkronizálódik a .LOCL-lel.

Ezután 10-15 perc várakozás után az ntpq parancs most ezt mutatja:

Ezért az ellenőrzés azonnali újrafuttatása sikertelen lesz, de egy bizonyos idő elteltével, mondjuk 10-15 perc elteltével, újrafuttatnia kell, hogy MEGADJA.

Tünetek és hatások

Ha ez az állapotellenőrzés nem PASS eredményt ad vissza, akkor a fürtművelet különféle tünetek/hatások kockázatával járhat, mint például:

• Azok a felhasználók, akik nem tudnak bejelentkezni a Prism webkonzolra LDAP vagy más címtárba integrált szolgáltatások használatával.
• A fürt nem tud elindulni vagy megfelelően működni a kimaradás vagy karbantartás utáni jelentős időtorzulás miatt.
• Pontatlan naplózás és naplógyűjtés.
• A pontatlan állapotellenőrzési eredmények pontos időkereten és eseménykorreláción alapulnak.
• Helytelen és ferde grafikonok a Prizmában.
• A hypervisor gazdagépeken induló felhasználói virtuális gépek pontatlan RTC-vel (valós idejű órákkal) okozzák a vendég operációs rendszer időtorzítását.
• Harmadik féltől származó biztonsági mentési szoftvertermékek, például a Veeam vagy a Commvault, problémákba ütköznek a fürttel való interakció során.
• A pillanatképek túl korán vagy túl későn járnak le, ha a fürt és a távoli hely közötti idő nincs szinkronban

Az NCC ellenőrzés futtatása

Futtassa ezt az ellenőrzést a teljes NCC állapotellenőrzés részeként:

Vagy futtassa ezt az ellenőrzést egyenként:

Az ellenőrzéseket a Prism Web konzol állapota oldaláról is futtathatja: válassza a Műveletek > Ellenőrzések futtatása lehetőséget. Válassza az Összes ellenőrzés lehetőséget, majd kattintson a Futtatás gombra.

Minta kimenet

Az állapothoz: INFO

Állapot: FAIL

Állapothoz: ERR

Az NCC-4.0.0-tól kezdődően az állapothoz: WARN

Kimeneti üzenetküldés

Megjegyzés : Az 103076-os csekkazonosító megszűnt az NCC 4.0.0-s verziójában.

Megoldás

Az ESXi 7.0.3 build 19193900-as verzióját futtató fürtök esetében az ellenőrzés hamis pozitív eredményt ad még akkor is, ha a gazdagépen és a Prism felhasználói felületen konfigurált NTP-kiszolgálók megegyeznek.

Kérjük, frissítsen az NCC-4.5.0.1-re a téves pozitív visszajelzések mérséklése érdekében.

Általános hibaelhárítási lépések

Ha az ellenőrzés nem PASS eredményt ad vissza, ellenőrizze a következőket:

• Legalább egy, de lehetőleg három vagy több megbízható fürtön kívüli NTP-kiszolgáló van konfigurálva a fürtön (CVM-ek/PCVM-ek) ÉS a gazdagépeken (hipervizorok - AHV, ESXi, Hyper-V, XenServer).
  • Az NTP-kiszolgálók konfigurálásához a CVM-eken és az AHV-n lásd: NTP-kiszolgálók konfigurálása a Prism Web Console útmutatóban . (Az NTP-kiszolgálók Prism segítségével történő konfigurálása frissíti a CVM-eket és az AHV-gazdagépeket is).
  • Az NTP-kiszolgálók ESXi-gazdagépeken való konfigurálásához lásd: Network Time Protocol (NTP) konfigurálása ESX/ESXi-gazdagépeken a vSphere Client segítségével (2012069) .
  • Az NTP-kiszolgálók Hyper-V-állomásokon történő konfigurálásához lásd az alábbi, Az NTP konfigurálása Hyper-V-n című részt .
  • Az NTP-kiszolgálók használatára vonatkozó javaslatokért lásd: Javaslatok az időszinkronizáláshoz .
• A hipervizorokon konfigurált NTP-kiszolgálók listájának lehetőleg meg kell egyeznie a CVM-eken konfiguráltakkal.
• Ha az NTP-kiszolgáló az FQDN vagy a gazdagépnév használatával van beállítva, győződjön meg arról, hogy a fürt fel tudja oldani az NTP FQDN IP-címét az összes konfigurált DNS-névkiszolgálóval szemben. A Prism érvénytelen névkiszolgáló-konfigurációja megakadályozhatja az NTP-kiszolgálók használatát, és időszinkronizálási problémákhoz vezethet.
• Az NTP-protokoll célportja (UDP 123) nyitva áll a megcélzott NTP-kiszolgálók számára az összes CVM/gazdagép és az NTP-kiszolgálók közötti hálózati úton található ACL-eken/tűzfalakon keresztül.
• Próbálja meg pingelni az NTP-kiszolgálókat FQDN és IP-címek használatával az alapvető hálózati kapcsolat létrehozásához. Ne feledje, hogy egyes ACL-ek/tűzfalak szándékosan blokkolhatják a ping (ICMP echo) forgalmat, de továbbra is engedélyezik az UDP/123-at, ezért vegye figyelembe, hogy az elérhetetlen eredmény nem feltétlenül a kiváltó ok, hanem a hálózati csatlakozási problémák lehetséges betekintése. A további érvényesítéshez használja a következő lépést.
• Függetlenül attól, hogy az NTP-szerver elérhető-e a ping-eléssel a hálózaton, győződjön meg arról, hogy az egészséges, és az alkalmazási rétegben érvényes és használható NTP-lekérdezésekkel válaszol, és pontos időinformációkat ad vissza. A következő parancs futtatásával ellenőrizheti, hogy az NTP-lekérdezések időinformációt adnak-e vissza:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Ellenőrizze az NTP-szinkronizálás állapotát az összes CVM-en és gazdagépen az alábbi „ntpq -pn” parancs kimenetének áttekintése eljárással.
• Ellenőrizze az NTP konfigurációt az összes gazdagépen az alábbi , Az ntp.conf fájl tartalmának áttekintése eljárással.
• Ez az ellenőrzés nem PASS eredményt adhat az NTP konfigurálása után, ha az idő még nincs szinkronizálva az új/frissített NTP-konfigurációval. Ha az NTP-kiszolgálót nemrég adták hozzá, és a CVM-idő nem számít a jövőbeni időnek (negatív eltolás az NTP-kiszolgálótól), akkor ez az ellenőrzés mindaddig aktiválódhat, amíg az NTP-protokoll nem talál egy stabil és megfelelő NTP-forrást, és a CVM sikeresen szinkronizálva (~10 perc).
• Ha a konfigurált NTP-szerver(ek) önmagukban nem megbízható 0. rétegforrások (GPS/Atomic Clock), akkor megfelelő rétegű külső időforrással kell rendelkezniük (0-3 jó), és nem kell szinkronizálniuk a helyi órával. hogy a szerver vagy egy belső időforrás.

Megjegyzések:

• A Nutanix AOS/PC-fürt Windows -alapú időforrással való szinkronizálása bizonyos időn keresztül problémákat okoz. Tekintse meg a KB 3851 - NTP Sync to Windows Time Servers hibaelhárítását .
  A Nutanix azt javasolja, hogy ne szinkronizálja a fürt idejét a Windows időforrásaival. Használjon helyette megbízható, nem Windows időforrásokat. Lásd: Javaslatok az időszinkronizáláshoz a Prism Web Console útmutatóban .
• Ne használjon NTP-kiszolgálót Nutanix-fürt és/vagy hypervisor forrásaként, ha a tényleges NTP-kiszolgáló egy felhasználói virtuális gép, amely ugyanazon a fürtön vendégként fut! Ez megbízhatatlan, kiszámíthatatlan a felhasználói virtuális gépeknél és a fürt leállásoknál és újraindításoknál, és nem ajánlott.
• Nem kell manuálisan konfigurálnia az NTP-kiszolgálókat az AHV-állomásokon. Az NTP-kiszolgálók Prism/ncli-n keresztüli konfigurálása frissíti a CVM-eket és az AHV-gazdagépeket is.
• Ha a Prism webkonzolt vagy az ncli-t használja az NTP-kiszolgálók hozzáadásához egy ESXi-alapú AOS-fürthöz, az NTP-kiszolgálók nem kerülnek automatikusan hozzáadásra a gazdagép /etc/ntp.conf fájljához. Miután hozzáadta az NTP-kiszolgálókat a Prism-hez, manuálisan is be kell állítania ezeket az NTP-kiszolgálókat az ESXi-állomásokon. Az NTP-kiszolgálók ESXi gazdagépeken való konfigurálásával kapcsolatos további információkért lásd: Network Time Protocol (NTP) konfigurálása ESX/ESXi gazdagépeken a vSphere Client használatával (2012069) .
• Egy vegyes-hipervizoros fürtben (AHV + ESXi), amint azt fentebb említettük, az AHV-állomások Prism-en keresztül lesznek konfigurálva, de manuálisan kell konfigurálnia az NTP-kiszolgálókat a vegyes-hipervizoros fürt ESXi-állomásain.
• Hyper-V-fürtön a check_ntp beépülő modul csak a CVM NTP konfigurációt érvényesíti. Nem ellenőrzi a Windows Hyper-V gazdagépek NTP-jét vagy időkonfigurációját, így az ellenőrzés nem eredményez FAIL állapotot, ha a hipervizor rosszul van konfigurálva, vagy nincs szinkronban az NTP-forrásokkal és/vagy az AD PDC-vel. Manuálisan ellenőrizze, hogy a Hyper-V gazdagépek és tartományvezérlők egészséges Windows -időhierarchiával rendelkeznek-e. Az AD PDC-knek megbízható upstream NTP-időforrásokat kell használniuk a CVM-ekkel párhuzamosan, esetleg ugyanazokat az NTP-kiszolgálókat (lásd a következő pontot).
• Ideális esetben a naplók összehasonlításának egyszerűsítése és a bonyolult időszinkronizálási problémák elkerülése érdekében a hypervisoroknak és a Controller virtuális gépeknek ugyanazt az NTP-kiszolgálót kell használniuk. Ha a hipervizorok és a Controller virtuális gépek különböző NTP-kiszolgálókat használnak, ez az állapotellenőrzés INFO-kimenetet produkálhat, hogy felhívja a figyelmet, és megbizonyosodjon arról, hogy ez tudatos és ésszerű konfiguráció, szemben a véletlen hibás konfigurációval, és gyorsan kiemeli ezt a tényt bármely más, nem kapcsolódó hibaelhárítás során. ha ez a klaszterek gyártása során bármikor bekövetkezik.

A Nutanix-fürtidő-szinkronizálással kapcsolatos további információkért és bevált gyakorlatokért tekintse meg a Nutanix támogatási portálján található Prism Web Console Guide cluster-idő-szinkronizálás című részét.

Konkrét hibaelhárítási lépések

• Ha az ellenőrzés jelentése „INFO: Az xxxx hypervisoron konfigurált NTP-kiszolgálók eltérnek a Zeus config xxxx-ben konfiguráltaktól”, konfigurálja ugyanazokat az NTP-kiszolgálókat a fürtben, valamint a hipervizorokat.
• Ha az ellenőrzés azt jelenti, hogy "FAIL: Az NTP vezető nem szinkronizál semmilyen külső NTP-kiszolgálóval, mert a fürt ideje a jövőben van a külső NTP-kiszolgálókhoz képest: xxxx", akkor előfordulhat, hogy a fürt érvényes NTP-szinkronizálási állapot és lehívás nélkül indult el. a CVM-idő visszafelé hatással lehet a repülés közbeni metaadat-tárolási műveletekre. A jövőbeli CVM-idővel kapcsolatos konkrét probléma megoldásához további segítségért naplózza az esetet a Nutanix ügyfélszolgálatával , és ne módosítsa manuálisan a CVM-dátumot/időt.
• Ha az ellenőrzés azt jelenti, hogy „SIKERES: Az NTP-vezér nem szinkronizál semmilyen külső NTP-kiszolgálóval”, kövesse a fenti általános hibaelhárítási lépéseket . Ha a fent említett lépések nem oldják meg a problémát, naplózzon egy esetet a Nutanix támogatással , és adja meg az általános hibaelhárítás és az aktuális fürt NTP-konfiguráció eredményeit és kimeneteit.
• Ha az ellenőrzés azt jelenti, hogy „SIKERES: A hypervisor nem szinkronizál egyetlen NTP-kiszolgálóval sem”, kövesse a fenti általános hibaelhárítási lépéseket . Ha a fent említett lépések nem oldják meg a problémát, kövesse az alábbi lépéseket:
  1. A gazdagépen indítsa újra az ntpd szolgáltatást az alábbiakban ismertetett Az ntpd szolgáltatás újraindítása eljárással.
  2. Ellenőrizze, hogy a gazdagép most szinkronizálja-e az idejét az NTP-vel az alábbi eljárással : Tekintse át az "ntpq -pn" parancs kimenetét . A szinkronizáláshoz mindenképpen várjon ~10 percet.
  3. Ha nem minden gazdagép szinkronizál megfelelően, kövesse az alábbi ntp.conf fájl tartalmának áttekintését .
  4. Ha a probléma továbbra sem oldódott meg, vegye fontolóra a Nutanix Support szolgáltatást, amely biztosítja az eredményeket, valamint az általános hibaelhárítás és a fürt jelenlegi NTP-konfigurációjának bármely kimenetét.
• Ha az ellenőrzés azt jelenti, hogy "FAIL: Ez a CVM az NTP vezető, de nem szinkronizálja az időt egyetlen külső NTP-kiszolgálóval sem", és Ön ellenőrizte, hogy az NTP-kiszolgáló be van állítva:
  1. Előfordulhat, hogy a konfigurált NTP-kiszolgáló(k) túlterheltek, és/vagy szándékosan korlátozzák az NTP-kliens-kérések számát, hogy megvédjék magukat a DDoS-el szemben (véletlen vagy egyéb), ezért nem válaszolnak a CVM NTP-vezető érvényes NTP-kéréseire. Kivizsgálhatja, hogy az NTP-kiszolgáló korlátozza-e a kérések sebességét, ha megvizsgálja a CVM genesis szolgáltatásnaplófájlját, hogy van-e olyan hibasor-bejegyzés, amely tartalmazza a " sebességkorlát válasz a szervertől " szöveget:
     nutanix@cvm$ allssh "grep -A 1 -i 'sebességkorlát' ~/data/logs/genesis.out | tail"
     ...
     2018-12-12 11:03:14 HIBA node_manager.py:3941 A rendszerfrissítés ntpdate-vel meghiúsult: 1: 12 december 11:03:14 ntpdate[26695]: nnn101 sebességkorlát válasz a szervertől.
     2018-12-12 11:03:14 ntpdate[26695]: nem található szinkronizálásra alkalmas szerver
     1. Ha nem Ön irányítja az érintett NTP-kiszolgálót, távolítsa el a Prism NTP-konfigurációjából, és adjon hozzá egy másik, megbízhatóbb NTP-kiszolgálót.
     2. Ha Ön szabályozza a forrás NTP-kiszolgáló konfigurációját, fontolja meg korlátozási kivételek hozzáadását a CVM/gazda IP-címekhez. A részletekért tekintse meg az NTP-kiszolgáló saját dokumentációját. Például egy Linux-alapú ntpd szolgáltatásnál a következő sort kell hozzáadni az NTP-kiszolgáló /etc/ntp.conf fájljához, majd újra kell tölteni:
        korlátoz maszk
  2. A CVM-idő megelőzheti az NTP-kiszolgáló idejét, és a CVM genezis-szolgáltatása szándékosan megakadályozza az NTP-szinkronizálást. Ezt tovább bizonyíthatja az érintett CVM Genesis naplóiban, ha futtatja a következő parancsot, és negatív eltolást keres a CVM és az NTP-forrás között:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | tail"
     Példa kimenet:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Upstream NTP-szerverek lekérdezése: 10.xx11
     2019-02-03 22:42:12 INFO node_manager.py:2334 NTP eltolás: -89,328 másodperc
     2019-02-03 22:42:12 INFO node_manager.py:2354 Az idő 89,328 másodperccel megelőzi a külső NTP-kiszolgálót, nincs szinkronizálási idő a fürtszolgáltatások futása közben
     2019-02-03 22:42:12 INFO node_manager.py:2230 Az NTP-szerver újraindítása.
     2019-02-03 23:02:13 HIBA node_manager.py:2450 A külső NTP továbbra is használhatatlan (0)
     2019-02-03 23:02:13 FIGYELMEZTETÉS node_manager.py:2456 Az upstream NTP-szerverek letiltása
     2019-02-03 23:02:13 INFO node_manager.py:2202 Az NTP-szerver leállítása.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Az NTP-szerver újraindítása.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Upstream NTP-szerverek lekérdezése: 10.xx11
     2019-02-03 23:12:13 INFO node_manager.py:2334 NTP eltolás: -89,297 másodperc
     
     A fenti példakimenetben a fürt nem szinkronizál az újonnan hozzáadott NTP-kiszolgálóval. Ebben a helyzetben az NTP-kiszolgáló 89 másodperccel lemaradva fut a CVM-től, ezért NTP-forrásként használhatatlannak tekinthető.
     Fontos: Ha a CVM idő a jövőben van, NE állítsa vissza kézzel az órát ! Forduljon a Nutanix ügyfélszolgálatához segítségért, és adja meg a fenti adatokat.
• Ha az ellenőrzés azt jelenti, hogy „ERR: Nem sikerült futtatni az ntpq-t a gazdagépen”: Futtassa a következő parancsot minden CVM-en, és győződjön meg arról, hogy a parancs sikeresen fut.
  nutanix@cvm$ ntpq -pn

  Ha a parancs nem fut le, vagy az NCC-ellenőrzés ismét ERR-állapotot jelez, vizsgálja meg a CVM-ek szabad memóriáját. További segítségért naplózza az esetet a Nutanix ügyfélszolgálattal .

Az " ntpq -pn " parancs kimenetének áttekintése

Az ' ntpq -pn ' parancs az ellenőrzés által használt fő parancs a CVM vagy a gazdagép NTP-szinkronizálási állapotának azonosítására.

Az eredmények minden sora a következő formátumú lesz: (Csak példa kimenet. A tényleges IP-címek, az NTP-kiszolgálók sorai és a kapcsolódó értékek az egyedi konfigurációktól függően eltérőek lehetnek)

Hol van a távoli partner vagy kiszolgáló, amellyel szinkronizálódik. A „127.127.1.0 LOCL” ez a helyi gazdagép (tartozik abban az esetben, ha nem állnak rendelkezésre távoli társak vagy kiszolgálók).

A táblázatban megjelenő első karakter egy állapotjelző. Szinkronizált állapot várható, amelyet a „*” jelképez egy távoli NTP-kiszolgáló bejegyzésének első karaktereként.

Megjegyzés: Ez a szinkronizált állapot 10-15 percet vesz igénybe, ha az NTP vezető szerepkörrel rendelkező genezis szolgáltatás nemrég módosult, vagy az NTP-kiszolgáló konfigurációja módosult.

1. Az összes CVM NTP állapotának ellenőrzéséhez futtassa a következő parancsot egy CVM-ről:
   nutanix@cvm$ allssh ntpq -pn
   A következő példa jó eredmény – bemutatja, hogy a CVM NTP-vezér egy külső NTP-kiszolgálóval, a többi CVM pedig a CVM NTP-vezetővel van szinkronizálva.
   ================== 10.xx.xx.61 ==================
   távoli refid st t amikor poll elérési késleltetés 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 <--- Szinkronizálva egy konfigurált NTP-kiszolgálóval 10.xx.xx.11
   127.127.1.0 .LOCL. 10 l 27 óra 64 0 0,000 0,000 0,000
   ================== 10.xx.xx.62 =================
   távoli refid st t amikor poll elérési késleltetés offset jitter
   =================================================== =============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Szinkronizálva a CVM NTP vezetővel 10.xx.xx.61
   ================== 10.xx.xx.63 ==================
   távoli refid st t amikor poll elérési késleltetés offset jitter
   =================================================== =============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Szinkronizálva a CVM NTP vezetővel 10.xx.xx.61
   
   Az alábbiakban egy példa látható egy problémás eredményre. A CVM NTP vezető csak a helyi órájával van szinkronizálva:
   ================== 10.xx.xx.61 ==================
   távoli refid st t amikor poll elérési késleltetés offset jitter
   =================================================== =============================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0,000 0,000 0,000 <--- CVM NTP vezető csak a helyi órájával szinkronizálva
   ================== 10.xx.xx.62 =================
   távoli refid st t amikor poll elérési késleltetés offset jitter
   =================================================== =============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0,353 2,584 1,355 <--- Szinkronizálva a CVM NTP vezetővel 10.xx.xx.61
   ================== 10.xx.xx.63 ==================
   távoli refid st t amikor poll elérési késleltetés offset jitter
   =================================================== =============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0,192 1,775 1,682 <--- Szinkronizálva a CVM NTP vezetővel 10.xx.xx.61
   
   Ha a „127.127.1.0” IP-címet használja, az azt jelenti, hogy a CVM-ek csak az NTP vezetővel szinkronizálnak (a „127.127.1.0” egy helyi állomás IP-címe), és az ellenőrzés időpontjában NEM szinkronizál semmilyen külső NTP-kiszolgálóval. teljesített.
2. Az összes gazdagép/hipervizor NTP állapotának ellenőrzéséhez futtassa a következő parancsot egy CVM-ről:
   nutanix@cvm$ hostssh ntpq -pn
   
   A következő példa jó eredmény. Minden gazdagép ugyanazokkal az NTP-kiszolgálókkal szinkronizál.
   ============= 192.xx.xx.1 =============
   távoli refid st t amikor poll elérési késleltetés 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 =============
   távoli refid st t amikor poll elérési késleltetés 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 =============
   távoli refid st t amikor poll elérési késleltetés 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
   Ha az NTP IP-címek nem következetesen azonosak minden gazdagépen, ellenőrizze az /etc/ntp.conf fájlt , hogy nem használnak-e olyan gazdagépnevet/FQDN-t, amely az NTP-kiszolgálók készletét képviseli. Az NTP-készletek nagyon sok körkörös DNS-bejegyzésből állnak, így az inicializáláskor az egyes gazdagépeknek adott DNS-válasz az NTP-szolgáltatás indításakor eltérő IP-címet adhat vissza NTP-kiszolgálóként való használatra.
3. Ha a következő üzenetet látja egy AHV gazdagépen az ntpq futtatásakor:
   Nincs visszaadott társítási azonosító
   
   A következő parancsok futtatásával erősítse meg, hogy AHV el6 kernelt futtat:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# macska /etc/nutanix-release
   
   Ha el6 kernelen fut, az alábbihoz hasonló kimenetet fog látni:
   el6.nutanix.20170830.151
   A probléma ideiglenes kijavításához (megkerülő megoldás) a gazdagépen indítsa újra az ntpd szolgáltatást az alábbi eljárással: Indítsa újra az ntpd szolgáltatást , majd futtassa újra ezt az NCC-ellenőrzést a megerősítéshez.

   A probléma végleges megoldásához frissítse az AOS rendszert 5.5.8, 5.9.2, 5.10 vagy újabb verzióra.

4. Ha a következő üzenetet látja egy ESXi gazdagépen az ntpq futtatásakor, az azt jelenti, hogy az ESXi/ESX gazdagép nem tudja elérni a konfigurált NTP-kiszolgálót:
   Nincs visszaadott társítási azonosító
   A hostssh date paranccsal győződjön meg arról, hogy az összes gépen az idő helyes és megegyezik.

   Győződjön meg arról, hogy az NTP-kiszolgáló IP-címei be vannak állítva a gazdagépen az /etc/ntp.conf fájllal.

   Az alábbi paranccsal ellenőrizze, hogy a DNS-kiszolgáló konfigurációja helyes-e a gazdagépeken:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli hálózati ip dns szerver lista >>> Egyetlen gazdagép ellenőrzése
   nutanix@cvm$ hostssh "esxcli hálózati ip dns szerver lista" >>> Az összes gazdagép ellenőrzése
   
   Ennek megoldásához javítsa ki a DNS-kiszolgáló konfigurációját a következő paranccsal. Alternatív megoldásként adja hozzá a megfelelő DNS-konfigurációt a Központban:
   [root@Esxi:~]esxcli hálózati ip dns szerver add --server=
5. Ha a következő üzenetet látja egy AHV gazdagépen az ntpq futtatásakor:
   A név vagy a szolgáltatás nem ismert
   Ezt a problémát az okozhatja, hogy az ntpq parancs nem tudja feloldani a "localhost"-ot 127.0.0.1-re.

   A probléma megoldásához naplózzon egy esetet a Nutanix támogatással , amely tartalmazza az általános hibaelhárítás és az aktuális NTP-konfiguráció eredményeit és kimeneteit.

6. A következő típusú kimenetet láthatja, amikor az ntpq -pn parancsot futtatja PCVM-en:
   nutanix@PCVM:~$ ntpq -pn
   távoli refid st t amikor poll elérési késleltetés 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:~$
   Az ntpq paranccsal kapcsolatos további információkért tekintse meg az ntpq kézikönyvoldalát .

Az ntp.conf fájl tartalmának áttekintése

1. Tekintse át az ntpq -pn parancs kimenetét a fenti eljárással .
2. Ha nem minden AHV vagy ESXi gazdagép szinkronizálja az időt az NTP-vel, ellenőrizze az összes gazdagép /etc/ntp.conf fájlját.

   Az alábbiakban egy minta kimenet látható, ahol 3-ból csak 2 gazdagép sikeresen szinkronizál az NTP-vel.

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   korlátozza az alapértelmezett kodot nomodify notrap nopeer noquery
   korlátozza a 127.0.0.1
   szerver 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.2 =============
   korlátozza az alapértelmezett kodot nomodify notrap nopeer noquery
   korlátozza a 127.0.0.1
   szerver 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.3 =============
   bütykös pánik 0
   szerver 10.xx.xx.8
   driftfile /var/lib/ntp/drift
   naplófájl /var/log/ntp.log
   korlátozza 10.8.xx maszk 255.255.255.0 nomodify notrap
   felület figyelmen kívül hagyja a helyettesítő karaktert
   felület hallgass br0
   korlátozza a 127.0.0.1
   korlátozni -6 ::1
   korlátozza az alapértelmezett kodot nomodify notrap nopeer noquery
   korlátoz -6 alapértelmezett kod nomodify notrap nopeer noquery
   tiltsa le a monitort
   A fenti mintakonfigurációban a 10.xx.xx.1 és 10.1xx.xx.2 gazdagépek sikeresen szinkronizálódnak az NTP-vel, míg a 10.xx.xx.3 sikertelen, mert korlátozza az NTP-szinkronizálást
3. Ennek megoldásához kövesse a fenti általános hibaelhárítási lépéseket . Vegye figyelembe, hogy az AHV gazdagépek a CVM-ekkel együtt Prism-en keresztül is konfigurálhatók.
4. Átmeneti upstream NTP vagy csatlakozási probléma esetén indítsa újra az ntpd szolgáltatást az alábbi eljárással.
5. Várjon 5-10 percet, majd futtassa a következő parancsot az egyik CVM-ről, hogy ellenőrizze, hogy az összes hipervizor szinkronizál-e az NTP-kiszolgálóval:
   nutanix@cvm$ hostssh ntpq -pn
6. Futtassa újra az NCC ellenőrzést.
7. Ha a fent említett lépések nem oldják meg a problémát, naplózzon egy esetet a Nutanix támogatással , és adja meg az eredményeket, valamint az általános hibaelhárítás és a fürt jelenlegi NTP-konfigurációjának kimenetét.

   Megjegyzés: Az ESXi rendszeren az /etc/ntp.conf fájlban szereplő " interface listen br0 " okozza a fenti problémát. A sort el kell távolítani, és az ntpd szolgáltatást újra kell indítani.

Az ntpd/w32time szolgáltatás újraindítása

AHV el6 vagy ESXi rendszeren futtassa:

AHV el7 futáson:

A paranccsal ellenőrizheti, hogy a telepített AHV verzió az el6 vagy az el7 családhoz tartozik-e:

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

A Hyper-V-n futtassa:

Az NTP beállítása Hyper-V-n

A Hyper-V 2016 gazdagépei a tartományvezérlőt használják NTP-ként. A külső NTP-források konfigurálása az Active Directory tartományvezérlő(k)en:

1. Nyisson meg egy parancssort a DC-n adminisztrátori jogosultságokkal.
2. Az időszolgáltatás leállítása:
   C:\> net stop w32time
3. Állítsa be a külső szerverek manuális peerlistáját:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:" ”
4. Állítsa be a kapcsolatot megbízhatónak:
   C:\> w32tm /config /megbízható:igen
5. Indítsa el az időszolgáltatás biztonsági mentését:
   C:\> net start w32time
6. Tesztelje a konfigurációt:
   C:\> w32tm /query /configuration és w32tm /query /status

további információ

• Nutanix KB 4519 - Eredeti dokumentum a Nutanix portálon