បណ្តាញដែលព្យាបាលខ្លួនឯង៖ វេទមន្តនៃ Flow Label និងអ្នកស៊ើបអង្កេតជុំវិញខឺណែលលីនុច។ របាយការណ៍ Yandex

មជ្ឈមណ្ឌលទិន្នន័យទំនើបមានឧបករណ៍សកម្មរាប់រយដែលត្រូវបានដំឡើង គ្របដណ្តប់ដោយប្រភេទផ្សេងគ្នានៃការត្រួតពិនិត្យ។ ប៉ុន្តែសូម្បីតែវិស្វករដ៏ល្អម្នាក់ដែលមានការត្រួតពិនិត្យល្អឥតខ្ចោះនៅក្នុងដៃនឹងអាចឆ្លើយតបបានត្រឹមត្រូវចំពោះការបរាជ័យបណ្តាញក្នុងរយៈពេលតែប៉ុន្មាននាទីប៉ុណ្ណោះ។ នៅក្នុងរបាយការណ៍មួយនៅឯសន្និសីទ Next Hop 2020 ខ្ញុំបានបង្ហាញពីវិធីសាស្រ្តរចនាបណ្តាញមជ្ឈមណ្ឌលទិន្នន័យ ដែលមានលក្ខណៈពិសេសប្លែកពីគេ - មជ្ឈមណ្ឌលទិន្នន័យព្យាបាលខ្លួនឯងជាមិល្លីវិនាទី។ កាន់តែច្បាស់ជាងនេះទៅទៀត វិស្វករដោះស្រាយបញ្ហាដោយស្ងប់ស្ងាត់ ខណៈពេលដែលសេវាកម្មមិនកត់សំគាល់វា។

- ដើម្បីចាប់ផ្តើមជាមួយ ខ្ញុំនឹងផ្តល់ការណែនាំលម្អិតដោយយុត្តិធម៌សម្រាប់អ្នកដែលប្រហែលជាមិនដឹងអំពីរចនាសម្ព័ន្ធនៃ DC ទំនើប។


សម្រាប់វិស្វករបណ្តាញជាច្រើន បណ្តាញមជ្ឈមណ្ឌលទិន្នន័យចាប់ផ្តើម ពិតណាស់ជាមួយ ToR ជាមួយនឹងកុងតាក់នៅក្នុង rack ។ ToR ជាធម្មតាមានតំណភ្ជាប់ពីរប្រភេទ។ តូចទៅម៉ាស៊ីនមេ អ្នកផ្សេងទៀត - មាន N ដងច្រើនជាងពួកគេ - ឆ្ពោះទៅរកឆ្អឹងខ្នងនៃកម្រិតទីមួយ ពោលគឺទៅកាន់តំណភ្ជាប់របស់វា។ Uplinks ជាធម្មតាត្រូវបានចាត់ទុកថាស្មើគ្នា ហើយចរាចររវាង uplinks គឺមានតុល្យភាពដោយផ្អែកលើ hash ពី 5-tuple ដែលរួមមាន proto, src_ip, dst_ip, src_port, dst_port ។ គ្មានការភ្ញាក់ផ្អើលនៅទីនេះទេ។


បន្ទាប់ តើស្ថាបត្យកម្មផែនការមើលទៅដូចអ្វី? ឆ្អឹងខ្នងនៃកម្រិតទី 1 មិនត្រូវបានតភ្ជាប់ទៅគ្នាទៅវិញទៅមកទេ ប៉ុន្តែត្រូវបានតភ្ជាប់តាមរយៈ superspines ។ អក្សរ X នឹងទទួលខុសត្រូវចំពោះ superspines វាស្ទើរតែដូចជាការតភ្ជាប់ឆ្លងកាត់។


ហើយវាច្បាស់ណាស់ថា ម្យ៉ាងវិញទៀត tori ត្រូវបានភ្ជាប់ទៅឆ្អឹងខ្នងទាំងអស់នៃកម្រិតទីមួយ។ តើអ្វីសំខាន់ក្នុងរូបភាពនេះ? ប្រសិនបើយើងមានអន្តរកម្មនៅខាងក្នុង rack នោះអន្តរកម្មពិតណាស់ឆ្លងកាត់ ToR ។ ប្រសិនបើអន្តរកម្មកើតឡើងនៅក្នុងម៉ូឌុល នោះអន្តរកម្មកើតឡើងតាមរយៈឆ្អឹងខ្នងកម្រិតទីមួយ។ ប្រសិនបើអន្តរកម្មគឺ intermodular - ដូចនៅទីនេះ ToR 1 និង ToR 2 - បន្ទាប់មកអន្តរកម្មនឹងឆ្លងកាត់ឆ្អឹងខ្នងទាំងកម្រិតទីមួយនិងទីពីរ។


តាមទ្រឹស្តី ស្ថាបត្យកម្មបែបនេះអាចធ្វើមាត្រដ្ឋានបានយ៉ាងងាយស្រួល។ ប្រសិនបើយើងមានសមត្ថភាពច្រក កន្លែងទំនេរនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ និងហ្វាយបឺដែលបានដាក់មុន នោះចំនួនផ្លូវថ្នល់អាចកើនឡើងជានិច្ច ដោយហេតុនេះបង្កើនសមត្ថភាពនៃប្រព័ន្ធទាំងមូល។ នេះងាយស្រួលធ្វើនៅលើក្រដាស។ វានឹងដូចនេះនៅក្នុងជីវិត។ ប៉ុន្តែ​រឿង​ថ្ងៃ​នេះ​មិន​មែន​អំពី​រឿង​នោះ​ទេ។


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


មានយន្តហោះចំនួនប្រាំបី ដែលយន្តហោះនីមួយៗមាន 32 superpines ។ ជាលទ្ធផល វាប្រែថាមានផ្លូវចំនួនប្រាំបីនៅខាងក្នុងម៉ូឌុល ហើយជាមួយនឹងអន្តរកម្មអន្តរកម្មមាន 256 រួចហើយ។

នោះគឺប្រសិនបើយើងកំពុងបង្កើត Cookbook ដោយព្យាយាមរៀនពីរបៀបបង្កើតមជ្ឈមណ្ឌលទិន្នន័យដែលអត់ឱនចំពោះកំហុសដែលព្យាបាលខ្លួនឯងនោះ ស្ថាបត្យកម្មប្លង់គឺជាជម្រើសដ៏ត្រឹមត្រូវ។ វាដោះស្រាយបញ្ហាការធ្វើមាត្រដ្ឋាន ហើយតាមទ្រឹស្តីវាងាយស្រួល។ មានផ្លូវឯករាជ្យជាច្រើន។ សំណួរនៅតែមាន៖ តើស្ថាបត្យកម្មបែបនេះអាចរួចផុតពីការបរាជ័យដោយរបៀបណា? មានការបរាជ័យផ្សេងៗគ្នា។ ហើយយើងនឹងពិភាក្សារឿងនេះឥឡូវនេះ។


