ສະຖາປັດຕະຍະກຳເວັບທີ່ທົນທານຕໍ່ຄວາມຜິດຖືກປະຕິບັດແນວໃດໃນເວທີ Mail.ru Cloud Solutions

ສະບາຍດີ, Habr! ຂ້ອຍແມ່ນ Artem Karamyshev, ຫົວຫນ້າທີມບໍລິຫານລະບົບ Mail.Ru Cloud Solutions (MCS). ພວກເຮົາໄດ້ມີການເປີດຕົວຜະລິດຕະພັນໃຫມ່ຫຼາຍໃນປີທີ່ຜ່ານມາ. ພວກເຮົາຕ້ອງການຮັບປະກັນວ່າການບໍລິການ API ສາມາດຂະຫຍາຍໄດ້ງ່າຍ, ທົນທານຕໍ່ຄວາມຜິດ, ແລະກຽມພ້ອມສໍາລັບການຂະຫຍາຍຕົວຢ່າງໄວວາໃນການໂຫຼດຂອງຜູ້ໃຊ້. ແພລະຕະຟອມຂອງພວກເຮົາຖືກປະຕິບັດຢູ່ໃນ OpenStack, ແລະຂ້ອຍຕ້ອງການບອກທ່ານວ່າບັນຫາຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງອົງປະກອບໃດທີ່ພວກເຮົາຕ້ອງແກ້ໄຂເພື່ອໃຫ້ໄດ້ລະບົບທີ່ທົນທານຕໍ່ຄວາມຜິດ. ຂ້າພະເຈົ້າຄິດວ່ານີ້ຈະເປັນສິ່ງທີ່ຫນ້າສົນໃຈສໍາລັບຜູ້ທີ່ຍັງພັດທະນາຜະລິດຕະພັນໃນ OpenStack.

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

ສະບັບວີດີໂອຂອງເລື່ອງນີ້, ແຫຼ່ງຕົ້ນຕໍແມ່ນບົດລາຍງານຢູ່ໃນກອງປະຊຸມ Uptime day 4, ຈັດໂດຍ ITSumma, ທ່ານສາມາດເບິ່ງ ຢູ່ໃນຊ່ອງ YouTube Uptime Community.

ຄວາມຢືດຢຸ່ນຂອງສະຖາປັດຕະຍະກໍາທາງດ້ານຮ່າງກາຍ

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

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

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

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

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

ຄວາມຢືດຢຸ່ນຂອງໂຄງສ້າງພື້ນຖານທາງດ້ານຮ່າງກາຍ

ສິ່ງທີ່ພວກເຮົາໃຊ້ສໍາລັບຄວາມທົນທານຕໍ່ຄວາມຜິດພາດໃນລະດັບຄໍາຮ້ອງສະຫມັກ

ການບໍລິການຂອງພວກເຮົາແມ່ນສ້າງຂຶ້ນໃນອົງປະກອບ opensource ຈໍານວນຫນຶ່ງ.

ExaBGP ແມ່ນການບໍລິການທີ່ປະຕິບັດຫນ້າທີ່ຈໍານວນຫນຶ່ງໂດຍໃຊ້ BGP-based dynamic routing protocol. ພວກເຮົາໃຊ້ມັນຢ່າງຈິງຈັງເພື່ອໂຄສະນາທີ່ຢູ່ IP ຂອງບັນຊີຂາວຂອງພວກເຮົາໂດຍຜ່ານທີ່ຜູ້ໃຊ້ເຂົ້າເຖິງ API.

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

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

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

ສະຖາປັດຕະຍະກຳແອັບພລິເຄຊັນ OpenStack ມາດຕະຖານ

ບໍລິການສ່ວນໃຫຍ່ທີ່ພັດທະນາສໍາລັບ OpenStack ພະຍາຍາມປະຕິບັດຕາມແບບແຜນດຽວ. ປົກກະຕິແລ້ວການບໍລິການປະກອບດ້ວຍ 2 ພາກສ່ວນ: API ແລະພະນັກງານ (ຜູ້ປະຕິບັດການ backend). ຕາມກົດລະບຽບ, API ແມ່ນແອັບພລິເຄຊັນ WSGI ໃນ python, ເຊິ່ງຖືກເປີດຕົວເປັນຂະບວນການເອກະລາດ (daemon), ຫຼືໃຊ້ເຄື່ອງແມ່ຂ່າຍເວັບ Nginx ຫຼື Apache ທີ່ກຽມພ້ອມ. API ປະມວນຜົນການຮ້ອງຂໍຂອງຜູ້ໃຊ້ແລະສົ່ງຄໍາແນະນໍາເພີ່ມເຕີມຕໍ່ກັບຄໍາຮ້ອງສະຫມັກຂອງພະນັກງານເພື່ອປະຕິບັດ. ການໂອນເງິນເກີດຂື້ນໂດຍໃຊ້ຕົວສະແດງຂໍ້ຄວາມ, ປົກກະຕິແລ້ວ RabbitMQ, ຄົນອື່ນໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ບໍ່ດີ. ເມື່ອຂໍ້ຄວາມມາຮອດນາຍຫນ້າ, ພວກມັນຈະຖືກປຸງແຕ່ງໂດຍຄົນງານແລະ, ຖ້າຈໍາເປັນ, ກັບຄືນຄໍາຕອບ.

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

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

