Load Balancing ໃນ Openstack

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

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

ທໍາອິດ, ໃຫ້ເບິ່ງຂໍ້ກໍານົດແລະຄໍານິຍາມ.

ຂໍ້ກໍານົດແລະຄໍານິຍາມ

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

ການປະຕິບັດ ເປັນວຽກພື້ນຖານທີ່ປ່ຽນແປງສະຖານະປັດຈຸບັນຂອງຊັບພະຍາກອນທີ່ຖືກຄຸ້ມຄອງເປົ້າໝາຍຂອງກຸ່ມ OpenStack ເຊັ່ນ: ການເຄື່ອນຍ້າຍເຄື່ອງ virtual (ການຍ້າຍຖິ່ນຖານ), ການປ່ຽນສະຖານະພະລັງງານຂອງ node (change_node_power_state), ການປ່ຽນສະຖານະຂອງບໍລິການ nova (change_nova_service_state). ), ການປ່ຽນແປງລົດຊາດ (ປັບຂະຫນາດ), ລົງທະບຽນຂໍ້ຄວາມ NOP (nop), ການຂາດການປະຕິບັດສໍາລັບໄລຍະເວລາທີ່ແນ່ນອນ - ພັກໄວ້ (ນອນ), ການໂອນແຜ່ນ (volume_migrate).

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

ການກວດສອບ ແມ່ນການຮ້ອງຂໍເພື່ອເພີ່ມປະສິດທິພາບຂອງກຸ່ມ. ການເພີ່ມປະສິດທິພາບແມ່ນປະຕິບັດເພື່ອບັນລຸເປົ້າໝາຍອັນໜຶ່ງໃນກຸ່ມທີ່ໃຫ້ໄວ້. ສໍາລັບແຕ່ລະການກວດສອບທີ່ປະສົບຜົນສໍາເລັດ, Watcher ສ້າງແຜນປະຕິບັດງານ.

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

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

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

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

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

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

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

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

ເປົ້າໝາຍ ແລະຍຸດທະສາດຂອງຜູ້ເບິ່ງ

ເປົ້າຫມາຍ
ຍຸດທະສາດ

ເປົ້າຫມາຍ dummy
ຍຸດທະສາດ dummy 

ຍຸດທະສາດ Dummy ໂດຍໃຊ້ເຄື່ອງຈັກໃຫ້ຄະແນນຕົວຢ່າງ

ຍຸດທະສາດ dummy ກັບປັບຂະຫນາດ

ປະຫຍັດພະລັງງານ
ຍຸດທະສາດການປະຫຍັດພະລັງງານ

ການລວມເຊີບເວີ
ການລວມເຊີບເວີອອບໄລນ໌ພື້ນຖານ

ຍຸດທະສາດການລວມວຽກ VM

ການດຸ່ນດ່ຽງວຽກ
ຍຸດທະສາດການເຄື່ອນຍ້າຍຄວາມດຸ່ນດ່ຽງວຽກ

ຍຸດທະສາດການດຸ່ນດ່ຽງຄວາມອາດສາມາດເກັບຮັກສາ

ສະຖຽນລະພາບການໂຫຼດ

Noisy Neighbor
Noisy Neighbor

ການເພີ່ມປະສິດທິພາບຄວາມຮ້ອນ
ຍຸດທະສາດການອີງໃສ່ອຸນຫະພູມຂອງ Outlet

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

ການຮັກສາຮາດແວ
ການເຄື່ອນຍ້າຍເຂດ

ບໍ່ເປັນຄວາມລັບ
ຜູ້ປະຕິບັດຕົວຈິງ

ເປົ້າຫມາຍ dummy — ເປົ້າ​ຫມາຍ​ສະ​ຫງວນ​ທີ່​ຖືກ​ນໍາ​ໃຊ້​ສໍາ​ລັບ​ຈຸດ​ປະ​ສົງ​ການ​ທົດ​ສອບ​.

ຍຸດທະສາດທີ່ກ່ຽວຂ້ອງ: Dummy Strategy, Dummy Strategy ໂດຍໃຊ້ຕົວຢ່າງ Scoring Engines ແລະ Dummy Strategy ດ້ວຍການປັບຂະໜາດ. ຍຸດທະສາດ Dummy ແມ່ນຍຸດທະສາດ dummy ທີ່ໃຊ້ສໍາລັບການທົດສອບການເຊື່ອມໂຍງຜ່ານ Tempest. ຍຸດທະສາດນີ້ບໍ່ໄດ້ສະຫນອງການເພີ່ມປະສິດທິພາບທີ່ເປັນປະໂຫຍດ, ຈຸດປະສົງດຽວຂອງມັນແມ່ນການນໍາໃຊ້ການທົດສອບ Tempest.

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

ຍຸດທະສາດ dummy ກັບ resize - ຍຸດທະສາດແມ່ນຄ້າຍຄືກັນກັບທີ່ຜ່ານມາ, ຄວາມແຕກຕ່າງພຽງແຕ່ແມ່ນການນໍາໃຊ້ການປ່ຽນແປງລົດຊາດ (ການເຄື່ອນຍ້າຍແລະປັບຂະຫນາດ).

