एक दोष सहिष्णु प्रणाली का निर्माण

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

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

कहाँ से शुरू करें?

सॉफ्टवेयर से लेकर हार्डवेयर तक - सबसे पहले, आपको अपने एप्लिकेशन के आर्किटेक्चर को अच्छी तरह से जानना होगा, ताकि आपके सिस्टम के पूरे स्टैक को कवर किया जा सके।

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

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

कार्यान्वयन के तरीके

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

दूसरा तरीका प्रोग्राम को प्रत्येक घटक और उनके इंटरैक्शन के लिए गलती सहिष्णुता को लागू करना है। आपके सिस्टम को अधिक स्थिर बनाने के लिए कई अलग-अलग तकनीकें हैं। आइए उनमें से कुछ को देखें।

निम्न स्तर की दोष सहिष्णु सेवाएं

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

विफलता का एकल बिंदु

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

अतिरेक (अतिरेक)

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

सक्रिय सक्रिय

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

सक्रिय निष्क्रिय

यह रणनीति केवल एक लगातार काम करने वाले घटक का प्रतिनिधित्व करती है, जिसके गिरने की स्थिति में दूसरा व्यक्ति स्वचालित रूप से उठता है, राज्य को पुनर्स्थापित करता है और सभी काम करता है। उदाहरण के लिए, ऐसी कार्यक्षमता TIBCO EMS में है। यदि आप इस विकल्प को सक्षम करते हैं, तो ईएमएस के काम करने की आवृत्ति पर लगातार नजर रखी जाती है, और विफलता के मामले में, ईएमएस का दूसरा उदाहरण लॉन्च किया जाता है, सभी अपठित संदेश भेजता है और नए प्राप्त करना शुरू करता है। लेकिन यहां यह समझना बहुत महत्वपूर्ण है कि आपको इसके लिए क्या भुगतान करना होगा। एक परियोजना में जहां हमने इस विकल्प को चालू किया, इस घटक का अधिकतम प्रवाह लगभग दो बार गिर गया।

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

लोड संतुलन

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

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

सुरक्षात्मक प्रोग्रामिंग (संवेदनशील कोडिंग)

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

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

पुनर्संयोजन। विशेष रूप से फ़ायरवॉल वाले सिस्टम पर , फिर से कनेक्ट करना सुनिश्चित करें।

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

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

InfrastructureError । यदि आपके एप्लिकेशन में कोई त्रुटि हुई है, जिससे आप पुनर्प्राप्त नहीं कर सकते हैं, उदाहरण के लिए जावा में OutOfMemoryError, तो आप एप्लिकेशन को रोकने और इसे फिर से शुरू करने का प्रयास कर सकते हैं। इसे तनुकी जावा सर्विस रैपर जैसे टूल का उपयोग करके स्वचालित किया जा सकता है, जिसके बारे में मैंने यहां विस्तार से लिखा है ।

NullPointerException । हालांकि, शून्य के लिए किसी विधि या कंस्ट्रक्टर के प्रत्येक इनपुट पैरामीटर की जाँच करके पागल मत होइए। इसे एक नियम के रूप में लेने के लिए बेहतर है: एक सिस्टम पर घटकों के बीच कभी भी अशक्त न करें।

इन्फ्रास्ट्रक्चर अलगाव

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

निगरानी

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

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

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

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

समस्या प्रबंधन

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

निष्कर्ष में

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