របៀបដែល AWS ចម្អិនសេវាកម្មយឺតរបស់វា។ ការធ្វើមាត្រដ្ឋានបណ្តាញ

មាត្រដ្ឋាននៃបណ្តាញសេវាគេហទំព័រ Amazon មាន 69 តំបន់ជុំវិញពិភពលោកក្នុង 22 តំបន់៖ សហរដ្ឋអាមេរិក អឺរ៉ុប អាស៊ី អាហ្រ្វិក និងអូស្ត្រាលី។ តំបន់នីមួយៗមានមជ្ឈមណ្ឌលទិន្នន័យរហូតដល់ 8 - មជ្ឈមណ្ឌលដំណើរការទិន្នន័យ។ មជ្ឈមណ្ឌលទិន្នន័យនីមួយៗមានម៉ាស៊ីនមេរាប់ពាន់ ឬរាប់រយរាប់ពាន់។ បណ្តាញនេះត្រូវបានរចនាឡើងតាមរបៀបដែលសេណារីយ៉ូដែលមិនទំនងទាំងអស់ត្រូវបានយកមកពិចារណា។ ជាឧទាហរណ៍ តំបន់ទាំងអស់គឺដាច់ឆ្ងាយពីគ្នាទៅវិញទៅមក ហើយតំបន់ភាពងាយស្រួលត្រូវបានបំបែកចេញពីគ្នាក្នុងចម្ងាយជាច្រើនគីឡូម៉ែត្រ។ ទោះបីជាអ្នកកាត់ខ្សែក៏ដោយ ប្រព័ន្ធនឹងប្តូរទៅបណ្តាញបម្រុងទុក ហើយការបាត់បង់ព័ត៌មាននឹងមានចំនួនដល់កញ្ចប់ទិន្នន័យមួយចំនួន។ Vasily Pantyukhin នឹងនិយាយអំពីគោលការណ៍ផ្សេងទៀតដែលបណ្តាញត្រូវបានបង្កើតឡើង និងរបៀបដែលវាត្រូវបានរៀបចំឡើង។

Vasily Pantyukhin បានចាប់ផ្តើមជាអ្នកគ្រប់គ្រងយូនីកនៅក្នុងក្រុមហ៊ុន .ru ធ្វើការលើផ្នែករឹង Sun Microsystem ដ៏ធំសម្រាប់រយៈពេល 6 ឆ្នាំបានផ្សព្វផ្សាយពិភពលោកដែលផ្តោតលើទិន្នន័យនៅ EMC អស់រយៈពេល 11 ឆ្នាំ។ ដោយធម្មជាតិវាបានវិវត្តទៅជាពពកឯកជន បន្ទាប់មកប្តូរទៅកន្លែងសាធារណៈ។ ឥឡូវនេះក្នុងនាមជាស្ថាបត្យករ Amazon Web Services គាត់ផ្តល់ដំបូន្មានបច្ចេកទេសដើម្បីជួយរស់នៅ និងអភិវឌ្ឍក្នុង AWS cloud។

នៅក្នុងផ្នែកមុននៃ AWS trilogy, Vasily បានបញ្ចូលទៅក្នុងការរចនានៃម៉ាស៊ីនមេរាងកាយ និងការធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យ។ កាត Nitro, hypervisor ដែលមានមូលដ្ឋានលើ KVM ផ្ទាល់ខ្លួន, មូលដ្ឋានទិន្នន័យ Amazon Aurora - អំពីអ្វីៗទាំងអស់នេះនៅក្នុងសម្ភារៈ "របៀបដែល AWS ចម្អិនសេវាកម្មយឺតរបស់វា។ ធ្វើមាត្រដ្ឋានម៉ាស៊ីនមេ និងមូលដ្ឋានទិន្នន័យ" អានសម្រាប់បរិបទ ឬមើល ខ្សែវីដេអូ សុន្ទរកថា។