ບໍ່ໄດ້ໃຊ້ໃນການຜະລິດ.

ປະຫຍັດພະລັງງານ - ຫຼຸດຜ່ອນການບໍລິໂພກພະລັງງານ. ຍຸດທະສາດການປະຢັດພະລັງງານຂອງເປົ້າໝາຍນີ້, ຮ່ວມກັບຍຸດທະສາດການລວມວຽກຂອງ VM (ການລວມເຊີບເວີ), ມີຄວາມສາມາດໃນການຈັດການພະລັງງານແບບເຄື່ອນໄຫວ (DPM) ຄຸນສົມບັດທີ່ປະຫຍັດພະລັງງານໂດຍການລວມວຽກແບບໄດນາມິກເຖິງແມ່ນວ່າໃນໄລຍະເວລາຂອງການນໍາໃຊ້ຊັບພະຍາກອນທີ່ຕໍ່າ: ເຄື່ອງຈັກ virtual ໄດ້ຖືກຍ້າຍໄປຢູ່ໃນຂໍ້ຫນ້ອຍລົງ. , ແລະ nodes ທີ່ບໍ່ຈໍາເປັນຖືກປິດໃຊ້ງານ. ຫຼັງຈາກການລວມຕົວ, ຍຸດທະສາດສະເຫນີການຕັດສິນໃຈກ່ຽວກັບການເປີດ / ປິດ nodes ໂດຍສອດຄ່ອງກັບພາລາມິເຕີທີ່ລະບຸໄວ້: "min_free_hosts_num" - ຈໍານວນຂອງ nodes ທີ່ເປີດໃຫ້ໃຊ້ງານຟຣີທີ່ລໍຖ້າການໂຫຼດ, ແລະ "free_used_percent" - ເປີເຊັນຂອງໂຮດທີ່ເປີດໃຫ້ໃຊ້ຟຣີກັບ ຈໍານວນຂອງ nodes ທີ່ຖືກຄອບຄອງໂດຍເຄື່ອງຈັກ. ສໍາລັບຍຸດທະສາດທີ່ຈະເຮັດວຽກຕ້ອງມີ ເປີດໃຊ້ ແລະກຳນົດຄ່າ Ironic ເພື່ອຈັດການຮອບວຽນພະລັງງານຢູ່ໃນໂນດ.

ຕົວກໍານົດການຍຸດທະສາດ

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

free_used_percent
ຈໍານວນ
10.0
ອັດ​ຕາ​ສ່ວນ​ຂອງ​ຈໍາ​ນວນ​ຂອງ nodes ຄອມ​ພິວ​ເຕີ​ຟຣີ​ກັບ​ຈໍາ​ນວນ​ຂອງ nodes ຄອມ​ພິວ​ເຕີ​ກັບ virtual machines​

min_free_hosts_num
Int
1
ຈໍານວນຕ່ໍາສຸດຂອງ nodes ຄອມພິວເຕີຟຣີ

ຄລາວຕ້ອງມີຢ່າງຫນ້ອຍສອງ nodes. ວິທີການທີ່ໃຊ້ແມ່ນການປ່ຽນແປງສະຖານະພະລັງງານຂອງ node (change_node_power_state). ຍຸດທະສາດບໍ່ຮຽກຮ້ອງໃຫ້ມີການເກັບກໍາ metrics.

Server Consolidation - ຫຼຸດຈໍານວນໂຫມດຄອມພິວເຕີໜ້ອຍທີ່ສຸດ (ການລວມຕົວ). ມັນມີສອງຍຸດທະສາດ: Basic Offline Server Consolidation ແລະ VM Workload Consolidation Strategy.

ຍຸດທະສາດການລວມເຊີບເວີອອບໄລນ໌ພື້ນຖານຈະຫຼຸດຈໍານວນເຊີບເວີທັງໝົດທີ່ໃຊ້ ແລະຍັງຫຼຸດຈໍານວນການເຄື່ອນຍ້າຍ.

ຍຸດທະສາດພື້ນຖານຮຽກຮ້ອງໃຫ້ມີການວັດແທກດັ່ງຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

compute.node.cpu.percent
Ceilometer
none
 

cpu_util
Ceilometer
none
 

ຕົວກໍານົດການຍຸດທະສາດ: migration_attempts - ຈໍານວນການລວມກັນເພື່ອຄົ້ນຫາຜູ້ສະຫມັກທີ່ມີທ່າແຮງສໍາລັບການປິດ (ຄ່າເລີ່ມຕົ້ນ, 0, ບໍ່ມີຂໍ້ຈໍາກັດ), ໄລຍະເວລາ - ໄລຍະເວລາເປັນວິນາທີເພື່ອໃຫ້ໄດ້ລວບລວມຂໍ້ມູນແບບຄົງທີ່ຈາກແຫຼ່ງຂໍ້ມູນ metric (ຄ່າເລີ່ມຕົ້ນ, 700).

