ການແກ້ໄຂ hyperconverged AERODISK vAIR. ພື້ນຖານແມ່ນລະບົບໄຟລ໌ ARDFS

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

ໃຫ້ເລີ່ມຕົ້ນເລື່ອງທີ່ມີປະຫວັດສາດຂອງການສ້າງລະບົບ, delve ເຂົ້າໄປໃນລະບົບໄຟລ໌ ARDFS, ເຊິ່ງເປັນພື້ນຖານຂອງ vAIR, ແລະຍັງສົນທະນາເລັກນ້ອຍກ່ຽວກັບການວາງຕໍາແຫນ່ງຂອງການແກ້ໄຂນີ້ໃນຕະຫຼາດລັດເຊຍ.

ໃນບົດຄວາມໃນອະນາຄົດພວກເຮົາຈະສົນທະນາໃນລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບອົງປະກອບສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນ (cluster, hypervisor, load balancer, monitoring system, etc.), ຂະບວນການກໍານົດ, ຍົກບັນຫາການອະນຸຍາດ, ແຍກຕ່າງຫາກສະແດງໃຫ້ເຫັນການທົດສອບ crash ແລະ, ແນ່ນອນ, ຂຽນກ່ຽວກັບການທົດສອບການໂຫຼດແລະ. ຂະໜາດ. ພວກເຮົາຍັງຈະອຸທິດບົດຄວາມແຍກຕ່າງຫາກໃຫ້ກັບ vAIR ສະບັບຊຸມຊົນ.

Aerodisk ແມ່ນເລື່ອງກ່ຽວກັບລະບົບການເກັບຮັກສາບໍ? ຫຼືເປັນຫຍັງພວກເຮົາຈຶ່ງເລີ່ມເຮັດ hyperconvergence ໃນສະຖານທີ່ທໍາອິດ?

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

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

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

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

ວຽກງານເບື້ອງຕົ້ນຕົ້ນຕໍແມ່ນການສ້າງຂອງພວກເຮົາເອງ, ເຖິງແມ່ນວ່າຈະງ່າຍດາຍ, ແຕ່ລະບົບໄຟລ໌ຂອງພວກເຮົາເອງ, ເຊິ່ງສາມາດແຈກຢາຍຂໍ້ມູນໂດຍອັດຕະໂນມັດແລະເທົ່າທຽມກັນໃນຮູບແບບຂອງບລັອກ virtual ໃນຈໍານວນ nth ຂອງ cluster nodes, ເຊິ່ງເຊື່ອມຕໍ່ກັນໂດຍການເຊື່ອມຕໍ່ຜ່ານ Ethernet. ໃນເວລາດຽວກັນ, FS ຄວນຂະຫນາດທີ່ດີແລະງ່າຍດາຍແລະເປັນເອກະລາດຂອງລະບົບທີ່ຢູ່ໃກ້ຄຽງ, i.e. ຖືກແຍກອອກຈາກ vAIR ໃນຮູບແບບຂອງ "ພຽງແຕ່ສະຖານທີ່ເກັບຮັກສາ".

ແນວຄວາມຄິດ vAIR ທໍາອິດ

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

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

ພວກ​ເຮົາ​ບໍ່​ໄດ້​ເບື່ອ​ຫຼາຍ​ເກີນ​ໄປ​ກັບ​ຊື່​ຂອງ​ລະ​ບົບ​ໄຟລ​໌​ແລະ​ຫຍໍ້​ເອີ້ນ​ມັນ​ວ່າ ARDFS (ເດົາ​ວ່າ​ມັນ​ແມ່ນ​ສໍາ​ລັບ​ການ​)​.

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

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

ການດໍານ້ໍາເຂົ້າໄປໃນລະບົບໄຟລ໌ ARDFS

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

ໂຄງສ້າງການເກັບຮັກສາ

