Qrator फ़िल्टरिंग नेटवर्क कॉन्फ़िगरेशन डिलीवरी सिस्टम

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

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

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

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

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

यहाँ हम इस प्रणाली को लेकर आए हैं:

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

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


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


हांगकांग के लिए अनुरेखक के साथ एक ही दूसरा स्क्रीनशॉट

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

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

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

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

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

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

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

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

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

हमने इसकी RPC और एक ही बार में कई भाषा समर्थन के कारण थ्रिफ़्ट फ्रेमवर्क लिया। हमेशा की तरह, आसान भागों का निर्माण आसान है: क्लाइंट और सर्वर। हालांकि, राउटर क्रैक करने के लिए काफी कठोर अखरोट था, उस समय तैयार उपयोग के समाधान की अनुपस्थिति के कारण भाग में था।

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

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

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

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

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

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

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

कॉन्फिग फाइल को रेंडर करने के लिए, हमें जेमस्पथ रिक्वेस्ट की जरूरत है, पाथ और डेस्टिनेशन फाइल के लिए टेम्प्लेट, खुद ही कॉन्फिग के लिए टेम्प्लेट। इसके अलावा, इस बिंदु पर, फ़ाइल एक्सेस अधिकारों को निर्दिष्ट करना अच्छा है। यह सब सौभाग्य से एक फ़ाइल में मिलाया गया - कॉन्फ़िगरेशन टेम्पलेट से पहले, हमने बाकी का वर्णन करते हुए एक 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) }}

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

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

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