Yandex.Cloud ເຮັດວຽກແນວໃດກັບ Virtual Private Cloud ແລະວິທີທີ່ຜູ້ໃຊ້ຂອງພວກເຮົາຊ່ວຍພວກເຮົາປະຕິບັດຄຸນສົມບັດທີ່ເປັນປະໂຫຍດ

ສະບາຍດີ, ຂ້ອຍຊື່ Kostya Kramlich, ຂ້ອຍເປັນຜູ້ພັດທະນາຊັ້ນນໍາຂອງພະແນກ Virtual Private Cloud ຢູ່ Yandex.Cloud. ຂ້ອຍກໍາລັງເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍ virtual, ແລະ, ຕາມທີ່ເຈົ້າອາດຈະຄາດເດົາ, ໃນບົດຄວາມນີ້ຂ້ອຍຈະເວົ້າກ່ຽວກັບອຸປະກອນ Virtual Private Cloud (VPC) ໂດຍທົ່ວໄປແລະເຄືອຂ່າຍ virtual ໂດຍສະເພາະ. ແລະທ່ານຍັງຈະຊອກຫາວ່າເປັນຫຍັງພວກເຮົາ, ຜູ້ພັດທະນາການບໍລິການ, ຄວາມຄິດເຫັນທີ່ມີຄຸນຄ່າຈາກຜູ້ໃຊ້ຂອງພວກເຮົາ. ແຕ່ສິ່ງທໍາອິດທໍາອິດ.

VPC ແມ່ນຫຍັງ?

ປະຈຸ​ບັນ, ມີ​ຫຼາຍ​ທາງ​ເລືອກ​ໃນ​ການ​ນຳ​ໃຊ້​ບໍລິການ. ຂ້ອຍແນ່ໃຈວ່າບາງຄົນຍັງຮັກສາເຄື່ອງແມ່ຂ່າຍພາຍໃຕ້ໂຕະຂອງຜູ້ເບິ່ງແຍງ, ເຖິງແມ່ນວ່າຂ້ອຍຫວັງວ່າເລື່ອງດັ່ງກ່າວກາຍເປັນເລື່ອງທົ່ວໄປຫນ້ອຍລົງ.

ໃນປັດຈຸບັນການບໍລິການກໍາລັງພະຍາຍາມຍ້າຍໄປຢູ່ໃນຄລາວສາທາລະນະ, ແລະນີ້ແມ່ນບ່ອນທີ່ພວກເຂົາພົບກັບ VPCs. VPC ແມ່ນສ່ວນຫນຶ່ງຂອງຄລາວສາທາລະນະທີ່ເຊື່ອມຕໍ່ຜູ້ໃຊ້, ໂຄງສ້າງພື້ນຖານ, ແພລະຕະຟອມແລະຄວາມສາມາດອື່ນໆຮ່ວມກັນ, ບໍ່ວ່າພວກເຂົາຢູ່ໃສ, ໃນ Cloud ຂອງພວກເຮົາຫຼືຫຼາຍກວ່ານັ້ນ. ໃນເວລາດຽວກັນ, VPC ອະນຸຍາດໃຫ້ທ່ານເພື່ອຫຼີກເວັ້ນການເປີດເຜີຍຄວາມສາມາດເຫຼົ່ານີ້ກັບອິນເຕີເນັດໂດຍບໍ່ຈໍາເປັນ; ພວກມັນຍັງຄົງຢູ່ໃນເຄືອຂ່າຍທີ່ໂດດດ່ຽວຂອງທ່ານ.

ສິ່ງທີ່ເຄືອຂ່າຍ virtual ເບິ່ງຄືວ່າຈາກພາຍນອກ

ໂດຍ VPC ພວກເຮົາຫມາຍຄວາມວ່າ, ກ່ອນອື່ນ ໝົດ, ເຄືອຂ່າຍຊ້ອນກັນແລະການບໍລິການເຄືອຂ່າຍ, ເຊັ່ນ VPNaaS, NATaas, LBaas, ແລະອື່ນໆ. ແລະສິ່ງທັງ ໝົດ ນີ້ເຮັດວຽກຢູ່ເທິງໂຄງສ້າງເຄືອຂ່າຍທີ່ທົນທານຕໍ່ຄວາມຜິດ, ເຊິ່ງໄດ້ສົນທະນາແລ້ວ. ບົດຄວາມທີ່ຍິ່ງໃຫຍ່ ທີ່ນີ້ໃນ Habre.

