Badoo ບັນລຸຄວາມສາມາດໃນການ render ຮູບພາບ 200k ຕໍ່ວິນາທີໄດ້ແນວໃດ

ເວັບໄຊຕ໌ທີ່ທັນສະໄຫມແມ່ນເກືອບຄິດວ່າບໍ່ມີເນື້ອໃນສື່ມວນຊົນ: ເກືອບທຸກແມ່ຕູ້ມີໂທລະສັບສະຫຼາດ, ທຸກຄົນຢູ່ໃນເຄືອຂ່າຍສັງຄົມ, ແລະການຢຸດເຊົາການບໍາລຸງຮັກສາແມ່ນຄ່າໃຊ້ຈ່າຍສໍາລັບບໍລິສັດ. ນີ້ແມ່ນບົດບັນທຶກຂອງເລື່ອງຂອງບໍລິສັດ Badoo ກ່ຽວກັບວິທີການທີ່ນາງໄດ້ຈັດຕັ້ງການຈັດສົ່ງຮູບພາບໂດຍໃຊ້ການແກ້ໄຂຮາດແວ, ບັນຫາການປະຕິບັດທີ່ນາງພົບໃນຂະບວນການ, ສາເຫດຂອງພວກມັນແມ່ນຫຍັງ, ແລະບັນຫາເຫຼົ່ານີ້ຖືກແກ້ໄຂແນວໃດໂດຍໃຊ້ການແກ້ໄຂຊອບແວໂດຍອີງໃສ່ Nginx, ໃນຂະນະທີ່ຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດໃນທຸກລະດັບ (видео). ພວກເຮົາຂໍຂອບໃຈຜູ້ຂຽນເລື່ອງ Oleg ຊານນິສ Efimova ແລະ Alexandra Dymova, ຜູ້ທີ່ໄດ້ແບ່ງປັນປະສົບການຂອງເຂົາເຈົ້າຢູ່ໃນກອງປະຊຸມ ວັນ​ເວ​ລາ 4.

— ໃຫ້ເລີ່ມຕົ້ນດ້ວຍການແນະນໍາເລັກນ້ອຍກ່ຽວກັບວິທີທີ່ພວກເຮົາເກັບຮັກສາແລະ cache ຮູບພາບ. ພວກເຮົາມີຊັ້ນທີ່ພວກເຮົາເກັບຮັກສາພວກມັນ, ແລະຊັ້ນທີ່ພວກເຮົາເກັບຮູບພາບ. ໃນເວລາດຽວກັນ, ຖ້າພວກເຮົາຕ້ອງການບັນລຸອັດຕາການຫລອກລວງທີ່ສູງແລະຫຼຸດຜ່ອນການໂຫຼດໃນບ່ອນເກັບມ້ຽນ, ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາທີ່ຮູບພາບຂອງຜູ້ໃຊ້ແຕ່ລະຄົນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງຖານຄວາມຈໍາຫນຶ່ງ. ຖ້າບໍ່ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງຕິດຕັ້ງແຜ່ນຫຼາຍເທົ່າທີ່ພວກເຮົາມີ servers ຫຼາຍ. ອັດຕາການຫລອກລວງຂອງພວກເຮົາແມ່ນປະມານ 99%, ນັ້ນແມ່ນ, ພວກເຮົາກໍາລັງຫຼຸດຜ່ອນການໂຫຼດໃນບ່ອນເກັບມ້ຽນຂອງພວກເຮົາ 100 ເທື່ອ, ແລະເພື່ອເຮັດສິ່ງນີ້, 10 ປີທີ່ຜ່ານມາ, ເມື່ອທັງຫມົດນີ້ຖືກສ້າງ, ພວກເຮົາມີ 50 ເຄື່ອງແມ່ຂ່າຍ. ດັ່ງນັ້ນ, ເພື່ອຮັບໃຊ້ຮູບພາບເຫຼົ່ານີ້, ພວກເຮົາຕ້ອງການ 50 ໂດເມນພາຍນອກທີ່ເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້ໃຫ້ບໍລິການ.

