विवरण

Nutanix NCC स्वास्थ्य जांच प्लगइन check_ntp CVMs (कंट्रोलर VMs) और हाइपरवाइजर होस्ट की NTP कॉन्फ़िगरेशन की पुष्टि करता है। यह क्लस्टर पर किसी भी समय के विचलन की भी जांच करता है।

प्लगइन check_ntp में कई व्यक्तिगत जांचें शामिल हैं जो विशिष्ट NTP-संबंधित परिदृश्यों पर ध्यान केंद्रित करती हैं:

• CVM/PCVM NTP समय समन्वय - यह निर्धारित करता है कि क्या CVM/PCVM किसी भी कॉन्फ़िगर किए गए NTP सर्वरों के साथ समय समन्वयित कर सकता है
• हाइपरवाइजर NTP समय समन्वय (AHV + ESXi केवल) - यह निर्धारित करता है कि क्या होस्ट किसी भी कॉन्फ़िगर किए गए NTP सर्वरों के साथ समय समन्वयित कर सकता है

नोट: NTP कॉन्फ़िगरेशन जांच, जांच आईडी 103076 NCC संस्करण 4.0.0 में समाप्त कर दी गई है।

यह प्लगइन Prism Central (PC) पर भी चलता है, हाइपरवाइजर जांच को छोड़कर।

यह स्वास्थ्य जांच प्लगइन NCC संस्करण 3.1 में पेश किया गया था और पिछले NCC संस्करणों से सभी NTP जांचों को समेकित करता है। Prism Central पर, यह जांच NCC संस्करण 3.5.3 में पेश की गई थी। इन जांचों की अलर्ट फ़ंक्शन NCC 3.6.2 में पेश की गई थी।

संभावित कारण

यदि यह स्वास्थ्य जांच एक गैर-PASS परिणाम लौटाती है, तो निम्नलिखित संभावित कारण हो सकते हैं:

• क्लस्टर पर कोई NTP सर्वर कॉन्फ़िगर नहीं है।
• हाइपरवाइजर पर कोई NTP सर्वर कॉन्फ़िगर नहीं है।
• हाइपरवाइजर पर कॉन्फ़िगर किए गए सभी या कुछ NTP सर्वर CVMs या PC VMs पर कॉन्फ़िगर किए गए सर्वरों के समान नहीं हैं।
• एक कॉन्फ़िगर किया गया NTP सर्वर पहुँच योग्य नहीं है या NTP प्रश्नों का उत्तर नहीं दे रहा है।
• एक कॉन्फ़िगर किया गया NTP सर्वर विश्वसनीय या स्थिर नहीं है।
• NTP सर्वर को एक होस्टनाम के साथ कॉन्फ़िगर किया गया है लेकिन DNS/नाम समाधान समस्याओं के कारण इसे हल नहीं किया जा सकता।
• NTP पोर्ट (UDP/123) खुला नहीं है।
• क्लस्टर का समय असमंजस में है और वास्तविक समय की तुलना में कम से कम 5 सेकंड भविष्य में पाया गया है।
• NTP सर्वर एक ऐसा पैरामीटर पास कर रहा है जिसे CVM या PC VM का NTP क्लाइंट NTP समन्वय के लिए अनुपयुक्त मानता है, जैसे उच्च विसरण मान, ऑफसेट, जिटर, पहुँच, या स्तर।
• एक Windows-आधारित NTP सर्वर (AD PDC) जो अपने स्थानीय घड़ी को अपने समय स्रोत के रूप में उपयोग करता है, डिफ़ॉल्ट रूप से, NTP पैरामीटर में 10 सेकंड का विसरण मान शामिल करके खुद को एक कम उपयुक्त NTP स्रोत के रूप में विज्ञापित करेगा। W32time NTP के लिए आवश्यक सटीकता के साथ डिज़ाइन नहीं किया गया है और +/- 5 मिनट की सहिष्णुता से बेहतर की गारंटी नहीं देता।
• जेनसिस सेवा हाल ही में पुनः प्रारंभ हुई है और NTP समन्वय अभी भी लंबित है, या यदि NTP कॉन्फ़िगरेशन में परिवर्तन किया गया है, तो प्रभाव में कुछ समय लग सकता है। NTP प्रोटोकॉल के अनुसार, एक NTP सर्वर को समन्वय स्रोत के रूप में स्वीकार करने में लगभग 5 मिनट (पाँच अच्छे नमूने) लगते हैं। 10-15 मिनट बाद जांच करने और पुनः चलाने से यदि इसने परिवर्तन को प्रभावी होने और समन्वयित करने के लिए पर्याप्त समय प्रदान किया है तो एक अलग परिणाम उत्पन्न हो सकता है।

  उदाहरण के लिए, जेनसिस को पुनः प्रारंभ करने के बाद, ntpq कमांड दिखाता है कि समय अभी भी .LOCL के साथ समन्वयित हो रहा है।