ຂໍໃຫ້ພິຈາລະນາຢ່າງໃກ້ຊິດກ່ຽວກັບເຄືອຂ່າຍ virtual ແລະໂຄງສ້າງຂອງມັນ.

ໃຫ້ເບິ່ງສອງເຂດທີ່ມີ. ພວກເຮົາສະຫນອງເຄືອຂ່າຍ virtual - ສິ່ງທີ່ພວກເຮົາເອີ້ນວ່າ VPC. ໃນຄວາມເປັນຈິງ, ມັນກໍານົດພື້ນທີ່ເປັນເອກະລັກຂອງທີ່ຢູ່ "ສີຂີ້ເຖົ່າ" ຂອງທ່ານ. ພາຍໃນແຕ່ລະເຄືອຂ່າຍ virtual, ທ່ານມີການຄວບຄຸມຢ່າງເຕັມທີ່ກ່ຽວກັບພື້ນທີ່ຂອງທີ່ຢູ່ທີ່ທ່ານສາມາດກໍາຫນົດໃຫ້ຊັບພະຍາກອນຄອມພິວເຕີ.

ເຄືອຂ່າຍແມ່ນທົ່ວໂລກ. ໃນເວລາດຽວກັນ, ມັນຖືກຄາດຄະເນໃສ່ແຕ່ລະເຂດທີ່ມີຢູ່ໃນຮູບແບບຂອງຫນ່ວຍງານທີ່ເອີ້ນວ່າ Subnet. ສໍາລັບແຕ່ລະ Subnet ທ່ານກໍານົດ CIDR ຂອງຂະຫນາດ 16 ຫຼືນ້ອຍກວ່າ. ແຕ່ລະເຂດທີ່ມີໃຫ້ສາມາດມີຫຼາຍກວ່າໜຶ່ງຫົວໜ່ວຍດັ່ງກ່າວ, ແລະມີເສັ້ນທາງທີ່ໂປ່ງໃສລະຫວ່າງພວກມັນສະເໝີ. ນີ້ຫມາຍຄວາມວ່າຊັບພະຍາກອນທັງຫມົດຂອງເຈົ້າພາຍໃນ VPC ດຽວກັນສາມາດ "ສົນທະນາ" ກັບກັນແລະກັນ, ເຖິງແມ່ນວ່າພວກເຂົາຢູ່ໃນເຂດ Availability ທີ່ແຕກຕ່າງກັນ. "ສື່ສານ" ໂດຍບໍ່ມີການເຂົ້າເຖິງອິນເຕີເນັດ, ຜ່ານຊ່ອງທາງພາຍໃນຂອງພວກເຮົາ, "ຄິດ" ວ່າພວກເຂົາຢູ່ໃນເຄືອຂ່າຍເອກະຊົນດຽວກັນ.

ແຜນວາດຂ້າງເທິງສະແດງໃຫ້ເຫັນສະຖານະການປົກກະຕິ: ສອງ VPCs ທີ່ຕັດກັນບາງບ່ອນໃນທີ່ຢູ່ຂອງພວກເຂົາ. ທັງສອງສາມາດເປັນຂອງເຈົ້າ. ຕົວຢ່າງ, ຫນຶ່ງສໍາລັບການພັດທະນາ, ອື່ນສໍາລັບການທົດສອບ. ມັນອາດຈະມີພຽງແຕ່ຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນ - ໃນກໍລະນີນີ້ມັນບໍ່ສໍາຄັນ. ແລະແຕ່ລະ VPC ມີເຄື່ອງ virtual ຫນຶ່ງ.

ຂໍໃຫ້ໂຄງການຮ້າຍແຮງກວ່າເກົ່າ. ທ່ານສາມາດເຮັດໃຫ້ເຄື່ອງ virtual ຫນຶ່ງເຊື່ອມຕໍ່ກັບ Subnets ຫຼາຍຄັ້ງໃນເວລາດຽວກັນ. ແລະບໍ່ພຽງແຕ່ຄືກັນ, ແຕ່ໃນເຄືອຂ່າຍ virtual ທີ່ແຕກຕ່າງກັນ.

