One-cloud - ລະດັບສູນຂໍ້ມູນ OS ໃນ Odnoklassniki

Aloha, ປະຊາຊົນ! ຂ້ອຍຊື່ Oleg Anastasyev, ຂ້ອຍເຮັດວຽກຢູ່ Odnoklassniki ໃນທີມງານຂອງເວທີ. ແລະນອກຈາກຂ້ອຍ, ມີຮາດແວຫຼາຍທີ່ເຮັດວຽກຢູ່ໃນ Odnoklassniki. ພວກເຮົາມີສີ່ສູນຂໍ້ມູນທີ່ມີປະມານ 500 racks ທີ່ມີຫຼາຍກວ່າ 8 ພັນເຄື່ອງແມ່ຂ່າຍ. ໃນຈຸດໃດຫນຶ່ງ, ພວກເຮົາຮັບຮູ້ວ່າການນໍາລະບົບການຄຸ້ມຄອງໃຫມ່ຈະຊ່ວຍໃຫ້ພວກເຮົາໂຫຼດອຸປະກອນທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ອໍານວຍຄວາມສະດວກໃນການຄຸ້ມຄອງການເຂົ້າເຖິງ, ອັດຕະໂນມັດການແຈກຢາຍຊັບພະຍາກອນຄອມພິວເຕີ້, ເລັ່ງການເປີດຕົວບໍລິການໃຫມ່, ແລະເລັ່ງການຕອບສະຫນອງ. ກັບ​ອຸ​ປະ​ຕິ​ເຫດ​ຂະ​ຫນາດ​ໃຫຍ່​.

ມັນມາຈາກຫຍັງ?

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

ການຮ້ອງຂໍຂອງຜູ້ໃຊ້ແມ່ນໄດ້ຮັບທັງສອງດ້ານຫນ້າຂອງປະຕູຕົ້ນຕໍ www.ok.ru, ແລະອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, ຢູ່ໃນຫນ້າ API ດົນຕີ. ເພື່ອປຸງແຕ່ງເຫດຜົນທາງທຸລະກິດ, ພວກເຂົາໂທຫາເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ, ເຊິ່ງ, ເມື່ອດໍາເນີນການຮ້ອງຂໍ, ໂທຫາ microservices ພິເສດທີ່ຈໍາເປັນ - one-graph (graph of social connection), user-cache (cache of user profile), ແລະອື່ນໆ.

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

ເປັນຫຍັງຄື? ວິທີການນີ້ມີຂໍ້ດີຫຼາຍ:

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

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

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

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

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

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

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

Очевидно, нужно запускать задачи либо в контейнерах, либо в виртуальных машинах. Поскольку практически все задачи у нас запускаются под управлением одной ОС (Linux) или адаптированы под неё, поддерживать множество различных операционных систем нам не требуется. Соответственно, виртуализация не нужна, из-за дополнительных накладных расходов она будет менее эффективна, чем контейнеризация.

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

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

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

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

ການແຈກຢາຍຕູ້ຄອນເທນເນີດ້ວຍຕົນເອງບໍ່ແມ່ນທາງເລືອກໃນເວລາທີ່ທ່ານມີ 8 ພັນເຄື່ອງແມ່ຂ່າຍແລະ 8-16 ພັນບັນຈຸ.

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

ແນ່ນອນ, ພວກເຮົາຕ້ອງການຊັ້ນຄວບຄຸມທີ່ຈະເຮັດສິ່ງນີ້ໂດຍອັດຕະໂນມັດ.

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

one-cloud masters ແມ່ນກຸ່ມ failover ທີ່ຮັບຜິດຊອບສໍາລັບ cloud orchestration. ນັກພັດທະນາສົ່ງ manifest ໄປຫາແມ່ບົດ, ເຊິ່ງປະກອບດ້ວຍຂໍ້ມູນທັງຫມົດທີ່ຈໍາເປັນໃນການເປັນເຈົ້າພາບການບໍລິການ. ອີງຕາມມັນ, ແມ່ບົດໃຫ້ຄໍາສັ່ງກັບ minions ທີ່ເລືອກ (ເຄື່ອງຈັກທີ່ອອກແບບມາເພື່ອແລ່ນພາຊະນະ). minions ມີຕົວແທນຂອງພວກເຮົາ, ເຊິ່ງໄດ້ຮັບຄໍາສັ່ງ, ອອກຄໍາສັ່ງຂອງມັນໃຫ້ກັບ Docker, ແລະ Docker ກໍານົດ linux kernel ເພື່ອເປີດຕົວ container ທີ່ສອດຄ້ອງກັນ. ນອກເຫນືອຈາກການປະຕິບັດຄໍາສັ່ງ, ຕົວແທນລາຍງານຢ່າງຕໍ່ເນື່ອງກັບແມ່ບົດກ່ຽວກັບການປ່ຽນແປງໃນສະພາບຂອງເຄື່ອງຈັກ minion ແລະເຄື່ອງບັນຈຸທີ່ແລ່ນຢູ່ເທິງມັນ.

ການຈັດສັນຊັບພະຍາກອນ

ຕອນນີ້ໃຫ້ເບິ່ງບັນຫາການຈັດສັນຊັບພະຍາກອນທີ່ຊັບຊ້ອນຫຼາຍສໍາລັບ minions ຫຼາຍ.

ຊັບພະຍາກອນຄອມພິວເຕີຢູ່ໃນຄລາວດຽວແມ່ນ:

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

