ស្ថាបត្យកម្មនៃតុល្យភាពផ្ទុកបណ្តាញនៅក្នុង Yandex.Cloud

ជំរាបសួរ, ខ្ញុំគឺ Sergey Elantsev, ខ្ញុំអភិវឌ្ឍ ឧបករណ៍ផ្ទុកតុល្យភាពបណ្តាញ នៅក្នុង Yandex.Cloud ។ កាលពីមុនខ្ញុំបានដឹកនាំការអភិវឌ្ឍន៍ L7 balancer សម្រាប់វិបផតថល Yandex - មិត្តរួមការងារនិយាយលេងថាមិនថាខ្ញុំធ្វើអ្វីក៏ដោយវាប្រែជាតុល្យភាព។ ខ្ញុំនឹងប្រាប់អ្នកអាន Habr ពីរបៀបគ្រប់គ្រងការផ្ទុកនៅក្នុងវេទិកាពពក អ្វីដែលយើងមើលឃើញថាជាឧបករណ៍ដ៏ល្អសម្រាប់ការសម្រេចបាននូវគោលដៅនេះ និងរបៀបដែលយើងកំពុងឆ្ពោះទៅរកការកសាងឧបករណ៍នេះ។

ជាដំបូងសូមណែនាំពាក្យមួយចំនួន៖

• វីអាយភី (អាយភីនិម្មិត) - អាសយដ្ឋាន IP ដែលមានតុល្យភាព
• Server, backend, instance - ម៉ាស៊ីននិម្មិតដែលកំពុងដំណើរការកម្មវិធី
• RIP (អាយភីពិតប្រាកដ) - អាសយដ្ឋាន IP របស់ម៉ាស៊ីនមេ
• ការពិនិត្យសុខភាព - ពិនិត្យមើលការត្រៀមខ្លួនរបស់ម៉ាស៊ីនមេ
• Availability Zone, AZ - ហេដ្ឋារចនាសម្ព័ន្ធដាច់ស្រយាលនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ
• តំបន់ - សហជីពនៃ AZs ផ្សេងគ្នា

Load Balancers ដោះស្រាយកិច្ចការសំខាន់ៗចំនួនបី៖ ពួកគេអនុវត្តតុល្យភាពខ្លួនវា ធ្វើអោយប្រសើរឡើងនូវភាពអត់ធ្មត់នៃកំហុសនៃសេវាកម្ម និងធ្វើឱ្យមាត្រដ្ឋានរបស់វាមានភាពសាមញ្ញ។ ការអត់ឱនចំពោះកំហុសត្រូវបានធានាតាមរយៈការគ្រប់គ្រងចរាចរណ៍ដោយស្វ័យប្រវត្តិ៖ តុល្យភាពត្រួតពិនិត្យស្ថានភាពនៃកម្មវិធី និងមិនរាប់បញ្ចូលករណីពីតុល្យភាពដែលមិនឆ្លងកាត់ការត្រួតពិនិត្យភាពរស់រវើក។ ការធ្វើមាត្រដ្ឋានត្រូវបានធានាដោយការចែកចាយបន្ទុកស្មើៗគ្នានៅទូទាំងវត្ថុ ក៏ដូចជាការធ្វើបច្ចុប្បន្នភាពបញ្ជីនៃវត្ថុភ្លាមៗ។ ប្រសិនបើសមតុល្យមិនស្មើគ្នាគ្រប់គ្រាន់ទេ ករណីមួយចំនួននឹងទទួលបានបន្ទុកលើសពីដែនកំណត់សមត្ថភាពរបស់ពួកគេ ហើយសេវាកម្មនឹងកាន់តែគួរឱ្យទុកចិត្ត។

ឧបករណ៍ផ្ទុកតុល្យភាពត្រូវបានចាត់ថ្នាក់ជាញឹកញាប់ដោយស្រទាប់ពិធីការពីគំរូ OSI ដែលវាដំណើរការ។ Cloud Balancer ដំណើរការនៅកម្រិត TCP ដែលត្រូវនឹងស្រទាប់ទី 4 LXNUMX ។

