ສະຖາປັດຕະຍະກໍາຂອງຕົວດຸ່ນດ່ຽງການໂຫຼດເຄືອຂ່າຍໃນ Yandex.Cloud

ສະບາຍດີ, ຂ້ອຍແມ່ນ Sergey Elantsev, ຂ້ອຍພັດທະນາ ຕົວດຸ່ນດ່ຽງການໂຫຼດເຄືອຂ່າຍ ໃນ Yandex.Cloud. ກ່ອນຫນ້ານີ້, ຂ້າພະເຈົ້າໄດ້ນໍາພາການພັດທະນາ L7 balancer ສໍາລັບ Yandex portal - ເພື່ອນຮ່ວມງານເວົ້າຕະຫລົກວ່າບໍ່ວ່າຂ້ອຍຈະເຮັດຫຍັງກໍ່ຕາມ, ມັນຈະກາຍເປັນຕົວດຸ່ນດ່ຽງ. ຂ້າພະເຈົ້າຈະບອກຜູ້ອ່ານ Habr ວິທີການຈັດການການໂຫຼດໃນເວທີຟັງ, ສິ່ງທີ່ພວກເຮົາເຫັນວ່າເປັນເຄື່ອງມືທີ່ເຫມາະສົມສໍາລັບການບັນລຸເປົ້າຫມາຍນີ້, ແລະວິທີທີ່ພວກເຮົາກໍາລັງກ້າວໄປສູ່ການສ້າງເຄື່ອງມືນີ້.

ກ່ອນອື່ນ, ຂໍແນະນຳບາງຄຳສັບ:

• VIP (Virtual IP) - ທີ່ຢູ່ IP balancer
• ເຊີບເວີ, backend, instance - ເຄື່ອງ virtual ແລ່ນແອັບພລິເຄຊັນ
• RIP (Real IP) - ທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍ
• Healthcheck - ກວດເບິ່ງຄວາມພ້ອມຂອງເຄື່ອງແມ່ຂ່າຍ
• Availability Zone, AZ - ໂຄງສ້າງພື້ນຖານທີ່ໂດດດ່ຽວໃນສູນຂໍ້ມູນ
• ພາກພື້ນ - ສະຫະພັນຂອງ AZs ທີ່ແຕກຕ່າງກັນ

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

ຕົວດຸ່ນດ່ຽງການໂຫຼດມັກຈະຖືກຈັດປະເພດໂດຍຊັ້ນໂປຣໂຕຄໍຈາກຮູບແບບ OSI ທີ່ມັນແລ່ນ. Cloud Balancer ດໍາເນີນການຢູ່ໃນລະດັບ TCP, ເຊິ່ງກົງກັບຊັ້ນທີສີ່, L4.

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

ຍົນຂໍ້ມູນ

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

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

Config ຍົນ

 
ອົງປະກອບທີ່ສໍາຄັນຂອງຍົນ config ແມ່ນ API, ໂດຍຜ່ານການດໍາເນີນງານຂັ້ນພື້ນຖານກັບຜູ້ດຸ່ນດ່ຽງປະຕິບັດ: ການສ້າງ, ລຶບ, ການປ່ຽນແປງອົງປະກອບຂອງຕົວຢ່າງ, ການໄດ້ຮັບຜົນການກວດສອບສຸຂະພາບ, ແລະອື່ນໆ, ໃນອີກດ້ານຫນຶ່ງ, ນີ້ແມ່ນ REST API, ແລະໃນ. ອື່ນໆ, ພວກເຮົາຢູ່ໃນ Cloud ມັກຈະໃຊ້ກອບ gRPC, ດັ່ງນັ້ນພວກເຮົາ "ແປ" REST ກັບ gRPC ແລະຫຼັງຈາກນັ້ນໃຊ້ພຽງແຕ່ gRPC. ການຮ້ອງຂໍໃດໆນໍາໄປສູ່ການສ້າງຊຸດຂອງວຽກງານ idempotent asynchronous ທີ່ຖືກປະຕິບັດຢູ່ໃນກຸ່ມຄົນງານ Yandex.Cloud ທົ່ວໄປ. ໜ້າວຽກຖືກຂຽນໄວ້ໃນແບບທີ່ພວກເຂົາສາມາດຖືກລະງັບໄດ້ທຸກເວລາ ແລະຫຼັງຈາກນັ້ນເລີ່ມຕົ້ນໃໝ່. ນີ້ຮັບປະກັນການຂະຫຍາຍ, ການເຮັດເລື້ມຄືນແລະການບັນທຶກການດໍາເນີນງານ.

