របៀបដែលស្ថាបត្យកម្មគេហទំព័រមិនអត់ឱនកំហុសត្រូវបានអនុវត្តនៅក្នុងវេទិកា Mail.ru Cloud Solutions

សួស្តី ហាប! ខ្ញុំគឺ Artem Karamyshev ជាប្រធានក្រុមគ្រប់គ្រងប្រព័ន្ធ Mail.Ru Cloud Solutions (MCS). យើងមានការចេញលក់ផលិតផលថ្មីៗជាច្រើនកាលពីឆ្នាំមុន។ យើងចង់ធានាថា សេវាកម្ម API អាចធ្វើមាត្រដ្ឋានបានយ៉ាងងាយស្រួល អត់ឱនចំពោះកំហុស និងត្រៀមខ្លួនជាស្រេចសម្រាប់ការកើនឡើងយ៉ាងឆាប់រហ័សនៃបន្ទុកអ្នកប្រើប្រាស់។ វេទិការបស់យើងត្រូវបានអនុវត្តនៅលើ OpenStack ហើយខ្ញុំចង់ប្រាប់អ្នកពីបញ្ហានៃការអត់ឱនកំហុសផ្នែកដែលយើងត្រូវដោះស្រាយដើម្បីទទួលបានប្រព័ន្ធដែលអត់ឱនកំហុស។ ខ្ញុំគិតថាវានឹងគួរឱ្យចាប់អារម្មណ៍សម្រាប់អ្នកដែលបង្កើតផលិតផលនៅលើ OpenStack ផងដែរ។

ការអត់ឱនកំហុសជាទូទៅនៃវេទិកាមួយមាន ភាពធន់នៃសមាសធាតុរបស់វា។ ដូច្នេះ យើងនឹងឆ្លងកាត់បន្តិចម្តងៗគ្រប់កម្រិតទាំងអស់ ដែលយើងកំណត់ហានិភ័យ និងបិទវា។

កំណែវីដេអូនៃរឿងនេះ ដែលជាប្រភពចម្បងនៃរបាយការណ៍មួយនៅឯសន្និសីទ Uptime day 4 ដែលរៀបចំដោយ ITSummaអ្នកអាចមើលឃើញ នៅលើបណ្តាញ YouTube សហគមន៍ Uptime.

ភាពធន់នៃស្ថាបត្យកម្មរូបវន្ត

ផ្នែកសាធារណៈនៃ MCS cloud ឥឡូវនេះមានមូលដ្ឋាននៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យលំដាប់ទី III ចំនួនពីរ រវាងពួកវាមានសរសៃងងឹតផ្ទាល់ខ្លួន ដែលត្រូវបានបម្រុងទុកនៅកម្រិតរូបវន្តដោយផ្លូវផ្សេងៗគ្នា ជាមួយនឹងល្បឿន 200 Gbit/s ។ កម្រិត III ផ្តល់នូវកម្រិតចាំបាច់នៃការអត់ឱនកំហុសសម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធរូបវន្ត។

ជាតិសរសៃងងឹតត្រូវបានបម្រុងទុកទាំងកម្រិតរាងកាយ និងឡូជីខល។ ដំណើរការកក់ប៉ុស្តិ៍គឺកើតឡើងដដែលៗ បញ្ហាបានកើតឡើង ហើយយើងកំពុងកែលម្អទំនាក់ទំនងរវាងមជ្ឈមណ្ឌលទិន្នន័យជានិច្ច។

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

នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមានចំណុចនៃវត្តមានរបស់អ្នកផ្តល់សេវាទំនាក់ទំនងដែលយើងផ្សព្វផ្សាយបុព្វបទរបស់យើងតាមរយៈ BGP ។ សម្រាប់ទិសដៅបណ្តាញនីមួយៗ រង្វាស់ល្អបំផុតត្រូវបានជ្រើសរើស ដែលអនុញ្ញាតឱ្យអតិថិជនផ្សេងៗគ្នាត្រូវបានផ្តល់ជូនជាមួយនឹងគុណភាពនៃការតភ្ជាប់ល្អបំផុត។ ប្រសិនបើការប្រាស្រ័យទាក់ទងតាមរយៈអ្នកផ្តល់សេវាមួយធ្លាក់ចុះ យើងបង្កើតផ្លូវរបស់យើងឡើងវិញតាមរយៈអ្នកផ្តល់សេវាដែលមាន។

ប្រសិនបើអ្នកផ្តល់សេវាបរាជ័យ យើងប្តូរទៅអ្នកបន្ទាប់ដោយស្វ័យប្រវត្តិ។ នៅក្នុងព្រឹត្តិការណ៍នៃការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យណាមួយ យើងមានច្បាប់ចម្លងកញ្ចក់នៃសេវាកម្មរបស់យើងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទីពីរ ដែលទទួលយកបន្ទុកទាំងមូល។

ភាពធន់នៃហេដ្ឋារចនាសម្ព័ន្ធរូបវន្ត

អ្វីដែលយើងប្រើសម្រាប់ការអត់ធ្មត់កំហុសកម្រិតកម្មវិធី

សេវាកម្មរបស់យើងត្រូវបានបង្កើតឡើងនៅលើផ្នែកមួយចំនួននៃប្រភពបើកចំហ។