ចូរបន្តទៅទិដ្ឋភាពទូទៅនៃស្ថាបត្យកម្ម Cloud balancer ។ យើងនឹងបង្កើនកម្រិតនៃព័ត៌មានលម្អិតបន្តិចម្តងៗ។ យើងបែងចែកសមាសធាតុតុល្យភាពជាបីថ្នាក់។ ថ្នាក់ config plane គឺទទួលខុសត្រូវចំពោះអន្តរកម្មអ្នកប្រើប្រាស់ និងរក្សាទុកស្ថានភាពគោលដៅនៃប្រព័ន្ធ។ យន្តហោះគ្រប់គ្រងរក្សាទុកស្ថានភាពបច្ចុប្បន្ននៃប្រព័ន្ធ និងគ្រប់គ្រងប្រព័ន្ធពីថ្នាក់យន្តហោះទិន្នន័យ ដែលទទួលខុសត្រូវផ្ទាល់ក្នុងការបញ្ជូនចរាចរពីអតិថិជនទៅកាន់ករណីរបស់អ្នក។

យន្តហោះទិន្នន័យ

ចរាចរណ៍បញ្ចប់នៅលើឧបករណ៍ថ្លៃ ៗ ដែលហៅថារ៉ោតទ័រព្រំដែន។ ដើម្បីបង្កើនការអត់ឱនចំពោះកំហុស ឧបករណ៍បែបនេះជាច្រើនដំណើរការក្នុងពេលដំណាលគ្នានៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមួយ។ បន្ទាប់មក ចរាចរទៅកាន់អ្នកតុល្យភាព ដែលប្រកាសអាសយដ្ឋាន IP ណាមួយទៅកាន់ AZs ទាំងអស់តាមរយៈ BGP សម្រាប់អតិថិជន។ 

ចរាចរណ៍ត្រូវបានបញ្ជូនតាម ECMP - នេះគឺជាយុទ្ធសាស្ត្រកំណត់ផ្លូវមួយ យោងទៅតាមដែលអាចមានផ្លូវល្អស្មើគ្នាជាច្រើនទៅកាន់គោលដៅ (ក្នុងករណីរបស់យើង គោលដៅនឹងក្លាយជាអាសយដ្ឋាន IP គោលដៅ) ហើយកញ្ចប់ព័ត៌មានអាចត្រូវបានផ្ញើតាមពួកវាណាមួយ។ យើងក៏គាំទ្រការងារនៅក្នុងតំបន់ដែលអាចរកបានជាច្រើនដោយយោងទៅតាមគ្រោងការណ៍ខាងក្រោម៖ យើងផ្សព្វផ្សាយអាសយដ្ឋាននៅក្នុងតំបន់នីមួយៗ ចរាចរទៅកាន់កន្លែងដែលនៅជិតបំផុត ហើយមិនហួសពីដែនកំណត់របស់វា។ នៅពេលក្រោយ យើងនឹងពិនិត្យមើលលម្អិតបន្ថែមទៀតអំពីអ្វីដែលកើតឡើងចំពោះចរាចរណ៍។

កំណត់រចនាសម្ព័ន្ធយន្តហោះ

 
ធាតុផ្សំសំខាន់នៃយន្តហោះកំណត់រចនាសម្ព័ន្ធគឺ API ដែលប្រតិបត្តិការជាមូលដ្ឋានជាមួយសមតុល្យត្រូវបានអនុវត្ត៖ ការបង្កើត ការលុប ការផ្លាស់ប្តូរសមាសភាពនៃវត្ថុ ទទួលបានលទ្ធផលពិនិត្យសុខភាព។ល។ ម្យ៉ាងវិញទៀតនេះគឺជា REST API ហើយនៅលើ ផ្សេងទៀត យើងនៅក្នុង Cloud ជាញឹកញាប់ប្រើ gRPC ក្របខ័ណ្ឌ ដូច្នេះយើង "បកប្រែ" REST ទៅ gRPC ហើយបន្ទាប់មកប្រើតែ gRPC ប៉ុណ្ណោះ។ សំណើណាមួយនាំទៅដល់ការបង្កើតជាបន្តបន្ទាប់នៃកិច្ចការ ideempotent អសមកាលមួយដែលត្រូវបានប្រតិបត្តិនៅលើក្រុមទូទៅនៃបុគ្គលិក Yandex.Cloud ។ កិច្ចការត្រូវបានសរសេរតាមរបៀបដែលពួកគេអាចផ្អាកបានគ្រប់ពេល ហើយបន្ទាប់មកចាប់ផ្តើមឡើងវិញ នេះធានានូវលទ្ធភាពធ្វើមាត្រដ្ឋាន ភាពអាចធ្វើម្តងទៀត និងការកត់ត្រាប្រតិបត្តិការ។

