ເຄືອຂ່າຍທີ່ປິ່ນປົວຕົວມັນເອງ: ຄວາມມະຫັດສະຈັນຂອງ Flow Label ແລະນັກສືບທີ່ຢູ່ອ້ອມຮອບ Linux kernel. ບົດລາຍງານ Yandex

ສູນຂໍ້ມູນທີ່ທັນສະໄຫມມີຫຼາຍຮ້ອຍອຸປະກອນທີ່ມີການເຄື່ອນໄຫວທີ່ກວມເອົາໂດຍປະເພດຕ່າງໆຂອງການຕິດຕາມ. ແຕ່ເຖິງແມ່ນວ່າວິສະວະກອນທີ່ສົມບູນແບບທີ່ມີການກວດສອບທີ່ສົມບູນແບບຢູ່ໃນມືຈະສາມາດຕອບສະຫນອງຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍຢ່າງຖືກຕ້ອງໃນເວລາພຽງແຕ່ສອງສາມນາທີ. ໃນບົດລາຍງານໃນກອງປະຊຸມ Next Hop 2020, ຂ້າພະເຈົ້າໄດ້ນໍາສະເຫນີວິທີການອອກແບບເຄືອຂ່າຍສູນຂໍ້ມູນທີ່ມີຄຸນສົມບັດທີ່ເປັນເອກະລັກ - data center heals itself in milliseconds . ຫຼາຍທີ່ຊັດເຈນ, ວິສະວະກອນແກ້ໄຂບັນຫາຢ່າງສະຫງົບ, ໃນຂະນະທີ່ການບໍລິການພຽງແຕ່ບໍ່ສັງເກດເຫັນມັນ.

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


ສໍາລັບວິສະວະກອນເຄືອຂ່າຍຈໍານວນຫຼາຍ, ເຄືອຂ່າຍສູນຂໍ້ມູນເລີ່ມຕົ້ນ, ແນ່ນອນ, ດ້ວຍ ToR, ດ້ວຍປຸ່ມສະຫຼັບໃນ rack. ToR ປົກກະຕິແລ້ວມີສອງປະເພດຂອງການເຊື່ອມຕໍ່. ເດັກນ້ອຍໄປຫາເຄື່ອງແມ່ຂ່າຍ, ຄົນອື່ນ - ມີ N ຫຼາຍກວ່າຂອງພວກເຂົາ - ໄປຫາກະດູກສັນຫຼັງລະດັບທໍາອິດ, ນັ້ນແມ່ນ, ເຖິງການເຊື່ອມຕໍ່ຂອງມັນ. ປົກກະຕິແລ້ວ Uplinks ແມ່ນຖືວ່າເທົ່າທຽມກັນ, ແລະການຈະລາຈອນລະຫວ່າງ uplinks ແມ່ນມີຄວາມສົມດູນໂດຍອີງໃສ່ hash 5-tuple, ເຊິ່ງປະກອບມີ proto, src_ip, dst_ip, src_port, dst_port. ບໍ່ມີຄວາມແປກໃຈຢູ່ທີ່ນີ້.


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


ແລະມັນເປັນທີ່ຊັດເຈນວ່າ, ໃນທາງກົງກັນຂ້າມ, tori ແມ່ນເຊື່ອມຕໍ່ກັບກະດູກສັນຫຼັງທັງຫມົດຂອງລະດັບທໍາອິດ. ແມ່ນຫຍັງສຳຄັນຢູ່ໃນຮູບນີ້? ຖ້າພວກເຮົາມີການໂຕ້ຕອບພາຍໃນ rack, ແນ່ນອນ, ການໂຕ້ຕອບແມ່ນຜ່ານ ToR. ຖ້າການໂຕ້ຕອບເຂົ້າໄປໃນໂມດູນ, ຫຼັງຈາກນັ້ນການໂຕ້ຕອບຈະຜ່ານກະດູກສັນຫຼັງຂອງລະດັບທໍາອິດ. ຖ້າການໂຕ້ຕອບແມ່ນ intermodular - ດັ່ງທີ່ນີ້, ToR 1 ແລະ ToR 2 - ຫຼັງຈາກນັ້ນ, ການໂຕ້ຕອບຈະຜ່ານກະດູກສັນຫຼັງຂອງທັງສອງລະດັບທໍາອິດແລະທີສອງ.


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


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