អនុញ្ញាតឱ្យឆ្អឹងខ្នងរបស់យើង "ឈឺ" ។ នៅទីនេះខ្ញុំបានត្រលប់ទៅស្ថាបត្យកម្មយន្តហោះពីរ។ យើង​នឹង​លើក​យក​ចំណុច​ទាំង​នេះ​ជា​ឧទាហរណ៍ ព្រោះ​វា​នឹង​កាន់​តែ​ងាយ​ស្រួល​ក្នុង​ការ​មើល​ឃើញ​ថា​មាន​អ្វី​កើត​ឡើង​ដោយ​មាន​ផ្នែក​ផ្លាស់ទី​តិច​ជាង។ សូមឱ្យ X11 ឈឺ។ តើវានឹងប៉ះពាល់ដល់សេវាកម្មដែលរស់នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យយ៉ាងដូចម្តេច? ច្រើន​អាស្រ័យ​លើ​អ្វី​ដែល​ពិត​ជា​បរាជ័យ​មើល​ទៅ​ដូច​ជា។


ប្រសិនបើការបរាជ័យគឺល្អវាត្រូវបានគេចាប់បាននៅកម្រិតស្វ័យប្រវត្តិកម្មនៃ BFD ដូចគ្នាស្វ័យប្រវត្តិកម្មដាក់សន្លាក់ដែលមានបញ្ហាដោយរីករាយហើយញែកបញ្ហានោះអ្វីៗទាំងអស់គឺល្អ។ យើងមានផ្លូវជាច្រើន ចរាចរណ៍ត្រូវបានបញ្ជូនបន្តទៅផ្លូវជំនួសវិញភ្លាមៗ ហើយសេវាកម្មនឹងមិនកត់សម្គាល់អ្វីនោះទេ។ នេះគឺជាស្គ្រីបដ៏ល្អ។


សេណារីយ៉ូមិនល្អគឺប្រសិនបើយើងមានការខាតបង់ជាបន្តបន្ទាប់ ហើយស្វ័យប្រវត្តិកម្មមិនកត់សំគាល់បញ្ហានោះទេ។ ដើម្បីយល់ពីរបៀបដែលវាប៉ះពាល់ដល់កម្មវិធីមួយ យើងនឹងត្រូវចំណាយពេលបន្តិចដើម្បីពិភាក្សាពីរបៀបដែល TCP ដំណើរការ។


ខ្ញុំសង្ឃឹមថាខ្ញុំមិនធ្វើឱ្យនរណាម្នាក់ភ្ញាក់ផ្អើលជាមួយនឹងព័ត៌មាននេះទេ៖ TCP គឺជាពិធីការបញ្ជាក់ការបញ្ជូន។ នោះ​គឺ​ជា​ករណី​សាមញ្ញ​បំផុត អ្នក​ផ្ញើ​ផ្ញើ​កញ្ចប់​ព័ត៌មាន​ចំនួន​ពីរ ហើយ​ទទួល​បាន​កញ្ចប់​បញ្ជរ​មួយ​លើ​ពួកគេ៖ "ខ្ញុំ​បាន​ទទួល​កញ្ចប់​ព័ត៌មាន​ពីរ"។


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


តើមានអ្វីកើតឡើងប្រសិនបើយើងបាត់បង់កញ្ចប់ទី 3? ក្នុងករណីនេះ អ្នកទទួលនឹងទទួលបានកញ្ចប់ 1, 2 និង 4។ ហើយគាត់នឹងប្រាប់អ្នកផ្ញើយ៉ាងច្បាស់លាស់ដោយប្រើជម្រើស SACK៖ "អ្នកដឹងទេ បីបានមកដល់ ប៉ុន្តែពាក់កណ្តាលបានបាត់បង់" ។ គាត់និយាយថា "Ack 2, SACK 4" ។


នៅពេលនេះ អ្នកផ្ញើដោយគ្មានបញ្ហា ធ្វើម្តងទៀតនូវកញ្ចប់ព័ត៌មានដែលបានបាត់បង់។


ប៉ុន្តែប្រសិនបើកញ្ចប់ចុងក្រោយនៅក្នុងបង្អួចត្រូវបានបាត់បង់នោះស្ថានភាពនឹងមើលទៅខុសគ្នាទាំងស្រុង។

អ្នកទទួលទទួលបានកញ្ចប់បីដំបូង ហើយជាដំបូងនៃការទាំងអស់ចាប់ផ្តើមរង់ចាំ។ សូមអរគុណចំពោះការបង្កើនប្រសិទ្ធភាពមួយចំនួននៅក្នុង TCP stack របស់ Linux ខឺណែល វានឹងរង់ចាំកញ្ចប់ព័ត៌មានដែលបានផ្គូផ្គង លុះត្រាតែទង់ជាតិបង្ហាញយ៉ាងច្បាស់ថាវាជាកញ្ចប់ចុងក្រោយ ឬអ្វីមួយដែលស្រដៀងគ្នា។ វានឹងរង់ចាំរហូតដល់ការពន្យារពេល ACK ផុតកំណត់ ហើយបន្ទាប់មកផ្ញើការទទួលស្គាល់លើកញ្ចប់បីដំបូង។ ប៉ុន្តែឥឡូវនេះអ្នកផ្ញើនឹងរង់ចាំ។ គាត់​មិន​ដឹង​ថា​តើ​កញ្ចប់​ទី​បួន​បាន​បាត់​ឬ​ក៏​ជិត​មក​ដល់។ ហើយដើម្បីកុំឱ្យផ្ទុកលើសបណ្តាញ វានឹងព្យាយាមរង់ចាំការចង្អុលបង្ហាញច្បាស់លាស់ថាកញ្ចប់ព័ត៌មានត្រូវបានបាត់បង់ ឬសម្រាប់ពេលវេលា RTO ផុតកំណត់។


តើអស់ពេល RTO ជាអ្វី? នេះគឺជាចំនួនអតិបរមានៃ RTT ដែលគណនាដោយ TCP stack និងថេរមួយចំនួន។ តើ​ប្រភេទ​នេះ​គឺ​ជា​ថេរ​អ្វី​នោះ ឥឡូវ​យើង​នឹង​ពិភាក្សា។