ផ្នែកនេះនឹងផ្តោតលើការធ្វើមាត្រដ្ឋានបណ្តាញ ដែលជាប្រព័ន្ធស្មុគស្មាញបំផុតមួយនៅក្នុង AWS ។ ការវិវត្តន៍ពីបណ្តាញផ្ទះល្វែងទៅជា Virtual Private Cloud និងការរចនារបស់វា សេវាកម្មខាងក្នុងរបស់ Blackfoot និង HyperPlane ដែលជាបញ្ហារបស់អ្នកជិតខាងដែលមានសំលេងរំខាន ហើយនៅចុងបញ្ចប់ - មាត្រដ្ឋាននៃបណ្តាញ ឆ្អឹងខ្នង និងខ្សែរាងកាយ។ អំពីទាំងអស់នេះនៅក្រោមការកាត់។

ការបដិសេធ៖ អ្វីគ្រប់យ៉ាងខាងក្រោមគឺជាគំនិតផ្ទាល់ខ្លួនរបស់ Vasily ហើយប្រហែលជាមិនស្របគ្នាជាមួយនឹងទីតាំងនៃ Amazon Web Services នោះទេ។

ការធ្វើមាត្រដ្ឋានបណ្តាញ

ពពក AWS ត្រូវបានដាក់ឱ្យដំណើរការនៅឆ្នាំ ២០០៦។ បណ្តាញរបស់គាត់មានលក្ខណៈដើមណាស់ - ជាមួយនឹងរចនាសម្ព័ន្ធផ្ទះល្វែង។ ជួរនៃអាសយដ្ឋានឯកជនគឺជារឿងធម្មតាសម្រាប់អ្នកជួលពពកទាំងអស់។ នៅពេលចាប់ផ្តើមម៉ាស៊ីននិម្មិតថ្មី អ្នកបានទទួលអាសយដ្ឋាន IP ដែលអាចប្រើបានដោយចៃដន្យពីជួរនេះ។

វិធីសាស្រ្តនេះមានភាពងាយស្រួលក្នុងការអនុវត្ត ប៉ុន្តែជាមូលដ្ឋានកំណត់ការប្រើប្រាស់ពពក។ ជាពិសេស វាពិបាកណាស់ក្នុងការអភិវឌ្ឍន៍ដំណោះស្រាយកូនកាត់ដែលរួមបញ្ចូលគ្នានូវបណ្តាញឯកជននៅលើដី និងក្នុង AWS ។ បញ្ហាទូទៅបំផុតគឺការត្រួតលើជួរអាសយដ្ឋាន IP ។

ពពកឯកជននិម្មិត

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

តើ​អ្វី​ជា​រឿង​ដំបូង​ដែល​អ្នក​គិត​ដល់​ពេល​អ្នក​គិត​អំពី​ភាព​ឯកោ​បណ្ដាញ? ពិតប្រាកដ វ៉ាលីន и VRF - ការបញ្ជូនបន្តនិម្មិត.

ជាអកុសល វាមិនដំណើរការទេ។ លេខសម្គាល់ VLAN គឺមានតែ 12 ប៊ីតប៉ុណ្ណោះ ដែលផ្តល់ឱ្យយើងនូវផ្នែកដាច់ដោយឡែកចំនួន 4096 ប៉ុណ្ណោះ។ សូម្បីតែកុងតាក់ធំបំផុតអាចប្រើ VRF អតិបរមាពី 1-2 ពាន់។ ការប្រើប្រាស់ VRF និង VLAN រួមគ្នាផ្តល់ឱ្យយើងនូវបណ្តាញរងចំនួនពីរបីលានប៉ុណ្ណោះ។ នេះពិតជាមិនគ្រប់គ្រាន់ទេសម្រាប់អ្នកជួលរាប់សិបលាននាក់ ដែលនីមួយៗត្រូវតែអាចប្រើបណ្តាញរងច្រើន។

