VMware NSX ສໍາລັບເດັກນ້ອຍ. ສ່ວນທີ 5: ການຕັ້ງຄ່າຕົວດຸ່ນດ່ຽງການໂຫຼດ

ສ່ວນຫນຶ່ງ. ແນະນໍາ
ສ່ວນສອງ. ການຕັ້ງຄ່າ Firewall ແລະກົດລະບຽບ NAT
ສ່ວນສາມ. ການຕັ້ງຄ່າ DHCP
ສ່ວນສີ່. ການຕັ້ງຄ່າເສັ້ນທາງ

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

ທິດສະດີ

ການແກ້ໄຂການດຸ່ນດ່ຽງ payload ໃນມື້ນີ້ທັງຫມົດສ່ວນຫຼາຍມັກຈະແບ່ງອອກເປັນສອງປະເພດ: ການດຸ່ນດ່ຽງໃນລະດັບທີ່ສີ່ (ການຂົນສົ່ງ) ແລະຄັ້ງທີ VII (ຄໍາຮ້ອງສະຫມັກ) ຂອງຮູບແບບ. ຫຼື IF. ຮູບແບບ OSI ບໍ່ແມ່ນຈຸດອ້າງອີງທີ່ດີທີ່ສຸດໃນເວລາທີ່ອະທິບາຍວິທີການດຸ່ນດ່ຽງ. ຕົວຢ່າງ, ຖ້າຕົວດຸ່ນດ່ຽງ L4 ຍັງສະຫນັບສະຫນູນການຢຸດເຊົາ TLS, ມັນຈະກາຍເປັນຕົວດຸ່ນດ່ຽງ L7 ບໍ? ແຕ່ວ່າມັນແມ່ນສິ່ງທີ່ມັນເປັນ.

• Balancer L4 ສ່ວນຫຼາຍມັກຈະເປັນຕົວແທນກາງລະຫວ່າງລູກຄ້າແລະຊຸດຂອງ backends ທີ່ມີຢູ່, ເຊິ່ງຢຸດການເຊື່ອມຕໍ່ TCP (ເຊິ່ງແມ່ນ, ຕອບສະຫນອງຢ່າງເປັນອິດສະຫຼະກັບ SYN), ເລືອກ backend ແລະເລີ່ມຕົ້ນກອງປະຊຸມ TCP ໃຫມ່ໃນທິດທາງຂອງມັນ, ສົ່ງ SYN ເປັນເອກະລາດ. ປະເພດນີ້ແມ່ນຫນຶ່ງໃນພື້ນຖານ; ທາງເລືອກອື່ນແມ່ນເປັນໄປໄດ້.
• Balancer L7 ແຈກຢາຍການຈະລາຈອນໃນທົ່ວ backends ທີ່ມີຢູ່ "ມີຄວາມຊັບຊ້ອນຫຼາຍ" ກ່ວາ L4 balancer ເຮັດ. ມັນສາມາດຕັດສິນໃຈວ່າຈະເລືອກ backend ໃດໂດຍອີງໃສ່, ຕົວຢ່າງ, ເນື້ອໃນຂອງຂໍ້ຄວາມ HTTP (URL, cookie, ແລະອື່ນໆ).

ບໍ່ວ່າປະເພດໃດກໍ່ຕາມ, ເຄື່ອງດຸ່ນດ່ຽງສາມາດສະຫນັບສະຫນູນຫນ້າທີ່ດັ່ງຕໍ່ໄປນີ້:

• ການຄົ້ນພົບການບໍລິການແມ່ນຂະບວນການກໍານົດຊຸດຂອງ backends ທີ່ມີຢູ່ (Static, DNS, Consul, Etcd, ແລະອື່ນໆ).
• ການກວດສອບການເຮັດວຽກຂອງ backends ທີ່ກວດພົບ ( "ping" ທີ່ໃຊ້ວຽກຂອງ backend ໂດຍໃຊ້ຄໍາຮ້ອງຂໍ HTTP, ການກວດສອບຕົວຕັ້ງຕົວຕີຂອງບັນຫາໃນການເຊື່ອມຕໍ່ TCP, ມີລະຫັດ HTTP ຫຼາຍ 503 ຢູ່ໃນຄໍາຕອບ, ແລະອື່ນໆ).
• ການດຸ່ນດ່ຽງຕົວມັນເອງ (ຮອບ robin, ການຄັດເລືອກແບບສຸ່ມ, ແຫຼ່ງ IP hash, URI).
• ການຢຸດເຊົາ TLS ແລະການກວດສອບໃບຢັ້ງຢືນ.
• ທາງເລືອກທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ (ການພິສູດຢືນຢັນ, ການປ້ອງກັນການໂຈມຕີ DoS, ການຈໍາກັດຄວາມໄວ) ແລະອື່ນໆອີກ.

NSX Edge ສະຫນອງການສະຫນັບສະຫນູນສໍາລັບສອງຮູບແບບການປະຕິບັດການດຸ່ນດ່ຽງການໂຫຼດ:

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

ນີ້ແມ່ນວິທີທີ່ມັນໄປ:
1. ຜູ້ໃຊ້ສົ່ງຄໍາຮ້ອງຂໍໄປຫາທີ່ຢູ່ VIP (ທີ່ຢູ່ Balancer) ທີ່ຖືກຕັ້ງຄ່າໃນ Edge.
2. Edge ເລືອກຫນຶ່ງຂອງ backends ແລະດໍາເນີນການ NAT ຈຸດຫມາຍປາຍທາງ, ທົດແທນທີ່ຢູ່ VIP ກັບທີ່ຢູ່ຂອງ backend ທີ່ເລືອກ.
3. Edge ປະຕິບັດ NAT ແຫຼ່ງ, ທົດແທນທີ່ຢູ່ຂອງຜູ້ໃຊ້ທີ່ສົ່ງຄໍາຮ້ອງຂໍດ້ວຍຕົວຂອງມັນເອງ.
4. ຊຸດດັ່ງກ່າວຖືກສົ່ງໄປຫາ backend ທີ່ເລືອກ.
5. backend ບໍ່ໄດ້ຕອບສະຫນອງໂດຍກົງກັບຜູ້ໃຊ້, ແຕ່ກັບ Edge, ເນື່ອງຈາກວ່າທີ່ຢູ່ຕົ້ນສະບັບຂອງຜູ້ໃຊ້ໄດ້ຖືກປ່ຽນເປັນທີ່ຢູ່ຂອງ balancer.
6. Edge ສົ່ງການຕອບສະຫນອງຂອງເຄື່ອງແມ່ຂ່າຍກັບຜູ້ໃຊ້.
ແຜນວາດແມ່ນຂ້າງລຸ່ມນີ້.


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

ກົນ​ໄກ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
1. ຜູ້ໃຊ້ສົ່ງຄໍາຮ້ອງຂໍໄປຫາທີ່ຢູ່ VIP (ທີ່ຢູ່ Balancer) ທີ່ຖືກຕັ້ງຄ່າໃນ Edge.
2. Edge ເລືອກຫນຶ່ງຂອງ backends ແລະດໍາເນີນການ NAT ຈຸດຫມາຍປາຍທາງ, ທົດແທນທີ່ຢູ່ VIP ກັບທີ່ຢູ່ຂອງ backend ທີ່ເລືອກ.
3. ຊຸດດັ່ງກ່າວຖືກສົ່ງໄປຫາ backend ທີ່ເລືອກ.
4. backend ໄດ້ຮັບການຮ້ອງຂໍກັບທີ່ຢູ່ຕົ້ນສະບັບຂອງຜູ້ໃຊ້ (ແຫຼ່ງ NAT ບໍ່ໄດ້ດໍາເນີນການ) ແລະຕອບສະຫນອງໂດຍກົງກັບມັນ.
5. ການຈະລາຈອນຖືກຍອມຮັບອີກເທື່ອຫນຶ່ງໂດຍຕົວດຸ່ນດ່ຽງການໂຫຼດ, ນັບຕັ້ງແຕ່ໃນລະບົບ inline ມັນມັກຈະເຮັດຫນ້າທີ່ເປັນປະຕູເລີ່ມຕົ້ນສໍາລັບການກະສິກໍາເຊີຟເວີ.
6. Edge ປະຕິບັດ NAT ແຫຼ່ງເພື່ອສົ່ງການຈະລາຈອນໄປຫາຜູ້ໃຊ້, ການນໍາໃຊ້ VIP ຂອງຕົນເປັນທີ່ຢູ່ IP ແຫຼ່ງ.
ແຜນວາດແມ່ນຂ້າງລຸ່ມນີ້.

