ប្រព័ន្ធត្រួតពិនិត្យមួយទៀត

16 ម៉ូដឹម, 4 ប្រតិបត្តិករកោសិកា = ល្បឿនចេញ 933.45 Mbit/s

សេចក្តីណែនាំ

សួស្តី! អត្ថបទនេះគឺអំពីរបៀបដែលយើងសរសេរប្រព័ន្ធត្រួតពិនិត្យថ្មីសម្រាប់ខ្លួនយើង។ វាខុសគ្នាពីអ្វីដែលមានស្រាប់នៅក្នុងសមត្ថភាពរបស់វាក្នុងការទទួលបានរង្វាស់សមកាលកម្មប្រេកង់ខ្ពស់ និងការប្រើប្រាស់ធនធានទាបបំផុត។ អត្រាបោះឆ្នោតអាចឈានដល់ 0.1 មីលីវិនាទី ជាមួយនឹងភាពត្រឹមត្រូវនៃការធ្វើសមកាលកម្មរវាងម៉ែត្រ 10 ណាណូវិនាទី។ ឯកសារគោលពីរទាំងអស់កាន់កាប់ 6 មេកាបៃ។

អំពីគម្រោង

យើងមានផលិតផលជាក់លាក់។ យើងផលិតដំណោះស្រាយដ៏ទូលំទូលាយមួយសម្រាប់ការសង្ខេបការបញ្ជូន និងការអត់ឱនកំហុសនៃបណ្តាញបញ្ជូនទិន្នន័យ។ នេះគឺជាពេលដែលមានប៉ុស្តិ៍ជាច្រើន ឧបមាថា Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ អ្វីផ្សេងទៀត (5 Mbit/s) លទ្ធផលគឺឆានែលមួយដែលមានស្ថេរភាព និងលឿន ដែលល្បឿននឹងមានដូចជា នេះ៖ (40+ 30+5)x0.92=75×0.92=69 Mbit/s ។

ដំណោះស្រាយបែបនេះគឺស្ថិតនៅក្នុងតម្រូវការដែលសមត្ថភាពនៃបណ្តាញណាមួយមិនគ្រប់គ្រាន់។ ឧទាហរណ៍ ការដឹកជញ្ជូន ប្រព័ន្ធឃ្លាំមើលវីដេអូ និងការផ្សាយវីដេអូតាមពេលវេលាជាក់ស្តែង ការផ្សាយតាមទូរទស្សន៍ និងវិទ្យុផ្សាយផ្ទាល់ កន្លែងជាយក្រុងណាមួយ ដែលក្នុងចំណោមប្រតិបត្តិករទូរគមនាគមន៍ មានតែតំណាងរបស់ Big Four ហើយល្បឿននៅលើម៉ូដឹម/ឆានែលតែមួយគឺមិនគ្រប់គ្រាន់ទេ។ .
សម្រាប់ផ្នែកនីមួយៗនៃផ្នែកទាំងនេះ យើងផលិតឧបករណ៍ដាច់ដោយឡែកមួយ ប៉ុន្តែផ្នែកទន់របស់ពួកគេគឺស្ទើរតែដូចគ្នា ហើយប្រព័ន្ធត្រួតពិនិត្យគុណភាពខ្ពស់គឺជាម៉ូឌុលសំខាន់មួយរបស់វា ប្រសិនបើមិនមានការអនុវត្តត្រឹមត្រូវដែលផលិតផលនោះនឹងមិនអាចទៅរួចនោះទេ។

ក្នុងរយៈពេលជាច្រើនឆ្នាំ យើងអាចបង្កើតប្រព័ន្ធត្រួតពិនិត្យពហុកម្រិត លឿន ឆ្លងវេទិកា និងទម្ងន់ស្រាល។ នេះជាអ្វីដែលយើងចង់ចែករំលែកជាមួយសហគមន៍ជាទីគោរពរបស់យើង។

ការបង្កើតបញ្ហា