ມີ 32 ຍົນ, ແຕ່ລະຍົນມີ 256 superspin. ດັ່ງນັ້ນ, ມັນປະກົດວ່າມີແປດເສັ້ນທາງພາຍໃນໂມດູນ, ແລະມີການໂຕ້ຕອບລະຫວ່າງໂມດູນມີ XNUMX ຂອງພວກເຂົາແລ້ວ.

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


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


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


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


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


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


ຈະເກີດຫຍັງຂຶ້ນຖ້າພວກເຮົາສູນເສຍແພັກເກດ 3? ໃນກໍລະນີນີ້, ຜູ້ຮັບຈະໄດ້ຮັບແພັກເກັດ 1, 2 ແລະ 4. ແລະລາວຈະແຈ້ງໃຫ້ຜູ້ສົ່ງຢ່າງຈະແຈ້ງໂດຍໃຊ້ຕົວເລືອກ SACK: "ເຈົ້າຮູ້, ສາມມາ, ແຕ່ກາງໄດ້ສູນເສຍ." ລາວເວົ້າວ່າ "Ack 2, SACK 4".


ຜູ້ສົ່ງໃນເວລານີ້ເຮັດຊ້ໍາແພັກເກັດທີ່ສູນເສຍໄປໂດຍບໍ່ມີບັນຫາໃດໆ.


ແຕ່ຖ້າຊຸດສຸດທ້າຍຢູ່ໃນປ່ອງຢ້ຽມແມ່ນສູນເສຍ, ສະຖານະການຈະເບິ່ງແຕກຕ່າງກັນຫຼາຍ.

ຜູ້ຮັບໄດ້ຮັບສາມຊອງທໍາອິດແລະທໍາອິດເລີ່ມລໍຖ້າ. ຂໍຂອບໃຈກັບການເພີ່ມປະສິດທິພາບບາງຢ່າງໃນ Linux kernel TCP stack, ມັນຈະລໍຖ້າຊຸດຄູ່, ເວັ້ນເສຍແຕ່ວ່າມີການຊີ້ບອກຢ່າງຊັດເຈນໃນທຸງວ່ານີ້ແມ່ນຊຸດສຸດທ້າຍຫຼືບາງສິ່ງບາງຢ່າງເຊັ່ນນັ້ນ. ມັນຈະລໍຖ້າຈົນກ່ວາການຫມົດເວລາ ACK ທີ່ຊັກຊ້າຈະຫມົດອາຍຸແລະຫຼັງຈາກນັ້ນສົ່ງການຮັບຮູ້ສໍາລັບສາມຊອງທໍາອິດ. ແຕ່ດຽວນີ້ຜູ້ສົ່ງຈະລໍຖ້າ. ລາວບໍ່ຮູ້ວ່າຊຸດທີສີ່ໄດ້ສູນເສຍຫຼື ກຳ ລັງຈະມາຮອດ. ແລະເພື່ອບໍ່ໃຫ້ overload ເຄືອຂ່າຍ, ມັນຈະພະຍາຍາມລໍຖ້າການຊີ້ບອກທີ່ຊັດເຈນວ່າແພັກເກັດສູນເສຍ, ຫຼືການຫມົດອາຍຸຂອງ RTO timeout.


ໝົດເວລາ RTO ແມ່ນຫຍັງ? ນີ້ແມ່ນສູງສຸດຈາກ RTT ທີ່ຄິດໄລ່ໂດຍ TCP stack ແລະບາງຄົງທີ່. ຄົງທີ່ອັນນີ້ແມ່ນຫຍັງ, ຕອນນີ້ພວກເຮົາຈະສົນທະນາກັນ.


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