ຫຼັງຈາກນັ້ນ, ສໍາລັບການບໍລິການບາງຢ່າງ, ສໍາລັບການຍົກຕົວຢ່າງສໍາລັບຜູ້ໃຊ້ - cache, ພວກເຮົາສາມາດບັນທຶກຊັບພະຍາກອນທີ່ບໍລິໂພກດ້ວຍວິທີນີ້: 400 ແກນໂປເຊດເຊີ, 2,5 TB ຂອງຫນ່ວຍຄວາມຈໍາ, ການຈະລາຈອນ 50 Gbit / s ໃນທັງສອງທິດທາງ, 6 TB ຂອງຊ່ອງ HDD ທີ່ຕັ້ງຢູ່ໃນ 100 spindles . ຫຼືໃນຮູບແບບທີ່ຄຸ້ນເຄີຍຫຼາຍກວ່ານີ້:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

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

ສິ່ງທີ່ຈັບຕາຂອງເຈົ້າ:

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

ມາແຕ້ມຮູບອີກຄັ້ງ:

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

ໂດຍການເອົາເສັ້ນເພີ່ມເຕີມ, ພວກເຮົາສາມາດຂຽນແຕ່ລະ node ຂອງຮູບຂອງພວກເຮົາໃນຮູບແບບ flatter: group1.web.front, api.music.front, user-cache.cache.

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

ຂໍໃຫ້ພິຈາລະນາເບິ່ງການບໍລິການເພີ່ມເຕີມ. ການບໍລິການມີຊື່ທີ່ມີຄຸນສົມບັດຄົບຖ້ວນ, ເຊິ່ງປະກອບດ້ວຍຊື່ຂອງແຖວຢູ່ສະເໝີ. ຫຼັງຈາກນັ້ນ, ການບໍລິການເວັບໄຊຕ໌ທາງຫນ້າຈະມີຊື່ ok-web.group1.web.front. ແລະບໍລິການເຊີບເວີແອັບພລິເຄຊັນທີ່ມັນເຂົ້າເຖິງຈະຖືກເອີ້ນ ok-app.group1.web.front. ແຕ່ລະບໍລິການມີ manifest, ເຊິ່ງລະບຸຂໍ້ມູນທີ່ຈໍາເປັນທັງຫມົດສໍາລັບການບັນຈຸເຂົ້າໃນເຄື່ອງຈັກສະເພາະ: ຈໍານວນຊັບພະຍາກອນທີ່ວຽກງານນີ້ບໍລິໂພກ, ການຕັ້ງຄ່າທີ່ຈໍາເປັນສໍາລັບມັນ, ຈໍານວນ replicas ຄວນມີ, ຄຸນສົມບັດສໍາລັບການຈັດການຄວາມລົ້ມເຫຼວຂອງການບໍລິການນີ້. ແລະຫຼັງຈາກການບໍລິການຖືກຈັດໃສ່ໂດຍກົງໃນເຄື່ອງຈັກ, ຕົວຢ່າງຂອງມັນປາກົດ. ພວກເຂົາຍັງຖືກຕັ້ງຊື່ຢ່າງບໍ່ຊັດເຈນ - ເປັນຕົວເລກຕົວຢ່າງແລະຊື່ບໍລິການ: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

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

ຕອນນີ້ໃຫ້ພິຈາລະນາເບິ່ງວ່າຕົວຢ່າງເຫຼົ່ານີ້ປະຕິບັດແນວໃດ: ວຽກງານ.

ຫ້ອງຮຽນການໂດດດ່ຽວໜ້າວຽກ

ວຽກງານທັງໝົດໃນ OK (ແລະ, ອາດຈະ, ຢູ່ທົ່ວທຸກແຫ່ງ) ສາມາດແບ່ງອອກເປັນກຸ່ມ:

• ວຽກງານການເລັ່ງລັດສັ້ນ - prod. ສໍາລັບວຽກງານແລະການບໍລິການດັ່ງກ່າວ, ການຊັກຊ້າການຕອບໂຕ້ (latency) ແມ່ນມີຄວາມສໍາຄັນຫຼາຍ, ແຕ່ລະຄໍາຮ້ອງຂໍຈະຖືກດໍາເນີນໂດຍລະບົບໄວເທົ່າໃດ. ຕົວຢ່າງຂອງໜ້າວຽກ: ໜ້າເວັບ, ແຄສ, ເຊີບເວີແອັບພລິເຄຊັນ, ການເກັບຮັກສາ OLTP, ແລະອື່ນໆ.
• ບັນຫາການຄິດໄລ່ - batch. ທີ່ນີ້, ຄວາມໄວການປຸງແຕ່ງຂອງແຕ່ລະຄໍາຮ້ອງຂໍສະເພາະແມ່ນບໍ່ສໍາຄັນ. ສໍາລັບພວກເຂົາ, ມັນເປັນສິ່ງສໍາຄັນວິທີການຄິດໄລ່ວຽກງານນີ້ຈະເຮັດໃນໄລຍະເວລາທີ່ແນ່ນອນ (ຍາວ) ຂອງເວລາ (ຜ່ານ). ເຫຼົ່ານີ້ຈະເປັນວຽກງານໃດໆຂອງ MapReduce, Hadoop, ການຮຽນຮູ້ເຄື່ອງຈັກ, ສະຖິຕິ.
• ວຽກງານພື້ນຫຼັງ - idle. ສໍາລັບວຽກງານດັ່ງກ່າວ, ບໍ່ວ່າເວລາ latency ຫຼື throughput ມີຄວາມສໍາຄັນຫຼາຍ. ນີ້ປະກອບມີການທົດສອບຕ່າງໆ, ການເຄື່ອນຍ້າຍ, ການຄິດໄລ່ຄືນໃຫມ່, ແລະການປ່ຽນຂໍ້ມູນຈາກຮູບແບບຫນຶ່ງໄປອີກ. ໃນອີກດ້ານຫນຶ່ງ, ພວກມັນຄ້າຍຄືກັບການຄິດໄລ່, ໃນທາງກົງກັນຂ້າມ, ມັນບໍ່ສໍາຄັນກັບພວກເຮົາວ່າພວກມັນສໍາເລັດໄວເທົ່າໃດ.

