របៀបដែល Yandex.Cloud ដំណើរការជាមួយ Virtual Private Cloud និងរបៀបដែលអ្នកប្រើប្រាស់របស់យើងជួយយើងអនុវត្តមុខងារមានប្រយោជន៍

ជំរាបសួរ ឈ្មោះរបស់ខ្ញុំគឺ Kostya Kramlikh ខ្ញុំជាអ្នកអភិវឌ្ឍន៍ឈានមុខគេនៃផ្នែក Virtual Private Cloud នៅក្នុង Yandex.Cloud ។ ខ្ញុំជាអ្នកបង្កើតបណ្តាញនិម្មិត ហើយដូចដែលអ្នកប្រហែលជាស្មាននៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងនិយាយអំពីឧបករណ៍ Virtual Private Cloud (VPC) ជាទូទៅ និងបណ្តាញនិម្មិតជាពិសេស។ ហើយ​អ្នក​ក៏​នឹង​រក​ឃើញ​ផង​ដែរ​ថា​ហេតុ​អ្វី​បាន​ជា​យើង​ដែល​ជា​អ្នក​បង្កើត​សេវាកម្ម​ផ្តល់​តម្លៃ​មតិ​ត្រឡប់​ពី​អ្នក​ប្រើ​របស់​យើង។ ប៉ុន្តែរឿងដំបូង។

តើ VPC ជាអ្វី?

សព្វថ្ងៃនេះ មានជម្រើសជាច្រើនសម្រាប់ដាក់ពង្រាយសេវាកម្ម។ ខ្ញុំប្រាកដថានរណាម្នាក់នៅតែរក្សាម៉ាស៊ីនមេនៅក្រោមតុរបស់អ្នកគ្រប់គ្រង ទោះបីជាខ្ញុំសង្ឃឹមថាមានរឿងបែបនេះតិចជាងនេះក៏ដោយ។

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

តើបណ្តាញនិម្មិតមើលទៅដូចអ្វីពីខាងក្រៅ?

តាម VPC យើងមានន័យថាជាចម្បងបណ្តាញត្រួតលើគ្នា និងសេវាបណ្តាញដូចជា VPNaaS, NATaas, LBaas ជាដើម។ ហើយទាំងអស់នេះដំណើរការលើហេដ្ឋារចនាសម្ព័ន្ធបណ្តាញដែលអត់ឱនចំពោះកំហុស ដែលធ្លាប់មានរួចហើយ។ អត្ថបទអស្ចារ្យ នៅទីនេះនៅលើ Habre ។

សូមក្រឡេកមើលបណ្តាញនិម្មិត និងឧបករណ៍របស់វា។

ពិចារណាតំបន់ដែលអាចរកបានពីរ។ យើងផ្តល់បណ្តាញនិម្មិត - អ្វីដែលគេហៅថា VPC ។ តាមពិត វាកំណត់ចន្លោះនៃភាពប្លែកនៃអាសយដ្ឋាន "ពណ៌ប្រផេះ" របស់អ្នក។ នៅក្នុងបណ្តាញនិម្មិតនីមួយៗ អ្នកមានការគ្រប់គ្រងពេញលេញលើទំហំអាសយដ្ឋាន ដែលអ្នកអាចកំណត់ដើម្បីគណនាធនធាន។

បណ្តាញគឺសកល។ ក្នុងពេលជាមួយគ្នានេះ វាត្រូវបានព្យាករលើតំបន់ដែលអាចរកបាននីមួយៗក្នុងទម្រង់ជាអង្គភាពដែលហៅថា Subnet។ សម្រាប់ Subnet នីមួយៗ អ្នកកំណត់ CIDR ទំហំ 16 ឬតិចជាងនេះ។ វាអាចមានអង្គភាពបែបនេះច្រើនជាងមួយនៅក្នុងតំបន់ដែលអាចរកបាននីមួយៗ ហើយតែងតែមានផ្លូវតម្លាភាពរវាងពួកវា។ នេះមានន័យថាធនធានរបស់អ្នកទាំងអស់នៅក្នុង VPC តែមួយអាច "និយាយ" គ្នាទៅវិញទៅមក ទោះបីជាវាស្ថិតនៅក្នុងតំបន់ដែលមានផ្សេងៗគ្នាក៏ដោយ។ "ទំនាក់ទំនង" ដោយមិនចាំបាច់ចូលប្រើអ៊ីនធឺណិត តាមរយៈបណ្តាញខាងក្នុងរបស់យើង "គិត" ថាពួកគេស្ថិតនៅក្នុងបណ្តាញឯកជនដូចគ្នា។