ជាលទ្ធផល ភារកិច្ចពី API នឹងធ្វើការស្នើសុំទៅកាន់ឧបករណ៍បញ្ជាសេវាតុល្យភាពដែលត្រូវបានសរសេរនៅក្នុង Go ។ វាអាចបន្ថែម និងលុបតុល្យភាព ផ្លាស់ប្តូរសមាសភាពនៃផ្នែកខាងក្រោយ និងការកំណត់។ 

សេវាកម្មរក្សាទុកស្ថានភាពរបស់វានៅក្នុង Yandex Database ដែលជាមូលដ្ឋានទិន្នន័យដែលបានគ្រប់គ្រងចែកចាយដែលអ្នកនឹងអាចប្រើប្រាស់បានក្នុងពេលឆាប់ៗនេះ។ នៅក្នុង Yandex.Cloud ដូចដែលយើងរួចហើយ បានប្រាប់គំនិតអាហារឆ្កែត្រូវបានអនុវត្ត៖ ប្រសិនបើយើងខ្លួនឯងប្រើប្រាស់សេវាកម្មរបស់យើង នោះអតិថិជនរបស់យើងក៏នឹងរីករាយក្នុងការប្រើប្រាស់វាផងដែរ។ មូលដ្ឋានទិន្នន័យ Yandex គឺជាឧទាហរណ៍នៃការអនុវត្តគំនិតបែបនេះ។ យើងរក្សាទុកទិន្នន័យរបស់យើងទាំងអស់នៅក្នុង YDB ហើយយើងមិនចាំបាច់គិតអំពីការរក្សា និងធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យទេ៖ បញ្ហាទាំងនេះត្រូវបានដោះស្រាយសម្រាប់យើង យើងប្រើមូលដ្ឋានទិន្នន័យជាសេវាកម្មមួយ។

ចូរយើងត្រលប់ទៅឧបករណ៍បញ្ជាតុល្យភាព។ ភារកិច្ចរបស់វាគឺដើម្បីរក្សាទុកព័ត៌មានអំពីសមតុល្យនិងផ្ញើភារកិច្ចដើម្បីពិនិត្យមើលការត្រៀមខ្លួនរបស់ម៉ាស៊ីននិម្មិតទៅឧបករណ៍ត្រួតពិនិត្យសុខភាព។

ឧបករណ៍ត្រួតពិនិត្យសុខភាព

វាទទួលសំណើដើម្បីផ្លាស់ប្តូរច្បាប់ត្រួតពិនិត្យ រក្សាទុកពួកវាក្នុង YDB ចែកចាយភារកិច្ចក្នុងចំណោមថ្នាំងពិនិត្យសុខភាព និងសរុបលទ្ធផល ដែលបន្ទាប់មកត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ និងផ្ញើទៅឧបករណ៍បញ្ជា loadbalancer ។ វាជាវេនផ្ញើសំណើដើម្បីផ្លាស់ប្តូរសមាសភាពនៃចង្កោមនៅក្នុងយន្តហោះទិន្នន័យទៅកាន់ loadbalancer-node ដែលខ្ញុំនឹងពិភាក្សាខាងក្រោម។

ចូរនិយាយបន្ថែមទៀតអំពីការពិនិត្យសុខភាព។ ពួកគេអាចត្រូវបានបែងចែកជាថ្នាក់ជាច្រើន។ សវនកម្មមានលក្ខណៈវិនិច្ឆ័យជោគជ័យខុសៗគ្នា។ ការត្រួតពិនិត្យ TCP ចាំបាច់ត្រូវបង្កើតការតភ្ជាប់ដោយជោគជ័យក្នុងរយៈពេលកំណត់។ ការត្រួតពិនិត្យ HTTP ទាមទារទាំងការតភ្ជាប់ជោគជ័យ និងការឆ្លើយតបជាមួយនឹងលេខកូដស្ថានភាព 200។

ដូចគ្នានេះផងដែរការត្រួតពិនិត្យខុសគ្នានៅក្នុងថ្នាក់នៃសកម្មភាព - ពួកគេសកម្មនិងអកម្ម។ ការត្រួតពិនិត្យអកម្មគ្រាន់តែត្រួតពិនិត្យនូវអ្វីដែលកំពុងកើតឡើងជាមួយចរាចរណ៍ដោយមិនចាត់វិធានការពិសេសណាមួយឡើយ។ វាមិនដំណើរការល្អនៅលើ L4 ព្រោះវាអាស្រ័យលើតក្កវិជ្ជានៃពិធីការកម្រិតខ្ពស់៖ នៅលើ L4 មិនមានព័ត៌មានអំពីរយៈពេលប្រតិបត្តិការ ឬថាតើការបញ្ចប់ការតភ្ជាប់ល្អ ឬអាក្រក់នោះទេ។ ការត្រួតពិនិត្យសកម្មតម្រូវឱ្យ Balancer ផ្ញើសំណើទៅកាន់ម៉ាស៊ីនមេនីមួយៗ។

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

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