ພາຍໃນທຸກໂຫນດຂອງກຸ່ມ, ARDFS ຈັດກຸ່ມຢ່າງມີເຫດຜົນຈາກພື້ນທີ່ດິສກ໌ທັງໝົດທີ່ມີຢູ່. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າສະນຸກເກີບໍ່ແມ່ນຂໍ້ມູນຫຼືພື້ນທີ່ທີ່ມີຮູບແບບ, ແຕ່ພຽງແຕ່ markup, i.e. ໂນດໃດທີ່ມີ vAIR ຕິດຕັ້ງ, ເມື່ອຖືກເພີ່ມໃສ່ກຸ່ມ, ຈະຖືກເພີ່ມໃສ່ສະນຸກເກີ ARDFS ທີ່ແບ່ງປັນໂດຍອັດຕະໂນມັດ ແລະຊັບພະຍາກອນຂອງແຜ່ນຈະຖືກແບ່ງປັນໂດຍອັດຕະໂນມັດໃນທົ່ວກຸ່ມທັງໝົດ (ແລະສາມາດໃຊ້ໄດ້ສໍາລັບການເກັບຮັກສາຂໍ້ມູນໃນອະນາຄົດ). ວິທີການນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມແລະເອົາໂຫນດອອກໄດ້ໂດຍບໍ່ມີຜົນກະທົບທີ່ຮ້າຍແຮງຕໍ່ລະບົບທີ່ໃຊ້ແລ້ວ. ເຫຼົ່ານັ້ນ. ລະບົບແມ່ນງ່າຍຫຼາຍທີ່ຈະຂະຫນາດ "ໃນ bricks", ເພີ່ມຫຼືເອົາ nodes ໃນ cluster ຖ້າຈໍາເປັນ.

ແຜ່ນ virtual (ວັດຖຸເກັບຮັກສາສໍາລັບເຄື່ອງ virtual) ໄດ້ຖືກເພີ່ມໃສ່ເທິງຂອງສະນຸກເກີ ARDFS, ເຊິ່ງສ້າງຂຶ້ນຈາກ virtual blocks ຂະຫນາດ 4 megabytes. ແຜ່ນ virtual ເກັບຮັກສາຂໍ້ມູນໂດຍກົງ. ໂຄງ​ການ​ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ຍັງ​ໄດ້​ຖືກ​ຕັ້ງ​ໄວ້​ໃນ​ລະ​ດັບ virtual disk​.

ດັ່ງທີ່ທ່ານອາດຈະໄດ້ຄາດເດົາແລ້ວ, ສໍາລັບຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງລະບົບຍ່ອຍຂອງແຜ່ນ, ພວກເຮົາບໍ່ໄດ້ໃຊ້ແນວຄວາມຄິດຂອງ RAID (Redundant array of independent Disks), ແຕ່ໃຊ້ RAIN (Redundant array of independent Nodes). ເຫຼົ່ານັ້ນ. ຄວາມທົນທານຄວາມຜິດຖືກວັດແທກ, ອັດຕະໂນມັດ, ແລະຈັດການໂດຍອີງໃສ່ຂໍ້, ບໍ່ແມ່ນແຜ່ນ. Disks, ແນ່ນອນ, ຍັງເປັນວັດຖຸເກັບຮັກສາ, ພວກມັນ, ຄືກັນກັບທຸກສິ່ງອື່ນໆ, ໄດ້ຖືກຕິດຕາມ, ທ່ານສາມາດປະຕິບັດການດໍາເນີນການມາດຕະຖານທັງຫມົດກັບພວກມັນ, ລວມທັງການປະກອບຮາດແວ RAID ທ້ອງຖິ່ນ, ແຕ່ cluster ເຮັດວຽກໂດຍສະເພາະໃນ nodes.

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

ຮູບແບບການທົນທານຕໍ່ຄວາມຜິດຂອງການເກັບຮັກສາ

ສາມາດມີສອງຮູບແບບຄວາມທົນທານຕໍ່ຄວາມຜິດພາດສໍາລັບແຜ່ນ virtual ໃນ vAIR:

1) ປັດໄຈການຈໍາລອງຫຼືການຈໍາລອງແບບງ່າຍໆ - ວິທີການຕ້ານຄວາມຜິດນີ້ແມ່ນງ່າຍດາຍຄືກັບໄມ້ແລະເຊືອກ. ການຈໍາລອງແບບຊິ້ງແມ່ນດໍາເນີນລະຫວ່າງຂໍ້ທີ່ມີປັດໄຈ 2 (2 ສະບັບຕໍ່ກຸ່ມ) ຫຼື 3 (3 ສະບັບຕາມລໍາດັບ). RF-2 ອະນຸຍາດໃຫ້ແຜ່ນ virtual ສາມາດທົນກັບຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງ node ໃນ cluster, ແຕ່ "ກິນ" ເຄິ່ງຫນຶ່ງຂອງປະລິມານທີ່ເປັນປະໂຫຍດ, ແລະ RF-3 ຈະທົນກັບຄວາມລົ້ມເຫຼວຂອງ 2 nodes ໃນ cluster, ແຕ່ສະຫງວນ 2/3 ຂອງ. ປະລິມານທີ່ເປັນປະໂຫຍດສໍາລັບຄວາມຕ້ອງການຂອງມັນ. ໂຄງ​ການ​ນີ້​ແມ່ນ​ຄ້າຍ​ຄື​ກັນ​ຫຼາຍ​ກັບ RAID-1​, ນັ້ນ​ແມ່ນ​, ແຜ່ນ virtual ທີ່​ກໍາ​ນົດ​ໄວ້​ໃນ RF-2 ແມ່ນ​ທົນ​ທານ​ຕໍ່​ກັບ​ຄວາມ​ລົ້ມ​ເຫຼວ​ຂອງ​ຂໍ້​ໃດ​ຫນຶ່ງ​ໃນ​ກຸ່ມ​. ໃນກໍລະນີນີ້, ທຸກສິ່ງທຸກຢ່າງຈະດີກັບຂໍ້ມູນແລະເຖິງແມ່ນວ່າ I/O ຈະບໍ່ຢຸດ. ເມື່ອ node ຫຼຸດລົງກັບຄືນສູ່ການບໍລິການ, ການຟື້ນຕົວ / synchronization ຂໍ້ມູນອັດຕະໂນມັດຈະເລີ່ມຕົ້ນ.

ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງການແຈກຢາຍຂໍ້ມູນ RF-2 ແລະ RF-3 ໃນຮູບແບບປົກກະຕິແລະໃນສະຖານະການລົ້ມເຫຼວ.

ພວກ​ເຮົາ​ມີ​ເຄື່ອງ virtual ທີ່​ມີ​ຄວາມ​ຈຸ 8MB ຂອງ​ຂໍ້​ມູນ​ທີ່​ເປັນ​ເອ​ກະ​ລັກ (ທີ່​ເປັນ​ປະ​ໂຫຍດ​)​, ເຊິ່ງ​ດໍາ​ເນີນ​ການ​ໃນ 4 vAIR nodes​. ມັນເປັນທີ່ຊັດເຈນວ່າໃນຄວາມເປັນຈິງມັນບໍ່ຫນ້າຈະເປັນປະລິມານຂະຫນາດນ້ອຍ, ແຕ່ສໍາລັບໂຄງການທີ່ສະທ້ອນໃຫ້ເຫັນເຫດຜົນຂອງການດໍາເນີນງານ ARDFS, ຕົວຢ່າງນີ້ແມ່ນເຂົ້າໃຈໄດ້ຫຼາຍທີ່ສຸດ. AB ແມ່ນ 4MB virtual blocks ທີ່ມີຂໍ້ມູນເຄື່ອງ virtual ເປັນເອກະລັກ. RF-2 ສ້າງສອງສໍາເນົາຂອງບລັອກເຫຼົ່ານີ້ A1+A2 ແລະ B1+B2, ຕາມລໍາດັບ. ຕັນເຫຼົ່ານີ້ແມ່ນ "ວາງໄວ້" ໃນທົ່ວ nodes, ຫຼີກເວັ້ນການຕັດກັນຂອງຂໍ້ມູນດຽວກັນໃນ node ດຽວກັນ, ນັ້ນແມ່ນ, ສໍາເນົາ A1 ຈະບໍ່ຕັ້ງຢູ່ໃນ node ດຽວກັນກັບສໍາເນົາ A2. ຄືກັນກັບ B1 ແລະ B2.

ຖ້າຫນຶ່ງຂອງ nodes ລົ້ມເຫລວ (ຕົວຢ່າງ, node ເລກ 3, ເຊິ່ງປະກອບດ້ວຍສໍາເນົາຂອງ B1), ສໍາເນົານີ້ຈະຖືກເປີດໃຊ້ອັດຕະໂນມັດໃນ node ທີ່ບໍ່ມີສໍາເນົາຂອງສໍາເນົາຂອງມັນ (ນັ້ນຄືສໍາເນົາຂອງ B2).

ດັ່ງນັ້ນ, ແຜ່ນ virtual (ແລະ VM, ຕາມຄວາມເຫມາະສົມ) ສາມາດລອດພົ້ນຈາກຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງ node ໃນໂຄງການ RF-2 ໄດ້ຢ່າງງ່າຍດາຍ.

ໂຄງການ replication, ໃນຂະນະທີ່ງ່າຍດາຍແລະເຊື່ອຖືໄດ້, ທົນທຸກຈາກບັນຫາດຽວກັນກັບ RAID1 - ບໍ່ພຽງພໍພື້ນທີ່ສາມາດໃຊ້ໄດ້.

