ການເກັບຮັກສາໃນ Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

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

ດ້ວຍຄວາມຊື່ສັດ, ຂ້ອຍຍອມແພ້ແລະຍອມແພ້ Kubernetes (ຢ່າງຫນ້ອຍສໍາລັບໃນປັດຈຸບັນ). ຂ້ອຍຈະໃຊ້ Heroku. ເປັນຫຍັງ? ເພາະການເກັບຮັກສາ! ໃຜຈະຄິດວ່າຂ້ອຍຈະເຮັດການເກັບຮັກສາຫຼາຍກວ່າ Kubernetes ຕົວມັນເອງ. ຂ້ອຍ​ໃຊ້ Hetzner Cloudເນື່ອງຈາກວ່າມັນມີລາຄາບໍ່ແພງແລະການປະຕິບັດແມ່ນດີແລະຕັ້ງແຕ່ເລີ່ມຕົ້ນຂ້ອຍໄດ້ປະຕິບັດກຸ່ມໂດຍໃຊ້ ນັກແລ່ນ. ຂ້ອຍບໍ່ໄດ້ລອງບໍລິການ Kubernetes ທີ່ມີການຈັດການຈາກ Google/Amazon/Microsoft/DigitalOcean, ແລະອື່ນໆ, ເພາະວ່າຂ້ອຍຢາກຮຽນຮູ້ທຸກຢ່າງດ້ວຍຕົວເອງ. ຂ້ອຍຍັງປະຫຍັດ.

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

ຂ້ອຍໄດ້ທົດສອບການແກ້ໄຂການເກັບຮັກສາ 6-7:

OpenEBS

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

ສະຫຼຸບແລ້ວ, Jiva ແມ່ນໄວເລັກນ້ອຍ, ແລະ LocalPV ໂດຍທົ່ວໄປແມ່ນໄວ, ບໍ່ຮ້າຍແຮງໄປກວ່າດັດຊະນີຂອງແຜ່ນໂດຍກົງ. ບັນຫາກັບ LocalPV ແມ່ນວ່າປະລິມານສາມາດເຂົ້າເຖິງໄດ້ພຽງແຕ່ຢູ່ໃນ node ບ່ອນທີ່ມັນຖືກກະກຽມ, ແລະບໍ່ມີການຈໍາລອງໃດໆ. ຂ້ອຍມີບັນຫາບາງຢ່າງໃນການຟື້ນຟູການສໍາຮອງຂໍ້ມູນຜ່ານ ເຮືອໃບ ຢູ່ໃນກຸ່ມໃຫມ່ເພາະວ່າຊື່ຂອງ node ແຕກຕ່າງກັນ. ຖ້າພວກເຮົາສົນທະນາກ່ຽວກັບການສໍາຮອງຂໍ້ມູນ, cStor ມີ plugin ສໍາລັບ Velero, ທີ່ທ່ານສາມາດເຮັດການສໍາຮອງຂໍ້ມູນນອກສະຖານທີ່ຂອງ snapshots ໃນເວລາໃດຫນຶ່ງ, ເຊິ່ງສະດວກກວ່າການສໍາຮອງຂໍ້ມູນລະດັບໄຟລ໌ກັບ Velero-Restic. ຂ້ອຍ​ໄດ້​ຂຽນ scripts ຫຼາຍ, ເພື່ອເຮັດໃຫ້ມັນງ່າຍຕໍ່ການຈັດການການສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູດ້ວຍ plugin ນີ້. ໂດຍລວມ, ຂ້ອຍມັກ OpenEBS, ແຕ່ການປະຕິບັດຂອງມັນ ...

ຮອກ

