Qrator फिल्टरिंग नेटवर्क कॉन्फिगरेशन व्यवस्थापन प्रणाली

TL; डॉ: आमच्या अंतर्गत नेटवर्क कॉन्फिगरेशन व्यवस्थापन प्रणाली, QControl च्या क्लायंट-सर्व्हर आर्किटेक्चरचे वर्णन. हे दोन-लेयर ट्रान्सपोर्ट प्रोटोकॉलवर आधारित आहे जे एंडपॉइंट्समधील डीकंप्रेशनशिवाय gzip-पॅक संदेशांसह कार्य करते. वितरित राउटर आणि एंडपॉइंट्स कॉन्फिगरेशन अद्यतने प्राप्त करतात आणि प्रोटोकॉल स्वतःच स्थानिकीकृत इंटरमीडिएट रिले स्थापित करण्यास परवानगी देतो. प्रणाली तत्त्वावर बांधली आहे विभेदक बॅकअप (“अलीकडील-स्थिर”, खाली स्पष्ट केले आहे) आणि कॉन्फिगरेशन फाइल्स रेंडर करण्यासाठी जिन्जा टेम्प्लेटिंग इंजिनसह JMESpath क्वेरी भाषा वापरते.

Qrator Labs जागतिक स्तरावर वितरीत हल्ला शमन नेटवर्क चालवते. आमचे नेटवर्क कोणत्याही कास्ट तत्त्वावर चालते आणि सबनेट्सची BGP द्वारे जाहिरात केली जाते. पृथ्वीच्या अनेक प्रदेशांमध्ये भौतिकरित्या स्थित असलेले BGP anycast नेटवर्क असल्याने, आम्ही इंटरनेटच्या गाभ्याजवळील बेकायदेशीर रहदारीवर प्रक्रिया आणि फिल्टर करू शकतो - टियर-1 ऑपरेटर.

दुसरीकडे, भौगोलिकदृष्ट्या वितरित नेटवर्क असणे सोपे नाही. सुरक्षा सेवा प्रदात्यासाठी सर्व नेटवर्क नोड्सचे सुसंगत कॉन्फिगरेशन, त्यांना वेळेवर अद्यतनित करण्यासाठी नेटवर्क पॉइंट्स ऑफ प्रेझेन्समधील संप्रेषण महत्त्वपूर्ण आहे. म्हणून, ग्राहकांना उच्च संभाव्य स्तरावरील मुख्य सेवा प्रदान करण्यासाठी, आम्हाला संपूर्ण खंडांमध्ये कॉन्फिगरेशन डेटा विश्वासार्हपणे समक्रमित करण्याचा मार्ग शोधण्याची आवश्यकता आहे.

सुरुवातीला शब्द होता. अद्ययावत करण्याची गरज असताना ते त्वरीत एक संप्रेषण प्रोटोकॉल बनले.

QControl च्या अस्तित्वाचा आधारस्तंभ, आणि त्याच वेळी या प्रकारचा प्रोटोकॉल तयार करण्यासाठी बराच वेळ आणि संसाधने खर्च करण्याचे मुख्य कारण म्हणजे कॉन्फिगरेशनचा एकच अधिकृत स्त्रोत प्राप्त करणे आणि शेवटी, आमच्या उपस्थितीचे बिंदू समक्रमित करणे. त्या सोबत. QControl च्या विकासादरम्यान स्टोरेज स्वतःच अनेक आवश्यकतांपैकी एक होती. याशिवाय, आम्हाला विद्यमान आणि नियोजित सेवांसह प्रेझेन्स पॉइंट्स (POP), डेटा प्रमाणीकरणासाठी स्मार्ट (आणि सानुकूल करण्यायोग्य) पद्धती, तसेच प्रवेश नियंत्रणाची देखील आवश्यकता होती. याशिवाय, आम्हाला फाइल्समध्ये बदल करण्याऐवजी कमांड वापरून अशा प्रणालीवर नियंत्रण ठेवायचे होते. QControl पूर्वी, डेटा जवळजवळ मॅन्युअली उपस्थितीच्या बिंदूंवर पाठविला जात असे. जर उपस्थितीच्या बिंदूंपैकी एक अनुपलब्ध असेल आणि आम्ही ते नंतर अद्यतनित करण्यास विसरलो, तर कॉन्फिगरेशन सिंक्रोनाइझेशनच्या बाहेर जाईल आणि आम्हाला ते पुन्हा चालू करण्यात वेळ वाया घालवावा लागेल.