ភាពខុសប្លែកគ្នានោះគឺថាអតិថិជនធ្វើសំណើទៅវីអាយភី ខណៈពេលដែលការពិនិត្យសុខភាពធ្វើសំណើទៅ RIP នីមួយៗ។ បញ្ហាគួរឱ្យចាប់អារម្មណ៍មួយកើតឡើងនៅទីនេះ៖ យើងផ្តល់ឱ្យអ្នកប្រើប្រាស់របស់យើងនូវឱកាសដើម្បីបង្កើតធនធាននៅក្នុងបណ្តាញ IP ពណ៌ប្រផេះ។ សូមស្រមៃថាមានម្ចាស់ពពកពីរផ្សេងគ្នាដែលបានលាក់សេវាកម្មរបស់ពួកគេនៅពីក្រោយសមតុល្យ។ ពួកវានីមួយៗមានធនធាននៅក្នុងបណ្តាញរង 10.0.0.1/24 ដែលមានអាសយដ្ឋានដូចគ្នា។ អ្នកត្រូវចេះបែងចែកពួកវាខ្លះ ហើយនៅទីនេះអ្នកត្រូវចូលទៅក្នុងរចនាសម្ព័ន្ធនៃបណ្តាញនិម្មិត Yandex.Cloud ។ វាជាការល្អប្រសើរជាងមុនដើម្បីស្វែងរកព័ត៌មានលម្អិតបន្ថែមនៅក្នុង វីដេអូអំពី៖ ព្រឹត្តិការណ៍ពពកវាមានសារៈសំខាន់សម្រាប់យើងឥឡូវនេះ ដែលបណ្តាញនេះមានច្រើនស្រទាប់ និងមានផ្លូវរូងក្រោមដីដែលអាចត្រូវបានសម្គាល់ដោយ subnet id ។

ថ្នាំងពិនិត្យសុខភាពទាក់ទងអ្នកតុល្យភាពដោយប្រើអាសយដ្ឋាន quasi-IPv6 ដែលគេហៅថា។ អាសយដ្ឋាន quasi-address គឺជាអាសយដ្ឋាន IPv6 ដែលមានអាសយដ្ឋាន IPv4 និងលេខសម្គាល់បណ្តាញរងអ្នកប្រើប្រាស់ដែលបានបង្កប់នៅខាងក្នុងវា។ ចរាចរឈានដល់តុល្យភាព ដែលទាញយកអាសយដ្ឋានធនធាន IPv4 ពីវា ជំនួស IPv6 ជាមួយ IPv4 ហើយផ្ញើកញ្ចប់ព័ត៌មានទៅបណ្តាញរបស់អ្នកប្រើ។

ចរាចរណ៍បញ្ច្រាសដំណើរការដូចគ្នា៖ អ្នកតុល្យភាពមើលឃើញថាទិសដៅគឺជាបណ្តាញពណ៌ប្រផេះពីអ្នកពិនិត្យសុខភាព ហើយបំប្លែង IPv4 ទៅ IPv6 ។

VPP - បេះដូងនៃយន្តហោះទិន្នន័យ

ឧបករណ៍តុល្យភាពត្រូវបានអនុវត្តដោយប្រើបច្ចេកវិទ្យា Vector Packet Processing (VPP) ដែលជាក្របខ័ណ្ឌពី Cisco សម្រាប់ដំណើរការបណ្តុំនៃចរាចរបណ្តាញ។ ក្នុងករណីរបស់យើង ក្របខ័ណ្ឌដំណើរការនៅលើកំពូលនៃបណ្ណាល័យគ្រប់គ្រងឧបករណ៍បណ្តាញអ្នកប្រើប្រាស់ចន្លោះ - Data Plane Development Kit (DPDK) ។ វាធានានូវដំណើរការដំណើរការកញ្ចប់ព័ត៌មានខ្ពស់៖ ការរំខានតិចជាងច្រើនកើតឡើងនៅក្នុងខឺណែល ហើយមិនមានការផ្លាស់ប្តូរបរិបទរវាងទំហំខឺណែល និងទំហំអ្នកប្រើប្រាស់ទេ។ 

