जब DNS सर्वर विफल रहता है तो DNS टाइमआउट से बचना

Question

हमारे पास एक छोटा डेटाकैटर है जिसमें लगभग 3 होस्ट्स हैं जो 3 आंतरिक डीएनएस सर्वर (9 बाइंड) की ओर इशारा करते हैं। हमारी समस्या तब आती है जब आंतरिक डीएनएस सर्वरों में से एक अनुपलब्ध हो जाता है। उस बिंदु पर उस सर्वर को इंगित करने वाले सभी क्लाइंट बहुत धीमी गति से प्रदर्शन करना शुरू करते हैं।

समस्या यह प्रतीत होती है कि स्टॉक लिनक्स रिसॉल्वर के पास वास्तव में एक अलग डीएनएस सर्वर के लिए "विफल होने" की अवधारणा नहीं है। आप उपयोग किए जाने वाले रिट्रीट के टाइमआउट और संख्या को समायोजित कर सकते हैं, (और घुमाएँ सेट करें ताकि यह सूची के माध्यम से काम करेगा), लेकिन कोई फर्क नहीं पड़ता कि कौन सी सेटिंग्स हमारी सेवाओं का उपयोग करती है यदि प्राथमिक dns सर्वर अनुपलब्ध हो तो बहुत अधिक धीरे-धीरे प्रदर्शन करें। फिलहाल यह हमारे लिए सेवा अवरोधों के सबसे बड़े स्रोतों में से एक है।

मेरा आदर्श उत्तर कुछ इस तरह होगा "RTFM: tweak /etc/resolv.conf इस तरह ...", लेकिन अगर यह एक विकल्प है, तो मैंने इसे नहीं देखा है।

मैं सोच रहा था कि अन्य लोगों ने इस मुद्दे को कैसे संभाला?

मैं 3 संभावित प्रकार के समाधान देख सकता हूं:

• Linux-ha / Pacemaker और failover ips का उपयोग करें (ताकि dns IP VIPs हमेशा "उपलब्ध" रहें)। काश, हमारे पास एक अच्छी बाड़ लगाने की अवसंरचना नहीं होती, और बाड़ लगाने के बिना पेसमेकर बहुत अच्छी तरह से काम नहीं करता (मेरे अनुभव में पेसमेकर बाड़ के बिना उपलब्धता कम करता है)।

• प्रत्येक नोड पर एक स्थानीय डीएनएस सर्वर चलाएं, और स्थानीयहोस्ट को resolv.conf बिंदु दें। यह काम करेगा, लेकिन यह हमें निगरानी और प्रबंधन के लिए बहुत अधिक सेवाएं प्रदान करेगा।

• प्रत्येक नोड पर एक स्थानीय कैश चलाएँ। फोल्क्स ने nscd को "टूटा हुआ" माना, लेकिन लगता है कि dnrd में सही फीचर सेट है: यह dns सर्वर को ऊपर या नीचे के रूप में चिह्नित करता है, और 'down' dns सर्वर का उपयोग नहीं करेगा।

कोई भी कास्टिंग केवल आईपी रूटिंग स्तर पर काम करती है, और सर्वर विफलता के लिए मार्ग अपडेट पर निर्भर करती है। मल्टी-कास्टिंग ऐसा लग रहा था कि यह एक सटीक उत्तर होगा, लेकिन बाइंड प्रसारण या मल्टी-कास्टिंग का समर्थन नहीं करता है, और डॉक्स मुझे यह प्रतीत होता है कि मल्टीकास्ट डीएनएस सेवा खोज और ऑटो-कॉन्फ़िगरेशन के बजाय नियमित रूप से मरने के उद्देश्य से है। ।

क्या मुझे एक स्पष्ट समाधान याद आ रहा है?

Comments

मेरा सुझाव है कि आप जिस समाधान के लिए पूछ रहे हैं (जो मैं आपकी मदद नहीं कर सकता) खोजने के अलावा, आपको वास्तविक रूट समस्या पर काम करना चाहिए और डीएनएस सर्वर के साथ विश्वसनीयता के मुद्दों को ठीक करना चाहिए।

— जॉन गार्डनियर्स

मूल समस्या यह है कि ये DNS सर्वर आपको इस बारे में परेशान करने के लिए इतनी बार क्यों नीचे जाते हैं? BuddyNS जैसी विशेष सेवाओं के साथ अपने DNS की प्रतिकृति बनाने पर विचार करें । आपकी विलंबता नाटकीय रूप से कम हो जाएगी और अपटाइम आपको /etc/resolv.conf के बारे में परेशान नहीं करेगा।

— मिशेल

Answer 1

विकल्पों की एक जोड़ी। दोनों आपके DNS सर्वर पर DNS लोड वितरित करेंगे।

• options rotateResolv.conf में उपयोग करने का प्रयास करें । यह प्राथमिक सर्वर के प्रभाव को कम करेगा। यदि अन्य सर्वरों में से एक नीचे है, तो यह क्रियाओं को धीमा कर देगा।
• अलग-अलग क्लाइंट पर अलग नेमसेवर ऑर्डर का उपयोग करें। यह कुछ क्लाइंट को सामान्य रूप से चलाने की अनुमति देगा यदि प्राथमिक DNS सर्वर डाउन है। यह आउट ऑफ़ सर्विस DNS सर्वर के इर्द-गिर्द फैलता है।

