टारनटूल नेटवर्क से बाहर निकलना। ट्रैफ़िक को फ़िल्टर करते समय नोड सिंक्रनाइज़ेशन

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

आप लिंक के माध्यम से रिपोर्ट का सार भी पढ़ सकते हैं, और स्पॉइलर के नीचे का वीडियो देख सकते हैं।


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



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

क्लस्टर के अंदर क्या होता है

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

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

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

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

क्लस्टर के बीच

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

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

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

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

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

नोड्स के बीच आंतरिक बातचीत

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

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

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

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

विकल्प और परिणाम

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

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

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

नीचे दिए गए आरेख में, हमने क्लस्टर के अंदर एक डेटाबेस जोड़ा, जिसमें आंतरिक संचार के लिए राज्यों को संग्रहीत किया जाता है।

डेटाबेस जोड़ें

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

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



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

समस्याओं

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

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

टारेंटूल अतुल्यकालिक प्रतिकृति मुद्दे बहुत अधिक जटिल थे। प्रारंभ में, हमने मास्टर / मास्टर नहीं लिया, लेकिन ऑपरेटिंग मास्टर / दास के लिए एक अधिक पारंपरिक मॉडल। और जब तक दास ने लंबे समय तक मास्टर लोड पर कब्जा नहीं किया तब तक सब कुछ ठीक काम करता था। नतीजतन, एक्सपायरीड ने काम किया और मास्टर पर डेटा हटा दिया, लेकिन दास पर यह नहीं था। तदनुसार, जब हमने मास्टर से दास और पीठ पर कई बार स्विच किया, तो दास पर इतना डेटा जमा हुआ कि कुछ बिंदु पर सब कुछ टूट गया। तो पूर्ण दोष सहिष्णुता के लिए, मुझे अतुल्यकालिक मास्टर / मास्टर प्रतिकृति पर स्विच करना पड़ा।

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

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

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

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

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

अंत में, सी के लिए टारनटूल चालक के साथ कठिनाइयाँ बनी रहीं। जब हमने सेवा को तोड़ दिया (उदाहरण के लिए, दौड़ की स्थिति के कारण), तो कारण और डिबग को खोजने में लंबा समय लगा। इसलिए, हमने सिर्फ अपना टारनटूल ड्राइवर लिखा। प्रॉडक्शन में टेस्टिंग, डिबगिंग और रनिंग के साथ-साथ प्रोटोकॉल को लागू करने में हमें पांच दिन लगे, लेकिन नेटवर्क के साथ काम करने के लिए हमारे पास पहले से ही अपना कोड था।

समस्याएँ बाहर

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

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

नीचे एक इंटरेक्शन इंटरफ़ेस के साथ एक क्लस्टर का पहले से ही विस्तृत आरेख है।

मैं क्या सुधार और जोड़ना चाहता हूं

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

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

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

निष्कर्ष

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

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

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