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

ກອບດຽວກັນກໍານົດຄໍາສັ່ງທີ່ພວກເຮົາຈະຈັດການກັບຄໍາຖາມ.
ແລະ virtualization ເຄືອຂ່າຍ, ເຊິ່ງບັນຫານີ້ແມ່ນອຸທິດຕົນ, ບໍ່ເຫມາະໂດຍສະເພາະກັບຫົວຂໍ້ ADSM, ບ່ອນທີ່ພວກເຮົາວິເຄາະອັດຕະໂນມັດ.

ແຕ່ໃຫ້ເບິ່ງມັນຈາກມຸມທີ່ແຕກຕ່າງກັນ.

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

ແລະການບໍລິການທັງຫມົດຮຽກຮ້ອງໃຫ້ມີການໂດດດ່ຽວຈາກກັນແລະກັນ. ນີ້ແມ່ນວິທີທີ່ເຄືອຂ່າຍ overlay ປາກົດ.

ແລະການບໍລິການທັງຫມົດບໍ່ຕ້ອງການລໍຖ້າໃຫ້ບຸກຄົນທີ່ຈະກໍາຫນົດຄ່າດ້ວຍຕົນເອງ. ນີ້ແມ່ນວິທີທີ່ນັກດົນຕີແລະ SDN ປາກົດ.

ວິທີການທໍາອິດໃນລະບົບອັດຕະໂນມັດຂອງເຄືອຂ່າຍ, ຫຼືແທນທີ່ຈະເປັນສ່ວນຫນຶ່ງຂອງມັນ, ໄດ້ຖືກປະຕິບັດແລະປະຕິບັດໃນຫຼາຍໆບ່ອນ: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາຈະຈັດການກັບໃນມື້ນີ້.

ເນື້ອໃນ

• ເຫດຜົນ
• Terminology
• Underlay - ເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ
• ວາງຊ້ອນ - ເຄືອຂ່າຍສະເໝືອນ
  • ວາງຊ້ອນກັບ ToR
  • ວາງຊ້ອນຈາກເຈົ້າພາບ
  • ການນໍາໃຊ້ຜ້າ Tungsten ເປັນຕົວຢ່າງ
    • ການສື່ສານພາຍໃນເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍດຽວ
    • ການສື່ສານລະຫວ່າງ VMs ທີ່ຕັ້ງຢູ່ໃນເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍທີ່ແຕກຕ່າງກັນ
    • ອອກສູ່ໂລກພາຍນອກ

• FAQ
• ສະຫລຸບ
• ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ

ເຫດຜົນ

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

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

ເພື່ອບໍ່ລໍຖ້າຜູ້ເຄືອຂ່າຍໃສ່ VLANs ແລະບໍ່ລົງທະບຽນບໍລິການໃດໆໃນແຕ່ລະ node ເຄືອຂ່າຍ, ປະຊາຊົນໄດ້ຄິດເຖິງການໃຊ້ overlays - overlay networks - ເຊິ່ງມີຫຼາກຫຼາຍຊະນິດ: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ແລະອື່ນໆ.

ການອຸທອນຂອງພວກເຂົາແມ່ນຢູ່ໃນສອງສິ່ງງ່າຍໆ:

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

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

ຊຸດທັງຫມົດຈະອະທິບາຍສູນຂໍ້ມູນປະກອບດ້ວຍແຖວຂອງ racks ດຽວກັນທີ່ອຸປະກອນເຄື່ອງແມ່ຂ່າຍດຽວກັນໄດ້ຖືກຕິດຕັ້ງ.

ອຸ​ປະ​ກອນ​ນີ້​ດໍາ​ເນີນ​ການ virtual machines/containers/serverless ທີ່​ປະ​ຕິ​ບັດ​ການ​ບໍ​ລິ​ການ.

Terminology

ໃນ loop ເປັນ ເຊີບເວີ ຂ້ອຍຈະຕັ້ງຊື່ໂຄງການທີ່ປະຕິບັດດ້ານເຊີຟເວີຂອງການສື່ສານລູກຄ້າກັບເຄື່ອງແມ່ຂ່າຍ.

ເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍໃນ racks ຖືກເອີ້ນວ່າເຄື່ອງແມ່ຂ່າຍ ບໍ່ ພວກ​ເຮົາ​ຈະ.

ເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍ — x86 ຄອມ​ພິວ​ເຕີ​ຕິດ​ຕັ້ງ​ໃນ rack ເປັນ​. ຄໍາສັບທີ່ໃຊ້ເລື້ອຍໆທີ່ສຸດ ເຈົ້າພາບ. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາຈະເອີ້ນວ່າ "машина"ຫຼື ເຈົ້າພາບ.

Hypervisor — ແອັບພລິເຄຊັ່ນທີ່ແລ່ນຢູ່ໃນເຄື່ອງຕົວຈິງທີ່ຈຳລອງຊັບພະຍາກອນທາງກາຍະພາບທີ່ເຄື່ອງ Virtual ແລ່ນ. ບາງຄັ້ງໃນວັນນະຄະດີແລະອິນເຕີເນັດຄໍາວ່າ "hypervisor" ຖືກໃຊ້ເປັນຄໍາສັບຄ້າຍຄື "ເຈົ້າພາບ".

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

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

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

ToR — ເທິງສຸດຂອງສະວິດ Rack - ສະວິດທີ່ຕິດຕັ້ງຢູ່ໃນ rack ທີ່ເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍທັງຫມົດແມ່ນເຊື່ອມຕໍ່.

ນອກເຫນືອໄປຈາກ ToR topology, ຜູ້ໃຫ້ບໍລິການຕ່າງໆໄດ້ປະຕິບັດ End of Row (EoR) ຫຼື Middle of Row (ເຖິງແມ່ນວ່າອັນສຸດທ້າຍແມ່ນເປັນສິ່ງທີ່ບໍ່ຄ່ອຍພໍໃຈແລະຂ້ອຍບໍ່ໄດ້ເຫັນຕົວຫຍໍ້ຂອງ MoR).

ເຄືອຂ່າຍ underlay ຫຼື ເຄືອ​ຂ່າຍ​ທີ່​ຕິດ​ພັນ​ຫຼື underlay ແມ່ນ​ໂຄງ​ລ່າງ​ເຄືອ​ຂ່າຍ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ​: ສະ​ຫຼັບ​, routers​, ສາຍ​.

ເຄືອຂ່າຍຊ້ອນກັນ ຫຼື overlay network ຫຼື overlay - ເຄືອຂ່າຍ virtual ຂອງ tunnels ແລ່ນຢູ່ເທິງສຸດທາງກາຍະພາບ.

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