परिणामी, आम्ही खालील योजना घेऊन आलो:

कॉन्फिगरेशन सर्व्हर डेटा प्रमाणीकरण आणि स्टोरेजसाठी जबाबदार आहे; राउटरमध्ये अनेक एंडपॉइंट्स आहेत जे क्लायंट आणि सपोर्ट टीम्सकडून सर्व्हरवर कॉन्फिगरेशन अपडेट्स प्राप्त करतात आणि प्रसारित करतात आणि सर्व्हरपासून उपस्थितीच्या बिंदूंपर्यंत.

इंटरनेट कनेक्शनची गुणवत्ता अजूनही जगभर मोठ्या प्रमाणात बदलते - हा मुद्दा स्पष्ट करण्यासाठी, प्राग, झेक प्रजासत्ताक ते सिंगापूर आणि हाँगकाँगपर्यंत एक साधा MTR पाहू या.

प्राग ते सिंगापूर MTR

तीच गोष्ट हाँगकाँगची

उच्च विलंब म्हणजे कमी वेग. याव्यतिरिक्त, पॅकेट नुकसान आहे. चॅनेलची रुंदी या समस्येची भरपाई करत नाही, जी विकेंद्रित प्रणाली तयार करताना नेहमी लक्षात घेतली पाहिजे.

उपस्थितीच्या बिंदूचे संपूर्ण कॉन्फिगरेशन म्हणजे डेटाची महत्त्वपूर्ण रक्कम आहे जी अविश्वसनीय कनेक्शनवर अनेक प्राप्तकर्त्यांना पाठविली जाणे आवश्यक आहे. सुदैवाने, कॉन्फिगरेशन सतत बदलत असले तरी, ते लहान वाढीमध्ये होते.

अलीकडील-स्थिर डिझाइन

आम्ही असे म्हणू शकतो की वाढीव अद्यतनांच्या तत्त्वावर आधारित वितरित नेटवर्क तयार करणे हा एक स्पष्ट उपाय आहे. परंतु मतभेदांसह अनेक समस्या आहेत. आम्हाला संदर्भ बिंदूंमधील सर्व फरक जतन करणे आवश्यक आहे आणि एखाद्याने डेटाचा काही भाग गमावल्यास ते पुन्हा पाठविण्यास सक्षम असणे आवश्यक आहे. प्रत्येक गंतव्यस्थानाने त्यांना काटेकोरपणे निर्दिष्ट क्रमाने लागू करणे आवश्यक आहे. सामान्यतः, अनेक गंतव्यस्थानांच्या बाबतीत, अशा ऑपरेशनला बराच वेळ लागू शकतो. प्राप्तकर्त्याने गहाळ भागांची विनंती करण्यास सक्षम असणे देखील आवश्यक आहे आणि अर्थातच, मध्यवर्ती भागाने अशा विनंतीला योग्य प्रतिसाद दिला पाहिजे, फक्त गहाळ डेटा पाठवला पाहिजे.

परिणामी, आम्ही एका ऐवजी मनोरंजक समाधानाकडे आलो - आमच्याकडे फक्त एक संदर्भ स्तर आहे, निश्चित आहे, चला त्याला स्थिर म्हणूया आणि त्यासाठी फक्त एक फरक - अलीकडील. प्रत्येक अलीकडील शेवटच्या व्युत्पन्न केलेल्या स्थिरतेवर आधारित आहे आणि कॉन्फिगरेशन डेटा पुन्हा तयार करण्यासाठी पुरेसे आहे. ताजे अलीकडील त्याच्या गंतव्यस्थानावर पोहोचताच, जुन्याची यापुढे गरज नाही.