ໃນເວລາດຽວກັນ, ຖ້າທ່ານຕ້ອງການເປີດເຜີຍເຄື່ອງຈັກໃນອິນເຕີເນັດ, ນີ້ສາມາດເຮັດໄດ້ໂດຍຜ່ານ API ຫຼື UI. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງກໍານົດການແປພາສາ NAT ຂອງ "ສີຂີ້ເຖົ່າ", ທີ່ຢູ່ພາຍໃນ, ເຂົ້າໄປໃນ "ສີຂາວ" - ທີ່ຢູ່ສາທາລະນະ. ທ່ານ​ບໍ່​ສາ​ມາດ​ເລືອກ​ເອົາ​ທີ່​ຢູ່ "ສີ​ຂາວ​" ໄດ້​; ມັນ​ຖືກ​ມອບ​ຫມາຍ​ໂດຍ​ສຸ່ມ​ຈາກ​ທີ່​ຢູ່​ຂອງ​ພວກ​ເຮົາ​. ທັນທີທີ່ທ່ານຢຸດໃຊ້ IP ພາຍນອກ, ມັນຈະກັບຄືນສູ່ສະນຸກເກີ. ທ່ານຈ່າຍພຽງແຕ່ເວລາທີ່ທ່ານໃຊ້ທີ່ຢູ່ "ສີຂາວ".

ມັນຍັງສາມາດໃຫ້ອິນເຕີເນັດຂອງເຄື່ອງໄດ້ໂດຍໃຊ້ NAT instance. ທ່ານ​ສາ​ມາດ​ກໍາ​ນົດ​ເສັ້ນ​ທາງ​ການ​ຈະ​ລາ​ຈອນ​ກັບ​ຕົວ​ຢ່າງ​ຂອງ​ທ່ານ​ໂດຍ​ຜ່ານ​ຕາ​ຕະ​ລາງ​ການ​ນໍາ​ທາງ​ສະ​ຖິ​ຕິ​. ພວກເຮົາໄດ້ສະຫນອງກໍລະນີດັ່ງກ່າວເພາະວ່າບາງຄັ້ງຜູ້ໃຊ້ຕ້ອງການມັນ, ແລະພວກເຮົາຮູ້ກ່ຽວກັບມັນ. ດັ່ງນັ້ນ, ໃນໄດເລກະທໍລີຮູບພາບຂອງພວກເຮົາມີຮູບພາບ NAT ທີ່ຖືກຕັ້ງຄ່າພິເສດ.

ແຕ່ເຖິງແມ່ນວ່າໃນເວລາທີ່ມີຮູບພາບ NAT ທີ່ກຽມພ້ອມ, ການຕັ້ງຄ່າສາມາດສັບສົນ. ພວກເຮົາເຂົ້າໃຈວ່າສໍາລັບຜູ້ໃຊ້ບາງຄົນນີ້ບໍ່ແມ່ນທາງເລືອກທີ່ສະດວກທີ່ສຸດ, ດັ່ງນັ້ນໃນທີ່ສຸດພວກເຮົາໄດ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເປີດໃຊ້ NAT ສໍາລັບ Subnet ທີ່ຕ້ອງການໃນຄລິກດຽວ. ຄຸນສົມບັດນີ້ຍັງຢູ່ໃນການເຂົ້າເຖິງຕົວຢ່າງປິດ, ບ່ອນທີ່ມັນກໍາລັງຖືກທົດສອບໂດຍການຊ່ວຍເຫຼືອຂອງສະມາຊິກຊຸມຊົນ.

ວິທີການເຄືອຂ່າຍ virtual ເຮັດວຽກຈາກພາຍໃນ

ຜູ້ໃຊ້ພົວພັນກັບເຄືອຂ່າຍສະເໝືອນຈິງແນວໃດ? ເຄືອຂ່າຍເບິ່ງພາຍນອກດ້ວຍ API ຂອງມັນ. ຜູ້ໃຊ້ມາຮອດ API ແລະເຮັດວຽກກັບສະຖານະເປົ້າຫມາຍ. ຜ່ານ API, ຜູ້ໃຊ້ເບິ່ງວ່າທຸກສິ່ງທຸກຢ່າງຄວນຈະຖືກຈັດລຽງແລະກໍາຫນົດຄ່າແນວໃດ, ໃນຂະນະທີ່ລາວເຫັນສະຖານະພາບ, ສະພາບຕົວຈິງແຕກຕ່າງຈາກສິ່ງທີ່ຕ້ອງການ. ນີ້ແມ່ນຮູບຂອງຜູ້ໃຊ້. ມີຫຍັງເກີດຂຶ້ນພາຍໃນ?