SDN - ຊອບແວກໍານົດເຄືອຂ່າຍ. ເກືອບຕ້ອງການການແນະນຳ. ວິທີການໃນການຄຸ້ມຄອງເຄືອຂ່າຍທີ່ການປ່ຽນແປງເຄືອຂ່າຍແມ່ນເຮັດບໍ່ໄດ້ໂດຍບຸກຄົນ, ແຕ່ໂດຍໂຄງການ. ໂດຍປົກກະຕິຫມາຍເຖິງການຍ້າຍ Control Plane ນອກເຫນືອຈາກອຸປະກອນເຄືອຂ່າຍສຸດທ້າຍໄປຫາຕົວຄວບຄຸມ.

NFV - Network Function Virtualization - virtualization ຂອງອຸປະກອນເຄືອຂ່າຍ, ແນະນໍາວ່າບາງຫນ້າທີ່ເຄືອຂ່າຍສາມາດດໍາເນີນການໃນຮູບແບບຂອງ virtual machines ຫຼື containers ເພື່ອເລັ່ງການປະຕິບັດການບໍລິການໃຫມ່, ຈັດລະບົບຕ່ອງໂສ້ການບໍລິການແລະການຂະຫຍາຍອອກຕາມລວງນອນງ່າຍດາຍ.

VNF - ຟັງຊັນເຄືອຂ່າຍສະເໝືອນ. ອຸປະກອນສະເໝືອນສະເພາະ: router, switch, firewall, NAT, IPS/IDS, ແລະອື່ນໆ.

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

ເຄືອຂ່າຍສ່ວນໃຫຍ່ໃນມື້ນີ້ສາມາດແບ່ງອອກເປັນສອງສ່ວນຢ່າງຊັດເຈນ:

ຊັ້ນໃຕ້ດິນ — ເຄືອ​ຂ່າຍ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ​ທີ່​ມີ​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ຫມັ້ນ​ຄົງ​.
ການຊ້ອນກັນ — abstraction over Underlay ສໍາລັບການແຍກຜູ້ເຊົ່າ.

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

ຮູບພາບທີ່ເນັ້ນໃສ່ເຄືອຂ່າຍ:

ຊັ້ນໃຕ້ດິນ

Underlay ແມ່ນເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ: ສະຫຼັບຮາດແວ ແລະສາຍ. ອຸປະກອນທີ່ຢູ່ໃຕ້ດິນຮູ້ວິທີການເຂົ້າເຖິງເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍ.

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

ແຕ່ບາງຄົນເຊັ່ນ Google ສາມາດທີ່ຈະພັດທະນາສະວິດຂອງຕົນເອງແລະປະຖິ້ມໂປໂຕຄອນທີ່ຍອມຮັບໂດຍທົ່ວໄປ. ແຕ່ LAN_DC ບໍ່ແມ່ນ Google.

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

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

ເຄືອຂ່າຍ Underlay ໄດ້ຖືກຕັ້ງຄ່າໃນແບບຄລາສສິກ: CLI/GUI/NETCONF.

ດ້ວຍຕົນເອງ, scripts, ຜົນປະໂຫຍດທີ່ເປັນເຈົ້າຂອງ.

ບົດຄວາມຕໍ່ໄປໃນຊຸດຈະໄດ້ຮັບການອຸທິດໃຫ້ underlay ໃນລາຍລະອຽດເພີ່ມເຕີມ.

ການຊ້ອນກັນ

Overlay ເປັນເຄືອຂ່າຍ virtual ຂອງ tunnels stretched ສຸດເທິງຂອງ Underlay, ມັນອະນຸຍາດໃຫ້ VMs ຂອງລູກຄ້າຫນຶ່ງຕິດຕໍ່ສື່ສານກັບກັນແລະກັນ, ໃນຂະນະທີ່ສະຫນອງການໂດດດ່ຽວຈາກລູກຄ້າອື່ນໆ.

ຂໍ້​ມູນ​ລູກ​ຄ້າ​ແມ່ນ encapsulated ໃນ​ບາງ​ຫົວ​ອຸ​ໂມງ​ສໍາ​ລັບ​ການ​ສົ່ງ​ຜ່ານ​ເຄືອ​ຂ່າຍ​ສາ​ທາ​ລະ​ນະ​.

ດັ່ງນັ້ນ VMs ຂອງລູກຄ້າຫນຶ່ງ (ຫນຶ່ງບໍລິການ) ສາມາດສື່ສານກັບກັນແລະກັນໂດຍຜ່ານການ Overlay, ໂດຍບໍ່ຮູ້ວ່າວິທີການຂອງ Packet ຕົວຈິງແລ້ວ.

ການວາງຊ້ອນອາດຈະເປັນຕົວຢ່າງເຊັ່ນທີ່ຂ້ອຍໄດ້ກ່າວມາຂ້າງເທິງ:

• ອຸໂມງ GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

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

ແມ່ນແລ້ວ, ນີ້ແມ່ນ SDN ໃນຮູບແບບທີ່ບໍລິສຸດຂອງມັນ.

ມີສອງວິທີທີ່ແຕກຕ່າງກັນໂດຍພື້ນຖານໃນການຈັດຕັ້ງເຄືອຂ່າຍ Overlay:

1. ວາງຊ້ອນກັບ ToR
2. ວາງຊ້ອນຈາກເຈົ້າພາບ

ວາງຊ້ອນກັບ ToR

ການວາງຊ້ອນສາມາດເລີ່ມຕົ້ນຢູ່ທີ່ສະວິດການເຂົ້າເຖິງ (ToR) ຢືນຢູ່ໃນ rack, ດັ່ງທີ່ເກີດຂື້ນ, ສໍາລັບຕົວຢ່າງ, ໃນກໍລະນີຂອງຜ້າ VXLAN.

ນີ້ແມ່ນກົນໄກການທົດສອບເວລາໃນເຄືອຂ່າຍ ISP ແລະຜູ້ຂາຍອຸປະກອນເຄືອຂ່າຍທັງຫມົດສະຫນັບສະຫນູນມັນ.

ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີນີ້, ສະຫຼັບ ToR ຈະຕ້ອງສາມາດແຍກການບໍລິການຕ່າງໆຕາມລໍາດັບ, ແລະຜູ້ບໍລິຫານເຄືອຂ່າຍຕ້ອງ, ໃນລະດັບໃດຫນຶ່ງ, ຮ່ວມມືກັບຜູ້ບໍລິຫານເຄື່ອງ virtual ແລະເຮັດການປ່ຽນແປງ (ເຖິງແມ່ນວ່າອັດຕະໂນມັດ) ກັບການຕັ້ງຄ່າຂອງອຸປະກອນ. .

ໃນທີ່ນີ້ຂ້າພະເຈົ້າຈະສົ່ງຜູ້ອ່ານໄປຫາບົດຄວາມກ່ຽວກັບ VxLAN ໃນ Habre ເພື່ອນເກົ່າຂອງພວກເຮົາ @bormoglotx.
ໃນ​ນີ້ ການນໍາສະເຫນີກັບ ENOG ວິທີການສ້າງເຄືອຂ່າຍ DC ດ້ວຍຜ້າ EVPN VXLAN ໄດ້ຖືກອະທິບາຍຢ່າງລະອຽດ.