ExaBGP គឺជាសេវាកម្មដែលអនុវត្តមុខងារមួយចំនួនដោយប្រើពិធីការបញ្ជូនផ្លូវថាមវន្តផ្អែកលើ BGP ។ យើងប្រើប្រាស់វាយ៉ាងសកម្មដើម្បីផ្សព្វផ្សាយអាសយដ្ឋាន IP របស់យើងក្នុងបញ្ជីស ដែលអ្នកប្រើប្រាស់ចូលទៅកាន់ API ។

HAProxy គឺជាឧបករណ៍តុល្យភាពបន្ទុកខ្ពស់ដែលអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធច្បាប់តុល្យភាពចរាចរណ៍ដែលអាចបត់បែនបាននៅកម្រិតផ្សេងៗគ្នានៃគំរូ OSI ។ យើងប្រើវាដើម្បីធ្វើសមតុល្យនៅពីមុខសេវាកម្មទាំងអស់៖ មូលដ្ឋានទិន្នន័យ ឈ្មួញកណ្តាលសារ សេវាកម្ម API សេវាកម្មគេហទំព័រ គម្រោងខាងក្នុងរបស់យើង - អ្វីគ្រប់យ៉ាងគឺនៅពីក្រោយ HAProxy ។

កម្មវិធី API - កម្មវិធីបណ្តាញដែលសរសេរជា python ដែលអ្នកប្រើប្រាស់គ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ និងសេវាកម្មរបស់គាត់។

ពាក្យសុំកម្មករ (តទៅនេះជាធម្មតាអ្នកធ្វើការ) - នៅក្នុងសេវាកម្ម OpenStack នេះគឺជាដេមិនហេដ្ឋារចនាសម្ព័ន្ធដែលអនុញ្ញាតឱ្យអ្នកផ្សាយពាក្យបញ្ជា API ទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធ។ ឧទាហរណ៍ ការបង្កើតថាសកើតឡើងនៅក្នុងកម្មករ ហើយសំណើបង្កើតកើតឡើងនៅក្នុង API កម្មវិធី។

ស្ថាបត្យកម្មកម្មវិធី OpenStack ស្តង់ដារ

សេវាកម្មភាគច្រើនដែលត្រូវបានបង្កើតឡើងសម្រាប់ OpenStack ព្យាយាមធ្វើតាមគំរូតែមួយ។ សេវាកម្មមួយជាធម្មតាមាន 2 ផ្នែក៖ API និងកម្មករ (អ្នកប្រតិបត្តិផ្នែកខាងក្រោយ)។ តាមក្បួន API គឺជាកម្មវិធី WSGI នៅក្នុង python ដែលត្រូវបានដាក់ឱ្យដំណើរការជាដំណើរការឯករាជ្យ (daemon) ឬដោយប្រើម៉ាស៊ីនមេបណ្តាញ Nginx ឬ Apache ដែលត្រៀមរួចជាស្រេច។ API ដំណើរការសំណើរបស់អ្នកប្រើ ហើយបញ្ជូនការណែនាំបន្ថែមទៅកម្មវិធីកម្មករសម្រាប់ការប្រតិបត្តិ។ ការផ្ទេរនេះកើតឡើងដោយប្រើឈ្មួញកណ្តាលសារ ជាធម្មតា RabbitMQ ផ្សេងទៀតត្រូវបានគាំទ្រយ៉ាងលំបាក។ នៅពេលដែលសារទៅដល់ឈ្មួញកណ្តាល ពួកគេត្រូវបានដំណើរការដោយកម្មករ ហើយប្រសិនបើចាំបាច់ ឆ្លើយតបមកវិញ។

គំរូនេះពាក់ព័ន្ធនឹងចំណុចរួមនៃការបរាជ័យដាច់ដោយឡែកពីគេ៖ RabbitMQ និងមូលដ្ឋានទិន្នន័យ។ ប៉ុន្តែ RabbitMQ គឺដាច់ពីគ្នាក្នុងសេវាកម្មមួយ ហើយតាមទ្រឹស្តី អាចជាបុគ្គលសម្រាប់សេវាកម្មនីមួយៗ។ ដូច្នេះនៅ MCS យើងបែងចែកសេវាកម្មទាំងនេះតាមដែលអាចធ្វើបាន សម្រាប់គម្រោងនីមួយៗ យើងបង្កើតមូលដ្ឋានទិន្នន័យដាច់ដោយឡែក RabbitMQ ដាច់ដោយឡែក។ វិធីសាស្រ្តនេះគឺល្អព្រោះក្នុងករណីមានឧបទ្ទវហេតុនៅចំណុចដែលងាយរងគ្រោះមួយចំនួន មិនមែនសេវាកម្មទាំងមូលខូចនោះទេ ប៉ុន្តែមានតែផ្នែកមួយប៉ុណ្ណោះ។

ចំនួននៃកម្មវិធីកម្មករគឺគ្មានដែនកំណត់ ដូច្នេះ API អាចធ្វើមាត្រដ្ឋានផ្ដេកយ៉ាងងាយស្រួលនៅពីក្រោយសមតុល្យដើម្បីបង្កើនការអនុវត្ត និងការអត់ធ្មត់ចំពោះកំហុស។