ຕາມທໍາມະຊາດ, ຄໍາຖາມເກີດຂຶ້ນທັນທີ: ຖ້າຫນຶ່ງໃນເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາຫຼຸດລົງແລະກາຍເປັນບໍ່ສາມາດໃຊ້ໄດ້, ພວກເຮົາຈະສູນເສຍສ່ວນໃດຂອງການຈະລາຈອນ? ພວກເຮົາໄດ້ເບິ່ງສິ່ງທີ່ຢູ່ໃນຕະຫຼາດແລະຕັດສິນໃຈຊື້ຊິ້ນສ່ວນຂອງຮາດແວເພື່ອວ່າມັນຈະແກ້ໄຂບັນຫາທັງຫມົດຂອງພວກເຮົາ. ທາງເລືອກໄດ້ຫຼຸດລົງໃນການແກ້ໄຂຂອງບໍລິສັດເຄືອຂ່າຍ F5 (ເຊິ່ງ, ໂດຍວິທີທາງການ, ບໍ່ດົນມານີ້ໄດ້ຊື້ NGINX, Inc): BIG-IP Local Traffic Manager.

ສິ່ງທີ່ຊິ້ນສ່ວນຂອງຮາດແວນີ້ (LTM) ເຮັດ: ມັນແມ່ນ router ທາດເຫຼັກທີ່ເຮັດໃຫ້ທາດເຫຼັກຂອງພອດພາຍນອກຂອງມັນຊ້ໍາກັນແລະຊ່ວຍໃຫ້ທ່ານສາມາດສົ່ງການຈະລາຈອນໂດຍອີງໃສ່ເຄືອຂ່າຍ topology, ໃນບາງການຕັ້ງຄ່າ, ແລະກວດເບິ່ງສຸຂະພາບ. ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາວ່າຊິ້ນສ່ວນຂອງຮາດແວນີ້ສາມາດຖືກດໍາເນີນໂຄງການ. ຕາມນັ້ນແລ້ວ, ພວກເຮົາສາມາດອະທິບາຍເຫດຜົນຂອງວິທີການຖ່າຍຮູບຂອງຜູ້ໃຊ້ສະເພາະໃດນຶ່ງຈາກຖານຄວາມຈຳສະເພາະໃດໜຶ່ງ. ມັນເບິ່ງຄືວ່າແນວໃດ? ມີຊິ້ນສ່ວນຂອງຮາດແວທີ່ເບິ່ງອິນເຕີເນັດຢູ່ໃນໂດເມນຫນຶ່ງ, IP ຫນຶ່ງ, ເຮັດ ssl offload, parses http requests, ເລືອກຈໍານວນ cache ຈາກ IRule, ບ່ອນທີ່ຈະໄປ, ແລະໃຫ້ການຈະລາຈອນໄປທີ່ນັ້ນ. ໃນຂະນະດຽວກັນ, ມັນເຮັດການກວດສຸຂະພາບ, ແລະໃນກໍລະນີທີ່ເຄື່ອງຈັກບາງຢ່າງບໍ່ສາມາດໃຊ້ໄດ້, ໃນເວລານັ້ນພວກເຮົາເຮັດໃຫ້ມັນເຮັດໃຫ້ການຈະລາຈອນໄປຫາເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນຫນຶ່ງ. ຈາກທັດສະນະຂອງການຕັ້ງຄ່າ, ແນ່ນອນ, ມັນມີຄວາມແຕກຕ່າງບາງຢ່າງ, ແຕ່ໂດຍທົ່ວໄປແລ້ວທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ: ພວກເຮົາລົງທະບຽນບັດ, ການຕອບໂຕ້ຂອງຕົວເລກທີ່ແນ່ນອນກັບ IP ຂອງພວກເຮົາໃນເຄືອຂ່າຍ, ພວກເຮົາເວົ້າວ່າພວກເຮົາຈະຟັງຢູ່ໃນທ່າເຮືອ 80. ແລະ 443, ພວກເຮົາເວົ້າວ່າຖ້າເຄື່ອງແມ່ຂ່າຍບໍ່ສາມາດໃຊ້ໄດ້, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງສົ່ງການຈະລາຈອນໄປຫາຕົວສໍາຮອງ, ໃນກໍລະນີນີ້, ວັນທີ 35, ແລະພວກເຮົາອະທິບາຍຫຼາຍເຫດຜົນກ່ຽວກັບວິທີການສະຖາປັດຕະຍະກໍານີ້ຄວນຈະຖືກຖອດອອກ. ບັນຫາພຽງແຕ່ວ່າພາສາທີ່ຮາດແວຖືກຕັ້ງໂຄງການແມ່ນ Tcl. ຖ້າໃຜຈື່ໄດ້ທັງໝົດ... ພາສານີ້ແມ່ນຂຽນໄດ້ຢ່າງດຽວກ່ວາພາສາທີ່ສະດວກໃນການຂຽນໂປຣແກຣມ:

ພວກເຮົາໄດ້ຮັບຫຍັງ? ພວກ​ເຮົາ​ໄດ້​ຮັບ​ຮາດ​ແວ​ອັນ​ໜຶ່ງ​ທີ່​ຮັບ​ປະ​ກັນ​ວ່າ​ໂຄງ​ລ່າງ​ພື້ນ​ຖານ​ຂອງ​ພວກ​ເຮົາ​ມີ​ຄວາມ​ພ້ອມ​ສູງ, ເປັນ​ເສັ້ນ​ທາງ​ການ​ສັນ​ຈອນ​ທັງ​ໝົດ​ຂອງ​ພວກ​ເຮົາ, ສະ​ຫນອງ​ຜົນ​ປະ​ໂຫຍດ​ດ້ານ​ສຸ​ຂະ​ພາບ ແລະ​ເຮັດ​ວຽກ​ໄດ້. ຍິ່ງໄປກວ່ານັ້ນ, ມັນເຮັດວຽກເປັນເວລາດົນນານ: ໃນໄລຍະ 10 ປີທີ່ຜ່ານມາບໍ່ມີການຮ້ອງທຸກກ່ຽວກັບມັນ. ໃນຕົ້ນປີ 2018, ພວກເຮົາໄດ້ສົ່ງຮູບປະມານ 80k ຕໍ່ວິນາທີແລ້ວ. ນີ້ແມ່ນບາງບ່ອນປະມານ 80 gigabits ຂອງການຈະລາຈອນຈາກທັງສອງສູນຂໍ້ມູນຂອງພວກເຮົາ.

ເຖິງຢ່າງໃດກໍ່ຕາມ…

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

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

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

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

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

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

ດັ່ງນັ້ນ, ເຫດຜົນຍັງຄົງຢູ່ຄືກັນ: ພວກເຮົາຕິດຕັ້ງ Nginx, ມັນສາມາດເຮັດ SSL-offload, ພວກເຮົາສາມາດດໍາເນີນໂຄງການ logic ເສັ້ນທາງ, ການກວດສອບສຸຂະພາບໃນ configs ແລະພຽງແຕ່ຊ້ໍາກັນຕາມເຫດຜົນທີ່ພວກເຮົາເຄີຍມີມາກ່ອນ.

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

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

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

ເພື່ອຫຼີກເວັ້ນການນີ້, ພວກເຮົາໄດ້ເຮັດສອງຢ່າງ:

a) ພວກເຂົາຫ້າມ Nginx ຈາກການເຮັດສິ່ງນີ້ດ້ວຍຕົນເອງ - ແຕ່ຫນ້າເສຍດາຍ, ວິທີດຽວທີ່ຈະເຮັດນີ້ແມ່ນພຽງແຕ່ກໍານົດການຕັ້ງຄ່າສູງສຸດທີ່ລົ້ມເຫລວ.

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