ແລະ​ເພື່ອ​ຄວາມ​ເປັນ​ຈິງ​ທີ່​ສົມ​ບູນ​ແບບ, ເຈົ້າ​ສາ​ມາດ​ອ່ານ​ຫນັງ​ສື​ຂອງ Nonka ໄດ້ ຜ້າທີ່ທັນສະໄໝ, ເປີດ ແລະຂະຫຍາຍໄດ້: VXLAN EVPN.

ຂ້າພະເຈົ້າສັງເກດວ່າ VXLAN ແມ່ນພຽງແຕ່ວິທີການ encapsulation ແລະການຢຸດເຊົາຂອງ tunnels ສາມາດເກີດຂຶ້ນບໍ່ໄດ້ຢູ່ໃນ ToR, ແຕ່ຢູ່ໃນເຈົ້າພາບ, ເຊັ່ນດຽວກັບກໍລະນີຂອງ OpenStack, ສໍາລັບການຍົກຕົວຢ່າງ.

ຢ່າງໃດກໍຕາມ, VXLAN fabric, ບ່ອນທີ່ overlay ເລີ່ມຕົ້ນທີ່ ToR, ເປັນຫນຶ່ງໃນການອອກແບບເຄືອຂ່າຍ overlay ສ້າງຕັ້ງຂຶ້ນ.

ວາງຊ້ອນຈາກເຈົ້າພາບ

ອີກວິທີໜຶ່ງແມ່ນການເລີ່ມຕົ້ນ ແລະຢຸດການເຈາະອຸໂມງໃນເຄື່ອງໝາຍປາຍທາງ.
ໃນກໍລະນີນີ້, ເຄືອຂ່າຍ (Underlay) ຍັງຄົງເປັນແບບງ່າຍດາຍແລະຄົງທີ່ທີ່ເປັນໄປໄດ້.
ແລະເຈົ້າພາບເອງເຮັດການຫຸ້ມຫໍ່ທີ່ຈໍາເປັນທັງຫມົດ.

ນີ້ແນ່ນອນຈະຮຽກຮ້ອງໃຫ້ມີການແລ່ນຄໍາຮ້ອງສະຫມັກພິເສດໃນເຈົ້າພາບ, ແຕ່ມັນຄຸ້ມຄ່າ.

ກ່ອນອື່ນ ໝົດ, ການໃຊ້ລູກຄ້າໃນເຄື່ອງ Linux ແມ່ນງ່າຍກວ່າ, ຫຼືສົມມຸດວ່າເປັນໄປໄດ້, ໃນຂະນະທີ່ຢູ່ໃນສະວິດ, ທ່ານມັກຈະຕ້ອງຫັນໄປຫາວິທີແກ້ໄຂ SDN ທີ່ເປັນເຈົ້າຂອງ, ເຊິ່ງຂ້າຄວາມຄິດຂອງຜູ້ຂາຍຫຼາຍ.

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

ໃນຊຸດ ADSM, ຂ້ອຍເລືອກວິທີການ overlay ຈາກເຈົ້າພາບ - ຫຼັງຈາກນັ້ນພວກເຮົາພຽງແຕ່ເວົ້າກ່ຽວກັບມັນແລະພວກເຮົາຈະບໍ່ກັບຄືນໄປຫາໂຮງງານ VXLAN.

ມັນງ່າຍທີ່ສຸດທີ່ຈະເບິ່ງຕົວຢ່າງ. ແລະເປັນວິຊາການທົດສອບພວກເຮົາຈະເອົາ OpenSource SDN platform OpenContrail, ປະຈຸບັນເອີ້ນວ່າ ຜ້າ Tungsten.

ໃນຕອນທ້າຍຂອງບົດຄວາມຂ້າພະເຈົ້າຈະໃຫ້ຄວາມຄິດບາງຢ່າງກ່ຽວກັບການປຽບທຽບກັບ OpenFlow ແລະ OpenvSwitch.

ການນໍາໃຊ້ຜ້າ Tungsten ເປັນຕົວຢ່າງ

ແຕ່ລະເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍມີ vRouter - ເປັນ router virtual ທີ່ຮູ້ກ່ຽວກັບເຄືອຂ່າຍທີ່ເຊື່ອມຕໍ່ກັບມັນແລະລູກຄ້າທີ່ເຂົາເຈົ້າຂຶ້ນກັບ - ທີ່ສໍາຄັນເປັນ router PE. ສໍາລັບລູກຄ້າແຕ່ລະຄົນ, ມັນຮັກສາຕາຕະລາງເສັ້ນທາງທີ່ໂດດດ່ຽວ (ອ່ານ VRF). ແລະ vRouter ຕົວຈິງແລ້ວເຮັດ Overlay tunneling.

ເພີ່ມເຕີມເລັກນ້ອຍກ່ຽວກັບ vRouter ແມ່ນຢູ່ໃນຕອນທ້າຍຂອງບົດຄວາມ.

ແຕ່ລະ VM ທີ່ຕັ້ງຢູ່ເທິງ hypervisor ແມ່ນເຊື່ອມຕໍ່ກັບ vRouter ຂອງເຄື່ອງນີ້ໂດຍຜ່ານ TAP ການໂຕ້ຕອບ.

TAP - ຈຸດເຂົ້າເຖິງ Terminal - ເປັນການໂຕ້ຕອບ virtual ໃນ kernel Linux ທີ່ອະນຸຍາດໃຫ້ການໂຕ້ຕອບເຄືອຂ່າຍ.

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

ເພື່ອໃຫ້ vRouters ສາມາດສື່ສານກັບກັນແລະກັນ, ແລະຕາມຄວາມເຫມາະສົມ VMs ທີ່ຕັ້ງຢູ່ຫລັງພວກເຂົາ, ພວກເຂົາແລກປ່ຽນຂໍ້ມູນເສັ້ນທາງຜ່ານ. ຕົວຄວບຄຸມ SDN.

ເພື່ອອອກໄປສູ່ໂລກພາຍນອກ, ມີຈຸດອອກຈາກ matrix - virtual network gateway VNGW - Virtual Network GateWay (ໄລຍະຂອງຂ້ອຍ).

ຕອນນີ້ໃຫ້ເບິ່ງຕົວຢ່າງຂອງການສື່ສານ - ແລະຈະມີຄວາມຊັດເຈນ.

ການສື່ສານພາຍໃນເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍດຽວ

VM0 ຕ້ອງການສົ່ງແພັກເກັດໄປຫາ VM2. ໃຫ້ສົມມຸດສໍາລັບຕອນນີ້ວ່ານີ້ແມ່ນ VM ລູກຄ້າດຽວ.

ຍົນຂໍ້ມູນ

1. VM-0 ມີເສັ້ນທາງເລີ່ມຕົ້ນໄປຫາສ່ວນຕິດຕໍ່ eth0 ຂອງມັນ. ຊຸດໄດ້ຖືກສົ່ງຢູ່ທີ່ນັ້ນ.
   ອິນເຕີເຟດ eth0 ນີ້ຕົວຈິງແລ້ວແມ່ນເຊື່ອມຕໍ່ virtually ກັບ router virtual vRouter ຜ່ານ TAP interface tap0.
