कैसे 8.8.8.8 को * हमेशा * जीवित रखा जाता है?

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

मुझे पता है कि यह वास्तव में व्यापक प्रश्न है, लेकिन मैं इसके लिए इस्तेमाल किए जा सकने वाले प्रोटोकॉल / तकनीकों के सिर्फ नाम सुनना चाहूंगा। मैं अपने बारे में उनके बारे में विवरण पढ़ सकता हूं।

networking dns

— Lapsio
स्रोत

एनीकट पर पढ़ें। लघु: एक ही आईपी पते के साथ कई मेजबान हैं। यही कारण है कि CloudFlare, Google, YouTube और अन्य बड़े नेटवर्क काम करते हैं।

— GiantTree

google.com और cloudflare में कई IP हैं। डीएनएस क्वेरी में स्थान आदि के आधार पर विभिन्न आईपी लौटाए जाते हैं, लेकिन 8.8.8.8 वास्तव में एकल आईपी है। और यह "एकाधिक ए रिकॉर्ड" या अन्य डीएनएस आधारित अतिरेक का उपयोग नहीं कर सकता क्योंकि यह डीएनएस ही है। क्या आपके पास एकल आईपी के तहत कई साइटें / होस्ट हो सकते हैं? वे मल्टी आईएसपी बीजीपी जैसे कुछ का उपयोग करते हैं?

— लैप्सियो

यह Anycast है, जैसे GiantTree ने लिखा है। Anycast में DNS शामिल नहीं है।

— डैनियल बी

IPv4 मूल रूप से anycast का समर्थन नहीं करता है। विकिपीडिया के अनुसार अगर यह सही तरीके से समझे तो मुझे बीजीपी का उपयोग करने का एहसास होता है। en.wikipedia.org/wiki/Anycast

— लैप्सियो

डेटाग्राम सेवाओं के लिए, anycast के लिए विशेष समर्थन की आवश्यकता नहीं है - यह सिर्फ प्रत्येक राउटर के परिणामस्वरूप अपने स्वयं के सबसे कम-मार्ग मार्ग संकलन के रूप में होता है। बीजीपी मूल रूप से या तो इसे किसी भी तरह से "समर्थन" नहीं करता है (यह उन लोगों को यूनिकस्ट मार्गों के रूप में देखता है), और फिर भी इसे इंटरनेट-वाइड करना एक सामान्य तरीका है।

— user1686

जवाबों:

सबसे पहले, वीआरआरपी किसी भी तरह से डीएनएस पर निर्भर नहीं करता है। किसी एकल साइट के भीतर अतिरेक के लिए आप साझा किए गए वीआरआरपी पते पर डीएनएस सर्वरों को ठीक से चला सकते हैं।

लेकिन जैसा कि अन्य लोगों ने टिप्पणियों में उल्लेख किया है, सेवाएं किसी भी प्रकार के राउटिंग मार्ग का उपयोग करती हैं , जिसका अनिवार्य रूप से मतलब है कि एक ही आईपी पता दुनिया भर में कई स्थानों पर मौजूद है। जब एक पूरी साइट नीचे जाती है, तो दुनिया भर में मार्गों को पुनर्गठित किया जाता है ताकि आपके पैकेट दूसरे कार्य स्थल पर जा सकें।

Google का सार्वजनिक डीएनएस से एक बेहतर उदाहरण होगा जड़ डीएनएस सर्वर - हैं, जो की सेवा .करने के लिए क्षेत्र और पकड़ संकेत दिए गए com, org, eu, और इतने पर - क्योंकि वे एक नक्शा है 13 तार्किक पतों के प्रत्येक उदाहरण के। ICANN के "L" को 160 विभिन्न साइटों द्वारा परोसा जाता है!

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

इंटरनेट संगठनों के बीच रूटिंग सूचनाओं के आदान-प्रदान के लिए बीजीपी का उपयोग करता है।

विभिन्न मानदंडों के आधार पर, बीजीपी स्वाभाविक रूप से एक ही नेटवर्क की ओर से कई मार्गों में से सर्वश्रेष्ठ का चयन करने का समर्थन करता है। उदाहरण के लिए, एक ही ग्राहक के पास एक ही ISP के लिए निरर्थक अपलिंक हो सकते हैं (केवल वजन या वरीयता में भिन्न दो मार्गों की घोषणा)। या ग्राहक के पास कई आईएसपी के माध्यम से अपलिंक हो सकता है, और हर कोई अपने पसंदीदा मार्ग (मुख्य रूप से सबसे छोटा एएस-पथ) का चयन करेगा - जो "सच" मल्टी-वैन का सार है।

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

हालांकि, बीजीपी केवल आपके प्रवेश द्वार के लिए यातायात का नेतृत्व करता है, लेकिन इससे आगे क्या होता है इसकी परवाह नहीं करता है। इसलिए यदि आप आंतरिक रूप से एक ही सर्वर की ओर दोनों मार्गों को सेट करते हैं, तो आपको मल्टीहोमिंग मिलता है। लेकिन अगर प्रत्येक "प्रवेश द्वार" एक अलग सर्वर (उसी आईपी के लिए कॉन्फ़िगर किया गया) की ओर जाता है, तो आपको कुछ भी मिलता है।

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

