अर्को अनुगमन प्रणाली

१६ मोडेम, ४ सेलुलर अपरेटर = बाहिर जाने गति ९३३.४५ Mbit/s

परिचय

नमस्ते! यो लेख हामीले आफ्नो लागि नयाँ अनुगमन प्रणाली कसरी लेख्यौं भन्ने बारेमा हो। यो उच्च-फ्रिक्वेन्सी सिंक्रोनस मेट्रिक्स र धेरै कम स्रोत खपत प्राप्त गर्ने क्षमतामा अवस्थित व्यक्तिहरू भन्दा फरक छ। १० नानोसेकेन्डको मेट्रिक्स बीचको सिङ्क्रोनाइजेसन शुद्धताको साथ मतदान दर ०.१ मिलिसेकेन्डमा पुग्न सक्छ। सबै बाइनरी फाइलहरूले 0.1 मेगाबाइटहरू ओगटेका छन्।

परियोजनाको बारेमा

हामीसँग बरु विशिष्ट उत्पादन छ। हामी डेटा प्रसारण च्यानलहरूको थ्रुपुट र दोष सहिष्णुता संक्षेप गर्नको लागि एक व्यापक समाधान उत्पादन गर्छौं। यो हो जब त्यहाँ धेरै च्यानलहरू छन्, मानौं Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ अरू केहि (5 Mbit/s), परिणाम एक स्थिर र छिटो च्यानल हो, जसको गति केहि जस्तै हुनेछ। यो: (40+ 30+5)x0.92=75×0.92=69 Mbit/s।

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

धेरै वर्षको अवधिमा, हामीले बहु-स्तर, छिटो, क्रस-प्लेटफर्म र हल्का वजन अनुगमन प्रणाली सिर्जना गर्न व्यवस्थित गर्यौं। यो हामी हाम्रो सम्मानित समुदाय संग साझा गर्न चाहन्छौं।

समस्याको गठन

अनुगमन प्रणालीले दुई आधारभूत रूपमा फरक वर्गहरूको मेट्रिक्स प्रदान गर्दछ: वास्तविक-समय मेट्रिक्स र अन्य सबै। अनुगमन प्रणालीमा निम्न आवश्यकताहरू मात्र थिए:

1. वास्तविक-समय मेट्रिक्सको उच्च-फ्रिक्वेन्सी सिंक्रोनस अधिग्रहण र ढिलाइ बिना सञ्चार व्यवस्थापन प्रणालीमा तिनीहरूको स्थानान्तरण।
   विभिन्न मेट्रिक्सको उच्च आवृत्ति र सिंक्रोनाइजेसन मात्र महत्त्वपूर्ण छैन, यो डाटा ट्रान्समिशन च्यानलहरूको एन्ट्रोपी विश्लेषणको लागि महत्त्वपूर्ण छ। यदि एउटा डाटा प्रसारण च्यानलमा औसत ढिलाइ 30 मिलिसेकेन्ड छ भने, त्यसपछि मात्र एक मिलिसेकेन्डको बाँकी मेट्रिक्स बीचको सिङ्क्रोनाइजेसनमा त्रुटिले परिणामस्वरूप च्यानलको गति लगभग 5% ले घटाउनेछ। यदि हामीले 1 च्यानलहरूमा 4 मिलिसेकेन्डले समयलाई गलत गर्यौं भने, गतिको गिरावट सजिलै 30% मा झर्छ। थप रूपमा, च्यानलहरूमा एन्ट्रोपी धेरै चाँडै परिवर्तन हुन्छ, त्यसैले यदि हामीले यसलाई प्रत्येक 0.5 मिलिसेकेन्डमा एक पटक भन्दा कम मापन गर्छौं भने, छिटो च्यानलहरूमा सानो ढिलाइमा हामीले उच्च गतिको ह्रास पाउनेछौं। निस्सन्देह, यस्तो शुद्धता सबै मेट्रिक्स को लागी आवश्यक छैन र सबै अवस्थामा छैन। जब च्यानलमा ढिलाइ 500 मिलिसेकेन्ड हुन्छ, र हामी त्यस्तासँग काम गर्छौं, तब 1 मिलिसेकेन्डको त्रुटि लगभग देख्न सकिने छैन। साथै, जीवन समर्थन प्रणाली मेट्रिक्सका लागि, हामीसँग पर्याप्त मतदान र 2 सेकेन्डको सिंक्रोनाइजेसन दरहरू छन्, तर अनुगमन प्रणाली आफैंले अति-उच्च मतदान दरहरू र मेट्रिक्सको अल्ट्रा-सटीक सिंक्रोनाइजेसनसँग काम गर्न सक्षम हुनुपर्छ।