2) ການລຶບລະຫັດ ຫຼືການລຶບລະຫັດການລຶບ (ຍັງເອີ້ນວ່າ “ການເຂົ້າລະຫັດຊໍ້າຊ້ອນ”, “ລະຫັດລຶບລ້າງ” ຫຼື “ລະຫັດຊໍ້າຊ້ອນ”) ມີຢູ່ເພື່ອແກ້ໄຂບັນຫາຂ້າງເທິງ. EC ແມ່ນໂຄງການທີ່ຊ້ໍາຊ້ອນທີ່ສະຫນອງຂໍ້ມູນສູງທີ່ມີພື້ນທີ່ດິສກ໌ຕ່ໍາກວ່າເມື່ອທຽບໃສ່ກັບການຈໍາລອງ. ຫຼັກການການດໍາເນີນງານຂອງກົນໄກນີ້ແມ່ນຄ້າຍຄືກັນກັບ RAID 5, 6, 6P.

ເມື່ອເຂົ້າລະຫັດ, ຂະບວນການ EC ແບ່ງບລັອກ virtual (4MB ໂດຍຄ່າເລີ່ມຕົ້ນ) ເປັນ "ຂໍ້ມູນ" ນ້ອຍໆຫຼາຍອັນຂຶ້ນກັບໂຄງການ EC (ຕົວຢ່າງ, ໂຄງການ 2+1 ຈະແບ່ງແຕ່ລະບລັອກ 4MB ເປັນ 2 ຕ່ອນ 2MB). ຕໍ່ໄປ, ຂະບວນການນີ້ສ້າງ "ຊິ້ນສ່ວນຄວາມສະເຫມີພາບ" ສໍາລັບ "ຂໍ້ມູນ chunks" ທີ່ບໍ່ໃຫຍ່ກວ່າຫນຶ່ງໃນສ່ວນທີ່ແບ່ງອອກກ່ອນຫນ້ານີ້. ເມື່ອຖອດລະຫັດ, EC ສ້າງຊິ້ນສ່ວນທີ່ຂາດຫາຍໄປໂດຍການອ່ານຂໍ້ມູນ "ຢູ່ລອດ" ໃນທົ່ວກຸ່ມທັງຫມົດ.

ຕົວຢ່າງ, ແຜ່ນ virtual ທີ່ມີ 2 + 1 EC scheme, ປະຕິບັດຢູ່ໃນ 4 nodes cluster, ຈະທົນກັບຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງ node ໃນ cluster ໄດ້ຢ່າງງ່າຍດາຍໃນລັກສະນະດຽວກັນກັບ RF-2. ໃນກໍລະນີນີ້, ຄ່າໃຊ້ຈ່າຍຕໍ່ຫົວຈະຕ່ໍາ, ໂດຍສະເພາະ, ຕົວຄູນຄວາມອາດສາມາດທີ່ເປັນປະໂຫຍດສໍາລັບ RF-2 ແມ່ນ 2, ແລະສໍາລັບ EC 2 + 1 ມັນຈະເປັນ 1,5.

ເພື່ອອະທິບາຍມັນງ່າຍກວ່າ, ໂດຍເນື້ອແທ້ແລ້ວແມ່ນວ່າຕັນ virtual ແບ່ງອອກເປັນ 2-8 (ເປັນຫຍັງຈາກ 2 ຫາ 8, ເບິ່ງຂ້າງລຸ່ມນີ້) "ຕ່ອນ", ແລະສໍາລັບຕ່ອນເຫຼົ່ານີ້ "ຕ່ອນ" ຂອງ parity ຂອງປະລິມານທີ່ຄ້າຍຄືກັນແມ່ນຄິດໄລ່.

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

ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງ, ມີເຄື່ອງ virtual 8 MB ດຽວກັນແລະ 4 nodes, ແຕ່ມີ EC 2+1 scheme.