សេវាកម្មមួយចំនួនតម្រូវឱ្យមានការសម្របសម្រួលនៅក្នុងសេវាកម្ម នៅពេលដែលប្រតិបត្តិការជាបន្តបន្ទាប់ដ៏ស្មុគស្មាញកើតឡើងរវាង APIs និងកម្មករ។ ក្នុងករណីនេះ មជ្ឈមណ្ឌលសំរបសំរួលតែមួយត្រូវបានប្រើប្រាស់ ប្រព័ន្ធចង្កោមដូចជា Redis, Memcache, etcd ដែលអនុញ្ញាតឱ្យកម្មករម្នាក់ប្រាប់អ្នកផ្សេងទៀតថាកិច្ចការនេះត្រូវបានប្រគល់ឱ្យគាត់ ("សូមកុំយកវា")។ យើងប្រើល។ តាមក្បួនមួយ កម្មករទំនាក់ទំនងយ៉ាងសកម្មជាមួយមូលដ្ឋានទិន្នន័យ សរសេរ និងអានព័ត៌មានពីទីនោះ។ យើងប្រើ mariadb ជា database ដែលមានទីតាំងនៅក្នុង multimaster cluster។

សេវាកម្មតែមួយបែបបុរាណនេះត្រូវបានរៀបចំតាមរបៀបដែលទទួលយកជាទូទៅសម្រាប់ OpenStack ។ វាអាចត្រូវបានចាត់ទុកថាជាប្រព័ន្ធបិទជិត ដែលវិធីសាស្ត្រនៃការធ្វើមាត្រដ្ឋាន និងការអត់ធ្មត់ចំពោះកំហុសគឺជាក់ស្តែង។ ឧទាហរណ៍សម្រាប់ការអត់ឱនកំហុស API វាគ្រប់គ្រាន់ដើម្បីដាក់តុល្យភាពនៅពីមុខពួកគេ។ ការធ្វើមាត្រដ្ឋានកម្មករត្រូវបានសម្រេចដោយការបង្កើនចំនួនរបស់ពួកគេ។

ចំណុចខ្សោយនៅក្នុងគ្រោងការណ៍ទាំងមូលគឺ RabbitMQ និង MariaDB ។ ស្ថាបត្យកម្មរបស់ពួកគេសមនឹងទទួលបានអត្ថបទដាច់ដោយឡែកមួយ។ នៅក្នុងអត្ថបទនេះខ្ញុំចង់ផ្តោតលើការអត់ឱនកំហុស API ។

ស្ថាបត្យកម្មកម្មវិធី Openstack ។ តុល្យភាព និងការអត់ឱនកំហុសនៃវេទិកាពពក

ធ្វើឱ្យ HAProxy balancer មានភាពអត់ធ្មត់ដោយប្រើ ExaBGP

ដើម្បីធ្វើឱ្យ APIs របស់យើងអាចធ្វើមាត្រដ្ឋានបាន លឿន និងធន់នឹងកំហុស យើងបានដាក់ឧបករណ៍ផ្ទុកតុល្យភាពនៅពីមុខពួកគេ។ យើងជ្រើសរើស HAProxy ។ តាមគំនិតរបស់ខ្ញុំ វាមានលក្ខណៈចាំបាច់ទាំងអស់សម្រាប់កិច្ចការរបស់យើង៖ តុល្យភាពនៅកម្រិត OSI ជាច្រើន ចំណុចប្រទាក់គ្រប់គ្រង ភាពបត់បែន និងការធ្វើមាត្រដ្ឋាន វិធីសាស្ត្រតុល្យភាពមួយចំនួនធំ ការគាំទ្រសម្រាប់តារាងសម័យ។

បញ្ហាដំបូងដែលត្រូវដោះស្រាយគឺការអត់ឱនកំហុសរបស់អ្នកតុល្យភាពខ្លួនឯង។ ការ​ដំឡើង​សមតុល្យ​ដោយ​សាមញ្ញ​ក៏​បង្កើត​នូវ​ចំណុច​នៃ​ការ​បរាជ័យ​ដែរ៖ តុល្យភាព​នឹង​រលត់​ហើយ​សេវាកម្ម​គាំង។ ដើម្បីការពារកុំឱ្យវាកើតឡើង យើងបានប្រើ HAProxy ដោយភ្ជាប់ជាមួយ ExaBGP ។

ExaBGP អនុញ្ញាតឱ្យអ្នកអនុវត្តយន្តការសម្រាប់ពិនិត្យមើលស្ថានភាពនៃសេវាកម្ម។ យើងបានប្រើយន្តការនេះដើម្បីពិនិត្យមើលមុខងាររបស់ HAProxy ហើយក្នុងករណីមានបញ្ហា សូមបិទសេវា HAProxy ពី BGP ។

គ្រោងការណ៍ ExaBGP + HAProxy

1. យើងដំឡើងកម្មវិធីចាំបាច់ ExaBGP និង HAProxy នៅលើម៉ាស៊ីនមេចំនួនបី។
2. យើងបង្កើតចំណុចប្រទាក់រង្វិលជុំនៅលើម៉ាស៊ីនមេនីមួយៗ។
3. នៅលើម៉ាស៊ីនមេទាំងបី យើងផ្តល់អាសយដ្ឋាន IP ពណ៌សដូចគ្នាទៅចំណុចប្រទាក់នេះ។
4. អាសយដ្ឋាន IP ពណ៌សត្រូវបានផ្សព្វផ្សាយទៅអ៊ីនធឺណិតតាមរយៈ ExaBGP ។

ការអត់ឱនចំពោះកំហុសត្រូវបានសម្រេចដោយការផ្សាយពាណិជ្ជកម្មអាសយដ្ឋាន IP ដូចគ្នាពីម៉ាស៊ីនមេទាំងបី។ តាមទស្សនៈបណ្តាញ អាសយដ្ឋានដូចគ្នាអាចចូលប្រើបានពី hops បន្ទាប់បីផ្សេងគ្នា។ រ៉ោតទ័រមើលឃើញផ្លូវដូចគ្នាចំនួនបី ជ្រើសរើសអាទិភាពខ្ពស់បំផុតរបស់ពួកគេដោយផ្អែកលើម៉ែត្រផ្ទាល់របស់វា (ជាទូទៅនេះគឺជាជម្រើសដូចគ្នា) ហើយចរាចរណ៍ទៅតែម៉ាស៊ីនមេមួយប៉ុណ្ណោះ។