Rook ຍັງເປັນແຫຼ່ງເປີດ, ແລະສິ່ງທີ່ກໍານົດມັນນອກເຫນືອຈາກທາງເລືອກທີ່ເຫລືອຢູ່ໃນບັນຊີລາຍຊື່ແມ່ນວ່າມັນເປັນການເກັບຮັກສາ orchestrator ທີ່ຈັດການກັບວຽກງານການຈັດການການເກັບຮັກສາທີ່ສັບສົນກັບ backends ທີ່ແຕກຕ່າງກັນ, e.g. ເຊໂປນ, EdgeFS ແລະອື່ນໆ, ເຊິ່ງເຮັດໃຫ້ວຽກງານງ່າຍຂຶ້ນຫຼາຍ. ຂ້ອຍມີບັນຫາກັບ EfgeFS ເມື່ອຂ້ອຍພະຍາຍາມມັນສອງສາມເດືອນກ່ອນຫນ້ານີ້, ດັ່ງນັ້ນຂ້ອຍໄດ້ທົດສອບສ່ວນໃຫຍ່ກັບ Ceph. Ceph ບໍ່ພຽງແຕ່ສະຫນອງການເກັບຮັກສາຕັນ, ແຕ່ຍັງການເກັບຮັກສາວັດຖຸທີ່ເຫມາະສົມກັບ S3 / Swift ແລະລະບົບໄຟລ໌ແຈກຢາຍ. ສິ່ງທີ່ຂ້ອຍມັກກ່ຽວກັບ Ceph ແມ່ນຄວາມສາມາດໃນການກະຈາຍຂໍ້ມູນປະລິມານໃນທົ່ວແຜ່ນຫຼາຍແຜ່ນເພື່ອໃຫ້ປະລິມານສາມາດນໍາໃຊ້ພື້ນທີ່ດິດຫຼາຍກ່ວາສາມາດໃສ່ໃນແຜ່ນດຽວ. ມັນສະດວກສະບາຍ. ຄຸນນະສົມບັດທີ່ເຢັນອີກອັນຫນຶ່ງແມ່ນວ່າເມື່ອທ່ານເພີ່ມແຜ່ນເຂົ້າໄປໃນກຸ່ມ, ມັນຈະແຈກຢາຍຂໍ້ມູນຄືນໃຫມ່ໂດຍອັດຕະໂນມັດໃນທົ່ວທຸກແຜ່ນ.

Ceph ມີພາບຖ່າຍ, ແຕ່ເທົ່າທີ່ຂ້ອຍຮູ້, ພວກມັນບໍ່ສາມາດຖືກນໍາໃຊ້ໂດຍກົງໃນ Rook/Kubernetes. ແທ້ຈິງແລ້ວ, ຂ້ອຍບໍ່ໄດ້ລົງເລິກໃນເລື່ອງນີ້. ແຕ່ບໍ່ມີການສໍາຮອງຂໍ້ມູນນອກສະຖານທີ່, ດັ່ງນັ້ນທ່ານຈະຕ້ອງໃຊ້ບາງສິ່ງບາງຢ່າງກັບ Velero / Restic, ແຕ່ວ່າມີພຽງແຕ່ການສໍາຮອງຂໍ້ມູນລະດັບໄຟລ໌, ບໍ່ແມ່ນການຖ່າຍຮູບຈຸດໃນເວລາ. ສິ່ງທີ່ຂ້ອຍມັກແທ້ໆກ່ຽວກັບ Rook ແມ່ນວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຮັດວຽກກັບ Ceph - ມັນເຊື່ອງເກືອບທຸກສິ່ງທີ່ສັບສົນແລະສະເຫນີເຄື່ອງມືທີ່ຈະເວົ້າກັບ Ceph ໂດຍກົງເພື່ອແກ້ໄຂບັນຫາ. ແຕ່ຫນ້າເສຍດາຍ, ໃນລະຫວ່າງການທົດສອບຄວາມກົດດັນຂອງປະລິມານ Ceph, ຂ້າພະເຈົ້າໄດ້ສືບຕໍ່ມີບັນຫາກັບ ບັນຫານີ້, ເຊິ່ງເຮັດໃຫ້ Ceph ກາຍເປັນຄວາມບໍ່ຫມັ້ນຄົງ. ມັນຍັງບໍ່ຊັດເຈນວ່ານີ້ແມ່ນແມງໄມ້ໃນ Ceph ຕົວຂອງມັນເອງຫຼືເປັນບັນຫາໃນວິທີທີ່ Rook ຄຸ້ມຄອງ Ceph. ຂ້າ​ພະ​ເຈົ້າ tinkered ກັບ​ການ​ຕັ້ງ​ຄ່າ​ຄວາມ​ຊົງ​ຈໍາ​, ແລະ​ມັນ​ໄດ້​ຮັບ​ການ​ດີກ​ວ່າ​, ແຕ່​ບັນ​ຫາ​ບໍ່​ໄດ້​ແກ້​ໄຂ​ຢ່າງ​ສົມ​ບູນ​. Ceph ມີການປະຕິບັດທີ່ເຫມາະສົມ, ດັ່ງທີ່ທ່ານສາມາດເບິ່ງຢູ່ໃນດັດຊະນີຂ້າງລຸ່ມນີ້. ມັນຍັງມີ dashboard ທີ່ດີ.

