ແນະນໍາພາກສ່ວນເຄືອຂ່າຍຂອງໂຄງສ້າງພື້ນຖານຄລາວ

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

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

ເມກແມ່ນຫຍັງ? virtualization ດຽວກັນ - ເບິ່ງໂປຣໄຟລ໌?

ຫຼາຍກ່ວາຄໍາຖາມທີ່ມີເຫດຜົນ. ບໍ່ - ນີ້ບໍ່ແມ່ນ virtualization, ເຖິງແມ່ນວ່າມັນບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີມັນ. ຂໍ​ໃຫ້​ເບິ່ງ​ສອງ​ຄໍາ​ນິ​ຍາມ​:

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

Virtualization - ນີ້ແມ່ນຄວາມສາມາດໃນການແບ່ງຫນ່ວຍງານທາງດ້ານຮ່າງກາຍຫນຶ່ງ (ຕົວຢ່າງເຊັ່ນເຄື່ອງແມ່ຂ່າຍ) ເຂົ້າໄປໃນ virtual ຫຼາຍ, ດັ່ງນັ້ນການເພີ່ມການນໍາໃຊ້ຊັບພະຍາກອນ (ຕົວຢ່າງ, ທ່ານມີ 3 ເຄື່ອງແມ່ຂ່າຍທີ່ໂຫລດຢູ່ທີ່ 25-30 ເປີເຊັນ, ຫຼັງຈາກ virtualization ທ່ານໄດ້ຮັບ 1 server loaded. 80-90 ເປີເຊັນ). ຕາມທໍາມະຊາດ, virtualization ກິນເຖິງບາງສ່ວນຂອງຊັບພະຍາກອນ - ທ່ານຈໍາເປັນຕ້ອງໃຫ້ອາຫານ hypervisor ໄດ້, ຢ່າງໃດກໍຕາມ, ເປັນການປະຕິບັດໄດ້ສະແດງໃຫ້ເຫັນ, ເກມແມ່ນຕົກເປັນມູນຄ່າທຽນໄຂ. ຕົວຢ່າງທີ່ເຫມາະສົມສໍາລັບ virtualization ແມ່ນ VMWare, ເຊິ່ງກະກຽມເຄື່ອງຈັກ virtual ຢ່າງສົມບູນ, ຫຼືຕົວຢ່າງ KVM, ທີ່ຂ້ອຍມັກ, ແຕ່ນີ້ແມ່ນເລື່ອງຂອງລົດຊາດ.

ພວກເຮົາໃຊ້ virtualization ໂດຍບໍ່ຮູ້ຕົວ, ແລະແມ້ແຕ່ routers ທາດເຫຼັກກໍ່ໃຊ້ virtualization ແລ້ວ - ຕົວຢ່າງ, ໃນ JunOS ຮຸ່ນຫຼ້າສຸດ, ລະບົບປະຕິບັດການໄດ້ຖືກຕິດຕັ້ງເປັນເຄື່ອງ virtual ຢູ່ເທິງສຸດຂອງການແຈກຢາຍ Linux ໃນເວລາທີ່ແທ້ຈິງ (Wind River 9). ແຕ່ virtualization ບໍ່ແມ່ນ cloud, ແຕ່ cloud ບໍ່ສາມາດມີຢູ່ໂດຍບໍ່ມີການ virtualization.

Virtualization ແມ່ນຫນຶ່ງໃນບັນດາສິ່ງກໍ່ສ້າງທີ່ຟັງໄດ້ຖືກສ້າງຂຶ້ນ.

ການສ້າງເມຄໂດຍພຽງແຕ່ລວບລວມ hypervisors ຫຼາຍເຂົ້າໄປໃນໂດເມນ L2 ຫນຶ່ງ, ເພີ່ມຄູ່ຂອງ yaml playbooks ສໍາລັບການລົງທະບຽນອັດຕະໂນມັດ vlans ຜ່ານບາງປະເພດຂອງ ansible ແລະ jamming ບາງສິ່ງບາງຢ່າງເຊັ່ນ: ລະບົບ orchestration ໃສ່ມັນທັງຫມົດສໍາລັບການສ້າງ virtual machines ອັດຕະໂນມັດຈະບໍ່ເຮັດວຽກ. ມັນຈະຖືກຕ້ອງກວ່າ, ແຕ່ຜົນໄດ້ຮັບ Frankenstein ບໍ່ແມ່ນເມຄທີ່ພວກເຮົາຕ້ອງການ, ເຖິງແມ່ນວ່າມັນອາດຈະເປັນຄວາມຝັນສູງສຸດສໍາລັບຄົນອື່ນ. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານເອົາ Openstack ດຽວກັນ, ມັນກໍ່ແມ່ນ Frankenstein, ແຕ່ໂອ້, ຂໍໃຫ້ເຮົາບໍ່ເວົ້າກ່ຽວກັບເລື່ອງນັ້ນໃນຕອນນີ້.

ແຕ່ຂ້ອຍເຂົ້າໃຈວ່າຈາກຄໍານິຍາມທີ່ນໍາສະເຫນີຂ້າງເທິງນັ້ນມັນບໍ່ຊັດເຈນທັງຫມົດສິ່ງທີ່ສາມາດເອີ້ນວ່າຟັງໄດ້.

ດັ່ງນັ້ນ, ເອກະສານຈາກ NIST (ສະຖາບັນມາດຕະຖານ ແລະ ເຕັກໂນໂລຊີແຫ່ງຊາດ) ໃຫ້ 5 ລັກສະນະຕົ້ນຕໍທີ່ພື້ນຖານໂຄງລ່າງຄລາວຄວນມີ:

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

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

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

ການປັບຕົວໄວກັບເງື່ອນໄຂທີ່ແຕກຕ່າງກັນ. ການບໍລິການຕ້ອງມີຄວາມຍືດຫຍຸ່ນ - ການສະຫນອງຊັບພະຍາກອນຢ່າງໄວວາ, ການແຈກຢາຍຄືນໃຫມ່ຂອງພວກເຂົາ, ເພີ່ມຫຼືຫຼຸດຜ່ອນຊັບພະຍາກອນຕາມຄໍາຮ້ອງຂໍຂອງລູກຄ້າ, ແລະໃນສ່ວນຂອງລູກຄ້າຄວນຈະມີຄວາມຮູ້ສຶກວ່າຊັບພະຍາກອນຟັງແມ່ນບໍ່ມີທີ່ສິ້ນສຸດ. ສໍາ​ລັບ​ຄວາມ​ງ່າຍ​ຂອງ​ການ​ເຂົ້າ​ໃຈ​, ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ​, ທ່ານ​ບໍ່​ໄດ້​ເຫັນ​ການ​ເຕືອນ​ວ່າ​ສ່ວນ​ຫນຶ່ງ​ຂອງ​ຊ່ອງ​ແຜ່ນ​ຂອງ​ທ່ານ​ໃນ Apple iCloud ໄດ້​ຫາຍ​ໄປ​ເນື່ອງ​ຈາກ​ວ່າ​ຮາດ​ດິດ​ໃນ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ໄດ້​ແຕກ​ຫັກ​, ແລະ​ການ​ຂັບ​ລົດ​ເຮັດ​ໃຫ້​ແຕກ​. ນອກຈາກນັ້ນ, ໃນສ່ວນຂອງທ່ານ, ຄວາມເປັນໄປໄດ້ຂອງການບໍລິການນີ້ແມ່ນເກືອບບໍ່ຈໍາກັດ - ທ່ານຕ້ອງການ 2 TB - ບໍ່ມີບັນຫາ, ທ່ານໄດ້ຈ່າຍແລະໄດ້ຮັບມັນ. ຕົວຢ່າງທີ່ຄ້າຍຄືກັນສາມາດໃຫ້ກັບ Google.Drive ຫຼື Yandex.Disk.

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

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

ເປັນຫຍັງພວກເຮົາຕ້ອງການຟັງ?

ຢ່າງໃດກໍ່ຕາມ, ເຕັກໂນໂລຢີໃຫມ່ຫຼືທີ່ມີຢູ່ແລ້ວ, ໂປໂຕຄອນໃຫມ່ໃດໆກໍ່ຖືກສ້າງຂຶ້ນສໍາລັບບາງສິ່ງບາງຢ່າງ (ດີ, ຍົກເວັ້ນ RIP-ng, ແນ່ນອນ). ບໍ່ມີໃຜຕ້ອງການໂປໂຕຄອນເພື່ອຜົນປະໂຫຍດຂອງໂປໂຕຄອນ (ດີ, ຍົກເວັ້ນສໍາລັບ RIP-ng, ແນ່ນອນ). ມັນສົມເຫດສົມຜົນທີ່ Cloud ຖືກສ້າງຂຶ້ນເພື່ອໃຫ້ບໍລິການບາງປະເພດໃຫ້ກັບຜູ້ໃຊ້ / ລູກຄ້າ. ພວກເຮົາທຸກຄົນຄຸ້ນເຄີຍກັບຢ່າງຫນ້ອຍສອງສາມບໍລິການຄລາວ, ຕົວຢ່າງ Dropbox ຫຼື Google.Docs, ແລະຂ້ອຍເຊື່ອວ່າຄົນສ່ວນໃຫຍ່ໃຊ້ພວກມັນຢ່າງສໍາເລັດຜົນ - ຕົວຢ່າງ, ບົດຄວາມນີ້ຖືກຂຽນໂດຍໃຊ້ Google.Docs cloud service. ແຕ່ການບໍລິການຄລາວທີ່ພວກເຮົາຮູ້ຈັກເປັນພຽງສ່ວນໜຶ່ງຂອງຄວາມສາມາດຂອງຄລາວເທົ່ານັ້ນ—ທີ່ຊັດເຈນກວ່ານັ້ນ, ພວກມັນເປັນບໍລິການປະເພດ SaaS ເທົ່ານັ້ນ. ພວກເຮົາສາມາດໃຫ້ບໍລິການຟັງໄດ້ສາມວິທີ: ໃນຮູບແບບຂອງ SaaS, PaaS ຫຼື IaaS. ການບໍລິການອັນໃດທີ່ທ່ານຕ້ອງການແມ່ນຂຶ້ນກັບຄວາມປາຖະໜາ ແລະຄວາມສາມາດຂອງທ່ານ.

ໃຫ້ເບິ່ງແຕ່ລະລໍາດັບ:

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

ແພລະຕະຟອມເປັນບໍລິການ (PaaS) — ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ຮູບ​ແບບ​ນີ້​, ຜູ້​ໃຫ້​ບໍ​ລິ​ການ​ໃຫ້​ລູກ​ຄ້າ​ມີ workpiece ສໍາ​ລັບ​ການ​ບໍ​ລິ​ການ​, ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ​, ໃຫ້​ເອົາ​ເວັບ​ເຊີ​ເວີ​. ຜູ້ໃຫ້ບໍລິການໄດ້ໃຫ້ລູກຄ້າມີເຄື່ອງແມ່ຂ່າຍ virtual (ໃນຄວາມເປັນຈິງ, ຊຸດຂອງຊັບພະຍາກອນ, ເຊັ່ນ RAM / CPU / Storage / Nets, ແລະອື່ນໆ), ແລະແມ້ກະທັ້ງຕິດຕັ້ງ OS ແລະຊອບແວທີ່ຈໍາເປັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍນີ້, ແນວໃດກໍ່ຕາມ, ການຕັ້ງຄ່າຂອງ. ສິ່ງທັງຫມົດນີ້ແມ່ນເຮັດໂດຍລູກຄ້າເອງແລະສໍາລັບການປະຕິບັດການບໍລິການລູກຄ້າຕອບ. ຜູ້ໃຫ້ບໍລິການ, ເຊັ່ນດຽວກັບກໍລະນີທີ່ຜ່ານມາ, ມີຄວາມຮັບຜິດຊອບຕໍ່ການປະຕິບັດຂອງອຸປະກອນທາງດ້ານຮ່າງກາຍ, hypervisors, ເຄື່ອງ virtual ຕົວຂອງມັນເອງ, ເຄືອຂ່າຍຂອງຕົນ, ແລະອື່ນໆ, ແຕ່ການບໍລິການຕົວມັນເອງບໍ່ໄດ້ຢູ່ໃນພື້ນທີ່ຄວາມຮັບຜິດຊອບຂອງມັນ.

ໂຄງລ່າງພື້ນຖານທີ່ເປັນການບໍລິການ (IaaS) - ວິທີການນີ້ແມ່ນຫນ້າສົນໃຈຫຼາຍ, ໃນຄວາມເປັນຈິງ, ຜູ້ໃຫ້ບໍລິການໃຫ້ລູກຄ້າມີໂຄງສ້າງພື້ນຖານ virtualized ຄົບຖ້ວນ - ນັ້ນແມ່ນ, ບາງຊຸດ (ສະນຸກເກີ) ຂອງຊັບພະຍາກອນ, ເຊັ່ນ CPU Cores, RAM, Networks, ແລະອື່ນໆ. ທຸກສິ່ງທຸກຢ່າງແມ່ນຂຶ້ນກັບ. ລູກຄ້າ - ສິ່ງທີ່ລູກຄ້າຕ້ອງການເຮັດກັບຊັບພະຍາກອນເຫຼົ່ານີ້ພາຍໃນສະນຸກເກີທີ່ຈັດສັນ (ໂຄຕ້າ) - ມັນບໍ່ສໍາຄັນໂດຍສະເພາະສໍາລັບຜູ້ສະຫນອງ. ບໍ່ວ່າລູກຄ້າຕ້ອງການສ້າງ vEPC ຂອງຕົນເອງຫຼືແມ້ກະທັ້ງສ້າງຜູ້ປະຕິບັດງານ mini ແລະໃຫ້ບໍລິການການສື່ສານ - ບໍ່ມີຄໍາຖາມ - ເຮັດມັນ. ໃນສະຖານະການດັ່ງກ່າວ, ຜູ້ໃຫ້ບໍລິການມີຄວາມຮັບຜິດຊອບໃນການສະຫນອງຊັບພະຍາກອນ, ຄວາມທົນທານແລະຄວາມຜິດຂອງເຂົາເຈົ້າ, ເຊັ່ນດຽວກັນກັບ OS ທີ່ອະນຸຍາດໃຫ້ພວກເຂົາລວບລວມຊັບພະຍາກອນເຫຼົ່ານີ້ແລະເຮັດໃຫ້ລູກຄ້າມີຄວາມສາມາດໃນການເພີ່ມຫຼືຫຼຸດລົງຊັບພະຍາກອນໄດ້ທຸກເວລາ. ຕາມການຮ້ອງຂໍຂອງລູກຄ້າ. ລູກຄ້າກໍາຫນົດຄ່າເຄື່ອງ virtual ທັງຫມົດແລະ tinsel ອື່ນໆດ້ວຍຕົນເອງໂດຍຜ່ານປະຕູບໍລິການຕົນເອງແລະ console, ລວມທັງການຕັ້ງຄ່າເຄືອຂ່າຍ (ຍົກເວັ້ນເຄືອຂ່າຍພາຍນອກ).

OpenStack ແມ່ນຫຍັງ?

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

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

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

ໃນເວລາທີ່ຂຽນເອກະສານນີ້, ໂຄງສ້າງ OpenStack ເບິ່ງຄືວ່ານີ້:

ຮູບພາບມາຈາກ openstack.org

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