ប៉ុន្តែអ្វីដែលសំខាន់នោះគឺថាប្រសិនបើយើងសំណាងម្តងទៀតហើយកញ្ចប់ទី 4 ត្រូវបានបាត់បង់ម្តងទៀតនោះ RTO កើនឡើងទ្វេដង។ នោះ​គឺ​ការ​ប៉ុនប៉ង​មិន​បាន​ជោគជ័យ​នីមួយៗ​មាន​ន័យ​ថា​ការ​អស់​ពេល​ទ្វេ​ដង។


ឥឡូវយើងមើលថាតើមូលដ្ឋាននេះស្មើនឹងអ្វី។ តាមលំនាំដើម RTO អប្បបរមាគឺ 200 ms ។ នេះគឺជា RTO អប្បបរមាសម្រាប់កញ្ចប់ទិន្នន័យ។ សម្រាប់កញ្ចប់ SYN វាខុសគ្នា 1 វិនាទី។ ដូចដែលអ្នកអាចឃើញ សូម្បីតែការប៉ុនប៉ងដំបូងដើម្បីផ្ញើកញ្ចប់ព័ត៌មានឡើងវិញនឹងចំណាយពេល 100 ដងយូរជាង RTT នៅខាងក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។


ឥឡូវនេះ ចូរយើងត្រលប់ទៅសេណារីយ៉ូរបស់យើង។ តើមានអ្វីកើតឡើងជាមួយសេវាកម្ម? សេវាកម្មចាប់ផ្តើមបាត់បង់កញ្ចប់ព័ត៌មាន។ អនុញ្ញាតឱ្យសេវាកម្មមានលក្ខខណ្ឌសំណាងនៅពេលដំបូង ហើយបាត់បង់អ្វីមួយនៅកណ្តាលបង្អួច បន្ទាប់មកវាទទួលបាន SACK និងផ្ញើកញ្ចប់ព័ត៌មានដែលបានបាត់បង់ឡើងវិញ។


ប៉ុន្តែប្រសិនបើសំណាងអាក្រក់កើតឡើងម្តងទៀត នោះយើងមាន RTO ។ តើមានអ្វីសំខាន់នៅទីនេះ? បាទ យើងមានផ្លូវជាច្រើននៅក្នុងបណ្តាញរបស់យើង។ ប៉ុន្តែចរាចរណ៍ TCP នៃការតភ្ជាប់ TCP ជាក់លាក់មួយនឹងបន្តឆ្លងកាត់ជង់ដែលខូចដូចគ្នា។ ការបាត់បង់កញ្ចប់ព័ត៌មាន ផ្តល់ថា X11 វេទមន្តរបស់យើងមិនចេញទៅក្រៅដោយខ្លួនឯង មិននាំឱ្យចរាចរហូរចូលទៅក្នុងតំបន់ដែលមិនមានបញ្ហានោះទេ។ យើងកំពុងព្យាយាមចែកចាយកញ្ចប់ព័ត៌មានតាមរយៈជង់ដែលខូចដូចគ្នា។ នេះនាំទៅរកការបរាជ័យជាបណ្តើរៗ៖ មជ្ឈមណ្ឌលទិន្នន័យគឺជាសំណុំនៃកម្មវិធីអន្តរកម្ម ហើយការភ្ជាប់ TCP មួយចំនួននៃកម្មវិធីទាំងអស់នេះចាប់ផ្តើមចុះខ្សោយ ដោយសារផ្នែក superspine ប៉ះពាល់ដល់កម្មវិធីទាំងអស់ដែលមាននៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ ដូច​ពាក្យ​ពោល​ថា បើ​អ្នក​មិន​ជិះ​សេះ សេះ​ទៅ​ជា​ខ្វិន។ សេះបានទៅខ្វិន - របាយការណ៍មិនត្រូវបានផ្តល់ឱ្យ; របាយការណ៍មិនត្រូវបានផ្តល់ឱ្យទេ - យើងបានចាញ់សង្គ្រាម។ មានតែនៅទីនេះប៉ុណ្ណោះ ការរាប់គឺគិតជាវិនាទីចាប់ពីពេលដែលបញ្ហាកើតឡើងរហូតដល់ដំណាក់កាលនៃការរិចរិលដែលសេវាកម្មចាប់ផ្តើមមានអារម្មណ៍។ នេះមានន័យថា អ្នកប្រើប្រាស់អាចនឹងបាត់បង់អ្វីមួយនៅកន្លែងណាមួយ។


មានដំណោះស្រាយបុរាណពីរដែលបំពេញគ្នាទៅវិញទៅមក។ ទីមួយគឺសេវាកម្មដែលកំពុងព្យាយាមដាក់ចំបើងចូល និងដោះស្រាយបញ្ហាដូចនេះ៖ "តោះកែសំរួលអ្វីមួយនៅក្នុងជង់ TCP ។ ចូរធ្វើការអស់ពេលនៅកម្រិតកម្មវិធី ឬវគ្គ TCP ដែលមានរយៈពេលយូរជាមួយនឹងការត្រួតពិនិត្យសុខភាពខាងក្នុង។" បញ្ហាគឺថាដំណោះស្រាយបែបនេះ: ក) មិនធ្វើមាត្រដ្ឋានទាល់តែសោះ; ខ) ត្រូវបានត្រួតពិនិត្យយ៉ាងលំបាក។ នោះគឺ ទោះបីជាសេវាកម្មកំណត់រចនាសម្ព័ន្ធ TCP stack ដោយចៃដន្យតាមរបៀបដែលធ្វើឱ្យវាប្រសើរជាងមុនក៏ដោយ ទីមួយវាមិនទំនងអាចអនុវត្តបានសម្រាប់កម្មវិធីទាំងអស់ និងមជ្ឈមណ្ឌលទិន្នន័យទាំងអស់ ហើយទីពីរ ភាគច្រើនទំនងជាវាមិនយល់ថាវាត្រូវបានធ្វើរួចនោះទេ។ ត្រឹមត្រូវ ហើយអ្វីដែលមិនមែន។ នោះ​គឺ​វា​ដំណើរការ ប៉ុន្តែ​វា​ដំណើរការ​មិនល្អ ហើយ​មិន​ធ្វើ​មាត្រដ្ឋាន។ ហើយ​បើ​មាន​បញ្ហា​បណ្តាញ​តើ​អ្នក​ណា​ត្រូវ​បន្ទោស? ជាការពិតណាស់ NOC ។ តើ NOC ធ្វើអ្វី?