VPP កាន់តែដំណើរការទៅទៀត ហើយច្របាច់ចេញនូវដំណើរការកាន់តែច្រើនចេញពីប្រព័ន្ធ ដោយរួមបញ្ចូលកញ្ចប់ជាបាច់។ ការកើនឡើងនៃដំណើរការបានមកពីការប្រើប្រាស់ឃ្លាំងសម្ងាត់យ៉ាងចាស់ដៃនៅលើប្រព័ន្ធដំណើរការទំនើប។ ឃ្លាំងសម្ងាត់ទិន្នន័យទាំងពីរត្រូវបានប្រើ (កញ្ចប់ព័ត៌មានត្រូវបានដំណើរការនៅក្នុង "វ៉ិចទ័រ" ទិន្នន័យគឺនៅជិតគ្នា) និងឃ្លាំងសម្ងាត់ការណែនាំ៖ នៅក្នុង VPP ដំណើរការកញ្ចប់ព័ត៌មានធ្វើតាមក្រាហ្វមួយ ថ្នាំងដែលមានមុខងារដែលបំពេញភារកិច្ចដូចគ្នា។

ឧទាហរណ៍ ដំណើរការនៃកញ្ចប់ព័ត៌មាន IP នៅក្នុង VPP កើតឡើងតាមលំដាប់ដូចខាងក្រោម៖ ដំបូង បឋមកថានៃកញ្ចប់ព័ត៌មានត្រូវបានញែកក្នុងថ្នាំងញែក ហើយបន្ទាប់មកពួកវាត្រូវបានបញ្ជូនទៅថ្នាំង ដែលបញ្ជូនកញ្ចប់បន្តទៅទៀតតាមតារាងនាំផ្លូវ។

ពិបាកចិត្តបន្តិច។ អ្នកនិពន្ធនៃ VPP មិនអត់ធ្មត់នឹងការសម្របសម្រួលក្នុងការប្រើប្រាស់ឃ្លាំងសម្ងាត់ដំណើរការទេ ដូច្នេះកូដធម្មតាសម្រាប់ដំណើរការវ៉ិចទ័រនៃកញ្ចប់ព័ត៌មានមានវ៉ិចទ័រដោយដៃ៖ មានរង្វិលជុំដំណើរការដែលស្ថានភាពដូចជា "យើងមានកញ្ចប់ព័ត៌មានចំនួនបួននៅក្នុងជួរ" ត្រូវបានដំណើរការ។ បន្ទាប់មកដូចគ្នាសម្រាប់ពីរបន្ទាប់មក - សម្រាប់មួយ។ ការណែនាំជាមុនត្រូវបានប្រើជាញឹកញាប់ដើម្បីផ្ទុកទិន្នន័យទៅក្នុងឃ្លាំងសម្ងាត់ ដើម្បីបង្កើនល្បឿនការចូលប្រើពួកវានៅក្នុងការបន្តបន្ទាប់ទៀត។

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ដូច្នេះ Healthchecks និយាយលើ IPv6 ទៅ VPP ដែលប្រែពួកវាទៅជា IPv4 ។ នេះត្រូវបានធ្វើដោយថ្នាំងនៅក្នុងក្រាហ្វដែលយើងហៅថា algorithmic NAT ។ សម្រាប់ចរាចរបញ្ច្រាស (និងការបម្លែងពី IPv6 ទៅ IPv4) មានថ្នាំង NAT ក្បួនដោះស្រាយដូចគ្នា។

ចរាចរដោយផ្ទាល់ពីអតិថិជនតុល្យភាពឆ្លងកាត់ថ្នាំងក្រាហ្វ ដែលធ្វើសមតុល្យដោយខ្លួនឯង។ 

ថ្នាំងទីមួយគឺវគ្គស្អិត។ វារក្សាទុក hash នៃ 5- tuple សម្រាប់វគ្គដែលបានបង្កើតឡើង។ 5-tuple រួមបញ្ចូលអាសយដ្ឋាន និងច្រករបស់អតិថិជនដែលព័ត៌មានត្រូវបានបញ្ជូន អាសយដ្ឋាន និងច្រកនៃធនធានដែលមានសម្រាប់ការទទួលចរាចរណ៍ ក៏ដូចជាពិធីការបណ្តាញ។ 

