सवाल कई साइटों को नए सर्वर पर ले जाना - उनके DNS रिकॉर्ड्स को अपडेट करने का सबसे तेज़ तरीका क्या है?


मैं एक नए सर्वर पर बड़ी संख्या में वेबसाइटों (लगभग 100) माइग्रेट करने की योजना बना रहा हूं और मैं माइग्रेशन प्लानिंग प्रक्रिया में हूं।

प्रत्येक वेबसाइट के लिए एक सामान्य DNS ज़ोन में दो ए रिकॉर्ड होते हैं जो वेब सर्वर आईपी को इंगित करते हैं, एक के लिए example.com और एक के लिए www उप डोमेन।

जब हम सभी सेटअप और उत्पादन के लिए नए सर्वर को लॉन्च करने के लिए तैयार होते हैं, तो 100x2 DNS रिकॉर्ड्स बदलना समय लेने वाला होगा इसलिए मैं इसे तेज बनाने का एक तरीका खोज रहा हूं। कुछ मामलों में मैंने एक बैश स्क्रिप्ट बनाने के बारे में पढ़ा जो DNS रिकॉर्ड को पुन: सक्रिय करता है और नए आईपी के साथ एक खोज-प्रतिस्थापन करता है। अन्य विषयों में मैंने नए आईपी के साथ एक रिकॉर्ड जोड़ने के बारे में सुझाव पढ़े हैं ताकि जब वर्तमान सर्वर अब उपलब्ध न हो, तो DNS सर्वर अनुरोध को अगले रिकॉर्ड में इंगित करेगा, जिसमें नया आईपी होगा।

इनके अलावा, क्या कोई परिदृश्य है जिसमें मैं किसी अन्य प्रकार की DNS एंट्री यानी होस्टनाम के साथ ए रिकॉर्ड को प्रतिस्थापित कर सकता हूं ताकि जब समय आ जाए, तो मैं केवल होस्टनाम के आईपी को नए के साथ बदल सकता हूं और सब कुछ वेबसाइट नए सर्वर को इंगित करती है? मुझे यकीन है कि 'होस्टनाम' सही शब्द नहीं है, मुझे उम्मीद है कि आपको सभी को यह विचार मिल जाएगा।


6
2017-09-27 12:58


मूल


आप किस DNS सर्वर / सेवा का उपयोग कर रहे हैं? जब आप परिवर्तन करते हैं तो आप एक रिकॉर्ड के बजाय एक CNAME का उपयोग करने पर विचार कर सकते हैं, फिर यदि आप सर्वर को फिर से ले जाते हैं तो आपके पास अपडेट करने के लिए केवल एक रिकॉर्ड होता है - Phil
हम अपने डीएनएस के प्रबंधन के लिए डब्ल्यूएचएम का उपयोग कर रहे हैं। सीएनएन के बारे में अच्छा बिंदु, मैं आपके सुझाव का उपयोग करने जा रहा हूं। - bikey77
"वर्तमान सर्वर अब उपलब्ध नहीं है, DNS सर्वर अनुरोध को अगले रिकॉर्ड में इंगित करेगा," कोई भी DNS इस तरह काम नहीं करता है, यह एक विफलता नहीं है। यदि एक लेबल में दो है A रिकॉर्ड्स, डीएनएस हमेशा दोनों वापस आ जाएगा, भले ही एक आईपी अब काम न करे। किसी को या किसी को क्षेत्र से निष्क्रिय आईपी को स्पष्ट रूप से हटाने की आवश्यकता होगी। - Patrick Mevzek
एक सीएनएन रिकॉर्ड का उपयोग करना एक विकल्प है www रिकॉर्ड लेकिन सर्वोच्च के लिए नहीं। साथ ही, एक रिकॉर्ड को संशोधित करने से CNAME को संशोधित करना बेहतर होगा? मुझे यकीन नहीं है। - Tom
पुराने सर्वर को रिवर्स प्रॉक्सी के रूप में नए सर्वर में कनवर्ट करें? यदि आपके पास सर्वर पर इतनी सारी साइटें हैं तो आपको आईपी फेलओवर या कुछ समान मानना ​​चाहिए - giammin