ដ្យាក្រាមខាងលើបង្ហាញពីស្ថានភាពធម្មតា៖ VPCs ពីរដែលប្រសព្វគ្នានៅកន្លែងណាមួយក្នុងអាសយដ្ឋាន។ ទាំងពីរអាចជារបស់អ្នក។ ឧទាហរណ៍ មួយសម្រាប់ការអភិវឌ្ឍន៍ មួយទៀតសម្រាប់សាកល្បង។ ប្រហែលជាមានអ្នកប្រើប្រាស់ផ្សេងគ្នា - ក្នុងករណីនេះវាមិនមានបញ្ហាទេ។ ហើយម៉ាស៊ីននិម្មិតមួយត្រូវបានដោតចូលទៅក្នុង VPC នីមួយៗ។

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

ក្នុងពេលជាមួយគ្នានេះ ប្រសិនបើអ្នកត្រូវការបង្ហាញម៉ាស៊ីនទៅអ៊ីនធឺណិត នេះអាចត្រូវបានធ្វើតាមរយៈ API ឬ UI ។ ដើម្បីធ្វើដូចនេះអ្នកត្រូវកំណត់រចនាសម្ព័ន្ធការបកប្រែ NAT នៃ "ពណ៌ប្រផេះ" អាសយដ្ឋានខាងក្នុងរបស់អ្នកទៅជា "ស" - សាធារណៈ។ អ្នកមិនអាចជ្រើសរើសអាសយដ្ឋាន "ស" បានទេ វាត្រូវបានផ្តល់ដោយចៃដន្យពីក្រុមអាសយដ្ឋានរបស់យើង។ ដរាបណាអ្នកឈប់ប្រើ IP ខាងក្រៅ វាត្រូវបានត្រលប់ទៅអាងវិញ។ អ្នកចំណាយសម្រាប់តែពេលប្រើប្រាស់អាសយដ្ឋាន "ស" ប៉ុណ្ណោះ។

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

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

របៀបដែលបណ្តាញនិម្មិតត្រូវបានរៀបចំពីខាងក្នុង

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

យើងសរសេរស្ថានភាពដែលចង់បានទៅមូលដ្ឋានទិន្នន័យ Yandex ហើយចូលទៅកំណត់រចនាសម្ព័ន្ធផ្នែកផ្សេងៗនៃ VPC របស់យើង។ បណ្តាញត្រួតលើគ្នានៅក្នុង Yandex.Cloud គឺផ្អែកលើសមាសធាតុដែលបានជ្រើសរើសរបស់ OpenContrail ដែលថ្មីៗនេះត្រូវបានគេហៅថា Tungsten Fabric ។ សេវាបណ្តាញត្រូវបានអនុវត្តនៅលើវេទិកា CloudGate តែមួយ។ នៅក្នុង CloudGate យើងក៏បានប្រើសមាសធាតុប្រភពបើកចំហមួយចំនួនផងដែរ៖ GoBGP - ដើម្បីចូលប្រើព័ត៌មានគ្រប់គ្រង ក៏ដូចជា VPP - ដើម្បីអនុវត្តរ៉ោតទ័រកម្មវិធីដែលដំណើរការនៅលើកំពូលនៃ DPDK សម្រាប់ផ្លូវទិន្នន័យ។

Tungsten Fabric ទំនាក់ទំនងជាមួយ CloudGate តាមរយៈ GoBGP ។ ប្រាប់ពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងបណ្តាញត្រួតលើគ្នា។ នៅក្នុងវេន CloudGate ភ្ជាប់បណ្តាញត្រួតលើគ្នា និងជាមួយអ៊ីនធឺណិត។