សេវាកម្មជាច្រើនជឿថានៅក្នុងការងារ NOC កើតឡើងដូចនេះ។ ប៉ុន្តែ​និយាយ​ឲ្យ​ត្រង់​ទៅ មិន​ត្រឹម​តែ​ប៉ុណ្ណឹង​ទេ។


NOC នៅក្នុងគ្រោងការណ៍បុរាណត្រូវបានចូលរួមនៅក្នុងការអភិវឌ្ឍប្រព័ន្ធត្រួតពិនិត្យជាច្រើន។ ទាំងនេះគឺជាការត្រួតពិនិត្យប្រអប់ខ្មៅ និងប្រអប់ស។ អំពីឧទាហរណ៍នៃការត្រួតពិនិត្យឆ្អឹងខ្នងប្រអប់ខ្មៅ បានប្រាប់ Alexander Klimenko នៅ Next Hop ចុងក្រោយ។ ដោយវិធីនេះការត្រួតពិនិត្យនេះដំណើរការ។ ប៉ុន្តែសូម្បីតែការត្រួតពិនិត្យដ៏ល្អក៏នឹងមានភាពយឺតយ៉ាវផងដែរ។ ជាធម្មតានេះគឺពីរបីនាទី។ បន្ទាប់ពីវារលត់ទៅ វិស្វករដែលបំពេញកាតព្វកិច្ចត្រូវការពេលវេលាដើម្បីពិនិត្យមើលប្រតិបត្តិការរបស់វាពីរដង ធ្វើមូលដ្ឋានីយកម្មបញ្ហា ហើយបន្ទាប់មកពន្លត់តំបន់បញ្ហា។ នោះគឺក្នុងករណីដែលល្អបំផុត ការដោះស្រាយបញ្ហាត្រូវចំណាយពេល 5 នាទី ក្នុងករណីដ៏អាក្រក់បំផុត 20 នាទី ប្រសិនបើវាមិនច្បាស់ភ្លាមៗពីកន្លែងដែលការខាតបង់កើតឡើង។ វាច្បាស់ណាស់ថាគ្រប់ពេលវេលា - 5 ឬ 20 នាទី - សេវាកម្មរបស់យើងនឹងបន្តរងទុក្ខ ដែលប្រហែលជាមិនល្អទេ។


តើអ្នកពិតជាចង់ទទួលបានអ្វី? យើងមានវិធីជាច្រើន។ ហើយបញ្ហាកើតឡើងយ៉ាងជាក់លាក់ដោយសារតែលំហូរ TCP ដែលមិនមានសំណាងបន្តប្រើផ្លូវដដែល។ យើងត្រូវការអ្វីមួយដែលនឹងអនុញ្ញាតឱ្យយើងប្រើផ្លូវច្រើនក្នុងការតភ្ជាប់ TCP តែមួយ។ វាហាក់ដូចជាយើងមានដំណោះស្រាយ។ មាន TCP ដែលត្រូវបានគេហៅថា multipath TCP នោះគឺ TCP សម្រាប់ផ្លូវច្រើន។ ពិត វាត្រូវបានបង្កើតឡើងសម្រាប់ភារកិច្ចខុសគ្នាទាំងស្រុង - សម្រាប់ស្មាតហ្វូនដែលមានឧបករណ៍បណ្តាញជាច្រើន។ ដើម្បីបង្កើនការផ្ទេរ ឬបង្កើតទម្រង់បឋម/បម្រុងទុក យន្តការមួយត្រូវបានបង្កើតឡើងដែលបង្កើតខ្សែស្រឡាយជាច្រើន (វគ្គ) ប្រកបដោយតម្លាភាពចំពោះកម្មវិធី និងអនុញ្ញាតឱ្យអ្នកប្តូររវាងពួកវាក្នុងករណីមានការបរាជ័យ។ ឬដូចដែលខ្ញុំបាននិយាយ បង្កើនកម្រិតអតិបរមា។

ប៉ុន្តែមានចំនុចពិសេសមួយនៅទីនេះ។ ដើម្បីយល់ថាវាជាអ្វី យើងនឹងត្រូវមើលពីរបៀបដែលខ្សែស្រឡាយត្រូវបានបង្កើតឡើង។


ខ្សែស្រឡាយត្រូវបានតំឡើងតាមលំដាប់លំដោយ។ ខ្សែទីមួយត្រូវបានតំឡើងជាមុន។ បន្ទាប់​មក​ខ្សែ​ស្រឡាយ​បន្ទាប់​ត្រូវ​បាន​កំណត់​ដោយ​ប្រើ​ខូគី​ដែល​បាន​យល់​ព្រម​រួច​ហើយ​ក្នុង​ខ្សែ​ស្រឡាយ​នោះ។ ហើយនេះគឺជាបញ្ហា។


បញ្ហាគឺថាប្រសិនបើខ្សែស្រឡាយទីមួយមិនបង្កើតដោយខ្លួនឯងនោះខ្សែទីពីរនិងទីបីនឹងមិនកើតឡើងទេ។ នោះគឺ multipath TCP មិនដោះស្រាយការបាត់បង់កញ្ចប់ព័ត៌មាន SYN នៅក្នុងលំហូរដំបូងទេ។ ហើយប្រសិនបើ SYN ត្រូវបានបាត់បង់នោះ multipath TCP ប្រែទៅជា TCP ធម្មតា។ នេះមានន័យថានៅក្នុងបរិយាកាសមជ្ឈមណ្ឌលទិន្នន័យវានឹងមិនជួយយើងដោះស្រាយបញ្ហាការខាតបង់នៅក្នុងរោងចក្រ និងរៀនប្រើផ្លូវច្រើនក្នុងករណីមានការបរាជ័យនោះទេ។


តើ​អ្វី​អាច​ជួយ​យើង? អ្នក​ខ្លះ​បាន​ទាយ​រួច​ហើយ​ពី​ចំណង​ជើង​ថា វាល​សំខាន់​មួយ​នៅ​ក្នុង​រឿង​បន្ថែម​ទៀត​របស់​យើង​នឹង​ជា​វាល​ក្បាល​ស្លាក​លំហូរ IPv6។ ជាការពិតនេះគឺជាវាលដែលលេចឡើងនៅក្នុង v6 វាមិនមែននៅក្នុង v4 ទេវាកាន់កាប់ 20 ប៊ីតហើយវាមានភាពចម្រូងចម្រាសលើការប្រើប្រាស់របស់វាជាយូរមកហើយ។ នេះគួរឱ្យចាប់អារម្មណ៍ណាស់ - មានជម្លោះអ្វីមួយត្រូវបានជួសជុលនៅក្នុង RFC ហើយនៅពេលជាមួយគ្នានោះការអនុវត្តបានលេចឡើងនៅក្នុងខឺណែលលីនុចដែលមិនត្រូវបានចងក្រងជាឯកសារគ្រប់ទីកន្លែង។