2. न्यूनतम स्रोत खपत र एकल स्ट्याक।
   अन्तिम यन्त्र या त एक शक्तिशाली अन-बोर्ड कम्प्लेक्स हुन सक्छ जसले सडकमा अवस्थाको विश्लेषण गर्न सक्छ वा मानिसहरूको बायोमेट्रिक रेकर्डिङ सञ्चालन गर्न सक्छ, वा एक विशेष बल सिपाहीले आफ्नो शरीरको कवचमुनि लगाएको पाम आकारको एकल-बोर्ड कम्प्युटरमा भिडियो प्रसारण गर्न सक्छ। खराब संचार अवस्थाहरूमा वास्तविक समय। विभिन्न प्रकारका वास्तुकला र कम्प्युटिङ पावरको बावजुद, हामी एउटै सफ्टवेयर स्ट्याक गर्न चाहन्छौं।
3. छाता वास्तुकला
   मेट्रिकहरू अन्तिम यन्त्रमा सङ्कलन र एकत्रित गरिनु पर्छ, स्थानीय रूपमा भण्डारण गरिएको छ, र वास्तविक समयमा र पूर्ववर्ती रूपमा दृश्यात्मक रूपमा। यदि त्यहाँ जडान छ भने, केन्द्रीय निगरानी प्रणालीमा डाटा स्थानान्तरण गर्नुहोस्। जब त्यहाँ कुनै जडान छैन, पठाउने लाम जम्मा हुनुपर्छ र RAM उपभोग गर्नु हुँदैन।
4. ग्राहकको निगरानी प्रणालीमा एकीकरणको लागि API, किनकि कसैलाई धेरै निगरानी प्रणालीहरू आवश्यक पर्दैन। ग्राहकले एकल निगरानीमा कुनै पनि उपकरण र नेटवर्कबाट डाटा सङ्कलन गर्नुपर्छ।

के भयो

पहिल्यै प्रभावशाली लामो पढाइलाई बोझ नगर्नको लागि, म सबै अनुगमन प्रणालीहरूको उदाहरण र मापन दिनेछैन। यसले अर्को लेखमा लैजान्छ। म मात्र भन्छु कि हामीले 1 मिलिसेकेन्ड भन्दा कमको त्रुटिको साथ एकै साथ दुई मेट्रिक्स लिन सक्षम अनुगमन प्रणाली फेला पार्न सकेनौं र यसले 64 MB RAM को साथ ARM आर्किटेक्चर र 86 को साथ x64_32 आर्किटेक्चरमा समान रूपमा प्रभावकारी रूपमा काम गर्दछ। RAM को GB। त्यसैले, हामीले आफ्नै लेख्ने निर्णय गर्यौं, जसले यो सबै गर्न सक्छ। हामीले पाएको कुरा यहाँ छ:

विभिन्न नेटवर्क टोपोलोजीहरूको लागि तीन च्यानलहरूको थ्रुपुट संक्षेप

केही प्रमुख मेट्रिक्सको दृश्यावलोकन

वास्तुकला

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

प्रणाली क्लासिक मोड्युलर सिद्धान्त अनुसार लागू गरिएको छ र धेरै उपप्रणालीहरू समावेश गर्दछ:

1. मेट्रिक्स दर्ता।
   प्रत्येक मेट्रिकलाई आफ्नै थ्रेडद्वारा सेवा गरिन्छ र च्यानलहरूमा सिङ्क्रोनाइज गरिन्छ। हामीले 10 नानोसेकेन्ड सम्मको सिङ्क्रोनाइजेसन शुद्धता हासिल गर्न सक्षम भयौं।
