ຫຍັງຍັງຄົງຢູ່ຫຼັງການສະຫຼັບ VIP ຂອງພຣັອກຊີ?
ແຍກການຟື້ນຟູທາງເຂົ້າພຣັອກຊີອອກຈາກການຄົງຢູ່ຂອງອຸໂມງ CONNECT ທີ່ສ້າງແລ້ວ ແລະ ທີ່ຢູ່ອອກໄປຫາເວັບໄຊ.
ທີ່ຢູ່ແບບລອຍຕົວຮັກສາການຕັ້ງຄ່າພຣັອກຊີໃຫ້ໝັ້ນຄົງ: ລູກຄ້າຍັງໃຊ້ຊື່ໂຮສ ຫຼື IP ເໝືອນເດີມ ຫຼັງຈາກເຄື່ອງທີ່ເຮັດວຽກລົ້ມເຫຼວ. ນັ້ນເປັນຄວາມສາມາດໃນການໃຊ້ງານທີ່ເປັນປະໂຫຍດ. ແຕ່ການດາວໂຫຼດທີ່ກຳລັງເຮັດຢູ່ກໍອາດຢຸດໄດ້.
ພິຈາລະນາຄຳຮ້ອງ HTTPS ທີ່ຢູ່ໃນ CONNECT ແລ້ວ. ພຣັອກຊີທີ່ເຮັດວຽກຖືກຳມະສິດການເຊື່ອມຕໍ່ TCP ໄປຫາລູກຄ້າ ແລະ ການເຊື່ອມຕໍ່ອີກອັນໜຶ່ງໄປຫາເວັບໄຊ. ມັນຍັງຖືສະຖານະຂອງແອັບພລິເຄຊັນທີ່ເຊື່ອມສະຕຣີມເຫຼົ່ານັ້ນ.
ການຍ້າຍທີ່ຢູ່ໄປຫາເຄື່ອງສຳຮອງ ບໍ່ໄດ້ຍ້າຍບລັອກຄວບຄຸມ TCP ຫຼື ສະຖານະການສົ່ງຕໍ່ນັ້ນໂດຍຕົວມັນເອງ. ເຈົ້າຂອງໃໝ່ສາມາດຮັບການເຊື່ອມຕໍ່ໃໝ່ໄດ້ ແຕ່ບໍ່ສາມາດສືບຕໍ່ສະຕຣີມໄບຕ໌ທີ່ເຈົ້າຂອງເກົ່າສ້າງໄວ້ໄດ້.
| ຄວາມຄາດຫວັງ | ການສະຫຼັບທີ່ຢູ່ປົກກະຕິໃຫ້ສິ່ງນີ້ບໍ? |
|---|---|
| ຮັກສາທາງເຂົ້າທີ່ຕັ້ງຄ່າໄວ້ໜຶ່ງອັນ | ນັ້ນແມ່ນຜົນປະໂຫຍດທີ່ຕັ້ງໃຈ |
| ສືບຕໍ່ສະຕຣີມ CONNECT ທີ່ສ້າງແລ້ວ | ຈະຕ້ອງມີກົນໄກຖືສະຖານະເພີ່ມ |
| ຮັກສາ IP ສາທາລະນະອອກໄປອັນເດີມ | ຂຶ້ນກັບການເສັ້ນທາງອອກ ແລະ NAT |
| ເຮັດວຽກແອັບພລິເຄຊັນທີ່ຂາດຕອນຄືນຢ່າງປອດໄພ | ຂຶ້ນກັບວຽກ ແລະ ລູກຄ້າ |
VRRP ກຳນົດການເລືອກຕັ້ງ ແລະ ຄວາມເປັນເຈົ້າຂອງທີ່ຢູ່. ມັນບໍ່ແມ່ນໂປຣໂຕຄໍການສຳເນົາສຳລັບຂະບວນການພຣັອກຊີ. ການຕິດຕັ້ງທີ່ໃຊ້ຊອບແວຄວາມພ້ອມສູງອື່ນກໍຕ້ອງການຄວາມແຕກຕ່າງດຽວກັນ ເວັ້ນເສຍແຕ່ມັນໃຫ້ເພີ່ມຢ່າງຊັດເຈນ.
ທົບທວນວ່າການກວດສຸຂະພາບເຫັນຫຍັງແທ້. ເຄື່ອງສາມາດຕອບການປະກາດໄດ້ ໃນຂະນະທີ່ບໍລິການພຣັອກຊີ, DNS ຫຼື ເສັ້ນທາງຂຶ້ນໄປລົ້ມເຫຼວ. ກົງກັນຂ້າມ ການກວດທີ່ໄວຕໍ່ການປ່ຽນແປງເກີນໄປອາດເຮັດໃຫ້ເກີດການສະຫຼັບທີ່ບໍ່ຈຳເປັນ.
ການຟື້ນຟູຝ່າຍລູກຄ້າກໍສຳຄັນ. ຄຳຮ້ອງບຣາວເຊີໃໝ່ອາດເຊື່ອມຕໍ່ຄືນໄດ້ງ່າຍ; ການອັບໂຫຼດທີ່ມີ ບອດີທີ່ໃຊ້ໄປແລ້ວ ຫຼື ການເຮັດວຽກ API ທີ່ບໍ່ແບບ idempotent ອາດຕ້ອງການການຈັດການສະເພາະແອັບພລິເຄຊັນ. ຢ່າສັນຍາການສະຫຼັບທີ່ເບິ່ງບໍ່ເຫັນ ພຽງເພາະຄຳຮ້ອງໃໝ່ສຳເລັດຜ່ານເຄື່ອງສຳຮອງ.