យើង​ក៏​មិន​អាច​មាន​លទ្ធភាព​ទិញ​ចំនួន​ប្រអប់​ធំ​ដែល​ត្រូវ​ការ​ដែរ ឧទាហរណ៍​ពី Cisco ឬ Juniper ។ មានហេតុផលពីរយ៉ាង៖ វាថ្លៃឆ្កួត ហើយយើងមិនចង់មានចិត្តមេត្តាចំពោះការអភិវឌ្ឍន៍ និងគោលនយោបាយបំណះរបស់ពួកគេទេ។

មានការសន្និដ្ឋានតែមួយគត់ - បង្កើតដំណោះស្រាយដោយខ្លួនឯង។

នៅឆ្នាំ ២០០៩ យើងបានប្រកាស VPC - ពពកឯកជននិម្មិត. ឈ្មោះជាប់គាំង ហើយឥឡូវនេះអ្នកផ្តល់សេវាពពកជាច្រើនក៏ប្រើវាដែរ។

VPC គឺជាបណ្តាញនិម្មិត SDN (បណ្តាញដែលកំណត់ដោយកម្មវិធី)។ យើងបានសម្រេចចិត្តមិនបង្កើតពិធីការពិសេសនៅកម្រិត L2 និង L3 ទេ។ បណ្តាញដំណើរការលើស្តង់ដារ Ethernet និង IP ។ សម្រាប់ការបញ្ជូនតាមបណ្តាញ ចរាចរម៉ាស៊ីននិម្មិតត្រូវបានរុំព័ទ្ធក្នុងរុំពិធីការផ្ទាល់ខ្លួនរបស់យើង។ វាបង្ហាញពីលេខសម្គាល់ដែលជាកម្មសិទ្ធិរបស់ VPC របស់អ្នកជួល។

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

នៅក្នុងម៉ាស៊ីនជំនាន់ថ្មី ការវេចខ្ចប់ត្រូវបានអនុវត្តដោយកាត Nitro នៅកម្រិតផ្នែករឹង។ ក្នុង​ករណី​ចាស់​ជាង​នេះ ការ​បិទ​បាំង​និង​ការ​កាត់​ចេញ​គឺ​ផ្អែក​លើ​កម្មវិធី។ 

ចូរយើងស្វែងយល់ពីរបៀបដែលវាដំណើរការនៅក្នុងពាក្យទូទៅ។ ចូរចាប់ផ្តើមជាមួយនឹងកម្រិត L2 ។ ឧបមាថាយើងមានម៉ាស៊ីននិម្មិតដែលមាន IP 10.0.0.2 នៅលើម៉ាស៊ីនមេ 192.168.0.3 ។ វាបញ្ជូនទិន្នន័យទៅម៉ាស៊ីននិម្មិត 10.0.0.3 ដែលរស់នៅលើ 192.168.1.4 ។ សំណើ ARP ត្រូវបានបង្កើត និងផ្ញើទៅកាន់បណ្តាញ Nitro card។ សម្រាប់ភាពសាមញ្ញ យើងសន្មត់ថាម៉ាស៊ីននិម្មិតទាំងពីររស់នៅក្នុង VPC "ពណ៌ខៀវ" ដូចគ្នា។

ផែនទីជំនួសអាសយដ្ឋានប្រភពដោយខ្លួនវា ហើយបញ្ជូនបន្តស៊ុម ARP ទៅសេវាកម្មផែនទី។

សេវាកម្មគូសផែនទីបង្ហាញព័ត៌មានដែលចាំបាច់សម្រាប់ការបញ្ជូនតាមបណ្តាញរូបវន្ត L2 ។

កាត Nitro នៅក្នុងការឆ្លើយតបរបស់ ARP ជំនួស MAC នៅលើបណ្តាញរូបវន្តជាមួយនឹងអាសយដ្ឋាននៅក្នុង VPC ។

នៅពេលផ្ទេរទិន្នន័យ យើងរុំឡូជីខល MAC និង IP នៅក្នុងរុំ VPC ។ យើងបញ្ជូនអ្វីៗទាំងអស់នេះតាមបណ្តាញរូបវន្ត ដោយប្រើកាត IP Nitro ប្រភព និងទិសដៅសមស្រប។