ການປະຕິບັດ

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

ການສ້າງໃບຢັ້ງຢືນ SSL ທີ່ຈະໃຊ້ໂດຍ NSX Edge
ທ່ານສາມາດນໍາເຂົ້າໃບຢັ້ງຢືນ CA ທີ່ຖືກຕ້ອງຫຼືໃຊ້ໃບຮັບຮອງທີ່ເຊັນດ້ວຍຕົນເອງ. ສໍາລັບການທົດສອບນີ້, ຂ້ອຍຈະໃຊ້ການເຊັນດ້ວຍຕົນເອງ.

1. ໃນການໂຕ້ຕອບ vCloud Director, ໄປທີ່ການຕັ້ງຄ່າບໍລິການ Edge.
   
2. ໄປທີ່ແຖບໃບຢັ້ງຢືນ. ຈາກບັນຊີລາຍຊື່ຂອງການປະຕິບັດ, ເລືອກການເພີ່ມ CSR ໃຫມ່.
   
3. ຕື່ມຂໍ້ມູນໃສ່ໃນຊ່ອງຂໍ້ມູນທີ່ຕ້ອງການແລະກົດ Keep.
   
4. ເລືອກ CSR ທີ່ສ້າງໃຫມ່ແລະເລືອກທາງເລືອກ CSR ທີ່ເຊັນດ້ວຍຕົນເອງ.
   
5. ເລືອກໄລຍະເວລາທີ່ຖືກຕ້ອງຂອງໃບຢັ້ງຢືນ ແລະຄລິກ Keep
   
6. ໃບຢັ້ງຢືນການເຊັນດ້ວຍຕົນເອງຈະປາກົດຢູ່ໃນບັນຊີລາຍຊື່ຂອງໃບຮັບຮອງທີ່ມີຢູ່.
   

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

1. ໄປທີ່ແຖບ Load Balancer ແລະເປີດໃຊ້ຕົວດຸ່ນດ່ຽງ. ຕົວເລືອກທີ່ເປີດໃຊ້ການເລັ່ງຢູ່ບ່ອນນີ້ເຮັດໃຫ້ຜູ້ດຸ່ນດ່ຽງໃຊ້ການດຸ່ນດ່ຽງ L4 ທີ່ໄວຂຶ້ນແທນ L7.
   
2. ໄປທີ່ແຖບໂປຣໄຟລ໌ແອັບພລິເຄຊັນເພື່ອຕັ້ງຄ່າໂປຣໄຟລ໌ແອັບພລິເຄຊັນ. ກົດ +.
   