• Dashboard — GUI ທີ່ອີງໃສ່ເວັບສໍາລັບການຄຸ້ມຄອງການບໍລິການ OpenStack
• Keystone ເປັນການບໍລິການຕົວຕົນທີ່ເປັນສູນກາງທີ່ສະຫນອງການທໍາງານຂອງການກວດສອບຄວາມຖືກຕ້ອງແລະການອະນຸຍາດສໍາລັບການບໍລິການອື່ນໆ, ເຊັ່ນດຽວກັນກັບການຄຸ້ມຄອງຂໍ້ມູນປະຈໍາຕົວຂອງຜູ້ໃຊ້ແລະພາລະບົດບາດຂອງເຂົາເຈົ້າ.
• Neutron - ການ​ບໍ​ລິ​ການ​ເຄືອ​ຂ່າຍ​ທີ່​ສະ​ຫນອງ​ການ​ເຊື່ອມ​ຕໍ່​ລະ​ຫວ່າງ​ການ​ໂຕ້​ຕອບ​ຂອງ​ການ​ບໍ​ລິ​ການ OpenStack ຕ່າງໆ (ລວມ​ທັງ​ການ​ເຊື່ອມ​ຕໍ່​ລະ​ຫວ່າງ VMs ແລະ​ການ​ເຂົ້າ​ເຖິງ​ໂລກ​ພາຍ​ນອກ​)
• Cinder — ສະ​ຫນອງ​ການ​ເຂົ້າ​ເຖິງ​ການ​ປິດ​ການ​ເກັບ​ຮັກ​ສາ​ສໍາ​ລັບ​ເຄື່ອງ virtual​
• Nova - ການຄຸ້ມຄອງວົງຈອນຊີວິດຂອງເຄື່ອງ virtual
• ການເບິ່ງດວງຕາ — ບ່ອນ​ເກັບ​ຂໍ້​ມູນ​ຂອງ​ຮູບ​ພາບ​ເຄື່ອງ virtual ແລະ​ພາບ​ຖ່າຍ​
• Swift — ໃຫ້ການເຂົ້າເຖິງວັດຖຸເກັບຮັກສາ
• Ceilometer — ເປັນ​ການ​ບໍ​ລິ​ການ​ທີ່​ສະ​ຫນອງ​ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ເກັບ​ກໍາ telemetry ແລະ​ວັດ​ແທກ​ຊັບ​ພະ​ຍາ​ກອນ​ທີ່​ມີ​ແລະ​ການ​ບໍ​ລິ​ໂພກ​
• ຄວາມຮ້ອນ — orchestration ໂດຍ​ອີງ​ໃສ່​ແມ່​ແບບ​ສໍາ​ລັບ​ການ​ສ້າງ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ການ​ສະ​ຫນອງ​ຊັບ​ພະ​ຍາ​ກອນ​

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

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

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

ຂໍໃຫ້ຜ່ານຂັ້ນຕອນວິທີການສ້າງເຄື່ອງ virtual ແລະເຊື່ອມຕໍ່ມັນກັບເຄືອຂ່າຍແລະການເກັບຮັກສາຢ່າງຕໍ່ເນື່ອງໃນ Openstack.

1. ເມື່ອທ່ານສ້າງຄໍາຮ້ອງຂໍເພື່ອສ້າງເຄື່ອງຈັກ, ບໍ່ວ່າຈະເປັນການຮ້ອງຂໍຜ່ານ Horizon (Dashboard) ຫຼືຄໍາຮ້ອງຂໍຜ່ານ CLI, ສິ່ງທໍາອິດທີ່ເກີດຂື້ນແມ່ນການອະນຸຍາດຄໍາຮ້ອງຂໍຂອງທ່ານໃນ Keystone - ທ່ານສາມາດສ້າງເຄື່ອງຈັກໄດ້ບໍ, ມັນມີ? ສິດທິໃນການໃຊ້ເຄືອຂ່າຍນີ້, ໂຄຕ້າຮ່າງຂອງເຈົ້າ, ແລະອື່ນໆ.
2. Keystone ກວດສອບການຮ້ອງຂໍຂອງທ່ານແລະສ້າງ token ການກວດສອບຄວາມຖືກຕ້ອງໃນຂໍ້ຄວາມຕອບສະຫນອງ, ເຊິ່ງຈະຖືກນໍາໃຊ້ຕື່ມອີກ. ໄດ້ຮັບການຕອບສະຫນອງຈາກ Keystone, ການຮ້ອງຂໍແມ່ນຖືກສົ່ງໄປຫາ Nova (nova api).
3. Nova-api ກວດເບິ່ງຄວາມຖືກຕ້ອງຂອງຄໍາຮ້ອງຂໍຂອງທ່ານໂດຍການຕິດຕໍ່ກັບ Keystone ໂດຍໃຊ້ token ການກວດສອບຄວາມຖືກຕ້ອງທີ່ສ້າງຂຶ້ນກ່ອນຫນ້ານີ້
4. Keystone ດໍາເນີນການກວດສອບຄວາມຖືກຕ້ອງແລະສະຫນອງຂໍ້ມູນກ່ຽວກັບການອະນຸຍາດແລະຂໍ້ຈໍາກັດໂດຍອີງໃສ່ token ການກວດສອບນີ້.
5. Nova-api ສ້າງລາຍການສໍາລັບ VM ໃຫມ່ໃນ nova-database ແລະສົ່ງຜ່ານຄໍາຮ້ອງຂໍເພື່ອສ້າງເຄື່ອງກັບ nova-scheduler.
6. Nova-scheduler ເລືອກໂຮດ (ໂນດຄອມພິວເຕີ) ທີ່ VM ຈະຖືກ ນຳ ໃຊ້ໂດຍອີງໃສ່ພາລາມິເຕີ, ນ້ ຳ ໜັກ ແລະເຂດທີ່ລະບຸ. ບັນທຶກຂອງອັນນີ້ ແລະ VM ID ຖືກຂຽນໃສ່ nova-database.
7. ຕໍ່ໄປ, nova-scheduler ຕິດຕໍ່ກັບ nova-compute ດ້ວຍການຮ້ອງຂໍໃຫ້ໃຊ້ instance. Nova-compute contacts nova-conductor ເພື່ອໃຫ້ໄດ້ຂໍ້ມູນກ່ຽວກັບພາລາມິເຕີຂອງເຄື່ອງຈັກ (nova-conductor ແມ່ນອົງປະກອບ nova ທີ່ເຮັດໜ້າທີ່ເປັນເຊີບເວີພຣັອກຊີລະຫວ່າງ nova-database ແລະ nova-compute, ຈຳກັດຈຳນວນການຮ້ອງຂໍຕໍ່ nova-database ເພື່ອຫຼີກເວັ້ນບັນຫາກັບຖານຂໍ້ມູນ. ການຫຼຸດຜ່ອນຄວາມສອດຄ່ອງຂອງການໂຫຼດ).
8. Nova-conductor ໄດ້ຮັບຂໍ້ມູນທີ່ຮ້ອງຂໍຈາກ nova-database ແລະສົ່ງມັນໄປຫາ nova-compute.
9. ຕໍ່ໄປ, nova-compute ໂທຫາ glance ເພື່ອໃຫ້ໄດ້ຮັບ ID ຮູບພາບ. Glace ກວດສອບຄໍາຮ້ອງຂໍໃນ Keystone ແລະສົ່ງຄືນຂໍ້ມູນທີ່ຮ້ອງຂໍ.
10. Nova-compute ຕິດຕໍ່ກັບ neutron ເພື່ອໃຫ້ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຕົວກໍານົດການເຄືອຂ່າຍ. ຄ້າຍຄືກັນກັບ glance, neutron validates ການຮ້ອງຂໍໃນ Keystone, ຫຼັງຈາກນັ້ນມັນສ້າງການປ້ອນຂໍ້ມູນໃນຖານຂໍ້ມູນ (ຕົວລະບຸພອດ, ແລະອື່ນໆ), ສ້າງຄໍາຮ້ອງຂໍເພື່ອສ້າງພອດ, ແລະສົ່ງຄືນຂໍ້ມູນທີ່ຮ້ອງຂໍໃຫ້ nova-compute.
11. Nova-compute contacts cinder ດ້ວຍການຮ້ອງຂໍເພື່ອຈັດສັນປະລິມານໃຫ້ກັບເຄື່ອງ virtual. ຄ້າຍຄືກັນກັບ glance, cider validates ການຮ້ອງຂໍໃນ Keystone, ສ້າງຄໍາຮ້ອງຂໍການສ້າງປະລິມານ, ແລະສົ່ງຄືນຂໍ້ມູນທີ່ຮ້ອງຂໍ.
12. Nova-compute contacts libvirt ດ້ວຍການຮ້ອງຂໍໃຫ້ໃຊ້ເຄື່ອງ virtual ກັບພາລາມິເຕີທີ່ລະບຸ.

ໃນຄວາມເປັນຈິງ, ການດໍາເນີນງານທີ່ເບິ່ງຄືວ່າງ່າຍດາຍຂອງການສ້າງເຄື່ອງ virtual ງ່າຍດາຍປ່ຽນເປັນ whirlpool ຂອງການໂທ API ລະຫວ່າງອົງປະກອບຂອງເວທີຟັງ. ຍິ່ງໄປກວ່ານັ້ນ, ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ເຖິງແມ່ນວ່າການບໍລິການທີ່ຖືກກໍານົດໄວ້ກ່ອນຫນ້ານີ້ຍັງປະກອບດ້ວຍອົງປະກອບຂະຫນາດນ້ອຍກວ່າລະຫວ່າງການໂຕ້ຕອບທີ່ເກີດຂື້ນ. ການສ້າງເຄື່ອງຈັກແມ່ນພຽງແຕ່ສ່ວນນ້ອຍຂອງສິ່ງທີ່ເວທີຟັງອະນຸຍາດໃຫ້ທ່ານເຮັດ - ມີບໍລິການທີ່ຮັບຜິດຊອບສໍາລັບການດຸ່ນດ່ຽງການຈະລາຈອນ, ການບໍລິການທີ່ຮັບຜິດຊອບສໍາລັບການເກັບຮັກສາຕັນ, ບໍລິການທີ່ຮັບຜິດຊອບ DNS, ການບໍລິການທີ່ຮັບຜິດຊອບສໍາລັບການສະຫນອງເຄື່ອງແມ່ຂ່າຍໂລຫະເປົ່າ, ແລະອື່ນໆ. ຟັງໄດ້ອະນຸຍາດໃຫ້ທ່ານສາມາດປະຕິບັດກັບເຄື່ອງ virtual ຂອງທ່ານຄືກັບຝູງແກະ (ກົງກັນຂ້າມກັບ virtualization). ຖ້າມີບາງສິ່ງບາງຢ່າງເກີດຂື້ນກັບເຄື່ອງຂອງທ່ານໃນສະພາບແວດລ້ອມ virtual - ທ່ານຟື້ນຟູມັນຈາກການສໍາຮອງຂໍ້ມູນ, ແລະອື່ນໆ, ແຕ່ຄໍາຮ້ອງສະຫມັກຟັງແມ່ນສ້າງຂຶ້ນໃນລັກສະນະທີ່ເຄື່ອງ virtual ບໍ່ມີບົດບາດສໍາຄັນ - ເຄື່ອງ virtual "ຕາຍ" - ບໍ່ມີບັນຫາ. - ເປັນອັນໃຫມ່ພຽງແຕ່ສ້າງຍານພາຫະນະແມ່ນອີງໃສ່ແມ່ແບບແລະ, ຍ້ອນວ່າເຂົາເຈົ້າເວົ້າວ່າ, squad ບໍ່ໄດ້ສັງເກດເຫັນການສູນເສຍຂອງ fighter ໄດ້. ຕາມທໍາມະຊາດ, ນີ້ສະຫນອງການປະກົດຕົວຂອງກົນໄກການ orchestration - ໂດຍໃຊ້ແມ່ແບບຄວາມຮ້ອນ, ທ່ານສາມາດປະຕິບັດຫນ້າທີ່ສະລັບສັບຊ້ອນທີ່ປະກອບດ້ວຍຫຼາຍສິບເຄືອຂ່າຍແລະເຄື່ອງຈັກ virtual.

ມັນເປັນມູນຄ່າທີ່ຈື່ໄວ້ສະເຫມີວ່າບໍ່ມີໂຄງສ້າງພື້ນຖານຂອງເມຄທີ່ບໍ່ມີເຄືອຂ່າຍ - ແຕ່ລະອົງປະກອບໃນວິທີການຫນຶ່ງຫຼືອື່ນພົວພັນກັບອົງປະກອບອື່ນໆໂດຍຜ່ານເຄືອຂ່າຍ. ນອກຈາກນັ້ນ, ຟັງມີເຄືອຂ່າຍທີ່ບໍ່ສະຖິດຢ່າງແທ້ຈິງ. ຕາມທໍາມະຊາດ, ເຄືອຂ່າຍ underlay ແມ່ນຫຼາຍຫຼືຫນ້ອຍ static - nodes ແລະ switches ໃຫມ່ບໍ່ໄດ້ເພີ່ມທຸກໆມື້, ແຕ່ອົງປະກອບ overlay ສາມາດແລະ inevitably ມີການປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງ - ເຄືອຂ່າຍໃຫມ່ຈະຖືກເພີ່ມຫຼືລຶບ, virtual machines ໃຫມ່ຈະປາກົດແລະເຄື່ອງເກົ່າຈະ. ຕາຍ. ແລະຕາມທີ່ທ່ານຈື່ໄດ້ຈາກຄໍານິຍາມຂອງຟັງທີ່ໃຫ້ຢູ່ໃນຕອນຕົ້ນຂອງບົດຄວາມ, ຊັບພະຍາກອນຄວນໄດ້ຮັບການຈັດສັນໃຫ້ຜູ້ໃຊ້ໂດຍອັດຕະໂນມັດແລະມີຫນ້ອຍທີ່ສຸດ (ຫຼືດີກວ່າ, ໂດຍບໍ່ມີການ) ແຊກແຊງຈາກຜູ້ໃຫ້ບໍລິການ. ນັ້ນແມ່ນ, ປະເພດຂອງການສະຫນອງຊັບພະຍາກອນເຄືອຂ່າຍທີ່ປະຈຸບັນມີຢູ່ໃນຮູບແບບຂອງ front-end ໃນຮູບແບບຂອງບັນຊີສ່ວນບຸກຄົນຂອງທ່ານສາມາດເຂົ້າເຖິງໄດ້ຜ່ານ http / https ແລະວິສະວະກອນເຄືອຂ່າຍທີ່ເຮັດວຽກຢູ່ Vasily ເປັນ backend ບໍ່ແມ່ນເມຄ, ເຖິງແມ່ນວ່າ. ຖ້າ Vasily ມີແປດມື.

Neutron, ເປັນບໍລິການເຄືອຂ່າຍ, ສະຫນອງ API ສໍາລັບການຄຸ້ມຄອງສ່ວນເຄືອຂ່າຍຂອງໂຄງສ້າງພື້ນຖານຂອງຟັງ. ການບໍລິການໃຫ້ອຳນາດ ແລະຈັດການສ່ວນເຄືອຂ່າຍຂອງ Openstack ໂດຍການສະໜອງຊັ້ນອັນບໍ່ມີຕົວຕົນທີ່ເອີ້ນວ່າ Network-as-a-Service (NaaS). ນັ້ນແມ່ນ, ເຄືອຂ່າຍແມ່ນຫນ່ວຍງານທີ່ສາມາດວັດແທກໄດ້ virtual ຄືກັນກັບ, ສໍາລັບການຍົກຕົວຢ່າງ, ແກນ CPU virtual ຫຼືຈໍານວນ RAM.

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

ດັ່ງນັ້ນພວກເຮົາມີ VM ລູກຄ້າສີແດງສອງອັນແລະ VM ລູກຄ້າສີຂຽວສອງອັນ. ໃຫ້ສົມມຸດວ່າເຄື່ອງເຫຼົ່ານີ້ຕັ້ງຢູ່ເທິງສອງ hypervisors ໃນທາງນີ້:

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