ວິທີການທີ່ໃຊ້: ການເຄື່ອນຍ້າຍ, ການປ່ຽນແປງສະຖານະບໍລິການ nova (change_nova_service_state).

ຍຸດທະສາດການລວມວຽກ VM ແມ່ນອີງໃສ່ heuristic ທີ່ເຫມາະສົມທໍາອິດທີ່ສຸມໃສ່ການໂຫຼດ CPU ທີ່ວັດແທກແລະພະຍາຍາມຫຼຸດຜ່ອນ nodes ທີ່ມີການໂຫຼດຫຼາຍເກີນໄປຫຼືຫນ້ອຍເກີນໄປເນື່ອງຈາກຂໍ້ຈໍາກັດຄວາມສາມາດຂອງຊັບພະຍາກອນ. ຍຸດທະສາດນີ້ສະໜອງການແກ້ໄຂທີ່ສົ່ງຜົນໃຫ້ມີການນຳໃຊ້ຊັບພະຍາກອນກຸ່ມຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນໂດຍນຳໃຊ້ສີ່ຂັ້ນຕອນຕໍ່ໄປນີ້:

1. ໄລຍະການໂຫຼດ - ການປຸງແຕ່ງຊັບພະຍາກອນທີ່ໃຊ້ເກີນຂອບເຂດ;
2. ໄລຍະລວມ - ການຈັດການຊັບພະຍາກອນທີ່ບໍ່ໄດ້ນໍາໃຊ້;
3. ການເພີ່ມປະສິດທິພາບຂອງການແກ້ໄຂ - ການຫຼຸດຜ່ອນຈໍານວນການເຄື່ອນຍ້າຍ;
4. ການປິດການນຳໃຊ້ໂນດຄອມພິວເຕີທີ່ບໍ່ໄດ້ໃຊ້.

ຍຸດທະສາດຮຽກຮ້ອງໃຫ້ມີການວັດແທກດັ່ງຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

ຫນ່ວຍຄວາມຈໍາ
Ceilometer
none
 

disk.root.size
Ceilometer
none
 

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

metrics
ການບໍລິການ
ປລັກອິນ
commentary

memory.resident
Ceilometer
none
 

cpu_util
Ceilometer
none
 

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

ໃຊ້ວິທີການດຽວກັນກັບຍຸດທະສາດທີ່ຜ່ານມາ. ລາຍ​ລະ​ອຽດ​ເພີ່ມ​ເຕີມ ທີ່ນີ້.

ການດຸ່ນດ່ຽງວຽກ — ດຸ່ນ​ດ່ຽງ​ການ​ເຮັດ​ວຽກ​ລະ​ຫວ່າງ nodes ຄອມ​ພິວ​ເຕີ​. ເປົ້າຫມາຍດັ່ງກ່າວມີສາມຍຸດທະສາດ: ຍຸດທະສາດການດຸ່ນດ່ຽງການເຮັດວຽກ, ສະຖຽນລະພາບຂອງການເຮັດວຽກ, ຍຸດທະສາດການດຸ່ນດ່ຽງຄວາມສາມາດໃນການເກັບຮັກສາ.

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

ຄວາມຕ້ອງການ

• ການນໍາໃຊ້ໂປເຊດເຊີທາງດ້ານຮ່າງກາຍ;
• ຢ່າງຫນ້ອຍສອງໂຫນດຄອມພິວເຕີ້ທາງດ້ານຮ່າງກາຍ;
• ຕິດຕັ້ງແລະຕັ້ງຄ່າອົງປະກອບ Ceilometer - ceilometer-agent-compute, ແລ່ນຢູ່ໃນແຕ່ລະ node ຄອມພິວເຕີ້, ແລະ Ceilometer API, ເຊັ່ນດຽວກັນກັບການລວບລວມການວັດແທກຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

cpu_util
Ceilometer
none
 

memory.resident
Ceilometer
none
 

ຕົວກໍານົດການຍຸດທະສາດ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

ການວັດແທກ
string
'cpu_util'
ການວັດແທກພື້ນຖານແມ່ນ: 'cpu_util', 'memory.resident'.

threshold
ຈໍານວນ
25.0
ເກນວຽກສຳລັບການເຄື່ອນຍ້າຍ.

ໄລຍະເວລາ
ຈໍານວນ
300
ໄລຍະເວລາສະສົມ Ceilometer.

ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍ.

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

ຄວາມຕ້ອງການ

• ການນໍາໃຊ້ໂປເຊດເຊີທາງດ້ານຮ່າງກາຍ;
• ຢ່າງຫນ້ອຍສອງໂຫນດຄອມພິວເຕີ້ທາງດ້ານຮ່າງກາຍ;
• ຕິດຕັ້ງແລະຕັ້ງຄ່າອົງປະກອບ Ceilometer - ceilometer-agent-compute, ແລ່ນຢູ່ໃນແຕ່ລະ node ຄອມພິວເຕີ້, ແລະ Ceilometer API, ເຊັ່ນດຽວກັນກັບການລວບລວມການວັດແທກຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

cpu_util
Ceilometer
none
 