3. ຕັ້ງຊື່ຂອງໂປຣໄຟລ໌ແລະເລືອກປະເພດຂອງການຈະລາຈອນທີ່ໂປຣໄຟລ໌ຈະຖືກນໍາໃຊ້. ໃຫ້ຂ້ອຍອະທິບາຍບາງພາລາມິເຕີ.
   Persistence – ເກັບຮັກສາ ແລະຕິດຕາມຂໍ້ມູນເຊສຊັນ, ຕົວຢ່າງ: ເຊີບເວີສະເພາະໃດນຶ່ງໃນສະນຸກເກີທີ່ໃຫ້ບໍລິການຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້. ນີ້ຮັບປະກັນວ່າຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ຖືກສົ່ງໄປຫາສະມາຊິກກຸ່ມດຽວກັນຕະຫຼອດຊີວິດຂອງເຊດຊັນຫຼືເຊດຊັນຕໍ່ໄປ.
   ເປີດໃຊ້ SSL passthrough – ເມື່ອຕົວເລືອກນີ້ຖືກເລືອກ, NSX Edge ຢຸດການຢຸດ SSL. ແທນທີ່ຈະ, ການຢຸດເຊົາເກີດຂຶ້ນໂດຍກົງໃນເຄື່ອງແມ່ຂ່າຍທີ່ກໍາລັງຖືກດຸ່ນດ່ຽງ.
   ໃສ່ສ່ວນຫົວ X-Forwarded-For HTTP – ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດທີ່ຢູ່ IP ແຫຼ່ງຂອງລູກຄ້າທີ່ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ໂດຍຜ່ານຕົວດຸ່ນດ່ຽງການໂຫຼດ.
   ເປີດໃຊ້ Pool Side SSL – ອະນຸຍາດໃຫ້ທ່ານລະບຸວ່າສະນຸກເກີທີ່ເລືອກປະກອບດ້ວຍເຄື່ອງແມ່ຂ່າຍ HTTPS.
   
4. ເນື່ອງຈາກຂ້ອຍຈະດຸ່ນດ່ຽງການຈະລາຈອນ HTTPS, ຂ້ອຍຈໍາເປັນຕ້ອງເປີດໃຊ້ Pool Side SSL ແລະເລືອກໃບຢັ້ງຢືນທີ່ສ້າງຂຶ້ນໃນເມື່ອກ່ອນໃນ Virtual Server Certificate -> ແຖບໃບຢັ້ງຢືນການບໍລິການ.
   
5. ເຊັ່ນດຽວກັນສໍາລັບ Pool Certificate -> ໃບຢັ້ງຢືນການບໍລິການ.
   

ພວກເຮົາສ້າງສະນຸກເກີຂອງເຄື່ອງແມ່ຂ່າຍ, ການຈະລາຈອນທີ່ຈະເປັນ Pools ດຸ່ນດ່ຽງ

1. ໄປທີ່ແຖບສະນຸກເກີ. ກົດ +.
   