ຂໍໃຫ້ເບິ່ງວ່າວຽກງານດັ່ງກ່າວບໍລິໂພກຊັບພະຍາກອນແນວໃດ, ສໍາລັບການຍົກຕົວຢ່າງ, ໂຮງງານຜະລິດສູນກາງ.

ວຽກງານຊັກຊ້າສັ້ນ. ວຽກງານດັ່ງກ່າວຈະມີຮູບແບບການບໍລິໂພກ CPU ຄ້າຍຄືກັນກັບນີ້:

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

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

alloc: cpu = 4 (max)

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

ວຽກງານການຄິດໄລ່. ຮູບແບບຂອງພວກມັນຈະແຕກຕ່າງກັນເລັກນ້ອຍ:

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

alloc: cpu = [1,*)

"ກະລຸນາວາງມັນໃສ່ minion ບ່ອນທີ່ມີຢ່າງຫນ້ອຍຫນຶ່ງແກນ, ແລະຫຼັງຈາກນັ້ນຈໍານວນຫຼາຍເທົ່າທີ່ມີ, ມັນຈະກິນທຸກສິ່ງທຸກຢ່າງ."

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

ແຕ່ວ່າຈະເຮັດແນວໃດ?

ທໍາອິດ, ໃຫ້ເບິ່ງຢູ່ໃນ prod ແລະການຈັດສັນຂອງມັນ: cpu = 4. ພວກເຮົາຈໍາເປັນຕ້ອງສະຫງວນສີ່ແກນ. ໃນ Docker run ນີ້ສາມາດເຮັດໄດ້ໃນສອງວິທີ:

• ການນໍາໃຊ້ທາງເລືອກ --cpuset=1-4, i.e. ຈັດສັນສີ່ cores ສະເພາະໃນເຄື່ອງກັບວຽກງານ.
• ໃຊ້ --cpuquota=400_000 --cpuperiod=100_000, ກໍານົດໂຄຕ້າສໍາລັບເວລາຂອງໂປເຊດເຊີ, i.e. ຊີ້ບອກວ່າທຸກໆ 100 ms ຂອງເວລາຈິງ, ວຽກງານຈະໃຊ້ເວລາຂອງໂປເຊດເຊີບໍ່ເກີນ 400 ms. ດຽວກັນສີ່ແກນແມ່ນໄດ້ຮັບ.

ແຕ່ວິທີການໃດແດ່ທີ່ເຫມາະສົມ?

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

ໃຫ້ພວກເຮົາຄິດອອກວິທີການຈອງໃນ Docker ໂດຍອີງໃສ່ຈໍານວນຂັ້ນຕ່ໍາຂອງ cores. ໂຄຕ້າສໍາລັບວຽກງານ batch ແມ່ນບໍ່ມີຕໍ່ໄປອີກແລ້ວ, ເນື່ອງຈາກວ່າບໍ່ຈໍາເປັນຕ້ອງຈໍາກັດການສູງສຸດ, ມັນພຽງພໍທີ່ຈະພຽງແຕ່ຮັບປະກັນຕໍາ່ສຸດທີ່. ແລະໃນທີ່ນີ້ທາງເລືອກທີ່ເຫມາະສົມ docker run --cpushares.

ພວກເຮົາຕົກລົງເຫັນດີວ່າຖ້າ batch ຕ້ອງການການຮັບປະກັນຢ່າງຫນ້ອຍຫນຶ່ງຫຼັກ, ຫຼັງຈາກນັ້ນພວກເຮົາຊີ້ໃຫ້ເຫັນ --cpushares=1024, ແລະຖ້າຫາກວ່າມີຢ່າງຫນ້ອຍສອງແກນ, ຫຼັງຈາກນັ້ນພວກເຮົາຊີ້ໃຫ້ເຫັນ --cpushares=2048. ຮຸ້ນ Cpu ບໍ່ແຊກແຊງໃນທາງໃດກໍ່ຕາມກັບການແຈກຢາຍເວລາຂອງໂປເຊດເຊີຕາບໃດທີ່ມັນພຽງພໍ. ດັ່ງນັ້ນ, ຖ້າ prod ບໍ່ໄດ້ໃຊ້ທັງຫມົດສີ່ແກນຂອງມັນ, ບໍ່ມີຫຍັງຈໍາກັດວຽກງານ batch, ແລະພວກເຂົາສາມາດໃຊ້ເວລາຂອງໂປເຊດເຊີເພີ່ມເຕີມ. ແຕ່ໃນສະຖານະການທີ່ຂາດແຄນໂປເຊດເຊີ, ຖ້າ prod ໄດ້ບໍລິໂພກທັງສີ່ແກນຂອງມັນແລະໄດ້ເຖິງໂຄຕ້າຂອງມັນ, ເວລາຂອງໂປເຊດເຊີທີ່ຍັງເຫຼືອຈະຖືກແບ່ງຕາມອັດຕາສ່ວນກັບ cpushares, i.e. ໃນສະຖານະການສາມແກນຟຣີ, ຫນຶ່ງຈະເປັນ. ມອບໃຫ້ກັບວຽກງານທີ່ມີ 1024 cpushares, ແລະອີກສອງອັນທີ່ຍັງເຫຼືອຈະຖືກມອບໃຫ້ກັບວຽກງານທີ່ມີ 2048 cpushares.

