នៅពេលដែល Linux conntrack លែងជាមិត្តរបស់អ្នកទៀតហើយ

ការតាមដានការតភ្ជាប់ (“conntrack”) គឺជាមុខងារស្នូលនៃបណ្តាញខឺណែលលីនុច។ វាអនុញ្ញាតឱ្យខឺណែលតាមដានរាល់ការភ្ជាប់បណ្តាញ ឬលំហូរឡូជីខល ហើយដោយហេតុនេះកំណត់អត្តសញ្ញាណកញ្ចប់ព័ត៌មានទាំងអស់ដែលបង្កើតជាលំហូរនីមួយៗ ដូច្នេះពួកគេអាចដំណើរការជាមួយគ្នាតាមលំដាប់លំដោយ។

Conntrack គឺជាលក្ខណៈពិសេសខឺណែលដ៏សំខាន់ដែលត្រូវបានប្រើនៅក្នុងករណីមូលដ្ឋានមួយចំនួន៖

• NAT ពឹងផ្អែកលើព័ត៌មានពី conntrack ដូច្នេះវាអាចព្យាបាលកញ្ចប់ព័ត៌មានទាំងអស់ពីស្ទ្រីមដូចគ្នាដោយស្មើភាពគ្នា។ ជាឧទាហរណ៍ នៅពេលដែលផតចូលប្រើសេវាកម្ម Kubernetes ឧបករណ៍ផ្ទុកបន្ទុកប្រូកស៊ី kube ប្រើ NAT ដើម្បីដឹកនាំចរាចរណ៍ទៅកាន់ផតជាក់លាក់មួយនៅក្នុងចង្កោម។ Conntrack កត់ត្រាថាសម្រាប់ការតភ្ជាប់ដែលបានផ្តល់ឱ្យ កញ្ចប់ព័ត៌មានទាំងអស់ទៅកាន់សេវា IP ត្រូវតែត្រូវបានផ្ញើទៅកាន់ផតដូចគ្នា ហើយកញ្ចប់នោះដែលត្រឡប់ដោយផតផតផ្នែកខាងក្រោយត្រូវតែ NATed ត្រឡប់ទៅផតដែលសំណើបានមក។
• ជញ្ជាំងភ្លើងដែលមានស្ថានភាពដូចជា Calico ពឹងផ្អែកលើព័ត៌មានពីបណ្តាញភ្ជាប់ទៅកាន់ចរាចរណ៍ "ឆ្លើយតប" បញ្ជីស។ នេះអនុញ្ញាតឱ្យអ្នកសរសេរគោលការណ៍បណ្តាញដែលនិយាយថា "អនុញ្ញាតឱ្យ pod របស់ខ្ញុំភ្ជាប់ទៅអាសយដ្ឋាន IP ពីចម្ងាយណាមួយ" ដោយមិនចាំបាច់សរសេរគោលការណ៍ដើម្បីអនុញ្ញាតឱ្យចរាចរណ៍ឆ្លើយតបយ៉ាងច្បាស់។ (បើគ្មានវាទេ អ្នកនឹងត្រូវបន្ថែម "អនុញ្ញាតឱ្យកញ្ចប់ព័ត៌មានទៅផតរបស់ខ្ញុំពីច្បាប់ IP ណាមួយ" ដែលមិនសូវមានសុវត្ថិភាព។ )

លើសពីនេះ conntrack ជាធម្មតាធ្វើអោយប្រសើរឡើងនូវដំណើរការប្រព័ន្ធ (ដោយកាត់បន្ថយការប្រើប្រាស់ CPU និង packet latency) ចាប់តាំងពីមានតែកញ្ចប់ដំបូងនៅក្នុងស្ទ្រីមប៉ុណ្ណោះ។
ត្រូវតែឆ្លងកាត់ជង់បណ្តាញទាំងមូលដើម្បីកំណត់ពីអ្វីដែលត្រូវធ្វើជាមួយវា។ សូមមើលប្រកាស "ការប្រៀបធៀបនៃរបៀប kube-ប្រូកស៊ី" ដើម្បីមើលឧទាហរណ៍នៃរបៀបដែលវាដំណើរការ។

ទោះជាយ៉ាងណាក៏ដោយ Conntrack មានដែនកំណត់របស់វា ...