ພວກເຮົາບັນທຶກສະຖານະທີ່ຕ້ອງການໃນຖານຂໍ້ມູນ Yandex ແລະໄປທີ່ການຕັ້ງຄ່າສ່ວນຕ່າງໆຂອງ VPC ຂອງພວກເຮົາ. ເຄືອຂ່າຍ overlay ໃນ Yandex.Cloud ຖືກສ້າງຂຶ້ນບົນພື້ນຖານຂອງອົງປະກອບທີ່ເລືອກຂອງ OpenContrail, ເຊິ່ງບໍ່ດົນມານີ້ໄດ້ຖືກເອີ້ນວ່າ Tungsten Fabric. ການບໍລິການເຄືອຂ່າຍຖືກປະຕິບັດຢູ່ໃນເວທີ CloudGate ດຽວ. ຢູ່ CloudGate, ພວກເຮົາຍັງໄດ້ນໍາໃຊ້ອົງປະກອບແຫຼ່ງເປີດຈໍານວນຫນຶ່ງ: GoBGP ສໍາລັບການຈັດການຂໍ້ມູນການຄວບຄຸມ, ເຊັ່ນດຽວກັນກັບ VPP ສໍາລັບການປະຕິບັດ router ຊອບແວທີ່ແລ່ນຢູ່ເທິງສຸດຂອງ DPDK ສໍາລັບເສັ້ນທາງຂໍ້ມູນ.

ຜ້າ Tungsten ຕິດຕໍ່ສື່ສານກັບ CloudGate ຜ່ານ GoBGP. ບອກສິ່ງທີ່ເກີດຂຶ້ນໃນເຄືອຂ່າຍຊ້ອນກັນ. CloudGate, ໃນທາງກັບກັນ, ເຊື່ອມຕໍ່ເຄືອຂ່າຍຊ້ອນກັນກັບກັນແລະກັນແລະອິນເຕີເນັດ.

ຕອນນີ້ໃຫ້ເບິ່ງວິທີການເຄືອຂ່າຍສະເໝືອນແກ້ໄຂບັນຫາການຂະຫຍາຍ ແລະ ການມີໃຫ້ໄດ້. ໃຫ້ພິຈາລະນາກໍລະນີທີ່ງ່າຍດາຍ. ມີເຂດຄວາມພ້ອມຫນຶ່ງແລະສອງ VPC ໄດ້ຖືກສ້າງຂື້ນຢູ່ໃນນັ້ນ. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ຕົວ​ຢ່າງ Tungsten Fabric ຫນຶ່ງ​, ແລະ​ມັນ​ປະ​ກອບ​ດ້ວຍ​ຫຼາຍ​ສິບ​ພັນ​ຂອງ​ເຄືອ​ຂ່າຍ​. ເຄືອຂ່າຍຕິດຕໍ່ສື່ສານກັບ CloudGate. CloudGate, ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວແລ້ວ, ຮັບປະກັນການເຊື່ອມຕໍ່ຂອງພວກເຂົາກັບກັນແລະກັນແລະກັບອິນເຕີເນັດ.

ສົມມຸດວ່າເຂດ Availability ທີສອງຖືກເພີ່ມ. ມັນຄວນຈະລົ້ມເຫລວຢ່າງສິ້ນເຊີງເປັນເອກະລາດຂອງຄັ້ງທໍາອິດ. ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງຕິດຕັ້ງຕົວຢ່າງຜ້າ Tungsten ແຍກຕ່າງຫາກຢູ່ໃນເຂດທີ່ສອງ. ນີ້ຈະເປັນລະບົບແຍກຕ່າງຫາກທີ່ຈັດການກັບ overlay ແລະຮູ້ພຽງເລັກນ້ອຍກ່ຽວກັບລະບົບທໍາອິດ. ແລະຮູບລັກສະນະທີ່ເຄືອຂ່າຍ virtual ຂອງພວກເຮົາແມ່ນທົ່ວໂລກ, ໃນຄວາມເປັນຈິງ, ສ້າງ VPC API ຂອງພວກເຮົາ. ນີ້ແມ່ນວຽກງານຂອງລາວ.