Но использования quota и shares недостаточно. Нам нужно сделать так, чтобы задача с короткой задержкой получала приоритет перед batch-задачей при распределении процессорного времени. Без такой приоритизации batch-задача будет забирать всё процессорное время в момент, когда оно необходимо prod. В Docker run нет никаких опций приоритизации контейнеров, но на помощь приходят политики планировщика центрального процессора в Linux. Подробно о них можно прочитать ທີ່ນີ້, ແລະໃນຂອບຂອງບົດຄວາມນີ້ພວກເຮົາຈະຜ່ານພວກເຂົາໂດຍຫຍໍ້:

• SCHED_OTHER
  По умолчанию получают все обычные пользовательские процессы на Linux-машине.
• SCHED_BATCH
  ຖືກອອກແບບມາສໍາລັບຂະບວນການທີ່ໃຊ້ຊັບພະຍາກອນ. ເມື່ອວາງວຽກງານໃສ່ໂປເຊດເຊີ, ອັນທີ່ເອີ້ນວ່າການລົງໂທດການເປີດໃຊ້ແມ່ນໄດ້ຖືກນໍາສະເຫນີ: ວຽກງານດັ່ງກ່າວມີແນວໂນ້ມຫນ້ອຍທີ່ຈະໄດ້ຮັບຊັບພະຍາກອນຂອງໂປເຊດເຊີຖ້າມັນຖືກນໍາໃຊ້ໂດຍວຽກງານທີ່ມີ SCHED_OTHER.
• SCHED_IDLE
  ຂະບວນການພື້ນຖານທີ່ມີບູລິມະສິດຕໍ່າຫຼາຍ, ເຖິງແມ່ນວ່າຈະຕໍ່າກວ່າອັນງາມ -19. ພວກເຮົາໃຊ້ຫ້ອງສະຫມຸດແຫຼ່ງເປີດຂອງພວກເຮົາ one-nio, ເພື່ອກໍານົດນະໂຍບາຍທີ່ຈໍາເປັນໃນເວລາທີ່ເລີ່ມຕົ້ນບັນຈຸໂດຍການໂທຫາ

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ແຕ່ເຖິງແມ່ນວ່າທ່ານບໍ່ໄດ້ຂຽນໂປຣແກຣມໃນ Java, ສິ່ງດຽວກັນສາມາດເຮັດໄດ້ໂດຍໃຊ້ຄໍາສັ່ງ chrt:

chrt -i 0 $pid

ຂໍໃຫ້ສະຫຼຸບລະດັບຄວາມໂດດດ່ຽວຂອງພວກເຮົາທັງຫມົດເຂົ້າໄປໃນຕາຕະລາງດຽວເພື່ອຄວາມຊັດເຈນ:

ຫ້ອງຮຽນ insulation
ຕົວຢ່າງ Alloc
ຕົວເລືອກການດໍາເນີນການ Docker
scheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Batch
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

Idle
CPU= [2,*)
--cpushares=2048
SCHED_IDLE

* ຖ້າທ່ານກໍາລັງເຮັດ chrt ຈາກພາຍໃນຕູ້ຄອນເທນເນີ, ທ່ານອາດຈະຕ້ອງການຄວາມສາມາດ sys_nice, ເພາະວ່າໂດຍຄ່າເລີ່ມຕົ້ນ Docker ເອົາຄວາມສາມາດນີ້ອອກເມື່ອເລີ່ມຕົ້ນບັນຈຸ.

ແຕ່ວຽກງານທີ່ບໍລິໂພກບໍ່ພຽງແຕ່ໂປເຊດເຊີ, ແຕ່ຍັງການຈະລາຈອນ, ເຊິ່ງສົ່ງຜົນກະທົບຕໍ່ການຊັກຊ້າຂອງວຽກງານເຄືອຂ່າຍເຖິງແມ່ນວ່າການຈັດສັນຊັບພະຍາກອນຂອງໂປເຊດເຊີທີ່ບໍ່ຖືກຕ້ອງ. ເພາະສະນັ້ນ, ຕາມທໍາມະຊາດພວກເຮົາຕ້ອງການທີ່ຈະໄດ້ຮັບຮູບພາບດຽວກັນຢ່າງແທ້ຈິງສໍາລັບການຈະລາຈອນ. ນັ້ນແມ່ນ, ເມື່ອວຽກງານ prod ສົ່ງບາງແພັກເກັດໄປຫາເຄືອຂ່າຍ, ພວກເຮົາຈໍາກັດຄວາມໄວສູງສຸດ (ສູດ alloc: lan=[*,500mbps) ), ທີ່ prod ສາມາດເຮັດໄດ້. ແລະສໍາລັບ batch ພວກເຮົາຮັບປະກັນພຽງແຕ່ throughput ຕໍາ່ສຸດທີ່, ແຕ່ບໍ່ຈໍາກັດສູງສຸດ (ສູດ alloc: lan=[10Mbps,*) ) ໃນກໍລະນີນີ້, ການຈະລາຈອນ prod ຄວນໄດ້ຮັບບູລິມະສິດຫຼາຍກວ່າວຽກງານ batch.
ທີ່ນີ້ Docker ບໍ່ມີພື້ນຖານໃດໆທີ່ພວກເຮົາສາມາດນໍາໃຊ້ໄດ້. ແຕ່ມັນມາກັບການຊ່ວຍເຫຼືອຂອງພວກເຮົາ Linux ການຄວບຄຸມການຈະລາຈອນ. ພວກເຮົາສາມາດບັນລຸຜົນໄດ້ຮັບທີ່ຕ້ອງການດ້ວຍການຊ່ວຍເຫຼືອຂອງລະບຽບວິໄນ ເສັ້ນໂຄ້ງການບໍລິການຍຸດຕິທຳຕາມລຳດັບ. ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ພວກເຮົາຈໍາແນກສອງປະເພດການຈະລາຈອນ: ຜະລິດຕະພັນບູລິມະສິດສູງ ແລະ batch/idle ບູລິມະສິດຕໍ່າ. ດັ່ງນັ້ນ, ການຕັ້ງຄ່າສໍາລັບການຈາລະຈອນຂາອອກແມ່ນຄ້າຍຄືນີ້:

ທີ່ນີ້ 1:0 ແມ່ນ "ຮາກ qdisc" ຂອງລະບຽບວິໄນ hsfc; 1:1 - ຫ້ອງຮຽນເດັກນ້ອຍ hsfc ທີ່ມີຂອບເຂດຈໍາກັດແບນວິດທັງຫມົດ 8 Gbit / s, ພາຍໃຕ້ການວາງຊັ້ນເດັກຂອງບັນຈຸທັງຫມົດ; 1:2 - ຫ້ອງຮຽນເດັກນ້ອຍ hsfc ແມ່ນທົ່ວໄປກັບທຸກໆວຽກ batch ແລະ idle ທີ່ມີຂອບເຂດຈໍາກັດ "dynamic", ເຊິ່ງໄດ້ສົນທະນາຂ້າງລຸ່ມນີ້. ຊັ້ນຮຽນເດັກນ້ອຍ hsfc ທີ່ຍັງເຫຼືອແມ່ນຫ້ອງຮຽນທີ່ອຸທິດຕົນສໍາລັບປະຈຸບັນການແລ່ນບັນຈຸ prod ທີ່ມີຂໍ້ຈໍາກັດທີ່ສອດຄ່ອງກັບ manifests ຂອງພວກເຂົາ - 450 ແລະ 400 Mbit / s. ແຕ່ລະຊັ້ນຮຽນ hsfc ໄດ້ຖືກມອບຫມາຍເປັນແຖວ qdisc fq ຫຼື fq_codel, ອີງຕາມສະບັບ Linux kernel, ເພື່ອຫຼີກເວັ້ນການສູນເສຍແພັກເກັດໃນລະຫວ່າງການຈະລາຈອນລະເບີດ.

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

ໃນລະຫວ່າງການທົດລອງ, ພວກເຮົາໄດ້ພົບເຫັນວ່າ hsfc ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດໃນເວລາທີ່ 1:2 ຫ້ອງຮຽນ batch ທີ່ບໍ່ມີບູລິມະສິດ / idle traffic ຖືກຈໍາກັດຢູ່ໃນເຄື່ອງຈັກ minion ບໍ່ໃຫ້ຫຼາຍກ່ວາເສັ້ນທາງຟຣີທີ່ແນ່ນອນ. ຖ້າບໍ່ດັ່ງນັ້ນ, ການຈະລາຈອນທີ່ບໍ່ແມ່ນບູລິມະສິດມີຜົນກະທົບຫຼາຍເກີນໄປຕໍ່ການຊັກຊ້າຂອງວຽກງານຜະລິດຕະພັນ. miniond ກໍານົດຈໍານວນປະຈຸບັນຂອງແບນວິດຟຣີທຸກໆວິນາທີ, ການວັດແທກການບໍລິໂພກການຈະລາຈອນໂດຍສະເລ່ຍຂອງຫນ້າວຽກທັງຫມົດຂອງ minion ທີ່ກໍານົດໄວ້. ແລະຫັກອອກຈາກແບນວິດຂອງການໂຕ້ຕອບເຄືອຂ່າຍ ມີຂອບຂະຫນາດນ້ອຍ, i.e.

ແຖບແມ່ນຖືກກໍານົດເປັນເອກະລາດສໍາລັບການຈະລາຈອນຂາເຂົ້າແລະຂາອອກ. ແລະອີງຕາມຄຸນຄ່າໃຫມ່, miniond reconfigures ຂອບເຂດຈໍາກັດຫ້ອງຮຽນທີ່ບໍ່ແມ່ນບູລິມະສິດ 1:2.

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

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

ດ້ວຍການເອົາເສັ້ນເພີ່ມເຕີມອອກອີກເທື່ອໜຶ່ງ, ພວກເຮົາສາມາດຂຽນຊື່ການບໍລິການຂອງພວກເຮົາໃຫ້ດີຂຶ້ນໂດຍການເພີ່ມໜ້າວຽກທີ່ໂດດດ່ຽວໃສ່ທ້າຍຂອງຊື່ການບໍລິການເຕັມ: web.front.prod, catalog.music.batch, transformer.music.idle.

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

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

ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ບັນ​ລຸ​ໄດ້​: ຖ້າ​ຫາກ​ວ່າ batch ສຸມ​ການ​ບໍ​ລິ​ໂພກ​ ພຽງແຕ່ ресурсы процессора, то встроенный планировщик ЦП Linux очень хорошо справляется со своей задачей, и влияния на prod-задачу практически нет. Но если эта batch-задача начинает активно работать с памятью, то взаимное влияние уже проявляется. Это происходит потому, что у prod-задачи «вымываются» процессорные кеши памяти — в итоге в кеше возрастают промахи, и процессор обрабатывает prod-задачу медленнее. Такая batch-задача может на 10 % повысить задержки нашего типичного prod-контейнера.

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