ដូច្នេះតើវាខុសត្រង់ណា?

តារាង conntrack មានទំហំអតិបរមាដែលអាចកំណត់រចនាសម្ព័ន្ធបាន ហើយប្រសិនបើវាពេញ ការតភ្ជាប់ជាធម្មតាចាប់ផ្តើមត្រូវបានបដិសេធ ឬទម្លាក់។ មានទំហំទំនេរគ្រប់គ្រាន់ក្នុងតារាងដើម្បីគ្រប់គ្រងចរាចរណ៍នៃកម្មវិធីភាគច្រើន ហើយវានឹងមិនក្លាយជាបញ្ហាទេ។ ទោះយ៉ាងណាក៏ដោយ មានសេណារីយ៉ូមួយចំនួនដែលអ្នកប្រហែលជាចង់ពិចារណាប្រើតារាង conntrack៖

• ករណីជាក់ស្តែងបំផុតគឺប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកគ្រប់គ្រងចំនួនដ៏ច្រើននៃការតភ្ជាប់សកម្មក្នុងពេលដំណាលគ្នា។ ឧទាហរណ៍ ប្រសិនបើតារាង conntrack របស់អ្នកត្រូវបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ធាតុ 128k ប៉ុន្តែអ្នកមានការតភ្ជាប់ស្របគ្នា > 128k អ្នកប្រាកដជានឹងមានបញ្ហា!
• ករណីមិនសូវច្បាស់៖ ប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកដំណើរការចំនួននៃការតភ្ជាប់ច្រើនណាស់ក្នុងមួយវិនាទី។ ទោះបីជាការតភ្ជាប់មានរយៈពេលខ្លីក៏ដោយ ក៏ពួកគេបន្តត្រូវបានត្រួតពិនិត្យដោយលីនុចសម្រាប់រយៈពេលមួយចំនួន (120s តាមលំនាំដើម)។ ឧទាហរណ៍ ប្រសិនបើតារាង conntrack របស់អ្នកត្រូវបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ធាតុ 128k ហើយអ្នកកំពុងព្យាយាមគ្រប់គ្រងការតភ្ជាប់ 1100 ក្នុងមួយវិនាទី ពួកគេនឹងលើសពីទំហំនៃតារាង conntrack ទោះបីជាការតភ្ជាប់មានរយៈពេលខ្លីណាស់ (128k/120s = 1092 connections/ s)

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

ឧទាហរណ៍ជាក់ស្តែង

សូមផ្តល់ឧទាហរណ៍ជាក់លាក់មួយ៖ អ្នកផ្តល់សេវា SaaS ដ៏ធំមួយដែលយើងធ្វើការជាមួយមានម៉ាស៊ីនមេ memcached ជាច្រើននៅលើម៉ាស៊ីន (មិនមែនម៉ាស៊ីននិម្មិត) ដែលនីមួយៗដំណើរការការតភ្ជាប់រយៈពេលខ្លី 50K+ ក្នុងមួយវិនាទី។

ពួកគេបានពិសោធជាមួយការកំណត់រចនាសម្ព័ន្ធ conntrack បង្កើនទំហំតារាង និងកាត់បន្ថយពេលវេលាតាមដាន ប៉ុន្តែការកំណត់រចនាសម្ព័ន្ធគឺមិនអាចទុកចិត្តបាន ការប្រើប្រាស់ RAM កើនឡើងយ៉ាងខ្លាំង ដែលជាបញ្ហា (តាមលំដាប់នៃ GBytes!) ហើយការតភ្ជាប់គឺខ្លីណាស់ដែល conntrack មិនបាន បង្កើតអត្ថប្រយោជន៍ដំណើរការធម្មតារបស់វា (កាត់បន្ថយការប្រើប្រាស់ស៊ីភីយូ ឬភាពយឺតនៃកញ្ចប់ព័ត៌មាន)។

ពួកគេបានងាកទៅ Calico ជាជម្រើសមួយ។ គោលការណ៍បណ្តាញ Calico អនុញ្ញាតឱ្យអ្នកមិនប្រើ conntrack សម្រាប់ប្រភេទមួយចំនួននៃចរាចរណ៍ (ដោយប្រើជម្រើសគោលការណ៍ doNotTrack) ។ នេះផ្តល់ឱ្យពួកគេនូវកម្រិតនៃការអនុវត្តដែលពួកគេត្រូវការ បូកនឹងកម្រិតសុវត្ថិភាពបន្ថែមដែលផ្តល់ដោយ Calico ។