ການບໍລິການບາງຢ່າງຕ້ອງການການປະສານງານພາຍໃນການບໍລິການໃນເວລາທີ່ການດໍາເນີນການຕາມລໍາດັບທີ່ສັບສົນເກີດຂື້ນລະຫວ່າງ APIs ແລະພະນັກງານ. ໃນກໍລະນີນີ້, ສູນປະສານງານດຽວຖືກນໍາໃຊ້, ລະບົບກຸ່ມເຊັ່ນ Redis, Memcache, ແລະອື່ນໆ, ເຊິ່ງອະນຸຍາດໃຫ້ພະນັກງານຄົນຫນຶ່ງບອກຄົນອື່ນວ່າວຽກງານນີ້ຖືກມອບຫມາຍໃຫ້ລາວ ("ກະລຸນາຢ່າເອົາມັນ"). ພວກເຮົາໃຊ້ແລະອື່ນໆ. ຕາມກົດລະບຽບ, ພະນັກງານສື່ສານຢ່າງຈິງຈັງກັບຖານຂໍ້ມູນ, ຂຽນແລະອ່ານຂໍ້ມູນຈາກບ່ອນນັ້ນ. ພວກເຮົາໃຊ້ mariadb ເປັນຖານຂໍ້ມູນ, ເຊິ່ງຕັ້ງຢູ່ໃນກຸ່ມ multimaster.

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

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

ສະຖາປັດຕະຍະກຳແອັບພລິເຄຊັນ Openstack. ການດຸ່ນດ່ຽງແລະຄວາມທົນທານຕໍ່ຄວາມຜິດພາດຂອງເວທີຟັງ

ເຮັດໃຫ້ເຄື່ອງດຸ່ນດ່ຽງ HAProxy ມີຄວາມທົນທານຕໍ່ຄວາມຜິດພາດໂດຍໃຊ້ ExaBGP

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

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

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

ໂຄງການ ExaBGP+HAProxy

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

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

ໃນກໍລະນີທີ່ມີບັນຫາກັບການດໍາເນີນງານຂອງ HAProxy ຫຼືຄວາມລົ້ມເຫຼວຂອງເຄື່ອງແມ່ຂ່າຍ, ExaBGP ຢຸດເຊົາການປະກາດເສັ້ນທາງ, ແລະການຈະລາຈອນຈະສະຫຼັບກັບເຄື່ອງແມ່ຂ່າຍອື່ນ.

ດັ່ງນັ້ນ, ພວກເຮົາບັນລຸຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງຜູ້ດຸ່ນດ່ຽງ.

ຄວາມທົນທານຄວາມຜິດຂອງຕົວດຸ່ນດ່ຽງ HAProxy

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

ການດຸ່ນດ່ຽງໂດຍອີງໃສ່ DNS ບວກ BGP

ບັນຫາຂອງການດຸ່ນດ່ຽງການໂຫຼດສໍາລັບ HAProxy ຂອງພວກເຮົາຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂ. ຢ່າງໃດກໍຕາມ, ມັນສາມາດແກ້ໄຂໄດ້ຢ່າງງ່າຍດາຍ, ດັ່ງທີ່ພວກເຮົາໄດ້ເຮັດຢູ່ທີ່ນີ້.

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

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

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

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

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

ການດຸ່ນດ່ຽງ HAProxy ໂດຍອີງໃສ່ DNS + BGP

ການໂຕ້ຕອບລະຫວ່າງ ExaBGP ແລະ HAProxy

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

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

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

ກວດສຸຂະພາບ HAProxy

HAProxy Peers: ການຊິ້ງຂໍ້ມູນເຊດຊັນ

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

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

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

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

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

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

ໃນ IaaS ພວກເຮົາມີບໍລິການທີ່ສ້າງຂຶ້ນໂດຍໃຊ້ເຕັກໂນໂລຢີດຽວກັນ. ນີ້ Load Balancer ເປັນບໍລິການສໍາລັບ OpenStack, ເຊິ່ງເອີ້ນວ່າ Octavia. ມັນແມ່ນອີງໃສ່ສອງຂະບວນການ HAProxy ແລະໃນເບື້ອງຕົ້ນປະກອບມີການສະຫນັບສະຫນູນສໍາລັບເພື່ອນມິດ. ພວກເຂົາເຈົ້າໄດ້ພິສູດຕົນເອງທີ່ດີເລີດໃນການບໍລິການນີ້.

