Qrator फ़िल्टर नेटवर्क कॉन्फ़िगरेशन प्रबंधन प्रणाली

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

Qrator Labs एक वैश्विक रूप से वितरित हमले शमन नेटवर्क का प्रबंधन करती है। हमारा नेटवर्क Anycast के सिद्धांत पर काम करता है, और सबनेट की घोषणा बीजीपी के माध्यम से की जाती है। पृथ्वी के कई क्षेत्रों में शारीरिक रूप से स्थित एक बीजीपी किसी भी प्रकार का नेटवर्क होने के नाते, हम इंटरनेट - टियर -1 ऑपरेटरों के करीब नाजायज ट्रैफिक को प्रोसेस और फ़िल्टर कर सकते हैं।

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

शुरुआत में वर्ड था। यह जल्दी से एक अद्यतन की जरूरत में एक संचार प्रोटोकॉल बन गया।

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

परिणामस्वरूप, हम निम्नलिखित योजना के साथ आए:

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

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


प्राग से सिंगापुर तक एमटीआर


हाँग काँग के लिए एक ही बात

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

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

हाल ही में स्थिर डिजाइन

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

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

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

दो-स्तरीय परिवहन वास्तुकला

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

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

हमने RPC और कई भाषाओं के समर्थन के कारण थ्रिफ़्ट फ्रेमवर्क लिया। हमेशा की तरह, क्लाइंट और सर्वर आसान भाग हैं। हालांकि, राउटर एक कठिन नट निकला, आंशिक रूप से हमारे विकास के दौरान तैयार समाधान की कमी के कारण।

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

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

Msgpack JSON का एक एनालॉग है, लेकिन तेज और कम। यह एक बाइनरी डेटा क्रमांकन प्रारूप है जो कई भाषाओं के बीच डेटा के आदान-प्रदान की अनुमति देता है।

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

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

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

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

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

उदाहरण के लिए:

---
selector: "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


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

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

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

लेखन सामग्री के लिए धन्यवाद VolanDamrod , serenheit , NoN ।

पोस्ट का अंग्रेजी संस्करण ।