फिर, 10-15 मिनट इंतजार करने के बाद, ntpq कमांड अब दिखाता है:

इसलिए, तुरंत जांच को पुनः चलाना विफल होगा, लेकिन कुछ समय बाद, जैसे 10-15 मिनट, इसे PASS करना चाहिए।

लक्षण और प्रभाव

यदि यह स्वास्थ्य जांच एक गैर-PASS परिणाम लौटाती है, तो क्लस्टर संचालन विभिन्न लक्षणों/प्रभावों के जोखिम में हो सकता है जैसे:

• उपयोगकर्ता LDAP या अन्य निर्देशिका एकीकृत सेवाओं का उपयोग करके Prism वेब कंसोल में लॉग इन नहीं कर पा रहे हैं।
• क्लस्टर आउटेज या रखरखाव के बाद प्रमुख समय-स्क्यू के कारण शुरू या सही ढंग से कार्य करने में असमर्थ है।
• असंगत लॉगिंग और लॉग संग्रह।
• असंगत स्वास्थ्य जांच परिणाम सटीक समय सीमा और घटना सहसंबंध पर निर्भर करते हैं।
• Prism में गलत और विकृत ग्राफ।
• उपयोगकर्ता VMs हाइपरवाइजर होस्ट पर असंगत RTC (वास्तविक समय घड़ियों) के साथ शुरू हो रहे हैं जिससे अतिथि OS का समय विकृत हो रहा है।
• तीसरे पक्ष के बैकअप सॉफ़्टवेयर उत्पाद जैसे Veeam या Commvault क्लस्टर के साथ बातचीत करने में कठिनाई हो रही है।
• जब क्लस्टर और एक दूरस्थ साइट के बीच का समय असमंजस में होता है, तो स्नैपशॉट बहुत जल्दी या बहुत देर से समाप्त हो रहे हैं।

NCC जांच चलाना

इस जांच को पूर्ण NCC स्वास्थ्य जांच के भाग के रूप में चलाएँ:

या इस जांच को व्यक्तिगत रूप से चलाएँ:

आप Prism वेब कंसोल स्वास्थ्य पृष्ठ से भी जांच चला सकते हैं: क्रियाएँ चुनें > जांचें चलाएँ। सभी जांचें चुनें और चलाएँ पर क्लिक करें।

नमूना आउटपुट

स्थिति के लिए: INFO

स्थिति के लिए: FAIL

स्थिति के लिए: ERR

NCC-4.0.0 से आगे स्थिति के लिए: WARN

आउटपुट संदेश

नोट: चेक आईडी 103076 NCC संस्करण 4.0.0 में समाप्त हो गया है।

समाधान

ESXi 7.0.3 बिल्ड 19193900 पर चलने वाले क्लस्टरों के लिए, चेक NTP सर्वर कॉन्फ़िगर होने के बावजूद झूठी सकारात्मकता देगा।

झूठी सकारात्मकता को कम करने के लिए कृपया NCC-4.5.0.1 में अपग्रेड करें।

सामान्य समस्या निवारण कदम

यदि यह चेक गैर-PASS परिणाम लौटाता है, तो निम्नलिखित की जांच करें:

• क्लस्टर (CVMs/PCVMs) और होस्ट (हाइपरवाइजर - AHV, ESXi, Hyper-V, XenServer) पर कम से कम एक, लेकिन तीन या अधिक विश्वसनीय ऑफ-क्लस्टर NTP सर्वर कॉन्फ़िगर किए गए हैं।
  • CVMs और AHV पर NTP सर्वर कॉन्फ़िगर करने के लिए, NTP सर्वर कॉन्फ़िगर करना देखें प्रिज्म वेब कंसोल गाइड में। (प्रिज्म के माध्यम से NTP सर्वर कॉन्फ़िगर करने से CVMs और AHV होस्ट दोनों अपडेट होंगे)।
  • ESXi होस्ट पर NTP सर्वर कॉन्फ़िगर करने के लिए, vSphere क्लाइंट का उपयोग करके ESX/ESXi होस्ट पर नेटवर्क टाइम प्रोटोकॉल (NTP) कॉन्फ़िगर करना (2012069) देखें।
  • हाइपर-V होस्ट पर NTP सर्वर कॉन्फ़िगर करने के लिए, नीचे हाइपर-V पर NTP कॉन्फ़िगर करना देखें।
  • कौन से NTP सर्वर का उपयोग करना है, इस पर सिफारिशों के लिए, समय समन्वयन के लिए सिफारिशें देखें।