ຕອນນີ້ໃຫ້ເບິ່ງວ່າພື້ນຖານນີ້ເທົ່າກັບຫຍັງ. ໂດຍຄ່າເລີ່ມຕົ້ນ, RTO ຕໍ່າສຸດແມ່ນ 200ms. ນີ້ແມ່ນ RTO ຕໍ່າສຸດສໍາລັບຊຸດຂໍ້ມູນ. ສໍາລັບແພັກເກັດ SYN, ມັນແຕກຕ່າງກັນ, 1 ວິນາທີ. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ເຖິງແມ່ນວ່າຄວາມພະຍາຍາມທໍາອິດທີ່ຈະສົ່ງແພັກເກັດຄືນໃຫມ່ຈະໃຊ້ເວລາ 100 ເວລາດົນກວ່າ RTT ພາຍໃນສູນຂໍ້ມູນ.


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


ແຕ່ຖ້າໂຊກບໍ່ດີເກີດຂື້ນ, ພວກເຮົາມີ RTO. ສິ່ງທີ່ສໍາຄັນຢູ່ທີ່ນີ້? ແມ່ນແລ້ວ, ພວກເຮົາມີເສັ້ນທາງຫຼາຍໃນເຄືອຂ່າຍ. ແຕ່ການຈາລະຈອນ TCP ຂອງການເຊື່ອມຕໍ່ TCP ໂດຍສະເພາະຫນຶ່ງຈະສືບຕໍ່ຜ່ານ stack ທີ່ແຕກຫັກດຽວກັນ. ການສູນເສຍແພັກເກັດ, ສະຫນອງໃຫ້ວ່າ magic X11 ຂອງພວກເຮົາບໍ່ອອກໄປດ້ວຍຕົວມັນເອງ, ບໍ່ໄດ້ນໍາໄປສູ່ການຈະລາຈອນທີ່ໄຫລໄປສູ່ພື້ນທີ່ທີ່ບໍ່ມີບັນຫາ. ພວກເຮົາກໍາລັງພະຍາຍາມຈັດສົ່ງຊຸດຜ່ານ stack ທີ່ແຕກຫັກດຽວກັນ. ນີ້ນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງ cascading: ສູນຂໍ້ມູນແມ່ນຊຸດຂອງຄໍາຮ້ອງສະຫມັກການໂຕ້ຕອບ, ແລະບາງສ່ວນຂອງການເຊື່ອມຕໍ່ TCP ຂອງຄໍາຮ້ອງສະຫມັກທັງຫມົດເຫຼົ່ານີ້ເລີ່ມຕົ້ນທີ່ຈະຊຸດໂຊມ - ເນື່ອງຈາກວ່າ superspin ຜົນກະທົບຕໍ່ຄໍາຮ້ອງສະຫມັກທັງຫມົດທີ່ຢູ່ໃນ DC. ດັ່ງ​ທີ່​ເວົ້າ​ວ່າ: ຖ້າ​ເຈົ້າ​ບໍ່​ເກີບ​ມ້າ, ມ້າ​ຂາ​ລົງ; ມ້າ limped - ບົດລາຍງານບໍ່ໄດ້ສົ່ງ; ຂໍ້ຄວາມບໍ່ໄດ້ຖືກສົ່ງ - ພວກເຂົາສູນເສຍສົງຄາມ. ພຽງແຕ່ໃນທີ່ນີ້ການນັບເປັນວິນາທີນັບຈາກເວລາທີ່ບັນຫາເກີດຂຶ້ນເຖິງຂັ້ນຕອນຂອງການເຊື່ອມໂຊມທີ່ການບໍລິການເລີ່ມມີຄວາມຮູ້ສຶກ. ນີ້ຫມາຍຄວາມວ່າຜູ້ໃຊ້ອາດຈະບໍ່ໄດ້ຮັບບາງສິ່ງບາງຢ່າງບາງບ່ອນ.