ເພື່ອສ້າງເມຄ, ພວກເຮົາຈໍາເປັນຕ້ອງເພີ່ມອົງປະກອບຈໍານວນຫນຶ່ງ. ຫນ້າທໍາອິດ, ພວກເຮົາ virtualize ສ່ວນເຄືອຂ່າຍ - ພວກເຮົາຈໍາເປັນຕ້ອງເຊື່ອມຕໍ່ 4 ເຄື່ອງເຫຼົ່ານີ້ເປັນຄູ່, ແລະລູກຄ້າຕ້ອງການການເຊື່ອມຕໍ່ L2. ທ່ານສາມາດນໍາໃຊ້ສະວິດແລະກໍາຫນົດຄ່າລໍາຕົ້ນໃນທິດທາງຂອງຕົນແລະແກ້ໄຂທຸກສິ່ງທຸກຢ່າງໂດຍໃຊ້ຂົວ linux ຫຼື, ສໍາລັບຜູ້ໃຊ້ທີ່ກ້າວຫນ້າທາງດ້ານຫຼາຍ, openvswitch (ພວກເຮົາຈະກັບຄືນໄປນີ້ຕໍ່ມາ). ແຕ່ສາມາດມີເຄືອຂ່າຍຫຼາຍ, ແລະການຊຸກຍູ້ L2 ຢ່າງຕໍ່ເນື່ອງບໍ່ແມ່ນຄວາມຄິດທີ່ດີທີ່ສຸດ - ມີພະແນກທີ່ແຕກຕ່າງກັນ, ມີໂຕະບໍລິການ, ຫຼາຍເດືອນລໍຖ້າການສະຫມັກສໍາເລັດ, ອາທິດຂອງການແກ້ໄຂບັນຫາ - ໃນໂລກທີ່ທັນສະໄຫມນີ້. ວິທີການບໍ່ເຮັດວຽກອີກຕໍ່ໄປ. ແລະໄວບໍລິສັດເຂົ້າໃຈເລື່ອງນີ້, ມັນງ່າຍຂຶ້ນສໍາລັບມັນທີ່ຈະກ້າວໄປຂ້າງຫນ້າ. ດັ່ງນັ້ນ, ລະຫວ່າງ hypervisors ພວກເຮົາຈະເລືອກເຄືອຂ່າຍ L3 ທີ່ເຄື່ອງ virtual ຂອງພວກເຮົາຈະສື່ສານ, ແລະຢູ່ເທິງສຸດຂອງເຄືອຂ່າຍ L3 ນີ້ພວກເຮົາຈະສ້າງເຄືອຂ່າຍ virtual L2 overlay ທີ່ການຈະລາຈອນຂອງເຄື່ອງຈັກ virtual ຂອງພວກເຮົາຈະດໍາເນີນການ. ທ່ານສາມາດນໍາໃຊ້ GRE, Geneve ຫຼື VxLAN ເປັນ encapsulation. ຂໍໃຫ້ສຸມໃສ່ອັນສຸດທ້າຍສໍາລັບໃນປັດຈຸບັນ, ເຖິງແມ່ນວ່າມັນບໍ່ສໍາຄັນໂດຍສະເພາະ.

ພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາ VTEP ບາງບ່ອນ (ຂ້າພະເຈົ້າຫວັງວ່າທຸກຄົນຈະຄຸ້ນເຄີຍກັບຄໍາສັບ VxLAN). ເນື່ອງຈາກພວກເຮົາມີເຄືອຂ່າຍ L3 ມາຈາກເຊີບເວີໂດຍກົງ, ບໍ່ມີຫຍັງກີດຂວາງພວກເຮົາຈາກການວາງ VTEP ໃນເຄື່ອງແມ່ຂ່າຍຂອງຕົນເອງ, ແລະ OVS (OpenvSwitch) ແມ່ນດີເລີດໃນການເຮັດສິ່ງນີ້. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບການອອກແບບນີ້:

ເນື່ອງຈາກການຈະລາຈອນລະຫວ່າງ VMs ຕ້ອງໄດ້ຮັບການແບ່ງອອກ, ພອດໄປຫາເຄື່ອງ virtual ຈະມີຕົວເລກ vlan ທີ່ແຕກຕ່າງກັນ. ໝາຍເລກແທັກມີບົດບາດພຽງແຕ່ພາຍໃນສະຫຼັບສະເໝືອນດຽວເທົ່ານັ້ນ, ເພາະວ່າເມື່ອຖືກຫຸ້ມຫໍ່ຢູ່ໃນ VxLAN ພວກເຮົາສາມາດເອົາມັນອອກໄດ້ຢ່າງງ່າຍດາຍ, ເພາະວ່າພວກເຮົາຈະມີ VNI.

ໃນປັດຈຸບັນພວກເຮົາສາມາດສ້າງເຄື່ອງຂອງພວກເຮົາແລະເຄືອຂ່າຍ virtual ສໍາລັບພວກເຂົາໂດຍບໍ່ມີບັນຫາໃດໆ.

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

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

ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ຮັບແຜນວາດຕໍ່ໄປນີ້:

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

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບແຜນວາດນີ້:

ຄໍາຖາມທີ່ສົມເຫດສົມຜົນແມ່ນເປັນຫຍັງຈຶ່ງບໍ່ສ້າງ gateways ໃນໂຫນດຄອມພິວເຕີ້ດ້ວຍຕົນເອງ? ນີ້ບໍ່ແມ່ນບັນຫາໃຫຍ່; ນອກຈາກນັ້ນ, ຖ້າທ່ານເປີດ router ທີ່ແຈກຢາຍ (DVR), ນີ້ຈະເຮັດວຽກ. ໃນສະຖານະການນີ້, ພວກເຮົາກໍາລັງພິຈາລະນາທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດທີ່ມີປະຕູສູນກາງ, ເຊິ່ງຖືກນໍາໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນໃນ Openstack. ສໍາລັບຟັງຊັນການໂຫຼດສູງ, ພວກເຂົາຈະໃຊ້ທັງ router ທີ່ແຈກຢາຍແລະເຕັກໂນໂລຢີການເລັ່ງເຊັ່ນ SR-IOV ແລະ Passthrough, ແຕ່ຍ້ອນວ່າພວກເຂົາເວົ້າ, ນັ້ນແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນຫມົດ. ທໍາອິດ, ໃຫ້ຈັດການກັບພາກສ່ວນພື້ນຖານ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈະເຂົ້າໄປໃນລາຍລະອຽດ.

ແທ້ຈິງແລ້ວ, ໂຄງການຂອງພວກເຮົາແມ່ນສາມາດເຮັດວຽກໄດ້ແລ້ວ, ແຕ່ມີສອງສາມຢ່າງ:

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

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍການປົກປ້ອງເຄື່ອງຈັກ. ສໍາລັບການນີ້ທ່ານສາມາດນໍາໃຊ້ iptables banal, ເປັນຫຍັງບໍ່.

ນັ້ນແມ່ນ, ໃນປັດຈຸບັນ topology ຂອງພວກເຮົາໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍ:

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

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

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

ແລະນີ້ NAT ມາຊ່ວຍເຫຼືອຂອງພວກເຮົາ - ພວກເຮົາພຽງແຕ່ຈະເຮັດໃຫ້ລູກຄ້າສາມາດເຂົ້າເຖິງໂລກພາຍນອກໄດ້ໂດຍຜ່ານ namespace ເລີ່ມຕົ້ນໂດຍໃຊ້ NAT ການແປພາສາ. ດີ, ນີ້ແມ່ນບັນຫານ້ອຍໆ. ນີ້ແມ່ນດີຖ້າເຄື່ອງແມ່ຂ່າຍລູກຄ້າປະຕິບັດເປັນລູກຄ້າແລະບໍ່ແມ່ນເຄື່ອງແມ່ຂ່າຍ - ນັ້ນແມ່ນ, ມັນເລີ່ມຕົ້ນແທນທີ່ຈະຍອມຮັບການເຊື່ອມຕໍ່. ແຕ່ສໍາລັບພວກເຮົາ, ມັນຈະເປັນວິທີທາງອື່ນ. ໃນກໍລະນີນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດ NAT ຈຸດຫມາຍປາຍທາງເພື່ອໃຫ້ເມື່ອໄດ້ຮັບການຈະລາຈອນ, node ຄວບຄຸມເຂົ້າໃຈວ່າການຈະລາຈອນນີ້ແມ່ນມີຈຸດປະສົງສໍາລັບເຄື່ອງ virtual A ຂອງລູກຄ້າ A, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາຈໍາເປັນຕ້ອງເຮັດການແປພາສາ NAT ຈາກທີ່ຢູ່ພາຍນອກ, ຕົວຢ່າງ 100.1.1.1. .10.0.0.1, ໄປຫາທີ່ຢູ່ພາຍໃນ 100. ໃນກໍລະນີນີ້, ເຖິງແມ່ນວ່າລູກຄ້າທັງຫມົດຈະໃຊ້ເຄືອຂ່າຍດຽວກັນ, ການໂດດດ່ຽວພາຍໃນແມ່ນຖືກຮັກສາໄວ້ຢ່າງສົມບູນ. ນັ້ນແມ່ນ, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດ dNAT ແລະ sNAT ໃນໂຫນດຄວບຄຸມ. ວ່າຈະໃຊ້ເຄືອຂ່າຍດຽວກັບທີ່ຢູ່ລອຍຕົວ ຫຼືເຄືອຂ່າຍພາຍນອກ, ຫຼືທັງສອງໃນເວລາດຽວກັນ, ແມ່ນຂຶ້ນກັບສິ່ງທີ່ທ່ານຕ້ອງການນຳໄປສູ່ຄລາວ. ພວກເຮົາຈະບໍ່ເພີ່ມທີ່ຢູ່ທີ່ລອຍຢູ່ໃນແຜນວາດ, ແຕ່ຈະອອກຈາກເຄືອຂ່າຍພາຍນອກທີ່ເພີ່ມແລ້ວກ່ອນຫນ້ານັ້ນ - ລູກຄ້າແຕ່ລະຄົນມີເຄືອຂ່າຍພາຍນອກຂອງຕົນເອງ (ໃນແຜນວາດພວກເຂົາຖືກລະບຸເປັນ vlan 200 ແລະ XNUMX ໃນການໂຕ້ຕອບພາຍນອກ).

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

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

ຕາມທໍາມະຊາດ, ໂຫນດທັງຫມົດແມ່ນ synchronized ແລະໃນເວລາທີ່ node ການເຄື່ອນໄຫວອອກໄປ, node ອື່ນຈະຮັບຜິດຊອບຄວາມຮັບຜິດຊອບຂອງຕົນ.

ບັນຫາຕໍ່ໄປແມ່ນແຜ່ນເຄື່ອງ virtual. ໃນປັດຈຸບັນ, ພວກມັນຖືກເກັບໄວ້ໃນ hypervisors ຕົວເອງ, ແລະໃນກໍລະນີຂອງບັນຫາກັບ hypervisor, ພວກເຮົາສູນເສຍຂໍ້ມູນທັງຫມົດ - ແລະການປະກົດຕົວຂອງການໂຈມຕີຈະບໍ່ຊ່ວຍທີ່ນີ້ຖ້າພວກເຮົາສູນເສຍບໍ່ແມ່ນແຜ່ນ, ແຕ່ເຄື່ອງແມ່ຂ່າຍທັງຫມົດ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດໃຫ້ການບໍລິການທີ່ຈະເຮັດຫນ້າທີ່ເປັນສ່ວນຫນ້າສໍາລັບການເກັບຮັກສາບາງປະເພດ. ປະເພດຂອງການເກັບຮັກສາມັນຈະບໍ່ມີຄວາມສໍາຄັນໂດຍສະເພາະກັບພວກເຮົາ, ແຕ່ມັນຄວນຈະປົກປ້ອງຂໍ້ມູນຂອງພວກເຮົາຈາກຄວາມລົ້ມເຫຼວຂອງທັງແຜ່ນແລະ node, ແລະອາດຈະເປັນຕູ້ທັງຫມົດ. ມີຫລາຍທາງເລືອກຢູ່ທີ່ນີ້ - ແນ່ນອນ, ມີເຄືອຂ່າຍ SAN ກັບ Fiber Channel, ແຕ່ໃຫ້ຄວາມຊື່ສັດ - FC ແມ່ນເປັນວັດຖຸບູຮານຂອງອະດີດ - ການປຽບທຽບຂອງ E1 ໃນການຂົນສົ່ງ - ແມ່ນແລ້ວ, ຂ້າພະເຈົ້າຕົກລົງ, ມັນຍັງຖືກນໍາໃຊ້, ແຕ່. ພຽງແຕ່ບ່ອນທີ່ມັນເປັນໄປບໍ່ໄດ້ຢ່າງແທ້ຈິງໂດຍບໍ່ມີມັນ. ດັ່ງນັ້ນ, ຂ້ອຍຈະບໍ່ສະໝັກໃຈທີ່ຈະນຳໃຊ້ເຄືອຂ່າຍ FC ໃນປີ 2020, ໂດຍຮູ້ວ່າມີທາງເລືອກອື່ນທີ່ໜ້າສົນໃຈກວ່າ. ເຖິງແມ່ນວ່າແຕ່ລະຄົນຂອງຕົນເອງ, ອາດຈະມີຜູ້ທີ່ເຊື່ອວ່າ FC ທີ່ມີຂໍ້ຈໍາກັດທັງຫມົດແມ່ນສິ່ງທີ່ພວກເຮົາຕ້ອງການ - ຂ້ອຍຈະບໍ່ໂຕ້ຖຽງ, ທຸກຄົນມີຄວາມຄິດເຫັນຂອງຕົນເອງ. ຢ່າງໃດກໍ່ຕາມ, ການແກ້ໄຂທີ່ຫນ້າສົນໃຈທີ່ສຸດໃນຄວາມຄິດເຫັນຂອງຂ້ອຍແມ່ນການໃຊ້ SDS, ເຊັ່ນ Ceph.

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

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

ຫມາຍເຫດ: ທ່ານຍັງສາມາດສ້າງ nodes ຄອມພິວເຕີ້ hyperconverged - ນີ້ແມ່ນແນວຄວາມຄິດຂອງການລວມເອົາຫຼາຍຫນ້າທີ່ຢູ່ໃນຫນຶ່ງ node - ຕົວຢ່າງ, storage+compute - ໂດຍບໍ່ມີການອຸທິດ nodes ພິເສດສໍາລັບການເກັບຮັກສາ ceph. ພວກເຮົາຈະໄດ້ຮັບໂຄງການທີ່ມີຄວາມທົນທານຕໍ່ຄວາມຜິດດຽວກັນ - ນັບຕັ້ງແຕ່ SDS ຈະສະຫງວນຂໍ້ມູນທີ່ມີລະດັບການຈອງທີ່ພວກເຮົາກໍານົດ. ຢ່າງໃດກໍຕາມ, hyperconverged nodes ສະເຫມີເປັນການປະນີປະນອມ - ເນື່ອງຈາກວ່າ node ການເກັບຮັກສາບໍ່ພຽງແຕ່ເຮັດໃຫ້ອາກາດຮ້ອນຍ້ອນວ່າມັນເບິ່ງຄືວ່າຢູ່ glance ທໍາອິດ (ເນື່ອງຈາກວ່າບໍ່ມີເຄື່ອງ virtual ກ່ຽວກັບມັນ) - ມັນໃຊ້ຊັບພະຍາກອນ CPU ໃນການບໍລິການ SDS (ໃນຄວາມເປັນຈິງ, ມັນເຮັດທັງຫມົດ. replication ແລະການຟື້ນຕົວຫຼັງຈາກຄວາມລົ້ມເຫຼວຂອງ nodes, disks, ແລະອື່ນໆ). ນັ້ນແມ່ນ, ທ່ານຈະສູນເສຍພະລັງງານບາງຢ່າງຂອງໂຫນດຄອມພິວເຕີ້ຖ້າທ່ານສົມທົບກັບບ່ອນເກັບມ້ຽນ.

ສິ່ງທັງຫມົດນີ້ຕ້ອງໄດ້ຮັບການຄຸ້ມຄອງບາງຢ່າງ - ພວກເຮົາຕ້ອງການບາງສິ່ງບາງຢ່າງໂດຍຜ່ານທີ່ພວກເຮົາສາມາດສ້າງເຄື່ອງຈັກ, ເຄືອຂ່າຍ, router virtual, ແລະອື່ນໆ. ລູກຄ້າຈະສາມາດເຊື່ອມຕໍ່ກັບປະຕູນີ້ຜ່ານ http / https ແລະເຮັດທຸກຢ່າງທີ່ລາວຕ້ອງການ (ດີ, ເກືອບ).

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