ນອກຈາກນັ້ນ, ມາຮອດປັດຈຸບັນພວກເຮົາໄດ້ຈັດການພຽງແຕ່ແກ້ໄຂບັນຫາການຈັດລໍາດັບຄວາມສໍາຄັນຂອງການຈະລາຈອນ TCP: ວິທີການ hsfc ບໍ່ເຮັດວຽກສໍາລັບ UDP. ແລະເຖິງແມ່ນວ່າໃນກໍລະນີຂອງການຈະລາຈອນ TCP, ຖ້າວຽກງານ batch ສ້າງການຈະລາຈອນຫຼາຍ, ນີ້ຍັງເຮັດໃຫ້ການຊັກຊ້າຂອງວຽກງານ prod ເພີ່ມຂຶ້ນປະມານ 10%.

ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​

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

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

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

ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ຖ້າມີລູກນ້ອຍທັງໝົດບໍ່ສາມາດໃຊ້ໄດ້?

ແນ່ນອນ, ແລ່ນຖັງໃສ່ເຄື່ອງອື່ນ. ສ່ວນທີ່ຫນ້າສົນໃຈຢູ່ທີ່ນີ້ແມ່ນສິ່ງທີ່ເກີດຂື້ນກັບທີ່ຢູ່ IP (es) ທີ່ຖືກມອບຫມາຍໃສ່ຖັງ.

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

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

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

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

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

ດັ່ງນັ້ນ, ການສ້າງແຜນທີ່ຂອງຊື່ການບໍລິການກັບບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ IP ຂອງມັນມີການປ່ຽນແປງຫນ້ອຍທີ່ສຸດ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເບິ່ງ​ອີກ​ເທື່ອ​ຫນຶ່ງ​ຊື່​ຂອງ​ການ​ບໍ​ລິ​ການ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ກ່າວ​ມາ​ໃນ​ຕອນ​ຕົ້ນ​ຂອງ​ບົດ​ຄວາມ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), ພວກເຮົາຈະສັງເກດເຫັນວ່າພວກເຂົາຄ້າຍຄືກັບ FQDNs ທີ່ໃຊ້ໃນ DNS. ນັ້ນແມ່ນ, ເພື່ອສ້າງແຜນທີ່ຊື່ຂອງຕົວຢ່າງການບໍລິການກັບທີ່ຢູ່ IP ຂອງພວກເຂົາ, ພວກເຮົາໃຊ້ໂປໂຕຄອນ DNS. ຍິ່ງໄປກວ່ານັ້ນ, DNS ນີ້ສົ່ງຄືນທີ່ຢູ່ IP ທີ່ສະຫງວນໄວ້ຂອງທຸກ container - ທັງແລ່ນແລະຢຸດ (ໃຫ້ເວົ້າວ່າສາມ replicas ຖືກນໍາໃຊ້, ແລະພວກເຮົາມີຫ້າທີ່ຢູ່ທີ່ສະຫງວນໄວ້ - ທັງຫ້າຈະຖືກສົ່ງຄືນ). ລູກຄ້າ, ໄດ້ຮັບຂໍ້ມູນນີ້, ຈະພະຍາຍາມສ້າງການເຊື່ອມຕໍ່ກັບຫ້າ replicas - ແລະດັ່ງນັ້ນຈຶ່ງກໍານົດສິ່ງທີ່ເຮັດວຽກ. ຕົວເລືອກນີ້ສໍາລັບການກໍານົດຄວາມພ້ອມແມ່ນມີຄວາມຫນ້າເຊື່ອຖືຫຼາຍ; ມັນບໍ່ກ່ຽວຂ້ອງກັບ DNS ຫຼື Service Discovery, ຊຶ່ງຫມາຍຄວາມວ່າບໍ່ມີບັນຫາຍາກທີ່ຈະແກ້ໄຂເພື່ອຮັບປະກັນຄວາມກ່ຽວຂ້ອງຂອງຂໍ້ມູນແລະຄວາມຜິດຂອງລະບົບເຫຼົ່ານີ້. ຍິ່ງໄປກວ່ານັ້ນ, ໃນການບໍລິການທີ່ສໍາຄັນທີ່ການດໍາເນີນງານຂອງປະຕູທັງຫມົດແມ່ນຂຶ້ນກັບ, ພວກເຮົາບໍ່ສາມາດໃຊ້ DNS ທັງຫມົດ, ແຕ່ພຽງແຕ່ໃສ່ທີ່ຢູ່ IP ເຂົ້າໃນການຕັ້ງຄ່າ.

ການປະຕິບັດການໂອນ IP ດັ່ງກ່າວຢູ່ຫລັງກ່ອງບັນຈຸສາມາດບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ - ແລະພວກເຮົາຈະເບິ່ງວ່າມັນເຮັດວຽກແນວໃດກັບຕົວຢ່າງຕໍ່ໄປນີ້:

ໃຫ້ເວົ້າວ່າ one-cloud master ມອບຄໍາສັ່ງໃຫ້ minion M1 ເພື່ອດໍາເນີນການ 1.ok-web.group1.web.front.prod ກັບທີ່ຢູ່ 1.1.1.1. ເຮັດວຽກກ່ຽວກັບ minion ໝີ, ເຊິ່ງໂຄສະນາທີ່ຢູ່ນີ້ກັບເຄື່ອງແມ່ຂ່າຍພິເສດ ເຄື່ອງສະທ້ອນເສັ້ນທາງ. У последних есть BGP-сессия с сетевой железкой, в которую и транслируется маршрут адреса 1.1.1.1 на M1. M1 же маршрутизирует пакеты внутрь контейнера уже средствами Linux. Серверов route reflector три, так как это очень критичная часть инфраструктуры one-cloud — без них сеть в one-cloud работать не будет. Мы размещаем их в разных стойках, по возможности расположенных в разных залах дата-центра, чтобы уменьшить вероятность единовременного отказа всех трёх.