महत्वपूर्ण रूप से, इसका मतलब यह भी है कि अगर बीपी बिल्कुल नहीं है तो बीजीपी परवाह नहीं करता है। विश्वव्यापी अतिरेक पाने के लिए, बस एक ही नेटवर्क को कई भौतिक स्थानों से घोषित करें - यदि आप उन स्थानों को एक साथ जोड़ते हैं (ताकि वे उस नेटवर्क को एक स्थान पर रूट कर दें), तो आपको मल्टीहोमिंग मिल जाएगी; यदि वे द्वीप हैं, तो आपको कुछ भी मिल जाएगा।

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(उस मामले के लिए, इसे एक ही एएस होने की भी आवश्यकता नहीं है - जैसे 6to4 रिले कई स्वतंत्र संगठनों द्वारा चलाए जाते हैं, उनमें से प्रत्येक अपने स्वयं के मार्ग की घोषणा करता है 192.88.99.0/24।)

चेतावनियां:

एनीकास्ट अतिरेक प्रदान करता है, लेकिन लोड-संतुलन नहीं। एक बार जब बीजीपी परिवर्तित हो जाता है, तो प्रत्येक राउटर ने एक पसंदीदा मार्ग (या कभी-कभी कुछ) चुना होगा और नेटवर्क के बदलने तक इसका उपयोग जारी रखेगा।
हालाँकि, आप अनुमान नहीं लगा सकते हैं कि मार्ग कितने समय तक स्थिर रहेंगे, इसलिए किसी भी तरह की राज्य सेवाओं को मुश्किल में डाला जा सकता है। DNS स्टेटलेस होने के कारण और मुख्य रूप से UDP (EDNS ने टीसीपी कनेक्शन की आवश्यकता कम कर दिया है) के उपयोग से यह दूर हो जाता है।
वास्तविक सेवा और बीजीपी रूटर के बीच समन्वय होना चाहिए, ताकि सेवा के दुर्घटनाग्रस्त होने पर मार्ग वापस ले लिया जाए।

यह भी देखें "4.2.2.2 का इतिहास। कहानी क्या है?" NANOG मेलिंग सूची पर: पोस्ट 1 , पोस्ट 2 ।

— user1686
स्रोत

"इस अजीब चाल के साथ 60 सेकंड से कम समय में आपका जवाब कैसे स्वीकार किया जाता है"

— user1686

"द्वीप" आप पहले-अंतिम पैराग्राफ में किसका उल्लेख करते हैं? सिर्फ कनेक्टेड साइट्स नहीं?

— लैप्सियो

हां - आपके नेटवर्क के कुछ भाग जो एक-दूसरे या बाकी के साथ परस्पर जुड़े नहीं हैं। (हालांकि यह सिर्फ एक उदाहरण है। यह संभव है कि किसी बड़े इंटरकनेक्टेड नेटवर्क के अंदर आंतरिक एनकास्ट को लागू किया जाए, वह भी - फिर से राउटिंग प्रोटोकॉल द्वारा।)

— user1686

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

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

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

यह भी महत्वपूर्ण है कि लोड बैलेंसर स्वयं विफलता का एक बिंदु नहीं बनता है। आमतौर पर लोड बैलेंसरों को उच्च उपलब्धता वाले जोड़े में लागू किया जाता है, जो विशिष्ट एप्लिकेशन द्वारा आवश्यक होने पर सत्र दृढ़ता डेटा को दोहरा सकते हैं। [५]

— phuclv
स्रोत

हाँ, लेकिन लोड बैलेन्सर केवल विफलता का एक बिंदु नहीं हैं यदि वे उदाहरण के लिए VRRP, राउटिंग प्रोटोकॉल आदि जैसे कुछ अन्य उच्च उपलब्धता तकनीक का उपयोग करते हैं, लेकिन फिर VRRP या IGP बल्कि LAN समाधान हैं। तो मेरा मतलब है कि ISP बोर्डर WAN कनेक्शन डेटासेंटर में विफल रहता है। बेशक कंपनी के पास बहु WAN है, जब तक कि साइट गेटवे अलग-अलग WAN लिंक पर स्विच कर सकता है यह ठीक है, लेकिन एक ही आईपी समस्या को कम करता है। मामले में जब DNS उपलब्ध है तो यह ठीक है - एकाधिक ए या एएएए फिर से तैयार करता है और किया जाता है। लेकिन जब यह DNS सर्वर ही है तो केवल समाधान कई ISPs के बीच anycast / BGP है।

— लैप्सियो

मैं गेटवे के बाद WAN की उच्च उपलब्धता वाले समाधानों का उल्लेख कर रहा था । जब ISP आपदा के कारण पूरी कंपनी साइट दुनिया से अप्राप्य है। 8.8.8.8 मान नहीं सकते कि ISP काम करेगा। जब पूरी दुनिया आपकी सेवा पर निर्भर करती है तो आप किसी एक कंपनी पर भरोसा नहीं कर सकते हैं

— लैप्सियो