ມີສອງວິທີແກ້ໄຂຄລາສສິກທີ່ໃຫ້ສົມບູນເຊິ່ງກັນແລະກັນ. ທໍາອິດແມ່ນການບໍລິການທີ່ພະຍາຍາມວາງເຟືອງແລະແກ້ໄຂບັນຫາເຊັ່ນນີ້: "ໃຫ້ພວກເຮົາປັບບາງສິ່ງບາງຢ່າງໃນ TCP stack. ແລະໃຫ້ພວກເຮົາເຮັດການຫມົດເວລາລະດັບແອັບພລິເຄຊັນຫຼືກອງປະຊຸມ TCP ທີ່ມີຊີວິດຍາວດ້ວຍການກວດສຸຂະພາບພາຍໃນ. ບັນຫາແມ່ນວ່າການແກ້ໄຂດັ່ງກ່າວ: a) ບໍ່ຂະຫນາດທັງຫມົດ; b) ການທົດສອບບໍ່ດີຫຼາຍ. ນັ້ນແມ່ນ, ເຖິງແມ່ນວ່າການບໍລິການຈະຕັ້ງຄ່າ TCP stack ໂດຍບັງເອີນເພື່ອໃຫ້ມັນດີຂຶ້ນ, ກ່ອນອື່ນ ໝົດ, ນີ້ອາດຈະບໍ່ສາມາດໃຊ້ໄດ້ກັບທຸກແອັບພລິເຄຊັນແລະສູນຂໍ້ມູນທັງຫມົດ, ແລະອັນທີສອງ, ສ່ວນຫຼາຍອາດຈະ, ມັນຈະບໍ່ເຂົ້າໃຈສິ່ງທີ່ຖືກເຮັດຢ່າງຖືກຕ້ອງແລະແມ່ນຫຍັງ. ບໍ່. ນັ້ນແມ່ນ, ມັນເຮັດວຽກ, ແຕ່ມັນເຮັດວຽກບໍ່ດີແລະບໍ່ຂະຫນາດ. ແລະຖ້າມີບັນຫາເຄືອຂ່າຍ, ໃຜຈະຕໍານິຕິຕຽນ? ແນ່ນອນ NOC. NOC ເຮັດຫຍັງ?

ການບໍລິການຫຼາຍຄົນເຊື່ອວ່າໃນ NOC, ການເຮັດວຽກເປັນແບບນີ້. ແຕ່ເພື່ອຄວາມຊື່ສັດ, ບໍ່ພຽງແຕ່.


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


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

ແຕ່ມີ nuance ຢູ່ທີ່ນີ້. ເພື່ອເຂົ້າໃຈວ່າມັນແມ່ນຫຍັງ, ພວກເຮົາຈະຕ້ອງເບິ່ງວິທີການສ້າງສາຍນ້ໍາ.


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


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


ສິ່ງທີ່ສາມາດຊ່ວຍພວກເຮົາ? ບາງສ່ວນຂອງທ່ານໄດ້ຄາດເດົາແລ້ວຈາກຊື່ທີ່ພາກສະຫນາມທີ່ສໍາຄັນໃນເລື່ອງຕໍ່ໄປຂອງພວກເຮົາຈະເປັນພາກສະຫນາມຫົວຂໍ້ IPv6 flow label header. ແທ້ຈິງແລ້ວ, ນີ້ແມ່ນພາກສະຫນາມທີ່ປາກົດຢູ່ໃນ v6, ມັນບໍ່ແມ່ນຢູ່ໃນ v4, ມັນໃຊ້ເວລາ 20 bits, ແລະມີການໂຕ້ຖຽງກັນກ່ຽວກັບການນໍາໃຊ້ຂອງມັນເປັນເວລາດົນ. ນີ້ແມ່ນຫນ້າສົນໃຈຫຼາຍ - ມີການຂັດແຍ້ງ, ບາງສິ່ງບາງຢ່າງໄດ້ຖືກແກ້ໄຂຢູ່ໃນຂອບຂອງ RFC, ແລະໃນເວລາດຽວກັນ, ການປະຕິບັດໄດ້ປາກົດຢູ່ໃນ Linux kernel ທີ່ບໍ່ເຄີຍມີເອກະສານໃດໆ.


ຂ້ອຍຂໍແນະນໍາໃຫ້ເຈົ້າເຂົ້າຮ່ວມກັບຂ້ອຍໃນການສືບສວນເລັກນ້ອຍ. ລອງເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນໃນ kernel Linux ໃນສອງສາມປີຜ່ານມາ.