• हाइपरवाइजर पर कॉन्फ़िगर किए गए NTP सर्वरों की सूची को CVMs पर कॉन्फ़िगर किए गए लोगों के समान होना चाहिए।
• यदि NTP सर्वर को FQDN या होस्टनेम का उपयोग करके सेट किया गया है, तो सुनिश्चित करें कि क्लस्टर सभी कॉन्फ़िगर किए गए DNS नाम सर्वरों के खिलाफ NTP FQDN के लिए IP पते को हल कर सकता है। प्रिज्म में एक अमान्य नाम सर्वर कॉन्फ़िगरेशन NTP सर्वरों के उपयोग को रोक सकता है और समय समन्वय समस्याओं का कारण बन सकता है।
• NTP प्रोटोकॉल गंतव्य पोर्ट (UDP 123) सभी CVMs/होस्ट और NTP सर्वरों के बीच नेटवर्क पथ में किसी भी ACLs/फायरवॉल के माध्यम से लक्षित NTP सर्वरों के लिए खुला है।
• NTP सर्वरों को FQDN और IP पते का उपयोग करके पिंग करने का प्रयास करें ताकि बुनियादी नेटवर्क कनेक्टिविटी स्थापित हो सके। ध्यान रखें कि कुछ ACLs/फायरवॉल जानबूझकर पिंग (ICMP इको) ट्रैफ़िक को अवरुद्ध कर सकते हैं लेकिन फिर भी UDP/123 की अनुमति दे सकते हैं, इसलिए यह ध्यान रखें कि एक अप्राप्य परिणाम अनिवार्य रूप से एक मूल कारण नहीं है बल्कि नेटवर्क कनेक्टिविटी समस्याओं के बारे में संभावित अंतर्दृष्टि है। आगे की पुष्टि के लिए अगले कदम का उपयोग करें।
• NTP सर्वर की नेटवर्क पर पिंग द्वारा पहुंच्यता की परवाह किए बिना, सुनिश्चित करें कि यह स्वस्थ है और मान्य और उपयोगी NTP प्रश्नों के साथ एप्लिकेशन स्तर पर प्रतिक्रिया दे रहा है और यह सटीक समय जानकारी लौटाता है। आप निम्नलिखित कमांड चलाकर जांच सकते हैं कि NTP प्रश्न समय जानकारी लौटाते हैं:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• सभी CVMs और होस्ट पर NTP समन्वयन की स्थिति की जांच करें "ntpq -pn" कमांड के आउटपुट की समीक्षा करना प्रक्रिया का उपयोग करके।
• सभी होस्ट पर NTP कॉन्फ़िगरेशन की जांच करें ntp.conf फ़ाइल की सामग्री की समीक्षा करना प्रक्रिया का उपयोग करके।
• यह चेक NTP कॉन्फ़िगर होने के बाद एक गैर-PASS परिणाम उत्पन्न कर सकता है यदि समय अभी तक नए/अपडेटेड NTP कॉन्फ़िगरेशन के साथ समन्वयित नहीं हुआ है। यदि NTP सर्वर हाल ही में जोड़ा गया है, और CVM का समय भविष्य के समय में नहीं माना जाता है (NTP सर्वर से नकारात्मक ऑफसेट), तो यह चेक तब तक सक्रिय हो सकता है जब तक NTP प्रोटोकॉल एक स्थिर और उपयुक्त NTP स्रोत नहीं ढूंढ लेता और CVM सफलतापूर्वक समन्वयित नहीं हो जाता (~10 मिनट)।
• यदि कॉन्फ़िगर किए गए NTP सर्वर स्वयं विश्वसनीय स्ट्रेटम 0 स्रोत (GPS/एटॉमिक घड़ी) नहीं हैं, तो उन्हें उपयुक्त स्ट्रेटम (0-3 अच्छा है) का एक बाहरी समय स्रोत कॉन्फ़िगर किया जाना चाहिए और उन्हें उस सर्वर की स्थानीय घड़ी या आंतरिक समय स्रोत के साथ समन्वयित नहीं होना चाहिए।

नोट्स:

• Nutanix AOS/PC क्लस्टर को Windows-आधारित समय स्रोत के साथ समन्वयित करना समय के साथ समस्याएँ उत्पन्न करने के लिए जाना जाता है। KB 3851 NTP सिंक को Windows समय सर्वरों के लिए समस्या निवारण देखें।
  Nutanix सिफारिश करता है कि आप क्लस्टर के समय को Windows समय स्रोतों के साथ समन्वयित न करें। इसके बजाय विश्वसनीय गैर-Windows समय स्रोतों का उपयोग करें। समय समन्वयन के लिए सिफारिशें देखें प्रिज्म वेब कंसोल गाइड में।