ខ្ញុំសូមអញ្ជើញអ្នកឱ្យទៅជាមួយខ្ញុំលើការស៊ើបអង្កេតតិចតួច។ សូមក្រឡេកមើលអ្វីដែលកំពុងកើតឡើងនៅក្នុងខឺណែលលីនុចក្នុងរយៈពេលប៉ុន្មានឆ្នាំកន្លងមកនេះ។

ឆ្នាំ 2014 ។ វិស្វករមកពីក្រុមហ៊ុនធំមួយ និងគួរឱ្យគោរពបន្ថែមលើមុខងាររបស់ខឺណែលលីនុច នូវភាពអាស្រ័យនៃតម្លៃស្លាកលំហូរនៅលើរន្ធរន្ធ។ តើពួកគេព្យាយាមជួសជុលអ្វីនៅទីនេះ? នេះគឺទាក់ទងទៅនឹង RFC 6438 ដែលបានពិភាក្សាអំពីបញ្ហាខាងក្រោម។ នៅខាងក្នុងមជ្ឈមណ្ឌលទិន្នន័យ IPv4 ជារឿយៗត្រូវបានរុំព័ទ្ធក្នុងកញ្ចប់ IPv6 ពីព្រោះរោងចក្រខ្លួនវាគឺ IPv6 ប៉ុន្តែ IPv4 ត្រូវតែផ្តល់ឱ្យនៅខាងក្រៅ។ អស់រយៈពេលជាយូរមានបញ្ហាជាមួយកុងតាក់ដែលមិនអាចមើលក្រោមបឋមកថា IP ពីរដើម្បីចូលទៅកាន់ TCP ឬ UDP និងស្វែងរក src_ports, dst_ports នៅទីនោះ។ វាបានប្រែក្លាយថា hash ប្រសិនបើអ្នកក្រឡេកមើលបឋមកថា IP ពីរដំបូងបានប្រែទៅជាស្ទើរតែត្រូវបានជួសជុល។ ដើម្បីជៀសវាងបញ្ហានេះ ដើម្បីឱ្យតុល្យភាពនៃចរាចរដែលរុំព័ទ្ធនេះដំណើរការបានត្រឹមត្រូវ វាត្រូវបានស្នើឱ្យបន្ថែមសញ្ញានៃកញ្ចប់ព័ត៌មានដែលបិទបាំង 5-tuple ទៅតម្លៃនៃវាលស្លាកលំហូរ។ ប្រហែលជារឿងដូចគ្នានេះត្រូវបានធ្វើសម្រាប់គ្រោងការណ៍ការវេចខ្ចប់ផ្សេងទៀតសម្រាប់ UDP សម្រាប់ GRE ក្រោយមកទៀតបានប្រើវាល GRE Key ។ វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត គោលដៅនៅទីនេះគឺច្បាស់។ ហើយយ៉ាងហោចណាស់នៅចំណុចនោះនៅក្នុងពេលដែលពួកគេមានប្រយោជន៍។

នៅឆ្នាំ 2015 បំណះថ្មីមួយបានមកពីវិស្វករដែលមានការគោរពដូចគ្នា។ គាត់គួរឱ្យចាប់អារម្មណ៍ណាស់។ វានិយាយដូចខាងក្រោម - យើងនឹងចៃដន្យ hash ក្នុងករណីមានព្រឹត្តិការណ៍នាំផ្លូវអវិជ្ជមាន។ តើ​អ្វី​ទៅ​ជា​ព្រឹត្តិការណ៍​នាំផ្លូវ​អវិជ្ជមាន? នេះគឺជា RTO ដែលយើងបានពិភាក្សាពីមុន នោះគឺការបាត់បង់កន្ទុយនៃបង្អួចគឺជាព្រឹត្តិការណ៍ដែលពិតជាអវិជ្ជមាន។ ពិត​មែន វា​ពិបាក​ស្មាន​ណាស់​ថា​នេះ​ជា​វា​។

2016 ដែលជាក្រុមហ៊ុនល្បីឈ្មោះមួយទៀតក៏ធំដែរ។ វារុះរើឈើច្រត់ចុងក្រោយ និងធ្វើឱ្យវាដូច្នេះថា hash ដែលពីមុនយើងធ្វើដោយចៃដន្យ ឥឡូវនេះផ្លាស់ប្តូរសម្រាប់ការបញ្ជូនបន្ត SYN នីមួយៗ និងបន្ទាប់ពីអស់ពេល RTO នីមួយៗ។ ហើយនៅក្នុងសំបុត្រនេះ ជាលើកដំបូង និងចុងក្រោយ គោលដៅចុងក្រោយគឺត្រូវបានចែង - ដើម្បីធានាថាចរាចរណ៍ក្នុងករណីមានការខាតបង់ ឬការកកស្ទះឆានែល មានសមត្ថភាពធ្វើផ្លូវឡើងវិញដោយទន់ភ្លន់ និងប្រើប្រាស់ផ្លូវច្រើន។ ជាការពិតណាស់បន្ទាប់ពីនេះមានការបោះពុម្ពផ្សាយជាច្រើនអ្នកអាចស្វែងរកវាបានយ៉ាងងាយស្រួល។

ទោះបីជាទេ អ្នកមិនអាចទេ ព្រោះមិនទាន់មានការបោះពុម្ពផ្សាយតែមួយលើប្រធានបទនេះទេ។ ប៉ុន្តែយើងដឹង!

ហើយប្រសិនបើអ្នកមិនយល់ច្បាស់ពីអ្វីដែលបានធ្វើ ខ្ញុំនឹងប្រាប់អ្នកឥឡូវនេះ។