ສະຖາປັດຕະຍະກໍາ Neutron

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

ໃນລະດັບສູງ, ການດໍາເນີນງານຂອງການບໍລິການເຄືອຂ່າຍ (ສ່ວນພື້ນຖານ) ສາມາດອະທິບາຍດັ່ງຕໍ່ໄປນີ້.

ເມື່ອເລີ່ມ VM, ບໍລິການເຄືອຂ່າຍ:

1. ສ້າງພອດສໍາລັບ VM ທີ່ໃຫ້ (ຫຼືພອດ) ແລະແຈ້ງການບໍລິການ DHCP ກ່ຽວກັບມັນ;
2. ອຸປະກອນເຄືອຂ່າຍ virtual ໃຫມ່ຖືກສ້າງຂື້ນ (ຜ່ານ libvirt);
3. VM ເຊື່ອມຕໍ່ກັບຜອດທີ່ສ້າງຂຶ້ນໃນຂັ້ນຕອນທີ 1;

Oddly ພຽງພໍ, ການເຮັດວຽກຂອງ Neutron ແມ່ນອີງໃສ່ກົນໄກມາດຕະຖານທີ່ຄຸ້ນເຄີຍກັບທຸກຄົນທີ່ເຄີຍເຂົ້າໄປໃນ Linux - namespaces, iptables, linux bridges, openvswitch, conntrack, ແລະອື່ນໆ.

ມັນຄວນຈະແຈ້ງທັນທີວ່າ Neutron ບໍ່ແມ່ນຕົວຄວບຄຸມ SDN.

Neutron ປະກອບດ້ວຍອົງປະກອບເຊື່ອມຕໍ່ກັນຫຼາຍອັນ:

Openstack-neutron-server ແມ່ນ daemon ທີ່ເຮັດວຽກກັບການຮ້ອງຂໍຂອງຜູ້ໃຊ້ຜ່ານ API. ຜີປີສາດນີ້ບໍ່ໄດ້ມີສ່ວນຮ່ວມໃນການລົງທະບຽນການເຊື່ອມຕໍ່ເຄືອຂ່າຍໃດໆ, ແຕ່ໃຫ້ຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການນີ້ກັບ plugins ຂອງມັນ, ເຊິ່ງຫຼັງຈາກນັ້ນ configure ອົງປະກອບເຄືອຂ່າຍທີ່ຕ້ອງການ. ຕົວແທນ Neutron ໃນຂໍ້ OpenStack ລົງທະບຽນກັບເຊີບເວີ Neutron.

Neutron-server ແມ່ນຕົວຈິງແລ້ວຄໍາຮ້ອງສະຫມັກທີ່ຂຽນໃນ python, ປະກອບດ້ວຍສອງພາກສ່ວນ:

• ບໍລິການພັກຜ່ອນ
• ປລັກອິນ Neutron (ຫຼັກ/ການບໍລິການ)

ບໍລິການ REST ຖືກອອກແບບມາເພື່ອຮັບການໂທ API ຈາກອົງປະກອບອື່ນໆ (ຕົວຢ່າງ, ການຮ້ອງຂໍໃຫ້ຂໍ້ມູນບາງຢ່າງ, ແລະອື່ນໆ).

Plugins ແມ່ນສ່ວນປະກອບຂອງຊອບແວ plug-in / ໂມດູນທີ່ຖືກເອີ້ນໃນລະຫວ່າງການຮ້ອງຂໍ API - ນັ້ນແມ່ນ, ຄຸນລັກສະນະຂອງການບໍລິການເກີດຂື້ນຜ່ານພວກມັນ. Plugins ແບ່ງອອກເປັນສອງປະເພດ - ບໍລິການແລະຮາກ. ຕາມກົດລະບຽບ, plugin ມ້າແມ່ນຮັບຜິດຊອບຕົ້ນຕໍໃນການຄຸ້ມຄອງພື້ນທີ່ທີ່ຢູ່ແລະການເຊື່ອມຕໍ່ L2 ລະຫວ່າງ VMs, ແລະ plugins ການບໍລິການສະຫນອງການເຮັດວຽກເພີ່ມເຕີມເຊັ່ນ VPN ຫຼື FW.

ບັນຊີລາຍຊື່ຂອງ plugins ທີ່ມີຢູ່ໃນມື້ນີ້ສາມາດເບິ່ງໄດ້ສໍາລັບຕົວຢ່າງ ທີ່ນີ້

ສາມາດມີ plugins ການບໍລິການຈໍານວນຫນຶ່ງ, ແຕ່ມີພຽງແຕ່ຫນຶ່ງ plugin ມ້າ.

openstack-neutron-ml2 ແມ່ນ plugin ຮາກ Openstack ມາດຕະຖານ. ປັ໊ກອິນນີ້ມີສະຖາປັດຕະຍະ ກຳ ແບບໂມດູນ (ບໍ່ຄືກັບລຸ້ນກ່ອນ) ແລະ ກຳ ນົດຄ່າບໍລິການເຄືອຂ່າຍຜ່ານໄດເວີທີ່ເຊື່ອມຕໍ່ກັບມັນ. ພວກເຮົາຈະເບິ່ງ plugin ຕົວຂອງມັນເອງຕໍ່ມາເລັກນ້ອຍ, ເພາະວ່າໃນຄວາມເປັນຈິງມັນເຮັດໃຫ້ຄວາມຍືດຫຍຸ່ນທີ່ OpenStack ມີຢູ່ໃນສ່ວນເຄືອຂ່າຍ. ປັ໊ກອິນຮາກສາມາດຖືກແທນທີ່ (ຕົວຢ່າງ, Contrail Networking ເຮັດການທົດແທນ).

ບໍລິການ RPC (rabbitmq-server) — ການ​ບໍ​ລິ​ການ​ທີ່​ໃຫ້​ການ​ຄຸ້ມ​ຄອງ​ຄິວ​ແລະ​ການ​ໂຕ້​ຕອບ​ກັບ​ການ​ບໍ​ລິ​ການ OpenStack ອື່ນໆ​, ເຊັ່ນ​ດຽວ​ກັນ​ກັບ​ການ​ພົວ​ພັນ​ລະ​ຫວ່າງ​ຕົວ​ແທນ​ການ​ບໍ​ລິ​ການ​ເຄືອ​ຂ່າຍ​.

ຕົວແທນເຄືອຂ່າຍ — ຕົວ​ແທນ​ທີ່​ຕັ້ງ​ຢູ່​ໃນ​ແຕ່​ລະ​ຂໍ້​, ໂດຍ​ຜ່ານ​ການ​ການ​ບໍ​ລິ​ການ​ເຄືອ​ຂ່າຍ​ໄດ້​ຖືກ​ຕັ້ງ​ຄ່າ​.

ມີຫຼາຍປະເພດຂອງຕົວແທນ.

ຕົວແທນຕົ້ນຕໍແມ່ນ ຕົວແທນ L2. ຕົວແທນເຫຼົ່ານີ້ດໍາເນີນການຢູ່ໃນແຕ່ລະ hypervisors, ລວມທັງ nodes ຄວບຄຸມ (ທີ່ຊັດເຈນກວ່າ, ໃນທຸກ nodes ທີ່ໃຫ້ບໍລິການໃດໆສໍາລັບຜູ້ເຊົ່າ) ແລະຫນ້າທີ່ຕົ້ນຕໍຂອງພວກເຂົາແມ່ນການເຊື່ອມຕໍ່ເຄື່ອງ virtual ກັບເຄືອຂ່າຍ L2 ທົ່ວໄປ, ແລະຍັງສ້າງການແຈ້ງເຕືອນເມື່ອເຫດການໃດໆເກີດຂື້ນ ( ສໍາ​ລັບ​ຕົວ​ຢ່າງ​ປິດ​ການ​ທໍາ​ງານ / ເຮັດ​ໃຫ້​ພອດ​)​.

ຕໍ່ໄປ, ບໍ່ມີຕົວແທນທີ່ສໍາຄັນຫນ້ອຍແມ່ນ ຕົວແທນ L3. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວແທນນີ້ເຮັດວຽກສະເພາະໃນ node ເຄືອຂ່າຍ (ເລື້ອຍໆ node ເຄືອຂ່າຍຖືກລວມກັບ node ຄວບຄຸມ) ແລະສະຫນອງການກໍານົດເສັ້ນທາງລະຫວ່າງເຄືອຂ່າຍຜູ້ເຊົ່າ (ທັງລະຫວ່າງເຄືອຂ່າຍຂອງຕົນແລະເຄືອຂ່າຍຂອງຜູ້ເຊົ່າອື່ນໆ, ແລະສາມາດເຂົ້າເຖິງໂລກພາຍນອກໄດ້, ສະຫນອງ. NAT, ເຊັ່ນດຽວກັນກັບການບໍລິການ DHCP). ຢ່າງໃດກໍຕາມ, ເມື່ອໃຊ້ DVR (router ແຈກຢາຍ), ຄວາມຕ້ອງການສໍາລັບ plugin L3 ຍັງປາກົດຢູ່ໃນ nodes ຄອມພິວເຕີ.

ຕົວແທນ L3 ໃຊ້ namespaces Linux ເພື່ອໃຫ້ຜູ້ເຊົ່າແຕ່ລະຄົນມີຊຸດຂອງເຄືອຂ່າຍທີ່ໂດດດ່ຽວຂອງຕົນເອງແລະການເຮັດວຽກຂອງ routers virtual ທີ່ສົ່ງເສັ້ນທາງການຈະລາຈອນແລະໃຫ້ບໍລິການປະຕູສໍາລັບ Layer 2 networks.

ຖານຂໍ້ມູນ - ຖານຂໍ້ມູນຂອງຕົວລະບຸເຄືອຂ່າຍ, ເຄືອຂ່າຍຍ່ອຍ, ພອດ, ສະນຸກເກີ, ແລະອື່ນໆ.

ໃນຄວາມເປັນຈິງ, Neutron ຍອມຮັບການຮ້ອງຂໍ API ຈາກການສ້າງຫນ່ວຍງານເຄືອຂ່າຍໃດໆ, ຢືນຢັນຄໍາຮ້ອງຂໍ, ແລະຜ່ານ RPC (ຖ້າມັນເຂົ້າເຖິງບາງ plugin ຫຼືຕົວແທນ) ຫຼື REST API (ຖ້າມັນສື່ສານໃນ SDN) ສົ່ງໄປຫາຕົວແທນ (ຜ່ານ plugins) ໄດ້. ຄໍາແນະນໍາທີ່ຈໍາເປັນໃນການຈັດຕັ້ງການບໍລິການທີ່ຮ້ອງຂໍ.

ຕອນນີ້ໃຫ້ພວກເຮົາຫັນໄປຫາການຕິດຕັ້ງການທົດສອບ (ວິທີການທີ່ມັນຖືກນໍາໄປໃຊ້ແລະສິ່ງທີ່ລວມຢູ່ໃນມັນ, ພວກເຮົາຈະເບິ່ງຕໍ່ມາໃນພາກປະຕິບັດ) ແລະເບິ່ງວ່າແຕ່ລະອົງປະກອບຢູ່ໃສ:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

ໃນຄວາມເປັນຈິງ, ນັ້ນແມ່ນໂຄງສ້າງທັງຫມົດຂອງ Neutron. ຕອນນີ້ມັນຄຸ້ມຄ່າໃຊ້ເວລາໃນ plugin ML2.

Modular Layer 2

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, plugin ແມ່ນ plugin ຮາກ OpenStack ມາດຕະຖານແລະມີສະຖາປັດຕະຍະກໍາ modular.

ກ່ອນຫນ້າຂອງ plugin ML2 ມີໂຄງສ້າງ monolithic, ເຊິ່ງບໍ່ອະນຸຍາດໃຫ້, ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້ການຜະສົມຜະສານຂອງເຕັກໂນໂລຢີຈໍານວນຫນຶ່ງໃນການຕິດຕັ້ງດຽວ. ຕົວຢ່າງ, ທ່ານບໍ່ສາມາດໃຊ້ທັງ openvswitch ແລະ linuxbridge ໃນເວລາດຽວກັນ - ບໍ່ວ່າຈະເປັນຄັ້ງທໍາອິດຫຼືທີສອງ. ສໍາລັບເຫດຜົນນີ້, plugin ML2 ທີ່ມີສະຖາປັດຕະຍະກໍາຂອງມັນໄດ້ຖືກສ້າງຂື້ນ.

ML2 ມີສອງອົງປະກອບ - ໄດເວີສອງປະເພດ: ໄດເວີປະເພດແລະໄດເວີກົນໄກ.

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

ໄດເວີປະເພດປະກອບມີປະເພດເຄືອຂ່າຍຕໍ່ໄປນີ້:

Flat - ເຄືອຂ່າຍໂດຍບໍ່ມີການ tagging
VLANs - tagged ເຄືອ​ຂ່າຍ​
ທ້ອງຖິ່ນ — ເປັນ​ປະ​ເພດ​ພິ​ເສດ​ຂອງ​ເຄືອ​ຂ່າຍ​ສໍາ​ລັບ​ການ​ຕິດ​ຕັ້ງ​ທັງ​ຫມົດ​ໃນ​ຫນຶ່ງ (ການ​ຕິດ​ຕັ້ງ​ດັ່ງ​ກ່າວ​ແມ່ນ​ຈໍາ​ເປັນ​ສໍາ​ລັບ​ການ​ພັດ​ທະ​ນາ​ຫຼື​ສໍາ​ລັບ​ການ​ຝຶກ​ອົບ​ຮົມ​)
GRE - ເຄືອຂ່າຍຊ້ອນກັນໂດຍໃຊ້ອຸໂມງ GRE
VxLAN - ເຄືອຂ່າຍຊ້ອນກັນໂດຍໃຊ້ອຸໂມງ VxLAN

ໄດເວີກົນໄກ ກໍານົດເຄື່ອງມືທີ່ຮັບປະກັນການຈັດຕັ້ງຂອງເຕັກໂນໂລຢີທີ່ລະບຸໄວ້ໃນໄດເວີປະເພດ - ຕົວຢ່າງ, openvswitch, sr-iov, opendaylight, OVN, ແລະອື່ນໆ.

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

ຕົວຢ່າງ: ຖ້າພວກເຮົາໃຊ້ ML2 ຮ່ວມກັບ OVS, ຕົວແທນ L2 ຖືກຕິດຕັ້ງຢູ່ໃນແຕ່ລະ node ຄອມພິວເຕີທີ່ຈັດການ OVS. ຢ່າງໃດກໍຕາມ, ຖ້າພວກເຮົາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, OVN ຫຼື OpenDayLight, ຫຼັງຈາກນັ້ນການຄວບຄຸມຂອງ OVS ແມ່ນຢູ່ພາຍໃຕ້ສິດອໍານາດຂອງພວກເຂົາ - Neutron, ໂດຍຜ່ານ plugin ຮາກ, ໃຫ້ຄໍາສັ່ງກັບຕົວຄວບຄຸມ, ແລະມັນເຮັດແລ້ວສິ່ງທີ່ມັນບອກ.

ມາທົບທວນກ່ຽວກັບ Open vSwitch