2. मेट्रिक्स भण्डारण
   हामीले समय श्रृङ्खलाका लागि हाम्रो आफ्नै भण्डारण लेख्ने वा पहिले नै उपलब्ध भएको केही प्रयोग गर्ने बीच छनौट गरिरहेका थियौं। डाटाबेसलाई पछिल्ला भिजुअलाइजेशनको अधीनमा रहेको पूर्वव्यापी डेटाको लागि आवश्यक छ। अर्थात्, यसले च्यानलमा प्रत्येक ०.५ मिलिसेकेन्डमा हुने ढिलाइ वा यातायात नेटवर्कमा त्रुटि रिडिङमा डाटा समावेश गर्दैन, तर प्रत्येक इन्टरफेसमा प्रत्येक ५०० मिलिसेकेन्डमा गति हुन्छ। क्रस-प्लेटफर्म र कम स्रोत खपत को लागी उच्च आवश्यकताहरु को अतिरिक्त, यो हाम्रो लागि प्रशोधन गर्न सक्षम हुनु धेरै महत्त्वपूर्ण छ। डाटा जहाँ भण्डार गरिएको छ। यसले ठूलो कम्प्युटिङ स्रोतहरू बचत गर्छ। हामीले 0.5 देखि यस परियोजनामा ​​Tarantool DBMS प्रयोग गर्दै आएका छौं र अहिलेसम्म हामीले क्षितिजमा यसको प्रतिस्थापन देखेका छैनौं। लचिलो, इष्टतम स्रोत खपतको साथ, पर्याप्त प्राविधिक समर्थन भन्दा बढी। Tarantool ले GIS मोड्युल पनि लागू गर्दछ। निस्सन्देह, यो PostGIS जत्तिकै शक्तिशाली छैन, तर यो केहि स्थान-सम्बन्धित मेट्रिक्स (यातायातको लागि प्रासंगिक) भण्डारण गर्ने हाम्रो कार्यहरूको लागि पर्याप्त छ।
3. मेट्रिक्स को दृश्य
   यहाँ सबै कुरा अपेक्षाकृत सरल छ। हामी गोदामबाट डाटा लिन्छौं र यसलाई वास्तविक समयमा वा पूर्ववर्ती रूपमा प्रदर्शन गर्छौं।
4. केन्द्रीय अनुगमन प्रणाली संग डाटा को सिंक्रोनाइजेसन।
   केन्द्रीय अनुगमन प्रणालीले सबै उपकरणहरूबाट डाटा प्राप्त गर्दछ, यसलाई निर्दिष्ट इतिहासको साथ भण्डारण गर्दछ र API मार्फत ग्राहकको निगरानी प्रणालीमा पठाउँदछ। क्लासिक अनुगमन प्रणालीहरूको विपरीत, जसमा "हेड" घुम्छ र डेटा सङ्कलन गर्छ, हामीसँग विपरित योजना छ। जडान हुँदा उपकरणहरू आफैले डेटा पठाउँछन्। यो एक धेरै महत्त्वपूर्ण बिन्दु हो, किनकि यसले तपाईंलाई ती समयावधिहरूको लागि यन्त्रबाट डेटा प्राप्त गर्न अनुमति दिन्छ जुन समयमा यो उपलब्ध थिएन र यन्त्र अनुपलब्ध हुँदा च्यानलहरू र स्रोतहरू लोड गर्दैन। हामी केन्द्रीय अनुगमन प्रणालीको रूपमा Influx निगरानी सर्भर प्रयोग गर्दछौं। यसको एनालगहरूको विपरीत, यसले पूर्वव्यापी डेटा आयात गर्न सक्छ (अर्थात, मेट्रिक्स प्राप्त भएको क्षण भन्दा फरक टाइम स्ट्याम्पको साथ)। सङ्कलन गरिएका मेट्रिकहरू ग्राफानाद्वारा भिजुअलाइज गरिएको छ, फाइलसँग परिमार्जन गरिएको छ। यो मानक स्ट्याक पनि छनोट गरिएको थियो किनभने यो लगभग कुनै पनि ग्राहक निगरानी प्रणाली संग रेडिमेड एपीआई एकीकरण छ।