वेळोवेळी नवीन स्थिर कॉन्फिगरेशन पाठवणे बाकी आहे, उदाहरणार्थ अलीकडील खूप मोठे झाले आहे. येथे देखील महत्त्वाचे आहे की आम्ही ही सर्व अद्यतने ब्रॉडकास्ट/मल्टीकास्ट मोडमध्ये पाठवतो, वैयक्तिक प्राप्तकर्ते आणि डेटाचे तुकडे एकत्र करण्याची त्यांची क्षमता याबद्दल काळजी न करता. एकदा आम्‍हाला खात्री पटल्‍यावर की, प्रत्‍येकाकडे अचूक स्‍थिर असल्‍यावर, आम्‍ही फक्त नवीन अलीकडील पाठवतो. हे कार्य करते हे स्पष्ट करणे योग्य आहे का? कार्य करते. कॉन्फिगरेशन सर्व्हर आणि प्राप्तकर्त्यांवर स्थिर कॅशे केले जाते, अलीकडील आवश्यकतेनुसार तयार केले जाते.

दोन-स्तरीय वाहतुकीचे आर्किटेक्चर

आम्ही आमची वाहतूक दोन स्तरांवर का तयार केली? उत्तर अगदी सोपे आहे - आम्हाला ओएसआय मॉडेलपासून त्याच्या ट्रान्सपोर्ट आणि अॅप्लिकेशन लेयर्ससह प्रेरणा घेऊन उच्च-स्तरीय तर्कशास्त्रातून राउटिंग दुप्पट करायचे होते. आम्ही ट्रान्सपोर्ट प्रोटोकॉलच्या भूमिकेसाठी थ्रिफ्ट आणि कंट्रोल मेसेजच्या उच्च-स्तरीय फॉरमॅटसाठी msgpack सीरियलायझेशन फॉरमॅट वापरले. म्हणूनच राउटर (मल्टिकास्ट/ब्रॉडकास्ट/रिले करत आहे) msgpack मध्ये दिसत नाही, अनपॅक करत नाही किंवा परत सामग्री पॅक करत नाही आणि फक्त डेटा फॉरवर्ड करतो.

थ्रिफ्ट (इंग्रजीतून - "काटकसर", उच्चारित [θrift]) ही इंटरफेस वर्णन भाषा आहे जी वेगवेगळ्या प्रोग्रामिंग भाषांसाठी सेवा परिभाषित करण्यासाठी आणि तयार करण्यासाठी वापरली जाते. हे रिमोट प्रोसिजर कॉल्स (RPC) साठी एक फ्रेमवर्क आहे. भाषांमध्ये कमी-अधिक कार्यक्षमतेने आणि सहजपणे काम करणाऱ्या सेवा विकसित करण्यासाठी कोड जनरेशन इंजिनसह सॉफ्टवेअर पाइपलाइन एकत्र करते.

RPC आणि अनेक भाषांना सपोर्ट असल्यामुळे आम्ही थ्रिफ्ट फ्रेमवर्क निवडले. नेहमीप्रमाणे, सोपे भाग क्लायंट आणि सर्व्हर होते. तथापि, राउटर क्रॅक करण्यासाठी एक कठीण नट असल्याचे दिसून आले, अंशतः आमच्या विकासादरम्यान तयार सोल्यूशनच्या अभावामुळे.

इतर पर्याय आहेत, जसे की प्रोटोबफ/जीआरपीसी, तथापि, आम्ही आमचा प्रकल्प सुरू केला तेव्हा, जीआरपीसी अगदी नवीन होते आणि आम्ही ते बोर्डवर घेण्याचे धाडस केले नाही.

अर्थात, आम्ही आमची स्वतःची बाईक बनवू शकलो (आणि खरं तर असायला हवा होता). आम्हाला आवश्यक असलेल्या गोष्टींसाठी प्रोटोकॉल तयार करणे सोपे होईल कारण क्लायंट-सर्व्हर आर्किटेक्चर थ्रिफ्टवर राउटर बनवण्याच्या तुलनेत अंमलात आणण्यासाठी तुलनेने सरळ आहे. एक ना एक मार्ग, स्वत: लिखित प्रोटोकॉल आणि लोकप्रिय लायब्ररींच्या अंमलबजावणीकडे पारंपारिक पूर्वाग्रह आहे (चांगल्या कारणासाठी); शिवाय, चर्चेदरम्यान नेहमी प्रश्न येतो: "आम्ही हे इतर भाषांमध्ये कसे पोर्ट करणार आहोत?" म्हणून आम्ही लगेच सायकलची कल्पना फेकून दिली.

Msgpack JSON सारखाच आहे, परंतु वेगवान आणि लहान आहे. हे बायनरी डेटा सीरियलायझेशन स्वरूप आहे जे एकाधिक भाषांमध्ये डेटाची देवाणघेवाण करण्यास अनुमती देते.