តើ​ត្រូវ​បាន​ធ្វើ​អ្វី​ខ្លះ មុខងារ​អ្វី​ត្រូវ​បាន​បន្ថែម​ទៅ​ខឺណែល​លីនុច? ត្រឹមត្រូវsh ផ្លាស់ប្តូរទៅជាតម្លៃចៃដន្យបន្ទាប់ពីព្រឹត្តិការណ៍ RTO នីមួយៗ។ នេះគឺជាលទ្ធផលអវិជ្ជមានយ៉ាងខ្លាំងនៃការបញ្ជូន។ សញ្ញា​អាស្រ័យ​លើ​សូន្យ​នេះ ហើយ​ស្លាក​លំហូរ​អាស្រ័យ​លើ​សញ្ញា skb ។ មានការគណនាមួយចំនួនលើមុខងារនៅទីនេះ ព័ត៌មានលម្អិតទាំងអស់មិនអាចដាក់នៅលើស្លាយតែមួយបានទេ។ ប្រសិនបើអ្នកណាម្នាក់ចង់ដឹងចង់ឃើញ អ្នកអាចចូលទៅមើលកូដខឺណែល ហើយពិនិត្យមើល។

តើមានអ្វីសំខាន់នៅទីនេះ? តម្លៃនៃវាលស្លាកលំហូរផ្លាស់ប្តូរទៅជាលេខចៃដន្យបន្ទាប់ពី RTO នីមួយៗ។ តើវាប៉ះពាល់ដល់ការផ្សាយ TCP អកុសលរបស់យើងយ៉ាងដូចម្តេច?


ប្រសិនបើ SACK កើតឡើង គ្មានអ្វីផ្លាស់ប្តូរទេ ដោយសារយើងកំពុងព្យាយាមផ្ញើកញ្ចប់ព័ត៌មានដែលបាត់ដែលគេស្គាល់ឡើងវិញ។ មកដល់ពេលនេះល្អណាស់។


ប៉ុន្តែនៅក្នុងករណីនៃ RTO បានផ្តល់ថាយើងបានបន្ថែមស្លាកលំហូរទៅមុខងារ hash នៅលើ ToR ចរាចរណ៍អាចប្រើផ្លូវផ្សេង។ ហើយផ្លូវកាន់តែច្រើន ឱកាសកាន់តែច្រើនដែលវានឹងរកឃើញផ្លូវដែលមិនត្រូវបានប៉ះពាល់ដោយការបរាជ័យនៅលើឧបករណ៍ជាក់លាក់មួយ។


បញ្ហាមួយនៅតែមាន - RTO ។ ជា​ការ​ពិត​ណាស់ មាន​ផ្លូវ​មួយ​ទៀត ប៉ុន្តែ​ពេល​វេលា​ច្រើន​ត្រូវ​ខ្ជះខ្ជាយ​លើ​ផ្លូវ​នេះ។ 200 ms គឺច្រើនណាស់។ មួយវិនាទីគឺពិតជាព្រៃ។ ពីមុនខ្ញុំបាននិយាយអំពីការអស់ពេលដែលសេវាកម្មត្រូវបានកំណត់រចនាសម្ព័ន្ធ។ ដូច្នេះ វិនាទីគឺជាការអស់ពេល ដែលជាធម្មតាត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយសេវាកម្មនៅកម្រិតកម្មវិធី ហើយនៅក្នុងសេវាកម្មនេះក៏នឹងត្រឹមត្រូវផងដែរ។ លើសពីនេះទៅទៀត ខ្ញុំនិយាយម្តងទៀតថា RTT ពិតប្រាកដនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទំនើបគឺប្រហែល 1 មិល្លីវិនាទី។


តើអ្នកអាចធ្វើអ្វីបានជាមួយនឹងការអស់ពេល RTO? ការអស់ពេលដែលទទួលខុសត្រូវចំពោះ RTO ក្នុងករណីបាត់បង់កញ្ចប់ទិន្នន័យអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធយ៉ាងងាយស្រួលពីទំហំអ្នកប្រើប្រាស់៖ មានឧបករណ៍ប្រើប្រាស់ IP ហើយប៉ារ៉ាម៉ែត្រមួយក្នុងចំណោមប៉ារ៉ាម៉ែត្ររបស់វាមាន rto_min ដូចគ្នា។ ដោយពិចារណាថា RTO ពិតណាស់ចាំបាច់ត្រូវកែតម្រូវមិនមែនសកលទេ ប៉ុន្តែសម្រាប់បុព្វបទដែលបានផ្តល់ឱ្យ យន្តការបែបនេះមើលទៅអាចដំណើរការបាន។


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


eBPF មកជួយសង្គ្រោះ។ ដើម្បីនិយាយឱ្យសាមញ្ញ ទាំងនេះគឺជាកម្មវិធី C តូចៗ។ ពួកវាអាចត្រូវបានបញ្ចូលទៅក្នុងទំពក់នៅកន្លែងផ្សេងៗគ្នាក្នុងការប្រតិបត្តិនៃជង់ខឺណែល និងជង់ TCP ដែលអ្នកអាចផ្លាស់ប្តូរការកំណត់មួយចំនួនធំ។ ជាទូទៅ eBPF គឺជានិន្នាការរយៈពេលវែង។ ជំនួសឱ្យការកាត់ប៉ារ៉ាម៉ែត្រ sysctl ថ្មីរាប់សិប និងពង្រីកឧបករណ៍ប្រើប្រាស់ IP ចលនាកំពុងឆ្ពោះទៅរក eBPF និងពង្រីកមុខងាររបស់វា។ ដោយប្រើ eBPF អ្នកអាចផ្លាស់ប្តូរការគ្រប់គ្រងការកកស្ទះ និងការកំណត់ TCP ផ្សេងៗយ៉ាងសកម្ម។


ប៉ុន្តែវាមានសារៈសំខាន់សម្រាប់យើងដែលវាអាចត្រូវបានប្រើដើម្បីផ្លាស់ប្តូរតម្លៃ SYN_RTO ។ លើស​ពី​នេះ​ទៅ​ទៀត មាន​ឧទាហរណ៍​ដែល​បាន​បង្ហោះ​ជា​សាធារណៈ៖ https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. តើបានធ្វើអ្វីនៅទីនេះ? ឧទាហរណ៍កំពុងដំណើរការ ប៉ុន្តែនៅក្នុងខ្លួនវាគឺរដុបខ្លាំងណាស់។ នៅទីនេះវាត្រូវបានសន្មត់ថានៅខាងក្នុងមជ្ឈមណ្ឌលទិន្នន័យយើងប្រៀបធៀប 44 ប៊ីតដំបូងប្រសិនបើវាត្រូវគ្នានោះយើងស្ថិតនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ ហើយក្នុងករណីនេះយើងប្តូរតម្លៃអស់ពេល SYN_RTO ទៅជា 4ms។ ភារកិច្ចដូចគ្នាអាចត្រូវបានធ្វើកាន់តែឆើតឆាយ។ ប៉ុន្តែ​ឧទាហរណ៍​សាមញ្ញ​នេះ​បង្ហាញ​ថា​នេះ​គឺ​ជា a) អាច​ទៅ​រួច; ខ) សាមញ្ញ។