VPC1 ຖືກສ້າງແຜນທີ່ໃສ່ເຂດ Availability B ຖ້າ Availability Zone B ມີຊັບພະຍາກອນທີ່ຕິດກັບ VPC1. ຖ້າບໍ່ມີຊັບພະຍາກອນຈາກ VPC2 ໃນເຂດ B, ພວກເຮົາບໍ່ໄດ້ສ້າງ VPC2 ໃນເຂດນີ້. ໃນທາງກັບກັນ, ເນື່ອງຈາກວ່າຊັບພະຍາກອນຈາກ VPC3 ມີຢູ່ໃນເຂດ B, VPC3 ບໍ່ມີຢູ່ໃນເຂດ A. ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍແລະມີເຫດຜົນ.

ໃຫ້ເຂົ້າໄປເລິກກວ່າເລັກນ້ອຍ ແລະເບິ່ງວ່າເຈົ້າພາບສະເພາະໃນ Y.Cloud ເຮັດວຽກແນວໃດ. ສິ່ງທີ່ສໍາຄັນທີ່ຂ້ອຍຢາກສັງເກດແມ່ນວ່າເຈົ້າພາບທັງຫມົດຖືກອອກແບບມາຄືກັນ. ພວກເຮົາຮັບປະກັນວ່າການບໍລິການຂັ້ນຕ່ຳທີ່ຈຳເປັນເທົ່ານັ້ນທີ່ແລ່ນເທິງຮາດແວ; ສ່ວນທີ່ເຫຼືອທັງໝົດແມ່ນແລ່ນຢູ່ໃນເຄື່ອງສະເໝືອນ. ພວກເຮົາສ້າງການບໍລິການທີ່ມີຄໍາສັ່ງສູງກວ່າໂດຍອີງໃສ່ການບໍລິການພື້ນຖານໂຄງລ່າງ, ແລະຍັງໃຊ້ Cloud ເພື່ອແກ້ໄຂບັນຫາວິສະວະກໍາບາງຢ່າງ, ຕົວຢ່າງ, ເປັນສ່ວນຫນຶ່ງຂອງການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ.

ຖ້າພວກເຮົາເບິ່ງຢູ່ໃນເຈົ້າພາບສະເພາະ, ພວກເຮົາສາມາດເຫັນໄດ້ວ່າມີສາມອົງປະກອບທີ່ເຮັດວຽກຢູ່ໃນ host OS:

• ຄອມພີວເຕີແມ່ນພາກສ່ວນທີ່ຮັບຜິດຊອບໃນການແຈກຢາຍຊັບພະຍາກອນຄອມພິວເຕີ້ຢູ່ໃນໂຮດ.
• VRouter ແມ່ນສ່ວນຫນຶ່ງຂອງຜ້າ Tungsten, ເຊິ່ງຈັດລະບຽບ overlay, ນັ້ນແມ່ນ, ມັນ tunnels packets ຜ່ານ underlay ໄດ້.
• VDisks ແມ່ນຊິ້ນສ່ວນຂອງການເກັບຮັກສາ virtualization.

ນອກຈາກນັ້ນ, ເຄື່ອງ virtual ດໍາເນີນການບໍລິການ: ການບໍລິການພື້ນຖານໂຄງລ່າງຄລາວ, ການບໍລິການເວທີແລະຄວາມອາດສາມາດຂອງລູກຄ້າ. ຄວາມອາດສາມາດຂອງລູກຄ້າ ແລະການບໍລິການຂອງແພລດຟອມສະເໝີໄປການຊ້ອນກັນຜ່ານ VRouter.

ການບໍລິການພື້ນຖານໂຄງລ່າງສາມາດສຽບເຂົ້າໄປໃນ overlay ໄດ້, ແຕ່ສ່ວນຫຼາຍແມ່ນພວກເຂົາຕ້ອງການທີ່ຈະເຮັດວຽກຢູ່ໃນ underlay ໄດ້. ພວກມັນຕິດຢູ່ໃນຊັ້ນໃຕ້ດິນໂດຍໃຊ້ SR-IOV. ໃນ​ຄວາມ​ເປັນ​ຈິງ, ພວກ​ເຮົາ​ຕັດ​ບັດ​ເປັນ​ບັດ​ເຄືອ​ຂ່າຍ virtual (ຫນ້າ​ທີ່ virtual) ແລະ​ຊຸກ​ດັນ​ໃຫ້​ເຂົາ​ເຈົ້າ​ເຂົ້າ​ໄປ​ໃນ​ໂຄງ​ລ່າງ virtual machines ເພື່ອ​ບໍ່​ໃຫ້​ສູນ​ເສຍ​ການ​ປະ​ຕິ​ບັດ. ຕົວຢ່າງ, CloudGate ດຽວກັນຖືກເປີດຕົວເປັນຫນຶ່ງໃນເຄື່ອງຈັກ virtual ໂຄງສ້າງພື້ນຖານເຫຼົ່ານີ້.