• यदि वास्तविक NTP सर्वर एक उपयोगकर्ता VM है जो उसी क्लस्टर पर मेहमान के रूप में चल रहा है, तो Nutanix क्लस्टर और/या हाइपरवाइजर के लिए NTP सर्वर का उपयोग न करें! यह अविश्वसनीय है, उपयोगकर्ता VM और क्लस्टर के आउटेज और पुनरारंभ में अप्रत्याशित है, और अनुशंसित नहीं है।
• आपको AHV होस्ट पर NTP सर्वरों को मैन्युअल रूप से कॉन्फ़िगर करने की आवश्यकता नहीं है। प्रिज्म/ncli के माध्यम से NTP सर्वरों को कॉन्फ़िगर करने से CVMs और AHV होस्ट दोनों अपडेट होंगे।
• जब प्रिज्म वेब कंसोल या ncli का उपयोग करके ESXi-आधारित AOS क्लस्टर पर NTP सर्वर जोड़े जाते हैं, तो NTP सर्वर स्वचालित रूप से होस्ट की /etc/ntp.conf फ़ाइल में नहीं जोड़े जाते हैं। प्रिज्म में NTP सर्वर जोड़ने के बाद, आपको उन NTP सर्वरों को ESXi होस्ट पर भी मैन्युअल रूप से कॉन्फ़िगर करना होगा। ESXi होस्ट पर NTP सर्वरों को कॉन्फ़िगर करने के बारे में अधिक जानकारी के लिए, vSphere क्लाइंट का उपयोग करके ESX/ESXi होस्ट पर नेटवर्क टाइम प्रोटोकॉल (NTP) कॉन्फ़िगर करना (2012069) देखें।
• मिश्रित-हाइपरवाइजर क्लस्टर (AHV + ESXi) में, जैसा कि ऊपर उल्लेख किया गया है, AHV होस्ट प्रिज्म के माध्यम से कॉन्फ़िगर किए जाएंगे लेकिन आपको मिश्रित-हाइपरवाइजर क्लस्टर के ESXi होस्ट पर NTP सर्वरों को मैन्युअल रूप से कॉन्फ़िगर करना होगा।
• हाइपर-V क्लस्टर पर, check_ntp प्लगइन केवल CVM NTP कॉन्फ़िगरेशन को मान्य करता है। यह Windows हाइपर-V होस्ट के NTP या समय कॉन्फ़िगरेशन की जांच नहीं करता है, इसलिए यदि हाइपरवाइजर गलत कॉन्फ़िगर किया गया है या NTP स्रोतों और/या AD PDC के साथ समन्वयित नहीं है, तो चेक FAIL स्थिति का परिणाम नहीं देता है। मैन्युअल रूप से पुष्टि करें कि हाइपर-V होस्ट और डोमेन नियंत्रक एक स्वस्थ Windows समय पदानुक्रम रखते हैं। AD PDC(s) को CVMs के समानांतर विश्वसनीय अपस्ट्रीम NTP समय स्रोतों का उपयोग करना चाहिए, संभवतः वही NTP सर्वर (अगले बिंदु को देखें)।
• आदर्श रूप से, लॉग की तुलना को सरल बनाने और जटिल समय समन्वय समस्या की जांच से बचने के लिए, हाइपरवाइजर और कंट्रोलर VMs सभी को समान NTP सर्वरों का उपयोग करना चाहिए। यदि हाइपरवाइजर और कंट्रोलर VMs विभिन्न NTP सर्वरों का उपयोग कर रहे हैं, तो यह स्वास्थ्य जांच एक INFO आउटपुट उत्पन्न कर सकती है ताकि जागरूकता बढ़ सके और सुनिश्चित किया जा सके कि यह एक जानबूझकर और उचित कॉन्फ़िगरेशन है न कि एक आकस्मिक गलत कॉन्फ़िगरेशन और किसी अन्य अप्रासंगिक समस्या निवारण घटना के दौरान इस तथ्य को जल्दी से उजागर किया जा सके।

अधिक जानकारी और Nutanix क्लस्टर समय समन्वयन के सर्वोत्तम प्रथाओं के लिए, क्लस्टर समय समन्वयन को देखें प्रिज्म वेब कंसोल गाइड में Nutanix समर्थन पोर्टल पर।

विशिष्ट समस्या निवारण कदम