2. vRouter ວິເຄາະວ່າແພັກເກັດທີ່ມາຂອງອິນເຕີເຟດນັ້ນແມ່ນລູກຄ້າ (VRF) ໃດເປັນຂອງ, ແລະກວດເບິ່ງທີ່ຢູ່ຂອງຜູ້ຮັບກັບຕາຕະລາງເສັ້ນທາງຂອງລູກຄ້ານີ້.
3. ໂດຍໄດ້ກວດພົບວ່າຜູ້ຮັບໃນເຄື່ອງດຽວກັນຢູ່ໃນພອດທີ່ແຕກຕ່າງກັນ, vRouter ພຽງແຕ່ສົ່ງແພັກເກັດໄປຫາມັນໂດຍບໍ່ມີສ່ວນຫົວເພີ່ມເຕີມ - ສໍາລັບກໍລະນີນີ້, vRouter ມີລາຍການ ARP ແລ້ວ.

ໃນກໍລະນີນີ້, ແພັກເກັດບໍ່ເຂົ້າໄປໃນເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ - ມັນຖືກສົ່ງຜ່ານພາຍໃນ vRouter.

ຍົນຄວບຄຸມ

ເມື່ອເຄື່ອງ virtual ເລີ່ມຕົ້ນ, hypervisor ບອກມັນ:

• ທີ່ຢູ່ IP ຂອງນາງເອງ.
• ເສັ້ນທາງເລີ່ມຕົ້ນແມ່ນຜ່ານທີ່ຢູ່ IP ຂອງ vRouter ໃນເຄືອຂ່າຍນີ້.

hypervisor ລາຍງານໃຫ້ vRouter ຜ່ານ API ພິເສດ:

• ສິ່ງທີ່ທ່ານຕ້ອງການເພື່ອສ້າງການໂຕ້ຕອບ virtual.
• ມັນຕ້ອງການສ້າງເຄືອຂ່າຍສະເໝືອນ (VM) ປະເພດໃດ?
• ທີ່ VRF (VN) ຜູກມັດມັນກັບ.
• ການເຂົ້າ ARP ຄົງທີ່ສໍາລັບ VM ນີ້ - ທີ່ຢູ່ IP ຂອງມັນຢູ່ໃນການໂຕ້ຕອບໃດແລະທີ່ຢູ່ MAC ມັນຜູກມັດກັບອັນໃດ.

ອີກເທື່ອຫນຶ່ງ, ຂັ້ນຕອນການໂຕ້ຕອບຕົວຈິງແມ່ນງ່າຍດາຍສໍາລັບຄວາມເຂົ້າໃຈແນວຄວາມຄິດ.

ດັ່ງນັ້ນ, vRouter ເຫັນ VM ທັງໝົດຂອງລູກຄ້າໜຶ່ງເຄື່ອງຢູ່ໃນເຄື່ອງທີ່ໃຫ້ມາເປັນເຄືອຂ່າຍທີ່ເຊື່ອມຕໍ່ໂດຍກົງ ແລະສາມາດສົ່ງເສັ້ນທາງລະຫວ່າງເຂົາເຈົ້າເອງໄດ້.

ແຕ່ VM0 ແລະ VM1 ເປັນຂອງລູກຄ້າທີ່ແຕກຕ່າງກັນແລະ, ຕາມນັ້ນ, ແມ່ນຢູ່ໃນຕາຕະລາງ vRouter ທີ່ແຕກຕ່າງກັນ.

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

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

ການສື່ສານລະຫວ່າງ VMs ທີ່ຕັ້ງຢູ່ໃນເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍທີ່ແຕກຕ່າງກັນ

ຍົນຂໍ້ມູນ

1. ການເລີ່ມຕົ້ນແມ່ນຄືກັນແທ້ໆ: VM-0 ສົ່ງແພັກເກັດທີ່ມີປາຍທາງ VM-7 (172.17.3.2) ຕາມຄ່າເລີ່ມຕົ້ນຂອງມັນ.
2. vRouter ໄດ້ຮັບມັນແລະເວລານີ້ເຫັນວ່າຈຸດຫມາຍປາຍທາງຢູ່ໃນເຄື່ອງອື່ນແລະສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານ Tunnel0.
3. ທໍາອິດ, ມັນວາງປ້າຍ MPLS ທີ່ກໍານົດການໂຕ້ຕອບຫ່າງໄກສອກຫຼີກ, ດັ່ງນັ້ນ vRouter ດ້ານກົງກັນຂ້າມສາມາດກໍານົດບ່ອນທີ່ຈະວາງແພັກເກັດນີ້ໂດຍບໍ່ມີການຊອກຫາເພີ່ມເຕີມ.

   

4. Tunnel0 ມີແຫຼ່ງ 10.0.0.2, ຈຸດຫມາຍປາຍທາງ: 10.0.1.2.
   vRouter ເພີ່ມສ່ວນຫົວ GRE (ຫຼື UDP) ແລະ IP ໃໝ່ໃສ່ແພັກເກັດຕົ້ນສະບັບ.
5. ຕາຕະລາງການກຳນົດເສັ້ນທາງ vRouter ມີເສັ້ນທາງເລີ່ມຕົ້ນຜ່ານທີ່ຢູ່ ToR1 10.0.0.1. ນັ້ນແມ່ນບ່ອນທີ່ລາວສົ່ງມັນ.

   
   

6. ToR1, ເປັນສະມາຊິກຂອງເຄືອຂ່າຍ Underlay, ຮູ້ (ຕົວຢ່າງ, ຜ່ານ OSPF) ວິທີການໄປຫາ 10.0.1.2 ແລະສົ່ງແພັກເກັດຕາມເສັ້ນທາງ. ໃຫ້ສັງເກດວ່າ ECMP ຖືກເປີດໃຊ້ຢູ່ທີ່ນີ້. ມີສອງຫົວຂໍ້ຕໍ່ໄປໃນຕົວຢ່າງ, ແລະກະທູ້ທີ່ແຕກຕ່າງກັນຈະຖືກຈັດຮຽງເຂົ້າໄປໃນພວກມັນໂດຍ hash. ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ໂຮງ​ງານ​ຜະ​ລິດ​ທີ່​ແທ້​ຈິງ​, ຈະ​ມີ​ຫຼາຍ​ກວ່າ 4 nexthops​.

   ໃນເວລາດຽວກັນ, ລາວບໍ່ຈໍາເປັນຕ້ອງຮູ້ວ່າສິ່ງທີ່ຢູ່ພາຍໃຕ້ຫົວຂໍ້ IP ພາຍນອກ. ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, ພາຍໃຕ້ IP ສາມາດມີ sandwich ຂອງ IPv6 ໃນໄລຍະ MPLS ຜ່ານ Ethernet ໃນໄລຍະ MPLS ໃນໄລຍະ GRE ໃນໄລຍະພາສາກເຣັກ.

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