ប្រព័ន្ធត្រួតពិនិត្យផ្តល់នូវការវាស់វែងនៃថ្នាក់មូលដ្ឋានពីរផ្សេងគ្នា៖ រង្វាស់ពេលវេលាជាក់ស្តែង និងផ្សេងទៀតទាំងអស់។ ប្រព័ន្ធត្រួតពិនិត្យមានតម្រូវការដូចខាងក្រោមៈ

1. ការទិញសមកាលកម្មប្រេកង់ខ្ពស់នៃរង្វាស់ពេលវេលាជាក់ស្តែង និងការផ្ទេររបស់ពួកគេទៅប្រព័ន្ធគ្រប់គ្រងទំនាក់ទំនងដោយមិនពន្យារពេល។
   ប្រេកង់ខ្ពស់ និងការធ្វើសមកាលកម្មនៃម៉ែត្រផ្សេងគ្នាគឺមិនត្រឹមតែមានសារៈសំខាន់ប៉ុណ្ណោះទេ វាមានសារៈសំខាន់សម្រាប់ការវិភាគ entropy នៃបណ្តាញបញ្ជូនទិន្នន័យ។ ប្រសិនបើនៅក្នុងបណ្តាញបញ្ជូនទិន្នន័យមួយ ការពន្យាពេលជាមធ្យមគឺ 30 មីលីវិនាទី នោះកំហុសក្នុងការធ្វើសមកាលកម្មរវាងម៉ែត្រដែលនៅសល់ត្រឹមតែមួយមិល្លីវិនាទីនឹងនាំឱ្យខូចល្បឿននៃឆានែលលទ្ធផលប្រហែល 5% ។ ប្រសិនបើយើងកំណត់ពេលវេលាខុសត្រឹម 1 មិល្លីវិនាទីឆ្លងកាត់ 4 ប៉ុស្តិ៍ នោះការបន្ថយល្បឿនអាចធ្លាក់ចុះយ៉ាងងាយស្រួលដល់ 30% ។ លើសពីនេះ entropy នៅក្នុង channels ផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស ដូច្នេះប្រសិនបើយើងវាស់វាតិចជាងម្តងរៀងរាល់ 0.5 មិល្លីវិនាទី នៅលើបណ្តាញដែលមានល្បឿនលឿនជាមួយនឹងការពន្យាពេលតិចតួច យើងនឹងទទួលបានការរិចរិលល្បឿនលឿន។ ជាការពិតណាស់ភាពត្រឹមត្រូវបែបនេះមិនចាំបាច់សម្រាប់ម៉ែត្រទាំងអស់ទេហើយមិនមែននៅក្នុងគ្រប់លក្ខខណ្ឌទាំងអស់នោះទេ។ នៅពេលដែលការពន្យាពេលក្នុងឆានែលគឺ 500 មីលីវិនាទី ហើយយើងធ្វើការជាមួយបែបនេះ នោះកំហុស 1 មីលីវិនាទីនឹងស្ទើរតែមិនគួរឱ្យកត់សម្គាល់។ ដូចគ្នាដែរ សម្រាប់ការវាស់វែងប្រព័ន្ធទ្រទ្រង់ជីវិត យើងមានអត្រានៃការស្ទង់មតិ និងសមកាលកម្មគ្រប់គ្រាន់ក្នុងរយៈពេល 2 វិនាទី ប៉ុន្តែប្រព័ន្ធត្រួតពិនិត្យខ្លួនឯងត្រូវតែអាចដំណើរការជាមួយនឹងអត្រាបោះឆ្នោតខ្ពស់ជ្រុល និងការធ្វើសមកាលកម្មម៉ែត្រជាក់លាក់ជ្រុល។
