VSphere प्रतिकृति के साथ क्लाउड बैकअप

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



क्लाउड प्रौद्योगिकियों के विकास के साथ, एक सार्वजनिक क्लाउड में वर्चुअल मशीनों की मेजबानी के लिए अत्यधिक सुलभ सेवाओं के पक्ष में अपने स्वयं के बुनियादी ढांचे को छोड़ने के लिए संगठनों की बढ़ती संख्या तैयार है।

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

क्या सार्वजनिक क्लाउड में बैकअप साइट रखने की तकनीकी संभावना है? परियोजना को लागू करते समय आप किन कठिनाइयों का सामना करेंगे? नेटवर्क की विशालता और क्लाउड सेवाओं के संभावित उपभोक्ताओं के बीच इस तरह के सवाल लगातार बढ़ रहे हैं। सेवा प्रदाता मल्टी-टेनेंसी के बारे में, संसाधन दक्षता के बारे में, संगतता के बारे में और नेटवर्क अवसंरचना आवश्यकताओं के बारे में इस प्रश्न को जोड़ते हैं।

क्लासिक डीआरएस समाधान

बैकअप साइट या डेटा रिकवरी साइट बनाने के लिए क्लासिक समाधान ने हमेशा अपनी जटिलता के साथ आम आदमी की कल्पना को मारा है। सबसे पहले, यह संबंधित डेटा प्रतिकृति, जिसे भंडारण के माध्यम से किया जाना था, जो बदले में:


• भंडारण क्षमताओं के लिए बार बढ़ा,
• अनुकूलता सुनिश्चित करने के लिए भंडारण निर्माताओं की पसंद पर प्रतिबंध लगाया,
• महंगे लाइसेंस की खरीद की आवश्यकता है।

और बैकअप और रिकवरी के प्रबंधन के लिए सॉफ्टवेयर के पास (और इस समय) एक महत्वपूर्ण लागत है। इस तरह के एक समाधान का एक महत्वपूर्ण उदाहरण VMware साइट रिकवरी मैनेजर है। हालांकि, प्रौद्योगिकी अभी भी खड़ा नहीं है, और बाजार में बढ़ती प्रतिस्पर्धा निर्माताओं को पुरानी समस्याओं को हल करने के नए अवसरों को खोलने के लिए मजबूर कर रही है।

नया दृष्टिकोण - हाइपरविजर-स्तरीय प्रतिकृति

इन नई विशेषताओं में से एक VMware vSphere प्रतिकृति प्रौद्योगिकी थी, जो VMware साइट रिकवरी प्रबंधक संस्करण 5.0 के भाग के रूप में शुरू हुई, और फिर vSphere 5.1 वर्चुअलाइजेशन प्लेटफ़ॉर्म में शामिल, नि: शुल्क और लगभग सभी संस्करणों में नि: शुल्क!

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

लेकिन भंडारण से डीकोपिंग ने न केवल प्रतिकृति प्रणालियों की लागत और सरलीकरण को कम किया - इसने "असंगत" भंडारण प्रणालियों और स्वतंत्र रूप से प्रबंधित इन्फ्रास्ट्रक्चर के बीच प्रतिकृति के लिए एक महत्वपूर्ण अवसर प्रदान किया। और, वास्तव में, इसने क्लाउड में बैकअप साइट के सरल और प्रभावी कार्यान्वयन का मार्ग प्रशस्त किया।

VSphere प्रतिकृति प्रौद्योगिकी

VSphere प्रतिकृति प्रौद्योगिकी उपयोगकर्ता के दृष्टिकोण से बहुत सरल है। मुख्य साइट पर वर्चुअल मशीन डिस्क से किए गए परिवर्तनों को हाइपरविज़र द्वारा मॉनिटर किया जाता है, और फिर, निर्दिष्ट RPO (रिकवरी पॉइंट ऑब्जेक्टिव) नीतियों के अनुसार, वे समय-समय पर बैकअप साइट के साथ सिंक्रनाइज़ किए जाते हैं। इस स्थिति में, सिंक्रनाइज़ेशन को दोनों साइटों में स्थित वीआर उपकरण की सेवा आभासी मशीनों द्वारा नियंत्रित किया जाता है, और साइटों के बीच डेटा हाइपरविजर से मुख्य साइट पर बैकअप एक पर वीआर उपकरण में स्थानांतरित किया जाता है।



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

व्यवहार में vSphere प्रतिकृति का उपयोग करना

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

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

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

चैनलों के संगठन को प्रदाता के आधार पर किया गया था, जो पहले से ही क्लाइंट को "वर्चुअल स्विच" के आधार पर शाखाओं के संयोजन की सेवाएं प्रदान करता था, जिसमें रूटिंग प्रदान करने के लिए और मौजूदा ग्राहक बुनियादी ढांचे में बैकअप साइट प्रदान करने के लिए, सेवा प्रदाता के लिए एक नया लिंक जोड़ा गया था।



जब प्रतिकृति ऐसी योजना में कार्य कर रही है (प्रत्यक्ष या रिवर्स), तो राउटर का उपयोग करके ट्रैफ़िक सेवा प्रदाता की साइट पर या क्लाइंट के मुख्य कार्यालय को भेज दिया जाता है, विफलता के मामले में, क्लाइंट के सर्वर नेटवर्क के लिए प्रवेश द्वार जिसमें क्लाइंट की साइटों पर वर्चुअल मशीन स्थित हैं। इस प्रकार, पूरा बुनियादी ढांचा वर्चुअल मशीनों पर नेटवर्क को फिर से व्यवस्थित किए बिना सेवा प्रदाता की साइट पर काम कर रहा है।

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

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

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

निष्कर्ष

क्या वर्तमान में क्लाउड में बैकअप साइट संभव है?

मूल उत्तर हां है, यह संभव है।

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

हालांकि, दुनिया अभी भी स्थिर नहीं है, और पहली परियोजना आमतौर पर नए लोगों द्वारा पीछा की जाती है, और विक्रेताओं के समर्थन के साथ, मुझे यकीन है कि क्लाउड में बैकअप साइटों को व्यवस्थित करने का अभ्यास जल्द ही व्यापक हो जाएगा।