ການປຽບທຽບໂດຍຫຍໍ້ຂອງສະຖາປັດຕະຍະກໍາ SDS ຫຼືຊອກຫາເວທີການເກັບຮັກສາທີ່ເຫມາະສົມ (GlusterVsCephVsVirtuozzoStorage)

ບົດຄວາມນີ້ຖືກຂຽນຂື້ນເພື່ອຊ່ວຍໃຫ້ທ່ານເລືອກການແກ້ໄຂທີ່ເຫມາະສົມສໍາລັບຕົວທ່ານເອງແລະເຂົ້າໃຈຄວາມແຕກຕ່າງລະຫວ່າງ SDS ເຊັ່ນ Gluster, Ceph ແລະ Vstorage (Virtuozzo).

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

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

gluster

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍ Gluster, ເຊິ່ງຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໂດຍຜູ້ຜະລິດແພລະຕະຟອມ hyperconverged ກັບ SDS ໂດຍອີງໃສ່ແຫຼ່ງເປີດສໍາລັບສະພາບແວດລ້ອມ virtual ແລະສາມາດພົບເຫັນຢູ່ໃນເວັບໄຊທ໌ RedHat ໃນສ່ວນການເກັບຮັກສາ, ບ່ອນທີ່ທ່ານສາມາດເລືອກຈາກສອງທາງເລືອກ SDS: Gluster ຫຼື Ceph.

Gluster ປະກອບດ້ວຍ stack ຂອງນັກແປ - ບໍລິການທີ່ປະຕິບັດວຽກງານທັງຫມົດຂອງການແຈກຢາຍໄຟລ໌, ແລະອື່ນໆ. Brick ແມ່ນການບໍລິການທີ່ໃຫ້ບໍລິການຫນຶ່ງແຜ່ນ, Volume ແມ່ນປະລິມານ (ສະນຸກເກີ) ທີ່ unites bricks ເຫຼົ່ານີ້. ຕໍ່ໄປແມ່ນການບໍລິການສໍາລັບການແຈກຢາຍໄຟລ໌ເຂົ້າໄປໃນກຸ່ມໂດຍໃຊ້ຟັງຊັນ DHT (ຕາຕະລາງ hash ແຈກຢາຍ). ພວກເຮົາຈະບໍ່ລວມເອົາການບໍລິການ Sharding ໃນຄໍາອະທິບາຍນັບຕັ້ງແຕ່ການເຊື່ອມຕໍ່ຂ້າງລຸ່ມນີ້ຈະອະທິບາຍບັນຫາທີ່ກ່ຽວຂ້ອງກັບມັນ.

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

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

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

ຈາກຄໍາອະທິບາຍຢ່າງເປັນທາງການ ຖາປັດຕະຍະ ພວກເຮົາຍັງເຂົ້າໃຈໂດຍບໍ່ໄດ້ຕັ້ງໃຈວ່າ gluster ເຮັດວຽກເປັນການເກັບຮັກສາໄຟລ໌ຢູ່ເທິງສຸດຂອງ RAID ຮາດແວຄລາສສິກ. ໄດ້ມີການພັດທະນາຄວາມພະຍາຍາມເພື່ອຕັດ (Sharding) ໄຟລ໌ເຂົ້າໄປໃນຕັນ, ແຕ່ທັງຫມົດນີ້ແມ່ນການເພີ່ມເຕີມທີ່ imposes ການສູນເສຍປະສິດທິພາບໃນວິທີການສະຖາປັດຕະທີ່ມີຢູ່ແລ້ວ, ບວກກັບການນໍາໃຊ້ຂອງອົງປະກອບການແຈກຢາຍ freely ດັ່ງກ່າວມີຂໍ້ຈໍາກັດປະສິດທິພາບເປັນ Fuse. ບໍ່ມີບໍລິການ metadata, ເຊິ່ງຈໍາກັດການປະຕິບັດແລະຄວາມຜິດຂອງຄວາມສາມາດໃນການເກັບຮັກສາໃນເວລາທີ່ແຈກຢາຍໄຟລ໌ເຂົ້າໄປໃນບລັອກ. ຕົວຊີ້ວັດການປະຕິບັດທີ່ດີຂຶ້ນສາມາດສັງເກດເຫັນໄດ້ດ້ວຍການຕັ້ງຄ່າ "ແຈກຢາຍແບບຈໍາລອງ" ແລະຈໍານວນໂຫນດຄວນຈະມີຢ່າງຫນ້ອຍ 6 ເພື່ອຈັດວາງແບບຈໍາລອງທີ່ເຊື່ອຖືໄດ້ 3 ທີ່ມີການແຈກຢາຍການໂຫຼດທີ່ດີທີ່ສຸດ.

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


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

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

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

ເຊໂປນ

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

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

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

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

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

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

Vstorage

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