Rancher Longhorn

ຂ້ອຍມັກ Longhorn. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ນີ້ແມ່ນການແກ້ໄຂທີ່ດີ. ແທ້ຈິງແລ້ວ, ນັກພັດທະນາເອງ (Rancher Labs) ຍອມຮັບວ່າມັນຍັງບໍ່ທັນເຫມາະສົມກັບສະພາບແວດລ້ອມການເຮັດວຽກ, ແລະນີ້ສະແດງໃຫ້ເຫັນ. ມັນເປັນແຫຼ່ງເປີດແລະມີການປະຕິບັດທີ່ເຫມາະສົມ (ເຖິງແມ່ນວ່າພວກເຂົາຍັງບໍ່ໄດ້ປັບປຸງມັນເທື່ອ), ແຕ່ປະລິມານໃຊ້ເວລາດົນຫຼາຍເພື່ອເຊື່ອມຕໍ່ກັບຝັກ, ແລະໃນກໍລະນີຮ້າຍແຮງທີ່ສຸດມັນໃຊ້ເວລາ 15-16 ນາທີ, ໂດຍສະເພາະຫຼັງຈາກການຟື້ນຟູການສໍາຮອງຂໍ້ມູນຂະຫນາດໃຫຍ່ຫຼືການຍົກລະດັບ. ໜັກວຽກ. ມັນມີພາບຖ່າຍແລະການສໍາຮອງຂໍ້ມູນນອກສະຖານທີ່ຂອງ snapshots ເຫຼົ່ານີ້, ແຕ່ພວກເຂົາເຈົ້າພຽງແຕ່ນໍາໃຊ້ກັບປະລິມານ, ດັ່ງນັ້ນທ່ານຍັງຈະຕ້ອງການບາງສິ່ງບາງຢ່າງເຊັ່ນ: Velero ເພື່ອສໍາຮອງຂໍ້ມູນຊັບພະຍາກອນອື່ນໆ. ການ​ສໍາ​ຮອງ​ແລະ​ການ​ຟື້ນ​ຟູ​ແມ່ນ​ເຊື່ອ​ຖື​ໄດ້​ຫຼາຍ​, ແຕ່ indecently ຊ້າ​. ຢ່າງຮຸນແຮງ, ພຽງແຕ່ຊ້າ incredibly. ການໃຊ້ CPU ແລະການໂຫຼດລະບົບມັກຈະເພີ່ມຂຶ້ນເມື່ອເຮັດວຽກກັບຂໍ້ມູນຂະໜາດກາງໃນ Longhorn. ມີ dashboard ສະດວກໃນການຄຸ້ມຄອງ Longhorn. ຂ້ອຍເວົ້າແລ້ວວ່າຂ້ອຍມັກ Longhorn, ແຕ່ມັນຕ້ອງການວຽກບາງຢ່າງ.

StorageOS

