Tupperware: Facebook's Kubernetes killer?

ການ​ຄຸ້ມ​ຄອງ​ປະ​ສິດ​ທິ​ພາບ​ແລະ​ເຊື່ອ​ຖື​ໄດ້​ຂອງ​ກຸ່ມ​ໃນ​ຂະ​ຫນາດ​ໃດ​ຫນຶ່ງ​ທີ່​ມີ Tupperware​

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

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

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

ຖາປັດຕະຍະ Tupperware

ສະຖາປັດຕະຍະກຳ Tupperware PRN ແມ່ນໜຶ່ງໃນພາກພື້ນຂອງສູນຂໍ້ມູນຂອງພວກເຮົາ. ພາກພື້ນປະກອບດ້ວຍອາຄານສູນຂໍ້ມູນຫຼາຍແຫ່ງ (PRN1 ແລະ PRN2) ທີ່ຕັ້ງຢູ່ໃກ້ໆ. ພວກເຮົາວາງແຜນທີ່ຈະສ້າງແຜງຄວບຄຸມຫນຶ່ງທີ່ຈະຈັດການເຄື່ອງແມ່ຂ່າຍທັງຫມົດໃນພາກພື້ນດຽວ.

ຜູ້ພັດທະນາແອັບພລິເຄຊັນໃຫ້ບໍລິການໃນຮູບແບບຂອງວຽກ Tupperware. ວຽກໃດໜຶ່ງປະກອບດ້ວຍຫຼາຍກ່ອງບັນຈຸ, ແລະພວກມັນທັງໝົດປົກກະຕິໃຊ້ລະຫັດແອັບພລິເຄຊັນດຽວກັນ.

Tupperware ແມ່ນຮັບຜິດຊອບໃນການສະຫນອງບັນຈຸແລະການຄຸ້ມຄອງວົງຈອນຊີວິດຂອງເຂົາເຈົ້າ. ມັນ​ປະ​ກອບ​ດ້ວຍ​ຫຼາຍ​ອົງ​ປະ​ກອບ​:

• Tupperware frontend ໃຫ້ APIs ສໍາລັບການໂຕ້ຕອບຜູ້ໃຊ້, CLI, ແລະເຄື່ອງມືອັດຕະໂນມັດອື່ນໆໂດຍຜ່ານທີ່ທ່ານສາມາດພົວພັນກັບ Tupperware. ພວກເຂົາເຈົ້າເຊື່ອງໂຄງສ້າງພາຍໃນທັງຫມົດຈາກເຈົ້າຂອງວຽກ Tupperware.
• Tupperware Scheduler ແມ່ນແຜງຄວບຄຸມທີ່ຮັບຜິດຊອບໃນການຄຸ້ມຄອງບັນຈຸແລະວົງຈອນຊີວິດຂອງວຽກ. ມັນຖືກນໍາໃຊ້ໃນລະດັບພາກພື້ນແລະທົ່ວໂລກ, ບ່ອນທີ່ຜູ້ຈັດຕາຕະລາງພາກພື້ນຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍໃນພາກພື້ນຫນຶ່ງແລະຜູ້ຈັດຕາຕະລາງທົ່ວໂລກຈະຈັດການເຄື່ອງແມ່ຂ່າຍຈາກພາກພື້ນຕ່າງໆ. ຜູ້ຈັດຕາຕະລາງແບ່ງອອກເປັນ shards, ແລະແຕ່ລະ shard ຄຸ້ມຄອງຊຸດຂອງວຽກ.
• Tupperware's Scheduler Proxy ເຊື່ອງ sharding ພາຍໃນແລະສະຫນອງແກ້ວດຽວທີ່ສະດວກສໍາລັບຜູ້ໃຊ້ Tupperware.
• ຜູ້ຈັດສັນ Tupperware ມອບກ່ອງບັນຈຸໃຫ້ກັບເຊີບເວີ. ຕົວກໍານົດເວລາຈັດການການຢຸດເຊົາ, ການເລີ່ມຕົ້ນ, ການປັບປຸງ, ແລະການລົ້ມເຫຼວຂອງບັນຈຸ. ປະຈຸ​ບັນ, ຜູ້​ຈັດ​ສັນ​ຄົນ​ໜຶ່ງ​ສາມາດ​ຄຸ້ມ​ຄອງ​ເຂດ​ທັງ​ໝົດ​ໄດ້​ໂດຍ​ບໍ່​ມີ​ການ​ແບ່ງ​ອອກ​ເປັນ​ກຸ່ມ. (ໃຫ້ສັງເກດຄວາມແຕກຕ່າງຂອງຄໍາສັບ. ຕົວຢ່າງ, ຕົວກໍານົດເວລາໃນ Tupperware ກົງກັບແຜງຄວບຄຸມໃນ. Kubernetes, ແລະຜູ້ຈັດສັນ Tupperware ເອີ້ນວ່າຕົວກໍານົດເວລາໃນ Kubernetes.)
• ນາຍຫນ້າຊັບພະຍາກອນເກັບຮັກສາແຫຼ່ງຄວາມຈິງສໍາລັບເຫດການຂອງເຄື່ອງແມ່ຂ່າຍແລະການບໍລິການ. ພວກເຮົາດໍາເນີນການຫນຶ່ງນາຍຫນ້າຊັບພະຍາກອນສໍາລັບແຕ່ລະສູນຂໍ້ມູນ, ແລະມັນເກັບຮັກສາຂໍ້ມູນທັງຫມົດກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍໃນສູນຂໍ້ມູນນັ້ນ. ນາຍຫນ້າຊັບພະຍາກອນແລະລະບົບການຄຸ້ມຄອງຄວາມອາດສາມາດ, ຫຼືລະບົບການສະຫນອງຊັບພະຍາກອນ, ການຕັດສິນໃຈແບບໄດນາມິກທີ່ກໍານົດເວລາການຈັດສົ່ງທີ່ຄວບຄຸມເຄື່ອງແມ່ຂ່າຍໃດ. ບໍລິການກວດສຸຂະພາບຕິດຕາມເຄື່ອງແມ່ຂ່າຍແລະເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບສຸຂະພາບຂອງເຂົາເຈົ້າຢູ່ໃນນາຍຫນ້າຊັບພະຍາກອນ. ຖ້າເຄື່ອງແມ່ຂ່າຍມີບັນຫາຫຼືຕ້ອງການການບໍາລຸງຮັກສາ, ນາຍຫນ້າຊັບພະຍາກອນບອກຜູ້ຈັດສັນແລະຜູ້ຈັດຕາຕະລາງໃຫ້ຢຸດເຊົາການບັນຈຸຫຼືຍ້າຍພວກມັນໄປຫາເຄື່ອງແມ່ຂ່າຍອື່ນ.
• ຕົວແທນ Tupperware ແມ່ນ daemon ເຮັດວຽກຢູ່ໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍທີ່ກະກຽມແລະເອົາບັນຈຸ. ແອັບພລິເຄຊັນເຮັດວຽກຢູ່ໃນກ່ອງບັນຈຸ, ເຊິ່ງເຮັດໃຫ້ພວກມັນໂດດດ່ຽວ ແລະສາມາດແຜ່ພັນໄດ້ຫຼາຍຂຶ້ນ. ສຸດ ກອງປະຊຸມ Systems @Scale ປີກາຍນີ້ ພວກ​ເຮົາ​ໄດ້​ອະ​ທິ​ບາຍ​ແລ້ວ​ວິ​ທີ​ການ​ບັນ​ຈຸ Tupperware ບຸກ​ຄົນ​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ໂດຍ​ນໍາ​ໃຊ້​ຮູບ​ພາບ​, btrfs​, cgroupv2 ແລະ systemd​.

ລັກສະນະທີ່ໂດດເດັ່ນຂອງ Tupperware

Tupperware ແມ່ນຄ້າຍຄືກັນໃນຫຼາຍວິທີກັບລະບົບການຈັດການກຸ່ມອື່ນໆເຊັ່ນ Kubernetes ແລະ ເມໂຊ, ແຕ່​ຍັງ​ມີ​ຄວາມ​ແຕກ​ຕ່າງ​ກັນ​:

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

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

ສະຫນັບສະຫນູນໃນຕົວສໍາລັບການບໍລິການຂອງລັດ.