ໃນປັດຈຸບັນ, ຫນຶ່ງໃນອົງປະກອບທີ່ສໍາຄັນຂອງ OpenStack ແມ່ນ Open vSwitch.
ເມື່ອຕິດຕັ້ງ OpenStack ໂດຍບໍ່ມີ SDN ຜູ້ຂາຍເພີ່ມເຕີມເຊັ່ນ Juniper Contrail ຫຼື Nokia Nuage, OVS ແມ່ນອົງປະກອບເຄືອຂ່າຍຕົ້ນຕໍຂອງເຄືອຂ່າຍຄລາວແລະ, ຮ່ວມກັນກັບ iptables, conntrack, namespaces, ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດວາງເຄືອຂ່າຍຊ້ອນກັນຫຼາຍຊັ້ນ. ຕາມທໍາມະຊາດ, ອົງປະກອບນີ້ສາມາດຖືກທົດແທນໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ເມື່ອນໍາໃຊ້ການແກ້ໄຂ SDN ຂອງພາກສ່ວນທີສາມທີ່ເປັນເຈົ້າຂອງ (ຜູ້ຂາຍ).

OVS ເປັນສະວິດຊອບແວແຫຼ່ງເປີດທີ່ຖືກອອກແບບມາສໍາລັບການນໍາໃຊ້ໃນສະພາບແວດລ້ອມ virtualized ເປັນຕົວສົ່ງຕໍ່ການຈະລາຈອນ virtual.

ໃນປັດຈຸບັນ, OVS ມີຫນ້າທີ່ທີ່ເຫມາະສົມຫຼາຍ, ເຊິ່ງປະກອບມີເຕັກໂນໂລຢີເຊັ່ນ QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ແລະອື່ນໆ.

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

ມີສາມອົງປະກອບທີ່ສໍາຄັນຂອງ OVS ທີ່ທ່ານຈໍາເປັນຕ້ອງລະວັງ:

• ໂມດູນ Kernel — ອົງປະກອບທີ່ຕັ້ງຢູ່ໃນຊ່ອງແກ່ນສານທີ່ປະມວນຜົນການຈະລາຈອນໂດຍອີງໃສ່ກົດລະບຽບທີ່ໄດ້ຮັບຈາກອົງປະກອບຄວບຄຸມ;
• vSwitch daemon (ovs-vswitchd) ແມ່ນຂະບວນການທີ່ເປີດຕົວໃນພື້ນທີ່ຜູ້ໃຊ້ທີ່ຮັບຜິດຊອບສໍາລັບການຂຽນໂປລແກລມໂມດູນ kernel - ນັ້ນແມ່ນ, ມັນສະແດງໂດຍກົງກ່ຽວກັບເຫດຜົນຂອງການເຮັດວຽກຂອງສະຫຼັບ.
• ເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນ - ຖານຂໍ້ມູນທ້ອງຖິ່ນທີ່ຕັ້ງຢູ່ໃນແຕ່ລະໂຮດທີ່ແລ່ນ OVS, ເຊິ່ງການຕັ້ງຄ່າຈະຖືກເກັບໄວ້. ຕົວຄວບຄຸມ SDN ສາມາດສື່ສານຜ່ານໂມດູນນີ້ໂດຍໃຊ້ OVSDB protocol.

ທັງໝົດນີ້ແມ່ນມາພ້ອມກັບອຸປະກອນການວິນິດໄສ ແລະການຈັດການ, ເຊັ່ນ: ovs-vsctl, ovs-appctl, ovs-ofctl, ແລະອື່ນໆ.

ໃນປັດຈຸບັນ, Openstack ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໂດຍຜູ້ປະຕິບັດການໂທລະຄົມເພື່ອເຄື່ອນຍ້າຍຫນ້າທີ່ເຄືອຂ່າຍໄປຫາມັນ, ເຊັ່ນ EPC, SBC, HLR, ແລະອື່ນໆ. ບາງຫນ້າທີ່ສາມາດດໍາລົງຊີວິດໂດຍບໍ່ມີບັນຫາກັບ OVS ເທົ່າທີ່ເປັນ, ແຕ່ສໍາລັບຕົວຢ່າງ, EPC ດໍາເນີນການຈະລາຈອນຈອງ - ຫຼັງຈາກນັ້ນມັນຜ່ານ. ຈໍານວນຂະຫນາດໃຫຍ່ຂອງການຈະລາຈອນ (ໃນປັດຈຸບັນປະລິມານການຈະລາຈອນບັນລຸຫຼາຍຮ້ອຍ gigabits ຕໍ່ວິນາທີ). ຕາມທໍາມະຊາດ, ການຂັບລົດການຈະລາຈອນດັ່ງກ່າວຜ່ານຊ່ອງແກ່ນ (ນັບຕັ້ງແຕ່ຜູ້ສົ່ງຕໍ່ຢູ່ທີ່ນັ້ນໂດຍຄ່າເລີ່ມຕົ້ນ) ບໍ່ແມ່ນຄວາມຄິດທີ່ດີທີ່ສຸດ. ດັ່ງນັ້ນ, OVS ມັກຈະຖືກນໍາໄປໃຊ້ທັງຫມົດໃນພື້ນທີ່ຂອງຜູ້ໃຊ້ໂດຍໃຊ້ເຕັກໂນໂລຢີການເລັ່ງ DPDK ເພື່ອສົ່ງຕໍ່ການຈະລາຈອນຈາກ NIC ໄປຫາພື້ນທີ່ຂອງຜູ້ໃຊ້ໂດຍຂ້າມ kernel.

ຫມາຍເຫດ: ສໍາລັບຟັງຊັນທີ່ນໍາໃຊ້ສໍາລັບຫນ້າທີ່ໂທລະຄົມ, ມັນເປັນໄປໄດ້ທີ່ຈະສົ່ງການຈະລາຈອນຈາກໂຫນດຄອມພິວເຕີ້ຂ້າມ OVS ໂດຍກົງໄປຫາອຸປະກອນສະຫຼັບ. ກົນໄກ SR-IOV ແລະ Passthrough ແມ່ນໃຊ້ເພື່ອຈຸດປະສົງນີ້.

ນີ້ເຮັດວຽກແນວໃດກ່ຽວກັບຮູບແບບທີ່ແທ້ຈິງ?

ແລ້ວ, ຕອນນີ້ໃຫ້ພວກເຮົາກ້າວໄປສູ່ພາກປະຕິບັດແລະເບິ່ງວ່າມັນເຮັດວຽກແນວໃດໃນການປະຕິບັດທັງຫມົດ.

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

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

ດັ່ງນັ້ນ, ໃຫ້ເລີ່ມຕົ້ນໃນຄໍາສັ່ງ. ທໍາອິດ, ທິດສະດີເລັກນ້ອຍ. ພວກເຮົາຈະຕິດຕັ້ງ Openstack ໂດຍໃຊ້ TripleO (Openstack on Openstack). ໂດຍເນື້ອແທ້ແລ້ວຂອງ TripleO ແມ່ນວ່າພວກເຮົາຕິດຕັ້ງ Openstack all-in-one (ໃນຫນຶ່ງ node), ເອີ້ນວ່າ undercloud, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ຄວາມສາມາດຂອງ Openstack ທີ່ໃຊ້ໃນການຕິດຕັ້ງ Openstack ມີຈຸດປະສົງສໍາລັບການດໍາເນີນງານ, ເອີ້ນວ່າ overcloud. Undercloud ຈະໃຊ້ຄວາມສາມາດທີ່ມີຢູ່ແລ້ວຂອງຕົນໃນການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍ (ໂລຫະເປົ່າ) - ໂຄງການ Ironic - ເພື່ອສະຫນອງ hypervisors ທີ່ຈະປະຕິບັດພາລະບົດບາດຂອງຄອມພິວເຕີ້, ການຄວບຄຸມ, ການເກັບຮັກສາ nodes. ນັ້ນແມ່ນ, ພວກເຮົາບໍ່ໄດ້ໃຊ້ເຄື່ອງມືພາກສ່ວນທີສາມໃດໆເພື່ອນໍາໃຊ້ Openstack - ພວກເຮົາໃຊ້ Openstack ໂດຍໃຊ້ Openstack. ມັນຈະກາຍເປັນທີ່ຊັດເຈນຂຶ້ນຍ້ອນວ່າການຕິດຕັ້ງດໍາເນີນໄປ, ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ຢຸດຢູ່ທີ່ນັ້ນແລະກ້າວໄປຂ້າງຫນ້າ.

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

ຫມາຍເຫດ: ນັບຕັ້ງແຕ່ພວກເຮົາຈະດໍາເນີນການ virtual machines ໃນສະພາບແວດລ້ອມ virtual ໂດຍອີງໃສ່ virtual machines, ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງເປີດໃຊ້ virtualization ຊ້ອນ.

ທ່ານ​ສາ​ມາດ​ກວດ​ສອບ​ໄດ້​ວ່າ​ການ virtualization ທີ່​ຕິດ​ຕັ້ງ​ໄດ້​ຖືກ​ເປີດ​ໃຊ້​ງານ​ຫຼື​ບໍ່​ເຊັ່ນ​ນີ້​:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

ພວກເຮົາຈໍາເປັນຕ້ອງປະກອບວົງຈອນດັ່ງຕໍ່ໄປນີ້ຈາກເຄື່ອງ virtual:

ໃນກໍລະນີຂອງຂ້ອຍ, ເພື່ອເຊື່ອມຕໍ່ເຄື່ອງ virtual ທີ່ເປັນສ່ວນຫນຶ່ງຂອງການຕິດຕັ້ງໃນອະນາຄົດ (ແລະຂ້ອຍໄດ້ຮັບ 7 ຂອງພວກເຂົາ, ແຕ່ເຈົ້າສາມາດໄປໄດ້ດ້ວຍ 4 ຖ້າເຈົ້າບໍ່ມີຊັບພະຍາກອນຫຼາຍ), ຂ້ອຍໃຊ້ OpenvSwitch. ຂ້າພະເຈົ້າໄດ້ສ້າງຂົວ ovs ຫນຶ່ງແລະເຊື່ອມຕໍ່ເຄື່ອງຈັກ virtual ກັບມັນຜ່ານ port-groups. ເພື່ອເຮັດສິ່ງນີ້, ຂ້ອຍສ້າງໄຟລ໌ xml ແບບນີ້:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

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

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

ຕອນນີ້ພວກເຮົາແກ້ໄຂການຕັ້ງຄ່າພອດ hypervisor:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

ໝາຍເຫດ: ໃນສະຖານະການນີ້, ທີ່ຢູ່ໃນພອດ ovs-br1 ຈະບໍ່ສາມາດເຂົ້າເຖິງໄດ້ເພາະມັນບໍ່ມີແທັກ vlan. ເພື່ອແກ້ໄຂບັນຫານີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ອອກຄໍາສັ່ງ sudo ovs-vsctl set port ovs-br1 tag=100. ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກ reboot, tag ນີ້ຈະຫາຍໄປ (ຖ້າໃຜຮູ້ວິທີເຮັດໃຫ້ມັນຢູ່ໃນສະຖານທີ່, ຂ້ອຍຈະຂອບໃຈຫຼາຍ). ແຕ່ນີ້ບໍ່ສໍາຄັນຫຼາຍ, ເພາະວ່າພວກເຮົາຈະຕ້ອງການທີ່ຢູ່ນີ້ພຽງແຕ່ໃນລະຫວ່າງການຕິດຕັ້ງແລະຈະບໍ່ຕ້ອງການມັນເມື່ອ Openstack ຖືກນໍາໄປໃຊ້ຢ່າງເຕັມທີ່.

ຕໍ່ໄປ, ພວກເຮົາສ້າງເຄື່ອງ undercloud:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

ໃນລະຫວ່າງການຕິດຕັ້ງ, ທ່ານກໍານົດພາລາມິເຕີທີ່ຈໍາເປັນທັງຫມົດ, ເຊັ່ນ: ຊື່ເຄື່ອງ, ລະຫັດຜ່ານ, ຜູ້ໃຊ້, ເຄື່ອງແມ່ຂ່າຍ ntp, ແລະອື່ນໆ, ທ່ານສາມາດ configure ports ໄດ້ທັນທີ, ແຕ່ສໍາລັບຂ້າພະເຈົ້າສ່ວນບຸກຄົນ, ຫຼັງຈາກການຕິດຕັ້ງ, ມັນງ່າຍທີ່ຈະເຂົ້າສູ່ລະບົບໂດຍຜ່ານເຄື່ອງ. console ແລະແກ້ໄຂໄຟລ໌ທີ່ຈໍາເປັນ. ຖ້າທ່ານມີຮູບພາບທີ່ກຽມພ້ອມແລ້ວ, ທ່ານສາມາດນໍາໃຊ້ມັນ, ຫຼືເຮັດສິ່ງທີ່ຂ້ອຍໄດ້ເຮັດ - ດາວໂຫລດຮູບພາບ Centos 7 ຫນ້ອຍທີ່ສຸດແລະໃຊ້ມັນເພື່ອຕິດຕັ້ງ VM.

ຫຼັງຈາກການຕິດຕັ້ງສົບຜົນສໍາເລັດ, ທ່ານຄວນມີເຄື່ອງ virtual ທີ່ທ່ານສາມາດຕິດຕັ້ງ undercloud

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

ທໍາອິດ, ຕິດຕັ້ງເຄື່ອງມືທີ່ຈໍາເປັນສໍາລັບຂະບວນການຕິດຕັ້ງ:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

ການຕິດຕັ້ງ undercloud

ພວກເຮົາສ້າງຜູ້ໃຊ້ stack, ຕັ້ງລະຫັດຜ່ານ, ເພີ່ມມັນໃສ່ sudoer ແລະໃຫ້ລາວສາມາດປະຕິບັດຄໍາສັ່ງຮາກຜ່ານ sudo ໂດຍບໍ່ຕ້ອງໃສ່ລະຫັດຜ່ານ:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

ຕອນນີ້ພວກເຮົາລະບຸຊື່ເຕັມ undercloud ໃນໄຟລ໌ hosts:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

ຕໍ່ໄປ, ພວກເຮົາເພີ່ມ repositories ແລະຕິດຕັ້ງຊອບແວທີ່ພວກເຮົາຕ້ອງການ:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

ຕໍ່ໄປ, ຄັດລອກໄຟລ໌ການຕັ້ງຄ່າ undercloud ໄປຫາ stack directory ເຮືອນຂອງຜູ້ໃຊ້:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂໄຟລ໌ນີ້, ປັບມັນກັບການຕິດຕັ້ງຂອງພວກເຮົາ.

ທ່ານຈໍາເປັນຕ້ອງເພີ່ມເສັ້ນເຫຼົ່ານີ້ໃສ່ຈຸດເລີ່ມຕົ້ນຂອງໄຟລ໌:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

ດັ່ງນັ້ນ, ໃຫ້ໄປໂດຍຜ່ານການຕັ້ງຄ່າ:

undercloud_hostname — ຊື່ເຕັມຂອງເຊີບເວີ undercloud, ຕ້ອງກົງກັບລາຍການຢູ່ໃນເຊີບເວີ DNS

local_ip — ທີ່​ຢູ່ undercloud ທ້ອງ​ຖິ່ນ​ເພື່ອ​ໃຫ້​ການ​ສະ​ຫນອງ​ເຄືອ​ຂ່າຍ​

network_gateway — ທີ່​ຢູ່​ທ້ອງ​ຖິ່ນ​ດຽວ​ກັນ​, ເຊິ່ງ​ຈະ​ເຮັດ​ຫນ້າ​ທີ່​ເປັນ​ປະ​ຕູ​ສໍາ​ລັບ​ການ​ເຂົ້າ​ເຖິງ​ໂລກ​ພາຍ​ນອກ​ໃນ​ລະ​ຫວ່າງ​ການ​ຕິດ​ຕັ້ງ​ຂອງ overcloud nodes​, ຍັງ coincides ກັບ ip ທ້ອງ​ຖິ່ນ

undercloud_public_host — ທີ່ຢູ່ API ພາຍນອກ, ທີ່ຢູ່ຟຣີໃດໆຈາກເຄືອຂ່າຍການສະໜອງແມ່ນຖືກມອບໝາຍ

undercloud_admin_host ທີ່ຢູ່ API ພາຍໃນ, ທີ່ຢູ່ຟຣີໃດໆຈາກເຄືອຂ່າຍການສະຫນອງແມ່ນຖືກມອບຫມາຍ