जवाब:


जिस शब्द को आप ढूंढ रहे हैं वह है CNAME, और आपके प्रश्न का उत्तर हां और नहीं दोनों है।

सबसे पहले, यहां एक उदाहरण है कि एक सीओएन जोन फ़ाइल में कैसे काम करता है।

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

server1    A       10.1.2.3
www        CNAME   server1

अब आपको बस अपडेट करने की जरूरत है server1 दोनों को स्थानांतरित करने के लिए रिकॉर्ड करें server1 तथा www नए आईपी पते पर।

सीएनएन को एक ही डोमेन के भीतर किसी पते को इंगित करने की आवश्यकता नहीं है; यह भी इस तरह दिख सकता है:

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

www         CNAME   server1.example.org.

अब, जब आप के लिए एक रिकॉर्ड अद्यतन करते हैं server1 ज़ोन में example.orgके लिए रिकॉर्ड www.example.se बिना किसी और विन्यास के साथ पालन करेंगे।

आपके दृष्टिकोण से खराब हिस्सा यह है कि यह शीर्ष रिकॉर्ड के लिए काम नहीं करता है - इसका मतलब है "बेयर" डोमेन। दूसरे शब्दों में, आप कर सकते हैं www.example.com एक सीएनएन में, लेकिन आप इसके साथ ऐसा नहीं कर सकते हैं example.com। ऐसा इसलिए है क्योंकि जब आप एक CNAME रिकॉर्ड का उपयोग करते हैं, तो आपके पास उस प्रविष्टि के लिए कोई अतिरिक्त रिकॉर्ड नहीं हो सकता है - जिसका अर्थ है कि आपके पास मेल सर्वर रिकॉर्ड नहीं हो सकते हैं, या सर्वर सर्वर का नाम नहीं है ... जिसका अर्थ है कि डोमेन काम करना बंद कर देगा।

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

आप माइग्रेशन से पहले उचित समय में डोमेन के लिए टीटीएल मान को भी कम करना चाहते हैं। (और ज़ोन फ़ाइल के सीरियल नंबर को अपडेट करना न भूलें - मेरे पास है, और यह बहुत शर्मनाक है ...)


11
2017-09-27 13:20