StorageOS ແມ່ນຜະລິດຕະພັນທີ່ຈ່າຍເງິນທໍາອິດໃນບັນຊີລາຍຊື່. ມັນມີຮຸ່ນນັກພັດທະນາທີ່ມີຂະຫນາດການເກັບຮັກສາທີ່ຖືກຄຸ້ມຄອງຈໍາກັດຂອງ 500GB, ແຕ່ຂ້ອຍບໍ່ຄິດວ່າມີຂໍ້ຈໍາກັດກ່ຽວກັບຈໍານວນ nodes. ພະແນກການຂາຍບອກຂ້ອຍວ່າຄ່າໃຊ້ຈ່າຍເລີ່ມຕົ້ນທີ່ $ 125 ຕໍ່ເດືອນສໍາລັບ 1 TB, ຖ້າຂ້ອຍຈື່ໄດ້ຢ່າງຖືກຕ້ອງ. ມີ dashboard ພື້ນຖານແລະ CLI ​​ທີ່ສະດວກ, ແຕ່ບາງສິ່ງບາງຢ່າງທີ່ແປກປະຫຼາດແມ່ນເກີດຂຶ້ນກັບການປະຕິບັດ: ໃນບາງມາດຕະຖານທີ່ຂ້ອນຂ້າງຂ້ອນຂ້າງ, ແຕ່ໃນການທົດສອບຄວາມກົດດັນຂອງປະລິມານຂ້ອຍບໍ່ມັກຄວາມໄວທັງຫມົດ. ໂດຍທົ່ວໄປ, ຂ້ອຍບໍ່ຮູ້ວ່າຈະເວົ້າຫຍັງ. ສະນັ້ນຂ້ອຍບໍ່ເຂົ້າໃຈຫຼາຍແທ້ໆ. ບໍ່ມີການສໍາຮອງຂໍ້ມູນນອກສະຖານທີ່ຢູ່ທີ່ນີ້ແລະທ່ານຍັງຈະຕ້ອງໃຊ້ Velero ກັບ Restic ເພື່ອສໍາຮອງຂໍ້ມູນປະລິມານ. ມັນເປັນເລື່ອງແປກ, ເພາະວ່າຜະລິດຕະພັນຖືກຈ່າຍ. ແລະນັກພັດທະນາບໍ່ໄດ້ກະຕືລືລົ້ນທີ່ຈະຕິດຕໍ່ສື່ສານກ່ຽວກັບ Slack.