ក្នុងករណីមានបញ្ហាជាមួយប្រតិបត្តិការរបស់ HAProxy ឬការបរាជ័យម៉ាស៊ីនមេ ExaBGP ឈប់ប្រកាសផ្លូវ ហើយចរាចរបានយ៉ាងរលូនប្តូរទៅម៉ាស៊ីនមេផ្សេងទៀត។

ដូច្នេះហើយ យើងសម្រេចបាននូវការអត់ឱនចំពោះកំហុសរបស់ឧបករណ៍តុល្យភាព។

ការអត់ឱនកំហុសរបស់ឧបករណ៍តុល្យភាព HAProxy

គ្រោងការណ៍បានប្រែទៅជាមិនល្អឥតខ្ចោះ៖ យើងបានរៀនពីរបៀបកក់ HAProxy ប៉ុន្តែមិនបានរៀនពីរបៀបចែកចាយបន្ទុកនៅក្នុងសេវាកម្មនោះទេ។ ដូច្នេះ យើងបានពង្រីកគ្រោងការណ៍នេះបន្តិច៖ យើងបានបន្តទៅតុល្យភាពរវាងអាសយដ្ឋាន IP ពណ៌សជាច្រើន។

តុល្យភាពផ្អែកលើ DNS បូក BGP

បញ្ហានៃតុល្យភាពបន្ទុកសម្រាប់ HAProxy របស់យើងនៅតែមិនអាចដោះស្រាយបាន។ ទោះយ៉ាងណាក៏ដោយ វាអាចត្រូវបានដោះស្រាយយ៉ាងសាមញ្ញ ដូចដែលយើងបានធ្វើនៅទីនេះ។

ដើម្បីធ្វើសមតុល្យម៉ាស៊ីនមេចំនួន 3 អ្នកនឹងត្រូវការអាសយដ្ឋាន IP ពណ៌សចំនួន XNUMX និង DNS ចាស់ល្អ។ អាសយដ្ឋានទាំងនេះនីមួយៗត្រូវបានកំណត់នៅលើចំណុចប្រទាក់រង្វិលជុំនៃ HAProxy នីមួយៗ ហើយត្រូវបានផ្សព្វផ្សាយទៅអ៊ីនធឺណិត។

នៅក្នុង OpenStack ដើម្បីគ្រប់គ្រងធនធាន បញ្ជីសេវាកម្មត្រូវបានប្រើប្រាស់ ដែលបញ្ជាក់ API ចំណុចបញ្ចប់នៃសេវាកម្មជាក់លាក់មួយ។ នៅក្នុងថតនេះយើងចុះឈ្មោះឈ្មោះដែន - public.infra.mail.ru ដែលត្រូវបានដោះស្រាយតាមរយៈ DNS ដោយអាសយដ្ឋាន IP បីផ្សេងគ្នា។ ជាលទ្ធផល យើងទទួលបានការចែកចាយបន្ទុករវាងអាសយដ្ឋានបីតាមរយៈ DNS ។

ប៉ុន្តែចាប់តាំងពីពេលប្រកាសអាសយដ្ឋាន IP ពណ៌ស យើងមិនគ្រប់គ្រងអាទិភាពនៃការជ្រើសរើសម៉ាស៊ីនមេ នេះមិនទាន់មានតុល្យភាពនៅឡើយ។ ជាធម្មតា មានតែម៉ាស៊ីនមេមួយប៉ុណ្ណោះនឹងត្រូវបានជ្រើសរើសដោយផ្អែកលើអតីតភាពអាសយដ្ឋាន IP ហើយពីរផ្សេងទៀតនឹងនៅទំនេរ ដោយសារមិនមានការបញ្ជាក់នៅក្នុង BGP ទេ។

យើងបានចាប់ផ្តើមផ្ញើផ្លូវតាមរយៈ ExaBGP ជាមួយនឹងម៉ែត្រផ្សេងគ្នា។ តុល្យការនីមួយៗផ្សព្វផ្សាយអាសយដ្ឋាន IP ពណ៌សទាំងបី ប៉ុន្តែមួយក្នុងចំណោមពួកគេ ដែលជាមេសម្រាប់តុល្យភាពនេះត្រូវបានផ្សាយពាណិជ្ជកម្មជាមួយនឹងម៉ែត្រអប្បបរមា។ ដូច្នេះខណៈពេលដែលសមតុល្យទាំងបីកំពុងដំណើរការ ការហៅទៅកាន់អាសយដ្ឋាន IP ទីមួយទៅកាន់សមតុល្យទីមួយ ហៅទៅលេខទីពីរទៅទីពីរ ហើយហៅទៅលេខទីបីទៅទីបី។