ສິ່ງທີ່ສາມາດຢູ່ຮ່ວມກັນສໍາລັບການເກັບຮັກສາຖັດຈາກການບໍລິການຂອງ kvm-qemu hypervisor, ແລະເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ການບໍລິການຈໍານວນຫນ້ອຍທີ່ພົບເຫັນລໍາດັບຊັ້ນທີ່ເຫມາະສົມທີ່ຫນາແຫນ້ນຂອງອົງປະກອບ: ການບໍລິການລູກຄ້າທີ່ຕິດຕັ້ງຜ່ານ FUSE (ດັດແກ້, ບໍ່ແມ່ນແຫຼ່ງເປີດ), ບໍລິການ metadata MDS (ການບໍລິການ Metadata), ການບໍລິການຂໍ້ມູນການບໍລິການ Chunk, ເຊິ່ງຢູ່ໃນລະດັບທາງດ້ານຮ່າງກາຍເທົ່າກັບຫນຶ່ງແຜ່ນແລະນັ້ນແມ່ນທັງຫມົດ. ໃນແງ່ຂອງຄວາມໄວ, ແນ່ນອນ, ມັນດີທີ່ສຸດທີ່ຈະໃຊ້ຮູບແບບທີ່ທົນທານຕໍ່ຄວາມຜິດທີ່ມີສອງ replicas, ແຕ່ຖ້າທ່ານໃຊ້ caching ແລະເຂົ້າສູ່ລະບົບ SSD drives, ລະຫັດທີ່ທົນທານຕໍ່ຄວາມຜິດພາດ (erase coding or raid6) ສາມາດ overclocked ໄດ້ຢ່າງເຫມາະສົມ. ໂຄງການປະສົມຫຼືດີກວ່າໃນ flash ທັງຫມົດ. ມີຂໍ້ເສຍບາງອັນກັບ EC (ການລຶບລະຫັດ): ເມື່ອປ່ຽນຂໍ້ມູນຫນຶ່ງ, ມັນຈໍາເປັນຕ້ອງຄິດໄລ່ຈໍານວນ parity. ເພື່ອຂ້າມການສູນເສຍທີ່ກ່ຽວຂ້ອງກັບການປະຕິບັດງານນີ້, Ceph ຂຽນໄປຫາ EC ຊ້າລົງແລະບັນຫາການປະຕິບັດສາມາດເກີດຂື້ນໃນລະຫວ່າງການຮ້ອງຂໍສະເພາະໃດຫນຶ່ງ, ເມື່ອ, ຕົວຢ່າງ, ຕັນທັງຫມົດຕ້ອງໄດ້ຮັບການອ່ານ, ແລະໃນກໍລະນີຂອງ Virtuozzo Storage, ການຂຽນບລັອກທີ່ປ່ຽນແປງແມ່ນດໍາເນີນການ. ການນໍາໃຊ້ວິທີການ "ລະບົບໄຟລ໌ທີ່ມີໂຄງສ້າງບັນທຶກ", ເຊິ່ງຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການຄິດໄລ່ຄວາມສະເຫມີພາບ. ເພື່ອຄາດຄະເນປະມານທາງເລືອກທີ່ມີການເລັ່ງການເຮັດວຽກທີ່ມີແລະບໍ່ມີ EC, ມີ ເຄື່ອງຄິດເລກ. - ຕົວເລກສາມາດປະມານໄດ້ໂດຍອີງຕາມຕົວຄູນຄວາມຖືກຕ້ອງຂອງຜູ້ຜະລິດອຸປະກອນ, ແຕ່ຜົນຂອງການຄິດໄລ່ແມ່ນເປັນຕົວຊ່ວຍທີ່ດີໃນການວາງແຜນການຕັ້ງຄ່າ.

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

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

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

ໃຫ້ພິຈາລະນາຂະບວນການບັນທຶກໃນການຕັ້ງຄ່າຮາດແວແບບປະສົມກັບອົງປະກອບທີ່ໄດ້ກ່າວມາຂ້າງເທິງ: ການບັນທຶກເລີ່ມຕົ້ນໄປຫາໂຫນດທີ່ລູກຄ້າໄດ້ລິເລີ່ມມັນ (ການບໍລິການຈຸດເຊື່ອມຕໍ່ FUSE), ແຕ່ອົງປະກອບຕົ້ນສະບັບຂອງບໍລິການ Metadata (MDS) ແນ່ນອນ. ຊີ້ລູກຄ້າໂດຍກົງກັບການບໍລິການ chunk ທີ່ຕ້ອງການ (ການບໍລິການເກັບຮັກສາ CS blocks), ນັ້ນແມ່ນ, MDS ບໍ່ໄດ້ເຂົ້າຮ່ວມໃນຂະບວນການບັນທຶກ, ແຕ່ພຽງແຕ່ຊີ້ນໍາການບໍລິການໄປຫາ chunk ທີ່ກໍານົດໄວ້. ໂດຍທົ່ວໄປ, ພວກເຮົາສາມາດໃຫ້ການປຽບທຽບກັບການບັນທຶກດ້ວຍການຖອກນ້ໍາເຂົ້າໄປໃນຖັງ. ແຕ່ລະຖັງແມ່ນບລັອກຂໍ້ມູນ 256MB.