2. ພວກເຮົາຕັ້ງຊື່ຂອງສະນຸກເກີ, ເລືອກ algorithm (ຂ້ອຍຈະໃຊ້ round robin) ແລະປະເພດຂອງການຕິດຕາມສໍາລັບ backend ການກວດສອບສຸຂະພາບ. ຕົວເລືອກໂປ່ງໃສຊີ້ບອກວ່າ IPs ຕົ້ນສະບັບຂອງລູກຄ້າສາມາດເບິ່ງເຫັນກັບເຄື່ອງແມ່ຂ່າຍພາຍໃນຫຼືບໍ່.
   • ຖ້າທາງເລືອກຖືກປິດໃຊ້ງານ, ການຈະລາຈອນສໍາລັບເຄື່ອງແມ່ຂ່າຍພາຍໃນແມ່ນມາຈາກ IP ແຫຼ່ງຂອງ balancer.
   • ຖ້າຕົວເລືອກຖືກເປີດໃຊ້, ເຄື່ອງແມ່ຂ່າຍພາຍໃນຈະເບິ່ງ IP ແຫຼ່ງຂອງລູກຄ້າ. ໃນການຕັ້ງຄ່ານີ້, NSX Edge ຕ້ອງເຮັດໜ້າທີ່ເປັນປະຕູເລີ່ມຕົ້ນເພື່ອຮັບປະກັນວ່າແພັກເກັດທີ່ສົ່ງຄືນຜ່ານ NSX Edge.

   NSX ສະຫນັບສະຫນູນລະບົບການດຸ່ນດ່ຽງດັ່ງຕໍ່ໄປນີ້:

   • IP_HASH - ການເລືອກເຊີບເວີໂດຍອີງໃສ່ຜົນໄດ້ຮັບຂອງຟັງຊັນ hash ສໍາລັບ IP ແຫຼ່ງແລະປາຍທາງຂອງແຕ່ລະແພັກເກັດ.
   • ໜ້ອຍສຸດຄອນ - ການດຸ່ນດ່ຽງການເຊື່ອມຕໍ່ຂາເຂົ້າ, ຂຶ້ນກັບຈໍານວນທີ່ມີຢູ່ໃນເຄື່ອງແມ່ຂ່າຍສະເພາະ. ການເຊື່ອມຕໍ່ໃຫມ່ຈະຖືກນໍາໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ມີການເຊື່ອມຕໍ່ຫນ້ອຍທີ່ສຸດ.
   • ROUND_ROBIN - ການ​ເຊື່ອມ​ຕໍ່​ໃຫມ່​ຖືກ​ສົ່ງ​ໄປ​ຫາ​ແຕ່​ລະ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ໃນ​ການ​ເຮັດ​ໃຫ້​ສອດ​ຄ່ອງ​ກັບ​ນ​້​ໍ​າ​ທີ່​ໄດ້​ຮັບ​ມອບ​ຫມາຍ​ໃຫ້​ມັນ​.
   • URI - ສ່ວນຊ້າຍຂອງ URI (ກ່ອນເຄື່ອງໝາຍຄໍາຖາມ) ຖືກຕັດ ແລະແບ່ງດ້ວຍນ້ຳໜັກທັງໝົດຂອງເຊີບເວີໃນສະນຸກເກີ. ຜົນໄດ້ຮັບຊີ້ໃຫ້ເຫັນວ່າເຄື່ອງແມ່ຂ່າຍໃດທີ່ໄດ້ຮັບຄໍາຮ້ອງຂໍ, ໃຫ້ແນ່ໃຈວ່າການຮ້ອງຂໍຖືກສົ່ງກັບເຄື່ອງແມ່ຂ່າຍດຽວກັນຕະຫຼອດເວລາ, ຕາບໃດທີ່ເຄື່ອງແມ່ຂ່າຍທັງຫມົດຍັງມີຢູ່.
   • HTTPHEADER - ການດຸ່ນດ່ຽງໂດຍອີງໃສ່ສ່ວນຫົວ HTTP ສະເພາະ, ເຊິ່ງສາມາດຖືກກໍານົດເປັນພາລາມິເຕີ. ຖ້າສ່ວນຫົວຂາດຫາຍໄປ ຫຼືບໍ່ມີຄ່າໃດໆ, ລະບົບໃຊ້ລະບົບ ROUND_ROBIN algorithm.
   • URL - ແຕ່ລະຄໍາຮ້ອງຂໍ HTTP GET ຄົ້ນຫາພາລາມິເຕີ URL ທີ່ລະບຸໄວ້ເປັນການໂຕ້ຖຽງ. ຖ້າພາລາມິເຕີຖືກຕິດຕາມດ້ວຍເຄື່ອງຫມາຍເທົ່າທຽມກັນແລະຄ່າ, ຫຼັງຈາກນັ້ນຄ່າຈະຖືກ hash ແລະແບ່ງອອກດ້ວຍນ້ໍາຫນັກທັງຫມົດຂອງເຄື່ອງແມ່ຂ່າຍທີ່ເຮັດວຽກ. ຜົນໄດ້ຮັບຊີ້ໃຫ້ເຫັນວ່າເຄື່ອງແມ່ຂ່າຍໃດໄດ້ຮັບການຮ້ອງຂໍ. ຂະບວນການນີ້ຖືກນໍາໃຊ້ເພື່ອຕິດຕາມ ID ຜູ້ໃຊ້ໃນການຮ້ອງຂໍແລະໃຫ້ແນ່ໃຈວ່າ ID ຜູ້ໃຊ້ດຽວກັນຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍດຽວກັນຢູ່ສະເຫມີ, ຕາບໃດທີ່ເຄື່ອງແມ່ຂ່າຍທັງຫມົດຍັງຄົງມີຢູ່.

   