តើមានអ្វីកើតឡើងនៅពេលដែល Balancer ម្នាក់ធ្លាក់? ប្រសិនបើអ្នកតុល្យភាពណាមួយបរាជ័យ អាសយដ្ឋានចម្បងរបស់វានៅតែត្រូវបានផ្សព្វផ្សាយពីពីរផ្សេងទៀត ហើយចរាចរណ៍ត្រូវបានចែកចាយឡើងវិញរវាងពួកគេ។ ដូច្នេះ យើងផ្តល់ឱ្យអ្នកប្រើប្រាស់នូវអាសយដ្ឋាន IP ជាច្រើនក្នុងពេលតែមួយតាមរយៈ DNS ។ តាមរយៈការធ្វើសមតុល្យដោយ DNS និងម៉ែត្រផ្សេងគ្នា យើងទទួលបានការចែកចាយសូម្បីតែនៃបន្ទុកនៅទូទាំងតុល្យភាពទាំងបី។ ហើយក្នុងពេលជាមួយគ្នានេះ យើងមិនបាត់បង់ការអត់ឱនចំពោះកំហុសនោះទេ។

តុល្យភាព HAProxy ផ្អែកលើ DNS + BGP

អន្តរកម្មរវាង ExaBGP និង HAProxy

ដូច្នេះ យើងបានអនុវត្តការអត់ឱនចំពោះកំហុសក្នុងករណីដែលម៉ាស៊ីនមេចាកចេញ ដោយផ្អែកលើការបញ្ឈប់ការប្រកាសផ្លូវ។ ប៉ុន្តែ HAProxy អាចបិទសម្រាប់ហេតុផលផ្សេងទៀតជាងការបរាជ័យរបស់ម៉ាស៊ីនមេ៖ កំហុសរដ្ឋបាល ការបរាជ័យនៅក្នុងសេវាកម្ម។ យើងចង់ដកសមតុល្យដែលខូចចេញពីក្រោមបន្ទុកនៅក្នុងករណីទាំងនេះផងដែរ ហើយយើងត្រូវការយន្តការផ្សេង។

ដូច្នេះហើយ ការពង្រីកគ្រោងការណ៍ពីមុន យើងបានអនុវត្តចង្វាក់បេះដូងរវាង ExaBGP និង HAProxy ។ នេះគឺជាការអនុវត្តកម្មវិធីនៃអន្តរកម្មរវាង ExaBGP និង HAProxy នៅពេលដែល ExaBGP ប្រើស្គ្រីបផ្ទាល់ខ្លួនដើម្បីពិនិត្យមើលស្ថានភាពនៃកម្មវិធី។

ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធកម្មវិធីពិនិត្យសុខភាពនៅក្នុង ExaBGP config ដែលអាចពិនិត្យមើលស្ថានភាពរបស់ HAProxy ។ ក្នុងករណីរបស់យើង យើងបានកំណត់រចនាសម្ព័ន្ធផ្នែកខាងក្រោយសុខភាពនៅក្នុង HAProxy ហើយពីផ្នែក ExaBGP យើងពិនិត្យជាមួយនឹងសំណើ GET ដ៏សាមញ្ញមួយ។ ប្រសិនបើការប្រកាសឈប់កើតឡើង នោះ HAProxy ទំនងជាមិនដំណើរការ ហើយមិនចាំបាច់ផ្សព្វផ្សាយវាទេ។

ការពិនិត្យសុខភាព HAProxy

HAProxy Peers៖ ការធ្វើសមកាលកម្មសម័យ

រឿងបន្ទាប់ដែលត្រូវធ្វើគឺធ្វើសមកាលកម្មវគ្គ។ នៅពេលធ្វើការតាមរយៈសមតុល្យដែលបានចែកចាយ វាពិបាកក្នុងការរៀបចំការផ្ទុកព័ត៌មានអំពីវគ្គអតិថិជន។ ប៉ុន្តែ HAProxy គឺជាផ្នែកមួយនៃតុល្យភាពមួយចំនួនដែលអាចធ្វើដូចនេះបានដោយសារតែមុខងារ Peers - សមត្ថភាពក្នុងការផ្ទេរតារាងសម័យរវាងដំណើរការ HAProxy ផ្សេងៗគ្នា។

មានវិធីសាស្រ្តតុល្យភាពផ្សេងគ្នា: សាមញ្ញដូចជា រ៉ូបូតមូលនិងបានពង្រីក នៅពេលដែលវគ្គរបស់អតិថិជនត្រូវបានចងចាំ ហើយរាល់ពេលដែលគាត់បញ្ចប់នៅលើម៉ាស៊ីនមេដូចពីមុន។ យើងចង់អនុវត្តជម្រើសទីពីរ។

HAProxy ប្រើ stick-tables ដើម្បីរក្សាទុកវគ្គអតិថិជននៃយន្តការនេះ។ ពួកគេរក្សាទុកអាសយដ្ឋាន IP ដើមរបស់អតិថិជន អាសយដ្ឋានគោលដៅដែលបានជ្រើសរើស (ផ្នែកខាងក្រោយ) និងព័ត៌មានសេវាកម្មមួយចំនួន។ ជាធម្មតា តារាងដំបងត្រូវបានប្រើដើម្បីរក្សាទុកគូប្រភព-IP + ទិសដៅ-IP ដែលមានប្រយោជន៍ជាពិសេសសម្រាប់កម្មវិធីដែលមិនអាចផ្ទេរបរិបទវេនអ្នកប្រើប្រាស់នៅពេលប្តូរទៅឧបករណ៍តុល្យភាពផ្សេងទៀត ឧទាហរណ៍នៅក្នុងរបៀបតុល្យភាព RoundRobin ។