ម៉ាស៊ីនរាងកាយដែលកញ្ចប់ត្រូវកំណត់ ធ្វើការត្រួតពិនិត្យ។ នេះគឺចាំបាច់ដើម្បីការពារលទ្ធភាពនៃការក្លែងបន្លំអាសយដ្ឋាន។ ម៉ាស៊ីនផ្ញើសំណើពិសេសមួយទៅកាន់សេវាកម្មគូសផែនទី ហើយសួរថា “ពីម៉ាស៊ីន 192.168.0.3 ខ្ញុំបានទទួលកញ្ចប់ព័ត៌មានដែលមានបំណងសម្រាប់ 10.0.0.3 នៅក្នុង VPC ពណ៌ខៀវ។ តើគាត់ស្របច្បាប់ទេ? 

សេវាផែនទីពិនិត្យតារាងបែងចែកធនធានរបស់វា ហើយអនុញ្ញាត ឬបដិសេធកញ្ចប់ព័ត៌មានឱ្យឆ្លងកាត់។ នៅក្នុងករណីថ្មីទាំងអស់ សុពលភាពបន្ថែមត្រូវបានបង្កប់នៅក្នុងកាត Nitro។ វាមិនអាចទៅរួចទេក្នុងការរំលងវាសូម្បីតែទ្រឹស្តី។ ដូច្នេះ ការក្លែងបន្លំទៅធនធាននៅក្នុង VPC មួយផ្សេងទៀតនឹងមិនដំណើរការទេ។

បន្ទាប់មកទិន្នន័យត្រូវបានផ្ញើទៅម៉ាស៊ីននិម្មិតដែលវាត្រូវបានបម្រុងទុក។ 

សេវាកម្មគូសផែនទីក៏ដំណើរការជារ៉ោតទ័រឡូជីខលសម្រាប់ការផ្ទេរទិន្នន័យរវាងម៉ាស៊ីននិម្មិតនៅក្នុងបណ្តាញរងផ្សេងៗគ្នា។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញតាមគំនិត ខ្ញុំនឹងមិននិយាយលម្អិតទេ។

វាប្រែថានៅពេលបញ្ជូនកញ្ចប់ព័ត៌មាននីមួយៗនោះម៉ាស៊ីនមេប្រែទៅជាសេវាកម្មគូសផែនទី។ តើធ្វើដូចម្តេចដើម្បីដោះស្រាយជាមួយនឹងការពន្យារពេលដែលជៀសមិនរួច? ឃ្លាំងសម្ងាត់, ពិតប្រាកដ​ណាស់។

ភាពស្រស់ស្អាតគឺថាអ្នកមិនចាំបាច់ដាក់ឃ្លាំងសម្ងាត់តារាងដ៏ធំទាំងមូលនោះទេ។ ម៉ាស៊ីនមេរាងកាយផ្ទុកម៉ាស៊ីននិម្មិតពី VPCs មួយចំនួនតូច។ អ្នកគ្រាន់តែត្រូវការរក្សាទុកព័ត៌មានអំពី VPCs ទាំងនេះប៉ុណ្ណោះ។ ការផ្ទេរទិន្នន័យទៅ VPC ផ្សេងទៀតនៅក្នុងការកំណត់ "លំនាំដើម" នៅតែមិនស្របច្បាប់។ ប្រសិនបើមុខងារដូចជា VPC-peering ត្រូវបានប្រើ នោះព័ត៌មានអំពី VPCs ដែលត្រូវគ្នាត្រូវបានផ្ទុកបន្ថែមទៅក្នុងឃ្លាំងសម្ងាត់។ 

យើងបានតម្រៀបការផ្ទេរទិន្នន័យទៅ VPC ។

Blackfoot