5. केन्द्रीय उपकरण व्यवस्थापन प्रणाली संग डाटा सिंक्रोनाइजेसन।
   यन्त्र व्यवस्थापन प्रणालीले शून्य टच प्रावधान लागू गर्दछ (फर्मवेयर, कन्फिगरेसन, आदि अद्यावधिक गर्दै) र, अनुगमन प्रणालीको विपरीत, प्रति उपकरण मात्र समस्याहरू प्राप्त गर्दछ। यी अन-बोर्ड हार्डवेयर वाचडग सेवाहरू र जीवन समर्थन प्रणालीहरूको सबै मेट्रिक्सको सञ्चालनका लागि ट्रिगरहरू हुन्: CPU र SSD तापमान, CPU लोड, खाली ठाउँ र डिस्कहरूमा स्मार्ट स्वास्थ्य। उपप्रणाली भण्डारण पनि Tarantool मा निर्मित छ। यसले हामीलाई हजारौं यन्त्रहरूमा समय शृङ्खलाहरू जम्मा गर्न महत्त्वपूर्ण गति दिन्छ, र यी यन्त्रहरूसँग डेटा सिङ्क्रोनाइज गर्ने समस्यालाई पूर्ण रूपमा समाधान गर्दछ। Tarantool एक उत्कृष्ट कतार र ग्यारेन्टी वितरण प्रणाली छ। हामीले यो महत्त्वपूर्ण सुविधा बक्सबाट बाहिर पायौं, उत्कृष्ट!

नेटवर्क व्यवस्थापन प्रणाली

अब के

अहिलेसम्म हाम्रो सबैभन्दा कमजोर लिङ्क केन्द्रीय अनुगमन प्रणाली हो। यो मानक स्ट्याकमा 99.9% लागू गरिएको छ र यसका धेरै बेफाइदाहरू छन्:

1. पावर हराउँदा InfluxDB ले डेटा गुमाउँछ। नियमको रूपमा, ग्राहकले तुरुन्तै उपकरणहरूबाट आउने सबै चीजहरू सङ्कलन गर्दछ र डाटाबेसमा 5 मिनेट भन्दा पुरानो डाटा समावेश गर्दैन, तर भविष्यमा यो पीडा हुन सक्छ।
2. Grafana सँग डाटा एकत्रीकरण र यसको प्रदर्शनको सिङ्क्रोनाइजेसनको साथ धेरै समस्याहरू छन्। सबैभन्दा सामान्य समस्या हो जब डाटाबेसले 2:00:00 बाट सुरु हुने 00 सेकेन्डको अन्तरालको साथ समय श्रृंखला समावेश गर्दछ, र Grafana +1 सेकेन्डबाट एकत्रीकरणमा डेटा देखाउन थाल्छ। नतिजाको रूपमा, प्रयोगकर्ताले नृत्य ग्राफ देख्छ।
3. तेस्रो-पक्ष निगरानी प्रणालीहरूसँग API एकीकरणको लागि कोडको अत्यधिक मात्रा। यसलाई धेरै कम्प्याक्ट बनाउन सकिन्छ र पक्कै पनि Go मा पुन: लेख्न सकिन्छ)

मलाई लाग्छ कि तपाईं सबैले Grafana कस्तो देखिन्छ र यसको समस्याहरू म बिना थाहा पाउनु भएको छ, त्यसैले म तस्विरहरूको साथ पोस्ट ओभरलोड गर्दिन।

निष्कर्षमा

मैले जानाजानी प्राविधिक विवरणहरू वर्णन गरेन, तर यस प्रणालीको आधारभूत डिजाइन मात्र वर्णन गरें। पहिलो, प्राविधिक रूपमा प्रणाली पूर्ण रूपमा वर्णन गर्न, अर्को लेख आवश्यक हुनेछ। दोस्रो, सबैले यसमा चासो दिने छैनन्। तपाइँ के प्राविधिक विवरणहरू जान्न चाहनुहुन्छ टिप्पणीहरूमा लेख्नुहोस्।

यदि कसैसँग यस लेखको दायरा बाहिर प्रश्नहरू छन् भने, तपाईं मलाई a.rodin @ qedr.com मा लेख्न सक्नुहुन्छ।

स्रोत: www.habr.com