ប្រសិនបើតារាងឈើត្រូវបានបង្រៀនឱ្យផ្លាស់ទីរវាងដំណើរការ HAProxy ផ្សេងៗគ្នា (រវាងតុល្យភាពកើតឡើង) តុល្យភាពរបស់យើងនឹងអាចធ្វើការជាមួយតុឈើមួយ។ វា​នឹង​ធ្វើ​ឱ្យ​វា​អាច​ប្តូរ​បណ្តាញ​របស់​អតិថិជន​បាន​យ៉ាង​រលូន ប្រសិនបើ​សមតុល្យ​ណាមួយ​បរាជ័យ ការងារ​ជាមួយ​វគ្គ​អតិថិជន​នឹង​បន្ត​នៅលើ​កម្មវិធី​ខាងក្រោយ​ដូចគ្នា​ដែល​ត្រូវ​បាន​ជ្រើសរើស​ពីមុន។

សម្រាប់ប្រតិបត្តិការត្រឹមត្រូវ បញ្ហានៃអាសយដ្ឋាន IP ប្រភពនៃតុល្យភាពដែលវគ្គត្រូវបានបង្កើតឡើងត្រូវតែដោះស្រាយ។ ក្នុងករណីរបស់យើង នេះគឺជាអាសយដ្ឋានថាមវន្តនៅលើចំណុចប្រទាក់រង្វិលជុំ។

ការងារត្រឹមត្រូវរបស់មិត្តភក្ដិគឺសម្រេចបានតែក្នុងលក្ខខណ្ឌមួយចំនួនប៉ុណ្ណោះ។ នោះគឺការអស់ពេល TCP ត្រូវតែធំល្មម ឬការប្តូរត្រូវតែលឿនគ្រប់គ្រាន់ ដូច្នេះវគ្គ TCP មិនមានពេលវេលាដើម្បីបញ្ចប់។ ទោះយ៉ាងណាក៏ដោយវាអនុញ្ញាតឱ្យមានការផ្លាស់ប្តូរដោយគ្មានថ្នេរ។

នៅក្នុង IaaS យើងមានសេវាកម្មមួយដែលត្រូវបានបង្កើតឡើងដោយប្រើបច្ចេកវិទ្យាដូចគ្នា។ នេះ។ Load Balancer ជាសេវាកម្មសម្រាប់ OpenStackដែលត្រូវបានគេហៅថា Octavia ។ វាត្រូវបានផ្អែកលើដំណើរការ HAProxy ពីរ ហើយដំបូងរួមបញ្ចូលការគាំទ្រសម្រាប់មិត្តភក្ដិ។ ពួក​គេ​បាន​បង្ហាញ​ខ្លួន​ឯង​ថា​ពូកែ​ក្នុង​សេវាកម្ម​នេះ។

រូបភាពបង្ហាញពីចលនានៃតារាងមិត្តភ័ក្តិរវាងឧទាហរណ៍ HAProxy ចំនួនបី ការកំណត់ត្រូវបានស្នើឡើងអំពីរបៀបដែលវាអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធ៖

HAProxy Peers (ការធ្វើសមកាលកម្មសម័យ)

ប្រសិនបើអ្នកអនុវត្តគ្រោងការណ៍ដូចគ្នានោះប្រតិបត្តិការរបស់វាត្រូវតែត្រូវបានសាកល្បងដោយប្រុងប្រយ័ត្ន។ វាមិនមែនជាការពិតដែលថាវានឹងដំណើរការដូចគ្នា 100% នៃពេលវេលានោះទេ។ ប៉ុន្តែយ៉ាងហោចណាស់អ្នកនឹងមិនបាត់បង់តារាងឈើទេ នៅពេលដែលអ្នកត្រូវការចងចាំ IP ប្រភពរបស់អតិថិជន។

ការកំណត់ចំនួនសំណើក្នុងពេលដំណាលគ្នាពីអតិថិជនដូចគ្នា។

សេវាកម្មណាមួយដែលអាចប្រើបានជាសាធារណៈ រួមទាំង APIs របស់យើង អាចជាកម្មវត្ថុនៃការស្នើរសុំ។ ហេតុផលសម្រាប់ពួកគេអាចមានភាពខុសគ្នាទាំងស្រុង ពីកំហុសរបស់អ្នកប្រើប្រាស់ រហូតដល់ការវាយប្រហារគោលដៅ។ យើងត្រូវបាន DDoSed ជាទៀងទាត់ដោយអាសយដ្ឋាន IP ។ អតិថិជនតែងតែធ្វើខុសនៅក្នុងស្គ្រីបរបស់ពួកគេ ហើយផ្តល់ឱ្យយើងនូវ mini-DDoSs ។

វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត ការការពារបន្ថែមត្រូវតែត្រូវបានផ្តល់ជូន។ ដំណោះស្រាយជាក់ស្តែងគឺកំណត់ចំនួនសំណើ API និងមិនខ្ជះខ្ជាយពេលវេលា CPU ដំណើរការសំណើព្យាបាទ។

ដើម្បីអនុវត្តការរឹតបន្តឹងបែបនេះ យើងប្រើដែនកំណត់អត្រា ដែលរៀបចំនៅលើមូលដ្ឋាននៃ HAProxy ដោយប្រើតារាងឈើដូចគ្នា។ ការកំណត់ដែនកំណត់គឺសាមញ្ញណាស់ ហើយអនុញ្ញាតឱ្យអ្នកកំណត់អ្នកប្រើប្រាស់ដោយចំនួនសំណើទៅ API ។ ក្បួនដោះស្រាយចងចាំ IP ប្រភពដែលសំណើត្រូវបានធ្វើឡើង និងកំណត់ចំនួនសំណើក្នុងពេលដំណាលគ្នាពីអ្នកប្រើប្រាស់ម្នាក់។ ជាការពិតណាស់ យើងបានគណនាទម្រង់ផ្ទុក API ជាមធ្យមសម្រាប់សេវាកម្មនីមួយៗ ហើយកំណត់ដែនកំណត់ ≈ 10 ដងនៃតម្លៃនេះ។ យើងបន្តតាមដានស្ថានភាពយ៉ាងដិតដល់ និងរក្សាម្រាមដៃរបស់យើងនៅលើជីពចរ។