2. ការប្រើប្រាស់ធនធានតិចបំផុត និងជង់តែមួយ។
   ឧបករណ៍ចុងអាចជាស្មុគ្រស្មាញនៅលើយន្តហោះដ៏មានឥទ្ធិពលដែលអាចវិភាគស្ថានភាពនៅលើផ្លូវ ឬថតជីវមាត្ររបស់មនុស្ស ឬកុំព្យូទ័របន្ទះតែមួយទំហំប៉ុនបាតដៃដែលទាហានកងកម្លាំងពិសេសពាក់នៅក្រោមអាវក្រោះរាងកាយរបស់គាត់ដើម្បីបញ្ជូនវីដេអូនៅក្នុង ពេលវេលាពិតនៅក្នុងលក្ខខណ្ឌទំនាក់ទំនងមិនល្អ។ ទោះបីជាមានភាពខុសប្លែកគ្នានៃស្ថាបត្យកម្ម និងថាមពលកុំព្យូទ័រក៏ដោយ ក៏យើងចង់បានកម្មវិធីដូចគ្នាដែរ។
3. ស្ថាបត្យកម្មឆ័ត្រ
   ម៉ែត្រត្រូវតែត្រូវបានប្រមូល និងប្រមូលផ្តុំនៅលើឧបករណ៍ចុងក្រោយ រក្សាទុកក្នុងមូលដ្ឋាន និងមើលឃើញក្នុងពេលវេលាជាក់ស្តែង និងបន្តបន្ទាប់ទៀត។ ប្រសិនបើមានការតភ្ជាប់ ផ្ទេរទិន្នន័យទៅប្រព័ន្ធត្រួតពិនិត្យកណ្តាល។ នៅពេលដែលមិនមានការតភ្ជាប់ ជួរបញ្ជូនគួរតែកកកុញ និងមិនប្រើប្រាស់ RAM។
4. API សម្រាប់បញ្ចូលទៅក្នុងប្រព័ន្ធត្រួតពិនិត្យរបស់អតិថិជន ព្រោះគ្មាននរណាម្នាក់ត្រូវការប្រព័ន្ធត្រួតពិនិត្យច្រើននោះទេ។ អតិថិជនត្រូវតែប្រមូលទិន្នន័យពីឧបករណ៍ និងបណ្តាញណាមួយទៅក្នុងការត្រួតពិនិត្យតែមួយ។

តើមានអ្វីកើតឡើង

ដើម្បីកុំឱ្យបន្ទុកលើការអានដ៏គួរឱ្យចាប់អារម្មណ៍រួចហើយ ខ្ញុំនឹងមិនផ្តល់ឧទាហរណ៍ និងការវាស់វែងនៃប្រព័ន្ធត្រួតពិនិត្យទាំងអស់នោះទេ។ នេះនឹងនាំទៅដល់អត្ថបទមួយទៀត។ ខ្ញុំនឹងនិយាយថាយើងមិនអាចស្វែងរកប្រព័ន្ធត្រួតពិនិត្យដែលមានសមត្ថភាពទទួលយកម៉ែត្រពីរក្នុងពេលដំណាលគ្នាជាមួយនឹងកំហុសតិចជាង 1 មិល្លីវិនាទី ហើយវាដំណើរការស្មើៗគ្នាទាំងនៅលើស្ថាបត្យកម្ម ARM ដែលមាន RAM 64 MB និងនៅលើស្ថាបត្យកម្ម x86_64 ដែលមាន 32 ជីកាបៃនៃ RAM ។ ដូច្នេះហើយ ទើបយើងសម្រេចចិត្តសរសេរដោយខ្លួនឯង ដែលអាចធ្វើអ្វីៗទាំងអស់នេះបាន។ នេះជាអ្វីដែលយើងទទួលបាន៖

សង្ខេបការបញ្ជូនបន្តនៃបណ្តាញចំនួនបីសម្រាប់ topologies បណ្តាញផ្សេងគ្នា

ការមើលឃើញនៃម៉ែត្រសំខាន់ៗមួយចំនួន

ស្ថាបត្យកម្ម