Robin

ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ກ່ຽວກັບ Robin ໃນ Reddit ຈາກຜູ້ອໍານວຍການດ້ານວິຊາການຂອງພວກເຂົາ. ຂ້ອຍບໍ່ເຄີຍໄດ້ຍິນເລື່ອງລາວມາກ່ອນ. ອາດຈະເປັນຍ້ອນວ່າຂ້ອຍກໍາລັງຊອກຫາວິທີແກ້ໄຂຟຣີ, ແຕ່ Robin ແມ່ນຈ່າຍ. ພວກມັນມີລຸ້ນຟຣີທີ່ມີພື້ນທີ່ເກັບຂໍ້ມູນ 10TB ແລະສາມຂໍ້. ໂດຍລວມ, ຜະລິດຕະພັນແມ່ນຂ້ອນຂ້າງມີກຽດແລະມີຄຸນສົມບັດທີ່ສວຍງາມ. ມີ CLI ທີ່ດີ, ແຕ່ສິ່ງທີ່ coolest ແມ່ນວ່າທ່ານສາມາດ snapshot ແລະ backup ຄໍາຮ້ອງສະຫມັກທັງຫມົດ (ໃນຕົວເລືອກຊັບພະຍາກອນນີ້ເອີ້ນວ່າ Helm releases ຫຼື "flex apps"), ລວມທັງປະລິມານແລະຊັບພະຍາກອນອື່ນໆ, ດັ່ງນັ້ນທ່ານສາມາດເຮັດໄດ້ໂດຍບໍ່ມີການ Velero. ແລະທຸກສິ່ງທຸກຢ່າງຈະດີເລີດຖ້າບໍ່ແມ່ນສໍາລັບລາຍລະອຽດນ້ອຍໆ: ຖ້າທ່ານຟື້ນຟູ (ຫຼື "ນໍາເຂົ້າ", ດັ່ງທີ່ມັນຖືກເອີ້ນວ່າ Robin) ຄໍາຮ້ອງສະຫມັກໃນກຸ່ມໃຫມ່ - ຕົວຢ່າງ, ໃນກໍລະນີຂອງການຟື້ນຕົວຈາກໄພພິບັດ - ການຟື້ນຟູ, ແນ່ນອນ, ເຮັດວຽກ, ແຕ່ສືບຕໍ່ສໍາຮອງຂໍ້ມູນຄໍາຮ້ອງສະຫມັກທີ່ມັນຖືກຫ້າມ. ນີ້ແມ່ນເປັນໄປບໍ່ໄດ້ໃນການປ່ອຍນີ້, ຍ້ອນວ່ານັກພັດທະນາໄດ້ຢືນຢັນ. ນີ້ແມ່ນ, ເຮັດໃຫ້ມັນອ່ອນໂຍນ, ແປກ, ໂດຍສະເພາະແມ່ນການພິຈາລະນາຂໍ້ດີອື່ນໆ (ຕົວຢ່າງ, ການສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູໄວຢ່າງບໍ່ຫນ້າເຊື່ອ). ນັກພັດທະນາສັນຍາວ່າຈະແກ້ໄຂທຸກສິ່ງທຸກຢ່າງໂດຍການປ່ອຍຕໍ່ໄປ. ການປະຕິບັດໂດຍທົ່ວໄປແມ່ນດີ, ແຕ່ຂ້ອຍສັງເກດເຫັນຄວາມແປກປະຫລາດ: ຖ້າຂ້ອຍແລ່ນດັດຊະນີໂດຍກົງໃສ່ປະລິມານທີ່ຕິດກັບເຈົ້າພາບ, ຄວາມໄວໃນການອ່ານແມ່ນໄວກວ່າແລ່ນປະລິມານດຽວກັນຈາກພາຍໃນຝັກ. ຜົນໄດ້ຮັບອື່ນໆທັງຫມົດແມ່ນຄືກັນ, ແຕ່ໃນທາງທິດສະດີບໍ່ຄວນມີຄວາມແຕກຕ່າງ. ເຖິງແມ່ນວ່າພວກເຂົາກໍາລັງເຮັດວຽກກັບມັນ, ຂ້ອຍຮູ້ສຶກເສຍໃຈກັບບັນຫາກັບການຟື້ນຟູແລະການສໍາຮອງ - ຂ້ອຍຄິດວ່າໃນທີ່ສຸດຂ້ອຍໄດ້ພົບການແກ້ໄຂທີ່ເຫມາະສົມ, ແລະຂ້ອຍກໍ່ເຕັມໃຈທີ່ຈະຈ່າຍຄ່າມັນເມື່ອຂ້ອຍຕ້ອງການພື້ນທີ່ຫຼືຫຼາຍເຄື່ອງແມ່ຂ່າຍ.

portworx