लेकिन क्या यह समस्याग्रस्त नहीं है यदि DNS कैश टीटीएल को अनदेखा करते हैं और आप डाउनटाइम से बचना चाहते हैं? यातायात को पुराने आईपी से या नए आईपी से पुराने आईपी तक रूट नहीं करता है जब तक कि साइटें स्थानांतरित नहीं हो जाती हैं (दृष्टिकोण के आधार पर) अधिक समझ में आता है? इसके लिए DNS पर भरोसा करते समय मूल रूप से आपका नियंत्रण नहीं होता है जब आपके क्लाइंट नए आईपी परोसते हैं। रूटिंग के साथ इससे कोई फर्क नहीं पड़ता, आप अपने पुराने सर्वर और रूट को कुछ दिनों / सप्ताह के लिए नए में रख सकते हैं। - Broco
@ ब्रोको हां, बाधाओं के आधार पर, आपको या तो दोनों सर्वर हैंडओवर के दौरान कुछ समय तक जीवित रहना होगा, या पुराने से नए यातायात (जैसे HTTP पुनर्निर्देशन या ईमेल अग्रेषण इत्यादि) को रीडायरेक्ट करना होगा। - Patrick Mevzek
"आप माइग्रेशन से पहले उचित समय में डोमेन के लिए टीटीएल मूल्य को भी कम करना चाहते हैं।" यदि आप बिल्कुल मूर्ख साबित होना चाहते हैं तो आपके पास अन्य knobs समायोजित करने और अधिक चरणों के लिए होगा। आपको SOA REFRESH मान भी कम करने की आवश्यकता है (इस पर निर्भर करता है कि सभी नेमसर्वर कैसे प्रावधान किए जाते हैं)। यदि आप ए को एक सीएनएन में "रूपांतरित" करते हैं तो आपको पहले ए को कम टीटीएल के साथ प्रकाशित करने की आवश्यकता हो सकती है और फिर इसे CNAME के ​​लिए बदलना पड़ सकता है। आपको न्यूनतम / नकारात्मक टीटीएल भी बदलना पड़ सकता है। संक्षेप में यह जटिल है (यदि तेजी से अभिसरण की आवश्यकता है)। - Patrick Mevzek
@ ब्रोको "DNS कैश टीटीएल को अनदेखा करते हैं" उन्हें नहीं करना चाहिए। या कम से कम चीजों को इससे पहले साफ़ कर सकते हैं लेकिन बाद में नहीं। सिवाय इसके कि कुछ वास्तव में बहुत कम टीटीएल मानों को कुछ सेकंड की तरह दबाएंगे। - Patrick Mevzek
@PatrickMevzek मुझे अनुभव से पता है कि वे करते हैं (सभी नहीं, लेकिन कुछ)। अतीत में मुझे DNS दृष्टिकोण के साथ साइटों को स्थानांतरित करते समय समस्याएं थीं। भले ही हमने साइट्स को स्थानांतरित करने से दो दिन पहले टीटीएल को 5 मिनट तक सेट किया था (यह 24 घंटे पहले था), कुछ प्रदाताओं ने परवाह नहीं की और केवल 24 घंटे के बाद नए आईपी की सेवा की, कुछ घंटे लगे, कुछ ने 5 मिनट लिया । - Broco


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

आप शायद अद्यतन करने के लिए या एक टेक्स्ट फ़ाइल संपादित करने के लिए एक स्क्रिप्टिंग एपीआई का उपयोग करना चाहेंगे, क्योंकि दोनों आसानी से स्वचालित हो सकते हैं। यदि यह एक टेक्स्ट फ़ाइल है, तो आप इसे पहले से तैयार भी कर सकते हैं और माइग्रेशन करते समय बस इसे कॉपी कर सकते हैं।

संयोग से, इस तरह के परिवर्तन को इस तरह के पैमाने पर बनाना है कि अब कई लोग देवओप्स उपकरण जैसे शेफ, Ansible, Puppet, नमक, का उपयोग कर रहे हैं ... जाहिर है ये बड़े उपकरण हैं जिनकी योजना की आवश्यकता है, इसलिए यह नहीं होने वाला है इस विशिष्ट आवश्यकता के लिए तत्काल सहायता के लिए, लेकिन यह आपके जीवन को दीर्घ अवधि में आसान बना सकता है।

कुछ अन्य महत्वपूर्ण विचार:

  • अपने टीटीएल की जांच करें। आपके माइग्रेशन से पहले एक दिन या सप्ताह के बारे में, टीटीएल को सबसे कम से कम बदलें जो आप कर सकते हैं। माइग्रेशन पूर्ण होने के बाद टीटीएल बढ़ाएं।

  • एसओए रिकॉर्ड में सीरियल नंबर बढ़ाने के लिए मत भूलना! एपीआई और वेब इंटरफेस स्वचालित रूप से आपके लिए यह कर सकते हैं या नहीं कर सकते हैं। यदि आपका DNS सर्वर टेक्स्ट फ़ाइलों का उपयोग करता है, तो आपको इसे याद रखना होगा।

  • सर्वर की प्रकृति के आधार पर, देखें कि क्या आप थोड़ी देर के लिए पुराने और नए पक्ष को चला सकते हैं। यदि आप कर सकते हैं, तो आपको एक बार में सभी DNS अपडेट पूर्ण नहीं करना पड़ सकता है।