Blocks A ແລະ B ຖືກແບ່ງອອກເປັນສອງຊິ້ນຂອງ 2 MB ແຕ່ລະຄົນ (ສອງເພາະວ່າ 2+1), ນັ້ນແມ່ນ, A1+A2 ແລະ B1+B2. ບໍ່ຄືກັບ replica, A1 ບໍ່ແມ່ນສໍາເນົາຂອງ A2, ມັນເປັນ virtual block A, ແບ່ງອອກເປັນສອງສ່ວນ, ດຽວກັນກັບ block B. ທັງຫມົດ, ພວກເຮົາໄດ້ຮັບສອງຊຸດຂອງ 4MB, ເຊິ່ງແຕ່ລະມີສອງຊິ້ນສອງ MB. ຕໍ່ໄປ, ສໍາລັບແຕ່ລະຊຸດເຫຼົ່ານີ້, parity ແມ່ນຄິດໄລ່ດ້ວຍປະລິມານບໍ່ເກີນຫນຶ່ງຊິ້ນ (i.e. 2 MB), ພວກເຮົາໄດ້ຮັບເພີ່ມເຕີມ + 2 ຊິ້ນຂອງ parity (AP ແລະ BP). ທັງໝົດພວກເຮົາມີຂໍ້ມູນ 4×2 + 2×2 parity.

ຕໍ່ໄປ, ຕ່ອນໄດ້ຖືກ "ວາງໄວ້" ໃນບັນດາຂໍ້ເພື່ອບໍ່ໃຫ້ຂໍ້ມູນຕັດກັນກັບຄວາມສະເຫມີພາບຂອງພວກເຂົາ. ເຫຼົ່ານັ້ນ. A1 ແລະ A2 ຈະບໍ່ຢູ່ໃນ node ດຽວກັນກັບ AP.

ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງ node (ຕົວຢ່າງ, ຍັງທີສາມ), ຕັນ B1 ທີ່ຫຼຸດລົງຈະໄດ້ຮັບການຟື້ນຟູອັດຕະໂນມັດຈາກ BP parity, ເຊິ່ງຖືກເກັບໄວ້ໃນ node ເລກ 2, ແລະຈະຖືກເປີດໃຊ້ໃນ node ທີ່ມີ. ບໍ່ມີ B-parity, i.e. ສິ້ນຂອງ BP. ໃນຕົວຢ່າງນີ້, ນີ້ແມ່ນຂໍ້ທີ 1

ຂ້າພະເຈົ້າແນ່ໃຈວ່າຜູ້ອ່ານມີຄໍາຖາມ:

"ທຸກສິ່ງທຸກຢ່າງທີ່ທ່ານອະທິບາຍໄດ້ຖືກປະຕິບັດມາດົນນານທັງໂດຍຄູ່ແຂ່ງແລະໃນການແກ້ໄຂແຫຼ່ງເປີດ, ຄວາມແຕກຕ່າງລະຫວ່າງການປະຕິບັດ EC ຂອງທ່ານໃນ ARDFS ແມ່ນຫຍັງ?"

ແລະຫຼັງຈາກນັ້ນຈະມີລັກສະນະທີ່ຫນ້າສົນໃຈຂອງ ARDFS.

ລົບລະຫັດໂດຍເນັ້ນໃສ່ຄວາມຍືດຫຍຸ່ນ

ໃນເບື້ອງຕົ້ນ, ພວກເຮົາໄດ້ໃຫ້ຮູບແບບ EC X+Y ທີ່ມີຄວາມຍືດຫຍຸ່ນພໍສົມຄວນ, ເຊິ່ງ X ເທົ່າກັບຕົວເລກ 2 ຫາ 8, ແລະ Y ເທົ່າກັບຕົວເລກຈາກ 1 ຫາ 8, ແຕ່ໜ້ອຍກວ່າ ຫຼືເທົ່າກັບ X ສະເໝີ. ສໍາລັບຄວາມຍືດຫຍຸ່ນ. ການເພີ່ມຈໍານວນຊິ້ນຂໍ້ມູນ (X) ເຊິ່ງການແບ່ງປັນ virtual block ຊ່ວຍໃຫ້ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍເກີນ, ນັ້ນແມ່ນ, ເພີ່ມພື້ນທີ່ໃຊ້ໄດ້.
ການເພີ່ມຈໍານວນ parity chunks (Y) ເພີ່ມຄວາມຫນ້າເຊື່ອຖືຂອງ virtual disk. ຄ່າ Y ໃຫຍ່ຂຶ້ນ, ໂນດຫຼາຍໃນກຸ່ມສາມາດລົ້ມເຫລວໄດ້. ແນ່ນອນ, ການເພີ່ມປະລິມານ parity ຫຼຸດລົງປະລິມານຄວາມສາມາດທີ່ສາມາດໃຊ້ໄດ້, ແຕ່ນີ້ແມ່ນລາຄາທີ່ຈະຈ່າຍສໍາລັບຄວາມຫນ້າເຊື່ອຖື.