undercloud_nameservers - ເຊີບເວີ DNS

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

local_interface ການໂຕ້ຕອບໃນການສະຫນອງເຄືອຂ່າຍ. ອິນເຕີເຟດນີ້ຈະຖືກປັບຕັ້ງຄ່າຄືນໃໝ່ໃນລະຫວ່າງການນຳໃຊ້ undercloud, ສະນັ້ນທ່ານຕ້ອງມີສອງອິນເຕີເຟດເທິງ undercloud - ອັນໜຶ່ງເພື່ອເຂົ້າເຖິງມັນ, ອັນທີສອງສຳລັບການສະໜອງ

local_mtu — MTU. ເນື່ອງຈາກພວກເຮົາມີຫ້ອງທົດລອງແລະຂ້ອຍມີ MTU ຂອງ 1500 ໃນພອດສະຫຼັບ OVS, ມັນຈໍາເປັນຕ້ອງຕັ້ງມັນເປັນ 1450 ເພື່ອໃຫ້ແພັກເກັດທີ່ຖືກຫຸ້ມຢູ່ໃນ VxLAN ສາມາດຜ່ານໄດ້.

network_cidr - ການ​ສະ​ຫນອງ​ເຄືອ​ຂ່າຍ​

masquerade — ການ​ນໍາ​ໃຊ້ NAT ເພື່ອ​ເຂົ້າ​ເຖິງ​ເຄືອ​ຂ່າຍ​ພາຍ​ນອກ​

masquerade_network - ເຄືອ​ຂ່າຍ​ທີ່​ຈະ NATed​

dhcp_start — ທີ່​ຢູ່​ເລີ່ມ​ຕົ້ນ​ຂອງ​ທີ່​ຢູ່​ທີ່​ຢູ່​ທີ່​ຢູ່​ຈະ​ຖືກ​ມອບ​ຫມາຍ​ໃຫ້ nodes ໃນ​ລະ​ຫວ່າງ​ການ​ນໍາ​ໃຊ້ overcloud​

dhcp_end — ທີ່​ຢູ່​ສຸດ​ທ້າຍ​ຂອງ​ທີ່​ຢູ່​ທີ່​ຢູ່​ທີ່​ຢູ່​ຈະ​ຖືກ​ມອບ​ຫມາຍ​ໃຫ້ nodes ໃນ​ລະ​ຫວ່າງ​ການ​ນໍາ​ໃຊ້ overcloud​

inspection_iprange — ສະ​ນຸກ​ເກີ​ຂອງ​ທີ່​ຢູ່​ທີ່​ຈໍາ​ເປັນ​ສໍາ​ລັບ​ການ introspection (ບໍ່​ຄວນ​ທັບ​ຊ້ອນ​ກັບ​ສະ​ນຸກ​ເກີ​ຂ້າງ​ເທິງ​)

scheduler_max_attempts - ຈໍາ​ນວນ​ສູງ​ສຸດ​ຂອງ​ຄວາມ​ພະ​ຍາ​ຍາມ​ໃນ​ການ​ຕິດ​ຕັ້ງ overcloud (ຕ້ອງ​ມີ​ຫຼາຍ​ກ​່​ວາ​ຫຼື​ເທົ່າ​ທຽມ​ກັບ​ຈໍາ​ນວນ​ຂອງ nodes​)

ຫຼັງຈາກໄຟລ໌ໄດ້ຖືກອະທິບາຍ, ທ່ານສາມາດໃຫ້ຄໍາສັ່ງເພື່ອປັບໃຊ້ undercloud:

openstack undercloud install

ຂັ້ນຕອນຈະໃຊ້ເວລາຈາກ 10 ຫາ 30 ນາທີຂຶ້ນກັບທາດເຫຼັກຂອງທ່ານ. ໃນ​ທີ່​ສຸດ​ທ່ານ​ຄວນ​ຈະ​ເຫັນ​ຜົນ​ຜະ​ລິດ​ດັ່ງ​ນີ້​:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

ຜົນໄດ້ຮັບນີ້ບອກວ່າທ່ານໄດ້ຕິດຕັ້ງ undercloud ສົບຜົນສໍາເລັດແລະຕອນນີ້ທ່ານສາມາດກວດເບິ່ງສະຖານະຂອງ undercloud ແລະດໍາເນີນການຕິດຕັ້ງ overcloud.

ຖ້າທ່ານເບິ່ງຜົນຜະລິດ ifconfig, ທ່ານຈະເຫັນວ່າການໂຕ້ຕອບຂົວໃຫມ່ໄດ້ປາກົດຂຶ້ນ

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ຕອນນີ້ການນຳໃຊ້ Overcloud ຈະດຳເນີນຜ່ານສ່ວນຕິດຕໍ່ນີ້.

ຈາກຜົນໄດ້ຮັບຂ້າງລຸ່ມນີ້ທ່ານສາມາດເຫັນໄດ້ວ່າພວກເຮົາມີບໍລິການທັງຫມົດໃນຫນຶ່ງ node:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

ຂ້າງລຸ່ມນີ້ແມ່ນການຕັ້ງຄ່າຂອງພາກສ່ວນເຄືອຂ່າຍ undercloud:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

ການຕິດຕັ້ງ overcloud

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

ໃຫ້ໄປທີ່ໂຟນເດີທີ່ມີແຜ່ນຂອງເຄື່ອງ virtual ຂອງພວກເຮົາແລະສ້າງແຜ່ນທີ່ມີຂະຫນາດທີ່ຕ້ອງການ:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

ເນື່ອງຈາກພວກເຮົາດໍາເນີນການເປັນຮາກ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນເຈົ້າຂອງແຜ່ນເຫຼົ່ານີ້ເພື່ອບໍ່ໃຫ້ມີບັນຫາກັບສິດທິ:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

ຫມາຍເຫດ: ຖ້າທ່ານບໍ່ວາງແຜນທີ່ຈະຕິດຕັ້ງ ceph ເພື່ອສຶກສາມັນ, ຄໍາສັ່ງບໍ່ໄດ້ສ້າງຢ່າງຫນ້ອຍ 3 nodes ທີ່ມີຢ່າງຫນ້ອຍສອງແຜ່ນ, ແຕ່ໃນແມ່ແບບຊີ້ໃຫ້ເຫັນວ່າ virtual disks vda, vdb, ແລະອື່ນໆ.

ດີຫຼາຍ, ຕອນນີ້ພວກເຮົາຈໍາເປັນຕ້ອງກໍານົດເຄື່ອງຈັກເຫຼົ່ານີ້ທັງຫມົດ:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

ໃນຕອນທ້າຍມີຄໍາສັ່ງ -print-xml> /tmp/storage-1.xml, ເຊິ່ງສ້າງໄຟລ໌ xml ທີ່ມີຄໍາອະທິບາຍຂອງແຕ່ລະເຄື່ອງໃນ /tmp/ folder; ຖ້າທ່ານບໍ່ເພີ່ມມັນ, ທ່ານຈະບໍ່ເປັນ. ສາມາດກໍານົດເຄື່ອງຈັກ virtual.

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍານົດເຄື່ອງຈັກເຫຼົ່ານີ້ທັງຫມົດໃນ virsh:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ໃນປັດຈຸບັນ nuance ຂະຫນາດນ້ອຍ - tripleO ໃຊ້ IPMI ເພື່ອຈັດການເຄື່ອງແມ່ຂ່າຍໃນລະຫວ່າງການຕິດຕັ້ງແລະການກວດກາ.

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

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

ຕິດຕັ້ງ vbmc:

yum install yum install python2-virtualbmc

ຖ້າ OS ຂອງທ່ານບໍ່ສາມາດຊອກຫາແພັກເກັດໄດ້, ຫຼັງຈາກນັ້ນໃຫ້ເພີ່ມ repository:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

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

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

ເພື່ອໃຫ້ພວກມັນປາກົດ, ພວກເຂົາຕ້ອງໄດ້ຮັບການປະກາດດ້ວຍຕົນເອງເຊັ່ນນີ້:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

ແລະການສໍາພັດສຸດທ້າຍ - ທ່ານຈໍາເປັນຕ້ອງແກ້ໄຂກົດລະບຽບຂອງ Firewall (ຫຼືປິດການໃຊ້ງານຢ່າງສົມບູນ):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

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

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

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

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ຂັ້ນ​ຕອນ​ຕໍ່​ໄປ​ແມ່ນ introspection ຂອງ nodes ທີ່ overcloud ຈະ​ໄດ້​ຮັບ​ການ​ຕິດ​ຕັ້ງ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກະກຽມໄຟລ໌ json ທີ່ມີຄໍາອະທິບາຍກ່ຽວກັບຂໍ້ຂອງພວກເຮົາ. ກະລຸນາຮັບຊາບວ່າ, ບໍ່ຄືກັບການຕິດຕັ້ງໃນເຊີບເວີເປົ່າ, ໄຟລ໌ຊີ້ໃຫ້ເຫັນພອດທີ່ vbmc ແລ່ນສໍາລັບແຕ່ລະເຄື່ອງ.

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

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

ຕອນນີ້ພວກເຮົາກະກຽມໄຟລ໌ json. ພວກເຮົາຈໍາເປັນຕ້ອງຊີ້ບອກທີ່ຢູ່ poppy ຂອງພອດໂດຍຜ່ານການສະຫນອງການຈະດໍາເນີນການ, ຕົວກໍານົດການຂອງ nodes, ໃຫ້ຊື່ໃຫ້ເຂົາເຈົ້າແລະຊີ້ບອກວິທີການໄປ ipmi:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

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

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

ກຳລັງອັບໂຫລດຮູບພາບໃສ່ undercloud:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

ກຳລັງກວດເບິ່ງວ່າຮູບທັງໝົດໄດ້ໂຫລດແລ້ວ

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

ອີກອັນຫນຶ່ງ - ທ່ານຈໍາເປັນຕ້ອງເພີ່ມເຄື່ອງແມ່ຂ່າຍ DNS:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

ໃນປັດຈຸບັນພວກເຮົາສາມາດໃຫ້ຄໍາສັ່ງສໍາລັບການ introspection:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້ຈາກຜົນຜະລິດ, ທຸກສິ່ງທຸກຢ່າງສໍາເລັດໂດຍບໍ່ມີຂໍ້ຜິດພາດ. ໃຫ້ກວດເບິ່ງວ່າ nodes ທັງຫມົດແມ່ນຢູ່ໃນສະຖານະທີ່ມີຢູ່:

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

ຕໍ່ໄປ, ພວກເຮົາຈໍາເປັນຕ້ອງຊີ້ບອກວ່າ node ໃດຈະປະຕິບັດຫນ້າທີ່ - ນັ້ນແມ່ນ, ຊີ້ບອກ profile ທີ່ node ຈະ deploy:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

ລະບຸໂປຣໄຟລ໌ສໍາລັບແຕ່ລະ node:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

ໃຫ້ກວດເບິ່ງວ່າພວກເຮົາໄດ້ເຮັດທຸກຢ່າງຢ່າງຖືກຕ້ອງ:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

ຖ້າທຸກຢ່າງຖືກຕ້ອງ, ພວກເຮົາໃຫ້ຄຳສັ່ງເພື່ອນຳໃຊ້ overcloud:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

ຫມາຍເຫດ: ຕົວແປ qemu ປະເພດ --libvirt-type ແມ່ນມີຄວາມຈໍາເປັນໃນກໍລະນີນີ້, ເພາະວ່າພວກເຮົາຈະໃຊ້ virtualization ຊ້ອນ. ຖ້າບໍ່ດັ່ງນັ້ນ, ທ່ານຈະບໍ່ສາມາດແລ່ນເຄື່ອງ virtual ໄດ້.

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

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

ໃນປັດຈຸບັນທ່ານມີ openstack ສະບັບເກືອບເຕັມທີ່, ທີ່ທ່ານສາມາດສຶກສາ, ທົດລອງ, ແລະອື່ນໆ.

ໃຫ້ກວດເບິ່ງວ່າທຸກຢ່າງເຮັດວຽກຢ່າງຖືກຕ້ອງ. ໃນ stack directory ເຮືອນຂອງຜູ້ໃຊ້ມີສອງໄຟລ໌ - stackrc ຫນຶ່ງ (ສໍາລັບການຄຸ້ມຄອງ undercloud) ແລະທີສອງ overcloudrc (ສໍາລັບການຄຸ້ມຄອງ overcloud). ໄຟລ໌ເຫຼົ່ານີ້ຕ້ອງຖືກລະບຸວ່າເປັນແຫຼ່ງ, ເພາະວ່າພວກມັນມີຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການພິສູດຢືນຢັນ.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

ການຕິດຕັ້ງຂອງຂ້ອຍຍັງຕ້ອງການການສໍາພັດເລັກນ້ອຍ - ການເພີ່ມເສັ້ນທາງໃນຕົວຄວບຄຸມ, ເພາະວ່າເຄື່ອງທີ່ຂ້ອຍເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ. ເພື່ອເຮັດສິ່ງນີ້, ໄປທີ່ control-1 ພາຍໃຕ້ບັນຊີ heat-admin ແລະລົງທະບຽນເສັ້ນທາງ

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

ແລ້ວ, ຕອນນີ້ເຈົ້າສາມາດເຂົ້າໄປໃນຂອບເຂດ. ຂໍ້ມູນທັງໝົດ - ທີ່ຢູ່, ເຂົ້າສູ່ລະບົບ ແລະລະຫັດຜ່ານ - ຢູ່ໃນໄຟລ໌ /home/stack/overcloudrc. ແຜນວາດສຸດທ້າຍເບິ່ງຄືດັ່ງນີ້:

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

ການຈະລາຈອນໄຫຼລະຫວ່າງເຄື່ອງ virtual ແນວໃດ?

ໃນບົດຄວາມນີ້ພວກເຮົາຈະເບິ່ງສາມທາງເລືອກສໍາລັບການຖ່າຍທອດການຈະລາຈອນ

• ສອງເຄື່ອງຢູ່ໃນ hypervisor ຫນຶ່ງໃນເຄືອຂ່າຍ L2
• ສອງເຄື່ອງຈັກໃນ hypervisors ທີ່ແຕກຕ່າງກັນໃນເຄືອຂ່າຍ L2 ດຽວກັນ
• ສອງເຄື່ອງຢູ່ໃນເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ (ການປົ່ງຮາກອອກຕາມເຄືອຂ່າຍຂ້າມ)

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

ເພື່ອກວດສອບ, ໃຫ້ພວກເຮົາເອົາແຜນວາດຕໍ່ໄປນີ້ຮ່ວມກັນ:

ພວກເຮົາໄດ້ສ້າງ 4 ເຄື່ອງ virtual - 3 ໃນເຄືອຂ່າຍ L2 ຫນຶ່ງ - net-1, ແລະອີກ 1 ເຄື່ອງໃນເຄືອຂ່າຍ net-2

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

ຂໍໃຫ້ເບິ່ງສິ່ງທີ່ hypervisors ເຄື່ອງຈັກທີ່ສ້າງຂື້ນຢູ່ເທິງ:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
ເຄື່ອງຈັກ vm-1 ແລະ vm-3 ຕັ້ງຢູ່ໃນຄອມພິວເຕີ້ 0, ເຄື່ອງຈັກ vm-2 ແລະ vm-4 ຕັ້ງຢູ່ໃນ node compute-1.

ນອກຈາກນັ້ນ, router virtual ໄດ້ຖືກສ້າງຂື້ນເພື່ອເປີດໃຊ້ເສັ້ນທາງລະຫວ່າງເຄືອຂ່າຍທີ່ລະບຸໄວ້:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