memory.resident
Ceilometer
none
 

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

ຂໍ້ກໍານົດແລະຂໍ້ຈໍາກັດ

• ຢ່າງຫນ້ອຍສອງສະນຸກເກີ Cinder;
• ຄວາມເປັນໄປໄດ້ຂອງການເຄື່ອນຍ້າຍແຜ່ນ.
• ຕົວແບບຂໍ້ມູນກຸ່ມ - ຕົວເກັບຂໍ້ມູນແບບຈໍາລອງຂອງກຸ່ມ Cinder.

ຕົວກໍານົດການຍຸດທະສາດ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

volume_threshold
ຈໍານວນ
80.0
ຄ່າເກນຂອງແຜ່ນສຳລັບການດຸ່ນດ່ຽງປະລິມານ.

ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍແຜ່ນ (volume_migrate).

Noisy Neighbor - ກໍານົດແລະການເຄື່ອນຍ້າຍ "ບ້ານໃກ້ເຮືອນຄຽງທີ່ມີສຽງດັງ" - ເຄື່ອງ virtual ບູລິມະສິດຕ່ໍາທີ່ມີຜົນກະທົບທາງລົບຕໍ່ການປະຕິບັດງານຂອງເຄື່ອງ virtual ບູລິມະສິດສູງໃນເງື່ອນໄຂຂອງ IPC ໂດຍການໃຊ້ Last Level Cache ຫຼາຍເກີນໄປ. ຍຸດທະສາດຂອງຕົນເອງ: Noisy Neighbor (ພາລາມິເຕີຍຸດທະສາດທີ່ໃຊ້ແມ່ນ cache_threshold (ຄ່າເລີ່ມຕົ້ນແມ່ນ 35), ເມື່ອການປະຕິບັດຫຼຸດລົງເຖິງຄ່າທີ່ລະບຸ, ການເຄື່ອນຍ້າຍແມ່ນເລີ່ມຕົ້ນ. ສໍາລັບຍຸດທະສາດທີ່ຈະເຮັດວຽກ, ເປີດໃຊ້ງານ. LLC (Last Level Cache) metrics, ເຊີບເວີ Intel ຫຼ້າສຸດທີ່ມີການຮອງຮັບ CMT, ເຊັ່ນດຽວກັນກັບການເກັບກໍາ metrics ດັ່ງຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

cpu_l3_cache
Ceilometer
none
Intel ຕ້ອງການ CMT.

ຕົວແບບຂໍ້ມູນກຸ່ມ (ຄ່າເລີ່ມຕົ້ນ): ຕົວເກັບຂໍ້ມູນແບບຈໍາລອງ Nova cluster. ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍ.

ການເຮັດວຽກກັບເປົ້າຫມາຍນີ້ຜ່ານ Dashboard ບໍ່ໄດ້ຖືກປະຕິບັດຢ່າງເຕັມສ່ວນໃນ Queens.

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

ສໍາລັບຍຸດທະສາດທີ່ຈະເຮັດວຽກ, ທ່ານຕ້ອງການເຄື່ອງແມ່ຂ່າຍທີ່ມີ Intel Power Node Manager ຕິດຕັ້ງແລະກໍາຫນົດຄ່າ 3.0 ຫຼືຫຼັງຈາກນັ້ນ, ເຊັ່ນດຽວກັນກັບການເກັບກໍາ metrics ດັ່ງຕໍ່ໄປນີ້:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

hardware.ipmi.node.outlet_temperature
Ceilometer
IPMI
 

ຕົວກໍານົດການຍຸດທະສາດ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

threshold
ຈໍານວນ
35.0
ເກນອຸນຫະພູມສຳລັບການເຄື່ອນຍ້າຍ.

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

ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍ.

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

ສໍາລັບຍຸດທະສາດທີ່ຈະເຮັດວຽກ, ທ່ານຕ້ອງການ:

• ຮາດແວ: ໂນດຄອມພິວເຕີ < ຮອງຮັບ NodeManager 3.0;
• ຢ່າງຫນ້ອຍສອງ nodes ຄອມພິວເຕີ;
• ອົງປະກອບ ceilometer-agent-compute ແລະ Ceilometer API ຕິດຕັ້ງແລະຕັ້ງຄ່າຢູ່ໃນແຕ່ລະ node ຄອມພິວເຕີ, ເຊິ່ງສົບຜົນສໍາເລັດສາມາດລາຍງານ metrics ເຊັ່ນ: ການໄຫຼຂອງອາກາດ, ພະລັງງານຂອງລະບົບ, ອຸນຫະພູມ inlet:

metrics
ການບໍລິການ
ປລັກອິນ
commentary

hardware.ipmi.node.airflow
Ceilometer
IPMI
 

hardware.ipmi.node.temperature
Ceilometer
IPMI
 

hardware.ipmi.node.power
Ceilometer
IPMI
 

ສໍາລັບຍຸດທະສາດທີ່ຈະເຮັດວຽກ, ທ່ານຕ້ອງການເຄື່ອງແມ່ຂ່າຍທີ່ມີ Intel Power Node Manager 3.0 ຫຼືຫຼັງຈາກນັ້ນໄດ້ຕິດຕັ້ງແລະກໍາຫນົດຄ່າ.

ຂໍ້ຈໍາກັດ: ແນວຄວາມຄິດບໍ່ໄດ້ມີຈຸດປະສົງໃນການຜະລິດ.

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

ການເຄື່ອນຍ້າຍແບບສົດໆເປັນໄປໄດ້.

ຕົວກໍານົດການຍຸດທະສາດ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

threshold_airflow
ຈໍານວນ
400.0
ເກນກະແສລົມສຳລັບໜ່ວຍເຄື່ອນຍ້າຍແມ່ນ 0.1CFM

threshold_inlet_t
ຈໍານວນ
28.0
ເກນອຸນຫະພູມຂາເຂົ້າສຳລັບການຕັດສິນໃຈການເຄື່ອນຍ້າຍ

threshold_power
ຈໍານວນ
350.0
ເກນພະລັງງານຂອງລະບົບສຳລັບການຕັດສິນໃຈການເຄື່ອນຍ້າຍ

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

ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍ.

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

ຂໍ້ຈໍາກັດ: ນ້ໍາຫນັກການປະຕິບັດແລະການຂະຫນານຕ້ອງໄດ້ຮັບການກໍາຫນົດຄ່າ.

ຕົວກໍານົດການຍຸດທະສາດ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

compute_nodes
array
ບໍ່ມີ
ໂນດຄອມພິວເຕີສຳລັບການເຄື່ອນຍ້າຍ.

storage_pools
array
ບໍ່ມີ
nodes ການເກັບຮັກສາສໍາລັບການຍົກຍ້າຍ.

parallel_total
integer
6
ຈໍານວນທັງຫມົດຂອງກິດຈະກໍາທີ່ຕ້ອງໄດ້ຮັບການປະຕິບັດໃນຂະຫນານ.

parallel_per_node
integer
2
ຈໍາ​ນວນ​ຂອງ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ຂະ​ຫນານ​ສໍາ​ລັບ​ແຕ່​ລະ​ຂໍ້​ມູນ​ຂອງ​ຄອມ​ພິວ​ເຕີ​.

parallel_per_pool
integer
2
ຈໍານວນຂອງການດໍາເນີນການຂະຫນານສໍາລັບແຕ່ລະສະນຸກເກີການເກັບຮັກສາ.

ບູລິມະສິດ
ຈຸດ​ປະ​ສົງ
ບໍ່ມີ
ບັນຊີລາຍຊື່ບູລິມະສິດສໍາລັບເຄື່ອງ virtual ແລະແຜ່ນ.

with_attached_volume
ປຸ້ຍ
ທີ່ບໍ່ຖືກຕ້ອງ
ບໍ່ຖືກຕ້ອງ—ເຄື່ອງສະເໝືອນຈະຖືກໂອນຍ້າຍຫຼັງຈາກຍ້າຍແຜ່ນທັງໝົດແລ້ວ. ແທ້​ຈິງ—ເຄື່ອງ​ສະ​ເໝືອນ​ຈະ​ຖືກ​ໂອນ​ຍ້າຍ​ຫຼັງ​ຈາກ​ແຜ່ນ​ທີ່​ເຊື່ອມ​ຕໍ່​ທັງ​ໝົດ​ໄດ້​ຖືກ​ໂອນ​ຍ້າຍ​ແລ້ວ.

ອົງປະກອບຂອງ array ຂອງ nodes ຄອມພິວເຕີ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

src_node
string
ບໍ່ມີ
ໂນດຄອມພິວເຕີທີ່ເຄື່ອງສະເໝືອນກຳລັງຖືກໂອນຍ້າຍ (ຕ້ອງການ).

dst_node
string
ບໍ່ມີ
ຄິດໄລ່ໂນດທີ່ເຄື່ອງ virtual ກໍາລັງເຄື່ອນຍ້າຍ.

ອົງປະກອບ array node ການເກັບຮັກສາ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

src_pool
string
ບໍ່ມີ
ສະນຸກເກີບ່ອນເກັບຂໍ້ມູນທີ່ດິສຖືກໂອນ (ຕ້ອງການ).

dst_pool
string
ບໍ່ມີ
ສະນຸກເກີບ່ອນເກັບຂໍ້ມູນທີ່ດິສຖືກໂອນຍ້າຍ.

src_type
string
ບໍ່ມີ
ປະເພດແຜ່ນຕົ້ນສະບັບ (ຕ້ອງການ).

dst_type
string
ບໍ່ມີ
ປະເພດແຜ່ນຜົນໄດ້ຮັບ (ຕ້ອງການ).

ອົງປະກອບບູລິມະສິດຂອງວັດຖຸ:

ພາລາມິເຕີ
ປະເພດ
ໂດຍຄ່າເລີ່ມຕົ້ນ
ຄໍາອະທິບາຍ

ໂຄງການ
array
ບໍ່ມີ
ຊື່ໂຄງການ.

compute_node
array
ບໍ່ມີ
ຄິດໄລ່ຊື່ node.

storage_pool
array
ບໍ່ມີ
ຊື່ສະລອຍນ້ຳ.

ຄຳ ນວນ
enum
ບໍ່ມີ
ຕົວກໍານົດການຂອງເຄື່ອງ virtual [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

ການເກັບຮັກສາ
enum
ບໍ່ມີ
ຕົວກໍານົດການ Disk ["ຂະຫນາດ", "created_at"].

ວິທີການທີ່ໃຊ້ແມ່ນການເຄື່ອນຍ້າຍເຄື່ອງ virtual, ການເຄື່ອນຍ້າຍແຜ່ນ.

ບໍ່ເປັນຄວາມລັບ - ເປົ້າໝາຍຊ່ວຍໃຊ້ເພື່ອອຳນວຍຄວາມສະດວກໃຫ້ແກ່ຂະບວນການພັດທະນາຍຸດທະສາດ. ບໍ່ມີຂໍ້ມູນສະເພາະ ແລະສາມາດນຳໃຊ້ໄດ້ທຸກຄັ້ງທີ່ຍຸດທະສາດຍັງບໍ່ທັນກ່ຽວຂ້ອງກັບເປົ້າໝາຍທີ່ມີຢູ່ແລ້ວ. ເປົ້າໝາຍນີ້ຍັງສາມາດໃຊ້ເປັນຈຸດປ່ຽນໄດ້. ຍຸດທະສາດທີ່ກ່ຽວຂ້ອງກັບເປົ້າຫມາຍນີ້ແມ່ນ Actuator.   

ການສ້າງເປົ້າຫມາຍໃຫມ່

ເຄື່ອງຈັກການຕັດສິນໃຈຂອງ Watcher ມີ "ເປົ້າຫມາຍພາຍນອກ" ການໂຕ້ຕອບ plugin ທີ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປະສົມປະສານເປົ້າຫມາຍພາຍນອກທີ່ສາມາດບັນລຸໄດ້ໂດຍໃຊ້ຍຸດທະສາດ.

ກ່ອນທີ່ທ່ານຈະສ້າງເປົ້າຫມາຍໃຫມ່, ທ່ານຄວນໃຫ້ແນ່ໃຈວ່າບໍ່ມີເປົ້າຫມາຍທີ່ມີຢູ່ແລ້ວຕອບສະຫນອງຄວາມຕ້ອງການຂອງທ່ານ.

ການສ້າງ plugin ໃຫມ່

ເພື່ອສ້າງເປົ້າຫມາຍໃຫມ່, ທ່ານຕ້ອງ: ຂະຫຍາຍຫ້ອງຮຽນເປົ້າຫມາຍ, ປະຕິບັດວິທີການຫ້ອງຮຽນ get_name() ເພື່ອສົ່ງຄືນ ID ສະເພາະຂອງເປົ້າໝາຍໃໝ່ທີ່ທ່ານຕ້ອງການສ້າງ. ຕົວລະບຸທີ່ເປັນເອກະລັກນີ້ຕ້ອງກົງກັບຊື່ຈຸດເຂົ້າທີ່ທ່ານປະກາດໃນພາຍຫຼັງ.

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

ປະຕິບັດວິທີການຫ້ອງຮຽນ get_translatable_display_name()ເພື່ອສົ່ງຄືນລະຫັດການແປ (ທີ່ຈິງແມ່ນຊື່ສະແດງພາສາອັງກິດ) ຂອງເປົ້າໝາຍໃໝ່ຂອງເຈົ້າ. ຄ່າກັບຄືນຕ້ອງກົງກັບສະຕຣິງທີ່ແປເປັນ get_display_name().

ປະຕິບັດວິທີການຂອງລາວ get_efficacy_specification()ເພື່ອສົ່ງຄືນການກໍານົດປະສິດທິພາບສໍາລັບເປົ້າຫມາຍຂອງທ່ານ. ວິທີການ get_efficacy_specification() ສົ່ງຄືນຕົວຢ່າງ Unclassified() ທີ່ສະໜອງໃຫ້ໂດຍ Watcher. ຂໍ້ກໍາຫນົດການປະຕິບັດນີ້ແມ່ນເປັນປະໂຫຍດໃນຂະບວນການພັດທະນາເປົ້າຫມາຍຂອງທ່ານເພາະວ່າມັນກົງກັບຂໍ້ກໍານົດທີ່ຫວ່າງເປົ່າ.

→ ອ່ານເພີ່ມເຕີມທີ່ນີ້

ສະຖາປັດຕະຍະກໍາ Watcher (ລາຍລະອຽດເພີ່ມເຕີມ) ທີ່ນີ້).

Components

Watcher API - ອົງປະກອບທີ່ປະຕິບັດ REST API ທີ່ສະໜອງໃຫ້ໂດຍ Watcher. ກົນໄກການໂຕ້ຕອບ: CLI, Horizon plugin, Python SDK.

Watcher DB - ຖານ​ຂໍ້​ມູນ Watcher​.

Watcher Applier — ອົງປະກອບທີ່ປະຕິບັດການປະຕິບັດແຜນປະຕິບັດງານທີ່ສ້າງຂຶ້ນໂດຍອົງປະກອບຂອງ Watcher Decision Engine.

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

ຜູ້ເຜີຍແພ່ Watcher Metrics - ອົງປະກອບທີ່ເກັບກໍາແລະຄິດໄລ່ບາງ metrics ຫຼືເຫດການແລະເຜີຍແຜ່ໃຫ້ເຂົາເຈົ້າກັບຈຸດສິ້ນສຸດ CEP. ການເຮັດວຽກຂອງອົງປະກອບຍັງສາມາດສະຫນອງໃຫ້ໂດຍຜູ້ເຜີຍແຜ່ Ceilometer.

Complex Event Processing (CEP) Engine - ເຄື່ອງຈັກໃນການປະມວນຜົນເຫດການທີ່ຊັບຊ້ອນ. ສໍາລັບເຫດຜົນການປະຕິບັດ, ອາດຈະມີຕົວຢ່າງ CEP Engine ຫຼາຍອັນທີ່ເຮັດວຽກພ້ອມກັນ, ແຕ່ລະການປະມວນຜົນປະເພດສະເພາະຂອງ metric / ເຫດການ. ໃນລະບົບ Watcher, CEP ກະຕຸ້ນສອງປະເພດຂອງການປະຕິບັດ: - ບັນທຶກເຫດການ / metrics ທີ່ສອດຄ້ອງກັນໃນຖານຂໍ້ມູນຊຸດເວລາ; - ສົ່ງເຫດການທີ່ເຫມາະສົມກັບ Watcher Decision Engine ເມື່ອເຫດການນີ້ສາມາດສົ່ງຜົນກະທົບຕໍ່ຜົນໄດ້ຮັບຂອງຍຸດທະສາດການເພີ່ມປະສິດທິພາບໃນປະຈຸບັນ, ນັບຕັ້ງແຕ່ກຸ່ມ Openstack ບໍ່ແມ່ນລະບົບຄົງທີ່.

ອົງປະກອບປະຕິສໍາພັນໂດຍໃຊ້ AMQP protocol.

→ ການ​ຕັ້ງ​ຄ່າ Watcher

ຮູບແບບການໂຕ້ຕອບກັບ Watcher

ຜົນ​ການ​ທົດ​ສອບ Watcher​

1. ກ່ຽວກັບການເພີ່ມປະສິດທິພາບ - ແຜນການປະຕິບັດງານ 500 ຫນ້າ (ທັງຢູ່ໃນ Queens ບໍລິສຸດແລະຢູ່ໃນຈຸດຢືນທີ່ມີໂມດູນ Tionix), ມັນປາກົດພຽງແຕ່ຫຼັງຈາກການກວດສອບໄດ້ຖືກເປີດຕົວແລະແຜນການປະຕິບັດໄດ້ຖືກສ້າງຂື້ນ;
2. ມີຂໍ້ຜິດພາດໃນແຖບລາຍລະອຽດການປະຕິບັດ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະໄດ້ຮັບເປົ້າຫມາຍການກວດສອບແລະຍຸດທະສາດ (ທັງຢູ່ໃນ Queens ບໍລິສຸດແລະຢືນຢູ່ກັບໂມດູນ Tionix).
3. ການກວດສອບທີ່ມີຈຸດປະສົງຂອງ Dummy (ການທົດສອບ) ແມ່ນສ້າງແລະເປີດຕົວຕາມປົກກະຕິ, ແຜນການປະຕິບັດງານແມ່ນຖືກສ້າງຂຶ້ນ.
4. ການກວດສອບສໍາລັບເປົ້າຫມາຍທີ່ບໍ່ໄດ້ຈັດປະເພດບໍ່ໄດ້ຖືກສ້າງຂື້ນເພາະວ່າເປົ້າຫມາຍບໍ່ມີປະໂຫຍດແລະມີຈຸດປະສົງສໍາລັບການຕັ້ງຄ່າລະດັບປານກາງໃນເວລາທີ່ສ້າງຍຸດທະສາດໃຫມ່.
5. ການກວດສອບເພື່ອຈຸດປະສົງຂອງການດຸ່ນດ່ຽງວຽກ (ຍຸດທະສາດການດຸ່ນດ່ຽງຄວາມສາມາດໃນການເກັບຮັກສາ) ໄດ້ຖືກສ້າງຂື້ນຢ່າງສໍາເລັດຜົນ, ແຕ່ແຜນການປະຕິບັດບໍ່ໄດ້ຖືກສ້າງຂຶ້ນ. ບໍ່ຈໍາເປັນຕ້ອງມີການເພີ່ມປະສິດທິພາບສະນຸກເກີບ່ອນເກັບຂໍ້ມູນ.
6. ການກວດສອບເປົ້າໝາຍການດຸ່ນດ່ຽງວຽກ (ຍຸດທະສາດການເຄື່ອນຍ້າຍຍອດເງິນຂອງວຽກ) ຖືກສ້າງຂຶ້ນຢ່າງສໍາເລັດຜົນ, ແຕ່ແຜນການປະຕິບັດບໍ່ໄດ້ຖືກສ້າງຂຶ້ນ.
7. ການກວດສອບການດຸ່ນດ່ຽງວຽກ (ຍຸດທະສາດການສະຖຽນລະພາບຂອງວຽກ) ລົ້ມເຫລວ.
8. ການກວດສອບສໍາລັບເປົ້າຫມາຍ Noisy Neighbor ໄດ້ຖືກສ້າງຂື້ນຢ່າງສໍາເລັດຜົນ, ແຕ່ແຜນການປະຕິບັດງານບໍ່ໄດ້ຖືກສ້າງຂຶ້ນ.
9. ການກວດສອບສໍາລັບຈຸດປະສົງຂອງການບໍາລຸງຮັກສາຮາດແວຖືກສ້າງຂື້ນຢ່າງສໍາເລັດຜົນ, ແຜນການປະຕິບັດບໍ່ໄດ້ຖືກສ້າງຂຶ້ນຢ່າງເຕັມທີ່ (ຕົວຊີ້ວັດການປະຕິບັດແມ່ນຖືກສ້າງຂຶ້ນ, ແຕ່ບັນຊີລາຍຊື່ຂອງການກະທໍາຂອງມັນເອງບໍ່ໄດ້ຖືກສ້າງຂຶ້ນ).
10. ການແກ້ໄຂໃນ nova.conf configs (ໃນພາກເລີ່ມຕົ້ນ compute_monitors = cpu.virt_driver) ຢູ່ໃນຄອມພິວເຕີ ແລະໂນດຄວບຄຸມບໍ່ໄດ້ແກ້ໄຂຂໍ້ຜິດພາດ.
11. ການກວດສອບສໍາລັບຈຸດປະສົງການລວມເຄື່ອງແມ່ຂ່າຍ (ຍຸດທະສາດພື້ນຖານ) ຍັງລົ້ມເຫລວ.
12. ການກວດສອບເພື່ອຈຸດປະສົງຂອງ Server Consolidation (ຍຸດທະສາດການລວມວຽກ VM) ລົ້ມເຫລວໂດຍມີຂໍ້ຜິດພາດ. ໃນບັນທຶກມີຄວາມຜິດພາດໃນການໄດ້ຮັບຂໍ້ມູນແຫຼ່ງ. ການສົນທະນາກ່ຽວກັບຄວາມຜິດພາດ, ໂດຍສະເພາະ ທີ່ນີ້.
    ພວກເຮົາໄດ້ພະຍາຍາມລະບຸ Watcher ໃນໄຟລ໌ config (ມັນບໍ່ໄດ້ຊ່ວຍ - ເປັນຜົນມາຈາກຄວາມຜິດພາດໃນຫນ້າ Optimization ທັງຫມົດ, ການກັບຄືນໄປຫາເນື້ອຫາຕົ້ນສະບັບຂອງໄຟລ໌ config ບໍ່ໄດ້ແກ້ໄຂສະຖານະການ):

    [ຍຸດທະສາດ_ຜູ້ເຝົ້າລະວັງ.ພື້ນຖານ]
    ແຫຼ່ງຂໍ້ມູນ = ceilometer, gnocchi

13. ການກວດສອບການປະຢັດພະລັງງານລົ້ມເຫລວ. ການຕັດສິນໂດຍໄມ້ທ່ອນ, ບັນຫາແມ່ນຍັງບໍ່ມີ Ironic;
14. ການກວດສອບສໍາລັບການເພີ່ມປະສິດທິພາບຄວາມຮ້ອນລົ້ມເຫລວ. traceback ແມ່ນຄືກັນກັບ Server Consolidation (ຍຸດທະສາດການລວມວຽກ VM) (ຄວາມຜິດພາດຂອງຂໍ້ມູນແຫຼ່ງ)
15. ການກວດສອບເພື່ອຈຸດປະສົງຂອງການເພີ່ມປະສິດທິພາບ Airflow ລົ້ມເຫລວໂດຍມີຂໍ້ຜິດພາດ.

ຄວາມຜິດພາດການສໍາເລັດການກວດສອບຕໍ່ໄປນີ້ຍັງພົບ. Traceback ໃນບັນທຶກການຕັດສິນໃຈ-engine.log (ສະຖານະຂອງກຸ່ມບໍ່ໄດ້ຖືກກໍານົດ).

→ ການສົນທະນາຂອງຄວາມຜິດພາດ ທີ່ນີ້

ສະຫລຸບ

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

Watcher ໄດ້ພິສູດວ່າເປັນຜະລິດຕະພັນທີ່ຮຸນແຮງແລະພັດທະນາຢ່າງໄວວາທີ່ມີທ່າແຮງອັນໃຫຍ່ຫຼວງ, ການນໍາໃຊ້ຢ່າງເຕັມທີ່ຈະຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກທີ່ຮ້າຍແຮງຫຼາຍ.

ແຕ່ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມຕໍ່ໄປຂອງຊຸດ.

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