តើយើងដឹងអ្វីខ្លះហើយ? ការពិតដែលថាស្ថាបត្យកម្មយន្តហោះអនុញ្ញាតឱ្យធ្វើមាត្រដ្ឋាន វាប្រែថាមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់យើងនៅពេលដែលយើងបើកស្លាកលំហូរនៅលើ ToR និងទទួលបានសមត្ថភាពក្នុងការហូរជុំវិញតំបន់ដែលមានបញ្ហា។ មធ្យោបាយដ៏ល្អបំផុតដើម្បីកាត់បន្ថយតម្លៃ RTO និង SYN-RTO គឺត្រូវប្រើកម្មវិធី eBPF ។ សំណួរនៅតែមាន៖ តើវាមានសុវត្ថិភាពក្នុងការប្រើស្លាកលំហូរសម្រាប់តុល្យភាពដែរឬទេ? ហើយនៅទីនេះមាន nuance មួយ។


ឧបមាថាអ្នកមានសេវាកម្មនៅលើបណ្តាញរបស់អ្នកដែលរស់នៅក្នុងកម្មវិធីណាមួយ។ ជាអកុសល ខ្ញុំមិនមានពេលវេលាដើម្បីចូលទៅលម្អិតអំពីអ្វីដែលជា anycast នោះទេ ប៉ុន្តែវាគឺជាសេវាកម្មចែកចាយដែលមានម៉ាស៊ីនមេផ្សេងគ្នាដែលអាចចូលប្រើបានតាមរយៈអាសយដ្ឋាន IP ដូចគ្នា។ ហើយនេះគឺជាបញ្ហាដែលអាចកើតមាន: ព្រឹត្តិការណ៍ RTO អាចកើតឡើងមិនត្រឹមតែនៅពេលដែលចរាចរណ៍ឆ្លងកាត់ក្រណាត់នោះទេ។ វាក៏អាចកើតឡើងនៅកម្រិត ToR buffer ផងដែរ៖ នៅពេលដែលព្រឹត្តិការណ៍ incast កើតឡើង វាអាចកើតឡើងនៅលើ host នៅពេលដែល host spills អ្វីមួយ។ នៅពេលដែលព្រឹត្តិការណ៍ RTO កើតឡើង ហើយវាផ្លាស់ប្តូរស្លាកលំហូរ។ ក្នុងករណីនេះ ចរាចរណ៍អាចទៅកាន់ធាតុណាមួយផ្សេងទៀត ចូរសន្មត់ថានេះជាកម្មវិធីណាមួយដែលមានស្ថានភាព វាមានស្ថានភាពតភ្ជាប់ - វាអាចជា L3 Balancer ឬសេវាកម្មផ្សេងទៀត។ បន្ទាប់មកបញ្ហាកើតឡើងព្រោះបន្ទាប់ពី RTO ការតភ្ជាប់ TCP មកដល់ម៉ាស៊ីនមេដែលមិនដឹងអ្វីសោះអំពីការតភ្ជាប់ TCP នេះ។ ហើយប្រសិនបើយើងមិនមានការចែករំលែករដ្ឋរវាងម៉ាស៊ីនមេណាមួយទេនោះ ចរាចរណ៍បែបនេះនឹងត្រូវបានទម្លាក់ ហើយការភ្ជាប់ TCP នឹងខូច។


តើអ្នកអាចធ្វើអ្វីនៅទីនេះ? នៅក្នុងបរិយាកាសដែលបានគ្រប់គ្រងរបស់អ្នក ដែលអ្នកបើកដំណើរការសមតុល្យស្លាកលំហូរ អ្នកត្រូវកត់ត្រាតម្លៃនៃស្លាកលំហូរ នៅពេលចូលប្រើម៉ាស៊ីនមេណាមួយ។ មធ្យោបាយងាយស្រួលបំផុតគឺធ្វើដូចនេះតាមរយៈកម្មវិធី eBPF ដូចគ្នា។ ប៉ុន្តែនេះគឺជាចំណុចសំខាន់ណាស់ - អ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកមិនដំណើរការបណ្តាញមជ្ឈមណ្ឌលទិន្នន័យប៉ុន្តែជាប្រតិបត្តិករទូរគមនាគមន៍? នេះគឺជាបញ្ហារបស់អ្នកផងដែរ៖ ចាប់ផ្តើមជាមួយនឹងកំណែជាក់លាក់នៃ Juniper និង Arista ពួកគេរួមបញ្ចូលស្លាកលំហូរនៅក្នុងមុខងារ hash របស់ពួកគេតាមលំនាំដើម - និយាយដោយត្រង់ទៅសម្រាប់ហេតុផលដែលមិនច្បាស់លាស់សម្រាប់ខ្ញុំ។ នេះអាចបណ្តាលឱ្យអ្នកទម្លាក់ការភ្ជាប់ TCP ពីអ្នកប្រើប្រាស់ដែលឆ្លងកាត់បណ្តាញរបស់អ្នក។ ដូច្នេះខ្ញុំសូមផ្តល់អនុសាសន៍ឱ្យពិនិត្យមើលការកំណត់រ៉ោតទ័ររបស់អ្នកនៅទីនេះ។

មធ្យោបាយមួយ ឬមធ្យោបាយផ្សេងទៀត វាហាក់ដូចជាខ្ញុំថា យើងត្រៀមខ្លួនរួចជាស្រេចដើម្បីបន្តទៅការពិសោធន៍។