• यदि जांच रिपोर्ट करती है "INFO: हाइपरवाइजर x.x.x.x पर कॉन्फ़िगर किए गए NTP सर्वर Zeus कॉन्फ़िगरेशन x.x.x.x में कॉन्फ़िगर किए गए सर्वरों से भिन्न हैं", तो क्लस्टर और हाइपरवाइज़र्स पर समान NTP सर्वरों को कॉन्फ़िगर करें।
• यदि जांच रिपोर्ट करती है "FAIL: NTP नेता किसी बाहरी NTP सर्वर के साथ समन्वयित नहीं हो रहा है क्योंकि क्लस्टर का समय बाहरी NTP सर्वरों के सापेक्ष भविष्य में है: xxxx", तो क्लस्टर को मान्य NTP समन्वय स्थिति के बिना शुरू किया गया हो सकता है और CVM समय को पीछे खींचने से इन-फ्लाइट स्टोरेज मेटाडेटा संचालन पर प्रभाव पड़ सकता है। इस विशेष CVM समय की समस्या को हल करने के लिए, Nutanix समर्थन के साथ एक मामला लॉग करें और किसी भी CVM दिनांक/समय को मैन्युअल रूप से न बदलें।
• यदि जांच रिपोर्ट करती है "FAIL: NTP नेता किसी बाहरी NTP सर्वर के साथ समन्वयित नहीं हो रहा है", तो ऊपर दिए गए सामान्य समस्या निवारण कदम का पालन करें। यदि उपरोक्त कदम समस्या को हल नहीं करते हैं, तो Nutanix समर्थन के साथ एक मामला लॉग करें, परिणाम और सामान्य समस्या निवारण और वर्तमान क्लस्टर NTP कॉन्फ़िगरेशन से कोई भी आउटपुट प्रदान करें।
• यदि जांच रिपोर्ट करती है "FAIL: हाइपरवाइजर किसी NTP सर्वर के साथ समन्वयित नहीं हो रहा है", तो ऊपर दिए गए सामान्य समस्या निवारण कदम का पालन करें। यदि उपरोक्त कदम समस्या को हल नहीं करते हैं, तो नीचे दिए गए कदमों का पालन करें:
  1. होस्ट पर, ntpd सेवा को नीचे दिए गए ntpd सेवा को पुनः प्रारंभ करना प्रक्रिया का उपयोग करके पुनः प्रारंभ करें।
  2. जांचें कि क्या होस्ट अब NTP के साथ समय समन्वयित कर रहा है, नीचे दिए गए "ntpq -pn" कमांड के आउटपुट की समीक्षा करना प्रक्रिया का पालन करें। समन्वय के लिए ~10 मिनट प्रतीक्षा करना सुनिश्चित करें।
  3. यदि सभी होस्ट सही ढंग से समन्वयित नहीं हो रहे हैं, तो नीचे दिए गए ntp.conf फ़ाइल की सामग्री की समीक्षा करना प्रक्रिया का पालन करें।
  4. यदि समस्या अभी भी हल नहीं हुई है, तो Nutanix समर्थन से संपर्क करने पर विचार करें, परिणाम और सामान्य समस्या निवारण और वर्तमान क्लस्टर NTP कॉन्फ़िगरेशन से कोई भी आउटपुट प्रदान करें।
• यदि जांच रिपोर्ट करती है "FAIL: यह CVM NTP नेता है लेकिन किसी बाहरी NTP सर्वर के साथ समय समन्वयित नहीं हो रहा है" और आपने सत्यापित किया है कि NTP सर्वर सेट किया गया है:
  1. कॉन्फ़िगर किए गए NTP सर्वर(ों) पर अधिक लोड हो सकता है और/या जानबूझकर DDoS (अनजाने में या अन्यथा) से खुद को बचाने के लिए NTP क्लाइंट अनुरोधों की संख्या को सीमित कर रहा है, इसलिए CVM NTP नेता द्वारा वैध NTP अनुरोधों का उत्तर नहीं दे रहा है। आप CVM जेनिसिस सेवा लॉग फ़ाइल की जांच करके देख सकते हैं कि क्या आपका NTP सर्वर अनुरोधों को सीमित कर रहा है, जिसमें "सर्वर से दर सीमा प्रतिक्रिया" शामिल है:
     nutanix@cvm$ allssh "grep -A 1 -i 'rate limit' ~/data/logs/genesis.out | tail"
     ...
     2018-12-12 11:03:14 ERROR node_manager.py:3941 Systime update with ntpdate failed with error: 1: 12 Dec 11:03:14 ntpdate[26695]: n.n.n.101 rate limit response from server.
     2018-12-12 11:03:14 ntpdate[26695]: no server suitable for synchronization found
     1. यदि आप प्रभावित NTP सर्वर को नियंत्रित नहीं करते हैं, तो इसे प्रिज्म के NTP कॉन्फ़िगरेशन से हटा दें और एक अलग, अधिक विश्वसनीय NTP सर्वर जोड़ें।
     2. यदि आप स्रोत NTP सर्वर कॉन्फ़िगरेशन को नियंत्रित करते हैं, तो CVM/होस्ट IPs के लिए प्रतिबंध अपवाद जोड़ने पर विचार करें। विवरण के लिए अपने NTP सर्वर की अपनी दस्तावेज़ीकरण देखें। उदाहरण के लिए, एक Linux-आधारित ntpd सेवा पर, NTP सर्वर के /etc/ntp.conf फ़ाइल में निम्नलिखित पंक्ति जोड़ने की आवश्यकता होगी और फिर इसे फिर से लोड करें:
        restrict mask
  2. CVM समय NTP सर्वर समय से आगे हो सकता है, और CVM की जेनिसिस सेवा जानबूझकर NTP समन्वयन को रोक देगी। प्रभावित CVM के जेनिसिस लॉग में इस पर और सबूत मिल सकता है, निम्नलिखित कमांड चलाकर और CVM और NTP स्रोत के बीच नकारात्मक ऑफसेट की तलाश करके:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | tail"
     उदाहरण आउटपुट:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Querying upstream NTP servers: 10.x.x.11
     2019-02-03 22:42:12 INFO node_manager.py:2334 NTP offset: -89.328 seconds
     2019-02-03 22:42:12 INFO node_manager.py:2354 Time is ahead of external NTP server by 89.328 seconds, not syncing time while cluster services are running
     2019-02-03 22:42:12 INFO node_manager.py:2230 Restarting the NTP server.
     2019-02-03 23:02:13 ERROR node_manager.py:2450 External NTP still unusable (0)
     2019-02-03 23:02:13 WARNING node_manager.py:2456 Disabling upstream NTP servers
     2019-02-03 23:02:13 INFO node_manager.py:2202 Stopping the NTP server.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Restarting the NTP server.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Querying upstream NTP servers: 10.x.x.11
     2019-02-03 23:12:13 INFO node_manager.py:2334 NTP offset: -89.297 seconds
     
     उपरोक्त उदाहरण आउटपुट में, क्लस्टर एक नए जोड़े गए NTP सर्वर के साथ समन्वयित नहीं हो रहा है। इस स्थिति में, NTP सर्वर CVM से 89 सेकंड पीछे चल रहा है और इसलिए इसे NTP स्रोत के रूप में अनुपयोगी माना जाता है।
     महत्वपूर्ण: यदि CVM समय भविष्य में है, घड़ी को पीछे मैन्युअल रूप से सेट न करें! सहायता के लिए Nutanix समर्थन से संपर्क करें और उपरोक्त आउटपुट प्रदान करें।