इन विकल्पों के साथ जोड़ा जा सकता है options timeout:1 attempts:5। यदि आप टाइमआउट कम करते हैं तो प्रयास बढ़ाएँ ताकि आप धीमे बाहरी सर्वरों को संभाल सकें।

आपके राउटर कॉन्फ़िगरेशन के आधार पर आप प्राथमिक DNS सर्वर के आईपी पते को डाउन करने के लिए अपने DNS सर्वर को कॉन्फ़िगर करने में सक्षम हो सकते हैं। यह उपरोक्त तकनीकों के साथ जोड़ा जा सकता है।

नोट: मैं वर्षों तक बिना शेड्यूल किए गए DNS आउटेज के बिना चलता हूं। जैसा कि अन्य ने उल्लेख किया है, मैं DNS सर्वरों को विफल करने वाले मुद्दों को हल करने पर काम करूंगा। उपरोक्त चरण, अनुपलब्ध नाम सर्वरों को निर्दिष्ट करने के साथ गलत DNS सर्वरों के साथ भी मदद करते हैं।

Answer 2

"आदमी resolv.conf" की जाँच करें। आप resolv.conf में टाइमआउट विकल्प जोड़ सकते हैं। डिफ़ॉल्ट 5 है, लेकिन resolv.conf में निम्न जोड़कर इसे 1 सेकंड तक नीचे लाना चाहिए:

विकल्प टाइमआउट: 1

Comments

आपके दूसरे पैराग्राफ को फिर से तैयार करने के बाद, मैंने ऊपर एक सेंटोस और डेबियन वीपीएस पर कोशिश की है। प्राथमिक डीएनएस को नीचे लाने के बाद, रिज़ॉल्वर ने उम्मीद के मुताबिक प्रदर्शन किया। एक tcpdump चलाने पर, मैं रिज़ॉल्वर को पहले सर्वर को आज़माता हुआ भी देख सकता था, और फिर अगले प्रयास कर रहा था। आप क्या व्यवहार देख रहे हैं?

— नियाल डोनेगन

हल करने के लिए दो बड़े उपयोग के मामले हैं: अल्पकालिक प्रक्रियाएं (जैसे कमांड लाइन टूल्स) और लंबे समय तक जीवित प्रक्रियाएं, और एक ही रिज़ॉल्वर कॉन्फ़िगरेशन दोनों के लिए काम करना है। अल्पकालिक (एकल खोज) के लिए एक छोटी समयावधि सेट करना जल्दी से विफल हो जाएगा। लेकिन अगर आप एक बाहरी पता देख रहे हैं जो उस समय में हल नहीं करता है: तो आपको एक नाम नहीं मिलेगा, क्योंकि रिज़ॉल्वर उस क्वेरी को छोड़ देगा यदि यह एक सेकंड में वापस नहीं आता है। (कमरे से बाहर; अगली टिप्पणी में और अधिक)

— नील काटिन

लंबी अवधि की प्रक्रियाएं प्रत्येक लुकअप, टाइमआउट और उसके बाद अगले सर्वर पर जाती हैं। लेकिन यह सर्वर की "डेडनेस" को कैश नहीं करता है।

— नील कटिन

Answer 3

दिल की धड़कन या पेसमेकर / कोरोसिंक जैसे क्लस्टरिंग सॉफ्टवेयर आपके मित्र हैं। एक छूट के रूप में, हमने पेसमेकर / कोरोसिंक को इस प्रकार सेट किया है:

• हर सर्वर को एक दूसरे के साथ जोड़ दें
• प्रति जोड़ी में 2 डीएनएस वाइप्स हैं, आमतौर पर प्रत्येक पर एक
• या तो बाइंड करना चाहिए या सर्वर फेल हो जाना चाहिए, vip मिलिसेकंड के भीतर दूसरे सर्वर पर चला जाता है

उत्पादन घंटे 24x7 हैं, लेकिन हम दृढ़ता से मानते हैं कि ग्राहकों को प्रभावित किए बिना हर सर्वर को विफल करना संभव होना चाहिए। विकल्प घुमाना केवल एक समाधान है, मैं ऐसा नहीं करूंगा।

Answer 4

प्रत्येक नोड पर एक स्थानीय डीएनएस सर्वर चलाएं, और स्थानीयहोस्ट को resolv.conf बिंदु दें। यह काम करेगा, लेकिन यह हमें निगरानी और प्रबंधन के लिए बहुत अधिक सेवाएं प्रदान करेगा।

एफडब्ल्यूआईडब्ल्यू, यह एकमात्र व्यावहारिक समाधान है जो मुझे इस समस्या के लिए मिला है। आपको सर्वर को केवल लोकलहोस्ट पर सुनने के लिए प्रतिबंधित करने की आवश्यकता है, लेकिन इसने हमारे वातावरण में DNS आउटेज को सूचित करने वाले उपयोगकर्ताओं को पूरी तरह से समाप्त कर दिया है।