តើ​អ្នក​នឹង​ត្រូវ​ទៅ​ដល់​ផ្លូវ​ឆ្លង​កាត់​រយៈ​ពេល​ប៉ុន្មាន?

• គោលការណ៍បណ្តាញ Do-not-track ជាទូទៅគួរតែស៊ីមេទ្រី។ ក្នុងករណីអ្នកផ្តល់សេវា SaaS៖ កម្មវិធីរបស់ពួកគេដំណើរការនៅក្នុងតំបន់ការពារ ដូច្នេះហើយ ដោយប្រើគោលការណ៍បណ្តាញ ពួកគេអាចដាក់បញ្ជីសចរាចរណ៍ពីកម្មវិធីជាក់លាក់ផ្សេងទៀតដែលត្រូវបានអនុញ្ញាតឱ្យចូលប្រើ memcached ។
• គោលការណ៍ do-not-track មិនគិតពីទិសដៅនៃការតភ្ជាប់ទេ។ ដូច្នេះ ប្រសិនបើម៉ាស៊ីនមេ memcached ត្រូវបានលួចចូល អ្នកតាមទ្រឹស្តីអាចព្យាយាមភ្ជាប់ទៅអតិថិជន memcached ណាមួយ ដរាបណាវាប្រើច្រកប្រភពត្រឹមត្រូវ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកបានកំណត់យ៉ាងត្រឹមត្រូវនូវគោលការណ៍បណ្តាញសម្រាប់អតិថិជន memcached របស់អ្នក នោះការព្យាយាមភ្ជាប់ទាំងនេះនឹងនៅតែត្រូវបានច្រានចោលនៅផ្នែកម៉ាស៊ីនភ្ញៀវ។
• គោលការណ៍ do-not-track ត្រូវបានអនុវត្តចំពោះរាល់កញ្ចប់ព័ត៌មាន ដែលផ្ទុយពីគោលការណ៍ធម្មតា ដែលត្រូវបានអនុវត្តតែចំពោះកញ្ចប់ព័ត៌មានដំបូងនៅក្នុងលំហូរមួយ។ នេះអាចបង្កើនការប្រើប្រាស់ស៊ីភីយូក្នុងមួយកញ្ចប់ ព្រោះគោលការណ៍ត្រូវតែអនុវត្តសម្រាប់កញ្ចប់ព័ត៌មាននីមួយៗ។ ប៉ុន្តែសម្រាប់ការតភ្ជាប់រយៈពេលខ្លី ការចំណាយនេះមានតុល្យភាពដោយការកាត់បន្ថយការប្រើប្រាស់ធនធានសម្រាប់ដំណើរការបន្ត។ ឧទាហរណ៍ ក្នុងករណីអ្នកផ្តល់សេវា SaaS ចំនួនកញ្ចប់ព័ត៌មានសម្រាប់ការតភ្ជាប់នីមួយៗគឺតូចណាស់ ដូច្នេះការប្រើប្រាស់ស៊ីភីយូបន្ថែមនៅពេលអនុវត្តគោលការណ៍ចំពោះកញ្ចប់ព័ត៌មាននីមួយៗគឺត្រឹមត្រូវ។

តោះចាប់ផ្តើមសាកល្បង

យើងបានដំណើរការការសាកល្បងនៅលើផតតែមួយជាមួយម៉ាស៊ីនមេ memcached និង pods ម៉ាស៊ីនភ្ញៀវ memcached ជាច្រើនដែលកំពុងដំណើរការនៅលើថ្នាំងពីចម្ងាយ ដូច្នេះយើងអាចដំណើរការការតភ្ជាប់ជាច្រើនក្នុងមួយវិនាទី។ ម៉ាស៊ីនមេដែលមានផតមេកាដែលផ្ទុកទិន្នន័យមាន 8 ស្នូល និងធាតុ 512k នៅក្នុងតារាង conntrack (ទំហំតារាងដែលបានកំណត់រចនាសម្ព័ន្ធស្តង់ដារសម្រាប់ម៉ាស៊ីន)។
យើងបានវាស់ភាពខុសគ្នានៃការអនុវត្តរវាង៖ គ្មានគោលការណ៍បណ្តាញ។ ជាមួយនឹងគោលការណ៍ Calico ទៀងទាត់; និងគោលការណ៍មិនតាមដាន Calico ។