3. ໃນບລັອກສະມາຊິກ, ຄລິກ + ເພື່ອເພີ່ມເຊີບເວີໃສ່ສະນຸກເກີ.
   
   
   ໃນທີ່ນີ້ທ່ານຕ້ອງການຊີ້ບອກ:
   • ຊື່ເຊີບເວີ;
   • ທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍ;
   • ພອດທີ່ເຄື່ອງແມ່ຂ່າຍຈະໄດ້ຮັບການຈະລາຈອນ;
   • port for health check (Monitor healthcheck);
   • ນ​້​ໍາ​ຫນັກ – ການ​ນໍາ​ໃຊ້​ຕົວ​ກໍາ​ນົດ​ການ​ນີ້​ທ່ານ​ສາ​ມາດ​ປັບ​ຈໍາ​ນວນ​ອັດ​ຕາ​ສ່ວນ​ຂອງ​ການ​ຈະ​ລາ​ຈອນ​ທີ່​ໄດ້​ຮັບ​ສໍາ​ລັບ​ສະ​ມາ​ຊິກ​ສະ​ນຸກ​ເກີ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​;
   • ການເຊື່ອມຕໍ່ສູງສຸດ – ຈໍານວນສູງສຸດຂອງການເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ;
   • ການເຊື່ອມຕໍ່ຂັ້ນຕ່ໍາ – ຈໍານວນການເຊື່ອມຕໍ່ຕໍາ່ສຸດທີ່ເຊີບເວີຕ້ອງປະມວນຜົນກ່ອນທີ່ຈະສົ່ງຕໍ່ໄປຫາສະມາຊິກກຸ່ມຕໍ່ໄປ.

   
   
   ນີ້ແມ່ນສິ່ງທີ່ສະນຸກເກີສຸດທ້າຍຂອງສາມເຄື່ອງແມ່ຂ່າຍເບິ່ງຄືວ່າ.
   

ເພີ່ມເຊີບເວີ Virtual

1. ໄປທີ່ແຖບ Virtual Servers. ກົດ +.
   
2. ພວກເຮົາເປີດໃຊ້ເຊີບເວີສະເໝືອນໂດຍໃຊ້ເປີດໃຊ້ເຊີບເວີ Virtual.
   ພວກເຮົາຕັ້ງຊື່ໃຫ້ມັນ, ເລືອກໂປຣໄຟລ໌ແອັບພລິເຄຊັນທີ່ສ້າງຂຶ້ນກ່ອນໜ້ານີ້, ສະນຸກເກີ ແລະຊີ້ບອກທີ່ຢູ່ IP ທີ່ເຊີບເວີ Virtual ຈະໄດ້ຮັບການຮ້ອງຂໍຈາກພາຍນອກ. ພວກເຮົາລະບຸໂປໂຕຄອນ HTTPS ແລະພອດ 443.
   ຕົວກໍານົດການທາງເລືອກທີ່ນີ້:
   ຈຳກັດການເຊື່ອມຕໍ່ - ຈໍານວນສູງສຸດຂອງການເຊື່ອມຕໍ່ພ້ອມກັນທີ່ເຄື່ອງແມ່ຂ່າຍ virtual ສາມາດປະມວນຜົນ;
   ຈຳກັດອັດຕາການເຊື່ອມຕໍ່ (CPS) - ຈໍາ​ນວນ​ສູງ​ສຸດ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ເຂົ້າ​ມາ​ໃຫມ່​ຕໍ່​ວິ​ນາ​ທີ​.
   

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


