माइग्रेशन की हर डरावनी कहानी का बीच वाला हिस्सा एक जैसा होता है: किसी ने पहले DNS बदल दिया और फिर कॉपी करना शुरू किया। शिफ़्ट के दौरान डाउनटाइम लगभग कभी धीमी कॉपी की वजह से नहीं होता। वह कदमों के ग़लत क्रम की वजह से होता है।
यह रहा वह क्रम जो काम करता है, चाहे आप किसी और प्रदाता को छोड़ रहे हों या हमारे दो प्लान के बीच जा रहे हों।
1. दो दिन पहले: TTL घटाएँ
वे DNS रिकॉर्ड ढूँढें जिन्हें आप बदलेंगे (आम तौर पर A, AAAA और उनकी ओर इशारा करने वाले CNAME) और उनका TTL 300 सेकंड कर दें। फिर कम से कम उतना इंतज़ार करें जितना पुराना TTL था। एक दिन के TTL वाले रिकॉर्ड का मतलब है कि कुछ रिज़ॉल्वर बदलाव के बाद भी एक दिन तक पुराना पता देते रहेंगे, और सर्वर पर आप कुछ भी करें, यह तेज़ नहीं होगा।
यही कदम लोग छोड़ देते हैं, और यही पाँच मिनट के स्विच को ऐसे दिन में बदल देता है जब आधे उपयोगकर्ता पुराना सर्वर देखते हैं।
2. पुराने सर्वर की सूची बनाएँ
आप इस मशीन को कहीं और दोबारा बनाने जा रहे हैं, इसलिए लिख लें कि यह असल में क्या करती है। वह नहीं जो आपको याद है। जो यह करती है:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
सूची में यह भी जोड़ें: TLS सर्टिफ़िकेट और वे कैसे रिन्यू होते हैं, सीक्रेट वाली एनवायरनमेंट फ़ाइलें, फ़ायरवॉल नियम, उपयोगकर्ता और उनकी SSH कुंजियाँ, डेटाबेस और उसका आकार, और हर वह चीज़ जो सर्वर से IP पते के ज़रिए बात करती है। यह आख़िरी समूह ही धोखेबाज़ है: किसी पार्टनर की allowlist, पेमेंट प्रदाता की वेबहुक सेटिंग, कोई मॉनिटरिंग जाँच।
3. नया सर्वर पुराने के बगल में खड़ा करें
नया सर्वर ऑर्डर करें और पुराने को छेड़ें नहीं। VPS सूची से ऐसा प्लान चुनें जिसकी डिस्क उतनी या उससे ज़्यादा हो जितनी आप असल में इस्तेमाल करते हैं, न कि जितनी आपको बेची गई थी। अगर पुरानी मशीन पर कोई भी इनबाउंड ट्रैफ़िक आता है (वेबसाइट, वेबहुक, API), तो नई को अपना IPv4 चाहिए। NAT प्लान सिर्फ़ अपने SSH पोर्ट पर इनबाउंड कनेक्शन लेता है, और यह क्यों मायने रखता है, यह एक फ़ॉरवर्ड किया गया पोर्ट क्या कर सकता है और क्या नहीं में समझाया गया है।
कनेक्ट करें, वही पैकेज इंस्टॉल करें, उपयोगकर्ता और फ़ायरवॉल फिर से बनाएँ। कुंजियाँ और पहला लॉगिन कनेक्शन गाइड में हैं।
4. फ़ाइलें दो बार सिंक करें
पहला सिंक सब कुछ कॉपी करता है जबकि पुराना सर्वर काम करता रहता है। इसमें घंटों लग सकते हैं; कोई बात नहीं।
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids फ़ाइलों के मालिकों को नंबर से बनाए रखता है, जिससे वह पुराना झटका नहीं लगता कि "सब कुछ ग़लत उपयोगकर्ता का है", जब दोनों सिस्टम ने उपयोगकर्ता अलग क्रम में बनाए हों। अगर आपने SSH पर rsync कभी नहीं चलाया, तो VPS पर फ़ाइलें कैसे भेजें इसे कदम-दर-कदम बताता है।
दूसरा सिंक, स्विच से ठीक पहले, सिर्फ़ वही कॉपी करता है जो पहले के बाद बदला। आम तौर पर कुछ सेकंड लगते हैं।
5. डेटाबेस सोच-समझकर ले जाएँ
फ़ाइलें आसान हैं। राइट लेने वाला डेटाबेस वह इकलौता हिस्सा है जहाँ "बिना डाउनटाइम" के लिए या तो थोड़ा समझौता चाहिए या ज़्यादा मेहनत।
आसान तरीक़ा: जाँच के लिए एक बार डंप लेकर रिस्टोर करें, फिर स्विच के समय एक मिनट के लिए राइट रोकें (ऐप को सिर्फ़-पढ़ने वाले मोड में डालें या बंद करें), ताज़ा डंप लें, नए सर्वर पर रिस्टोर करें और ऐप वहीं चालू करें। ज़्यादातर छोटे प्रोजेक्ट के लिए यह एक-दो मिनट का ठहराव है, जिसकी सूचना पहले दी जा सकती है।
बिना ठहराव का तरीक़ा: पुराने डेटाबेस से नए में रेप्लिकेशन सेट करें, उसे बराबरी पर आने दें, और स्विच के समय नए को मुख्य बना दें। तैयारी ज़्यादा है, और यह तब वाजिब है जब एक मिनट के खोए राइट भी मंज़ूर न हों।
6. किसी और के देखने से पहले नया सर्वर जाँचें
DNS अब भी पुराने सर्वर की ओर है, इसलिए नए को आप अकेले में जाँच सकते हैं। अपने असली डोमेन का अनुरोध नए पते पर भेजें:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
अगर सर्टिफ़िकेट अभी नहीं है, तो इसी तरह HTTP पर जाँचें, या hosts फ़ाइल में एक अस्थायी लाइन जोड़कर ब्राउज़र में साइट घूम लें। लॉगिन, अपलोड, बैकग्राउंड काम और भेजी जाने वाली मेल जाँचें। गुम PHP एक्सटेंशन पकड़ने का यही सबसे सस्ता मौक़ा है।
7. स्विच करें, और पुराना सर्वर चालू रखें
आख़िरी फ़ाइल सिंक और डेटाबेस वाला कदम पूरा करें, फिर DNS रिकॉर्ड बदलें। 300 सेकंड के TTL के साथ ज़्यादातर ट्रैफ़िक मिनटों में चला जाता है। पुराने सर्वर का एक्सेस लॉग देखते रहें: TTL को अनदेखा करने वाले रिज़ॉल्वर और क्लाइंट से वहाँ अब भी कुछ अनुरोध आते रहेंगे। उसे बिना बदले कुछ दिन चलने दें। फिर पुराने IP की ओर इशारा करने वाली हर चीज़ अपडेट करें: पार्टनर की allowlist, वेबहुक URL, और मेल के लिए नए पते का रिवर्स DNS (हमारे डेडिकेटेड IP प्लान पर आप इसे ख़ुद सेट करते हैं, देखें रिवर्स DNS) और अपना SPF रिकॉर्ड।
सबसे ज़्यादा क्या टूटता है
मोटे तौर पर उस क्रम में जितनी बार हम इसे देखते हैं: एक systemd टाइमर जिसे किसी ने सूची में नहीं डाला, पुराने IP के साथ सीधे लिखी कॉन्फ़िग फ़ाइल, ग़लत उपयोगकर्ता की फ़ाइलें, ऐप के अपने पोर्ट को रोकने वाला फ़ायरवॉल, पुराने सर्वर पर रिन्यू होने वाला लेकिन नए पर नहीं होने वाला सर्टिफ़िकेट, और स्पैम में जाती मेल क्योंकि नए पते का अभी रिवर्स DNS नहीं है।
यह चेकलिस्ट कहाँ ठीक नहीं
लगातार राइट वाले व्यस्त डेटाबेस को, जो ठहराव बिल्कुल नहीं झेल सकता, ब्लॉग की चेकलिस्ट नहीं बल्कि असली रेप्लिकेशन और एक रिहर्सल चाहिए। Windows सर्वर rsync की बजाय दूसरे औज़ारों से शिफ़्ट होते हैं। और अगर शिफ़्ट असल में आकार की वजह से है, तो पहले यह पढ़ें: यहाँ प्लान वहीं बढ़ते हैं। उसी नेटवर्क टाइप के बड़े प्लान पर जाने से बिना किसी शिफ़्ट के एक रीबूट में vCPU, RAM और डिस्क बढ़ जाते हैं। नया सर्वर सिर्फ़ छोटा करने के लिए चाहिए। अगर आप इसलिए शिफ़्ट हो रहे हैं कि पता नहीं मशीन काफ़ी है या नहीं, तो आपको सच में 64 GB RAM कब चाहिए आपको यह सफ़र बचा सकता है, और अगर आपको यक़ीन नहीं कि VPS सही ठिकाना है, तो VPS बनाम शेयर्ड होस्टिंग बनाम डेडिकेटेड बनाम क्लाउड मदद करेगा।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।