• यदि जांच रिपोर्ट करती है "ERR: होस्ट पर ntpq चलाने में विफल": प्रत्येक CVM पर निम्नलिखित कमांड चलाएं और सुनिश्चित करें कि कमांड सफलतापूर्वक चलती है।
  nutanix@cvm$ ntpq -pn

  यदि कमांड चलाने में विफल रहता है या NCC जांच फिर से ERR स्थिति रिपोर्ट करती है, तो CVMs के लिए मुक्त मेमोरी की जांच करें। आगे की सहायता के लिए Nutanix समर्थन के साथ एक मामला लॉग करें।

"ntpq -pn" कमांड के आउटपुट की समीक्षा करना

कमांड 'ntpq -pn' इस जांच द्वारा CVM या होस्ट के NTP समन्वयन स्थिति की पहचान करने के लिए उपयोग की जाने वाली मुख्य कमांड है।

परिणामों की प्रत्येक पंक्ति का प्रारूप होगा: (केवल उदाहरण आउटपुट। वास्तविक IPs, NTP सर्वरों की पंक्तियाँ, और संबंधित मान व्यक्तिगत कॉन्फ़िगरेशन के आधार पर भिन्न होंगे)

जहाँ remote वह दूरस्थ साथी या सर्वर है जिसके साथ समन्वयित किया जा रहा है। “127.127.1.0 LOCL” यह स्थानीय होस्ट है (यदि कोई दूरस्थ साथी या सर्वर उपलब्ध नहीं है तो शामिल किया गया)।

तालिका में प्रदर्शित पहला अक्षर एक स्थिति ध्वज है। एक समन्वयित स्थिति, जो एक दूरस्थ NTP सर्वर प्रविष्टि के पहले अक्षर के रूप में '*' द्वारा दर्शाई जाती है, अपेक्षित है।

नोट: यदि NTP नेता भूमिका के साथ जेनिसिस सेवा हाल ही में बदल गई है या NTP सर्वर कॉन्फ़िगरेशन में संशोधन किया गया है, तो इस समन्वयित स्थिति को होने में 10-15 मिनट लगते हैं।

1. सभी CVMs पर NTP स्थिति की जांच करने के लिए, एक CVM से निम्नलिखित कमांड चलाएं:
   nutanix@cvm$ allssh ntpq -pn
   निम्नलिखित उदाहरण एक अच्छा परिणाम है - यह दिखा रहा है कि CVM NTP नेता एक बाहरी NTP सर्वर के साथ समन्वयित है और अन्य CVMs CVM NTP नेता के साथ समन्वयित हैं।
   ================== 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 <--- एक कॉन्फ़िगर किए गए 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 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 <--- CVM NTP नेता 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 <--- CVM NTP नेता 10.xx.xx.61 के साथ समन्वयित
   
   नीचे एक समस्याग्रस्त परिणाम का उदाहरण है। CVM NTP नेता केवल अपनी स्थानीय घड़ी के साथ समन्वयित है:
   ================== 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 नेता केवल अपनी स्थानीय घड़ी के साथ समन्वयित
   ================== 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 <--- CVM NTP नेता 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 <--- CVM NTP नेता 10.xx.xx.61 के साथ समन्वयित
   
   यदि IP '127.127.1.0' का उपयोग किया जा रहा है, तो इसका अर्थ है कि CVMs केवल NTP नेता के साथ समन्वयित हो रहे हैं ('127.127.1.0' एक लोकलहोस्ट IP है) और यह जांच किए जाने के समय किसी बाहरी NTP सर्वर के साथ समन्वयित नहीं हो रहा है।