ປີ 2014. ວິສະວະກອນຈາກບໍລິສັດຂະຫນາດໃຫຍ່ແລະມີຊື່ສຽງເພີ່ມການເຮັດວຽກຂອງ Linux kernel ການເພິ່ງພາອາໄສມູນຄ່າຂອງປ້າຍຊື່ການໄຫຼໃສ່ hash ຂອງເຕົ້າຮັບ. ພວກເຂົາພະຍາຍາມແກ້ໄຂຫຍັງຢູ່ທີ່ນີ້? ນີ້ແມ່ນກ່ຽວຂ້ອງກັບ RFC 6438 ເຊິ່ງໄດ້ປຶກສາຫາລືກ່ຽວກັບບັນຫາຕໍ່ໄປນີ້. ພາຍໃນສູນຂໍ້ມູນ, IPv4 ມັກຈະຖືກຫຸ້ມຫໍ່ຢູ່ໃນຊຸດ IPv6, ເພາະວ່າໂຮງງານເອງແມ່ນ IPv6, ແຕ່ IPv4 ຈະຕ້ອງຖືກມອບໃຫ້ບາງຢ່າງ. ສໍາລັບເວລາດົນນານມີບັນຫາກັບສະຫວິດທີ່ບໍ່ສາມາດເບິ່ງພາຍໃຕ້ສອງຫົວ IP ເພື່ອໄປຫາ TCP ຫຼື UDP ແລະຊອກຫາ src_ports, dst_ports ຢູ່ທີ່ນັ້ນ. ມັນໄດ້ຫັນອອກວ່າ hash, ຖ້າທ່ານເບິ່ງສອງຫົວ IP ທໍາອິດ, ໄດ້ກາຍເປັນການແກ້ໄຂເກືອບທັງຫມົດ. ເພື່ອຫຼີກເວັ້ນການນີ້, ເພື່ອໃຫ້ການດຸ່ນດ່ຽງຂອງການຈະລາຈອນ encapsulated ນີ້ເຮັດວຽກຢ່າງຖືກຕ້ອງ, ມັນໄດ້ຖືກສະເຫນີໃຫ້ເພີ່ມ hash ຈາກ 5-tuple encapsulated packet ກັບມູນຄ່າຂອງພາກສະຫນາມປ້າຍຊື່ການໄຫຼ. ປະມານດຽວກັນໄດ້ຖືກເຮັດສໍາລັບໂຄງການ encapsulation ອື່ນໆ, ສໍາລັບ UDP, ສໍາລັບ GRE, ໃນສຸດທ້າຍພາກສະຫນາມ GRE Key ໄດ້ຖືກນໍາໃຊ້. ບໍ່​ທາງ​ໃດ​ທາງ​ຫນຶ່ງ, ເປົ້າ​ຫມາຍ​ຢູ່​ທີ່​ນີ້​ແມ່ນ​ຈະ​ແຈ້ງ. ແລະຢ່າງຫນ້ອຍໃນເວລານັ້ນ, ພວກເຂົາມີປະໂຫຍດ.

ໃນປີ 2015, patch ໃຫມ່ແມ່ນມາຈາກວິສະວະກອນທີ່ເຄົາລົບດຽວກັນ. ລາວແມ່ນຫນ້າສົນໃຈຫຼາຍ. ມັນບອກວ່າຕໍ່ໄປນີ້ - ພວກເຮົາຈະ Randomize hash ໃນກໍລະນີຂອງເຫດການເສັ້ນທາງລົບ. ເຫດການເສັ້ນທາງລົບແມ່ນຫຍັງ? ນີ້ແມ່ນ RTO ທີ່ພວກເຮົາສົນທະນາກ່ອນຫນ້ານີ້, ນັ້ນແມ່ນ, ການສູນເສຍຫາງຂອງປ່ອງຢ້ຽມແມ່ນເຫດການທີ່ເປັນທາງລົບແທ້ໆ. ແທ້ຈິງແລ້ວ, ມັນຂ້ອນຂ້າງຍາກທີ່ຈະຄາດເດົາວ່າມັນແມ່ນຫຍັງ.