ຂ້ອຍບໍ່ມີຫຍັງເວົ້າຫຼາຍຢູ່ທີ່ນີ້. ນີ້ແມ່ນຜະລິດຕະພັນທີ່ຈ່າຍ, ເຢັນແລະລາຄາແພງເທົ່າທຽມກັນ. ການປະຕິບັດແມ່ນເຮັດໃຫ້ປະລາດພຽງແຕ່. ນີ້ແມ່ນຕົວຊີ້ວັດທີ່ດີທີ່ສຸດຈົນເຖິງປະຈຸບັນ. Slack ບອກຂ້ອຍວ່າລາຄາເລີ່ມຕົ້ນທີ່ $ 205 ຕໍ່ເດືອນຕໍ່ node, ດັ່ງທີ່ລະບຸໄວ້ໃນ GKE Marketplace ຂອງ Google. ຂ້ອຍບໍ່ຮູ້ວ່າມັນຈະລາຄາຖືກກວ່າຖ້າທ່ານຊື້ໂດຍກົງ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ຈ່າຍ​ໄດ້​ຢ່າງ​ໃດ​ກໍ​ຕາມ, ສະ​ນັ້ນ​ຂ້າ​ພະ​ເຈົ້າ​ຜິດ​ຫວັງ​ຫຼາຍ​ທີ່​ໃບ​ອະ​ນຸ​ຍາດ​ຜູ້​ພັດ​ທະ​ນາ (ສູງ​ເຖິງ 1 TB ແລະ 3 nodes) ແມ່ນ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ບໍ່​ມີ​ປະ​ໂຫຍດ​ກັບ Kubernetes ເວັ້ນ​ເສຍ​ແຕ່​ວ່າ​ທ່ານ​ຈະ​ມີ​ຄວາມ​ສຸກ​ກັບ​ການ​ສະ​ຫນອງ​ສະ​ຖິ​ຕິ. ຂ້ອຍຫວັງວ່າໃບອະນຸຍາດປະລິມານຈະຫຼຸດລົງໂດຍອັດຕະໂນມັດກັບນັກພັດທະນາໃນຕອນທ້າຍຂອງໄລຍະເວລາທົດລອງ, ແຕ່ມັນບໍ່ເກີດຂຶ້ນ. ໃບອະນຸຍາດນັກພັດທະນາສາມາດຖືກນໍາໃຊ້ໂດຍກົງກັບ Docker, ແລະການຕັ້ງຄ່າໃນ Kubernetes ແມ່ນຫຍຸ້ງຍາກຫຼາຍແລະຈໍາກັດ. ແນ່ນອນ, ຂ້ອຍມັກແຫຼ່ງເປີດ, ແຕ່ຖ້າຂ້ອຍມີເງິນ, ຂ້ອຍແນ່ນອນຈະເລືອກ Portworx. ມາຮອດປະຈຸ, ການປະຕິບັດຂອງມັນພຽງແຕ່ບໍ່ໄດ້ປຽບທຽບກັບທາງເລືອກອື່ນ.

Linstor