ឥឡូវនេះសូមមើលពីរបៀបដែលបណ្តាញនិម្មិតដោះស្រាយបញ្ហានៃការធ្វើមាត្រដ្ឋាន និងភាពអាចរកបាន។ ចូរយើងពិចារណាករណីសាមញ្ញមួយ។ មានតំបន់ដែលអាចរកបានមួយ ហើយ VPCs ពីរត្រូវបានបង្កើតឡើងនៅក្នុងវា។ យើង​បាន​ដាក់​ពង្រាយ​ឧទាហរណ៍ Tungsten Fabric មួយ ហើយ​វា​ទាញ​បាន​បណ្តាញ​រាប់ម៉ឺន​បណ្តាញ។ បណ្តាញទំនាក់ទំនងជាមួយ CloudGate ។ ដូចដែលយើងបាននិយាយរួចមកហើយថា CloudGate ធានានូវការតភ្ជាប់របស់ពួកគេជាមួយគ្នាទៅវិញទៅមក និងជាមួយអ៊ីនធឺណិត។

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

VPC1 ត្រូវបានគូសផែនទីទៅ Availability Zone B ប្រសិនបើមានធនធាននៅក្នុង Availability Zone B ដែលត្រូវបានរុញទៅ VPC1។ ប្រសិនបើមិនមានធនធានពី VPC2 នៅក្នុងតំបន់ដែលអាចរកបាន B ទេ យើងនឹងមិនបង្កើត VPC2 នៅក្នុងតំបន់នេះទេ។ នៅក្នុងវេន ចាប់តាំងពីធនធានពី VPC3 មាននៅក្នុងតំបន់ B តែប៉ុណ្ណោះ VPC3 មិនមាននៅក្នុងតំបន់ A។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញ និងឡូជីខល។

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

ប្រសិនបើយើងក្រឡេកមើលម៉ាស៊ីនជាក់លាក់មួយ យើងអាចឃើញថាមានសមាសភាគបីដែលដំណើរការលើម៉ាស៊ីន OS៖

• Compute - ផ្នែកដែលទទួលខុសត្រូវចំពោះការចែកចាយធនធានកុំព្យូទ័រនៅលើម៉ាស៊ីន។
• VRouter គឺ​ជា​ផ្នែក​មួយ​នៃ​ក្រណាត់ Tungsten ដែល​រៀបចំ​ការ​ត្រួត​គ្នា ពោល​គឺ​វា​កាត់​កញ្ចប់​ព័ត៌មាន​តាម​រយៈ​ស្រទាប់​ក្រោម។
• VDisks គឺជាផ្នែកនៃទំហំផ្ទុកនិម្មិត។

លើសពីនេះទៀត សេវាកម្មត្រូវបានដាក់ឱ្យដំណើរការនៅក្នុងម៉ាស៊ីននិម្មិត៖ សេវាហេដ្ឋារចនាសម្ព័ន្ធពពក សេវាកម្មវេទិកា និងសមត្ថភាពរបស់អតិថិជន។ សមត្ថភាពរបស់អតិថិជន និងសេវាកម្មវេទិកាតែងតែទៅជាន់លើតាមរយៈ VRouter ។

សេវា​ហេដ្ឋារចនាសម្ព័ន្ធ​អាច​ជាប់​ក្នុង​ការ​ត្រួត​គ្នា ប៉ុន្តែ​ជា​មូលដ្ឋាន​ពួកគេ​ចង់​ធ្វើ​ការ​នៅ​ផ្នែក​ខាង​ក្រោម។ ពួកគេត្រូវបានជាប់គាំងនៅក្នុងស្រទាប់ខាងក្រោមដោយមានជំនួយពី SR-IOV ។ ជាការពិត យើងបានកាត់កាតទៅជាកាតបណ្តាញនិម្មិត (មុខងារនិម្មិត) ហើយរុញវាចូលទៅក្នុងម៉ាស៊ីននិម្មិតហេដ្ឋារចនាសម្ព័ន្ធ ដើម្បីកុំឱ្យបាត់បង់ដំណើរការ។ ឧទាហរណ៍ CloudGate ដូចគ្នាត្រូវបានបើកដំណើរការជាម៉ាស៊ីននិម្មិតហេដ្ឋារចនាសម្ព័ន្ធមួយក្នុងចំណោមម៉ាស៊ីននិម្មិតទាំងនេះ។