សញ្ញា 5-tuple ជួយយើងធ្វើការគណនាតិចនៅក្នុងថ្នាំង hashing ជាប់លាប់ជាបន្តបន្ទាប់ ក៏ដូចជាការផ្លាស់ប្តូរបញ្ជីធនធានដែលប្រសើរជាងមុននៅពីក្រោយ balancer ។ នៅពេលដែលកញ្ចប់ព័ត៌មានដែលមិនមានសម័យមកដល់ Balancer វាត្រូវបានបញ្ជូនទៅថ្នាំង hashing ជាប់លាប់។ នេះគឺជាកន្លែងដែលសមតុល្យកើតឡើងដោយប្រើការបំបែកជាប់គ្នា៖ យើងជ្រើសរើសធនធានពីបញ្ជីធនធាន "បន្តផ្ទាល់" ដែលមាន។ បន្ទាប់មក កញ្ចប់ព័ត៌មានត្រូវបានផ្ញើទៅកាន់ថ្នាំង NAT ដែលពិតជាជំនួសអាសយដ្ឋានគោលដៅ និងគណនាឡើងវិញនូវ checksums ។ ដូចដែលអ្នកអាចឃើញយើងអនុវត្តតាមច្បាប់របស់ VPP - ចូលចិត្ត ការដាក់ជាក្រុមនៃការគណនាស្រដៀងគ្នាដើម្បីបង្កើនប្រសិទ្ធភាពនៃឃ្លាំងសម្ងាត់ខួរក្បាល។

ការហាមប្រាមជាប់លាប់

ហេតុអ្វីបានជាយើងជ្រើសរើសវា ហើយតើវាជាអ្វី? ដំបូងយើងពិចារណាកិច្ចការមុន - ជ្រើសរើសធនធានពីបញ្ជី។ 

ជាមួយនឹងការ hashing ដែលមិនស្របគ្នា hash នៃកញ្ចប់ព័ត៌មានចូលត្រូវបានគណនា ហើយធនធានមួយត្រូវបានជ្រើសរើសពីបញ្ជីដោយនៅសល់នៃការបែងចែក hash នេះដោយចំនួនធនធាន។ ដរាបណាបញ្ជីនៅតែមិនផ្លាស់ប្តូរ គ្រោងការណ៍នេះដំណើរការល្អ៖ យើងតែងតែផ្ញើកញ្ចប់ព័ត៌មានដែលមាន 5-tuple ដូចគ្នាទៅកាន់ឧទាហរណ៍ដូចគ្នា។ ឧទាហរណ៍ ប្រសិនបើធនធានមួយចំនួនបានឈប់ឆ្លើយតបទៅនឹងការពិនិត្យសុខភាព នោះជម្រើសនឹងផ្លាស់ប្តូរសម្រាប់ផ្នែកសំខាន់នៃសញ្ញាសម្គាល់។ ការភ្ជាប់ TCP របស់អតិថិជននឹងត្រូវខូច៖ កញ្ចប់ព័ត៌មានដែលបានទៅដល់ឧទាហរណ៍ A ពីមុនអាចចាប់ផ្តើមឈានដល់ instance B ដែលមិនស្គាល់វគ្គសម្រាប់កញ្ចប់ព័ត៌មាននេះ។

ការ hashing ជាប់លាប់ដោះស្រាយបញ្ហាដែលបានពិពណ៌នា។ មធ្យោបាយងាយស្រួលបំផុតដើម្បីពន្យល់ពីគោលគំនិតនេះគឺ៖ ស្រមៃថាអ្នកមានចិញ្ចៀនដែលអ្នកចែកចាយធនធានដោយសញ្ញា (ឧទាហរណ៍តាម IP: ច្រក)។ ការជ្រើសរើសធនធានគឺបង្វិលកង់ដោយមុំមួយ ដែលត្រូវបានកំណត់ដោយសញ្ញានៃកញ្ចប់ព័ត៌មាន។

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

យើងបានក្រឡេកមើលអ្វីដែលកើតឡើងចំពោះចរាចរណ៍ដោយផ្ទាល់រវាងតុល្យភាព និងធនធាន។ ឥឡូវនេះសូមក្រឡេកមើលចរាចរណ៍ត្រឡប់មកវិញ។ វាធ្វើតាមលំនាំដូចគ្នាទៅនឹងការត្រួតពិនិត្យចរាចរណ៍ - តាមរយៈក្បួនដោះស្រាយ NAT ពោលគឺតាមរយៈ NAT 44 បញ្ច្រាសសម្រាប់ចរាចរណ៍អតិថិជន និងតាមរយៈ NAT 46 សម្រាប់ចរាចរណ៍ពិនិត្យសុខភាព។ យើងប្រកាន់ខ្ជាប់នូវគ្រោងការណ៍ផ្ទាល់ខ្លួនរបស់យើង៖ យើងបង្រួបបង្រួមការត្រួតពិនិត្យសុខភាព និងចរាចរណ៍អ្នកប្រើប្រាស់ពិតប្រាកដ។