ຕອນນີ້ພວກເຮົາໄດ້ອະທິບາຍເຖິງວຽກງານທົ່ວໂລກຂອງເຄືອຂ່າຍສະເໝືອນ ແລະການອອກແບບອົງປະກອບພື້ນຖານຂອງຄລາວ, ໃຫ້ເຮົາພິຈາລະນາເບິ່ງວ່າສ່ວນຕ່າງໆຂອງເຄືອຂ່າຍສະເໝືອນຈິງມີການພົວພັນກັນແນວໃດ.

ພວກເຮົາຈໍາແນກສາມຊັ້ນໃນລະບົບຂອງພວກເຮົາ:

• Config Plane - ກໍານົດສະຖານະເປົ້າຫມາຍຂອງລະບົບ. ນີ້ແມ່ນສິ່ງທີ່ຜູ້ໃຊ້ configure ຜ່ານ API.
• Control Plane - ສະໜອງຄວາມໝາຍທີ່ລະບຸໂດຍຜູ້ໃຊ້, ນັ້ນແມ່ນ, ມັນນຳເອົາສະຖານະຂອງ Data Plane ໄປສູ່ສິ່ງທີ່ໄດ້ອະທິບາຍໂດຍຜູ້ໃຊ້ໃນ Config Plane.
• Data Plane – ປະມວນຜົນແພັກເກັດຂອງຜູ້ໃຊ້ໂດຍກົງ.

ດັ່ງທີ່ຂ້ອຍໄດ້ກ່າວຂ້າງເທິງ, ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍຜູ້ໃຊ້ຫຼືບໍລິການເວທີພາຍໃນທີ່ເຂົ້າມາ API ແລະອະທິບາຍສະຖານະການເປົ້າຫມາຍທີ່ແນ່ນອນ.

ລັດນີ້ຖືກຂຽນໄວ້ໃນຖານຂໍ້ມູນ Yandex ທັນທີ, ສົ່ງຄືນ ID ຂອງການດໍາເນີນງານ asynchronous ຜ່ານ API, ແລະເປີດຕົວເຄື່ອງຈັກພາຍໃນຂອງພວກເຮົາເພື່ອຜະລິດລັດທີ່ຜູ້ໃຊ້ຕ້ອງການ. ວຽກງານການຕັ້ງຄ່າໄປຫາຕົວຄວບຄຸມ SDN ແລະບອກ Tungsten Fabric ສິ່ງທີ່ຕ້ອງເຮັດໃນການວາງຊ້ອນ. ຕົວຢ່າງ, ພວກເຂົາສະຫງວນພອດ, ເຄືອຂ່າຍ virtual, ແລະອື່ນໆ.

Config Plane ໃນ Tungsten Fabric ອັບໂຫລດສະຖານະທີ່ກໍານົດໄວ້ກັບຍົນຄວບຄຸມ. ຜ່ານມັນ, Config Plane ຕິດຕໍ່ສື່ສານກັບເຈົ້າພາບ, ບອກພວກເຂົາວ່າສິ່ງທີ່ຈະດໍາເນີນການກັບພວກເຂົາໃນອະນາຄົດອັນໃກ້ນີ້.

ຕອນນີ້ໃຫ້ເຮົາເບິ່ງວ່າລະບົບຈະມີລັກສະນະແນວໃດໃນເຈົ້າພາບ. ເຄື່ອງສະເໝືອນມີອະແດບເຕີເຄືອຂ່າຍສະເພາະທີ່ສຽບໃສ່ VRouter. VRouter ແມ່ນໂມດູນຫຼັກຂອງຜ້າ Tungsten ທີ່ເບິ່ງແພັກເກັດ. ຖ້າມີການໄຫຼເຂົ້າສໍາລັບບາງແພັກເກັດ, ໂມດູນຈະປະມວນຜົນມັນ. ຖ້າບໍ່ມີການໄຫຼເຂົ້າ, ໂມດູນເຮັດອັນທີ່ເອີ້ນວ່າ punting, ນັ້ນແມ່ນ, ມັນສົ່ງແພັກເກັດໄປຫາຂະບວນການ usermod. ຂະບວນການດັ່ງກ່າວຈະວິເຄາະແພັກເກັດ ແລະຕອບສະໜອງກັບມັນເອງ, ເຊັ່ນ: DHCP ແລະ DNS, ຫຼືບອກ VRouter ວ່າຈະເຮັດແນວໃດກັບມັນ. ຈາກນັ້ນ VRouter ສາມາດປະມວນຜົນແພັກເກັດໄດ້.