ຮູບ​ພາບ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ການ​ເຄື່ອນ​ໄຫວ​ຂອງ​ຕາ​ຕະ​ລາງ peer ລະ​ຫວ່າງ​ສາມ​ຕົວ​ຢ່າງ HAProxy​, ການ​ຕັ້ງ​ຄ່າ​ແມ່ນ​ໄດ້​ສະ​ເຫນີ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ນີ້​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​:

HAProxy Peers (ການຊິ້ງຂໍ້ມູນເຊດຊັນ)

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

ການຈໍາກັດຈໍານວນການຮ້ອງຂໍພ້ອມກັນຈາກລູກຄ້າດຽວກັນ

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

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

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

ນີ້ເບິ່ງຄືແນວໃດໃນການປະຕິບັດ? ພວກເຮົາມີລູກຄ້າທີ່ໃຊ້ APIs autoscaling ຂອງພວກເຮົາຕະຫຼອດເວລາ. ພວກເຂົາເຈົ້າສ້າງປະມານສອງຫາສາມຮ້ອຍເຄື່ອງ virtual ໃນຕອນເຊົ້າແລະລຶບພວກມັນໃນຕອນແລງ. ສໍາລັບ OpenStack, ການສ້າງເຄື່ອງ virtual, ພ້ອມກັບການບໍລິການ PaaS, ຕ້ອງການຢ່າງຫນ້ອຍ 1000 ຄໍາຮ້ອງຂໍ API, ເນື່ອງຈາກວ່າການໂຕ້ຕອບລະຫວ່າງການບໍລິການຍັງເກີດຂຶ້ນໂດຍຜ່ານ API.

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

ວິທີການປັບປຸງ codebase ຂອງທ່ານໂດຍທີ່ຜູ້ໃຊ້ສັງເກດເຫັນ

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

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

ເພື່ອແກ້ໄຂບັນຫານີ້, ມັນຈໍາເປັນຕ້ອງຮັບປະກັນການຄວບຄຸມການດຸ່ນດ່ຽງແລະການປິດການບໍລິການ "ທີ່ຖືກຕ້ອງ":

• ໃນກໍລະນີຂອງ HAProxy, ການຄວບຄຸມແມ່ນດໍາເນີນການຜ່ານໄຟລ໌ສະຖິຕິ, ເຊິ່ງເປັນສິ່ງຈໍາເປັນ socket ແລະຖືກກໍານົດໄວ້ໃນ HAProxy config. ທ່ານສາມາດສົ່ງຄໍາສັ່ງໄປຫາມັນຜ່ານ stdio. ແຕ່ເຄື່ອງມືຄວບຄຸມການຕັ້ງຄ່າຕົ້ນຕໍຂອງພວກເຮົາແມ່ນບໍ່ສາມາດໃຊ້ໄດ້, ສະນັ້ນມັນມີໂມດູນໃນຕົວສໍາລັບການຄຸ້ມຄອງ HAProxy. ທີ່ພວກເຮົາໃຊ້ຢ່າງຈິງຈັງ.
• ການບໍລິການ API ແລະ Engine ສ່ວນໃຫຍ່ຂອງພວກເຮົາສະໜັບສະໜູນເທັກໂນໂລຍີການປິດເຄື່ອງທີ່ສະຫງ່າງາມ: ເມື່ອປິດເຄື່ອງ, ພວກເຂົາລໍຖ້າໃຫ້ວຽກປັດຈຸບັນສຳເລັດ, ບໍ່ວ່າຈະເປັນການຮ້ອງຂໍ http ຫຼືບາງວຽກບໍລິການ. ສິ່ງດຽວກັນເກີດຂຶ້ນກັບຄົນງານ. ມັນຮູ້ຈັກວຽກງານທັງຫມົດທີ່ມັນກໍາລັງເຮັດແລະສິ້ນສຸດລົງເມື່ອມັນສໍາເລັດທຸກຢ່າງ.

ຂໍຂອບໃຈກັບສອງຈຸດນີ້, ສູດການຄິດໄລ່ທີ່ປອດໄພສໍາລັບການນໍາໃຊ້ຂອງພວກເຮົາເບິ່ງຄືວ່ານີ້.