Loadbalancer-node និងសមាសធាតុផ្សំ

សមាសភាពនៃសមតុល្យ និងធនធាននៅក្នុង VPP ត្រូវបានរាយការណ៍ដោយសេវាកម្មក្នុងស្រុក - loadbalancer-node ។ វាជាវចរន្តនៃព្រឹត្តិការណ៍ពី loadbalancer-controller ហើយអាចកំណត់ភាពខុសគ្នារវាងស្ថានភាព VPP បច្ចុប្បន្ន និងស្ថានភាពគោលដៅដែលទទួលបានពីឧបករណ៍បញ្ជា។ យើងទទួលបានប្រព័ន្ធបិទ៖ ព្រឹត្តិការណ៍ពី API មកដល់ឧបករណ៍បញ្ជាតុល្យភាព ដែលផ្តល់ភារកិច្ចទៅឱ្យឧបករណ៍ត្រួតពិនិត្យសុខភាព ដើម្បីពិនិត្យមើល "ភាពរស់រវើក" នៃធនធាន។ នោះហើយជាវេន ប្រគល់ភារកិច្ចទៅថ្នាំងពិនិត្យសុខភាព និងបូកសរុបលទ្ធផល បន្ទាប់មកវាបញ្ជូនពួកគេត្រឡប់ទៅឧបករណ៍បញ្ជាតុល្យភាពវិញ។ Loadbalancer-node ជាវព្រឹត្តិការណ៍ពីឧបករណ៍បញ្ជា និងផ្លាស់ប្តូរស្ថានភាពនៃ VPP ។ នៅក្នុងប្រព័ន្ធបែបនេះ សេវានីមួយៗដឹងតែអ្វីដែលចាំបាច់អំពីសេវាជិតខាងប៉ុណ្ណោះ។ ចំនួននៃការតភ្ជាប់មានកំណត់ ហើយយើងមានសមត្ថភាពក្នុងការដំណើរការ និងធ្វើមាត្រដ្ឋានផ្នែកផ្សេងៗដោយឯករាជ្យ។

តើបញ្ហាអ្វីខ្លះត្រូវបានជៀសវាង?

សេវាកម្មទាំងអស់របស់យើងនៅក្នុងយន្តហោះបញ្ជាត្រូវបានសរសេរជា Go ហើយមានលក្ខណៈមាត្រដ្ឋានល្អ និងភាពជឿជាក់។ Go មានបណ្ណាល័យប្រភពបើកចំហជាច្រើនសម្រាប់បង្កើតប្រព័ន្ធចែកចាយ។ យើងប្រើប្រាស់ GRPC យ៉ាងសកម្ម សមាសធាតុទាំងអស់មានប្រភពបើកចំហនៃការអនុវត្តការរកឃើញសេវាកម្ម - សេវាកម្មរបស់យើងត្រួតពិនិត្យដំណើរការរបស់គ្នាទៅវិញទៅមក អាចផ្លាស់ប្តូរសមាសភាពរបស់វាយ៉ាងស្វាហាប់ ហើយយើងបានភ្ជាប់វាជាមួយសមតុល្យ GRPC ។ សម្រាប់ម៉ែត្រ យើងក៏ប្រើដំណោះស្រាយប្រភពបើកចំហផងដែរ។ នៅក្នុងយន្តហោះទិន្នន័យ យើងទទួលបានការអនុវត្តសមរម្យ និងទុនបម្រុងធនធានដ៏ច្រើន៖ វាប្រែទៅជាពិបាកខ្លាំងណាស់ក្នុងការប្រមូលផ្តុំជំហរដែលយើងអាចពឹងផ្អែកលើដំណើរការរបស់ VPP ជាជាងកាតបណ្តាញដែក។

បញ្ហា និងដំណោះស្រាយ

