एक उच्च उपलब्धता और आपदा वसूली योजना की योजना बनाना और उसे चालू करना जो सभी सेवा स्तर के समझौतों को पूरा करती है, एक गैर-तुच्छ उपक्रम है और इसके लिए SQL सर्वर की मूल शक्तियों और कमजोरियों की बहुत स्पष्ट समझ की आवश्यकता होती है। सुविधाओं के संयोजन के खिलाफ आवश्यकताओं का मिलान करते समय, कुछ महत्वपूर्ण विवरणों पर प्रकाश डाला जा सकता है, और इस पोस्ट में मैं कुछ सामान्य विकृतियों और बुरी धारणाओं के माध्यम से चलूंगा जो एक समाधान में रेंग सकती हैं - अंततः हमें निशान से चूकने का कारण बनती हैं हमारे पुनर्प्राप्ति बिंदु और पुनर्प्राप्ति समय के उद्देश्यों पर। विकृतियों या आत्म-भ्रम के कुछ उदाहरणों का मैं यहां विस्तार से वर्णन कर रहा हूं जिन्हें विभिन्न विशेषताओं में सामान्यीकृत किया जा सकता है और कुछ विशेषता-विशिष्ट हैं।
"हमने अपनी आपदा पुनर्प्राप्ति योजना का परीक्षण तब किया जब हमने पहली बार अपना प्रोजेक्ट लॉन्च किया था और हम जानते हैं कि यह काम करेगा"
मैंने उन ग्राहकों के साथ काम किया है, जिन्हें वास्तव में उनका आपदा पुनर्प्राप्ति दृष्टिकोण "सही" मिला है - एक बार। लेकिन एक बार जब सभी ने समाधान की प्रभावशीलता में विश्वास महसूस किया, तो कोई अन्य आपदा वसूली अभ्यास फिर से नहीं किया गया। बेशक - इस बीच डेटा टियर और एप्लिकेशन समय के साथ बदलते रहते हैं। वे परिवर्तन नई वस्तुओं और प्रक्रियाओं का परिचय देते हैं जो अनुप्रयोग के लिए महत्वपूर्ण हैं। और भले ही लॉन्च के बाद सब कुछ स्थिर रहे, फिर भी आपको कर्मियों के कारोबार और अलग-अलग कौशल सेटों का हिसाब देना होगा। क्या आज का कर्मचारी आपदा वसूली अभ्यास सफलतापूर्वक कर सकता है? और यहां तक कि सर्वश्रेष्ठ कर्मचारियों को भी निरंतर अभ्यास की आवश्यकता होती है।
"हमें कोई डेटा हानि नहीं होगी क्योंकि हम सिंक्रोनस डेटाबेस मिररिंग का उपयोग कर रहे हैं"
मान लें कि आप दो SQL सर्वर इंस्टेंस के बीच सिंक्रोनस डेटाबेस मिररिंग का उपयोग कर रहे हैं, प्रत्येक इंस्टेंस एक अलग डेटा सेंटर में है। इस उदाहरण में, मान लें कि डेटा केंद्रों के बीच कुछ मील के साथ एक सिंक्रोनस डेटाबेस मिररिंग सत्र होने के बावजूद लेनदेन विलंबता स्वीकार्य है। आपके पास मिश्रण में कोई गवाह नहीं है क्योंकि आप डेटाबेस मिरर फ़ेलओवर को मैन्युअल रूप से नियंत्रित करना चाहते हैं।
अब मान लें कि आपका आपदा पुनर्प्राप्ति डेटा केंद्र चला गया है - लेकिन आपका प्राथमिक डेटा केंद्र अभी भी उपलब्ध है। आपका मुख्य डेटाबेस मिरर डेटाबेस से डिस्कनेक्ट हो गया है, लेकिन यह अभी भी कनेक्शन और डेटा संशोधनों को स्वीकार कर रहा है। अब "कोई डेटा हानि नहीं" आवश्यकता के बारे में क्या? यदि डिस्कनेक्ट किए गए प्रिंसिपल के खिलाफ एक और घंटे के लिए लेन-देन चलता है, तो प्राथमिक डेटा केंद्र भी खो जाने पर आपकी क्या योजना है?
"हमारे व्यवसाय के स्वामी का कहना है कि हम 12 घंटे तक का डेटा खो सकते हैं"
किसी संगठन में कुछ प्रश्नों को एक से अधिक बार और एक से अधिक व्यक्तियों से पूछना महत्वपूर्ण है। यदि कोई आपसे कहता है कि "12 घंटे का डेटा हानि स्वीकार्य है" - तो उनसे फिर से पूछें, या उनसे पूछें कि उस डेटा हानि का परिणाम क्या होगा। अन्य लोगों से भी पूछें। वे आपको बहुत सख्त आवश्यकता दे सकते हैं। मैंने पाया है कि पुनर्प्राप्ति बिंदु उद्देश्यों के लिए कुछ बातचीत और कुछ विचारशील, जानबूझकर चर्चाओं से अधिक की आवश्यकता होती है।
"हम [डेटाबेस मिररिंग या उपलब्धता समूह] का उपयोग कर रहे हैं और इसलिए आपदा की स्थिति में हमें जो चाहिए वह हमें कवर किया जाता है"
डेटाबेस मिररिंग और उपलब्धता समूहों का उपयोग निश्चित रूप से डेटाबेस स्तर पर आपकी सुरक्षा के लिए किया जा सकता है, लेकिन बाकी सब चीजों के बारे में क्या? आपके लॉगिन के बारे में क्या? एसएसआईएस पैकेज? नौकरियां? गैर-पूर्ण पुनर्प्राप्ति मॉडल डेटाबेस? लिंक किए गए सर्वर?
"हम SQL सर्वर सुविधा XYZ का उपयोग कर रहे हैं, इसलिए हम कोई भी इन-फ़्लाइट लेनदेन नहीं खोएंगे"
नहीं माफ़ करो। जबकि कुछ विशेषताएं पारदर्शी पुनर्निर्देशन की अनुमति देती हैं, यह विफलता के समय खुले लेनदेन को बनाए रखने और जारी रखने के समान नहीं है। कोई SQL सर्वर सुविधा आज यह कार्यक्षमता प्रदान नहीं करती है।
"इस एप्लिकेशन के लिए डेटा टियर का समर्थन करने वाली टीम SQL सर्वर सुविधा XYZ से नफरत करती है, लेकिन हम इसके साथ आगे बढ़ रहे हैं क्योंकि बाहरी सलाहकार ने हमें यही सलाह दी थी"
हालांकि यह अच्छा होगा यदि लोग SQL सर्वर में सुविधाओं के आसपास विशिष्ट पूर्वाग्रह विकसित नहीं करते हैं, तो अक्सर ऐसा नहीं होता है। यदि आप किसी ऐसे कर्मचारी पर समाधान थोपने का प्रयास करते हैं जो उनके साथ नहीं है, तो आप पूर्व-निर्धारित विफलता का जोखिम उठा रहे हैं। एचए/डीआर अभ्यासों के हिस्से के रूप में मैंने अतीत में मदद की है, मुझे हमेशा विशिष्ट विशेषताओं के साथ लोगों के पिछले अनुभवों के बारे में सुनने में दिलचस्पी है। उदाहरण के लिए, कुछ कंपनियां सैकड़ों फ़ेलओवर क्लस्टर इंस्टेंस का बहुत अच्छी तरह से लाभ उठाती हैं - जबकि अन्य पिछले संस्करणों के खराब अनुभवों के कारण उनसे बचती हैं। समाधान की योजना बनाते समय, आप इतिहास या कर्मचारियों के पूर्वाग्रहों को अनदेखा नहीं कर सकते जो अंततः अनुशंसित समाधान को लागू करने और समर्थन करने के लिए जिम्मेदार होंगे।
"डीबीए के रूप में, मैं तय करता हूं कि डेटा स्तर के लिए कौन सी एचए/डीआर तकनीक का उपयोग करना है, इसलिए हम आगे बढ़ते हुए उपलब्धता समूहों का उपयोग करने जा रहे हैं"
एक डेटाबेस व्यवस्थापक संभावित रूप से अन्य टीमों के साथ कम या बिना किसी भागीदारी के डेटाबेस मिररिंग सेट कर सकता है। अब उपलब्धता समूहों के साथ, भले ही एक डेटाबेस व्यवस्थापक यह सब अपने आप कर सकता है, वे ऐसा करने के लिए नासमझ हो सकते हैं। आखिरकार - यदि आप आपदा पुनर्प्राप्ति उद्देश्यों के लिए उपलब्धता समूहों को तैनात कर रहे हैं, तो आप चाहते हैं कि आपदा पुनर्प्राप्ति ऑपरेशन में शामिल सभी लोग आपके समाधान और सफलतापूर्वक ऑनलाइन वापस आने और डेटा पुनर्प्राप्त करने के लिए आवश्यक आवश्यकताओं से अवगत हों। उपलब्धता समूहों के साथ आपको विंडोज सर्वर फेलओवर क्लस्टर, कोरम कॉन्फ़िगरेशन, नोड वोट, उपलब्धता समूह श्रोता और बहुत कुछ के बारे में सोचना होगा। यदि आपको समाधान की सुविधा के लिए अन्य लोगों की आवश्यकता है, तो सुनिश्चित करें कि वे प्रारंभिक अनुशंसा में शामिल हैं।
"हम उपलब्धता समूहों का उपयोग कर रहे हैं ताकि हमारे पढ़ने-लिखने की प्रतिकृति के बंद होने की स्थिति में हम केवल-पढ़ने के लिए उपलब्धता प्राप्त कर सकें"
यह "क्या होगा" परिदृश्य का सिर्फ एक उदाहरण है। कार्यक्षमता के किसी भी कार्यान्वयन के साथ, आप विफलता के विभिन्न तरीकों की कल्पना करना चाहेंगे - और फिर यह सुनिश्चित करने के लिए इसका परीक्षण करना सुनिश्चित करें कि आपकी आवश्यकताओं को अभी भी पूरा किया जा रहा है। उदाहरण के लिए - यदि आपको लगता है कि आपका SQL Server 2012 उपलब्धता समूह एसिंक्रोनस रीड-ओनली प्रतिकृतियां उपलब्ध होंगी, जब रीड-राइट प्रतिकृति उपलब्ध नहीं होगी, तो आपको Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections उत्पादन में संदेश।
"हमने SQL सर्वर सुविधा XYZ का परीक्षण किया, और फ़ेलओवर तेज़ था, इसलिए हमने स्थापित किया है कि हम अपने पुनर्प्राप्ति समय के उद्देश्यों को आसानी से पूरा कर सकते हैं"
मान लें कि आप उपयोगकर्ता-डेटाबेस स्तर की उच्च उपलब्धता के लिए डेटाबेस मिररिंग का उपयोग करने का निर्णय लेते हैं। आप त्वरित विफलता चाहते हैं (सेकंड में मापा जाता है), और आप वास्तव में परीक्षण के दौरान त्वरित विफलता देखते हैं। लेकिन क्या यह एक यथार्थवादी परीक्षा थी? क्या आप एक महत्वपूर्ण कार्यभार बढ़ा रहे थे? डेटाबेस मिररिंग के उदाहरण में, आपके फ़ेलओवर ऑपरेशन का सबसे लंबा हिस्सा फिर से संचालन के लिए हो सकता है। यदि आप यथार्थवादी कार्यभार नहीं चला रहे हैं, तो आप वास्तव में यह नहीं कह सकते कि आपका विफलता वास्तव में "तेज़" होगा।
"यदि हमारे पास कोई आपदा है और हमें डेटा को बचाने और समेटने की आवश्यकता है, तो समय आने पर हम इसका पता लगा लेंगे"
यह कठिन है। मान लें कि आपके पास एक आपदा है और आपको अपने द्वितीयक डेटा केंद्र को चालू करने की आवश्यकता है। आप द्वितीयक डेटा केंद्र में सबसे महत्वपूर्ण डेटाबेस के लिए सेवा को बाध्य करने का निर्णय लेते हैं और अब आपके पास डेटा संशोधनों के वंश में एक विभाजन है (प्राथमिक डेटा केंद्र में कुछ असंगत पंक्तियाँ, और अब द्वितीयक डेटा केंद्र में नए संशोधन)। अंततः आपका प्राथमिक डेटा केंद्र ऑनलाइन लाया जाता है - लेकिन अब आपके पास डेटा है जिसे समग्र HA/DR समाधान को फिर से स्थापित करने से पहले बचाया और समेटने की आवश्यकता है। आप क्या करते हैं? आप क्या कर सकते हैं? यह चर्चा शायद ही कभी आसान होती है और कई कारकों पर निर्भर हो सकती है जैसे कि आपके द्वारा खरीदे गए सॉफ़्टवेयर पैकेज, डेटा स्तर की जटिलता, और आपके निपटान में डेटा अभिसरण उपकरण। वास्तव में, चर्चा आमतौर पर इतनी कठिन होती है कि लोगों के पास यह बिल्कुल नहीं होता है। लेकिन यदि डेटा आपके लिए एक द्वितीयक डेटा केंद्र स्थापित करने के लिए पर्याप्त महत्वपूर्ण है, तो चर्चा के एक प्रमुख भाग में यह शामिल होना चाहिए कि डेटा को कैसे बचाया जाए और एक आपदा होने के बाद इसे कैसे समेटा जाए।
सारांश
इस लेख में कुछ उदाहरण शामिल थे कि कैसे हम खुद को यह सोचकर भ्रमित कर सकते हैं कि एक समाधान पूरी तरह से उनकी आवश्यकताओं को पूरा कर रहा है। हालांकि ऐसा करना मानव स्वभाव है - जब डेटा हानि और व्यवसाय निरंतरता की बात आती है, तो हमारी नौकरियां इस बात पर निर्भर करेंगी कि हम अपने स्वयं के विश्वासों और मान्यताओं का परीक्षण करने में अधिक आक्रामक हैं।