ແຕ່ຫນ້າເສຍດາຍ, ນີ້ບໍ່ແມ່ນທັງຫມົດ, ເພາະວ່າຕົວຈິງແລ້ວສອງອາທິດທໍາອິດຂອງການດໍາເນີນງານຂອງໂຄງການນີ້ສະແດງໃຫ້ເຫັນວ່າ TCP ການກວດສອບສຸຂະພາບຍັງເປັນສິ່ງທີ່ບໍ່ຫນ້າເຊື່ອຖື: ໃນເຄື່ອງແມ່ຂ່າຍຂອງນ້ໍາມັນອາດຈະບໍ່ແມ່ນ Nginx, ຫຼື Nginx ໃນ D-state, ແລະໃນ. ກໍລະນີນີ້ kernel ຈະຍອມຮັບການເຊື່ອມຕໍ່, ການກວດສອບສຸຂະພາບຈະຜ່ານ, ແຕ່ຈະບໍ່ເຮັດວຽກ. ດັ່ງນັ້ນ, ພວກເຮົາທັນທີທັນໃດແທນນີ້ດ້ວຍການກວດສຸຂະພາບ http, ເຮັດສະເພາະຫນຶ່ງ, ເຊິ່ງ, ຖ້າມັນກັບຄືນມາ 200, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢູ່ໃນສະຄິບນີ້. ທ່ານສາມາດເຮັດເຫດຜົນເພີ່ມເຕີມ - ຕົວຢ່າງ, ໃນກໍລະນີຂອງເຄື່ອງແມ່ຂ່າຍຂອງຖານຄວາມຈໍາ, ກວດເບິ່ງວ່າລະບົບໄຟລ໌ຖືກຕິດຕັ້ງຢ່າງຖືກຕ້ອງ:

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