ນອກຈາກນັ້ນ, ການຈະລາຈອນລະຫວ່າງເຄື່ອງ virtual ພາຍໃນເຄືອຂ່າຍ virtual ດຽວກັນໄຫຼຢ່າງໂປ່ງໃສ, ມັນບໍ່ໄດ້ຖືກສົ່ງໄປຫາ CloudGate. ໂຮສທີ່ເຄື່ອງ virtual ຖືກນໍາໃຊ້ຕິດຕໍ່ສື່ສານກັບກັນແລະກັນໂດຍກົງ. ພວກ​ເຂົາ​ເຈົ້າ​ຈະ​ລາ​ຈອນ tunnel ແລະ​ສົ່ງ​ຕໍ່​ໃຫ້​ກັນ​ແລະ​ກັນ​ໂດຍ​ຜ່ານ underlay ໄດ້​.

ຍົນຄວບຄຸມຕິດຕໍ່ສື່ສານກັບກັນແລະກັນໃນທົ່ວເຂດທີ່ມີໃຫ້ຜ່ານ BGP, ຄືກັນກັບກັບ router ອື່ນ. ພວກເຂົາບອກທ່ານວ່າເຄື່ອງໃດຖືກຕິດຕັ້ງຢູ່ບ່ອນໃດ, ດັ່ງນັ້ນເຄື່ອງ virtual ໃນເຂດຫນຶ່ງສາມາດສື່ສານໂດຍກົງກັບເຄື່ອງ virtual ອື່ນໆ.

ຍົນຄວບຄຸມຍັງຕິດຕໍ່ສື່ສານກັບ CloudGate. ເຊັ່ນດຽວກັນ, ມັນລາຍງານວ່າມີການຕິດຕັ້ງເຄື່ອງ virtual ແລະບ່ອນໃດ, ທີ່ຢູ່ຂອງພວກເຂົາແມ່ນຫຍັງ. ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດຊີ້ນໍາການຈະລາຈອນພາຍນອກແລະການຈະລາຈອນຈາກຜູ້ດຸ່ນດ່ຽງໄປຫາພວກເຂົາ.

ການຈາລະຈອນທີ່ອອກຈາກ VPC ມາຮອດ CloudGate, ໃນເສັ້ນທາງຂໍ້ມູນ, ບ່ອນທີ່ VPP ກັບ plugins ຂອງພວກເຮົາຖືກ chewed ຢ່າງໄວວາ. ຫຼັງຈາກນັ້ນ, ການຈະລາຈອນຈະຖືກຍິງໄປຫາ VPCs ອື່ນໆ, ຫຼືພາຍນອກ, ໄປຫາ routers edge, ເຊິ່ງຖືກຕັ້ງຄ່າຜ່ານ Control Plane ຂອງ CloudGate ເອງ.

ແຜນການສໍາລັບອະນາຄົດອັນໃກ້ນີ້

ຖ້າພວກເຮົາສະຫຼຸບທຸກຢ່າງທີ່ກ່າວຂ້າງເທິງໃນສອງສາມປະໂຫຍກ, ພວກເຮົາສາມາດເວົ້າວ່າ VPC ໃນ Yandex.Cloud ແກ້ໄຂບັນຫາທີ່ສໍາຄັນສອງຢ່າງ:

• ສະຫນອງການໂດດດ່ຽວລະຫວ່າງລູກຄ້າທີ່ແຕກຕ່າງກັນ.
• ຮວມຊັບພະຍາກອນ, ພື້ນຖານໂຄງລ່າງ, ບໍລິການແພລດຟອມ, ຟັງຄລາວອື່ນໆ ແລະໃນສະຖານປະກອບເຂົ້າໃນເຄືອຂ່າຍດຽວ.

ແລະເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້ໄດ້ດີ, ທ່ານຈໍາເປັນຕ້ອງຮັບປະກັນການຂະຫຍາຍແລະຄວາມທົນທານຕໍ່ຄວາມຜິດໃນລະດັບຂອງສະຖາປັດຕະຍະກໍາພາຍໃນ, ເຊິ່ງເປັນສິ່ງທີ່ VPC ເຮັດ.

ຄ່ອຍໆ, VPC ກໍາລັງໄດ້ຮັບຫນ້າທີ່, ພວກເຮົາກໍາລັງປະຕິບັດຄຸນສົມບັດໃຫມ່, ແລະພະຍາຍາມປັບປຸງບາງສິ່ງບາງຢ່າງກ່ຽວກັບຄວາມສະດວກສໍາລັບຜູ້ໃຊ້. ແນວຄວາມຄິດບາງຢ່າງຖືກອອກສຽງ ແລະລວມຢູ່ໃນລາຍການບູລິມະສິດ ຂອບໃຈສະມາຊິກຂອງຊຸມຊົນຂອງພວກເຮົາ.

ໃນປັດຈຸບັນພວກເຮົາມີປະມານບັນຊີລາຍຊື່ດັ່ງຕໍ່ໄປນີ້ຂອງແຜນການສໍາລັບອະນາຄົດອັນໃກ້ນີ້:

• VPN ເປັນບໍລິການ.
• ຕົວຢ່າງ DNS ສ່ວນຕົວ – ຮູບພາບສໍາລັບການຕັ້ງຄ່າເຄື່ອງ virtual ຢ່າງໄວວາດ້ວຍເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ກໍານົດໄວ້ກ່ອນ.
• DNS ເປັນບໍລິການ.
• ຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍໃນ.
• ການເພີ່ມທີ່ຢູ່ IP “ສີຂາວ” ໂດຍບໍ່ມີການສ້າງເຄື່ອງ virtual.

ເຄື່ອງດຸ່ນດ່ຽງແລະຄວາມສາມາດໃນການປ່ຽນທີ່ຢູ່ IP ສໍາລັບເຄື່ອງ virtual ທີ່ສ້າງແລ້ວໄດ້ຖືກລວມເຂົ້າໃນບັນຊີລາຍຊື່ນີ້ຕາມຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້. ດ້ວຍຄວາມຊື່ສັດ, ໂດຍບໍ່ມີຄໍາຕິຊົມຢ່າງຈະແຈ້ງ, ພວກເຮົາຈະປະຕິບັດຫນ້າທີ່ເຫຼົ່ານີ້ຕໍ່ມາເລັກນ້ອຍ. ແລະດັ່ງນັ້ນພວກເຮົາກໍາລັງເຮັດວຽກແລ້ວກ່ຽວກັບບັນຫາກ່ຽວກັບທີ່ຢູ່.

ໃນເບື້ອງຕົ້ນ, ທີ່ຢູ່ IP "ສີຂາວ" ສາມາດຖືກເພີ່ມພຽງແຕ່ເມື່ອສ້າງເຄື່ອງຈັກ. ຖ້າຜູ້ໃຊ້ລືມເຮັດສິ່ງນີ້, ເຄື່ອງ virtual ຕ້ອງໄດ້ຮັບການສ້າງໃຫມ່. ເຊັ່ນດຽວກັນສໍາລັບການຖອນ IP ພາຍນອກຖ້າຈໍາເປັນ. ໃນໄວໆນີ້ມັນເປັນໄປໄດ້ທີ່ຈະເປີດແລະປິດ IP ສາທາລະນະໂດຍບໍ່ຈໍາເປັນຕ້ອງສ້າງເຄື່ອງໃຫມ່.

ຮູ້ສຶກບໍ່ເສຍຄ່າເພື່ອສະແດງອອກຂອງທ່ານ ແນວຄວາມຄິດແລະຄໍາແນະນໍາສະຫນັບສະຫນູນ ຜູ້ໃຊ້ອື່ນໆ. ທ່ານຊ່ວຍພວກເຮົາເຮັດໃຫ້ Cloud ດີຂຶ້ນ ແລະໄດ້ຮັບຄຸນສົມບັດທີ່ສຳຄັນ ແລະເປັນປະໂຫຍດໄວຂຶ້ນ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com