पहले नए सर्वर को तैयार और परीक्षण करें, एप्लिकेशन-समर्थित स्थिरता विधि से डेटा कॉपी करें, कटओवर विंडो परिभाषित करें और पुराने वातावरण को सुरक्षित रखें। रोलबैक में नए सर्वर पर स्वीकार किए गए लेखन को ध्यान में रखना चाहिए, केवल DNS परिवर्तन नहीं।
मशीन स्थानांतरित करने से पहले सेवा की सूची बनाएँ
माइग्रेशन में एप्लिकेशन फ़ाइलों से अधिक शामिल है। डेटाबेस, अपलोड, निर्धारित कार्य, कतार वर्कर, प्रमाणपत्र, डोमेन, सीक्रेट और आउटबाउंड इंटीग्रेशन सूचीबद्ध करें। सॉफ़्टवेयर संस्करण और मायने रखने वाली परिचालन धारणाएँ दर्ज करें, जैसे फ़ाइल अनुमतियाँ और संग्रहण पथ। एक नया समर्पित सर्वर कोई भूली हुई निर्भरता उजागर कर सकता है जो वर्षों पहले पुराने वातावरण पर चुपचाप इंस्टॉल की गई थी।
कटओवर निर्णय के लिए एक स्वामी नियुक्त करें और परिभाषित करें कि सफलता कैसी दिखती है। उपयोगकर्ता-दृश्य जाँच, डेटा स्थिरता और एक्सेस पुनर्प्राप्त करने की क्षमता शामिल करें। माइग्रेशन तिथि की घोषणा से पहले पुष्टि करें कि नया कॉन्फ़िगरेशन वितरित और उपयोग योग्य है। ऑर्डर पुष्टि या सूचीबद्ध हार्डवेयर विशिष्टता उत्पादन डेटा प्राप्त करने के लिए तैयार कार्यशील गंतव्य के समान नहीं है।
गंतव्य को एक अलग वातावरण के रूप में बनाएँ
आवश्यक स्टैक इंस्टॉल करें, प्रशासन स्थापित करें और इच्छित फ़ायरवॉल कॉन्फ़िगर करें। सीक्रेट निजी रखें और सेवा अनुमतियाँ जानबूझकर सेट करें। सार्वजनिक ट्रैफ़िक स्थानांतरित होने से पहले एप्लिकेशन के अपेक्षित होस्टनाम और प्रमाणपत्र व्यवहार को सत्यापित करें। Apache का वर्चुअल-होस्ट दस्तावेज़ दिखाता है कि होस्टनाम रूटिंग सर्वर के पते से अलग कॉन्फ़िगरेशन निर्णय क्यों है। कार्यशील डिफ़ॉल्ट पृष्ठ यह साबित नहीं करता कि सही एप्लिकेशन होस्ट कॉन्फ़िगर है।
पूर्वाभ्यास के लिए एक प्रतिनिधि पुनर्स्थापित डेटासेट का उपयोग करें, जिसमें आउटगोइंग ईमेल, भुगतान और निर्धारित कार्य अक्षम या सुरक्षित परीक्षण सिस्टम पर पुनर्निर्देशित हों। यह परीक्षण वातावरण को वास्तविक उपयोगकर्ताओं पर कार्य करने से रोकता है। लॉगिन, अपलोड, पृष्ठभूमि कार्य और पुनर्स्थापन का अभ्यास करें। प्रक्रिया और उसकी अवधि दर्ज करें ताकि वास्तविक विंडो आशावाद के बजाय देखी गई प्रक्रिया पर आधारित हो।
एक सुसंगत डेटा सीमा चुनें
डेटाबेस और एप्लिकेशन द्वारा समर्थित बैकअप या प्रतिकृति विधि का उपयोग करें। PostgreSQL SQL डंप, फ़ाइल-सिस्टम बैकअप और निरंतर आर्काइविंग में अंतर करता है, प्रत्येक की अपनी धारणाएँ हैं। इसका डंप मार्गदर्शन बताता है कि डेटाबेस डंप आंतरिक रूप से सुसंगत हो सकते हैं जबकि क्लस्टर-व्यापी भूमिकाओं और अन्य विवरणों को अलग से संभालना आवश्यक है। आप जो सटीक सिस्टम चलाते हैं उसकी आवश्यकताएँ पढ़ें, बजाय खुली डेटा फ़ाइलों को अंधाधुंध कॉपी करने के।
योजना बनाएँ कि डेटाबेस अपलोड और कतार स्थिति से कैसे संबंधित है। यदि कोई रिकॉर्ड ऐसी फ़ाइल की ओर इशारा करता है जो अलग समय पर कॉपी की गई थी, तो पुनर्स्थापित एप्लिकेशन अधूरा हो सकता है, भले ही दोनों प्रतियाँ अलग-अलग सफल रही हों। तय करें कि लेखन को संक्षेप में रोकना है, परीक्षित प्रतिकृति व्यवस्था का उपयोग करना है या एप्लिकेशन-विशिष्ट निर्यात करना है। उस स्थिरता निर्णय को रनबुक में स्पष्ट रखें।
| चरण | आवश्यक प्रमाण | निर्णय |
|---|---|---|
| पूर्वाभ्यास | एप्लिकेशन और पुनर्स्थापित डेटा जाँच पास करते हैं | गंतव्य को कटओवर के लिए विचार किया जा सकता है |
| अंतिम समकालिकरण | परिभाषित सुसंगत रिकवरी बिंदु | केवल समझे गए शेष परिवर्तनों के साथ आगे बढ़ें |
| ट्रैफ़िक स्विच | सही रूटिंग और प्रमाणपत्र व्यवहार | दोनों गंतव्यों की निगरानी करें |
| रोलबैक | सभी नए स्वीकृत लेखन का स्थान | ट्रैफ़िक लौटाने से पहले डेटा मिलाएँ |
तत्काल परिवर्तन का वादा किए बिना ट्रैफ़िक रूटिंग तैयार करें
DNS टाइम-टू-लाइव नियंत्रित करता है कि रिकॉर्ड कितने समय तक कैश किए जा सकते हैं, जैसा Cloudflare के DNS दस्तावेज़ में समझाया गया है। यदि DNS माइग्रेशन का हिस्सा है तो TTL की समीक्षा जल्दी करें, और मौजूदा कैश किए गए रिकॉर्ड को उनकी पिछली सेटिंग के तहत पुराना होने दें। कटओवर के क्षण मान बदलने से हर कैश किए गए उत्तर को पूर्वव्यापी रूप से छोटा नहीं किया जा सकता। संक्रमण के दौरान विभिन्न क्लाइंट विभिन्न गंतव्यों तक पहुँच सकते हैं।
रूटिंग परिवर्तन स्थिर होने तक पुराने वातावरण को उपलब्ध रखें, इस बारे में जानबूझकर नीति के साथ कि यह अभी भी लेखन स्वीकार कर सकता है या नहीं। डुप्लिकेट कतार उपभोक्ता या निर्धारित कार्य चलाने से बचें जब तक एप्लिकेशन इसके लिए डिज़ाइन न किया गया हो। दोनों पक्षों पर अनुरोधों की निगरानी करें और स्वतंत्र क्लाइंट से इच्छित होस्टनाम, TLS प्रमाणपत्र और एप्लिकेशन संस्करण की पुष्टि करें।
लेखन शुरू होने के बाद रोलबैक परिभाषित करें
नए सिस्टम के परिवर्तन स्वीकार करने से पहले, ट्रैफ़िक लौटाना अपेक्षाकृत सरल हो सकता है। उसके बाद, अकेला DNS उत्क्रमण कार्य खो सकता है या दो परस्पर विरोधी इतिहास बना सकता है। परिभाषित करें कि नए बनाए गए रिकॉर्ड और अपलोड कैसे संरक्षित या मिलाए जाएँगे। यदि एप्लिकेशन उन्हें सुरक्षित रूप से मर्ज नहीं कर सकता, तो पुरानी प्रति पर तात्कालिक वापसी की तुलना में नियंत्रित रखरखाव अवधि बेहतर हो सकती है।
वे शर्तें निर्धारित करें जिनके लिए माइग्रेशन रोकना आवश्यक है, और निर्णय स्वामी को पहुँच योग्य रखें। परियोजना के प्रतिधारण नियमों के तहत लॉग और उपयोगी प्रमाण सुरक्षित रखें। केवल इसलिए पुरानी मशीन या उसकी स्वतंत्र रिकवरी प्रति न हटाएँ कि होम पृष्ठ एक बार लोड हुआ था। प्रतिधारण अवधि में सहमत सत्यापन और रोलबैक आवश्यकताएँ शामिल होनी चाहिए।
परिचालन जाँचों के साथ माइग्रेशन समाप्त करें
कटओवर के बाद, बैकअप, अलर्ट, प्रमाणपत्र नवीनीकरण, निर्धारित कार्य और एक्सेस रिकवरी सत्यापित करें। पुष्टि करें कि निगरानी किया गया होस्ट नया गंतव्य है और उत्पादन में कोई परीक्षण इंटीग्रेशन शेष नहीं है। सामान्य ट्रैफ़िक के तहत एप्लिकेशन त्रुटियों और उपयोगकर्ता-दृश्य समय की समीक्षा करें। इन्वेंटरी और रनबुक अपडेट करें ताकि अगले प्रशासक को यह अनुमान न लगाना पड़े कि क्या बदला।
SwissOctet के समर्पित परिवार अलग-अलग भौतिक कॉन्फ़िगरेशन प्रदान करते हैं, लेकिन चुनी गई सेवा के लिए माइग्रेशन कार्य और प्रबंधित सहायता की पुष्टि आवश्यक है। उपयुक्त संसाधन चुनने के लिए कैटलॉग का उपयोग करें, फिर अपने एप्लिकेशन के डेटा के आसपास एक परीक्षित स्थानांतरण बनाएँ। माइग्रेशन तब पूरा होता है जब सेवा और उसकी रिकवरी प्रक्रिया गंतव्य पर काम करती है, न कि केवल तब जब फ़ाइलें स्थानांतरित हो गई हों।
आपकी व्यावहारिक चेकलिस्ट।
- डेटा, कार्य, सीक्रेट और इंटीग्रेशन की सूची बनाएँ।
- शेड्यूल करने से पहले वितरित गंतव्य सत्यापित करें।
- सुरक्षित बाहरी इंटीग्रेशन के साथ पूर्वाभ्यास करें।
- डेटाबेस और अपलोड स्थिरता परिभाषित करें।
- रूटिंग संक्रमण और डुप्लिकेट-कार्य रोकथाम की योजना बनाएँ।
- नए लेखन के लिए रोलबैक निर्दिष्ट करें।
- कटओवर के बाद बैकअप और निगरानी सत्यापित करें।
महत्वपूर्ण विवरण।
क्या मैं एप्लिकेशन निर्देशिका कॉपी करके माइग्रेट कर सकता हूँ?+
केवल तभी जब यह सेवा की आवश्यक हर चीज़ को कैप्चर करता हो और स्थिरता बनाए रखता हो। डेटाबेस, अपलोड, कार्य, सीक्रेट और कॉन्फ़िगरेशन आमतौर पर अलग ध्यान देने की आवश्यकता रखते हैं।
क्या DNS TTL घटाने से कटओवर तत्काल हो जाता है?+
नहीं। पहले कैश किए गए उत्तर उनके पहले के जीवनकाल तक बने रह सकते हैं, और क्लाइंट अलग-अलग समय पर अपडेट हो सकते हैं।
क्या रोलबैक केवल DNS को पुराने सर्वर की ओर इंगित करना है?+
नए सर्वर के लेखन स्वीकार करने के बाद नहीं। ट्रैफ़िक लौटाने से पहले उन रिकॉर्ड और फ़ाइलों को ध्यान में रखना आवश्यक है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- PostgreSQL: बैकअप और पुनर्स्थापन www.postgresql.org
- PostgreSQL: SQL डंप स्थिरता और पुनर्स्थापन www.postgresql.org
- Apache: वर्चुअल होस्ट दस्तावेज़ httpd.apache.org
- Cloudflare DNS: टाइम टू लाइव developers.cloudflare.com
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।