ຫຼັງຈາກໂຫຼດໜ້ານີ້ຄືນໃໝ່, ການຮ້ອງຂໍຈະຖືກປະມວນຜົນໂດຍເຊີບເວີຕໍ່ໄປນີ້:


ແລະອີກເທື່ອຫນຶ່ງ - ເພື່ອກວດເບິ່ງເຄື່ອງແມ່ຂ່າຍທີສາມຈາກສະນຸກເກີ:


ເມື່ອກວດເບິ່ງ, ທ່ານສາມາດເຫັນໄດ້ວ່າໃບຢັ້ງຢືນທີ່ Edge ສົ່ງໃຫ້ພວກເຮົາແມ່ນອັນດຽວກັນທີ່ພວກເຮົາສ້າງໃນຕອນເລີ່ມຕົ້ນ.

ກຳລັງກວດສອບສະຖານະຜູ້ດຸ່ນດ່ຽງຈາກ Edge gateway console. ເພື່ອເຮັດສິ່ງນີ້, ເຂົ້າ ສະແດງບໍລິການ loadbalancer pool.


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

• ຈໍ TCP,
• ຈໍ HTTP,
• HTTPS-ຕິດຕາມກວດກາ.

ມາສ້າງອັນໃໝ່.

1. ໄປທີ່ແຖບການຕິດຕາມການບໍລິການ, ຄລິກ +.
   
2. ເລືອກ:
   • ຊື່ສໍາລັບວິທີການໃຫມ່;
   • ຊ່ວງເວລາທີ່ການຮ້ອງຂໍຈະຖືກສົ່ງ,
   • ໝົດເວລາລໍຖ້າຄຳຕອບ,
   • ປະເພດການຕິດຕາມ – ການຮ້ອງຂໍ HTTPS ໂດຍໃຊ້ວິທີ GET, ລະຫັດສະຖານະທີ່ຄາດໄວ້ – 200(OK) ແລະ URL ຮ້ອງຂໍ.
3. ອັນນີ້ເຮັດສຳເລັດການຕິດຕັ້ງ Service Monitor ໃໝ່; ດຽວນີ້ພວກເຮົາສາມາດໃຊ້ມັນໄດ້ເມື່ອສ້າງກຸ່ມ.
   

ການຕັ້ງຄ່າກົດລະບຽບການສະຫມັກ

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

1. ເພື່ອສ້າງກົດລະບຽບ, ໄປທີ່ແຖບ Application Rules ຂອງ Balancer.
   
2. ເລືອກຊື່, script ທີ່ຈະໃຊ້ກົດລະບຽບ, ແລະຄລິກ Keep.
   
3. ຫຼັງຈາກກົດລະບຽບຖືກສ້າງຂື້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງແກ້ໄຂ Virtual Server ທີ່ກໍານົດໄວ້ແລ້ວ.
   
4. ໃນແຖບຂັ້ນສູງ, ເພີ່ມກົດລະບຽບທີ່ພວກເຮົາສ້າງ.
   

ໃນຕົວຢ່າງຂ້າງເທິງພວກເຮົາໄດ້ເປີດໃຊ້ການສະຫນັບສະຫນູນ tlsv1.

ຕົວຢ່າງອີກສອງສາມຢ່າງ:

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

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


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

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

ຕົວຢ່າງເພີ່ມເຕີມ ທີ່ນີ້.

ນັ້ນແມ່ນທັງຫມົດສໍາລັບຂ້ອຍກ່ຽວກັບການດຸ່ນດ່ຽງ. ຖ້າທ່ານມີຄໍາຖາມໃດໆ, ຖາມ, ຂ້ອຍພ້ອມທີ່ຈະຕອບ.

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