ຂ້າພະເຈົ້າໄດ້ເພີ່ມພາກນີ້ຫຼັງຈາກການພິມເຜີຍແຜ່, ເມື່ອຜູ້ອ່ານຄົນຫນຶ່ງແນະນໍາໃຫ້ພະຍາຍາມ Linstor. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ພະ​ຍາ​ຍາມ​ມັນ​ແລະ​ຂ້າ​ພະ​ເຈົ້າ​ມັກ​ມັນ​! ແຕ່ພວກເຮົາຍັງຈໍາເປັນຕ້ອງຂຸດເລິກຕື່ມອີກ. ຕອນນີ້ຂ້ອຍສາມາດເວົ້າໄດ້ວ່າການປະຕິບັດບໍ່ແມ່ນສິ່ງທີ່ບໍ່ດີ (ຂ້ອຍໄດ້ເພີ່ມຜົນໄດ້ຮັບ benchmark ຂ້າງລຸ່ມນີ້). ໂດຍພື້ນຖານແລ້ວ, ຂ້ອຍໄດ້ຮັບການປະຕິບັດຄືກັນກັບແຜ່ນໂດຍກົງ, ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍໃດໆ. (ຢ່າຖາມວ່າເປັນຫຍັງ Portworx ມີຕົວເລກທີ່ດີກ່ວາດັດຊະນີໄດໂດຍກົງ. ຂ້ອຍບໍ່ມີຄວາມຄິດ. Magic, ຂ້ອຍເດົາ.) ດັ່ງນັ້ນ Linstor ເບິ່ງຄືວ່າມີປະສິດທິພາບຫຼາຍ. ມັນບໍ່ຍາກຫຼາຍທີ່ຈະຕິດຕັ້ງ, ແຕ່ມັນບໍ່ງ່າຍຄືກັບທາງເລືອກອື່ນ. ທໍາອິດຂ້ອຍຕ້ອງຕິດຕັ້ງ Linstor (ໂມດູນ kernel ແລະເຄື່ອງມື / ການບໍລິການ) ແລະຕັ້ງຄ່າ LVM ສໍາລັບການສະຫນອງບາງໆແລະການສະຫນັບສະຫນູນ snapshot ຢູ່ນອກ Kubernetes, ໂດຍກົງໃນໂຮດ, ແລະຫຼັງຈາກນັ້ນສ້າງຊັບພະຍາກອນທີ່ຈໍາເປັນເພື່ອນໍາໃຊ້ການເກັບຮັກສາຈາກ Kubernetes. ຂ້ອຍບໍ່ມັກວ່າມັນບໍ່ເຮັດວຽກຢູ່ໃນ CentOS ແລະຂ້ອຍຕ້ອງໃຊ້ Ubuntu. ບໍ່ຂີ້ຮ້າຍ, ແນ່ນອນ, ແຕ່ເປັນທີ່ຫນ້າລໍາຄານເລັກນ້ອຍ, ເພາະວ່າເອກະສານ (ເຊິ່ງດີເລີດ, ໂດຍວິທີທາງການ) ກ່າວເຖິງຫລາຍຊຸດທີ່ບໍ່ສາມາດພົບເຫັນຢູ່ໃນບ່ອນເກັບມ້ຽນ Epel ທີ່ລະບຸໄວ້. Linstor ມີພາບຖ່າຍ, ແຕ່ບໍ່ແມ່ນການສໍາຮອງຂໍ້ມູນນອກສະຖານທີ່, ດັ່ງນັ້ນອີກເທື່ອຫນຶ່ງຂ້າພະເຈົ້າຕ້ອງໃຊ້ Velero ກັບ Restic ເພື່ອສໍາຮອງຂໍ້ມູນປະລິມານ. ຂ້ອຍຕ້ອງການພາບຖ່າຍແທນທີ່ຈະເປັນການສໍາຮອງຂໍ້ມູນລະດັບໄຟລ໌, ແຕ່ນີ້ສາມາດທົນທານໄດ້ຖ້າການແກ້ໄຂແມ່ນປະຕິບັດແລະເຊື່ອຖືໄດ້. Linstor ແມ່ນແຫຼ່ງເປີດແຕ່ໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ຈ່າຍ. ຖ້າຂ້ອຍເຂົ້າໃຈຢ່າງຖືກຕ້ອງ, ມັນສາມາດຖືກນໍາໃຊ້ໂດຍບໍ່ມີຂໍ້ຈໍາກັດ, ເຖິງແມ່ນວ່າທ່ານບໍ່ມີສັນຍາສະຫນັບສະຫນູນ, ແຕ່ນີ້ຕ້ອງໄດ້ຮັບການຊີ້ແຈງ. ຂ້ອຍບໍ່ຮູ້ວ່າ Linstor ທົດສອບແນວໃດສໍາລັບ Kubernetes, ແຕ່ຊັ້ນເກັບຮັກສາຕົວມັນເອງແມ່ນຢູ່ນອກ Kubernetes ແລະ, ປາກົດຂື້ນ, ການແກ້ໄຂບໍ່ປາກົດໃນມື້ວານນີ້, ດັ່ງນັ້ນມັນອາດຈະຖືກທົດສອບໃນສະພາບຕົວຈິງແລ້ວ. ມີການແກ້ໄຂຢູ່ທີ່ນີ້ທີ່ຈະເຮັດໃຫ້ຂ້ອຍປ່ຽນໃຈແລະກັບຄືນໄປຫາ Kubernetes? ຂ້ອຍ​ບໍ່​ຮູ້. ພວກເຮົາຍັງຈໍາເປັນຕ້ອງໄດ້ຂຸດເລິກແລະສຶກສາການຈໍາລອງແບບຈໍາລອງ. ໃຫ້ເຮົາເບິ່ງ. ແຕ່ຄວາມປະທັບໃຈຄັ້ງທໍາອິດແມ່ນດີ. ຂ້ອຍຢາກໃຊ້ກຸ່ມ Kubernetes ຂອງຂ້ອຍເອງແທນທີ່ຈະເປັນ Heroku ເພື່ອໃຫ້ມີອິດສະລະພາບຫຼາຍຂຶ້ນ ແລະຮຽນຮູ້ສິ່ງໃໝ່ໆ. ເນື່ອງຈາກ Linstor ບໍ່ແມ່ນການຕິດຕັ້ງງ່າຍຄືກັບຄົນອື່ນ, ຂ້ອຍຈະຂຽນບົດເລື່ອງກ່ຽວກັບມັນໃນໄວໆນີ້.