យើងប្រើ Golang ជាភាសាសរសេរកម្មវិធីសំខាន់ ទាំងនៅលើឧបករណ៍ និងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ វាបានធ្វើឱ្យជីវិតមានភាពសាមញ្ញយ៉ាងខ្លាំងជាមួយនឹងការអនុវត្តកិច្ចការច្រើន និងសមត្ថភាពក្នុងការទទួលបានឯកសារប្រព័ន្ធគោលពីរដែលអាចប្រតិបត្តិបានដែលភ្ជាប់គ្នាយ៉ាងឋិតថេរសម្រាប់សេវាកម្មនីមួយៗ។ ជាលទ្ធផល យើងសន្សំបានយ៉ាងច្រើននូវធនធាន វិធីសាស្រ្ត និងចរាចរសម្រាប់ការដាក់ពង្រាយសេវាកម្មដល់ឧបករណ៍បញ្ចប់ ពេលវេលាអភិវឌ្ឍន៍ និងការបំបាត់កំហុសកូដ។

ប្រព័ន្ធនេះត្រូវបានអនុវត្តតាមគោលការណ៍ម៉ូឌុលបុរាណ និងមានប្រព័ន្ធរងជាច្រើន៖

1. ការចុះឈ្មោះម៉ែត្រ។
   ម៉ែត្រនីមួយៗត្រូវបានបម្រើដោយខ្សែស្រឡាយរបស់វាផ្ទាល់ និងធ្វើសមកាលកម្មតាមបណ្តាញនានា។ យើងអាចសម្រេចបាននូវភាពត្រឹមត្រូវនៃការធ្វើសមកាលកម្មរហូតដល់ 10 ណាណូវិនាទី។
2. ការផ្ទុកម៉ែត្រ
   យើងកំពុងជ្រើសរើសរវាងការសរសេរទំហំផ្ទុកផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ស៊េរីពេលវេលា ឬប្រើប្រាស់អ្វីមួយដែលមានរួចហើយ។ មូលដ្ឋានទិន្នន័យគឺត្រូវការសម្រាប់ទិន្នន័យត្រលប់ក្រោយដែលជាកម្មវត្ថុនៃការមើលឃើញជាបន្តបន្ទាប់ ពោលគឺវាមិនមានទិន្នន័យអំពីការពន្យារពេលក្នុងឆានែលរៀងរាល់ 0.5 មីលីវិនាទី ឬការអានកំហុសក្នុងបណ្តាញដឹកជញ្ជូននោះទេ ប៉ុន្តែវាមានល្បឿននៅលើចំណុចប្រទាក់នីមួយៗរៀងរាល់ 500 មីលីវិនាទី។ បន្ថែមពីលើតម្រូវការខ្ពស់សម្រាប់ដំណើរការឆ្លងវេទិកា និងការប្រើប្រាស់ធនធានទាប វាមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ពួកយើងដើម្បីអាចដំណើរការបាន។ ទិន្នន័យគឺជាកន្លែងដែលវាត្រូវបានរក្សាទុក។ នេះជួយសន្សំសំចៃធនធានកុំព្យូទ័រដ៏ធំសម្បើម។ យើងបានប្រើប្រាស់ Tarantool DBMS នៅក្នុងគម្រោងនេះតាំងពីឆ្នាំ 2016 ហើយរហូតមកដល់ពេលនេះ យើងមិនឃើញការជំនួសសម្រាប់វានៅលើជើងមេឃទេ។ មានភាពបត់បែន ជាមួយនឹងការប្រើប្រាស់ធនធានដ៏ល្អប្រសើរ ច្រើនជាងការគាំទ្រផ្នែកបច្ចេកទេសគ្រប់គ្រាន់។ Tarantool ក៏អនុវត្តម៉ូឌុល GIS ផងដែរ។ ជាការពិតណាស់ វាមិនមានឥទ្ធិពលខ្លាំងដូច PostGIS នោះទេ ប៉ុន្តែវាគ្រប់គ្រាន់សម្រាប់ភារកិច្ចរបស់យើងក្នុងការរក្សាទុករង្វាស់ដែលទាក់ទងនឹងទីតាំងមួយចំនួន (ពាក់ព័ន្ធសម្រាប់ការដឹកជញ្ជូន)។
