मैंने कई बार पढ़ा है (हालांकि मैं अभी इसे नहीं ढूँढ सकता) कि डेटा सेंटर यह सुनिश्चित करने के लिए बहुत प्रयास करते हैं कि सभी सर्वर का समय एक ही हो। सहित, लेकिन लीप सेकंड के बारे में चिंता करने के लिए सीमित नहीं है।
यह इतना महत्वपूर्ण क्यों है कि सर्वरों का समय समान है? और वास्तविक सहिष्णुता क्या हैं?
जवाबों:
सामान्य तौर पर, पुनरावृत्ति के हमलों को रोकने में मदद करने के लिए विभिन्न प्रमाणीकरण प्रोटोकॉल में टाइमस्टैम्प्स का उपयोग किया जाता है , जहां एक हमलावर एक प्रमाणीकरण टोकन का पुन: उपयोग कर सकता है जो वह चोरी करने में सक्षम था (जैसे नेटवर्क को सूँघकर)।
उदाहरण के लिए, Kerberos प्रमाणीकरण ठीक यही करता है। विंडोज में उपयोग किए जाने वाले केर्बरोस के संस्करण में, डिफ़ॉल्ट सहिष्णुता 5 मिनट है।
इसका उपयोग दो-कारक प्रमाणीकरण जैसे कि Google प्रमाणक, RSA SecurID, आदि के लिए उपयोग किए जाने वाले विभिन्न वन-टाइम पासवर्ड प्रोटोकॉल द्वारा भी किया जाता है। इन मामलों में सहिष्णुता आमतौर पर 30-60 सेकंड के आसपास होती है।
क्लाइंट और सर्वर के बीच समयांतराल के बिना, प्रमाणीकरण को पूरा करना संभव नहीं होगा। (यह प्रतिबंध MIT कर्बरोस के नवीनतम संस्करणों में हटा दिया गया है, जो कि आवश्यक होने के बाद और KDC प्रमाणीकरण के दौरान अपनी घड़ियों के बीच ऑफसेट का निर्धारण करता है, लेकिन ये परिवर्तन Windows Server 2012 R2 के बाद हुए हैं और इसे Windows में देखने से पहले आपको थोड़ी देर हो जाएगी संस्करण। लेकिन 2FA के कुछ कार्यान्वयनों को हमेशा सिंक्रनाइज़ घड़ियों की आवश्यकता होगी।)
सिंक में घड़ियां होने से विषम प्रणालियों के साथ काम करना आसान हो जाता है। उदाहरण के लिए, एकाधिक सर्वरों से लॉग प्रविष्टियों को सहसंबंधित करना बहुत आसान है यदि सभी प्रणालियों का समय समान हो। इन मामलों में आप आमतौर पर 1 सेकंड की सहिष्णुता के साथ काम कर सकते हैं, जो एनटीपी प्रदान करेगा, लेकिन आदर्श रूप से आप चाहते हैं कि जितनी बार आप इसे बर्दाश्त कर सकें। PTP, जो बहुत तंग सहिष्णुता प्रदान करता है, लागू करने के लिए बहुत अधिक महंगा हो सकता है।
makeक्लायंट / सर्वर NFS के बीच क्लॉक स्क्यू से भी भ्रमित हो जाता है।
मुख्य रूप से, यह इतना है कि आप विभिन्न उपकरणों पर लॉग से घटनाओं को सहसंबंधित कर सकते हैं। मान लीजिए कि आपके पास एक सुरक्षा घटना है, जहां कोई आपके डेटाबेस को आपके वेब सर्वर के माध्यम से एक्सेस करता है - आप चाहते हैं कि आपके फ़ायरवॉल पर टाइमस्टैम्प, आपका लोड बैलेंसर, आपका वेब सर्वर और आपका डेटाबेस सर्वर सभी से मेल खाए ताकि आप प्रत्येक डिवाइस पर लॉग ढूंढ सकें वह घटना से संबंधित है। आदर्श रूप से, आप कुछ मिलीसेकंड के भीतर सब कुछ पसंद करेंगे। और इसे वास्तविक बाहरी समय के साथ सिंक करने की आवश्यकता है, ताकि आप अपने लॉग को तीसरे पक्ष के लॉग के साथ सहसंबंधित कर सकें, यदि वह आवश्यक हो।
न केवल प्रशासन के दृष्टिकोण से यह महत्वपूर्ण है, बल्कि सिंक में घड़ियां होना भी आवेदन स्तर के सहसंबंध से महत्वपूर्ण है। यह इस बात पर निर्भर करता है कि समाधान कैसे तैयार किया गया है, कैसे चल रहे अनुप्रयोगों को किसी भी लेनदेन के लिए अपना टाइमस्टैम्प प्राप्त होता है, जिसके साथ वे काम कर सकते हैं। मैंने लेन-देन सत्यापन को किसी अन्य के मुकाबले बहुत अधिक ऑफसेट (भविष्य में 20 सेकंड के बारे में) के साथ सर्वर पर चलने के कारण विफल देखा है।
इसके अलावा, उदाहरण के लिए VMWare ESXi सर्वर पर वर्चुअलाइजेशन और VM का समय हाइपरविजर के साथ सिंक में नहीं है, तो वीएमओएन जैसी क्रिया हाइपरवेर्स के साथ VM घड़ी को फिर से सिंक कर सकती है और इससे बदले में अप्रत्याशित परिणाम हो सकते हैं। अगर समय का अंतर काफी बड़ा है।
मुझे नहीं पता कि कोई भी वास्तविक सहिष्णुता क्या है, क्योंकि मुझे लगता है कि यह इस बात पर बहुत निर्भर करता है कि किस प्रकार के सिस्टम हैं, लेकिन मुझे लगता है कि आम तौर पर बोलते हुए सर्वर को डेटासेंटर में एक सेकंड से कम समय के लिए एक दूसरे के बीच ऑफसेट रखना संभव है।
चूंकि आपने लीप सेकंड का उल्लेख किया है, इसलिए यह ध्यान दिया जाना चाहिए कि उन्हें विशेष रूप से कठिन हैंडलिंग की आवश्यकता होती है।
वे आमतौर पर 23:59:60 के रूप में एक दूसरे को इंजेक्ट करके जोड़ते हैं, यह समस्याग्रस्त है यदि आप मिनट और सेकंड फ़ील्ड के लिए 0-59 के रूप में टाइमस्टैम्प को मान्य कर रहे हैं। इसे 2 सेकंड लंबा करने के लिए 23:59:59 दोहराए जाने का विकल्प बहुत बेहतर नहीं है क्योंकि यह उस चीज के साथ गड़बड़ करेगा जो प्रति सेकंड के स्तर के प्रति संवेदनशील है।
Google वास्तव में कुछ समय पहले एक अच्छे समाधान के साथ आया था जो लगता है कि व्यापक रूप से अभी तक अपनाया नहीं गया है। उनका समाधान एक लीप "स्मीयर" लागू करना और समय की अवधि में परिवर्तन को विभाजित करना था, पूरी प्रक्रिया एक एनटीपी सर्वर द्वारा प्रबंधित की जा रही थी। उन्होंने 2011 में इसके बारे में एक ब्लॉग प्रकाशित किया , दिलचस्प पढ़ने के लिए बनाता है और इस प्रश्न के लिए प्रासंगिक लगता है।
मैं उपरोक्त सभी बिंदुओं से सहमत हूं। मैं अधिक विचार फेंकना चाहता हूं
कुछ डेटाबेस जैसे कि कैसेंद्र समय की मुहर पर बहुत अधिक भरोसा करते हैं । यही तरीका है कि यह संगामिति से निपटता है।
अलग-अलग टाइमस्टैम्प डेटाबेस में समान रूप से गड़बड़ करेंगे।