2016, ບໍລິສັດທີ່ເຄົາລົບອື່ນ, ຍັງໃຫຍ່. ມັນ parses crutches ສຸດ​ທ້າຍ​ແລະ​ເຮັດ​ໃຫ້​ມັນ​ດັ່ງ​ນັ້ນ hash ທີ່​ພວກ​ເຮົາ​ໄດ້​ເຮັດ​ໃຫ້​ຜ່ານ​ມາ​ແບບ​ສຸ່ມ​ໃນ​ປັດ​ຈຸ​ບັນ​ມີ​ການ​ປ່ຽນ​ແປງ​ໃນ​ທຸກ SYN retransmit ແລະ​ຫຼັງ​ຈາກ​ທຸກ RTO timeout. ແລະໃນຈົດຫມາຍສະບັບນີ້, ຄັ້ງທໍາອິດແລະສຸດທ້າຍ, ເປົ້າຫມາຍສຸດທ້າຍສຽງ - ເພື່ອໃຫ້ແນ່ໃຈວ່າການຈະລາຈອນໃນກໍລະນີຂອງການສູນເສຍຫຼື overload ຂອງຊ່ອງທາງມີຄວາມເປັນໄປໄດ້ຂອງ rerouting ອ່ອນ, ການນໍາໃຊ້ເສັ້ນທາງຫຼາຍ. ແນ່ນອນ, ຫຼັງຈາກນັ້ນມີຫຼາຍສິ່ງພິມ, ທ່ານສາມາດຊອກຫາພວກມັນໄດ້ງ່າຍ.

ເຖິງແມ່ນວ່າບໍ່, ທ່ານບໍ່ສາມາດ, ເພາະວ່າຍັງບໍ່ທັນມີສິ່ງພິມດຽວກ່ຽວກັບຫົວຂໍ້ນີ້. ແຕ່ພວກເຮົາຮູ້!

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


ສິ່ງທີ່ໄດ້ເຮັດແລ້ວ, ຫນ້າທີ່ໃດທີ່ຖືກເພີ່ມເຂົ້າໃນ Linux kernel? Gesh ປ່ຽນເປັນຄ່າສຸ່ມຫຼັງຈາກແຕ່ລະເຫດການ RTO. ນີ້ແມ່ນຜົນເສັ້ນທາງລົບຄືກັນ. hash ຂື້ນກັບ a nosh ແລະປ້າຍ flow ຂຶ້ນກັບ skb hash. ມີການຄິດໄລ່ບາງຢ່າງກ່ຽວກັບຫນ້າທີ່ຢູ່ທີ່ນີ້, ລາຍລະອຽດທັງຫມົດບໍ່ສາມາດຖືກຈັດໃສ່ໃນສະໄລ້ດຽວ. ຖ້າໃຜຢາກຮູ້, ທ່ານສາມາດຜ່ານລະຫັດ kernel ແລະກວດເບິ່ງ.

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


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


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


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


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


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


eBPF ມາຊ່ວຍ. ເວົ້າງ່າຍໆ, ເຫຼົ່ານີ້ແມ່ນໂຄງການ C ຂະຫນາດນ້ອຍ, ພວກເຂົາສາມາດຖືກໃສ່ເຂົ້າໄປໃນ hooks ໃນສະຖານທີ່ຕ່າງໆໃນການປະຕິບັດຂອງ kernel stack ແລະ TCP stack, ເຊິ່ງທ່ານສາມາດປ່ຽນການຕັ້ງຄ່າຈໍານວນຫລາຍ. ໂດຍທົ່ວໄປ, eBPF ແມ່ນແນວໂນ້ມໃນໄລຍະຍາວ. ແທນທີ່ຈະ sawing ຫຼາຍສິບຕົວກໍານົດການ sysctl ໃຫມ່ແລະຂະຫຍາຍຜົນປະໂຫຍດ IP, ການເຄື່ອນໄຫວແມ່ນຢູ່ໃນທິດທາງຂອງ eBPF ແລະຂະຫຍາຍການເຮັດວຽກຂອງມັນ. ດ້ວຍ eBPF, ທ່ານສາມາດປ່ຽນການຄວບຄຸມຄວາມແອອັດ ແລະການຕັ້ງຄ່າ TCP ອື່ນໆແບບເຄື່ອນໄຫວໄດ້.