ຍົນຄວບຄຸມ

ເມື່ອທ່ານເລີ່ມລົດ, ສິ່ງດຽວກັນເກີດຂຶ້ນດັ່ງທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

ແລະບວກກັບສິ່ງຕໍ່ໄປນີ້:

• ສໍາລັບລູກຄ້າແຕ່ລະຄົນ, vRouter ຈັດສັນແທັກ MPLS. ນີ້ແມ່ນປ້າຍບໍລິການ L3VPN, ໂດຍທີ່ລູກຄ້າຈະຖືກແຍກອອກຈາກເຄື່ອງດຽວກັນ.
  

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

• vRouter ສ້າງຕັ້ງການເຊື່ອມຕໍ່ກັບຕົວຄວບຄຸມ SDN ໂດຍໃຊ້ໂປໂຕຄອນ BGP (ຫຼືຄ້າຍຄືກັນກັບມັນ - ໃນກໍລະນີຂອງ TF, ນີ້ແມ່ນ XMPP 0_o).
• ຜ່ານກອງປະຊຸມນີ້, vRouter ລາຍງານເສັ້ນທາງໄປຫາເຄືອຂ່າຍທີ່ເຊື່ອມຕໍ່ໄປຫາຕົວຄວບຄຸມ SDN:
  • ທີ່ຢູ່ເຄືອຂ່າຍ
  • ວິທີການຫຸ້ມຫໍ່ (MPLSoGRE, MPLSoUDP, VXLAN)
  • ແທັກລູກຄ້າ MPLS
  • ທີ່ຢູ່ IP ຂອງທ່ານເປັນ Nexthop

• ຕົວຄວບຄຸມ SDN ໄດ້ຮັບເສັ້ນທາງດັ່ງກ່າວຈາກ vRouters ທີ່ເຊື່ອມຕໍ່ທັງໝົດ ແລະສະທ້ອນໃຫ້ເຂົາເຈົ້າໄປຫາຜູ້ອື່ນ. ນັ້ນແມ່ນ, ມັນເຮັດຫນ້າທີ່ເປັນຕົວສະທ້ອນເສັ້ນທາງ.

ສິ່ງດຽວກັນເກີດຂຶ້ນໃນທິດທາງກົງກັນຂ້າມ.

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

ຕົວຄວບຄຸມສູນກາງເບິ່ງແຍງຄວາມສັບສົນທັງຫມົດຂອງການຮັກສາການຕັ້ງຄ່າແລະການຕິດຕາມຕາຕະລາງການປ່ຽນ / ເສັ້ນທາງໃນ vRouter.

ເວົ້າປະມານ, ຕົວຄວບຄຸມຕິດຕໍ່ສື່ສານກັບ vRouters ທັງຫມົດຜ່ານ BGP (ຫຼືໂປໂຕຄອນທີ່ຄ້າຍຄືກັນ) ແລະພຽງແຕ່ສົ່ງຂໍ້ມູນເສັ້ນທາງ. ຕົວຢ່າງເຊັ່ນ BGP ມີທີ່ຢູ່-ຄອບຄົວເພື່ອບົ່ງບອກວິທີການ encapsulation MPLS-in-GRE ຫຼື MPLS-in-UDP.

ໃນຂະນະດຽວກັນ, ການຕັ້ງຄ່າຂອງເຄືອຂ່າຍ Underlay ບໍ່ປ່ຽນແປງໃນທາງໃດກໍ່ຕາມ, ໂດຍວິທີທາງການ, ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະອັດຕະໂນມັດ, ແລະງ່າຍຕໍ່ການທໍາລາຍດ້ວຍການເຄື່ອນໄຫວທີ່ງຸ່ມງ່າມ.

ອອກສູ່ໂລກພາຍນອກ

ບາງບ່ອນການຈຳລອງຕ້ອງສິ້ນສຸດ, ແລະເຈົ້າຕ້ອງອອກຈາກໂລກສະເໝືອນຈິງ. ແລະທ່ານຕ້ອງການປະຕູ payphone.

ສອງ​ວິ​ທີ​ການ​ແມ່ນ​ປະ​ຕິ​ບັດ​:

1. ມີການຕິດຕັ້ງເຣົາເຕີຮາດແວ.
2. ເຄື່ອງໃຊ້ໄດ້ຖືກເປີດຕົວທີ່ປະຕິບັດຫນ້າທີ່ຂອງ router (ແມ່ນແລ້ວ, ປະຕິບັດຕາມ SDN, ພວກເຮົາຍັງພົບກັບ VNF). ໃຫ້ໂທຫາມັນເປັນປະຕູ virtual.

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

ຂໍ້ເສຍຂອງ virtual gateway ແມ່ນວ່າຫນ່ວຍງານຂອງ router ທາງດ້ານຮ່າງກາຍຍັງມີຄໍາສັ່ງທີ່ມີຄວາມເຂັ້ມແຂງຫຼາຍກ່ວາເຄື່ອງ virtual multi-core, ແລະຊອບແວຂອງມັນ, ເຫມາະສົມກັບພື້ນຖານຮາດແວຂອງຕົນເອງ, ເຮັດວຽກທີ່ຫມັ້ນຄົງຫຼາຍ (ບໍ່​ມີ). ມັນຍັງເປັນການຍາກທີ່ຈະປະຕິເສດຄວາມຈິງທີ່ວ່າຮາດແວແລະຊອບແວສະລັບສັບຊ້ອນພຽງແຕ່ເຮັດວຽກ, ຮຽກຮ້ອງໃຫ້ມີການຕັ້ງຄ່າເທົ່ານັ້ນ, ໃນຂະນະທີ່ການເປີດຕົວແລະການຮັກສາປະຕູ virtual ແມ່ນວຽກງານສໍາລັບວິສະວະກອນທີ່ເຂັ້ມແຂງ.

ດ້ວຍຕີນດຽວ, ປະຕູຈະເບິ່ງເຂົ້າໄປໃນເຄືອຂ່າຍສະເໝືອນ Overlay, ຄືກັບ Virtual Machine ປົກກະຕິ, ແລະສາມາດພົວພັນກັບ VMs ອື່ນໆທັງໝົດໄດ້. ໃນເວລາດຽວກັນ, ມັນສາມາດຢຸດເຄືອຂ່າຍຂອງລູກຄ້າທັງຫມົດແລະ, ຕາມຄວາມເຫມາະສົມ, ປະຕິບັດເສັ້ນທາງລະຫວ່າງພວກເຂົາ.

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

ຍົນຂໍ້ມູນ

ນັ້ນແມ່ນ, ຂະບວນການເບິ່ງຄືວ່າ:

1. VM-0, ໂດຍມີຄ່າເລີ່ມຕົ້ນກັບ vRouter ດຽວກັນ, ສົ່ງແພັກເກັດທີ່ມີປາຍທາງຢູ່ໃນໂລກພາຍນອກ (185.147.83.177) ໄປຫາສ່ວນຕິດຕໍ່ eth0.
2. vRouter ໄດ້ຮັບແພັກເກັດນີ້ແລະຊອກຫາທີ່ຢູ່ປາຍທາງໃນຕາຕະລາງການກໍານົດເສັ້ນທາງ - ຊອກຫາເສັ້ນທາງເລີ່ມຕົ້ນຜ່ານປະຕູ VNGW1 ຜ່ານ Tunnel 1.
   ລາວຍັງເຫັນວ່ານີ້ແມ່ນອຸໂມງ GRE ທີ່ມີ SIP 10.0.0.2 ແລະ DIP 10.0.255.2, ແລະລາວຍັງຕ້ອງຕິດປ້າຍ MPLS ຂອງລູກຄ້ານີ້ກ່ອນ, ເຊິ່ງ VNGW1 ຄາດວ່າ.
3. vRouter ບັນຈຸແພັກເກັດເບື້ອງຕົ້ນດ້ວຍ MPLS, GRE ແລະຫົວ IP ໃໝ່ ແລະສົ່ງໄປທີ່ ToR1 10.0.0.1 ໂດຍຄ່າເລີ່ມຕົ້ນ.
4. ເຄືອຂ່າຍພື້ນຖານສົ່ງແພັກເກັດໄປຫາປະຕູ VNGW1.
5. ປະຕູຮົ້ວ VNGW1 ເອົາສ່ວນຫົວຂອງອຸໂມງ GRE ແລະ MPLS, ເບິ່ງທີ່ຢູ່ປາຍທາງ, ປຶກສາຫາລືຕາຕະລາງເສັ້ນທາງຂອງມັນແລະເຂົ້າໃຈວ່າມັນຖືກນໍາໄປຫາອິນເຕີເນັດ - ນັ້ນແມ່ນ, ຜ່ານ Full View ຫຼື Default. ຖ້າຈໍາເປັນ, ດໍາເນີນການແປພາສາ NAT.
6. ອາດຈະມີເຄືອຂ່າຍ IP ປົກກະຕິຈາກ VNGW ໄປຫາຊາຍແດນ, ເຊິ່ງເປັນໄປບໍ່ໄດ້.
   ອາດຈະມີເຄືອຂ່າຍ MPLS ຄລາສສິກ (IGP+LDP/RSVP TE), ອາດຈະມີຜ້າກັບຄືນໄປບ່ອນທີ່ມີ BGP LU ຫຼືອຸໂມງ GRE ຈາກ VNGW ໄປຫາຊາຍແດນຜ່ານເຄືອຂ່າຍ IP.
   ຍ້ອນວ່າມັນອາດຈະ, VNGW1 ປະຕິບັດການຫຸ້ມຫໍ່ທີ່ຈໍາເປັນແລະສົ່ງຊຸດເບື້ອງຕົ້ນໄປສູ່ຊາຍແດນ.

ການຈະລາຈອນໃນທິດທາງກົງກັນຂ້າມຜ່ານຂັ້ນຕອນດຽວກັນໃນຄໍາສັ່ງກົງກັນຂ້າມ.

1. ຊາຍແດນຫຼຸດລົງຊອງເປັນ VNGW1
2. ລາວ undresses ລາວ, ເບິ່ງທີ່ຢູ່ຂອງຜູ້ຮັບແລະເຫັນວ່າລາວສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານອຸໂມງ Tunnel1 (MPLSoGRE ຫຼື MPLSoUDP).
3. ຕາມນັ້ນແລ້ວ, ມັນຕິດປ້າຍ MPLS, ຫົວ GRE/UDP ແລະ IP ໃໝ່ ແລະສົ່ງໄປທີ່ ToR3 10.0.255.1 ຂອງມັນ.
   ທີ່ຢູ່ປາຍທາງອຸໂມງແມ່ນທີ່ຢູ່ IP ຂອງ vRouter ທີ່ຢູ່ເບື້ອງຫຼັງທີ່ VM ເປົ້າໝາຍຕັ້ງຢູ່ - 10.0.0.2.
4. ເຄືອຂ່າຍພື້ນຖານສົ່ງແພັກເກັດໄປຫາ vRouter ທີ່ຕ້ອງການ.
5. vRouter ເປົ້າຫມາຍອ່ານ GRE/UDP, ກໍານົດການໂຕ້ຕອບໂດຍໃຊ້ປ້າຍ MPLS ແລະສົ່ງຊຸດ IP ເປົ່າໄປຫາສ່ວນຕິດຕໍ່ TAP ຂອງມັນທີ່ກ່ຽວຂ້ອງກັບ eth0 ຂອງ VM.

ຍົນຄວບຄຸມ

VNGW1 ສ້າງຕັ້ງເຂດບ້ານ BGP ທີ່ມີຕົວຄວບຄຸມ SDN, ຈາກທີ່ມັນໄດ້ຮັບຂໍ້ມູນເສັ້ນທາງທັງຫມົດກ່ຽວກັບລູກຄ້າ: ທີ່ຢູ່ IP (vRouter) ທີ່ຢູ່ເບື້ອງຫຼັງລູກຄ້າໃດ, ແລະປ້າຍ MPLS ໃດຖືກລະບຸໂດຍ.

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

ໃນ VNGW, ການລວບລວມເສັ້ນທາງຫຼືການແປພາສາ NAT ມັກຈະເກີດຂື້ນ.

ແລະໃນທິດທາງອື່ນ, ມັນສົ່ງແນ່ນອນເສັ້ນທາງລວມນີ້ໄປຫາກອງປະຊຸມທີ່ມີຊາຍແດນຕິດຫຼື Route Reflectors. ແລະຈາກພວກມັນມັນໄດ້ຮັບເສັ້ນທາງເລີ່ມຕົ້ນຫຼື Full-View, ຫຼືບາງສິ່ງບາງຢ່າງອື່ນ.

ໃນແງ່ຂອງການຫຸ້ມຫໍ່ແລະການແລກປ່ຽນການຈະລາຈອນ, VNGW ແມ່ນບໍ່ແຕກຕ່າງຈາກ vRouter.
ຖ້າທ່ານຂະຫຍາຍຂອບເຂດເລັກນ້ອຍ, ທ່ານສາມາດເພີ່ມອຸປະກອນເຄືອຂ່າຍອື່ນໆໃຫ້ກັບ VNGWs ແລະ vRouters, ເຊັ່ນໄຟວໍ, ການເຮັດຄວາມສະອາດການຈະລາຈອນຫຼືກະສິກໍາເສີມສ້າງ, IPS, ແລະອື່ນໆ.

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

ນັ້ນແມ່ນ, ຕົວຄວບຄຸມ SDN ເຮັດຫນ້າທີ່ເປັນ Route-Reflector ລະຫວ່າງ VNGWs, vRouters ແລະອຸປະກອນເຄືອຂ່າຍອື່ນໆ.