एक दिलचस्प साइड इफेक्ट यह है कि अगर स्थानीयहोस्ट सर्वर किसी कारण से नीचे चला जाता है, तो मानक रिज़ॉल्वर लाइब्रेरी मानक सर्वर की तुलना में अगले सर्वर में फ़ेलओवर को बहुत तेज़ी से संभालती प्रतीत होती है।

हम अब लगभग 3 साल से ऐसा कर रहे हैं और मैंने एक भी ऐसा मुद्दा नहीं देखा है जो स्थानीयहोस्ट पर चलने वाले डीएनएस सर्वर की विफलता / आउटेज से संबंधित हो।

Answer 5

यदि कोई नेमवेरेटर रखरखाव के लिए नीचे जा रहा है, तो उस समय से पहले उस डोमेन के लिए SOA में टाइमआउट को कम करना सामान्य प्रक्रिया है, ताकि जब मेंटेनेंस हो, तो बदलाव (जैसे मेंटेनेंस से पहले NS रिकॉर्ड्स को हटा दें और मेंटेनेंस के बाद उन्हें वापस कर दें। ) जल्दी से प्रचार। ध्यान दें कि यह एक सर्वर-साइड अप्रोच है - रिज़ॉल्वर बदलना एक क्लाइंट-साइड अप्रोच है और ... जब तक आप अपने हर एक क्लाइंट से बात कर सकते हैं और उन्हें अपनी मशीन पर यह समायोजन नहीं करवा सकते ... हो सकता है। सही दृष्टिकोण। ठीक है, मुझे लगता है कि आपने आंतरिक DNS सर्वर का उपयोग करके डेटा सेंटर में केवल सौ ग्राहकों को ही कहा था, लेकिन क्या वास्तव में आप सौ ग्राहकों पर कॉन्फ़िगरेशन बदलना चाहते हैं, जब आप सिर्फ ज़ोन बदल सकते हैं?

मैं आपको बताता हूं कि एसओए में कौन से मूल्य समायोजित करने के लिए हैं, लेकिन मैं वेब पर सर्फिंग कर रहा था ताकि यह पता लगाया जा सके कि जब मैं इस सवाल पर भाग रहा था तो वह सटीक जानकारी।

Comments

यह उत्तर केवल आधिकारिक DNS से ​​संबंधित है। सवाल ग्राहक सॉफ्टवेयर द्वारा किए गए पुनरावर्ती डीएनएस लुकअप से संबंधित था।

— एंड्रयू बी

Answer 6

शायद आप अपने DNS सर्वर को लोड बैलेंसर के पीछे रख सकते हैं? जाहिरा तौर पर LVS UDP को संतुलित कर सकता है। स्पष्ट रूप से अपने एलबी को अत्यधिक उपलब्ध करें ताकि यह विफलता का एक भी बिंदु न हो।

Answer 7

मुझे पता है कि यह ट्राइट लग सकता है, लेकिन समस्या के स्थायी समाधान के रूप में अधिक स्थिर, लचीला डीएनएस बुनियादी ढांचे के निर्माण के बारे में कैसे।

Comments

हमारे पास काफी लचीला डीएनएस है। लेकिन साल में 2 या 3 बार हमारा आउटेज होता है क्योंकि dns सर्वर डाउन हो जाता है (या रिस्टार्ट हो जाता है, या OS अपग्रेड हो जाता है, या जो भी हो)।

— नील कटिन

ठीक है ... गैर-उत्पादन घंटों के लिए पुनरारंभ और उन्नयन निर्धारित किया जाना चाहिए। बाकी के लिए, ऐसा लगता है कि आप एक बहुत बड़ी बात कर रहे हैं जो कि साल में कुछ बार होती है। क्या अतिरिक्त समस्या, समय, धन और प्रबंधन इसके लिए एक समस्या है जो इतनी बार-बार होने वाली समस्या के लिए इसके लायक है?

— जोवेवार्टी

क्या होता है जब आपके उत्पादन घंटे 24x7 होते हैं? DNS दूसरे / तीसरे / x सर्वर में विफल होना चाहिए और एक अवधि के लिए अन्य सर्वर की विफलता को कैश करना चाहिए। डिफ़ॉल्ट 5 सेकंड टाइमआउट लोड के आधार पर सेवाओं को नीचे लाने के लिए पर्याप्त है।

— रयान

Answer 8

अधिक नेटवर्क-केंद्रित समाधान समान (समर्पित) आईपी और के साथ दो डीएनएस सर्वर का उपयोग करेगा एनीकास्ट मार्ग के । (मैंने अब तक इस उत्तर पर इस सूत्र में ध्यान नहीं दिया है, लेकिन यहां इसका उपयोग किया गया है।)

जब तक दोनों ऊपर हैं, निकटतम सर्वर का उपयोग किया जाता है। यदि कोई नीचे जाता है, तो उस आईपी के लिए ट्रैफ़िक को फिर से आने तक दूसरे नोड पर भेजा जाएगा। यह विशेष रूप से समझ में आता है यदि आपके पास दो या अधिक स्थान या डेटा केंद्र हैं।