សម្រាប់ការធ្វើតេស្តលើកទីមួយ យើងកំណត់ចំនួននៃការតភ្ជាប់ទៅ 4.000 ក្នុងមួយវិនាទី ដូច្នេះយើងអាចផ្តោតលើភាពខុសគ្នានៃការប្រើប្រាស់ស៊ីភីយូ។ មិនមានភាពខុសគ្នាខ្លាំងរវាងគោលនយោបាយ និងគោលការណ៍ធម្មតាទេ ប៉ុន្តែកុំតាមដានការកើនឡើងនៃការប្រើប្រាស់ស៊ីភីយូប្រហែល 20%៖

នៅក្នុងការធ្វើតេស្តលើកទីពីរ យើងបានបើកដំណើរការការតភ្ជាប់ជាច្រើនតាមដែលអតិថិជនរបស់យើងអាចបង្កើត និងវាស់ចំនួនអតិបរមានៃការតភ្ជាប់ក្នុងមួយវិនាទី ដែលម៉ាស៊ីនមេ memcached របស់យើងអាចគ្រប់គ្រងបាន។ ដូចដែលបានរំពឹងទុក ករណី "គ្មានគោលការណ៍" និង "គោលការណ៍ធម្មតា" ទាំងពីរបានឈានដល់ដែនកំណត់នៃការតភ្ជាប់លើសពី 4,000 ក្នុងមួយវិនាទី (512k/120s = 4,369 connections/s)។ ជាមួយនឹងគោលការណ៍មិនតាមដាន អតិថិជនរបស់យើងបានផ្ញើការតភ្ជាប់ 60,000 ក្នុងមួយវិនាទីដោយមិនមានបញ្ហាអ្វីឡើយ។ យើងប្រាកដថាយើងអាចបង្កើនចំនួននេះដោយបន្ថែមអតិថិជនបន្ថែមទៀត ប៉ុន្តែយើងមានអារម្មណ៍ថាចំនួនទាំងនេះគឺគ្រប់គ្រាន់ហើយដើម្បីបង្ហាញពីចំណុចនៃអត្ថបទនេះ!

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

Conntrack គឺជាមុខងារខឺណែលដ៏សំខាន់មួយ។ គាត់ធ្វើការងាររបស់គាត់យ៉ាងល្អឥតខ្ចោះ។ វាត្រូវបានគេប្រើជាញឹកញាប់ដោយសមាសធាតុប្រព័ន្ធសំខាន់ៗ។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងសេណារីយ៉ូជាក់លាក់មួយចំនួន ការកកស្ទះដោយសារតែ conntrack មានលើសពីអត្ថប្រយោជន៍ធម្មតាដែលវាផ្តល់។ នៅក្នុងសេណារីយ៉ូនេះ គោលការណ៍បណ្តាញ Calico អាចត្រូវបានប្រើដើម្បីជ្រើសរើសបិទការប្រើប្រាស់ conntrack ខណៈពេលដែលបង្កើនសុវត្ថិភាពបណ្តាញ។ សម្រាប់ចរាចរណ៍ផ្សេងទៀតទាំងអស់ conntrack បន្តធ្វើជាមិត្តរបស់អ្នក!

សូមអានអត្ថបទផ្សេងទៀតនៅលើប្លក់របស់យើងផងដែរ៖

• ការកសាងម៉ូឌុលថាមវន្តសម្រាប់ Nginx
• ការណែនាំអំពីការអនុញ្ញាត Kubernetes របស់កុងស៊ុល Hashicorp
• ការបម្រុងទុកដែលមានស្ថានភាពនៅក្នុង Kubernetes
• ការ​បម្រុង​ទុក​នៃ​គម្រោង​បណ្ដាញ​ខុស​គ្នា​មួយ​ចំនួន​ធំ
• Telegram bot សម្រាប់ Redmine ។ វិធីធ្វើឱ្យជីវិតសាមញ្ញសម្រាប់ខ្លួនអ្នក និងអ្នកដទៃ

ប្រភព: www.habr.com