3. ការមើលឃើញនៃម៉ែត្រ
   អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅទីនេះ។ យើងយកទិន្នន័យពីឃ្លាំង ហើយបង្ហាញវាក្នុងពេលវេលាពិត ឬថយក្រោយ។
4. ការធ្វើសមកាលកម្មទិន្នន័យជាមួយប្រព័ន្ធត្រួតពិនិត្យកណ្តាល។
   ប្រព័ន្ធត្រួតពិនិត្យកណ្តាលទទួលបានទិន្នន័យពីឧបករណ៍ទាំងអស់ រក្សាទុកវាជាមួយនឹងប្រវត្តិដែលបានបញ្ជាក់ ហើយផ្ញើវាទៅប្រព័ន្ធត្រួតពិនិត្យរបស់អតិថិជនតាមរយៈ API ។ មិនដូចប្រព័ន្ធត្រួតពិនិត្យបុរាណ ដែល "ក្បាល" ដើរជុំវិញ និងប្រមូលទិន្នន័យ យើងមានគ្រោងការណ៍ផ្ទុយ។ ឧបករណ៍ខ្លួនឯងបញ្ជូនទិន្នន័យនៅពេលមានការតភ្ជាប់។ នេះគឺជាចំណុចសំខាន់ខ្លាំងណាស់ ព្រោះវាអនុញ្ញាតឱ្យអ្នកទទួលបានទិន្នន័យពីឧបករណ៍សម្រាប់រយៈពេលទាំងនោះក្នុងអំឡុងពេលដែលវាមិនមាន ហើយមិនផ្ទុកបណ្តាញ និងធនធានខណៈពេលដែលឧបករណ៍មិនអាចប្រើបាន។ យើងប្រើម៉ាស៊ីនមេត្រួតពិនិត្យ Influx ជាប្រព័ន្ធត្រួតពិនិត្យកណ្តាល។ មិនដូច analogues របស់វាទេ វាអាចនាំចូលទិន្នន័យត្រលប់ក្រោយ (នោះគឺមានត្រាពេលវេលាខុសពីពេលដែលម៉ែត្រត្រូវបានទទួល)។ ម៉ែត្រដែលប្រមូលបានមើលឃើញដោយ Grafana ដែលបានកែប្រែជាមួយឯកសារមួយ។ ជង់ស្តង់ដារនេះក៏ត្រូវបានជ្រើសរើសផងដែរ ព្រោះវាមានការរួមបញ្ចូល API ដែលត្រៀមរួចជាស្រេចជាមួយនឹងប្រព័ន្ធត្រួតពិនិត្យអតិថិជនស្ទើរតែទាំងអស់។
5. ការធ្វើសមកាលកម្មទិន្នន័យជាមួយប្រព័ន្ធគ្រប់គ្រងឧបករណ៍កណ្តាល។
   ប្រព័ន្ធគ្រប់គ្រងឧបករណ៍អនុវត្ត Zero Touch Provisioning (ការធ្វើបច្ចុប្បន្នភាពកម្មវិធីបង្កប់ ការកំណត់រចនាសម្ព័ន្ធ។ល។) ហើយមិនដូចប្រព័ន្ធត្រួតពិនិត្យទេ ទទួលបានតែបញ្ហាក្នុងមួយឧបករណ៍ប៉ុណ្ណោះ។ ទាំងនេះគឺជាគន្លឹះសម្រាប់ប្រតិបត្តិការនៃសេវាកម្មឃ្លាំមើលផ្នែករឹងនៅលើយន្តហោះ និងប្រព័ន្ធជំនួយជីវិតទាំងអស់៖ សីតុណ្ហភាពស៊ីភីយូ និងអេសអេសឌី ការផ្ទុកស៊ីភីយូ ទំហំទំនេរ និងសុខភាព S.M.A.R.T នៅលើថាស។ ការផ្ទុកប្រព័ន្ធរងក៏ត្រូវបានបង្កើតឡើងនៅលើ 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