3
2017-09-27 18:57





अगर मुझे यह अधिकार मिलता है तो पुराने सर्वर का एक आईपी पता होता है और नए में केवल एक ही होता है।

तो आप क्या कर सकते हैं नया सर्वर स्थापित करना और उस पर बस सभी प्रासंगिक http / https / ftp / पुराने आईपी पर जो भी ट्रैफिक रूट करें और फिर नया आईपी दिखाने के लिए DNS रिकॉर्ड्स अपडेट करें।

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

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

संपादित / आगे स्पष्टीकरण:  इसे समझने में कुछ आसान बनाने के लिए:

आप अभी भी अपना नया सर्वर अभी इंस्टॉल कर सकते हैं, सबकुछ कॉन्फ़िगर कर सकते हैं और अपनी सभी साइटें नए आईपी पर ले जा सकते हैं और फिर पुराने सर्वर से सभी ट्रैफिक को नए सर्वर पर रूट कर सकते हैं।

जैसे आपके पुराने सर्वर में आईपी है 192.0.2.1 आपके नए सर्वर में आईपी है 198.51.100.2

आपका DNS इंगित करता है 192.0.2.1 सभी साइटों (?) के लिए और वेबसर्वर निर्णय लेता है कि कौन सी सामग्री अनुरोधित डोमेन के नाम से सेवा करेगी, उदा। example.com -> /var/www/sites/example.com तथा www.example.com -> /var/www/sites/example.com

तो आप बस इसे चालू करें:

example.com -> 192.0.2.1

इसमें (जैसे ही आप साइट को 198.51.100.2 पर ले गए):

example.com -> 192.0.2.1 -> 198.51.100.2

और फिर 198.51.100.2 को इंगित करने के लिए DNS रिकॉर्ड्स को बदलें:

example.com -> 198.51.100.2

DNS के साथ समस्या यह है कि अद्यतन कभी भी तत्काल नहीं होता है, इसलिए आपके कुछ क्लाइंट example.com के लिए अभी भी एक चरम समय के लिए 198.51.100.2 को इंगित किया जाएगा (या तो आपके द्वारा सेट किया गया टीटीएल या, अगर वे इसे अनदेखा करते हैं, तो कौन जानता है कि कैसे लंबा)।

तो मेरा मुद्दा है: DNS पर भरोसा करने के बजाय, आईपी परत पर यातायात को पुनर्निर्देशित करें ताकि आप डाउनटाइम को कम कर सकें। मुझे उम्मीद है कि यह थोड़ा और स्पष्ट हो जाएगा।

उबंटू पर आप अग्रेषण और एनएटी (उदाहरण के लिए अपने पुराने गंतव्य 198.51.100.2 के लिए http.51.100.2 को अपने नए गंतव्य 198.51.100.2 पर रूटिंग http और https के साथ कर सकते हैं; ये सेटिंग्स आपके पुराने सर्वर पर की गई हैं):

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 198.51.100.2:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 198.51.100.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE

2
2017-09-27 13:31



आपके द्वारा वर्णित मार्गों के बारे में कुछ और समझाने की देखभाल? उनके पास किस प्रकार का फॉर्म है? - bikey77
मुझे इसे थोड़ा सा समझा देना था क्योंकि आपने यह उल्लेख नहीं किया था कि आप किस प्रकार का सर्वर उपयोग कर रहे हैं ताकि आप अपनी साइट्स की सेवा कर सकें। जैसे iptables (लिनक्स) में आप किसी नए स्थान पर यातायात को पुनर्निर्देशित करने के लिए प्रीरउटिंग और मास्कराइडिंग का उपयोग कर सकते हैं, यहां देखें: debuntu.org/... केवल एक DNS के साथ समस्या यह है कि जब आप अपनी साइट के आगंतुकों के DNS कैश अपडेट करते हैं तो आप भरोसा नहीं कर सकते हैं। रूटिंग दृष्टिकोण के साथ आप स्विच के समय को निर्धारित करते हैं, संभावित डाउनटाइम को कम करते हैं। - Broco
कृपया उदाहरणों के लिए बेवकूफ आईपी पते का उपयोग न करें, खासतौर पर उन लोगों ने जो वास्तव में इंटरनेट पर बड़ी वैश्विक सेवाओं के लिए उपयोग नहीं किया है। मैंने दस्तावेज के लिए आरक्षित आरएफसी 5737 आईपी पते का उपयोग करके अपनी पोस्ट संपादित की - Patrick Mevzek