ການເອື່ອຍອີງຂອງການປະຕິບັດໃນວົງຈອນ EC ແມ່ນເກືອບໂດຍກົງ: ຫຼາຍ "ຊິ້ນ", ການປະຕິບັດທີ່ຕໍ່າກວ່າ, ແນ່ນອນ, ຕ້ອງມີທັດສະນະທີ່ສົມດູນ.

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

ຂ້າງລຸ່ມນີ້ແມ່ນຕາຕະລາງປຽບທຽບຫຼາຍ (ບໍ່ແມ່ນເປັນໄປໄດ້ທັງຫມົດ) RF ແລະ EC schemes.

ຕາຕະລາງສະແດງໃຫ້ເຫັນວ່າເຖິງແມ່ນວ່າການປະສົມປະສານ "terry" ຫຼາຍທີ່ສຸດ EC 8 + 7, ເຊິ່ງອະນຸຍາດໃຫ້ສູນເສຍເຖິງ 7 nodes ໃນກຸ່ມພ້ອມກັນ, "ກິນ" ພື້ນທີ່ໃຊ້ຫນ້ອຍ (1,875 ທຽບກັບ 2) ກ່ວາການຈໍາລອງແບບມາດຕະຖານ, ແລະປົກປ້ອງ 7 ເທົ່າທີ່ດີກວ່າ. , ເຊິ່ງເຮັດໃຫ້ກົນໄກການປົກປັກຮັກສານີ້, ເຖິງແມ່ນວ່າສະລັບສັບຊ້ອນຫຼາຍ, ມີຄວາມດຶງດູດຫຼາຍໃນສະຖານະການທີ່ມີຄວາມຈໍາເປັນເພື່ອຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືສູງສຸດໃນເງື່ອນໄຂຂອງພື້ນທີ່ດິດຈໍາກັດ. ໃນເວລາດຽວກັນ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າທຸກໆ "ບວກ" ເຖິງ X ຫຼື Y ຈະເປັນການປະຕິບັດເພີ່ມເຕີມ, ດັ່ງນັ້ນໃນສາມຫຼ່ຽມລະຫວ່າງຄວາມຫນ້າເຊື່ອຖື, ການປະຫຍັດແລະການປະຕິບັດ, ທ່ານຈໍາເປັນຕ້ອງເລືອກຢ່າງລະມັດລະວັງ. ດ້ວຍເຫດຜົນນີ້, ພວກເຮົາຈະອຸທິດບົດຄວາມແຍກຕ່າງຫາກເພື່ອລົບລ້າງການປັບຂະຫນາດລະຫັດ.

ຄວາມຫນ້າເຊື່ອຖືແລະເອກະລາດຂອງລະບົບໄຟລ໌

ARDFS ເຮັດວຽກຢູ່ໃນທ້ອງຖິ່ນໃນທຸກ nodes ຂອງ cluster ແລະ synchronizes ໃຫ້ເຂົາເຈົ້າໂດຍໃຊ້ວິທີການຂອງຕົນເອງໂດຍຜ່ານການໂຕ້ຕອບ Ethernet ອຸທິດຕົນ. ຈຸດສໍາຄັນແມ່ນວ່າ ARDFS ເປັນເອກະລາດ synchronizes ບໍ່ພຽງແຕ່ຂໍ້ມູນ, ແຕ່ຍັງ metadata ທີ່ກ່ຽວຂ້ອງກັບການເກັບຮັກສາ. ໃນຂະນະທີ່ເຮັດວຽກກ່ຽວກັບ ARDFS, ພວກເຮົາພ້ອມກັນໄດ້ສຶກສາວິທີການແກ້ໄຂທີ່ມີຢູ່ຫຼາຍໆຢ່າງແລະພວກເຮົາຄົ້ນພົບວ່າຫຼາຍໆຄົນ synchronize meta ຂອງລະບົບໄຟລ໌ໂດຍໃຊ້ DBMS ທີ່ແຈກຢາຍພາຍນອກ, ເຊິ່ງພວກເຮົາຍັງໃຊ້ສໍາລັບການ synchronization, ແຕ່ພຽງແຕ່ການຕັ້ງຄ່າ, ບໍ່ແມ່ນ metadata FS (ກ່ຽວກັບເລື່ອງນີ້ແລະລະບົບຍ່ອຍອື່ນໆທີ່ກ່ຽວຂ້ອງ. ໃນ​ບົດ​ຄວາມ​ຕໍ່​ໄປ).