ແຕ່ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາວ່າດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນທ່ານສາມາດບິດຄ່າຂອງ SYN_RTO. ແລະມີຕົວຢ່າງທີ່ປະກາດສາທາລະນະ: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. ເຮັດຫຍັງແດ່ຢູ່ທີ່ນີ້? ຕົວຢ່າງແມ່ນເຮັດວຽກ, ແຕ່ໃນຕົວຂອງມັນເອງແມ່ນ rough ຫຼາຍ. ມັນສົມມຸດຢູ່ທີ່ນີ້ວ່າພາຍໃນສູນຂໍ້ມູນພວກເຮົາປຽບທຽບ 44 bits ທໍາອິດ, ຖ້າພວກເຂົາກົງກັນ, ຫຼັງຈາກນັ້ນພວກເຮົາຊອກຫາຕົວເຮົາເອງພາຍໃນ DC. ແລະໃນກໍລະນີນີ້, ພວກເຮົາປ່ຽນຄ່າຂອງ SYN_RTO timeout ເປັນ 4ms. ວຽກງານດຽວກັນສາມາດເຮັດໄດ້ຫຼາຍ gracefully. ແຕ່ຕົວຢ່າງທີ່ງ່າຍດາຍນີ້ສະແດງໃຫ້ເຫັນສິ່ງທີ່ເປັນ) ເປັນໄປໄດ້; b) ຂ້ອນຂ້າງງ່າຍ.

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


ສົມມຸດວ່າທ່ານມີບໍລິການຢູ່ໃນເຄືອຂ່າຍທີ່ອາໃສຢູ່ໃນ anycast. ແຕ່ຫນ້າເສຍດາຍ, ຂ້າພະເຈົ້າບໍ່ມີເວລາທີ່ຈະເຂົ້າໄປໃນລາຍລະອຽດກ່ຽວກັບ anycast, ແຕ່ມັນເປັນການບໍລິການແຈກຢາຍທີ່ເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍທີ່ແຕກຕ່າງກັນທີ່ມີຢູ່ໃນທີ່ຢູ່ IP ດຽວກັນ. ແລະນີ້ແມ່ນບັນຫາທີ່ເປັນໄປໄດ້: ເຫດການ RTO ສາມາດເກີດຂື້ນບໍ່ພຽງແຕ່ເມື່ອການຈະລາຈອນຜ່ານໂຮງງານ. ມັນຍັງສາມາດເກີດຂື້ນໄດ້ໃນລະດັບ ToR buffer: ເມື່ອເຫດການ incast ເກີດຂຶ້ນ, ມັນກໍ່ສາມາດເກີດຂື້ນກັບເຈົ້າພາບເມື່ອ host spills ບາງສິ່ງບາງຢ່າງ. ເມື່ອເຫດການ RTO ເກີດຂຶ້ນແລະມັນປ່ຽນປ້າຍການໄຫຼ. ໃນກໍລະນີນີ້, ການຈະລາຈອນອາດຈະໄປຫາຕົວຢ່າງອັນໃດອັນໜຶ່ງ. ສົມມຸດວ່າມັນເປັນອັນຄາສທ໌ທີ່ມີລັດ, ມັນມີສະຖານະການເຊື່ອມຕໍ່ - ມັນສາມາດເປັນ L3 Balancer ຫຼືບາງບໍລິການອື່ນໆ. ຫຼັງຈາກນັ້ນ, ບັນຫາເກີດຂື້ນ, ເພາະວ່າຫຼັງຈາກ RTO, ການເຊື່ອມຕໍ່ TCP ມາຮອດເຄື່ອງແມ່ຂ່າຍ, ເຊິ່ງບໍ່ຮູ້ຫຍັງກ່ຽວກັບການເຊື່ອມຕໍ່ TCP ນີ້. ແລະຖ້າພວກເຮົາບໍ່ມີການແບ່ງປັນຂອງລັດລະຫວ່າງເຄື່ອງແມ່ຂ່າຍໃດໆ, ຫຼັງຈາກນັ້ນການຈະລາຈອນດັ່ງກ່າວຈະຖືກຫຼຸດລົງແລະການເຊື່ອມຕໍ່ TCP ຈະແຕກ.


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

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