एक त्वरित समाधान (सबसे सुरुचिपूर्ण नहीं, लेकिन शायद काम कर रहा है) बस पुराने आईपी को एक साधारण खोज-प्रतिस्थापन के साथ बदल देगा।

पहले ज़ोन फाइलों का बैकअप लें।

फिर समस्याओं की जांच करें:

grep 'ol\.d\.i\.p' *.zone

जांचें कि क्या कोई लाइनें हैं, जो कि कोई रिकॉर्ड नहीं है जिसे आप प्रतिस्थापित करना चाहते हैं

अगला आईपी को प्रतिस्थापित करें:

sed -i 's/ol\.d\.i\.p/ne.w.i.p/g' *.zone
grep 'ne\.w\.i\.p' *.zone # check if the new lines look correct

ऐसा कुछ भी नहीं है जो आपको एक स्क्रिप्ट में करना चाहिए जो हर दिन चलता है, लेकिन एक ऑफ माइग्रेशन के लिए यह परिष्कृत माइग्रेशन टूल प्रोग्राम शुरू किए बिना समस्या को हल करने के लिए पर्याप्त हो सकता है।

  • grep आदेश केवल नियमित अभिव्यक्ति वाली रेखाओं की खोज करता है (यहां: आईपी का एक शाब्दिक मैच, द . बचने की जरूरत है क्योंकि उनके पास रेगेक्स में विशेष अर्थ है)।
  • sed धाराओं या फ़ाइलों पर लाइन आधारित संचालन के लिए प्रयोग किया जाता है (का उपयोग कर -i विकल्प)। s/regex/replacement/g नियमित अभिव्यक्ति को प्रतिस्थापित करता है (जैसा कि प्रयोग किया जाता है grep आदेश) प्रतिस्थापन (नया आईपी) के साथ। /g का मतलब ग्लोबल है, जो सुनिश्चित करता है कि आईपी को कई बार प्रतिस्थापित किया गया है, यदि एक लाइन पर कई मैचों हैं।

1
2017-09-27 14:37



दस्तावेज में उपयोग करने के लिए आईपी पते पर उदाहरणों के लिए आरएफसी 5737 पर एक नज़र डालें। - Patrick Mevzek
और आप खोज और प्रतिस्थापन को और अधिक सटीक होने की आवश्यकता होगी। क्योंकि अगर आपके पास दोनों हैं 192.0.2.1 तथा 192.0.2.100 आपके क्षेत्रफल में, पैटर्न 192\.0\.2\.1 दोनों को प्रभावित करेगा ... - Patrick Mevzek
जैसा कि कहा गया है, यह एक त्वरित और गंदे समाधान है और आपको फ़ाइलों का बैकअप लेने और पूरी तरह से इसका उपयोग करने से पहले मिलान करने की आवश्यकता है। वास्तव में आप भी मैच करना चाहते हैं \s पहले और संभवतः \s या $ आईपी ​​के बाद, लेकिन ऐसा लगता है कि ओपी को केवल एक आईपी को बदलने की जरूरत है। यदि आप एक संपूर्ण सबनेट या अन्य बड़े उपयोग के मामलों को प्रबंधित करना चाहते हैं, तो उचित टूल ढूंढें और सरल खोल स्क्रिप्टिंग पर भरोसा न करें। - allo