पहिल्या स्तरावर राउटरला संदेश फॉरवर्ड करण्यासाठी आवश्यक असलेली किमान माहिती असलेली थ्रिफ्ट आहे. दुसऱ्या स्तरावर पॅकेज्ड msgpack संरचना आहेत.

आम्ही msgpack निवडले कारण ते JSON च्या तुलनेत जलद आणि अधिक संक्षिप्त आहे. परंतु अधिक महत्त्वाचे म्हणजे, हे सानुकूल डेटा प्रकारांना समर्थन देते, ज्यामुळे आम्हाला रॉ बायनरी पास करणे किंवा डेटाची अनुपस्थिती दर्शविणारी विशेष वस्तू यासारखी छान वैशिष्ट्ये वापरता येतात, जी आमच्या “अलीकडील-स्थिर” योजनेसाठी महत्त्वाची होती.

JMESPath
JMESPath ही JSON क्वेरी भाषा आहे.
अधिकृत JMESPath दस्तऐवजीकरणातून आम्हाला मिळालेले वर्णन हेच ​​दिसते, परंतु प्रत्यक्षात ते त्यापेक्षा बरेच काही करते. JMESPath तुम्हाला एका अनियंत्रित वृक्ष संरचनेमध्ये उपवृक्ष शोधण्याची आणि फिल्टर करण्याची आणि फ्लायवरील डेटामध्ये बदल लागू करण्याची परवानगी देते. हे तुम्हाला विशेष फिल्टर आणि डेटा ट्रान्सफॉर्मेशन प्रक्रिया जोडण्याची देखील परवानगी देते. हे अर्थातच समजून घेण्यासाठी मेंदूचे प्रयत्न आवश्यक असले तरी.

जिन्जा
काही ग्राहकांसाठी, आम्हाला कॉन्फिगरेशन फाइलमध्ये बदलण्याची आवश्यकता आहे - म्हणून आम्ही टेम्पलेट इंजिन वापरतो आणि जिंजा ही स्पष्ट निवड आहे. त्याच्या मदतीने, आम्ही गंतव्यस्थानावर प्राप्त झालेल्या टेम्पलेट आणि डेटामधून कॉन्फिगरेशन फाइल तयार करतो.

कॉन्फिगरेशन फाइल तयार करण्यासाठी, आम्हाला JMESPath विनंती, FS मधील फाइल स्थानासाठी टेम्पलेट आणि कॉन्फिगरेशनसाठी टेम्पलेट आवश्यक आहे. या टप्प्यावर फाइल परवानग्या स्पष्ट करणे देखील चांगली कल्पना आहे. हे सर्व एका फाईलमध्ये यशस्वीरित्या एकत्र केले गेले - कॉन्फिगरेशन टेम्पलेट सुरू होण्यापूर्वी, आम्ही बाकीचे वर्णन करणारा YAML फॉरमॅटमध्ये शीर्षलेख ठेवतो.

उदाहरणार्थ:

---
selector: "[@][[email protected]._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) }}


नवीन सेवेसाठी कॉन्फिगरेशन फाइल बनवण्यासाठी, आम्ही फक्त नवीन टेम्पलेट फाइल जोडतो. उपस्थितीच्या बिंदूंवरील स्त्रोत कोड किंवा सॉफ्टवेअरमध्ये कोणतेही बदल आवश्यक नाहीत.

QControl थेट झाल्यापासून काय बदलले आहे? पहिली आणि सर्वात महत्वाची गोष्ट म्हणजे नेटवर्कमधील सर्व नोड्सवर कॉन्फिगरेशन अपडेट्सचे सुसंगत आणि विश्वासार्ह वितरण. दुसरे म्हणजे कॉन्फिगरेशन तपासण्यासाठी आणि आमच्या समर्थन कार्यसंघाद्वारे तसेच सेवेच्या ग्राहकांद्वारे त्यात बदल करण्यासाठी एक शक्तिशाली साधन प्राप्त करणे.

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

साहित्य लिहिण्यात मदत केल्याबद्दल धन्यवाद. व्होलनडामरोड, serenheit, न.

इंग्रजी आवृत्ती पोस्ट.

स्त्रोत: www.habr.com