2. सभी होस्ट/हाइपरवाइज़र्स पर NTP स्थिति की जांच करने के लिए, एक CVM से निम्नलिखित कमांड चलाएं:
   nutanix@cvm$ hostssh ntpq -pn
   
   निम्नलिखित उदाहरण एक अच्छा परिणाम है। सभी होस्ट समान NTP सर्वरों के साथ समन्वयित हैं।
   ============= 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
   यदि NTP IP पते सभी होस्टों में लगातार समान नहीं हैं, तो जांचें /etc/ntp.conf यदि वे एक होस्टनेम/FQDN का उपयोग कर रहे हैं जो NTP सर्वरों के एक पूल का प्रतिनिधित्व करता है। NTP पूल बहुत सारे राउंड-रॉबिन DNS प्रविष्टियों से बने होते हैं, इसलिए प्रारंभिक समय में, DNS प्रतिक्रिया जो प्रत्येक होस्ट को NTP सेवा शुरू करते समय दी जाती है, एक अलग IP पता वापस कर सकती है जिसका उपयोग NTP सर्वर के रूप में किया जा सकता है।
3. यदि आप AHV होस्ट पर ntpq चलाते समय निम्नलिखित संदेश देखते हैं:
   कोई संघ ID वापस नहीं आया
   
   पुष्टि करें कि आप AHV el6 कर्नेल चला रहे हैं, निम्नलिखित कमांड चलाकर:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   यदि आप el6 कर्नेल पर चल रहे हैं, तो आपको नीचे दिए गए समान आउटपुट दिखाई देगा:
   el6.nutanix.20170830.151
   इस समस्या को अस्थायी रूप से ठीक करने के लिए (कार्यaround), होस्ट पर ntpd सेवा को नीचे दिए गए ntpd सेवा को पुनः प्रारंभ करना प्रक्रिया का उपयोग करके पुनः प्रारंभ करें, फिर इस NCC जांच को फिर से चलाएं।

   इस समस्या को स्थायी रूप से ठीक करने के लिए, AOS को 5.5.8, 5.9.2, 5.10 या बाद के संस्करण में अपग्रेड करें।

4. यदि आप ESXi होस्ट पर ntpq चलाते समय निम्नलिखित संदेश देखते हैं, तो इसका अर्थ है कि ESXi/ESX होस्ट कॉन्फ़िगर किए गए NTP सर्वर तक नहीं पहुँच सकता:
   कोई संघ ID वापस नहीं आया
   सभी होस्टों पर समय सही और समान है या नहीं, इसकी पुष्टि करें hostssh date कमांड के साथ।

   पुष्टि करें कि NTP सर्वर IPs होस्ट पर /etc/ntp.conf. में कॉन्फ़िगर किए गए हैं।

   नीचे दिए गए कमांड के साथ यह पुष्टि करें कि होस्ट पर DNS सर्वर कॉन्फ़िगरेशन सही है:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli network ip dns server list >>> एकल होस्ट पर जांचने के लिए
   nutanix@cvm$ hostssh "esxcli network ip dns server list" >>> सभी होस्ट पर जांचने के लिए
   
   इसे हल करने के लिए, निम्नलिखित कमांड के साथ DNS सर्वर कॉन्फ़िगरेशन को सही करें। वैकल्पिक रूप से, Center में सही DNS कॉन्फ़िगरेशन जोड़ें:
   [root@Esxi:~]esxcli network ip dns server add --server=
5. यदि आप ntpq चलाते समय AHV होस्ट पर निम्नलिखित संदेश देखते हैं:
   नाम या सेवा ज्ञात नहीं है
   यह समस्या ntpq कमांड द्वारा "localhost" को 127.0.0.1 में हल करने में असमर्थता के कारण हो सकती है।

   इस समस्या को ठीक करने के लिए, Nutanix Support के साथ एक केस लॉग करें जिसमें सामान्य समस्या निवारण और वर्तमान होस्ट NTP कॉन्फ़िगरेशन से परिणाम और कोई आउटपुट प्रदान करें।