ນັ້ນແມ່ນ, ແຜ່ນຫນຶ່ງແມ່ນຈໍານວນທີ່ແນ່ນອນຂອງຖັງດັ່ງກ່າວ, ນັ້ນແມ່ນ, ປະລິມານຂອງແຜ່ນແບ່ງອອກດ້ວຍ 256MB. ແຕ່ລະສໍາເນົາຖືກແຈກຢາຍໃຫ້ຫນຶ່ງ node, ອັນທີສອງເກືອບຂະຫນານກັບ node ອື່ນ, ແລະອື່ນໆ ... ຖ້າພວກເຮົາມີສາມ replicas ແລະມີແຜ່ນ SSD ສໍາລັບ cache (ສໍາລັບການອ່ານແລະຂຽນບັນທຶກ), ຫຼັງຈາກນັ້ນການຢືນຢັນການຂຽນຈະເກີດຂຶ້ນຫຼັງຈາກຂຽນ. ບັນທຶກໄປຫາ SSD, ແລະການຕັ້ງຄ່າຂະຫນານຈາກ SSD ຈະສືບຕໍ່ຢູ່ໃນ HDD, ຄືກັບວ່າຢູ່ໃນພື້ນຫລັງ. ໃນກໍລະນີຂອງສາມ replicas, ການບັນທຶກຈະຫມັ້ນສັນຍາຫຼັງຈາກການຢືນຢັນຈາກ SSD ຂອງ node ທີສາມ. ມັນອາດຈະເບິ່ງຄືວ່າຜົນລວມຂອງຄວາມໄວການຂຽນຂອງສາມ SSD ສາມາດແບ່ງອອກໄດ້ສາມແລະພວກເຮົາຈະໄດ້ຮັບຄວາມໄວການຂຽນຂອງຫນຶ່ງ replica, ແຕ່ສໍາເນົາຖືກຂຽນໃນຂະຫນານແລະຄວາມໄວ Latency ເຄືອຂ່າຍມັກຈະສູງກວ່າ SSD, ແລະໃນຄວາມເປັນຈິງການປະຕິບັດການຂຽນຈະຂຶ້ນກັບເຄືອຂ່າຍ. ໃນເລື່ອງນີ້, ເພື່ອເບິ່ງ IOPS ທີ່ແທ້ຈິງ, ທ່ານຈໍາເປັນຕ້ອງໂຫລດ Vstorage ທັງຫມົດຢ່າງຖືກຕ້ອງ ວິທີການ, ນັ້ນແມ່ນ, ການທົດສອບການໂຫຼດທີ່ແທ້ຈິງ, ແລະບໍ່ແມ່ນຫນ່ວຍຄວາມຈໍາແລະແຄດ, ບ່ອນທີ່ມັນຈໍາເປັນຕ້ອງຄໍານຶງເຖິງຂະຫນາດບລັອກຂໍ້ມູນທີ່ຖືກຕ້ອງ, ຈໍານວນຂອງກະທູ້, ແລະອື່ນໆ.

ບັນທຶກການບັນທຶກທີ່ໄດ້ກ່າວມາຂ້າງເທິງໃນ SSD ເຮັດວຽກໃນລັກສະນະທີ່ທັນທີທີ່ຂໍ້ມູນເຂົ້າໄປໃນມັນ, ມັນຈະຖືກອ່ານໂດຍການບໍລິການແລະຂຽນໃສ່ HDD ທັນທີ. ມີຫຼາຍບໍລິການ metadata (MDS) ຕໍ່ກຸ່ມ ແລະຈໍານວນຂອງເຂົາເຈົ້າຖືກກໍານົດໂດຍກຸ່ມ, ເຊິ່ງເຮັດວຽກຕາມ Paxos algorithm. ຈາກທັດສະນະຂອງລູກຄ້າ, ຈຸດ mount FUSE ແມ່ນໂຟເດີເກັບຮັກສາຂອງກຸ່ມທີ່ເຫັນໄດ້ພ້ອມໆກັນກັບທຸກ nodes ໃນ cluster, ແຕ່ລະ node ມີ mounted client ຕາມຫຼັກການນີ້, ດັ່ງນັ້ນການເກັບຮັກສານີ້ມີຢູ່ໃນແຕ່ລະ node.

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

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

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

ມີແຜນທີ່ຈະຂຽນການປຽບທຽບລະຫວ່າງ vSAN, Space Direct Storage, Vstorage ແລະ Nutanix Storage, ການທົດສອບ Vstorage ໃນອຸປະກອນ HPE ແລະ Huawei, ເຊັ່ນດຽວກັນກັບສະຖານະການສໍາລັບການລວມ Vstorage ກັບລະບົບການເກັບຮັກສາຮາດແວພາຍນອກ, ດັ່ງນັ້ນຖ້າຫາກວ່າທ່ານມັກບົດຄວາມ, ມັນຈະເປັນ. ດີໃຈທີ່ຈະໄດ້ຮັບການຕິຊົມຈາກທ່ານ, ເຊິ່ງສາມາດເພີ່ມແຮງຈູງໃຈສໍາລັບບົດຄວາມໃຫມ່, ຄໍານຶງເຖິງຄວາມຄິດເຫັນແລະຄວາມປາດຖະຫນາຂອງທ່ານ.

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