ເມື່ອພວກເຮົາເປີດປ້າຍຊື່ການໄຫຼເຂົ້າໃສ່ ToR, ກະກຽມ eBPF ຂອງຕົວແທນ, ເຊິ່ງປະຈຸບັນດໍາລົງຊີວິດຢູ່ໃນເຈົ້າພາບ, ພວກເຮົາຕັດສິນໃຈທີ່ຈະບໍ່ລໍຖ້າຄວາມລົ້ມເຫຼວອັນໃຫຍ່ຫຼວງຕໍ່ໄປ, ແຕ່ເພື່ອດໍາເນີນການລະເບີດທີ່ຄວບຄຸມ. ພວກເຮົາໄດ້ເອົາ ToR, ທີ່ມີສີ່ uplinks, ແລະໄດ້ຫຼຸດລົງກ່ຽວກັບຫນຶ່ງໃນນັ້ນ. ພວກເຂົາເຈົ້າໄດ້ແຕ້ມກົດລະບຽບ, ພວກເຂົາເຈົ້າເວົ້າວ່າ - ໃນປັດຈຸບັນທ່ານກໍາລັງສູນເສຍການຫຸ້ມຫໍ່ທັງຫມົດ. ດັ່ງທີ່ເຈົ້າເຫັນຢູ່ເບື້ອງຊ້າຍ, ພວກເຮົາມີການກວດສອບຕໍ່ຊຸດ, ເຊິ່ງໄດ້ຫຼຸດລົງເຖິງ 75%, ນັ້ນແມ່ນ 25% ຂອງແພັກເກັດຖືກສູນເສຍ. ຢູ່ເບື້ອງຂວາແມ່ນກາຟຂອງການບໍລິການທີ່ຢູ່ເບື້ອງຫຼັງ ToR ນີ້. ໃນຄວາມເປັນຈິງ, ເຫຼົ່ານີ້ແມ່ນຕາຕະລາງການຈະລາຈອນຂອງຂໍ້ຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍພາຍໃນ rack. ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ພວກມັນຈົມລົງຕ່ໍາກວ່າ. ເປັນຫຍັງພວກເຂົາຈົມລົງຕ່ໍາ - ບໍ່ແມ່ນ 25%, ແຕ່ໃນບາງກໍລະນີ 3-4 ເທື່ອ? ຖ້າການເຊື່ອມຕໍ່ TCP ໂຊກບໍ່ດີ, ມັນຍັງສືບຕໍ່ພະຍາຍາມເຂົ້າເຖິງໂດຍຜ່ານການໂຕ້ຕອບທີ່ແຕກຫັກ. ນີ້ແມ່ນຮ້າຍແຮງຂຶ້ນໂດຍພຶດຕິກໍາປົກກະຕິຂອງການບໍລິການພາຍໃນ DC - ສໍາລັບຫນຶ່ງຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້, ການຮ້ອງຂໍ N ກັບການບໍລິການພາຍໃນແມ່ນຖືກສ້າງຂຶ້ນ, ແລະການຕອບສະຫນອງຈະໄປຫາຜູ້ໃຊ້, ບໍ່ວ່າຈະໃນເວລາທີ່ແຫຼ່ງຂໍ້ມູນທັງຫມົດຕອບສະຫນອງ, ຫຼືເວລາທີ່ຫມົດເວລາຖືກກະຕຸ້ນຢູ່ທີ່ ລະດັບຄໍາຮ້ອງສະຫມັກ, ເຊິ່ງຍັງຕ້ອງໄດ້ຮັບການ configure. ນັ້ນແມ່ນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຫຼາຍ, ບໍ່ດີຫຼາຍ.


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

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

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

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

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

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