Tupperware ດໍາເນີນການບໍລິການຂອງລັດທີ່ສໍາຄັນຫຼາກຫຼາຍຊະນິດທີ່ເກັບຮັກສາຂໍ້ມູນຜະລິດຕະພັນຢ່າງຕໍ່ເນື່ອງສໍາລັບ Facebook, Instagram, Messenger ແລະ WhatsApp. ເຫຼົ່ານີ້ອາດຈະເປັນຮ້ານຄ້າຂະຫນາດໃຫຍ່ຂອງຄູ່ຄີມູນຄ່າ (ເຊັ່ນ:. ZippyDB) ແລະ​ການ​ຕິດ​ຕາມ​ການ​ເກັບ​ຂໍ້​ມູນ (ຍົກ​ຕົວ​ຢ່າງ​, ODS Gorilla и Scuba). ການຮັກສາການບໍລິການຂອງລັດບໍ່ແມ່ນເລື່ອງງ່າຍ, ເພາະວ່າລະບົບຕ້ອງຮັບປະກັນວ່າການສະຫນອງຕູ້ຄອນເທນເນີສາມາດທົນທານຕໍ່ການຂັດຂວາງຂະຫນາດໃຫຍ່, ລວມທັງການປິດເຄືອຂ່າຍຫຼືໄຟຟ້າ. ແລະໃນຂະນະທີ່ເຕັກນິກແບບດັ້ງເດີມ, ເຊັ່ນການແຈກຢາຍຕູ້ຄອນເທນເນີໃນທົ່ວໂດເມນທີ່ຜິດ, ເຮັດວຽກໄດ້ດີສໍາລັບການບໍລິການທີ່ບໍ່ມີລັດ, ການບໍລິການຂອງລັດຕ້ອງການການສະຫນັບສະຫນູນເພີ່ມເຕີມ.

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

ການໂຕ້ຕອບ TaskControl ອະນຸຍາດໃຫ້ການບໍລິການຂອງລັດມີອິດທິພົນຕໍ່ການຕັດສິນໃຈທີ່ມີຜົນກະທົບຕໍ່ການມີຂໍ້ມູນ. ການນໍາໃຊ້ການໂຕ້ຕອບນີ້, ກໍານົດເວລາແຈ້ງເຕືອນຄໍາຮ້ອງສະຫມັກພາຍນອກກ່ຽວກັບການດໍາເນີນການບັນຈຸ (restart, ປັບປຸງ, ການເຄື່ອນຍ້າຍ, ບໍາລຸງຮັກສາ). ການບໍລິການຂອງລັດປະຕິບັດຕົວຄວບຄຸມທີ່ບອກ Tupperware ເມື່ອມັນປອດໄພໃນການປະຕິບັດແຕ່ລະອັນ, ແລະການດໍາເນີນການເຫຼົ່ານີ້ສາມາດແລກປ່ຽນຫຼືຊັກຊ້າຊົ່ວຄາວ. ໃນຕົວຢ່າງຂ້າງເທິງ, ຕົວຄວບຄຸມຖານຂໍ້ມູນສາມາດບອກ Tupperware ປັບປຸງ 49 ຂອງເຄື່ອງແມ່ຂ່າຍ 50, ແຕ່ປ່ອຍໃຫ້ເຄື່ອງແມ່ຂ່າຍສະເພາະ (X) ດຽວໃນປັດຈຸບັນ. ດັ່ງນັ້ນ, ຖ້າໄລຍະເວລາການປັບປຸງ kernel ຜ່ານໄປແລະຖານຂໍ້ມູນຍັງບໍ່ສາມາດຟື້ນຟູການຈໍາລອງທີ່ມີບັນຫາ, Tupperware ຈະຍັງປັບປຸງເຄື່ອງແມ່ຂ່າຍ X.

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

ການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍໃນສູນຂໍ້ມູນ

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

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

ສາມາດຂະຫຍາຍໄດ້ເພື່ອຮອງຮັບລະບົບທົ່ວໂລກທັງໝົດ

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

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

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

ປັບປຸງປະສິດທິພາບການນຳໃຊ້ດ້ວຍຄອມພິວເຕີ Elastic

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

• Elastic computing - ປັບຂະຫນາດການບໍລິການອອນໄລນ໌ໃນລະຫວ່າງຊົ່ວໂມງທີ່ງຽບສະຫງົບແລະໃຊ້ເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ເສຍຄ່າສໍາລັບການເຮັດວຽກແບບອອບໄລນ໌, ເຊັ່ນ: ການຮຽນຮູ້ເຄື່ອງຈັກແລະວຽກ MapReduce.
• Overloading - ວາງການບໍລິການອອນໄລນ໌ແລະ batch workloads ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນເພື່ອໃຫ້ batch workloads ເຮັດວຽກຢູ່ໃນບູລິມະສິດຕ່ໍາ.

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


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

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

ບົດຮຽນທີ່ຖອດຖອນໄດ້ແລະວາງແຜນສໍາລັບອະນາຄົດ

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

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

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

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