ឥឡូវនេះយើងបានពណ៌នាអំពីភារកិច្ចសកលនៃបណ្តាញនិម្មិត និងរចនាសម្ព័ន្ធនៃធាតុផ្សំជាមូលដ្ឋាននៃពពក សូមមើលពីរបៀបដែលផ្នែកផ្សេងៗនៃបណ្តាញនិម្មិតមានទំនាក់ទំនងគ្នាទៅវិញទៅមក។

យើងបែងចែកស្រទាប់បីនៅក្នុងប្រព័ន្ធរបស់យើង:

• Config Plane - កំណត់ស្ថានភាពគោលដៅនៃប្រព័ន្ធ។ នេះគឺជាអ្វីដែលអ្នកប្រើកំណត់រចនាសម្ព័ន្ធតាមរយៈ API ។
• Control Plane - ផ្តល់នូវអត្ថន័យដែលកំណត់ដោយអ្នកប្រើប្រាស់ ពោលគឺនាំស្ថានភាព Data Plane ទៅនឹងអ្វីដែលត្រូវបានពិពណ៌នាដោយអ្នកប្រើប្រាស់នៅក្នុង Config Plane ។
• Data Plane - ដំណើរការដោយផ្ទាល់នូវកញ្ចប់ព័ត៌មានរបស់អ្នកប្រើប្រាស់។

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

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

Config Plane នៅក្នុង Tungsten Fabric បញ្ជូនស្ថានភាពដែលត្រូវការទៅកាន់ Control Plane ។ តាមរយៈវា Config Plane ទាក់ទងជាមួយ hosts ដោយប្រាប់ពីអ្វីដែលនឹងកើតឡើងក្នុងពេលឆាប់ៗនេះ។

ឥឡូវនេះសូមមើលពីរបៀបដែលប្រព័ន្ធមើលទៅលើម៉ាស៊ីន។ ម៉ាស៊ីននិម្មិតមានអាដាប់ទ័របណ្តាញដែលដោតចូលទៅក្នុង VRouter ។ VRouter គឺជាម៉ូឌុលស្នូលក្រណាត់ Tungsten ដែលមើលទៅលើកញ្ចប់ព័ត៌មាន។ ប្រសិនបើមានលំហូរសម្រាប់កញ្ចប់មួយចំនួនរួចហើយ ម៉ូឌុលដំណើរការវា។ ប្រសិនបើមិនមានលំហូរទេ ម៉ូឌុលធ្វើអ្វីដែលហៅថា punting ពោលគឺវាផ្ញើកញ្ចប់ព័ត៌មានទៅកាន់ដំណើរការ usermod ។ ដំណើរការញែកកញ្ចប់ព័ត៌មាន ហើយឆ្លើយតបទៅវាដោយខ្លួនឯង ដូចជា DHCP និង DNS ឬប្រាប់ VRouter អ្វីដែលត្រូវធ្វើជាមួយវា។ បន្ទាប់ពីនោះ VRouter អាចដំណើរការកញ្ចប់ព័ត៌មាន។

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

Control Planes ទាក់ទងគ្នាទៅវិញទៅមករវាងតំបន់ដែលអាចរកបានតាមរយៈ BGP ដូចជាជាមួយរ៉ោតទ័រផ្សេងទៀត។ ពួកគេ​ប្រាប់​ថា​ម៉ាស៊ីន​ណា​ខ្លះ​នៅ​កន្លែង​ណា​ ទើប​ VMs ក្នុង​តំបន់​មួយ​អាច​ទំនាក់ទំនង​ផ្ទាល់​ជាមួយ​ VMs ផ្សេងទៀត។