ຕອນນີ້ໃຫ້ສົມມຸດວ່າການເຊື່ອມຕໍ່ລະຫວ່າງແມ່ບົດຟັງດຽວກັບ M1 minion ແມ່ນສູນເສຍ. ດຽວນີ້ແມ່ບົດເມຄດຽວຈະປະຕິບັດການສົມມຸດຕິຖານວ່າ M1 ລົ້ມເຫລວຢ່າງສົມບູນ. ນັ້ນແມ່ນ, ມັນຈະໃຫ້ຄໍາສັ່ງກັບ minion M2 ເພື່ອເປີດຕົວ web.group1.web.front.prod ກັບທີ່ຢູ່ດຽວກັນ 1.1.1.1. ໃນປັດຈຸບັນພວກເຮົາມີສອງເສັ້ນທາງທີ່ຂັດແຍ້ງກັນຢູ່ໃນເຄືອຂ່າຍສໍາລັບ 1.1.1.1: ໃນ M1 ແລະໃນ M2. ເພື່ອແກ້ໄຂຂໍ້ຂັດແຍ່ງດັ່ງກ່າວ, ພວກເຮົາໃຊ້ Multi Exit Discriminator, ເຊິ່ງລະບຸໄວ້ໃນປະກາດ BGP. ນີ້ແມ່ນຕົວເລກທີ່ສະແດງໃຫ້ເຫັນເຖິງນ້ໍາຫນັກຂອງເສັ້ນທາງທີ່ໂຄສະນາ. ໃນບັນດາເສັ້ນທາງທີ່ຂັດແຍ້ງກັນ, ເສັ້ນທາງທີ່ມີຄ່າ MED ຕ່ໍາຈະຖືກເລືອກ. ແມ່ບົດເມຄດຽວສະຫນັບສະຫນູນ MED ເປັນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງທີ່ຢູ່ IP ຂອງບັນຈຸ. ສໍາລັບຄັ້ງທໍາອິດ, ທີ່ຢູ່ແມ່ນຂຽນດ້ວຍ MED ຂະຫນາດໃຫຍ່ພຽງພໍ = 1. ໃນສະຖານະການການໂອນຕູ້ຄອນເທນເນີສຸກເສີນດັ່ງກ່າວ, ແມ່ບົດຫຼຸດລົງ MED, ແລະ M000 ຈະໄດ້ຮັບຄໍາສັ່ງເພື່ອໂຄສະນາທີ່ຢູ່ 000 ກັບ MED =. 2. ຕົວຢ່າງທີ່ແລ່ນຢູ່ໃນ M1.1.1.1 ຈະຍັງຄົງຢູ່ໃນກໍລະນີນີ້ບໍ່ມີການເຊື່ອມຕໍ່, ແລະຊະຕາກໍາຂອງລາວມີຄວາມສົນໃຈກັບພວກເຮົາຫນ້ອຍຫນຶ່ງຈົນກ່ວາການເຊື່ອມຕໍ່ກັບແມ່ບົດໄດ້ຖືກຟື້ນຟູຄືນໃຫມ່, ເມື່ອລາວຈະຖືກຢຸດເຊົາຄືກັບເກົ່າ.

ອຸບັດເຫດ

ລະບົບການຈັດການສູນຂໍ້ມູນທັງໝົດສະເຫມີຈັດການກັບຄວາມລົ້ມເຫລວເລັກນ້ອຍທີ່ຍອມຮັບໄດ້. ການລົ້ນຕູ້ຄອນເທນເນີແມ່ນມາດຕະຖານເກືອບທຸກບ່ອນ.

ຂໍໃຫ້ເບິ່ງວິທີທີ່ພວກເຮົາຈັດການກັບເຫດການສຸກເສີນ, ເຊັ່ນ: ໄຟຟ້າລົ້ມເຫຼວໃນຫນຶ່ງຫຼືຫຼາຍຫ້ອງຂອງສູນຂໍ້ມູນ.

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

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

ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ແດ່ກ່ຽວກັບເລື່ອງນີ້?

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

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

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

ໃນ prod ພວກເຮົາມອບຫມາຍບູລິມະສິດທີ່ສູງກວ່າ, 0; on batch - ເລັກນ້ອຍຕ່ໍາ, 100; on idle - ເຖິງແມ່ນວ່າຕ່ໍາກວ່າ, 200. ການຈັດລໍາດັບຄວາມສໍາຄັນແມ່ນຖືກນໍາໃຊ້ຕາມລໍາດັບ. ວຽກງານທັງໝົດທີ່ຕໍ່າກວ່າໃນລຳດັບຈະມີບູລິມະສິດທີ່ສອດຄ້ອງກັນ. ຖ້າພວກເຮົາຕ້ອງການ caches ພາຍໃນ prod ຖືກເປີດຕົວກ່ອນຫນ້າ, ຫຼັງຈາກນັ້ນພວກເຮົາກໍານົດບູລິມະສິດໃຫ້ cache = 0 ແລະ subqueues ດ້ານຫນ້າ = 1. ຕົວຢ່າງ, ພວກເຮົາຕ້ອງການເປີດປະຕູຕົ້ນຕໍຈາກຫນ້າກ່ອນ, ແລະທາງຫນ້າດົນຕີເທົ່ານັ້ນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາສາມາດກໍານົດຄວາມສໍາຄັນຕ່ໍາກວ່າອັນສຸດທ້າຍ - 10.

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

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

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