តើ​អ្វី​ដែល​មិន​បាន​ដំណើរការ​ល្អ​ដូច្នេះ? Go មានការគ្រប់គ្រងអង្គចងចាំដោយស្វ័យប្រវត្តិ ប៉ុន្តែការលេចធ្លាយអង្គចងចាំនៅតែកើតឡើង។ មធ្យោបាយងាយស្រួលបំផុតដើម្បីដោះស្រាយជាមួយពួកគេគឺត្រូវដំណើរការ goroutines ហើយចងចាំដើម្បីបញ្ចប់ពួកគេ។ Takeaway៖ មើលការប្រើប្រាស់អង្គចងចាំរបស់កម្មវិធី Go របស់អ្នក។ ជាញឹកញាប់សូចនាករដ៏ល្អមួយគឺចំនួននៃ goroutines ។ មានការបូកនៅក្នុងរឿងនេះ៖ នៅក្នុង Go វាងាយស្រួលក្នុងការទទួលបានទិន្នន័យពេលដំណើរការ - ការប្រើប្រាស់អង្គចងចាំ ចំនួននៃការដំណើរការ goroutines និងប៉ារ៉ាម៉ែត្រជាច្រើនទៀត។

ដូចគ្នានេះផងដែរ Go ប្រហែលជាមិនមែនជាជម្រើសដ៏ល្អបំផុតសម្រាប់ការធ្វើតេស្តមុខងារនោះទេ។ ពួកគេមានពាក្យសំដីហើយវិធីសាស្រ្តស្តង់ដារនៃ "ដំណើរការអ្វីគ្រប់យ៉ាងនៅក្នុង CI ជាបាច់" គឺមិនសមរម្យសម្រាប់ពួកគេទេ។ ការពិតគឺថាការធ្វើតេស្តមុខងារគឺមានតម្រូវការធនធានច្រើនជាង ហើយបណ្តាលឱ្យអស់ពេលពិតប្រាកដ។ ដោយសារតែនេះ ការធ្វើតេស្តអាចនឹងបរាជ័យ ដោយសារតែ CPU រវល់ជាមួយការធ្វើតេស្តឯកតា។ សេចក្តីសន្និដ្ឋាន៖ ប្រសិនបើអាចធ្វើបាន សូមអនុវត្តការធ្វើតេស្ត "ធ្ងន់" ដាច់ដោយឡែកពីការធ្វើតេស្តឯកតា។ 

ស្ថាបត្យកម្មព្រឹត្តិការណ៍ Microservice គឺស្មុគ្រស្មាញជាង monolith មួយ៖ ការប្រមូលកំណត់ហេតុនៅលើម៉ាស៊ីនផ្សេងៗគ្នារាប់សិបគឺមិនងាយស្រួលនោះទេ។ សេចក្តីសន្និដ្ឋាន៖ ប្រសិនបើអ្នកបង្កើតសេវាកម្មមីក្រូ សូមគិតភ្លាមៗអំពីការតាមដាន។

ផែនការរបស់យើង។

យើងនឹងបើកដំណើរការឧបករណ៍តុល្យភាពខាងក្នុង តុល្យភាព IPv6 បន្ថែមការគាំទ្រសម្រាប់ស្គ្រីប Kubernetes បន្តធ្វើឱ្យខូចសេវាកម្មរបស់យើង (បច្ចុប្បន្នមានតែការពិនិត្យសុខភាព និងការពិនិត្យសុខភាព-ctrl ប៉ុណ្ណោះដែលត្រូវបានបំបែក) បន្ថែមការពិនិត្យសុខភាពថ្មី និងអនុវត្តការរួមបញ្ចូលការត្រួតពិនិត្យយ៉ាងឆ្លាតវៃផងដែរ។ យើងកំពុងពិចារណាពីលទ្ធភាពនៃការធ្វើឱ្យសេវាកម្មរបស់យើងកាន់តែមានភាពឯករាជ្យ ដូច្នេះពួកគេទំនាក់ទំនងមិនដោយផ្ទាល់ជាមួយគ្នាទៅវិញទៅមក ប៉ុន្តែដោយប្រើជួរសារ។ សេវាកម្មដែលត្រូវគ្នានឹង SQS បានបង្ហាញខ្លួននៅក្នុង Cloud នាពេលថ្មីៗនេះ ជួរសារ Yandex.

ថ្មីៗនេះការចេញផ្សាយជាសាធារណៈនៃ Yandex Load Balancer បានកើតឡើង។ រុករក ឯកសារ ទៅកាន់សេវាកម្ម គ្រប់គ្រងតុល្យភាពក្នុងវិធីមួយដែលងាយស្រួលសម្រាប់អ្នក និងបង្កើនការអត់ឱនចំពោះកំហុសនៃគម្រោងរបស់អ្នក!

ប្រភព: www.habr.com