दोष सहिष्णुता: उपकरण विफलता की स्थिति में विश्वसनीय सेवा कैसे प्रदान करें

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

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



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

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


आमतौर पर, एक वेब एप्लिकेशन आर्किटेक्चर को संरचित किया जाता है (और हमारी वास्तुकला कोई अपवाद नहीं है):



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

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

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

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

हाल के वर्षों में, हम एक डेटाबेस के रूप में टारेंटयुला का उपयोग कर रहे हैं (यह हमारी खुली स्रोत परियोजना है, एक बहुत तेज़, सुविधाजनक डेटाबेस जो संग्रहीत प्रक्रियाओं का उपयोग करके आसानी से विस्तारित किया जा सकता है। वेबसाइट http://tarantool.org देखें)।

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

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

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

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

वैकल्पिक रूप से, आप प्रत्येक डेटा सेंटर में डेटा की एक मास्टर कॉपी रख सकते हैं और सॉफ़्टवेयर को इस तरह से लिख सकते हैं कि इस कॉन्फ़िगरेशन में सब कुछ सही ढंग से काम करता है। लेकिन अधिकांश कार्यों के लिए, इस तरह का समाधान बस शानदार है।

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

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

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

अनुरोधों के बड़े प्रवाह के कारण, कुछ डेटाबेस सर्वरों की अयोग्यता के बारे में ज्ञान जल्दी से अद्यतन किया जाता है, और यह आपको एक बदलती स्थिति में जितनी जल्दी हो सके प्रतिक्रिया करने की अनुमति देता है।



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

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

हम वहां रुकने की योजना नहीं बनाते हैं और कुछ स्पष्ट कमियों को खत्म करने की कोशिश करेंगे:

1) एक नेटवर्क टाइमआउट के मामले में, हम प्रतिकृति के लिए एक अनुरोध भेजने की कोशिश कर रहे हैं। एक संशोधित अनुरोध के मामले में, यह एक व्यर्थ प्रयास है, क्योंकि प्रतिकृति इसे संसाधित करने में सक्षम नहीं होगी। यह समझ में आता है कि प्रतिकृति को एक प्राथमिकता के लिए संशोधित कमांड नहीं भेजना है। इसे कमांड प्रकारों के मैनुअल कॉन्फ़िगरेशन के स्तर पर हल किया जाता है।

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

3) खैर, निश्चित रूप से, हम टारेंटयुला तुल्यकालिक मास्टर-मास्टर-प्रतिकृति के डेवलपर्स से उम्मीद करते हैं। यह आपको कई मास्टर प्रतियों के बीच समान रूप से अनुरोधों को वितरित करने और सर्वरों में से एक अनुपलब्ध होने पर भी सफलतापूर्वक अनुरोधों को संसाधित करने की अनुमति देगा!

दिमित्री इस्किन, अग्रणी मेल.उ मेल डेवलपर