ດັ່ງນັ້ນ, ວຽກງານຈາກ API ຈະເຮັດການຮ້ອງຂໍໃຫ້ຜູ້ຄວບຄຸມການບໍລິການ balancer, ເຊິ່ງຂຽນໃນ Go. ມັນ​ສາ​ມາດ​ເພີ່ມ​ແລະ​ເອົາ balancers​, ການ​ປ່ຽນ​ແປງ​ອົງ​ປະ​ກອບ​ຂອງ backends ແລະ​ການ​ຕັ້ງ​ຄ່າ​. 

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

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

ຕົວຄວບຄຸມການກວດສຸຂະພາບ

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

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

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

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

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

ຄວາມແຕກຕ່າງແມ່ນວ່າລູກຄ້າເຮັດການຮ້ອງຂໍຕໍ່ VIP, ໃນຂະນະທີ່ການກວດສອບສຸຂະພາບເຮັດໃຫ້ການຮ້ອງຂໍຕໍ່ RIP ແຕ່ລະຄົນ. ບັນຫາທີ່ຫນ້າສົນໃຈເກີດຂື້ນຢູ່ທີ່ນີ້: ພວກເຮົາໃຫ້ໂອກາດຜູ້ໃຊ້ຂອງພວກເຮົາໃນການສ້າງຊັບພະຍາກອນໃນເຄືອຂ່າຍ IP ສີຂີ້ເຖົ່າ. ຂໍໃຫ້ຈິນຕະນາການວ່າມີເຈົ້າຂອງຄລາວສອງຄົນທີ່ແຕກຕ່າງກັນທີ່ໄດ້ເຊື່ອງການບໍລິການຂອງພວກເຂົາຢູ່ເບື້ອງຫຼັງຜູ້ດຸ່ນດ່ຽງ. ແຕ່ລະພວກມັນມີຊັບພະຍາກອນຢູ່ໃນເຄືອຂ່າຍຍ່ອຍ 10.0.0.1/24, ທີ່ມີທີ່ຢູ່ດຽວກັນ. ທ່ານຈໍາເປັນຕ້ອງສາມາດຈໍາແນກໃຫ້ເຂົາເຈົ້າ somehow, ແລະໃນທີ່ນີ້ທ່ານຕ້ອງການ dive ເຂົ້າໄປໃນໂຄງສ້າງຂອງເຄືອຂ່າຍ virtual Yandex.Cloud. ມັນເປັນທີ່ດີກວ່າທີ່ຈະຊອກຫາລາຍລະອຽດເພີ່ມເຕີມໃນ ວິດີໂອຈາກກ່ຽວກັບ:ເຫດການຄລາວ, ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາໃນປັດຈຸບັນທີ່ເຄືອຂ່າຍມີຫຼາຍຊັ້ນແລະມີອຸໂມງທີ່ສາມາດຈໍາແນກໄດ້ໂດຍ subnet id.

Healthcheck nodes ຕິດຕໍ່ຜູ້ດຸ່ນດ່ຽງໂດຍໃຊ້ອັນທີ່ເອີ້ນວ່າທີ່ຢູ່ quasi-IPv6. ທີ່ຢູ່ quasi-address ແມ່ນທີ່ຢູ່ IPv6 ທີ່ມີທີ່ຢູ່ IPv4 ແລະ id subnet ຂອງຜູ້ໃຊ້ຝັງຢູ່ໃນມັນ. ການຈະລາຈອນໄປຮອດຕົວດຸ່ນດ່ຽງ, ເຊິ່ງສະກັດທີ່ຢູ່ຊັບພະຍາກອນ IPv4 ຈາກມັນ, ແທນ IPv6 ດ້ວຍ IPv4 ແລະສົ່ງແພັກເກັດໄປຫາເຄືອຂ່າຍຂອງຜູ້ໃຊ້.

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

VPP - ຫົວໃຈຂອງຍົນຂໍ້ມູນ

ເຄື່ອງດຸ່ນດ່ຽງຖືກປະຕິບັດໂດຍໃຊ້ເທກໂນໂລຍີ Vector Packet Processing (VPP), ກອບຈາກ Cisco ສໍາລັບການປະມວນຜົນ batch ຂອງການຈະລາຈອນເຄືອຂ່າຍ. ໃນກໍລະນີຂອງພວກເຮົາ, ກອບເຮັດວຽກຢູ່ເທິງຂອງຫ້ອງສະຫມຸດການຄຸ້ມຄອງອຸປະກອນເຄືອຂ່າຍຜູ້ໃຊ້ - Data Plane Development Kit (DPDK). ນີ້ຮັບປະກັນປະສິດທິພາບການປະມວນຜົນແພັກເກັດທີ່ສູງ: ການຂັດຂວາງຫນ້ອຍລົງໃນ kernel, ແລະບໍ່ມີການປ່ຽນສະພາບການລະຫວ່າງພື້ນທີ່ kernel ແລະພື້ນທີ່ຜູ້ໃຊ້. 

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

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

