Vipnet फेलओवर क्रिप्टो गेटवे या गलती सहिष्णुता को लागू करने के लिए कैसे नहीं

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

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

मैं ध्यान देता हूं कि विपनेट समन्वयक लिनक्स स्वयं खराब नहीं है, और गर्म स्पेयर योजना ही सब कुछ खराब कर देती है।

पूरे क्लस्टर, नेटवर्क के अन्य कंप्यूटरों के दृष्टिकोण से, इसके प्रत्येक नेटवर्क इंटरफेस पर एक आईपी पता है। इस पते में एक सर्वर है जो वर्तमान में सक्रिय मोड में है। निष्क्रिय मोड में एक सर्वर का एक अलग आईपी पता होता है जिसका उपयोग अन्य कंप्यूटरों द्वारा क्लस्टर के साथ संवाद करने के लिए नहीं किया जाता है। सक्रिय मोड पते के विपरीत, निष्क्रिय मोड में प्रत्येक सर्वर का प्रत्येक इंटरफेस पर अपना पता होता है, दो सर्वर के लिए ये पते मेल नहीं खाते हैं।

Failover.ini config में 3 प्रकार के पैरामीटर सेक्शन होते हैं। [चैनल] अनुभाग आरक्षित इंटरफेस के आईपी पते का वर्णन करता है:

[channel] device= eth1 activeip= 192.168.10.50 passiveip= 192.168.10.51 testip= 192.168.10.1 ident= if-1 checkonlyidle= yes 

[नेटवर्क] अनुभाग बैकअप विकल्पों का वर्णन करता है:

 [network] checktime= 10 timeout= 2 activeretries= 3 channelretries= 3 synctime= 5 fastdown= yes 

[Sendconfig] में, दूसरे सर्वर के नेटवर्क इंटरफ़ेस का पता लिखा जाता है, जिस पर क्लस्टर ऑपरेशन को सिंक्रनाइज़ किया जाएगा:

 [sendconfig] device= eth0 

फिर, मैं प्रलेखन से बैकअप एल्गोरिथ्म दे दूँगा:

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

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

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

पहली नज़र में, सब कुछ सही है, जैसे ही सक्रिय सर्वर के साथ कोई समस्या होती है, यह रिबूट होता है, और निष्क्रिय इसकी जगह लेता है। व्यवहार में हमारे पास क्या है?

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

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

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

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

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

सामान्य तौर पर, मेरी सलाह यह है कि यदि आपको टिक के लिए एक दोष-सहिष्णु क्रिप्टो गेटवे की आवश्यकता नहीं है, तो यह बेहतर है कि फाइलर के साथ परेशान न करें, लेकिन सामान्य विपनेट लिनक्स समन्वयक का उपयोग करने के लिए, यह अपने आप में काफी विश्वसनीय है, खासकर यदि आप इसे नहीं छूते हैं;)