ແຕ່ໃນຄວາມເປັນຈິງ, ຕົວຄວບຄຸມຍັງປ່ອຍຂໍ້ມູນກ່ຽວກັບ ACL ແລະ PBR (ເສັ້ນທາງທີ່ອີງໃສ່ນະໂຍບາຍ), ເຮັດໃຫ້ການໄຫຼເຂົ້າຂອງແຕ່ລະບຸກຄົນແຕກຕ່າງກັນຫຼາຍກ່ວາເສັ້ນທາງບອກພວກເຂົາ.

FAQ

ເປັນຫຍັງເຈົ້າຈຶ່ງຕັ້ງຂໍ້ສັງເກດ GRE/UDP ສະເໝີ?

ດີ, ໂດຍທົ່ວໄປ, ນີ້ສາມາດເວົ້າໄດ້ສະເພາະກັບຜ້າ Tungsten - ທ່ານບໍ່ຈໍາເປັນຕ້ອງພິຈາລະນາມັນທັງຫມົດ.

ແຕ່ຖ້າພວກເຮົາເອົາມັນ, ຫຼັງຈາກນັ້ນ TF ຕົວຂອງມັນເອງ, ໃນຂະນະທີ່ຍັງ OpenContrail, ສະຫນັບສະຫນູນທັງສອງ encapsulations: MPLS ໃນ GRE ແລະ MPLS ໃນ UDP.

UDP ແມ່ນດີເພາະວ່າໃນ Source Port ມັນງ່າຍຫຼາຍທີ່ຈະເຂົ້າລະຫັດຟັງຊັນ hash ຈາກ IP + Proto + Port ຕົ້ນສະບັບໃນສ່ວນຫົວຂອງມັນ, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານເຮັດການດຸ່ນດ່ຽງໄດ້.

ໃນກໍລະນີຂອງ GRE, ອະນິຈາ, ມີພຽງແຕ່ IP ແລະ GRE headers ພາຍນອກ, ເຊິ່ງແມ່ນຄືກັນສໍາລັບການຈະລາຈອນ encapsulated ທັງຫມົດແລະບໍ່ມີການເວົ້າກ່ຽວກັບການດຸ່ນດ່ຽງ - ມີຄົນຈໍານວນຫນ້ອຍທີ່ສາມາດເບິ່ງເລິກພາຍໃນຊອງ.

ຈົນກ່ວາບາງເວລາ, routers, ຖ້າພວກເຂົາຮູ້ວິທີການນໍາໃຊ້ tunnels ແບບເຄື່ອນໄຫວ, ໄດ້ພຽງແຕ່ໃນ MPLSoGRE, ແລະພຽງແຕ່ບໍ່ດົນມານີ້ພວກເຂົາເຈົ້າໄດ້ຮຽນຮູ້ການນໍາໃຊ້ MPLSoUDP. ເພາະສະນັ້ນ, ພວກເຮົາສະເຫມີຕ້ອງເຮັດບັນທຶກກ່ຽວກັບຄວາມເປັນໄປໄດ້ຂອງສອງ encapsulations ທີ່ແຕກຕ່າງກັນ.

ໃນຄວາມຍຸດຕິທໍາ, ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ TF ສະຫນັບສະຫນູນການເຊື່ອມຕໍ່ L2 ຢ່າງເຕັມສ່ວນໂດຍໃຊ້ VXLAN.

ທ່ານສັນຍາວ່າຈະແຕ້ມຂະຫນານກັບ OpenFlow.
ເຂົາເຈົ້າຂໍເອົາແທ້ໆ. vSwitch ໃນ OpenStack ດຽວກັນເຮັດສິ່ງທີ່ຄ້າຍຄືກັນຫຼາຍ, ການນໍາໃຊ້ VXLAN, ເຊິ່ງ, ໂດຍວິທີທາງການ, ຍັງມີຫົວ UDP.

ໃນ Data Plane ພວກເຂົາເຮັດວຽກປະມານດຽວກັນ; ຍົນຄວບຄຸມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍ. Tungsten Fabric ໃຊ້ XMPP ເພື່ອສົ່ງຂໍ້ມູນເສັ້ນທາງໄປຫາ vRouter, ໃນຂະນະທີ່ OpenStack ແລ່ນ Openflow.

ທ່ານສາມາດບອກຂ້ອຍຕື່ມອີກເລັກນ້ອຍກ່ຽວກັບ vRouter ໄດ້ບໍ?
ມັນແບ່ງອອກເປັນສອງສ່ວນ: vRouter Agent ແລະ vRouter Forwarder.

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

ອັນທີສອງປະຕິບັດການວາງແຜນຂໍ້ມູນ - ປົກກະຕິແລ້ວຢູ່ໃນ Kernel Space, ແຕ່ຍັງສາມາດດໍາເນີນການໃນ SmartNICs - ບັດເຄືອຂ່າຍທີ່ມີ CPU ແລະຊິບປ່ຽນໂຄງການແຍກຕ່າງຫາກ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເອົາການໂຫຼດອອກຈາກ CPU ຂອງເຄື່ອງໂຮດ, ແລະເຮັດໃຫ້ເຄືອຂ່າຍໄວຂຶ້ນແລະຫຼາຍ. ຄາດ​ຄະ​ເນ.

ສະຖານະການທີ່ເປັນໄປໄດ້ອີກອັນຫນຶ່ງແມ່ນວ່າ vRouter ເປັນແອັບພລິເຄຊັນ DPDK ໃນພື້ນທີ່ຜູ້ໃຊ້.

vRouter Agent ສົ່ງການຕັ້ງຄ່າໄປຫາ vRouter Forwarder.

ເຄືອຂ່າຍສະເໝືອນຈິງແມ່ນຫຍັງ?
ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງໃນຕອນຕົ້ນຂອງບົດຄວາມກ່ຽວກັບ VRF ວ່າຜູ້ເຊົ່າແຕ່ລະຄົນຖືກຜູກມັດກັບ VRF ຂອງຕົນເອງ. ແລະຖ້າຫາກວ່ານີ້ແມ່ນພຽງພໍສໍາລັບຄວາມເຂົ້າໃຈ superficial ຂອງການດໍາເນີນງານຂອງເຄືອຂ່າຍ overlay, ຫຼັງຈາກນັ້ນໃນ iteration ຕໍ່ໄປ, ມັນເປັນສິ່ງຈໍາເປັນເພື່ອເຮັດໃຫ້ຄວາມກະຈ່າງແຈ້ງ.

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

ດັ່ງນັ້ນ, ດັ່ງນັ້ນ, ບໍ່ມີການຕິດຕໍ່ໂດຍກົງລະຫວ່າງ Virtual Network ແລະຜູ້ເຊົ່າ.

ສະຫລຸບ