6. जब आप PCVM पर ntpq -pn चलाते हैं, तो आप निम्नलिखित प्रकार का आउटपुट देख सकते हैं:
   nutanix@PCVM:~$ ntpq -pn
   दूरस्थ refid st t कब पोल पहुंचें देरी ऑफसेट जिटर
   ==============================================================================
   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:~$
   ntpq कमांड के बारे में अधिक जानकारी के लिए, ntpq मैन पेज देखें।

ntp.conf फ़ाइल की सामग्री की समीक्षा करना

1. ntpq -pn कमांड के आउटपुट की समीक्षा करें जो ऊपर दिए गए प्रक्रिया का उपयोग करके।
2. यदि सभी AHV या ESXi होस्ट NTP के साथ समय समन्वयित नहीं हो रहे हैं, तो सभी होस्ट के /etc/ntp.conf फ़ाइलों की जांच करें।

   नीचे एक नमूना आउटपुट है जहां केवल 3 होस्ट में से 2 सफलतापूर्वक NTP के साथ समन्वयित हो रहे हैं।

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   restrict default kod nomodify notrap nopeer noquery
   restrict 127.0.0.1
   server 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   restrict default kod nomodify notrap nopeer noquery
   restrict 127.0.0.1
   server 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   tinker panic 0
   server 10.xx.xx.8
   driftfile /var/lib/ntp/drift
   logfile /var/log/ntp.log
   restrict 10.8.x.x mask 255.255.255.0 nomodify notrap
   interface ignore wildcard
   interface listen br0
   restrict 127.0.0.1
   restrict -6 ::1
   restrict default kod nomodify notrap nopeer noquery
   restrict -6 default kod nomodify notrap nopeer noquery
   disable monitor
   उपरोक्त नमूना कॉन्फ़िगरेशन में, होस्ट 10.xx.xx.1 और 10.1xx.xx.2 सफलतापूर्वक NTP के साथ समन्वयित हो रहे हैं जबकि 10.xx.xx.3 असफल हो रहा है क्योंकि यह NTP समन्वय को प्रतिबंधित कर रहा है।
3. इसे हल करने के लिए, ऊपर दिए गए सामान्य समस्या निवारण चरणों का पालन करें। ध्यान दें कि AHV होस्ट भी Prism के माध्यम से CVMs के साथ कॉन्फ़िगर किए गए हैं।
4. यदि अस्थायी अपस्ट्रीम NTP या कनेक्टिविटी समस्या है, तो नीचे दिए गए प्रक्रिया का उपयोग करके ntpd सेवा को पुनः प्रारंभ करें।
5. 5-10 मिनट प्रतीक्षा करें और CVMs में से एक से निम्नलिखित कमांड चलाएं यह जांचने के लिए कि क्या सभी हाइपरविज़र्स अब NTP सर्वर के साथ समन्वयित हो रहे हैं:
   nutanix@cvm$ hostssh ntpq -pn
6. फिर से NCC जांच चलाएं।
7. यदि उपरोक्त चरण समस्या को हल नहीं करते हैं, तो Nutanix Support के साथ एक केस लॉग करें, जिसमें सामान्य समस्या निवारण और वर्तमान क्लस्टर NTP कॉन्फ़िगरेशन से परिणाम और कोई आउटपुट प्रदान करें।

   नोट: ESXi पर, "interface listen br0" का /etc/ntp.conf में सूचीबद्ध होना उपरोक्त समस्या का कारण बनता है। इस पंक्ति को हटा दिया जाना चाहिए और ntpd सेवा को पुनः प्रारंभ किया जाना चाहिए।

ntpd/w32time सेवा को पुनः प्रारंभ करना

AHV el6 या ESXi पर, चलाएँ:

AHV el7 पर चलाएँ:

यह जांचने के लिए कि AHV संस्करण जो स्थापित है वह el6 या el7 परिवार से संबंधित है, कमांड का उपयोग करें:

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

Hyper-V पर, चलाएँ:

Hyper-V पर NTP कॉन्फ़िगर करना

Hyper-V 2016 होस्ट डोमेन कंट्रोलर को NTP के रूप में उपयोग करते हैं। सक्रिय निर्देशिका डोमेन कंट्रोलर पर बाहरी NTP स्रोतों को कॉन्फ़िगर करने के लिए:

1. DC पर प्रशासनिक अनुमतियों के साथ एक कमांड प्रॉम्प्ट खोलें।
2. समय सेवा को रोकें:
   C:\> net stop w32time
3. मैनुअल पीयर सूची बाहरी सर्वरों को सेट करें:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. कनेक्शन को विश्वसनीय के रूप में सेट करें:
   C:\> w32tm /config /reliable:yes
5. समय सेवा को फिर से शुरू करें:
   C:\> net start w32time
6. कॉन्फ़िगरेशन का परीक्षण करें:
   C:\> w32tm /query /configuration और w32tm /query /status

अतिरिक्त जानकारी

• Nutanix KB 4519 - Nutanix पोर्टल में मूल दस्तावेज़