អ្វីដែលត្រូវធ្វើក្នុងករណីដែលចរាចរណ៍ត្រូវការបញ្ជូនពីខាងក្រៅ ឧទាហរណ៍ទៅអ៊ីនធឺណិត ឬតាមរយៈ VPN ទៅដី? ជួយយើងនៅទីនេះ Blackfoot - សេវាកម្មផ្ទៃក្នុង AWS ។ វាត្រូវបានបង្កើតឡើងដោយក្រុមអាហ្វ្រិកខាងត្បូងរបស់យើង។ នោះហើយជាមូលហេតុដែលសេវាកម្មនេះត្រូវបានដាក់ឈ្មោះតាមសត្វភេនឃ្វីនដែលរស់នៅក្នុងប្រទេសអាហ្វ្រិកខាងត្បូង។

Blackfoot decapsulates ចរាចរណ៍ និងធ្វើអ្វីដែលចាំបាច់ជាមួយវា។ ទិន្នន័យ​ត្រូវ​បាន​បញ្ជូន​ទៅ​អ៊ីនធឺណិត​ដូច​ដែល​មាន។

ទិន្នន័យ​ត្រូវ​បាន​កាត់​ចេញ និង​រុំ​ឡើង​វិញ​ក្នុង IPsec ពេល​ប្រើ VPN។

នៅពេលប្រើ Direct Connect ចរាចរណ៍ត្រូវបានដាក់ស្លាក និងផ្ញើទៅកាន់ VLAN ដែលសមស្រប។

យន្តហោះ HyperPlan

នេះគឺជាសេវាកម្មត្រួតពិនិត្យលំហូរខាងក្នុង។ សេវាបណ្តាញជាច្រើនទាមទារការត្រួតពិនិត្យ ស្ថានភាពលំហូរទិន្នន័យ. ឧទាហរណ៍ នៅពេលប្រើ NAT ការគ្រប់គ្រងលំហូរត្រូវតែធានាថា IP: ច្រកគោលដៅនីមួយៗមានច្រកចេញតែមួយគត់។ ក្នុងករណីមានតុល្យភាព NLB - ឧបករណ៍តុល្យភាពផ្ទុកបណ្តាញលំហូរទិន្នន័យគួរតែត្រូវបានដឹកនាំទៅកាន់ម៉ាស៊ីននិម្មិតគោលដៅដូចគ្នាជានិច្ច។ ក្រុមសន្តិសុខគឺជាជញ្ជាំងភ្លើងដែលមានរដ្ឋ។ វាត្រួតពិនិត្យចរាចរណ៍ចូល និងបើកច្រកសម្រាប់លំហូរកញ្ចប់ព័ត៌មានចេញ។

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

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

Hyperplane គឺជាប្រព័ន្ធចែកចាយនៃចំនួនដ៏ច្រើននៃម៉ាស៊ីន EC2 បែបនេះ។ ម៉ាស៊ីននិម្មិតនីមួយៗមានកម្រិតបញ្ជូន 5 GB/s ។ នៅទូទាំងបណ្តាញក្នុងតំបន់ទាំងមូល វាផ្តល់នូវកម្រិតបញ្ជូនមិនគួរឱ្យជឿ terabits និងអនុញ្ញាតឱ្យដំណើរការ ការតភ្ជាប់រាប់លានក្នុងមួយវិនាទី.

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

អ្នកជិតខាងដែលរំខាន

នៅតែមានបញ្ហា អ្នកជិតខាងដែលរំខាន - អ្នកជិតខាងដែលរំខាន. ឧបមាថាយើងមាន 8 nodes ។ ថ្នាំងទាំងនេះដំណើរការលំហូរនៃអ្នកប្រើប្រាស់ពពកទាំងអស់។ អ្វីគ្រប់យ៉ាងហាក់ដូចជាល្អ ហើយបន្ទុកគួរតែត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំងថ្នាំងទាំងអស់។ ថ្នាំងមានថាមពលខ្លាំង ហើយវាពិបាកក្នុងការផ្ទុកលើសទម្ងន់។

ប៉ុន្តែយើងសាងសង់ស្ថាបត្យកម្មរបស់យើងដោយផ្អែកលើសេណារីយ៉ូដែលមិនទំនង។ 