នៅពេលដែលយើងបើកដំណើរការស្លាកលំហូរនៅលើ ToR បានរៀបចំភ្នាក់ងារ eBPF ដែលឥឡូវនេះរស់នៅលើម៉ាស៊ីន យើងបានសម្រេចចិត្តមិនរង់ចាំការបរាជ័យដ៏ធំបន្ទាប់ទៀតនោះទេ ប៉ុន្តែដើម្បីធ្វើការបំផ្ទុះដែលគ្រប់គ្រង។ យើងបានយក ToR ដែលមានតំណភ្ជាប់ឡើងចំនួនបួន ហើយដំឡើងដំណក់ទឹកលើមួយក្នុងចំណោមពួកគេ។ ពួកគេបានគូរច្បាប់មួយហើយនិយាយថា - ឥឡូវនេះអ្នកកំពុងបាត់បង់កញ្ចប់ទាំងអស់។ ដូចដែលអ្នកអាចឃើញនៅខាងឆ្វេងយើងមានការត្រួតពិនិត្យក្នុងមួយកញ្ចប់ដែលបានធ្លាក់ចុះដល់ 75% ពោលគឺ 25% នៃកញ្ចប់ព័ត៌មានត្រូវបានបាត់បង់។ នៅខាងស្តាំគឺជាក្រាហ្វនៃសេវាកម្មដែលរស់នៅខាងក្រោយ ToR នេះ។ សំខាន់ ទាំងនេះគឺជាក្រាហ្វចរាចរណ៍នៃចំណុចប្រទាក់ជាមួយម៉ាស៊ីនមេនៅខាងក្នុង rack ។ ដូចដែលអ្នកអាចឃើញពួកគេបានលិចទាបជាង។ ហេតុអ្វីបានជាពួកគេធ្លាក់ចុះទាប - មិនមែន 25% ប៉ុន្តែក្នុងករណីខ្លះ 3-4 ដង? ប្រសិនបើការភ្ជាប់ TCP សំណាងមិនល្អ វានៅតែបន្តព្យាយាមទៅដល់តាមរយៈប្រសព្វដែលខូច។ នេះត្រូវបានធ្វើឱ្យធ្ងន់ធ្ងរឡើងដោយឥរិយាបថធម្មតានៃសេវាកម្មនៅក្នុង DC - សម្រាប់សំណើរបស់អ្នកប្រើមួយ សំណើ N ចំពោះសេវាកម្មខាងក្នុងត្រូវបានបង្កើត ហើយការឆ្លើយតបនឹងទៅដល់អ្នកប្រើប្រាស់នៅពេលដែលប្រភពទិន្នន័យទាំងអស់ឆ្លើយតប ឬនៅពេលដែលអស់ពេលកើតឡើងនៅក្នុងកម្មវិធី។ កម្រិត ដែលនៅតែត្រូវកំណត់រចនាសម្ព័ន្ធ។ នោះគឺអ្វីគ្រប់យ៉ាងគឺអាក្រក់ខ្លាំងណាស់។


ឥឡូវនេះការពិសោធន៍ដូចគ្នា ប៉ុន្តែជាមួយនឹងតម្លៃស្លាកលំហូរត្រូវបានបើក។ ដូចដែលអ្នកអាចឃើញនៅខាងឆ្វេងការត្រួតពិនិត្យជាបាច់របស់យើងបានធ្លាក់ចុះដូចគ្នា 25% ។ នេះពិតជាត្រឹមត្រូវ ព្រោះវាមិនដឹងអ្វីទាំងអស់អំពីការបញ្ជូនសារឡើងវិញ វាផ្ញើកញ្ចប់ព័ត៌មាន ហើយគ្រាន់តែរាប់សមាមាត្រនៃចំនួនកញ្ចប់ដែលបានចែកចាយ និងបាត់បង់។

ហើយនៅខាងស្តាំគឺជាកាលវិភាគសេវាកម្ម។ អ្នកនឹងមិនអាចរកឃើញឥទ្ធិពលនៃសន្លាក់ដែលមានបញ្ហានៅទីនេះទេ។ ក្នុងមិល្លីវិនាទីដូចគ្នានោះ ចរាចរណ៍បានហូរចេញពីតំបន់បញ្ហាទៅកាន់បណ្តាញភ្ជាប់ដែលនៅសេសសល់ចំនួនបី ដែលមិនត្រូវបានប៉ះពាល់ដោយបញ្ហានេះ។ យើងទទួលបានបណ្តាញដែលព្យាបាលខ្លួនឯង។

នេះជាស្លាយចុងក្រោយរបស់ខ្ញុំ ដល់ពេលដែលត្រូវសង្ខេប។ ឥឡូវនេះ ខ្ញុំសង្ឃឹមថាអ្នកដឹងពីរបៀបបង្កើតបណ្តាញមជ្ឈមណ្ឌលទិន្នន័យព្យាបាលដោយខ្លួនឯង។ អ្នកនឹងមិនចាំបាច់ឆ្លងកាត់បណ្ណសារខឺណែលលីនុច ហើយរកមើលបំណះពិសេសនៅទីនោះទេ អ្នកដឹងថាស្លាក Flow ក្នុងករណីនេះដោះស្រាយបញ្ហា ប៉ុន្តែអ្នកត្រូវចូលទៅជិតយន្តការនេះដោយប្រុងប្រយ័ត្ន។ ហើយខ្ញុំបញ្ជាក់ម្តងទៀតថា ប្រសិនបើអ្នកជាប្រតិបត្តិករទូរគមនាគមន៍ អ្នកមិនគួរប្រើ Flow label ជាមុខងារ hash ទេ បើមិនដូច្នេះទេ អ្នកនឹងរំខានដល់វគ្គរបស់អ្នកប្រើប្រាស់។

វិស្វករបណ្តាញត្រូវតែឆ្លងកាត់ការផ្លាស់ប្តូរគំនិត៖ បណ្តាញចាប់ផ្តើមមិនមែនជាមួយ ToR មិនមែនជាមួយឧបករណ៍បណ្តាញ ប៉ុន្តែជាមួយម៉ាស៊ីន។ ឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍មួយគឺរបៀបដែលយើងប្រើ eBPF ទាំងពីរដើម្បីផ្លាស់ប្តូរ RTO និងដើម្បីជួសជុលស្លាកលំហូរឆ្ពោះទៅរកសេវាណាមួយខាស។

យន្តការស្លាកលំហូរគឺពិតជាសមរម្យសម្រាប់កម្មវិធីផ្សេងទៀតនៅក្នុងផ្នែករដ្ឋបាលដែលបានគ្រប់គ្រង។ នេះអាចជាចរាចរណ៍រវាងមជ្ឈមណ្ឌលទិន្នន័យ ឬអ្នកអាចប្រើមេកានិចបែបនេះក្នុងវិធីពិសេសមួយដើម្បីគ្រប់គ្រងចរាចរណ៍ចេញ។ ប៉ុន្តែខ្ញុំនឹងប្រាប់អ្នកអំពីរឿងនេះ ខ្ញុំសង្ឃឹមថាលើកក្រោយ។ អរគុណច្រើនសម្រាប់ការយកចិត្តទុកដាក់របស់អ្នក។

ប្រភព: www.habr.com