ເນື່ອງຈາກວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະໄປເຖິງຕົ້ນນ້ໍາອື່ນພາຍໃນຫນຶ່ງຕົ້ນນ້ໍາ, ມັນເປັນສິ່ງຈໍາເປັນເພື່ອໃຫ້ແນ່ໃຈວ່າຖ້າຕົ້ນນ້ໍາຕົ້ນຕໍ, ທີ່ພວກເຮົາພຽງແຕ່ບັນທຶກ cache ຮູບພາບທີ່ຖືກຕ້ອງ, ທີ່ຈໍາເປັນ, ແມ່ນບໍ່ສາມາດໃຊ້ໄດ້, ພວກເຮົາພຽງແຕ່ຜ່ານ error_page ກັບ fallback, ຈາກ. ບ່ອນທີ່ພວກເຮົາໄປ backup upstream:

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

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

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

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍສ່ວນທໍາອິດ: VRRP - ມັນເບິ່ງຄືວ່າແນວໃດ? ມີ IP virtual ທີ່ແນ່ນອນ, ເຊິ່ງມີການເຂົ້າຢູ່ໃນ dns badoocdn.com, ບ່ອນທີ່ລູກຄ້າເຊື່ອມຕໍ່. ໃນບາງເວລາ, ພວກເຮົາມີທີ່ຢູ່ IP ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ. packets Keepalived ດໍາເນີນການລະຫວ່າງເຄື່ອງແມ່ຂ່າຍໂດຍໃຊ້ໂປໂຕຄອນ VRRP, ແລະຖ້າແມ່ບົດຫາຍໄປຈາກ radar - ເຄື່ອງແມ່ຂ່າຍໄດ້ rebooted ຫຼືບາງສິ່ງບາງຢ່າງອື່ນ, ຫຼັງຈາກນັ້ນເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນຈະເລືອກເອົາທີ່ຢູ່ IP ນີ້ໂດຍອັດຕະໂນມັດ - ບໍ່ຈໍາເປັນຕ້ອງດໍາເນີນການຄູ່ມື. ຄວາມແຕກຕ່າງລະຫວ່າງແມ່ບົດແລະການສໍາຮອງສ່ວນໃຫຍ່ແມ່ນບູລິມະສິດ: ມັນສູງກວ່າ, ໂອກາດທີ່ເຄື່ອງຈັກຈະກາຍເປັນແມ່ບົດ. ປະໂຫຍດອັນໃຫຍ່ຫຼວງຫຼາຍແມ່ນວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງ configure ທີ່ຢູ່ IP ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງມັນເອງ, ມັນພຽງພໍທີ່ຈະອະທິບາຍພວກມັນໃນ config, ແລະຖ້າທີ່ຢູ່ IP ຕ້ອງການກົດລະບຽບການກໍານົດເສັ້ນທາງທີ່ກໍາຫນົດເອງ, ນີ້ແມ່ນອະທິບາຍໂດຍກົງໃນ config, ການນໍາໃຊ້. syntax ດຽວກັນທີ່ອະທິບາຍໄວ້ໃນຊຸດ VRRP. ເຈົ້າຈະບໍ່ພົບສິ່ງທີ່ບໍ່ຄຸ້ນເຄີຍ.

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງທີ່ຢູ່ IP ພາຍນອກ. ສ່ວນຕໍ່ໄປແມ່ນການດຸ່ນດ່ຽງການຈາລະຈອນຈາກທີ່ຢູ່ IP ພາຍນອກໄປຫາ routers ຮູບທີ່ກໍາລັງຢຸດມັນແລ້ວ. ທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງຊັດເຈນກັບໂປໂຕຄອນການດຸ່ນດ່ຽງ. ນີ້ແມ່ນບໍ່ວ່າຈະເປັນ round-robin ງ່າຍດາຍ, ຫຼືສິ່ງທີ່ສັບສົນເລັກນ້ອຍ, wrr, ການເຊື່ອມຕໍ່ບັນຊີລາຍຊື່ແລະອື່ນໆ. ນີ້ແມ່ນອະທິບາຍໂດຍພື້ນຖານໃນເອກະສານ, ບໍ່ມີຫຍັງພິເສດ. ແຕ່ວິທີການຈັດສົ່ງ ... ນີ້ພວກເຮົາຈະພິຈາລະນາຢ່າງໃກ້ຊິດວ່າເປັນຫຍັງພວກເຮົາເລືອກຫນຶ່ງຂອງພວກເຂົາ. ເຫຼົ່ານີ້ແມ່ນ NAT, Direct Routing ແລະ TUN. ຄວາມຈິງແລ້ວແມ່ນວ່າພວກເຮົາວາງແຜນທີ່ຈະສົ່ງ 100 gigabits ຂອງການຈະລາຈອນຈາກສະຖານທີ່. ຖ້າທ່ານຄາດຄະເນ, ທ່ານຕ້ອງການບັດ 10 gigabit, ແມ່ນບໍ? ບັດ 10 gigabit ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງແມ່ນເກີນຂອບເຂດຂອງ, ຢ່າງຫນ້ອຍ, ແນວຄວາມຄິດຂອງພວກເຮົາກ່ຽວກັບ "ອຸປະກອນມາດຕະຖານ". ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈື່ໄດ້ວ່າພວກເຮົາບໍ່ພຽງແຕ່ໃຫ້ການຈະລາຈອນບາງ, ພວກເຮົາໃຫ້ຮູບພາບໄປ.

ພິເສດແມ່ນຫຍັງ? - ຄວາມ​ແຕກ​ຕ່າງ​ອັນ​ໃຫຍ່​ຫຼວງ​ລະ​ຫວ່າງ​ການ​ຈະ​ລາ​ຈອນ​ເຂົ້າ​ແລະ​ຂາ​ອອກ​. ການຈະລາຈອນຂາເຂົ້າແມ່ນນ້ອຍຫຼາຍ, ການຈະລາຈອນຂາອອກແມ່ນໃຫຍ່ຫຼາຍ:

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

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

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

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

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

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

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