ហើយ Control Plane ទាក់ទងជាមួយ CloudGate ។ ស្រដៀងគ្នានេះដែរ វារាយការណ៍ពីកន្លែង និងម៉ាស៊ីននិម្មិតណាដែលត្រូវបានលើកឡើង អាសយដ្ឋានអ្វីដែលពួកគេមាន។ នេះអនុញ្ញាតឱ្យអ្នកដឹកនាំចរាចរខាងក្រៅនិងចរាចរពីតុល្យភាពទៅពួកគេ។

ចរាចរណ៍ដែលចាកចេញពី VPC មកដល់ CloudGate ទៅកាន់ផ្លូវទិន្នន័យ ដែល VPP ជាមួយនឹងកម្មវិធីជំនួយរបស់យើងត្រូវបានទំពារយ៉ាងលឿន។ បន្ទាប់មកចរាចរត្រូវបានបញ្ឆេះទៅកាន់ VPCs ផ្សេងទៀតឬនៅខាងក្រៅទៅកាន់រ៉ោតទ័រព្រំដែនដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមរយៈ Control Plane នៃ CloudGate ខ្លួនវាផ្ទាល់។

ផែនការសម្រាប់អនាគតដ៏ខ្លីខាងមុខនេះ

ប្រសិនបើយើងសង្ខេបអ្វីគ្រប់យ៉ាងដែលបាននិយាយខាងលើក្នុងប្រយោគមួយចំនួន យើងអាចនិយាយបានថា VPC នៅក្នុង Yandex.Cloud ដោះស្រាយកិច្ចការសំខាន់ពីរ៖

• ផ្តល់ភាពឯកោរវាងអតិថិជនផ្សេងៗគ្នា។
• រួមបញ្ចូលគ្នានូវធនធាន ហេដ្ឋារចនាសម្ព័ន្ធ សេវាកម្មវេទិកា ពពកផ្សេងទៀត និងនៅក្នុងបរិវេណទៅក្នុងបណ្តាញតែមួយ។

ហើយដើម្បីដោះស្រាយបញ្ហាទាំងនេះឱ្យបានល្អ អ្នកត្រូវផ្តល់នូវភាពធន់ និងការអត់ធ្មត់ចំពោះកំហុសនៅកម្រិតនៃស្ថាបត្យកម្មផ្ទៃក្នុងដែល VPC ធ្វើ។

បន្តិចម្តង VPC ទទួលបានមុខងារ យើងអនុវត្តមុខងារថ្មីៗ យើងព្យាយាមកែលម្អអ្វីមួយទាក់ទងនឹងភាពងាយស្រួលរបស់អ្នកប្រើប្រាស់។ គំនិតមួយចំនួនត្រូវបានបញ្ចេញ និងទទួលបាននៅក្នុងបញ្ជីអាទិភាព សូមអរគុណដល់សមាជិកនៃសហគមន៍របស់យើង។

បច្ចុប្បន្ននេះ យើងមានបញ្ជីនៃផែនការសម្រាប់អនាគតដ៏ខ្លីខាងមុខនេះ៖

• VPN ជាសេវាកម្ម។
• វត្ថុ DNS ឯកជនគឺជារូបភាពសម្រាប់ដំឡើងម៉ាស៊ីននិម្មិតយ៉ាងឆាប់រហ័សជាមួយនឹងម៉ាស៊ីនមេ DNS ដែលបានកំណត់ទុកជាមុន។
• DNS ជាសេវាកម្ម។
• ឧបករណ៍តុល្យភាពបន្ទុកខាងក្នុង។
• ការបន្ថែមអាសយដ្ឋាន IP "ពណ៌ស" ដោយមិនចាំបាច់បង្កើតម៉ាស៊ីននិម្មិតឡើងវិញ។

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

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

មានអារម្មណ៍សេរីក្នុងការបញ្ចេញមតិរបស់អ្នក។ គំនិត និងយោបល់គាំទ្រ អ្នកប្រើប្រាស់ផ្សេងទៀត។ អ្នកជួយយើងធ្វើឱ្យ Cloud កាន់តែប្រសើរឡើង និងទទួលបានមុខងារសំខាន់ៗ និងមានប្រយោជន៍លឿនជាងមុន!

ប្រភព: www.habr.com