ຍາກໜ້ອຍໜຶ່ງ. ຜູ້ຂຽນຂອງ VPP ບໍ່ທົນທານຕໍ່ການປະນີປະນອມໃນການນໍາໃຊ້ຖານຄວາມຈໍາຂອງໂປເຊດເຊີ, ດັ່ງນັ້ນລະຫັດປົກກະຕິສໍາລັບການປຸງແຕ່ງ vector ຂອງ packets ປະກອບດ້ວຍ vectorization ຄູ່ມື: ມີ loop ການປຸງແຕ່ງທີ່ສະຖານະການເຊັ່ນ: "ພວກເຮົາມີສີ່ຊອງໃນແຖວ" ແມ່ນການປະມວນຜົນ, ຫຼັງຈາກນັ້ນຄືກັນສໍາລັບສອງ, ຫຼັງຈາກນັ້ນ - ສໍາລັບຫນຶ່ງ. ຄໍາ​ແນະ​ນໍາ prefetch ມັກ​ຈະ​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ໂຫຼດ​ຂໍ້​ມູນ​ເຂົ້າ​ໄປ​ໃນ​ຖານ​ຄວາມ​ຈໍາ​ເພື່ອ​ເລັ່ງ​ການ​ເຂົ້າ​ເຖິງ​ພວກ​ເຂົາ​ໃນ​ການ​ຕໍ່​ໄປ​ອີກ​ເທື່ອ​ຫນຶ່ງ​.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ດັ່ງນັ້ນ, Healthchecks ເວົ້າຫຼາຍກວ່າ IPv6 ກັບ VPP, ເຊິ່ງປ່ຽນພວກມັນເປັນ IPv4. ນີ້ແມ່ນເຮັດໂດຍ node ໃນກາຟ, ທີ່ພວກເຮົາເອີ້ນວ່າ algorithmic NAT. ສໍາລັບການຈະລາຈອນປີ້ນກັບກັນ (ແລະການແປງຈາກ IPv6 ເປັນ IPv4) ມີ algorithmic NAT node ດຽວກັນ.

ການຈະລາຈອນໂດຍກົງຈາກລູກຄ້າ balancer ໄປໂດຍຜ່ານເສັ້ນຕາຕະລາງ, ເຊິ່ງປະຕິບັດການດຸ່ນດ່ຽງຕົວມັນເອງ. 

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

The 5-tuple hash ຊ່ວຍໃຫ້ພວກເຮົາປະຕິບັດການຄິດໄລ່ຫນ້ອຍລົງໃນ node hashing ທີ່ສອດຄ່ອງຕາມລໍາດັບ, ເຊັ່ນດຽວກັນກັບການປ່ຽນແປງບັນຊີລາຍຊື່ຊັບພະຍາກອນທີ່ດີກວ່າຢູ່ເບື້ອງຫຼັງ balancer. ເມື່ອແພັກເກັດທີ່ບໍ່ມີເຊດຊັນມາຮອດຕົວດຸ່ນດ່ຽງ, ມັນຖືກສົ່ງໄປຫາໂຫນດ hashing ທີ່ສອດຄ່ອງ. ນີ້ແມ່ນບ່ອນທີ່ການດຸ່ນດ່ຽງເກີດຂຶ້ນໂດຍໃຊ້ hashing ທີ່ສອດຄ່ອງ: ພວກເຮົາເລືອກຊັບພະຍາກອນຈາກບັນຊີລາຍຊື່ຂອງຊັບພະຍາກອນ "ສົດ" ທີ່ມີຢູ່. ຕໍ່ໄປ, ແພັກເກັດຖືກສົ່ງໄປຫາ NAT node, ເຊິ່ງຕົວຈິງແລ້ວແທນທີ່ຢູ່ປາຍທາງແລະຄິດໄລ່ checksums ຄືນໃຫມ່. ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ພວກເຮົາປະຕິບັດຕາມກົດລະບຽບຂອງ VPP - ມັກມັກ, ການຈັດກຸ່ມການຄິດໄລ່ທີ່ຄ້າຍຄືກັນເພື່ອເພີ່ມປະສິດຕິພາບຂອງຖານຄວາມຈໍາຂອງໂປເຊດເຊີ.

hashing ສອດຄ່ອງ