ប្រូបាប៊ីលីតេទាបមិនមានន័យថាមិនអាចទៅរួចនោះទេ។

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

តើធ្វើដូចម្តេចដើម្បីដោះស្រាយបញ្ហាអ្នកជិតខាងដែលរំខាន? រឿងដំបូងដែលចូលមកក្នុងគំនិតគឺការបំបែក។ ថ្នាំងទាំង 8 របស់យើងត្រូវបានបែងចែកតាមបែបឡូជីខលជា 4 shards នៃ 2 nodes នីមួយៗ។ ឥឡូវនេះអ្នកជិតខាងដែលមានសំលេងរំខាននឹងរំខានតែមួយភាគបួននៃអ្នកប្រើប្រាស់ទាំងអស់ប៉ុន្តែវានឹងរំខានពួកគេយ៉ាងខ្លាំង។

ចូរ​ធ្វើ​អ្វី​ផ្សេង​គ្នា​។ យើងនឹងបែងចែកតែ 3 nodes ដល់អ្នកប្រើប្រាស់ម្នាក់ៗ។ 

ល្បិចគឺដើម្បីកំណត់ថ្នាំងដោយចៃដន្យដល់អ្នកប្រើប្រាស់ផ្សេងគ្នា។ នៅក្នុងរូបភាពខាងក្រោម អ្នកប្រើប្រាស់ពណ៌ខៀវកំពុងប្រសព្វថ្នាំងជាមួយនឹងអ្នកប្រើប្រាស់ពីរនាក់ផ្សេងទៀត - ពណ៌បៃតង និងពណ៌ទឹកក្រូច។

ជាមួយនឹង 8 ថ្នាំង និងអ្នកប្រើប្រាស់ 3 នាក់ ប្រូបាប៊ីលីតេនៃអ្នកជិតខាងដែលមានសំលេងរំខានដែលប្រសព្វជាមួយអ្នកប្រើប្រាស់ម្នាក់ក្នុងចំណោមអ្នកប្រើប្រាស់គឺ 54% ។ វាគឺជាមួយនឹងប្រូបាប៊ីលីតេនេះដែលអ្នកប្រើប្រាស់ពណ៌ខៀវនឹងមានឥទ្ធិពលលើអ្នកជួលផ្សេងទៀត។ ក្នុងពេលជាមួយគ្នានេះមានតែផ្នែកមួយនៃបន្ទុករបស់វា។ ក្នុងឧទាហរណ៍របស់យើង ឥទ្ធិពលនេះនឹងមានយ៉ាងហោចណាស់គួរឱ្យកត់សម្គាល់ចំពោះអ្នកគ្រប់គ្នា ប៉ុន្តែសម្រាប់តែមួយភាគបីនៃអ្នកប្រើប្រាស់ទាំងអស់។ នេះជាលទ្ធផលល្អរួចទៅហើយ។

ចំនួនអ្នកប្រើប្រាស់ដែលនឹងប្រសព្វ

ប្រូបាប៊ីលីតេគិតជាភាគរយ

0

18%

1

54%

2

26%

3

2%

ចូរយើងនាំស្ថានការណ៍កាន់តែខិតទៅជិតការពិត - ចូរយើងយក 100 nodes និងអ្នកប្រើប្រាស់ 5 នាក់នៅលើ 5 nodes ។ ក្នុងករណីនេះ គ្មានថ្នាំងណាមួយនឹងប្រសព្វគ្នាជាមួយនឹងប្រូបាប៊ីលីតេ 77% នោះទេ។ 

ចំនួនអ្នកប្រើប្រាស់ដែលនឹងប្រសព្វ

ប្រូបាប៊ីលីតេគិតជាភាគរយ

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