ທັງຫມົດທີ່ຍັງຄົງເວົ້າແມ່ນວ່າທັງຫມົດນີ້, ແນ່ນອນ, ຕ້ອງໄດ້ຮັບການຕິດຕາມ. ແຍກຕ່າງຫາກ, ຄວນສັງເກດວ່າ Keepalivede, ເປັນຊອບແວທີ່ຂຽນໄວ້ດົນນານມາແລ້ວ, ມີວິທີການຕິດຕາມມັນ, ທັງການນໍາໃຊ້ການກວດສອບຜ່ານ DBus, SMTP, SNMP, ແລະມາດຕະຖານ Zabbix. ນອກຈາກນັ້ນ, ລາວເອງກໍ່ຮູ້ວິທີການຂຽນຕົວອັກສອນເກືອບທຸກໆການຈາມ, ແລະດ້ວຍຄວາມຊື່ສັດ, ໃນບາງຈຸດພວກເຮົາກໍ່ຄິດວ່າຈະປິດມັນ, ເພາະວ່າລາວຂຽນຕົວອັກສອນຈໍານວນຫລາຍສໍາລັບການປ່ຽນການຈະລາຈອນ, ສະຫຼັບ, ສໍາລັບການເຊື່ອມຕໍ່ IP ທຸກຄັ້ງ. ແລະອື່ນໆ. ແນ່ນອນ, ຖ້າມີເຄື່ອງແມ່ຂ່າຍຫຼາຍ, ຫຼັງຈາກນັ້ນທ່ານສາມາດ overwhelm ຕົວທ່ານເອງດ້ວຍຕົວອັກສອນເຫຼົ່ານີ້. ພວກເຮົາຕິດຕາມກວດກາ nginx ໃນ routers ຮູບພາບໂດຍໃຊ້ວິທີການມາດຕະຖານ, ແລະການກວດສອບຮາດແວບໍ່ໄດ້ຫມົດໄປ. ແນ່ນອນ, ພວກເຮົາຈະໃຫ້ຄໍາແນະນໍາອີກສອງຢ່າງ: ທໍາອິດ, ການກວດສອບສຸຂະພາບພາຍນອກແລະຄວາມພ້ອມ, ເພາະວ່າເຖິງແມ່ນວ່າທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກ, ໃນຄວາມເປັນຈິງ, ບາງທີຜູ້ໃຊ້ບໍ່ໄດ້ຮັບຮູບພາບຍ້ອນບັນຫາກັບຜູ້ໃຫ້ບໍລິການພາຍນອກຫຼືບາງສິ່ງບາງຢ່າງທີ່ສັບສົນຫຼາຍ. ມັນສະເຫມີຄຸ້ມຄ່າທີ່ຈະຮັກສາຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງໃນເຄືອຂ່າຍອື່ນ, ໃນ Amazon ຫຼືບ່ອນອື່ນ, ເຄື່ອງແຍກຕ່າງຫາກທີ່ສາມາດ ping ເຄື່ອງແມ່ຂ່າຍຂອງທ່ານຈາກພາຍນອກ, ແລະມັນຍັງຄຸ້ມຄ່າທີ່ຈະໃຊ້ການກວດສອບຄວາມຜິດປົກກະຕິ, ສໍາລັບຜູ້ທີ່ຮູ້ວິທີການເຮັດການຮຽນຮູ້ເຄື່ອງຈັກ tricky, ຫຼືການຕິດຕາມແບບງ່າຍໆ. , ຢ່າງຫນ້ອຍເພື່ອຕິດຕາມການຮ້ອງຂໍໄດ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ, ຫຼື, ໃນທາງກົງກັນຂ້າມ, ເພີ່ມຂຶ້ນ. ມັນຍັງສາມາດເປັນປະໂຫຍດ.

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

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

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