Synchronizing FS metadata ໂດຍໃຊ້ DBMS ພາຍນອກແມ່ນ, ແນ່ນອນ, ການແກ້ໄຂການເຮັດວຽກ, ແຕ່ຫຼັງຈາກນັ້ນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນທີ່ເກັບໄວ້ໃນ ARDFS ຈະຂຶ້ນກັບ DBMS ພາຍນອກແລະພຶດຕິກໍາຂອງມັນ (ແລະເວົ້າກົງໄປກົງມາ, ມັນເປັນ lady capricious), ເຊິ່ງໃນ. ຄວາມຄິດເຫັນຂອງພວກເຮົາບໍ່ດີ. ເປັນຫຍັງ? ຖ້າ metadata FS ໄດ້ຮັບຄວາມເສຍຫາຍ, ຂໍ້ມູນ FS ຕົວຂອງມັນເອງຍັງສາມາດເວົ້າໄດ້ວ່າ "ສະບາຍດີ", ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຕັດສິນໃຈທີ່ຈະໃຊ້ເສັ້ນທາງທີ່ສັບສົນຫຼາຍແຕ່ເຊື່ອຖືໄດ້.

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

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

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

ໃຜຕ້ອງການມະຫັດສະຈັນນີ້?

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

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

ເມື່ອໃດທີ່ລະບົບການເກັບຮັກສາດີກວ່າ GCS?

ໃນຂະນະທີ່ພວກເຮົາເຮັດວຽກກັບຕະຫຼາດ, ພວກເຮົາມັກຈະຖືກຖາມວ່າເວລາທີ່ມັນດີກວ່າທີ່ຈະໃຊ້ໂຄງການຄລາສສິກກັບລະບົບການເກັບຮັກສາ, ແລະເວລາໃດທີ່ຈະໃຊ້ hyperconvergent? ຫຼາຍບໍລິສັດທີ່ຜະລິດ GCS (ໂດຍສະເພາະບໍລິສັດທີ່ບໍ່ມີລະບົບການເກັບຮັກສາໃນຫຼັກຊັບຂອງເຂົາເຈົ້າ) ເວົ້າວ່າ: "ລະບົບການເກັບຮັກສາໄດ້ກາຍເປັນລ້າສະໄຫມ, hyperconverged ເທົ່ານັ້ນ!" ນີ້ແມ່ນຄໍາເວົ້າທີ່ກ້າຫານ, ແຕ່ມັນບໍ່ໄດ້ສະທ້ອນເຖິງຄວາມເປັນຈິງທັງຫມົດ.

ຄວາມຈິງ, ຕະຫຼາດການເກັບຮັກສາແມ່ນກ້າວໄປສູ່ hyperconvergence ແລະວິທີແກ້ໄຂທີ່ຄ້າຍຄືກັນ, ແຕ່ວ່າມີ "ແຕ່".

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

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

ອັນທີສາມ, ມີຂໍ້ຈໍາກັດດ້ານວິຊາການຢ່າງດຽວໃນການຊັກຊ້າຂະຫນາດນ້ອຍເພີ່ມເຕີມຂອງ 2 milliseconds ຕໍ່ການຂຽນ (ບໍ່ລວມ cache ທ້ອງຖິ່ນ, ແນ່ນອນ), ຊຶ່ງເປັນຄ່າໃຊ້ຈ່າຍຂອງການເກັບຮັກສາແຈກຢາຍ.

ດີ, ຢ່າລືມກ່ຽວກັບການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍຂະຫນາດໃຫຍ່ທີ່ຮັກການປັບຂະຫນາດຂອງລະບົບຍ່ອຍຂອງແຜ່ນ.

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

ແລະບ່ອນໃດທີ່ວິທີແກ້ໄຂ hyperconverged ຈະເຮັດວຽກດີກວ່າລະບົບການເກັບຮັກສາ?

ອີງຕາມຈຸດຂ້າງເທິງ, ສາມຂໍ້ສະຫຼຸບທີ່ຈະແຈ້ງສາມາດແຕ້ມໄດ້:

1. ບ່ອນທີ່ 2 milliseconds ຂອງ latency ເພີ່ມເຕີມສໍາລັບການບັນທຶກ, ທີ່ເກີດຂຶ້ນຢ່າງຕໍ່ເນື່ອງໃນຜະລິດຕະພັນໃດຫນຶ່ງ (ໃນປັດຈຸບັນພວກເຮົາບໍ່ໄດ້ເວົ້າກ່ຽວກັບການສັງເຄາະ, nanoseconds ສາມາດສະແດງໃຫ້ເຫັນກ່ຽວກັບການສັງເຄາະ), uncritical, hyperconvergent ແມ່ນເຫມາະສົມ.
2. ບ່ອນທີ່ການໂຫຼດຈາກເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍຂະຫນາດໃຫຍ່ສາມາດຫັນເຂົ້າໄປໃນ virtual ຂະຫນາດນ້ອຍຈໍານວນຫຼາຍແລະແຈກຢາຍລະຫວ່າງ nodes, hyperconvergence ຍັງຈະເຮັດວຽກໄດ້ດີຢູ່ທີ່ນັ້ນ.
3. ບ່ອນທີ່ການປັບຂະຫນາດຕາມລວງນອນເປັນບູລິມະສິດສູງກວ່າການປັບຂະຫນາດຕາມແນວຕັ້ງ, GCS ຈະເຮັດໄດ້ດີຄືກັນ.

ວິທີແກ້ໄຂເຫຼົ່ານີ້ແມ່ນຫຍັງ?

1. ການບໍລິການພື້ນຖານໂຄງລ່າງມາດຕະຖານທັງຫມົດ (ບໍລິການໄດເລກະທໍລີ, ເມລ, EDMS, ເຄື່ອງແມ່ຂ່າຍຂອງໄຟລ໌, ລະບົບ ERP ຂະຫນາດນ້ອຍຫຼືຂະຫນາດກາງແລະ BI, ແລະອື່ນໆ). ພວກເຮົາເອີ້ນນີ້ວ່າ "ຄອມພິວເຕີ້ທົ່ວໄປ."
2. ໂຄງສ້າງພື້ນຖານຂອງຜູ້ໃຫ້ບໍລິການຟັງ, ບ່ອນທີ່ມັນຈໍາເປັນຕ້ອງໄດ້ຂະຫຍາຍອອກຕາມແນວນອນຢ່າງໄວວາແລະມາດຕະຖານແລະງ່າຍດາຍ "ຕັດ" ເຄື່ອງ virtual ຈໍານວນຫລາຍສໍາລັບລູກຄ້າ.
3. ໂຄງລ່າງພື້ນຖານຂອງເດັສທັອບສະເໝືອນ (VDI), ບ່ອນທີ່ມີເຄື່ອງ virtual ຜູ້ໃຊ້ຂະໜາດນ້ອຍຫຼາຍເຄື່ອງແລ່ນ ແລະ “ເລື່ອນ” ຢູ່ພາຍໃນກຸ່ມທີ່ເປັນເອກະພາບ.
4. ເຄືອຂ່າຍສາຂາ, ບ່ອນທີ່ແຕ່ລະສາຂາຕ້ອງການມາດຕະຖານ, ທົນທານຕໍ່ຄວາມຜິດ, ແຕ່ໂຄງສ້າງພື້ນຖານລາຄາຖືກຂອງ 15-20 ເຄື່ອງ virtual.
5. ຄອມພິວເຕີ້ແຈກຢາຍໃດໆ (ການບໍລິການຂໍ້ມູນໃຫຍ່, ຕົວຢ່າງ). ບ່ອນທີ່ການໂຫຼດບໍ່ໄດ້ "ເລິກ", ແຕ່ "ກວ້າງ".
6. ສະພາບແວດລ້ອມການທົດສອບທີ່ຄວາມລ່າຊ້າຂະຫນາດນ້ອຍເພີ່ມເຕີມແມ່ນຍອມຮັບ, ແຕ່ມີຂໍ້ຈໍາກັດດ້ານງົບປະມານ, ເພາະວ່າເຫຼົ່ານີ້ແມ່ນການທົດສອບ.

ໃນປັດຈຸບັນ, ມັນແມ່ນສໍາລັບວຽກງານເຫຼົ່ານີ້ທີ່ພວກເຮົາໄດ້ເຮັດ AERODISK vAIR ແລະມັນຢູ່ໃນພວກມັນທີ່ພວກເຮົາສຸມໃສ່ (ປະສົບຜົນສໍາເລັດຈົນເຖິງປະຈຸບັນ). ບາງທີນີ້ຈະມີການປ່ຽນແປງໃນໄວໆນີ້, ເພາະວ່າ ... ໂລກບໍ່ໄດ້ຢືນຢູ່.

ດັ່ງນັ້ນ…

ນີ້ເຮັດສໍາເລັດສ່ວນທໍາອິດຂອງຊຸດຂະຫນາດໃຫຍ່ຂອງບົດຄວາມ;

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

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