router ມີສອງພອດ virtual, ເຊິ່ງເຮັດຫນ້າທີ່ເປັນປະຕູສໍາລັບເຄືອຂ່າຍ:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ໃນປັດຈຸບັນ, node ມີສາມຂົວ ovs - br-int, br-tun, br-ex. ລະຫວ່າງພວກເຂົາ, ດັ່ງທີ່ພວກເຮົາເຫັນ, ມີຊຸດຂອງການໂຕ້ຕອບ. ເພື່ອຄວາມສະດວກໃນການເຂົ້າໃຈ, ໃຫ້ພວກເຮົາວາງແຜນການໂຕ້ຕອບທັງຫມົດເຫຼົ່ານີ້ຢູ່ໃນແຜນວາດແລະເບິ່ງວ່າມີຫຍັງເກີດຂື້ນ.

ຊອກຫາຢູ່ໃນທີ່ຢູ່ທີ່ອຸໂມງ VxLAN ຖືກຍົກຂຶ້ນມາ, ມັນສາມາດເຫັນໄດ້ວ່າອຸໂມງຫນຶ່ງຖືກຍົກຂຶ້ນມາເປັນ compute-1 (192.168.255.26), tunnel ທີສອງເບິ່ງເປັນ control-1 (192.168.255.15). ແຕ່ສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່າ br-ex ບໍ່ມີການໂຕ້ຕອບທາງກາຍະພາບ, ແລະຖ້າທ່ານເບິ່ງສິ່ງທີ່ກະແສຖືກຕັ້ງຄ່າ, ທ່ານສາມາດເບິ່ງວ່າຂົວນີ້ສາມາດລຸດລົງພຽງແຕ່ການຈະລາຈອນໃນປັດຈຸບັນ.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້ຈາກຜົນຜະລິດ, ທີ່ຢູ່ແມ່ນ screwed ໂດຍກົງກັບພອດທາງດ້ານຮ່າງກາຍ, ແລະບໍ່ແມ່ນກັບການໂຕ້ຕອບຂົວ virtual.

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

ຕາມກົດລະບຽບທໍາອິດ, ທຸກສິ່ງທຸກຢ່າງທີ່ມາຈາກພອດ phy-br-ex ຕ້ອງຖືກຍົກເລີກ.
ຕົວຈິງແລ້ວ, ໃນປັດຈຸບັນບໍ່ມີບ່ອນອື່ນສໍາລັບການຈະລາຈອນເຂົ້າມາໃນຂົວນີ້ຍົກເວັ້ນຈາກການໂຕ້ຕອບນີ້ (ການໂຕ້ຕອບກັບ br-int), ແລະການຕັດສິນໂດຍການຫຼຸດລົງ, ການຈະລາຈອນ BUM ໄດ້ບິນເຂົ້າໄປໃນຂົວແລ້ວ.

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

ພວກ​ເຮົາ​ໄດ້​ຄັດ​ອອກ​ບັນ​ດາ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ການ​ຄອມ​ພິວ​ເຕີ​, ໃຫ້​ເຮົາ​ໄປ​ທີ່​ຂໍ້​ຄວບ​ຄຸມ​.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

ພອດນີ້ຖືກຜູກມັດກັບຂົວ br-ex ແລະເນື່ອງຈາກບໍ່ມີປ້າຍ vlan ຢູ່ເທິງມັນ, ພອດນີ້ແມ່ນພອດລໍາຕົ້ນທີ່ vlans ທັງຫມົດໄດ້ຮັບອະນຸຍາດ, ປະຈຸບັນການຈະລາຈອນອອກໄປຂ້າງນອກໂດຍບໍ່ມີປ້າຍຊື່, ດັ່ງທີ່ລະບຸໄວ້ໂດຍ vlan-id 0 ໃນ. ຜົນຜະລິດຂ້າງເທິງ.

ທຸກສິ່ງທຸກຢ່າງອື່ນໃນປັດຈຸບັນແມ່ນຄ້າຍຄືກັນກັບ node ຄອມພິວເຕີ - ຂົວດຽວກັນ, tunnels ດຽວກັນໄປຫາສອງ nodes ຄອມພິວເຕີ.

ພວກເຮົາຈະບໍ່ພິຈາລະນາ nodes ການເກັບຮັກສາໃນບົດຄວາມນີ້, ແຕ່ສໍາລັບການເຂົ້າໃຈມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເວົ້າວ່າສ່ວນເຄືອຂ່າຍຂອງ nodes ເຫຼົ່ານີ້ແມ່ນ banal ເຖິງຈຸດຂອງຄວາມອັບອາຍ. ໃນກໍລະນີຂອງພວກເຮົາ, ມີພຽງແຕ່ຫນຶ່ງພອດທາງດ້ານຮ່າງກາຍ (eth0) ທີ່ມີທີ່ຢູ່ IP ທີ່ຖືກມອບຫມາຍໃຫ້ມັນແລະນັ້ນແມ່ນມັນ. ບໍ່ມີອຸໂມງ VxLAN, ຂົວອຸໂມງ, ແລະອື່ນໆ - ບໍ່ມີ ovs ທັງຫມົດ, ເນື່ອງຈາກວ່າບໍ່ມີຈຸດຢູ່ໃນມັນ. ເມື່ອໃຊ້ການໂດດດ່ຽວເຄືອຂ່າຍ, ໂຫນດນີ້ຈະມີສອງສ່ວນຕິດຕໍ່ (ພອດທາງດ້ານຮ່າງກາຍ, bodny, ຫຼືພຽງແຕ່ສອງ vlans - ມັນບໍ່ສໍາຄັນ - ມັນຂຶ້ນກັບສິ່ງທີ່ທ່ານຕ້ອງການ) - ຫນຶ່ງສໍາລັບການຄຸ້ມຄອງ, ອັນທີສອງສໍາລັບການຈະລາຈອນ (ຂຽນໃສ່ VM disk. , ອ່ານ​ຈາກ​ແຜ່ນ​, ແລະ​ອື່ນໆ​)

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

ມາຮອດປະຈຸ, ເຄືອຂ່າຍຂອງພວກເຮົາເບິ່ງຄືວ່າ:

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

ເຄື່ອງຈັກມີພຽງແຕ່ຫນຶ່ງການໂຕ້ຕອບ virtual - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

ການໂຕ້ຕອບນີ້ເບິ່ງຢູ່ໃນຂົວ linux:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້ຈາກຜົນຜະລິດ, ມີພຽງແຕ່ສອງການໂຕ້ຕອບໃນຂົວ - tap95d96a75-a0 ແລະ qvb95d96a75-a0.

ໃນທີ່ນີ້ມັນຄຸ້ມຄ່າທີ່ຈະຢູ່ເລັກນ້ອຍກ່ຽວກັບປະເພດຂອງອຸປະກອນເຄືອຂ່າຍ virtual ໃນ OpenStack:
vtap - ການໂຕ້ຕອບສະເໝືອນຕິດຢູ່ກັບຕົວຢ່າງ (VM)
qbr - ຂົວ Linux
qvb ແລະ qvo - ຄູ່ vEth ເຊື່ອມຕໍ່ກັບຂົວ Linux ແລະ Open vSwitch bridge
br-int, br-tun, br-vlan — ເປີດຂົວ vSwitch
patch-, int-br-, phy-br- - ເປີດ vSwitch patch interfaces ເຊື່ອມຕໍ່ຂົວ
qg, qr, ha, fg, sg - ເປີດຜອດ vSwitch ທີ່ໃຊ້ໂດຍອຸປະກອນສະເໝືອນເພື່ອເຊື່ອມຕໍ່ກັບ OVS

ຕາມທີ່ທ່ານເຂົ້າໃຈ, ຖ້າພວກເຮົາມີພອດ qvb95d96a75-a0 ໃນຂົວ, ເຊິ່ງເປັນຄູ່ vEth, ຫຼັງຈາກນັ້ນບາງບ່ອນມີຄູ່ຮ່ວມງານຂອງມັນ, ເຊິ່ງຄວນເອີ້ນວ່າ qvo95d96a75-a0. ໃຫ້ເບິ່ງວ່າພອດໃດຢູ່ໃນ OVS.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

ດັ່ງທີ່ພວກເຮົາສາມາດເຫັນໄດ້, ພອດແມ່ນຢູ່ໃນ br-int. Br-int ເຮັດໜ້າທີ່ເປັນສະຫຼັບທີ່ປິດພອດເຄື່ອງ virtual. ນອກເຫນືອຈາກ qvo95d96a75-a0, ພອດ qvo5bd37136-47 ແມ່ນເຫັນໄດ້ໃນຜົນຜະລິດ. ນີ້ແມ່ນພອດໄປຫາເຄື່ອງ virtual ທີສອງ. ດັ່ງນັ້ນ, ແຜນວາດຂອງພວກເຮົາໃນປັດຈຸບັນເບິ່ງຄືວ່ານີ້:

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

ນັ້ນແມ່ນ, ໃນທີ່ສຸດໂຄງການເບິ່ງຄືວ່ານີ້:

ສອງເຄື່ອງຢູ່ໃນ hypervisor ຫນຶ່ງໃນເຄືອຂ່າຍ L2

ເນື່ອງຈາກ VMs ສອງອັນນີ້ຕັ້ງຢູ່ໃນເຄືອຂ່າຍ L2 ດຽວກັນ ແລະຢູ່ໃນ hypervisor ດຽວກັນ, ການຈະລາຈອນລະຫວ່າງພວກມັນຈະໄຫຼຕາມເຫດຜົນໃນທ້ອງຖິ່ນຜ່ານ br-int, ເນື່ອງຈາກວ່າທັງສອງເຄື່ອງຈະຢູ່ໃນ VLAN ດຽວກັນ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ສອງເຄື່ອງຈັກໃນ hypervisors ທີ່ແຕກຕ່າງກັນໃນເຄືອຂ່າຍ L2 ດຽວກັນ

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

ທີ່ຢູ່ຂອງເຄື່ອງ virtual ລະຫວ່າງທີ່ພວກເຮົາຈະເບິ່ງການຈະລາຈອນ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

ພວກເຮົາເບິ່ງຕາຕະລາງການສົ່ງຕໍ່ໃນ br-int ໃນ compute-0:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ການຈະລາຈອນຄວນໄປຫາທ່າເຮືອ 2 - ໃຫ້ພວກເຮົາເບິ່ງວ່າມັນເປັນທ່າເຮືອປະເພດໃດ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

ນີ້ແມ່ນ patch-tun - ນັ້ນແມ່ນ, ການໂຕ້ຕອບໃນ br-tun. ມາເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນກັບຊຸດໃນ br-tun:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

ແພັກເກັດຖືກຫຸ້ມຫໍ່ຢູ່ໃນ VxLAN ແລະຖືກສົ່ງໄປຫາພອດ 2. ໃຫ້ເບິ່ງບ່ອນທີ່ພອດ 2 ນໍາ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

ນີ້ແມ່ນອຸໂມງ vxlan ໃນຄອມພິວເຕີ-1:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ໃຫ້ໄປທີ່ compute-1 ແລະເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນຕໍ່ໄປກັບຊຸດ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac ຢູ່ໃນຕາຕະລາງການສົ່ງຕໍ່ br-int ໃນ compute-1, ແລະດັ່ງທີ່ເຫັນໄດ້ຈາກຜົນຜະລິດຂ້າງເທິງ, ມັນເຫັນໄດ້ຜ່ານພອດ 2, ເຊິ່ງເປັນພອດໄປຫາ br-tun:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

ແລ້ວ, ພວກເຮົາເຫັນວ່າໃນ br-int ໃນ compute-1 ມີ poppy ຈຸດຫມາຍປາຍທາງ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

ນັ້ນແມ່ນ, ແພກເກັດທີ່ໄດ້ຮັບຈະບິນໄປຫາພອດ 3, ທີ່ຢູ່ເບື້ອງຫຼັງມີເຄື່ອງ virtual instance-00000003 ແລ້ວ.

ຄວາມງາມຂອງການນໍາໃຊ້ Openstack ສໍາລັບການຮຽນຮູ້ກ່ຽວກັບໂຄງສ້າງພື້ນຖານ virtual ແມ່ນວ່າພວກເຮົາສາມາດເກັບກໍາການຈະລາຈອນລະຫວ່າງ hypervisors ໄດ້ຢ່າງງ່າຍດາຍແລະເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນກັບມັນ. ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາຈະເຮັດໃນປັດຈຸບັນ, ແລ່ນ tcpdump ໃນພອດ vnet ໄປສູ່ compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

ແຖວທໍາອິດສະແດງໃຫ້ເຫັນວ່າ Patek ຈາກທີ່ຢູ່ 10.0.1.85 ໄປຫາທີ່ຢູ່ 10.0.1.88 (ການຈາລະຈອນ ICMP), ແລະມັນຖືກຫໍ່ຢູ່ໃນແພັກເກັດ VxLAN ກັບ vni 22 ແລະແພັກເກັດໄປຈາກໂຮດ 192.168.255.19 (compute-0) ໄປເປັນເຈົ້າພາບ 192.168.255.26. .1 (ຄອມພິວເຕີ-XNUMX). ພວກເຮົາສາມາດກວດເບິ່ງວ່າ VNI ກົງກັບທີ່ລະບຸໄວ້ໃນ ovs.

ໃຫ້ກັບຄືນໄປຫາເສັ້ນນີ້ actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 ແມ່ນ vni ໃນລະບົບເລກຖານສິບຫົກ. ໃຫ້ພວກເຮົາປ່ຽນຕົວເລກນີ້ເປັນລະບົບທີ 16:

16 = 6*16^0+1*16^1 = 6+16 = 22

ນັ້ນແມ່ນ, vni ກົງກັບຄວາມເປັນຈິງ.

ເສັ້ນທີສອງສະແດງໃຫ້ເຫັນການຈະລາຈອນກັບຄືນ, ດີ, ບໍ່ມີຈຸດໃດທີ່ຈະອະທິບາຍມັນ, ທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງຢູ່ທີ່ນັ້ນ.

ສອງເຄື່ອງຢູ່ໃນເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ (ການກໍານົດເສັ້ນທາງລະຫວ່າງເຄືອຂ່າຍ)

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

ທໍາອິດ, ໃຫ້ເບິ່ງວ່າ routing ເຮັດວຽກ:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

ເນື່ອງຈາກວ່າໃນກໍລະນີນີ້ແພັກເກັດຕ້ອງໄປຫາປະຕູແລະຖືກສົ່ງໄປທີ່ນັ້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາທີ່ຢູ່ poppy ຂອງປະຕູ, ເຊິ່ງພວກເຮົາເບິ່ງຕາຕະລາງ ARP ໃນຕົວຢ່າງ:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

ຕອນນີ້ໃຫ້ເບິ່ງບ່ອນທີ່ການຈະລາຈອນກັບປາຍທາງ (10.0.1.254) fa:16:3e:c4:64:70 ຄວນຖືກສົ່ງໄປ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ຂໍໃຫ້ເບິ່ງບ່ອນທີ່ພອດ 2 ນໍາ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

ທຸກສິ່ງທຸກຢ່າງແມ່ນມີເຫດຜົນ, ການຈະລາຈອນໄປຫາ br-tun. ມາເບິ່ງວ່າອຸໂມງ vxlan ໃດຈະຖືກຫໍ່ຢູ່ໃນ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

ທ່າເຮືອທີສາມແມ່ນອຸໂມງ vxlan:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

ເຊິ່ງເບິ່ງຢູ່ໃນໂຫນດຄວບຄຸມ:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ການຈະລາຈອນໄດ້ມາຮອດ node ຄວບຄຸມ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງໄປຫາມັນແລະເບິ່ງວ່າເສັ້ນທາງຈະເກີດຂຶ້ນແນວໃດ.