តើនេះមើលទៅដូចអ្វីនៅក្នុងការអនុវត្ត? យើងមានអតិថិជនដែលប្រើ APIs ស្វ័យប្រវត្តិរបស់យើងគ្រប់ពេលវេលា។ ពួកគេបង្កើតម៉ាស៊ីននិម្មិតប្រហែលពីរទៅបីរយនៅពេលព្រឹក ហើយលុបវានៅពេលល្ងាច។ សម្រាប់ OpenStack ការបង្កើតម៉ាស៊ីននិម្មិត រួមទាំងសេវាកម្ម PaaS ទាមទារយ៉ាងហោចណាស់ 1000 សំណើ API ចាប់តាំងពីអន្តរកម្មរវាងសេវាកម្មក៏កើតឡើងតាមរយៈ API ផងដែរ។

ការផ្ទេរភារកិច្ចបែបនេះបណ្តាលឱ្យមានបន្ទុកធំល្មម។ យើងបានវាយតម្លៃបន្ទុកនេះ ប្រមូលចំនួនកំពូលប្រចាំថ្ងៃ បង្កើនចំនួនដប់ដង ហើយនេះបានក្លាយជាដែនកំណត់អត្រារបស់យើង។ យើងទុកម្រាមដៃរបស់យើងនៅលើជីពចរ។ ជាញឹកញាប់យើងឃើញ bots និងម៉ាស៊ីនស្កេនដែលព្យាយាមមើលមកយើងដើម្បីមើលថាតើយើងមានស្គ្រីប CGA ណាដែលអាចដំណើរការបាន យើងកំពុងកាត់វាយ៉ាងសកម្ម។

របៀបអាប់ដេតមូលដ្ឋានកូដរបស់អ្នកដោយមិនមានអ្នកប្រើប្រាស់កត់សម្គាល់

យើងក៏អនុវត្តការអត់ឱនកំហុសនៅកម្រិតនៃដំណើរការដាក់ពង្រាយកូដផងដែរ។ វាអាចមានកំហុសកំឡុងពេលដាក់ឱ្យដំណើរការ ប៉ុន្តែផលប៉ះពាល់របស់វាទៅលើភាពមានសេវាកម្មអាចត្រូវបានបង្រួមអប្បបរមា។

យើងធ្វើបច្ចុប្បន្នភាពសេវាកម្មរបស់យើងឥតឈប់ឈរ ហើយត្រូវតែធានាថាមូលដ្ឋានកូដត្រូវបានធ្វើបច្ចុប្បន្នភាពដោយមិនប៉ះពាល់ដល់អ្នកប្រើប្រាស់។ យើងបានដោះស្រាយបញ្ហានេះដោយប្រើសមត្ថភាពគ្រប់គ្រងរបស់ HAProxy និងការអនុវត្តការបិទដោយប្រយោលនៅក្នុងសេវាកម្មរបស់យើង។

ដើម្បីដោះស្រាយបញ្ហានេះ វាចាំបាច់ដើម្បីធានាការគ្រប់គ្រងតុល្យភាព និងការបិទសេវាកម្ម "ត្រឹមត្រូវ"៖

• ក្នុងករណី HAProxy ការគ្រប់គ្រងត្រូវបានអនុវត្តតាមរយៈឯកសារស្ថិតិ ដែលសំខាន់គឺរន្ធមួយ ហើយត្រូវបានកំណត់នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ HAProxy ។ អ្នកអាចផ្ញើពាក្យបញ្ជាទៅវាតាមរយៈ stdio ។ ប៉ុន្តែឧបករណ៍ត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធចម្បងរបស់យើងគឺមិនអាចប្រើប្រាស់បាន ដូច្នេះវាមានម៉ូឌុលដែលភ្ជាប់មកជាមួយសម្រាប់គ្រប់គ្រង HAProxy ។ ដែលយើងប្រើយ៉ាងសកម្ម។
• សេវាកម្ម API និង Engine របស់យើងភាគច្រើនគាំទ្របច្ចេកវិទ្យាបិទយ៉ាងប្រណិត៖ នៅពេលបិទ ពួកគេរង់ចាំឱ្យកិច្ចការបច្ចុប្បន្នបញ្ចប់ ថាតើវាជាសំណើ http ឬកិច្ចការសេវាកម្មមួយចំនួន។ រឿងដដែលនេះកើតឡើងជាមួយកម្មករ។ វាដឹងពីកិច្ចការទាំងអស់ដែលខ្លួនកំពុងធ្វើ ហើយបញ្ចប់នៅពេលដែលវាបានបញ្ចប់គ្រប់យ៉ាងដោយជោគជ័យ។

សូមអរគុណចំពោះចំណុចទាំងពីរនេះ ក្បួនដោះស្រាយសុវត្ថិភាពសម្រាប់ការដាក់ពង្រាយរបស់យើងមើលទៅដូចនេះ។