1. ນັກພັດທະນາປະກອບຊຸດລະຫັດໃຫມ່ (ສໍາລັບພວກເຮົານີ້ແມ່ນ RPM), ທົດສອບມັນຢູ່ໃນສະພາບແວດລ້ອມ dev, ທົດສອບມັນຢູ່ໃນຂັ້ນຕອນ, ແລະປ່ອຍໃຫ້ມັນຢູ່ໃນ repository ເວທີ.
2. ນັກພັດທະນາກໍານົດວຽກງານສໍາລັບການນໍາໃຊ້ທີ່ມີຄໍາອະທິບາຍລາຍລະອຽດທີ່ສຸດຂອງ "ສິ່ງປະດິດ": ສະບັບຂອງຊຸດໃຫມ່, ຄໍາອະທິບາຍກ່ຽວກັບຫນ້າທີ່ໃຫມ່ແລະລາຍລະອຽດອື່ນໆກ່ຽວກັບການຕິດຕັ້ງຖ້າຈໍາເປັນ.
3. ຜູ້ເບິ່ງແຍງລະບົບເລີ່ມຕົ້ນການອັບເດດ. ເປີດຕົວ Ansible playbook, ເຊິ່ງໃນນັ້ນເຮັດດັ່ງຕໍ່ໄປນີ້:
   • ເອົາຊຸດຈາກ repository ຂັ້ນຕອນແລະນໍາໃຊ້ມັນເພື່ອປັບປຸງສະບັບຂອງຊຸດໃນ repository ຜະລິດຕະພັນ.
   • ລວບລວມບັນຊີລາຍຊື່ຂອງ backend ຂອງການບໍລິການປັບປຸງ.
   • ປິດການບໍລິການທໍາອິດທີ່ຈະໄດ້ຮັບການປັບປຸງໃນ HAProxy ແລະລໍຖ້າຂະບວນການຂອງມັນສໍາເລັດການເຮັດວຽກ. ຂໍຂອບໃຈກັບການປິດຢ່າງສະໜິດສະໜົມ, ພວກເຮົາໝັ້ນໃຈວ່າທຸກຄຳຮ້ອງຂໍຂອງລູກຄ້າໃນປັດຈຸບັນຈະສຳເລັດຢ່າງສຳເລັດຜົນ.
   • ຫຼັງຈາກ API ແລະພະນັກງານຖືກຢຸດຢ່າງສົມບູນ, ແລະ HAProxy ຖືກປິດ, ລະຫັດຈະຖືກປັບປຸງ.
   • ບໍລິການແລ່ນ Ansible.
   • ສໍາລັບແຕ່ລະບໍລິການ, "ມືຈັບ" ບາງຢ່າງຖືກດຶງ, ເຊິ່ງປະຕິບັດການທົດສອບຫນ່ວຍງານກ່ຽວກັບການທົດສອບທີ່ສໍາຄັນຈໍານວນຫນຶ່ງທີ່ກໍານົດໄວ້ກ່ອນ. ການກວດສອບພື້ນຖານຂອງລະຫັດໃຫມ່ເກີດຂຶ້ນ.
   • ຖ້າບໍ່ພົບຂໍ້ຜິດພາດໃນຂັ້ນຕອນທີ່ຜ່ານມາ, backend ຈະຖືກເປີດໃຊ້.
   • ຂໍໃຫ້ກ້າວໄປສູ່ backend ຕໍ່ໄປ.
4. ຫຼັງຈາກ backends ທັງຫມົດໄດ້ຖືກປັບປຸງ, ການທົດສອບທີ່ເປັນປະໂຫຍດແມ່ນໄດ້ເປີດຕົວ. ຖ້າພວກເຂົາຫາຍໄປ, ຫຼັງຈາກນັ້ນນັກພັດທະນາເບິ່ງຫນ້າທີ່ໃຫມ່ທີ່ລາວສ້າງ.

ນີ້ຈະສໍາເລັດການປະຕິບັດການ.

ຮອບອັບເດດການບໍລິການ

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

ສະຫລຸບ

ແບ່ງປັນຄວາມຄິດຂອງຕົນເອງກ່ຽວກັບສະຖາປັດຕະຍະກໍາເວັບທີ່ທົນທານຕໍ່ຄວາມຜິດ, ຂ້າພະເຈົ້າຢາກຈະສັງເກດເຫັນຈຸດສໍາຄັນຂອງມັນອີກເທື່ອຫນຶ່ງ:

• ຄວາມທົນທານຕໍ່ຄວາມຜິດທາງຮ່າງກາຍ;
• ຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງເຄືອຂ່າຍ (ຜູ້ດຸ່ນດ່ຽງ, BGP);
• ຄວາມທົນທານຄວາມຜິດຂອງຊອບແວທີ່ໃຊ້ແລະພັດທະນາ.

ເວລາເຮັດວຽກຄົງທີ່ທຸກຄົນ!

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