क्या कोई ऐसा तरीका है जो DNS प्रोटोकॉल स्वाभाविक रूप से बैकअप ए रिकॉर्ड सर्वर एड्रेस, जैसे बैकअप नाम सर्वर या मेल सर्वर रिकॉर्ड को पकड़ सकता है? इसके लिए खोज करते समय मैंने केवल बैकअप नेमसर्वर (एनएस रिकॉर्ड) पर परिणाम देखे।
यदि DNS के लिए बैकअप ए रिकॉर्ड्स का समर्थन करने का कोई तरीका नहीं है, तो परिणामों को अनुकरण करने का सबसे अच्छा तरीका क्या है ताकि उपयोगकर्ताओं को कार्यशील सर्वर पर निर्देशित किया जा सके अगर प्राथमिक सर्वर जवाब नहीं दे रहा है?
जवाबों:
हाँ ... की तरह।
यहां आप दो काम कर सकते हैं: यदि आप किसी दिए गए नाम के लिए अपने DNS सर्वर में एकाधिक ए रिकॉर्ड डालते हैं, तो वे सभी ग्राहकों को दिए जाएंगे और उन ग्राहकों को कनेक्ट करने के लिए सेट से एक उठाएगा, जिसका अर्थ है कि ट्रैफ़िक होगा "निष्पक्ष" समान रूप से सभी साइटों के बीच समान रूप से वितरित किया जाए। यह वास्तव में ऐसा नहीं है जो आप वर्णन करते हुए प्रतीत होते हैं, लेकिन यह एक सामान्य स्थिति है (हालांकि मैं कई कारणों से इस पर भरोसा नहीं करता हूं)।
दूसरा विकल्प यह है कि आप अपने DNS सर्वर में केवल एक A रिकॉर्ड रखते हैं, और DNS सर्वर (या इसके बारे में कोई सूचना देने वाला स्क्रिप्ट की तरह) आपकी साइट के मुख्य पते पर नजर रखता है, और यदि यह विफल रहता है तो DNS सर्वर का A रिकॉर्ड आपकी दूसरी साइट में बदल जाता है। इसका मतलब है कि एक समय में केवल एक साइट पर ट्रैफ़िक हो रहा होगा।
इस दूसरी रणनीति के नकारात्मक पक्ष डीएनएस कैशिंग है। जिस किसी को भी पुरानी साइट का पता मिला है, वह तब तक SOL रहेगा जब तक कि पुराने पते वाले DNS कैश एंट्रीज से पर्स नहीं मिल जाता। इसका मतलब यह है कि आपको अपने टीटीएल को कम रखना होगा (अपने DNS इन्फ्रास्ट्रक्चर पर लोड बढ़ाना, हालांकि यह शायद ही कभी एक व्यावहारिक समस्या है), लेकिन अभी भी "दुष्ट" डीएनएस कैश की समस्या है, जो टीटीएल का सम्मान नहीं करते हैं। ये किसी के लिए एक बड़े पैमाने पर दर्द हैं जिन्हें कभी भी डीएनएस प्रविष्टियाँ बदलनी पड़ती हैं, लेकिन वे उन लाखों लोगों के लिए बदतर होते हैं जिन्हें डीएनएस प्रविष्टियों को "अक्सर" बदलने की आवश्यकता होती है (उम्मीद है कि आपकी साइट दिन में कई बार नीचे नहीं जा रही है, लेकिन अभी भी ...) मूल रूप से, कोई भी इन दुर्व्यवहार DNS कैश में से एक के पीछे आपकी साइट को अत्यधिक विस्तारित अवधि के लिए "डाउन" के रूप में देखा जाएगा, और बस उन्हें यह समझाने की कोशिश करें कि यह उनका DNS कैश है जो गलती पर है ... Eugh।
संक्षेप में, मैं इसे किसी साइट के लिए नहीं करूंगा, क्योंकि आप जो भी जोखिम के बारे में सोच रहे हैं उसे कम करने के लिए बेहतर तरीके हैं, लेकिन आपको उस जोखिम का वर्णन करना होगा यदि आप इसे कम करने के बारे में सुझाव चाहते हैं।
सभी को लगता है कि आप डब्ल्यूडब्ल्यूडब्ल्यू सर्वरों के बारे में बात कर रहे हैं, भले ही आपने स्पष्ट रूप से लिखा हो
सत्य-अनदेखा सच यह है कि HTTP सेवा अपवाद है और जब यह इस पर आता है तो आदर्श नहीं। सामान्य स्थिति में, हाँ, वहाँ है इतना है कि वे ठीक से वापस आने प्राथमिक सर्वर से बैकअप सर्वर के लिए DNS के माध्यम से ग्राहकों को जानकारी प्रकाशित करने के लिए एक तंत्र। वह तंत्रएक बैकअप नाम-सर्वर या मेल सर्वर की तरह
SRVसंसाधन रिकॉर्ड है, जो HTTP के अलावा कई अन्य प्रोटोकॉल के लिए सेवा ग्राहकों द्वारा उपयोग किया जाता है । आरएफसी 2782 देखें।
SRVसंसाधन रिकॉर्ड के साथ , ग्राहकों को प्राथमिकताओं और वजन के साथ सर्वरों की एक सूची बताई जाती है, और प्राथमिकता के क्रम में सर्वरों की कोशिश करने की आवश्यकता होती है, सर्वरों के बीच वजन के अनुसार समान प्राथमिकताओं को चुनना, उच्च-भारित सर्वरों को कम-भारित से अधिक बार चुनना। लोगों को। इसलिए SRVसंसाधन रिकॉर्ड के साथ , सर्वर प्रशासक क्लाइंट को बता सकते हैं कि फॉलबैक सर्वर क्या हैं, और समान-प्राथमिकता वाले सर्वरों के सेट पर उनके भार को कैसे वितरित किया जाए।
अब सामग्री DNS सर्वर अपने स्वयं के संसाधन रिकॉर्ड के एक विशेष प्रकार के संसाधन द्वारा स्थित हैं NS, जिसमें प्राथमिकता और वजन की जानकारी नहीं है। समान रूप से, SMTP रिले सर्वर अपने स्वयं के विशेष प्रकार के संसाधन रिकॉर्ड द्वारा स्थित होते हैं MX, जिसमें प्राथमिकता की जानकारी होती है, लेकिन कोई भारित जानकारी नहीं होती है। इसलिए कंटेंट DNS सर्वर के लिए फॉलबैक और लोड वितरण जानकारी प्रकाशित करने का कोई प्रावधान नहीं है; और यदि कोई MXसंसाधन रिकॉर्ड का उपयोग कर रहा है तो SMTP रिले सर्वर के लिए लोड वितरण जानकारी प्रकाशित करने का कोई प्रावधान नहीं है।
हालाँकि, SRV-capable MTSes अब मौजूद हैं। (पहला था exim, जो SRV2005 के बाद से-योग्य है।) और अन्य सेवा प्रोटोकॉल के लिए, के सामान MXऔर NSसंसाधन रिकॉर्ड के साथ अप्रभावित , SRVगोद लेना कहीं अधिक गहन और व्यापक है। यदि आपके पास Microsoft Windows डोमेन है, उदाहरण के लिए, तो DNS में लुकअप के माध्यम से सेवाओं की एक पूरी बेड़ा स्थित हैSRV । इस बिंदु पर, एक दशक से अधिक समय से यही स्थिति है।
समस्या यह है कि हर कोई HTTP के बारे में सोचता है, जब HTTP अब तक है, आजकल 2011 में, अपवाद और नियम यहां नहीं है।
SRVरिकॉर्ड सेवाओं का पता लगाने का एक परिभाषित तरीका है। यह भी ध्यान दें कि सवाल यह था कि क्या तंत्र मौजूद है और यह क्या था। तंत्र मौजूद है, और यह तंत्र है। यह एक दशक से व्यापक उपयोग में है।
यदि आप गतिशील सामग्री परोस रहे हैं और यह केवल दो सर्वरों को एक साथ सामग्री देने के लिए व्यावहारिक नहीं है, तो आपका अन्य विकल्प वैसे भी आपके DNS पर कई रिकॉर्ड हैं और बैकअप सर्वर को कॉन्फ़िगर करने के लिए ICMP पोर्ट को उन ग्राहकों के लिए उपलब्ध नहीं है जो कोशिश करते हैं और इसे कनेक्ट करते हैं ; यदि किसी भी बिंदु पर मुख्य सर्वर नीचे चला जाता है, तो आप बस पोर्ट 80 को बैकअप पर हटा दें और ट्रैफ़िक अंदर आना शुरू हो जाएगा।
केवल दूसरे (बजट) तरीके से आप इसे करने में सक्षम होने जा रहे हैं, NAT पर अनुरोध करने के लिए एक अलग मशीन (या दो) सेटअप है, इस प्रकार यदि कोई वेबसर्वर मर जाता है, तो आप बस इसके लिए NAT नियम हटा सकते हैं।
कोई बैकअप ए रिकॉर्ड नहीं हैं, लेकिन कई ए रिकॉर्ड हो सकते हैं जो यादृच्छिक क्रम में दिए गए हैं।
यदि कोई विफल रहता है, तो अधिकांश ब्राउज़र दूसरे सर्वर को आज़माने में सक्षम होते हैं। (देखें: राउंड रोबिन DNS के साथ वेब लचीलापन )
आप एक क्लस्टर आईपी पते के साथ कई सर्वरों का समर्थन प्राप्त हो सकता है VRRP या कार्प । जब प्राथमिक सर्वर विफल हो जाता है तो बैकअप सर्वर पते को संभाल लेता है।
यह एक काफी पुराना प्रश्न है, लेकिन दो महत्वपूर्ण तकनीकों को उत्तर में नहीं लाया गया है: डायनेमिक डीएनएस और सीडीएन।
डायनेमिक DNS को सेट किया गया है ताकि DNS रिकॉर्ड को लगभग वास्तविक समय में संशोधित किया जा सके, इसलिए एक मॉनिटरिंग क्लाइंट सार्वजनिक DNS ए रिकॉर्ड में परिवर्तन को ट्रिगर कर सकता है क्योंकि सेवा की उपलब्धता निर्धारित होती है। (बेशक, आपकी DNS होस्टिंग सेवा को गतिशील DNS का समर्थन करना चाहिए।)
CDNs का उपयोग DNS देने के लिए भी किया जा सकता है, उदाहरण के लिए Cloudflare करता है (जो 2010 में लॉन्च हुआ था, मुझे विश्वास है)।