ຕາມທີ່ທ່ານຈື່, ໂຫນດຄວບຄຸມພາຍໃນເບິ່ງຄືກັນກັບໂຫນດຄອມພິວເຕີ້ - ຂົວສາມອັນດຽວກັນ, ພຽງແຕ່ br-ex ມີພອດທາງດ້ານຮ່າງກາຍທີ່ຜ່ານທີ່ node ສາມາດສົ່ງການຈະລາຈອນອອກໄປນອກ. ການສ້າງ instances ໄດ້ປ່ຽນການຕັ້ງຄ່າໃນ nodes ຄອມພິວເຕີ - linux bridge, iptables ແລະ interfaces ໄດ້ຖືກເພີ່ມເຂົ້າໃນ nodes. ການສ້າງເຄືອຂ່າຍແລະ router virtual ຍັງປະໄວ້ເຄື່ອງຫມາຍຂອງຕົນກ່ຽວກັບການຕັ້ງຄ່າຂອງ node ການຄວບຄຸມ.

ດັ່ງນັ້ນ, ມັນເປັນທີ່ຊັດເຈນວ່າ gateway MAC address ຈະຕ້ອງຢູ່ໃນຕາຕະລາງການສົ່ງຕໍ່ br-int ໃນໂຫມດຄວບຄຸມ. ໃຫ້ກວດເບິ່ງວ່າມັນຢູ່ທີ່ນັ້ນແລະມັນກໍາລັງຊອກຫາຢູ່ໃສ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac ແມ່ນເຫັນໄດ້ຈາກພອດ qr-0c52b15f-8f. ຖ້າພວກເຮົາກັບຄືນໄປຫາບັນຊີລາຍຊື່ຂອງພອດ virtual ໃນ Openstack, ປະເພດຂອງພອດນີ້ຖືກນໍາໃຊ້ເພື່ອເຊື່ອມຕໍ່ອຸປະກອນ virtual ຕ່າງໆກັບ OVS. ເພື່ອໃຫ້ມີຄວາມຊັດເຈນຫຼາຍຂຶ້ນ, qr ແມ່ນພອດໄປຫາ router virtual, ເຊິ່ງສະແດງເປັນ namespace.

ໃຫ້ເບິ່ງວ່າ namespaces ແມ່ນຫຍັງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ເປັນສາມສະບັບ. ແຕ່ການຕັດສິນໂດຍຊື່, ທ່ານສາມາດເດົາຈຸດປະສົງຂອງແຕ່ລະຄົນ. ພວກເຮົາຈະກັບຄືນໄປຫາຕົວຢ່າງທີ່ມີ ID 0 ແລະ 1 ຕໍ່ມາ, ຕອນນີ້ພວກເຮົາມີຄວາມສົນໃຈໃນ namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

namespace ນີ້ມີສອງອັນພາຍໃນທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້. ທັງສອງພອດ virtual ໄດ້ຖືກເພີ່ມເຂົ້າໃນ br-int. ໃຫ້ກວດເບິ່ງທີ່ຢູ່ mac ຂອງພອດ qr-0c52b15f-8f, ນັບຕັ້ງແຕ່ການຈະລາຈອນ, ຕັດສິນໂດຍທີ່ຢູ່ mac ປາຍທາງ, ໄດ້ໄປຫາການໂຕ້ຕອບນີ້.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

ນັ້ນແມ່ນ, ໃນກໍລະນີນີ້, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຕາມກົດຫມາຍຂອງເສັ້ນທາງມາດຕະຖານ. ເນື່ອງຈາກການຈະລາຈອນແມ່ນ destined ສໍາລັບເຈົ້າພາບ 10.0.2.8, ມັນຕ້ອງອອກຈາກການໂຕ້ຕອບທີສອງ qr-92fa49b5-54 ແລະຜ່ານອຸໂມງ vxlan ໄປຫາໂຫນດຄອມພິວເຕີ້:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

ທຸກສິ່ງທຸກຢ່າງແມ່ນມີເຫດຜົນ, ບໍ່ມີຄວາມແປກໃຈ. ລອງເບິ່ງບ່ອນທີ່ທີ່ຢູ່ poppy ຂອງ host 10.0.2.8 ເຫັນໄດ້ໃນ br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

ດັ່ງທີ່ຄາດໄວ້, ການຈະລາຈອນໄປເຖິງ br-tun, ໃຫ້ເບິ່ງວ່າອຸໂມງໃດທີ່ການຈະລາຈອນໄປຕໍ່ໄປ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ການຈະລາຈອນເຂົ້າໄປໃນອຸໂມງເພື່ອ compute-1. ດີ, ໃນ compute-1 ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ - ຈາກ br-tun ຊຸດໄປຫາ br-int ແລະຈາກນັ້ນໄປຫາການໂຕ້ຕອບເຄື່ອງ virtual:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

ໃຫ້ກວດເບິ່ງວ່າອັນນີ້ແມ່ນການໂຕ້ຕອບທີ່ຖືກຕ້ອງແທ້ໆ:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

ຕົວຈິງແລ້ວ, ພວກເຮົາໄດ້ໄປຕະຫຼອດທາງຜ່ານຊຸດ. ຂ້າພະເຈົ້າຄິດວ່າທ່ານສັງເກດເຫັນວ່າການຈະລາຈອນໄດ້ຜ່ານອຸໂມງ vxlan ທີ່ແຕກຕ່າງກັນແລະອອກໄປດ້ວຍ VNIs ທີ່ແຕກຕ່າງກັນ. ຂໍໃຫ້ເບິ່ງວ່າ VNI ເຫຼົ່ານີ້ແມ່ນປະເພດໃດ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະເກັບຂີ້ເຫຍື້ອຢູ່ໃນພອດຄວບຄຸມຂອງໂຫນດແລະໃຫ້ແນ່ໃຈວ່າການຈະລາຈອນໄຫຼຕາມທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.
ດັ່ງນັ້ນ, tunnel to compute-0 ມີຄຳສັ່ງຕໍ່ໄປນີ້=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. ມາແປງ 0x16 ເປັນລະບົບເລກທົດສະນິຍົມ:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

ອຸໂມງເພື່ອ compute-1 ມີ VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. ມາແປງ 0x63 ເປັນລະບົບເລກທົດສະນິຍົມ:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

ແລ້ວ, ຕອນນີ້ໃຫ້ເບິ່ງການຖິ້ມຂີ້ເຫຍື້ອ:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

ແພັກເກັດທຳອິດແມ່ນແພັກເກັດ vxlan ຈາກໂຮສ 192.168.255.19 (compute-0) ໄປເປັນເຈົ້າພາບ 192.168.255.15 (control-1) ກັບ vni 22, ພາຍໃນນັ້ນແພັກເກັດ ICMP ຖືກຫຸ້ມຫໍ່ຈາກໂຮສ 10.0.1.85 ໄປເປັນເຈົ້າພາບ 10.0.2.8. ດັ່ງທີ່ພວກເຮົາຄິດໄລ່ຂ້າງເທິງ, vni ກົງກັບສິ່ງທີ່ພວກເຮົາເຫັນໃນຜົນຜະລິດ.

ແພັກເກັດທີສອງແມ່ນແພັກເກັດ vxlan ຈາກໂຮສ 192.168.255.15 (control-1) ໄປເປັນເຈົ້າພາບ 192.168.255.26 (compute-1) ກັບ vni 99, ພາຍໃນນັ້ນແພັກເກັດ ICMP ຖືກຫຸ້ມຈາກໂຮສ 10.0.1.85 ໄປເປັນເຈົ້າພາບ 10.0.2.8. ດັ່ງທີ່ພວກເຮົາຄິດໄລ່ຂ້າງເທິງ, vni ກົງກັບສິ່ງທີ່ພວກເຮົາເຫັນໃນຜົນຜະລິດ.

ສອງຊຸດຕໍ່ໄປແມ່ນການຈະລາຈອນກັບຄືນຈາກ 10.0.2.8 ບໍ່ແມ່ນ 10.0.1.85.

ນັ້ນແມ່ນ, ໃນທີ່ສຸດພວກເຮົາໄດ້ຮັບຮູບແບບການຄວບຄຸມຕໍ່ໄປນີ້:

ເບິ່ງແບບນັ້ນບໍ? ພວກເຮົາລືມກ່ຽວກັບສອງ namespaces:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ດັ່ງທີ່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງແພລະຕະຟອມຟັງ, ມັນຈະດີຖ້າເຄື່ອງຈັກໄດ້ຮັບທີ່ຢູ່ອັດຕະໂນມັດຈາກເຄື່ອງແມ່ຂ່າຍ DHCP. ເຫຼົ່ານີ້ແມ່ນສອງເຊີບເວີ DHCP ສໍາລັບສອງເຄືອຂ່າຍຂອງພວກເຮົາ 10.0.1.0/24 ແລະ 10.0.2.0/24.

ໃຫ້ກວດເບິ່ງວ່ານີ້ແມ່ນຄວາມຈິງ. ມີພຽງແຕ່ຫນຶ່ງທີ່ຢູ່ໃນ namespace ນີ້ - 10.0.1.1 - ທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍ DHCP ຕົວຂອງມັນເອງ, ແລະມັນຍັງລວມຢູ່ໃນ br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ໃຫ້ເບິ່ງວ່າຂະບວນການທີ່ມີ qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ໃນຊື່ຂອງພວກມັນຢູ່ໃນໂຫນດຄວບຄຸມ:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

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

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບຊຸດການບໍລິການຕໍ່ໄປນີ້ຢູ່ໃນໂຫນດຄວບຄຸມ:

ດີ, ຈົ່ງຈື່ໄວ້ - ນີ້ແມ່ນພຽງແຕ່ 4 ເຄື່ອງ, 2 ເຄືອຂ່າຍພາຍໃນແລະຫນຶ່ງ router virtual ... ພວກເຮົາບໍ່ມີເຄືອຂ່າຍພາຍນອກຢູ່ທີ່ນີ້, ຊໍ່ຂອງໂຄງການທີ່ແຕກຕ່າງກັນ, ແຕ່ລະຄົນມີເຄືອຂ່າຍຂອງຕົນເອງ (ທັບຊ້ອນ), ແລະພວກເຮົາມີ router ທີ່ແຈກຢາຍໄດ້ຖືກປິດ, ແລະໃນທີ່ສຸດ, ຫຼັງຈາກທັງຫມົດ, ມີພຽງແຕ່ຫນຶ່ງ node ຄວບຄຸມຢູ່ໃນ bench ການທົດສອບ (ສໍາລັບການຄວາມທົນທານຄວາມຜິດຈະຕ້ອງມີ quorum ຂອງສາມ nodes). ມັນເປັນເຫດຜົນວ່າໃນການຄ້າທຸກຢ່າງແມ່ນ "ເລັກນ້ອຍ" ສັບສົນຫຼາຍ, ແຕ່ໃນຕົວຢ່າງງ່າຍໆນີ້ພວກເຮົາເຂົ້າໃຈວ່າມັນຄວນຈະເຮັດວຽກແນວໃດ - ແນ່ນອນວ່າທ່ານມີ 3 ຫຼື 300 namespaces ແມ່ນສໍາຄັນ, ແຕ່ຈາກທັດສະນະຂອງການດໍາເນີນງານທັງຫມົດ. ໂຄງສ້າງ, ບໍ່ມີຫຍັງຈະປ່ຽນແປງຫຼາຍ ... ເຖິງແມ່ນວ່າທ່ານຈະບໍ່ສຽບໃນບາງຜູ້ຂາຍ SDN. ແຕ່ນັ້ນແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນຫມົດ.

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

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

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

ຂ້ອຍບໍ່ໄດ້ສົ່ງເສີມຜະລິດຕະພັນທໍາອິດຫຼືທີສອງ - ເຈົ້າເລືອກສິ່ງທີ່ທ່ານຕ້ອງການ. ແຕ່ຖ້າຂ້ອຍມີທາງເລືອກດັ່ງກ່າວ, ຂ້ອຍຈະເລືອກທັງສອງວິທີແກ້ໄຂ - VMWare ສໍາລັບ IT cloud (ການໂຫຼດຕ່ໍາ, ການຈັດການງ່າຍ), OpenStack ຈາກບາງຜູ້ຂາຍ (Nokia ແລະ Juniper ສະຫນອງການແກ້ໄຂ turnkey ທີ່ດີຫຼາຍ) - ສໍາລັບ Telecom cloud. ຂ້ອຍຈະບໍ່ໃຊ້ Openstack ສໍາລັບ IT ບໍລິສຸດ - ມັນຄ້າຍຄືກັບການຍິງນົກກະຈອກເທດດ້ວຍປືນໃຫຍ່, ແຕ່ຂ້ອຍບໍ່ເຫັນຂໍ້ຫ້າມໃດໆທີ່ຈະໃຊ້ມັນນອກ ເໜືອ ຈາກການໃຊ້ຊ້ໍາຊ້ອນ. ຢ່າງໃດກໍ່ຕາມ, ການໃຊ້ VMWare ໃນໂທລະຄົມແມ່ນຄ້າຍຄືກັບການດຶງຫີນທີ່ແຕກຢູ່ໃນລົດ Ford Raptor - ມັນງາມຈາກພາຍນອກ, ແຕ່ຜູ້ຂັບຂີ່ຕ້ອງເຮັດ 10 ການເດີນທາງແທນທີ່ຈະເປັນຫນຶ່ງ.

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຂໍ້ເສຍທີ່ໃຫຍ່ທີ່ສຸດຂອງ VMWare ແມ່ນການປິດທີ່ສົມບູນຂອງມັນ - ບໍລິສັດຈະບໍ່ໃຫ້ຂໍ້ມູນໃດໆກ່ຽວກັບວິທີເຮັດວຽກ, ຕົວຢ່າງ, vSAN ຫຼືສິ່ງທີ່ຢູ່ໃນ hypervisor kernel - ມັນພຽງແຕ່ບໍ່ມີກໍາໄລສໍາລັບມັນ - ນັ້ນແມ່ນ, ທ່ານຈະ. ບໍ່ເຄີຍກາຍເປັນຜູ້ຊ່ຽວຊານໃນ VMWare - ໂດຍບໍ່ມີການສະຫນັບສະຫນູນຈາກຜູ້ຂາຍ, ເຈົ້າຖືກ doomed (ເລື້ອຍໆຂ້ອຍພົບກັບຜູ້ຊ່ຽວຊານ VMWare ທີ່ສັບສົນກັບຄໍາຖາມນ້ອຍໆ). ສໍາລັບຂ້ອຍ, VMWare ກໍາລັງຊື້ລົດທີ່ມີ hood lock - ແມ່ນແລ້ວ, ທ່ານອາດຈະມີຜູ້ຊ່ຽວຊານທີ່ສາມາດປ່ຽນສາຍແອວກໍານົດເວລາ, ແຕ່ວ່າພຽງແຕ່ຜູ້ທີ່ຂາຍໃຫ້ທ່ານແກ້ໄຂບັນຫານີ້ສາມາດເປີດ hood ໄດ້. ສ່ວນບຸກຄົນ, ຂ້ອຍບໍ່ມັກວິທີແກ້ໄຂທີ່ຂ້ອຍບໍ່ສາມາດເຂົ້າກັນໄດ້. ເຈົ້າຈະເວົ້າວ່າເຈົ້າອາດຈະບໍ່ຕ້ອງໄປພາຍໃຕ້ຜ້າຄຸມ. ແມ່ນແລ້ວ, ນີ້ແມ່ນເປັນໄປໄດ້, ແຕ່ຂ້ອຍຈະເບິ່ງເຈົ້າເມື່ອເຈົ້າຕ້ອງການປະກອບຫນ້າທີ່ຂະຫນາດໃຫຍ່ຢູ່ໃນຄລາວຈາກ 20-30 ເຄື່ອງ virtual, 40-50 ເຄືອຂ່າຍ, ເຄິ່ງຫນຶ່ງຂອງທີ່ຕ້ອງການອອກໄປຂ້າງນອກ, ແລະເຄິ່ງທີ່ສອງຂໍ. ການເລັ່ງ SR-IOV, ຖ້າບໍ່ດັ່ງນັ້ນທ່ານຈະຕ້ອງການລົດຫຼາຍສິບຄັນ - ຖ້າບໍ່ດັ່ງນັ້ນ, ການປະຕິບັດຈະບໍ່ພຽງພໍ.

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

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