នៅក្នុងស្ថានភាពជាក់ស្តែង ជាមួយនឹងចំនួនដ៏ច្រើននៃ HyperPlane nodes និងអ្នកប្រើប្រាស់ ផលប៉ះពាល់សក្តានុពលនៃអ្នកជិតខាងដែលរំខានដល់អ្នកប្រើប្រាស់ផ្សេងទៀតគឺតិចតួចបំផុត។ វិធីសាស្រ្តនេះត្រូវបានគេហៅថា លាយ sharding - shuffle sharding. វាកាត់បន្ថយផលប៉ះពាល់អវិជ្ជមាននៃការបរាជ័យថ្នាំង។

សេវាកម្មជាច្រើនត្រូវបានបង្កើតឡើងដោយផ្អែកលើ HyperPlane៖ Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway។

មាត្រដ្ឋានបណ្តាញ

ឥឡូវនេះសូមនិយាយអំពីមាត្រដ្ឋាននៃបណ្តាញខ្លួនឯង។ សម្រាប់ខែតុលា ឆ្នាំ 2019 AWS ផ្តល់សេវាកម្មរបស់ខ្លួននៅក្នុង 22 តំបន់និង ៩ ទៀតត្រូវបានគ្រោងទុក។

• តំបន់នីមួយៗមានតំបន់ដែលមានស្រាប់ជាច្រើន។ មាន 69 ក្នុងចំណោមពួកគេនៅជុំវិញពិភពលោក។
• AZ នីមួយៗមានមជ្ឈមណ្ឌលដំណើរការទិន្នន័យ។ សរុបទាំងអស់មិនលើសពី ៨ ទេ។
• មជ្ឈមណ្ឌលទិន្នន័យផ្ទុកនូវចំនួនដ៏ច្រើននៃម៉ាស៊ីនមេ ដែលខ្លះមានរហូតដល់ 300។

ឥឡូវនេះ ចូរយើងជាមធ្យមទាំងអស់នេះ គុណ និងទទួលបានតួលេខគួរឱ្យចាប់អារម្មណ៍ដែលឆ្លុះបញ្ចាំង មាត្រដ្ឋានពពក Amazon.

មានតំណភ្ជាប់អុបទិកជាច្រើនរវាង Availability Zones និងមជ្ឈមណ្ឌលទិន្នន័យ។ នៅក្នុងតំបន់ដ៏ធំបំផុតមួយរបស់យើង បណ្តាញចំនួន 388 ត្រូវបានដាក់សម្រាប់ការទំនាក់ទំនង AZ រវាងគ្នាទៅវិញទៅមក និងមជ្ឈមណ្ឌលទំនាក់ទំនងជាមួយតំបន់ផ្សេងទៀត (មជ្ឈមណ្ឌលឆ្លងកាត់) ។ សរុបមកនេះធ្វើឱ្យឆ្កួត 5000 Tbit.

Backbone AWS ត្រូវបានបង្កើតឡើងជាពិសេសសម្រាប់ និងធ្វើឱ្យប្រសើរសម្រាប់ពពក។ យើងបង្កើតវានៅលើប៉ុស្តិ៍ ២៥៦ ជីកាបៃ / វិនាទី. យើងគ្រប់គ្រងពួកគេទាំងស្រុង លើកលែងតែតំបន់នៅក្នុងប្រទេសចិន។ ចរាចរណ៍មិនត្រូវបានចែករំលែកជាមួយបន្ទុករបស់ក្រុមហ៊ុនផ្សេងទៀតទេ។

ជាការពិតណាស់ យើងមិនមែនជាអ្នកផ្តល់សេវាពពកតែមួយគត់ដែលមានបណ្តាញឆ្អឹងខ្នងឯកជននោះទេ។ ក្រុមហ៊ុនធំៗកាន់តែច្រើនកំពុងដើរតាមគន្លងនេះ។ នេះត្រូវបានបញ្ជាក់ដោយអ្នកស្រាវជ្រាវឯករាជ្យឧទាហរណ៍ពី ទូរគមនាគមន៍.