ມາດຕະຖານ

ແຕ່ຫນ້າເສຍດາຍ, ຂ້າພະເຈົ້າບໍ່ໄດ້ບັນທຶກຈໍານວນຫຼາຍກ່ຽວກັບການປຽບທຽບເພາະວ່າຂ້ອຍບໍ່ຄິດວ່າຂ້ອຍຈະຂຽນກ່ຽວກັບມັນ. ຂ້າພະເຈົ້າມີພຽງແຕ່ຜົນໄດ້ຮັບຈາກດັດຊະນີ fio ພື້ນຖານແລະພຽງແຕ່ສໍາລັບກຸ່ມ node ດຽວ, ດັ່ງນັ້ນຂ້າພະເຈົ້າບໍ່ມີຕົວເລກສໍາລັບ replicated configurations ເທື່ອ. ແຕ່ຈາກຜົນໄດ້ຮັບເຫຼົ່ານີ້ທ່ານສາມາດໄດ້ຮັບຄວາມຄິດທີ່ຫຍາບຄາຍຂອງສິ່ງທີ່ຄາດຫວັງຈາກແຕ່ລະທາງເລືອກ, ເພາະວ່າຂ້ອຍປຽບທຽບພວກມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຟັງດຽວກັນ, 4 cores, 16 GB ຂອງ RAM, ມີແຜ່ນ 100 GB ເພີ່ມເຕີມສໍາລັບປະລິມານທີ່ທົດສອບ. ຂ້ອຍແລ່ນມາດຕະຖານສາມຄັ້ງສໍາລັບແຕ່ລະການແກ້ໄຂແລະຄິດໄລ່ຜົນໄດ້ຮັບໂດຍສະເລ່ຍ, ບວກກັບຂ້ອຍປັບການຕັ້ງຄ່າເຊີຟເວີສໍາລັບແຕ່ລະຜະລິດຕະພັນ. ທັງໝົດນີ້ແມ່ນບໍ່ມີວິທະຍາສາດຢ່າງສິ້ນເຊີງ, ພຽງແຕ່ເພື່ອໃຫ້ທ່ານມີຄວາມຄິດທົ່ວໄປ. ໃນການທົດສອບອື່ນໆ, ຂ້າພະເຈົ້າໄດ້ຄັດລອກຮູບພາບແລະວິດີໂອ 38 GB ຈາກປະລິມານເພື່ອທົດສອບການອ່ານແລະການຂຽນ, ແຕ່, ອະນິຈາ, ຂ້າພະເຈົ້າບໍ່ໄດ້ບັນທຶກຕົວເລກ. ໃນສັ້ນ: Portworkx ແມ່ນໄວກວ່າ.

ສໍາລັບມາດຕະຖານປະລິມານຂ້າພະເຈົ້າໄດ້ໃຊ້ manifest ນີ້:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

ຂ້າພະເຈົ້າທໍາອິດສ້າງປະລິມານທີ່ມີຫ້ອງຮຽນການເກັບຮັກສາທີ່ເຫມາະສົມແລະຫຼັງຈາກນັ້ນດໍາເນີນການກັບ fio ຫລັງ scenes. ຂ້ອຍເອົາ 1 GB ເພື່ອປະເມີນປະສິດທິພາບແລະບໍ່ລໍຖ້າດົນເກີນໄປ. ນີ້ແມ່ນຜົນໄດ້ຮັບ:

ຂ້າພະເຈົ້າໄດ້ເນັ້ນໃຫ້ເຫັນຄ່າທີ່ດີທີ່ສຸດສໍາລັບແຕ່ລະ metric ໃນສີຂຽວແລະຮ້າຍແຮງທີ່ສຸດເປັນສີແດງ.

ສະຫລຸບ

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

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