ອຸບັດເຫດ DC ທັງໝົດ

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

ແລະນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາເຮັດເພື່ອປ້ອງກັນບໍ່ໃຫ້ໃຜ tweeting #alive.

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

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

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

ຜົນໄດ້ຮັບ

ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຂອງ one-cloud​:

• ໂຄງ​ການ​ຕັ້ງ​ຊື່​ຕາມ​ລໍາ​ດັບ​ແລະ​ພາບ​ສໍາ​ລັບ​ການ​ບໍ​ລິ​ການ​ແລະ​ພາ​ຊະ​ນະ​, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຊອກຫາໄດ້ຢ່າງໄວວາວ່າວຽກງານແມ່ນຫຍັງ, ມັນກ່ຽວຂ້ອງກັບຫຍັງແລະວິທີການເຮັດວຽກແລະໃຜເປັນຜູ້ຮັບຜິດຊອບ.
• ພວກເຮົາສະຫມັກຂອງພວກເຮົາ ເຕັກ​ນິກ​ການ​ປະ​ສົມ​ຜະ​ລິດ​ຕະ​ພັນ - ແລະ batch -задач на миньонах, чтобы повысить эффективность совместного использования машин. Вместо cpuset мы используем CPU quotas, shares, политики планировщика CPU и Linux QoS.
• ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແຍກພາຊະນະທີ່ແລ່ນຢູ່ໃນເຄື່ອງດຽວກັນຢ່າງສົມບູນ, ແຕ່ອິດທິພົນເຊິ່ງກັນແລະກັນຂອງພວກມັນຍັງຄົງຢູ່ພາຍໃນ 20%.
• ການ​ຈັດ​ຕັ້ງ​ການ​ບໍ​ລິ​ການ​ເຂົ້າ​ໄປ​ໃນ​ລໍາ​ດັບ​ການ​ຊ່ວຍ​ໃຫ້​ມີ​ການ​ຟື້ນ​ຟູ​ໄພ​ພິ​ບັດ​ອັດ​ຕະ​ໂນ​ມັດ​ໂດຍ​ນໍາ​ໃຊ້​ ການຈັດວາງ ແລະບູລິມະສິດການຈອງ.

ຄຳ ຖາມທີ່ຖາມ

ເປັນຫຍັງພວກເຮົາບໍ່ເອົາວິທີແກ້ໄຂທີ່ກຽມພ້ອມ?

• ຫ້ອງຮຽນທີ່ແຕກຕ່າງກັນຂອງການໂດດດ່ຽວວຽກງານຮຽກຮ້ອງໃຫ້ມີເຫດຜົນທີ່ແຕກຕ່າງກັນໃນເວລາທີ່ຖືກຈັດໃສ່ໃນ minions. ຖ້າວຽກງານຜະລິດຕະພັນສາມາດຖືກຈັດໃສ່ໂດຍພຽງແຕ່ສະຫງວນຊັບພະຍາກອນ, ຫຼັງຈາກນັ້ນຕ້ອງວາງວຽກ batch ແລະ idle, ຕິດຕາມການນໍາໃຊ້ຕົວຈິງຂອງຊັບພະຍາກອນໃນເຄື່ອງຈັກ minion.
• ຄວາມຕ້ອງການທີ່ຈະພິຈາລະນາຊັບພະຍາກອນທີ່ບໍລິໂພກໂດຍວຽກງານ, ເຊັ່ນ:
  • ແບນວິດຂອງເຄືອຂ່າຍ;
  • ປະເພດແລະ "spindles" ຂອງແຜ່ນ.
• ຄວາມຕ້ອງການທີ່ຈະຊີ້ບອກບູລິມະສິດຂອງການບໍລິການໃນລະຫວ່າງການຕອບສະຫນອງສຸກເສີນ, ສິດແລະໂຄຕ້າຂອງຄໍາສັ່ງສໍາລັບຊັບພະຍາກອນ, ເຊິ່ງຖືກແກ້ໄຂໂດຍໃຊ້ແຖວລໍາດັບຊັ້ນໃນຫນຶ່ງຟັງ.
• ຄວາມຕ້ອງການທີ່ຈະມີການຕັ້ງຊື່ຂອງມະນຸດຂອງຕູ້ຄອນເທນເນີເພື່ອຫຼຸດຜ່ອນເວລາຕອບສະຫນອງຕໍ່ອຸປະຕິເຫດແລະເຫດການ
• ຄວາມບໍ່ເປັນໄປໄດ້ຂອງການຈັດຕັ້ງປະຕິບັດການຄົ້ນພົບການບໍລິການທີ່ແຜ່ຫຼາຍຄັ້ງດຽວ; ຄວາມຕ້ອງການທີ່ຈະຢູ່ຮ່ວມກັນເປັນເວລາດົນນານກັບວຽກງານທີ່ໂຮດຢູ່ໃນຮາດແວ - ບາງສິ່ງບາງຢ່າງທີ່ຖືກແກ້ໄຂໂດຍທີ່ຢູ່ IP "static" ດັ່ງຕໍ່ໄປນີ້ບັນຈຸ, ແລະ, ດັ່ງນັ້ນ, ຄວາມຕ້ອງການສໍາລັບການເຊື່ອມໂຍງທີ່ເປັນເອກະລັກກັບໂຄງສ້າງເຄືອຂ່າຍຂະຫນາດໃຫຍ່.

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

ເຖິງຜູ້ທີ່ອ່ານຂໍ້ຄວາມສຸດທ້າຍ, ຂອບໃຈສໍາລັບຄວາມອົດທົນແລະຄວາມສົນໃຈຂອງທ່ານ!

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