ក្រាហ្វបង្ហាញថាចំណែកនៃអ្នកផ្តល់មាតិកានិងអ្នកផ្តល់ពពកកំពុងកើនឡើង។ ដោយសារតែនេះចំណែកនៃចរាចរអ៊ីនធឺណិតរបស់អ្នកផ្តល់សេវាឆ្អឹងខ្នងកំពុងថយចុះឥតឈប់ឈរ។

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

ខ្ញុំឆ្ងល់ថាតើអ៊ិនធឺណិតនឹងផ្លាស់ប្តូរយ៉ាងដូចម្តេចក្នុងរយៈពេល 10 ឆ្នាំប្រសិនបើនិន្នាការនេះនៅតែបន្ត?

បណ្តាញរាងកាយ

អ្នកវិទ្យាសាស្ត្រមិនទាន់បានគិតពីរបៀបបង្កើនល្បឿននៃពន្លឺនៅក្នុងសកលលោកនៅឡើយទេ ប៉ុន្តែពួកគេបានរីកចម្រើនយ៉ាងខ្លាំងនៅក្នុងវិធីសាស្រ្តនៃការបញ្ជូនវាតាមរយៈសរសៃអុបទិក។ បច្ចុប្បន្នយើងប្រើប្រាស់ខ្សែកាបអុបទិកចំនួន 6912 ។ នេះជួយបង្កើនប្រសិទ្ធភាពយ៉ាងខ្លាំងនូវតម្លៃនៃការដំឡើងរបស់ពួកគេ។

នៅតំបន់ខ្លះយើងត្រូវប្រើខ្សែពិសេស។ ជាឧទាហរណ៍ នៅតំបន់ស៊ីដនី យើងប្រើខ្សែកាបដែលមានថ្នាំកូតប្រឆាំងនឹងមេរោគពិសេស។ 

គ្មាន​នរណា​ម្នាក់​មាន​ភាពស៊ាំ​ពី​បញ្ហា​ឡើយ ហើយ​ពេល​ខ្លះ​ឆានែល​របស់​យើង​ត្រូវ​បាន​ខូច។ រូបថតនៅខាងស្តាំបង្ហាញពីខ្សែកាបអុបទិកនៅក្នុងតំបន់មួយនៃអាមេរិកដែលត្រូវបានរហែកដោយកម្មករសំណង់។ ជាលទ្ធផលនៃគ្រោះថ្នាក់នេះមានតែកញ្ចប់ទិន្នន័យចំនួន 13 ត្រូវបានបាត់បង់ដែលគួរឱ្យភ្ញាក់ផ្អើល។ ម្តងទៀត - មានតែ 13 ប៉ុណ្ណោះ! ប្រព័ន្ធបានប្តូរទៅបណ្តាញបម្រុងទុកភ្លាមៗ - មាត្រដ្ឋានកំពុងដំណើរការ។

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

នេះគឺជាផ្នែកចុងក្រោយនៃត្រីភាគីពី Vasily Pantyukhin អំពីឧបករណ៍ AWS ។ IN ដំបូង ផ្នែកពិពណ៌នាអំពីការបង្កើនប្រសិទ្ធភាពម៉ាស៊ីនមេ និងការធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យ និងនៅក្នុង ទីពីរ - មុខងារគ្មានម៉ាស៊ីនមេ និង Firecracker ។

នៅលើ ការផ្ទុកខ្ពស់ ++ នៅក្នុងខែវិច្ឆិកា Vasily Pantyukhin នឹងចែករំលែកព័ត៌មានលម្អិតថ្មីនៃឧបករណ៍ Amazon ។ គាត់ នឹងប្រាប់ អំពីមូលហេតុនៃការបរាជ័យ និងការរចនាប្រព័ន្ធចែកចាយនៅ Amazon ។ ថ្ងៃទី 24 ខែតុលានៅតែអាចធ្វើទៅបាន កក់​ទុក សំបុត្រក្នុងតម្លៃសមរម្យ ហើយបង់ពេលក្រោយ។ យើងកំពុងរង់ចាំអ្នកនៅ HighLoad++ មកជជែកគ្នាលេង!

ប្រភព: www.habr.com