ເປັນຫຍັງພວກເຮົາເລືອກມັນແລະມັນແມ່ນຫຍັງ? ທໍາອິດ, ໃຫ້ພິຈາລະນາວຽກງານທີ່ຜ່ານມາ - ການເລືອກຊັບພະຍາກອນຈາກບັນຊີລາຍຊື່. 

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

hashing ສອດຄ່ອງແກ້ໄຂບັນຫາທີ່ໄດ້ອະທິບາຍ. ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະອະທິບາຍແນວຄວາມຄິດນີ້ແມ່ນນີ້: ຈິນຕະນາການວ່າທ່ານມີວົງແຫວນທີ່ທ່ານແຈກຢາຍຊັບພະຍາກອນໂດຍ hash (ຕົວຢ່າງ, ໂດຍ IP: port). ການເລືອກຊັບພະຍາກອນແມ່ນການຫັນລໍ້ໂດຍມຸມ, ເຊິ່ງຖືກກໍານົດໂດຍ hash ຂອງແພັກເກັດ.

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

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

Loadbalancer-node ແລະອົງປະກອບປະກອບ

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

ບັນຫາໃດແດ່ຖືກຫຼີກເວັ້ນ?

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

ບັນຫາແລະການແກ້ໄຂ

ອັນໃດບໍ່ໄດ້ຜົນດີ? Go ມີການຈັດການຄວາມຊົງຈໍາອັດຕະໂນມັດ, ແຕ່ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຍັງຄົງເກີດຂຶ້ນ. ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະຈັດການກັບພວກມັນແມ່ນເພື່ອດໍາເນີນການ goroutines ແລະຈື່ຈໍາທີ່ຈະຢຸດພວກມັນ. Takeaway: ເບິ່ງການໃຊ້ຄວາມຊົງຈຳຂອງໂປຣແກຣມ Go ຂອງທ່ານ. ເລື້ອຍໆຕົວຊີ້ວັດທີ່ດີແມ່ນຈໍານວນຂອງ goroutines. ມີບວກໃນເລື່ອງນີ້: ໃນ Go ມັນງ່າຍທີ່ຈະໄດ້ຮັບຂໍ້ມູນເວລາແລ່ນ - ການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ, ຈໍານວນຂອງການແລ່ນ goroutines, ແລະຕົວກໍານົດການອື່ນໆຈໍານວນຫຼາຍ.

ນອກຈາກນີ້, Go ອາດຈະບໍ່ແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດສໍາລັບການທົດສອບທີ່ເປັນປະໂຫຍດ. ພວກເຂົາເຈົ້າແມ່ນຂ້ອນຂ້າງ verbose, ແລະວິທີການມາດຕະຖານຂອງ "ແລ່ນທຸກສິ່ງທຸກຢ່າງໃນ CI ເປັນ batch" ແມ່ນບໍ່ເຫມາະສົມສໍາລັບເຂົາເຈົ້າ. ຄວາມຈິງແລ້ວແມ່ນວ່າການທົດສອບທີ່ເປັນປະໂຫຍດແມ່ນຕ້ອງການຊັບພະຍາກອນຫຼາຍຂຶ້ນແລະເຮັດໃຫ້ເກີດການຫມົດເວລາທີ່ແທ້ຈິງ. ດ້ວຍເຫດຜົນນີ້, ການທົດສອບອາດຈະລົ້ມເຫລວເພາະວ່າ CPU ຫຍຸ້ງກັບການທົດສອບຫນ່ວຍ. ສະຫຼຸບ: ຖ້າເປັນໄປໄດ້, ເຮັດການທົດສອບ "ຫນັກ" ແຍກຕ່າງຫາກຈາກການທົດສອບຫນ່ວຍ. 

ສະຖາປັດຕະຍະກໍາເຫດການ Microservice ແມ່ນສະລັບສັບຊ້ອນຫຼາຍກ່ວາ monolith: ການເກັບບັນທຶກໃນຫລາຍສິບເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນແມ່ນບໍ່ສະດວກຫຼາຍ. ສະຫຼຸບ: ຖ້າທ່ານເຮັດບໍລິການຈຸລະພາກ, ໃຫ້ຄິດກ່ຽວກັບການຕິດຕາມທັນທີ.

ແຜນການຂອງພວກເຮົາ

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

ບໍ່ດົນມານີ້, ການປ່ອຍຕົວສາທາລະນະຂອງ Yandex Load Balancer ເກີດຂຶ້ນ. ສຳຫຼວດ ເອກະສານ ກັບການບໍລິການ, ຈັດການການດຸ່ນດ່ຽງໃນວິທີທີ່ສະດວກສໍາລັບທ່ານແລະເພີ່ມຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງໂຄງການຂອງທ່ານ!

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