ນີ້ແມ່ນຄຳອະທິບາຍທີ່ຫຼູຫຼາຫຼາຍຂອງການເຮັດວຽກຂອງເຄືອຂ່າຍສະເໝືອນທີ່ມີການຊ້ອນກັນຈາກໂຮດ ແລະຕົວຄວບຄຸມ SDN. ແຕ່ບໍ່ວ່າເວທີ virtualization ໃດກໍ່ຕາມທີ່ທ່ານເລືອກໃນມື້ນີ້, ມັນຈະເຮັດວຽກໃນລັກສະນະທີ່ຄ້າຍຄືກັນ, ບໍ່ວ່າຈະເປັນ VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ຫຼື Juniper Contrail. ພວກມັນຈະແຕກຕ່າງກັນໃນປະເພດຂອງ encapsulations ແລະ headers, protocols ສໍາລັບການສົ່ງຂໍ້ມູນໄປຍັງອຸປະກອນເຄືອຂ່າຍສຸດທ້າຍ, ແຕ່ຫຼັກການຂອງເຄືອຂ່າຍ overlay ທີ່ສາມາດກໍາຫນົດຄ່າຊອບແວທີ່ເຮັດວຽກຢູ່ເທິງເຄືອຂ່າຍ underlay ຂ້ອນຂ້າງງ່າຍດາຍແລະຄົງທີ່ຈະຍັງຄົງຄືກັນ.
ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າໃນມື້ນີ້ SDN ໂດຍອີງໃສ່ເຄືອຂ່າຍ overlay ໄດ້ຊະນະພາກສະຫນາມຂອງການສ້າງຄລາວສ່ວນຕົວ. ຢ່າງໃດກໍ່ຕາມ, ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າ Openflow ບໍ່ມີບ່ອນຢູ່ໃນໂລກທີ່ທັນສະໄຫມ - ມັນຖືກນໍາໃຊ້ໃນ OpenStacke ແລະໃນ VMWare NSX ດຽວກັນ, ເທົ່າທີ່ຂ້ອຍຮູ້, Google ໃຊ້ມັນເພື່ອຕັ້ງເຄືອຂ່າຍໃຕ້ດິນ.

ຂ້າງລຸ່ມນີ້ຂ້າພະເຈົ້າໄດ້ສະຫນອງການເຊື່ອມຕໍ່ກັບອຸປະກອນລາຍລະອຽດເພີ່ມເຕີມຖ້າຫາກວ່າທ່ານຕ້ອງການທີ່ຈະສຶກສາບັນຫາທີ່ເລິກເຊິ່ງ.

ແລະສິ່ງທີ່ກ່ຽວກັບ Underlay ຂອງພວກເຮົາ?

ແຕ່ໂດຍທົ່ວໄປ, ບໍ່ມີຫຍັງ. ລາວບໍ່ໄດ້ປ່ຽນແປງທັງຫມົດ. ທັງຫມົດທີ່ລາວຕ້ອງເຮັດໃນກໍລະນີຂອງການຊ້ອນກັນຈາກເຈົ້າພາບແມ່ນການປັບປຸງເສັ້ນທາງແລະ ARPs ຍ້ອນວ່າ vRouter / VNGW ປາກົດແລະຫາຍໄປແລະເອົາແພັກເກັດລະຫວ່າງພວກມັນ.

ໃຫ້ພວກເຮົາສ້າງບັນຊີລາຍຊື່ຂອງຄວາມຕ້ອງການສໍາລັບເຄືອຂ່າຍ Underlay.

1. ສາມາດນໍາໃຊ້ບາງປະເພດຂອງໂປໂຕຄອນການກໍານົດເສັ້ນທາງ, ໃນສະຖານະການຂອງພວກເຮົາ - BGP.
2. ມີແບນວິດກວ້າງ, ດີກວ່າໂດຍບໍ່ມີການຈອງເກີນ, ເພື່ອບໍ່ໃຫ້ແພັກເກັດຖືກສູນເສຍຍ້ອນການໂຫຼດເກີນ.
3. ການສະຫນັບສະຫນູນ ECMP ແມ່ນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງຜ້າ.
4. ສາມາດສະຫນອງ QoS, ລວມທັງສິ່ງທີ່ຫຍຸ້ງຍາກເຊັ່ນ ECN.
5. ສະຫນັບສະຫນູນ NETCONF ເປັນພື້ນຖານສໍາລັບອະນາຄົດ.

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

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

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

ເປັນສ່ວນຫນຶ່ງຂອງ ADSM, Roman Gorge ແລະຂ້ອຍວາງແຜນທີ່ຈະເຜີຍແຜ່ບັນຫາແຍກຕ່າງຫາກກ່ຽວກັບ virtualization ຂອງພະລັງງານຄອມພິວເຕີ້ແລະການພົວພັນກັບ virtualization ເຄືອຂ່າຍ. ຕິດຕໍ່ກັນ.

ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ

• ສະຖາປັດຕະຍະກໍາຜ້າ Tungsten.
• ກ່ຽວກັບ: cloud. 6 ຊົ່ວໂມງກ່ຽວກັບ Yandex.Cloud, ເຊິ່ງຍັງກວມເອົາເຄືອຂ່າຍ virtual ໃນ TF.
• Open vSwitch ແມ່ນຫຍັງ?
• ແນະນຳກ່ຽວກັບ VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): ກອບສໍາລັບການວາງຊ້ອນຊັ້ນ Virtualized 2 ເຄືອຂ່າຍໃນໄລຍະ 3 ເຄືອຂ່າຍ.
  
• ວິທີການ Scaleway ກັບ VXLAN EVPN Fabric. ມັນເວົ້າກ່ຽວກັບເຄືອຂ່າຍ DC ທັງຫມົດ, ລວມທັງ Underlay, Overlay, ເຂົ້າຫາ multi-homing ແລະການຄຸ້ມຄອງ.

ຂອບ​ໃຈ

• Roman Gorga - ອະດີດເຈົ້າພາບຂອງ linkmeup podcast ແລະປະຈຸບັນເປັນຜູ້ຊ່ຽວຊານໃນພາກສະຫນາມຂອງເວທີຟັງ. ສໍາລັບຄໍາເຫັນແລະການແກ້ໄຂ. ດີ, ພວກເຮົາກໍາລັງລໍຖ້າບົດຄວາມທີ່ເລິກເຊິ່ງຂອງລາວກ່ຽວກັບ virtualization ໃນອະນາຄົດອັນໃກ້ນີ້.
• Alexander Shalimov - ເພື່ອນຮ່ວມງານຂອງຂ້ອຍແລະຜູ້ຊ່ຽວຊານໃນດ້ານການພັດທະນາເຄືອຂ່າຍ virtual. ສໍາລັບຄໍາເຫັນແລະການແກ້ໄຂ.
• Valentin Sinitsyn - ເພື່ອນຮ່ວມງານຂອງຂ້ອຍແລະຜູ້ຊ່ຽວຊານໃນຂົງເຂດຜ້າ Tungsten. ສໍາລັບຄໍາເຫັນແລະການແກ້ໄຂ.
• Artyom Chernobay - illustrator linkmeup. ສໍາລັບ KDPV.
• Alexander Limonov. ສໍາລັບ meme "automato".

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