1. អ្នកអភិវឌ្ឍន៍ប្រមូលផ្តុំកញ្ចប់កូដថ្មី (សម្រាប់យើងនេះគឺជា RPM) សាកល្បងវានៅក្នុងបរិស្ថានអ្នកអភិវឌ្ឍន៍ សាកល្បងវាក្នុងដំណាក់កាល ហើយទុកវានៅក្នុងឃ្លាំងដំណាក់កាល។
2. អ្នកអភិវឌ្ឍន៍កំណត់ភារកិច្ចសម្រាប់ការដាក់ពង្រាយជាមួយនឹងការពិពណ៌នាលម្អិតបំផុតនៃ "វត្ថុបុរាណ"៖ កំណែនៃកញ្ចប់ថ្មី ការពិពណ៌នាអំពីមុខងារថ្មី និងព័ត៌មានលម្អិតផ្សេងទៀតអំពីការដាក់ឱ្យប្រើប្រាស់ប្រសិនបើចាំបាច់។
3. អ្នកគ្រប់គ្រងប្រព័ន្ធចាប់ផ្តើមធ្វើបច្ចុប្បន្នភាព។ បើកដំណើរការ Ansible playbook ដែលធ្វើដូចខាងក្រោម៖
   • យកកញ្ចប់មួយពីឃ្លាំងដំណាក់កាល ហើយប្រើវាដើម្បីធ្វើបច្ចុប្បន្នភាពកំណែនៃកញ្ចប់នៅក្នុងឃ្លាំងផលិតផល។
   • ចងក្រងបញ្ជីនៃផ្នែកខាងក្រោយនៃសេវាកម្មដែលបានធ្វើបច្ចុប្បន្នភាព។
   • បិទសេវាកម្មដំបូងដែលត្រូវធ្វើបច្ចុប្បន្នភាពនៅក្នុង HAProxy ហើយរង់ចាំដំណើរការរបស់វាបញ្ចប់ដំណើរការ។ សូមអរគុណចំពោះការបិទប្រកបដោយភាពទន់ភ្លន់ យើងមានទំនុកចិត្តថារាល់សំណើរបស់អតិថិជនបច្ចុប្បន្ននឹងបញ្ចប់ដោយជោគជ័យ។
   • បន្ទាប់ពី API និងកម្មករត្រូវបានបញ្ឈប់ទាំងស្រុង ហើយ HAProxy ត្រូវបានបិទ លេខកូដត្រូវបានធ្វើបច្ចុប្បន្នភាព។
   • សេវាកម្មដំណើរការ Ansible ។
   • សម្រាប់សេវាកម្មនីមួយៗ "ចំណុចទាញ" ជាក់លាក់ត្រូវបានទាញ ដែលអនុវត្តការធ្វើតេស្តឯកតាលើការធ្វើតេស្តគន្លឹះដែលបានកំណត់ជាមុនមួយចំនួន។ ការត្រួតពិនិត្យជាមូលដ្ឋាននៃលេខកូដថ្មីកើតឡើង។
   • ប្រសិនបើគ្មានកំហុសត្រូវបានរកឃើញនៅក្នុងជំហានមុនទេនោះ កម្មវិធីខាងក្រោយត្រូវបានធ្វើឱ្យសកម្ម។
   • តោះបន្តទៅផ្នែកខាងក្រោយបន្ទាប់។
4. បន្ទាប់ពីកម្មវិធីខាងក្រោយទាំងអស់ត្រូវបានធ្វើបច្ចុប្បន្នភាព ការធ្វើតេស្តមុខងារត្រូវបានចាប់ផ្តើម។ ប្រសិនបើពួកគេបាត់ នោះអ្នកអភិវឌ្ឍន៍មើលមុខងារថ្មីណាមួយដែលគាត់បានបង្កើត។

នេះបញ្ចប់ការដាក់ពង្រាយ។

វដ្តនៃការធ្វើបច្ចុប្បន្នភាពសេវាកម្ម

គ្រោងការណ៍នេះនឹងមិនដំណើរការទេប្រសិនបើយើងមិនមានច្បាប់តែមួយ។ យើងគាំទ្រទាំងកំណែចាស់ និងថ្មីនៅក្នុងសមរភូមិ។ ជាមុននៅដំណាក់កាលនៃការអភិវឌ្ឍន៍កម្មវិធីវាត្រូវបានកំណត់ថាទោះបីជាមានការផ្លាស់ប្តូរនៅក្នុងមូលដ្ឋានទិន្នន័យសេវាកម្មក៏ដោយក៏ពួកគេនឹងមិនបំបែកកូដពីមុនដែរ។ ជាលទ្ធផល មូលដ្ឋានកូដត្រូវបានធ្វើបច្ចុប្បន្នភាពបន្តិចម្តងៗ។

សេចក្តីសន្និដ្ឋាន

ចែករំលែកគំនិតផ្ទាល់ខ្លួនរបស់ខ្ញុំអំពីស្ថាបត្យកម្មគេហទំព័រដែលអត់ឱនចំពោះកំហុស ខ្ញុំចង់កត់សម្គាល់ម្តងទៀតនូវចំណុចសំខាន់ៗរបស់វា៖

• ភាពអត់ធ្មត់នៃកំហុសរាងកាយ;
• ការអត់ធ្មត់កំហុសបណ្តាញ (សមតុល្យ, BGP);
• ការអត់ឱនចំពោះកំហុសនៃកម្មវិធីដែលបានប្រើ និងបង្កើត។

ការងារមានស្ថេរភាពទាំងអស់គ្នា!

ប្រភព: www.habr.com