ຮູບແບບການເກັບຮັກສາຂໍ້ມູນໃນ Kubernetes

Hey Habr!

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

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

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

ເມື່ອການນໍາໃຊ້ Kubernetes ເຕີບໂຕ, ຄວາມສັບສົນກ່ຽວກັບຮູບແບບການເກັບຮັກສາຂອງມັນ..

ກັບທຸກຄົນແຂ່ງຂັນສໍາລັບສິ້ນຂອງ pie Kubernetes (i.e. , ການເກັບຮັກສາຂໍ້ມູນ), ໃນເວລາທີ່ມັນມາກັບການເກັບຮັກສາຂໍ້ມູນ, ສັນຍານໄດ້ຖືກຈົມນ້ໍາໃນສຽງຫຼາຍ.
Kubernetes ປະກອບຮູບແບບທີ່ທັນສະໄຫມສໍາລັບການພັດທະນາແອັບພລິເຄຊັນ, ການນຳໃຊ້ ແລະການຈັດການ. ຮູບແບບທີ່ທັນສະໄຫມນີ້ decouples ການເກັບຮັກສາຂໍ້ມູນຈາກການຄິດໄລ່. ເພື່ອເຂົ້າໃຈການແຍກຕົວອອກຢ່າງສົມບູນໃນສະພາບການຂອງ Kubernetes, ທ່ານຍັງຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ມີລັດແລະບໍ່ມີລັດແມ່ນຫຍັງ, ແລະການເກັບຮັກສາຂໍ້ມູນທີ່ເຫມາະສົມກັບສິ່ງນັ້ນແນວໃດ. ນີ້ແມ່ນບ່ອນທີ່ວິທີການ REST API ທີ່ໃຊ້ໂດຍ S3 ມີຂໍ້ໄດ້ປຽບທີ່ຊັດເຈນກວ່າວິທີການ POSIX / CSI ຂອງວິທີແກ້ໄຂອື່ນໆ.

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

ຕູ້ບັນຈຸທີ່ບໍ່ມີລັດ

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

ຕູ້ບັນຈຸຂອງລັດ

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

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

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

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງກັນວ່າ ເປັນຫຍັງວິທີການບັນຈຸ stateful ຈິ່ງເປັນແບບແຜນຕ້ານການຢູ່ໃນໂລກທີ່ມີເມຄເປັນສູນກາງ.

ການອອກແບບແອັບພລິເຄຊັນ Cloud-native

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

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

ວິທີການຕູ້ຄອນເທນເນີທີ່ມີລັດບັງຄັບໃຫ້ຂະບວນວິວັດທັງໝົດນີ້ກັບມາຈາກບ່ອນທີ່ມັນເລີ່ມຕົ້ນ!

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

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

• POSIX ແມ່ນ chatty: POSIX semantics ຮຽກຮ້ອງໃຫ້ແຕ່ລະປະຕິບັດການເຊື່ອມໂຍງກັບ metadata ແລະຕົວອະທິບາຍໄຟລ໌ທີ່ຊ່ວຍຮັກສາສະຖານະຂອງການດໍາເນີນງານ. ນີ້ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍທີ່ສໍາຄັນທີ່ບໍ່ມີມູນຄ່າທີ່ແທ້ຈິງ. APIs ການເກັບຮັກສາວັດຖຸ, ໂດຍສະເພາະ S3 API, ກໍາຈັດຄວາມຕ້ອງການເຫຼົ່ານີ້, ອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນໄຟໄຫມ້ແລະຫຼັງຈາກນັ້ນ "ລືມ" ກ່ຽວກັບການໂທ. ການຕອບສະ ໜອງ ຂອງລະບົບການເກັບຮັກສາຊີ້ບອກວ່າການກະ ທຳ ປະສົບຜົນ ສຳ ເລັດຫຼືບໍ່. ຖ້າມັນລົ້ມເຫລວ, ແອັບພລິເຄຊັນສາມາດລອງອີກຄັ້ງ.
• ຂໍ້ຈໍາກັດເຄືອຂ່າຍ: ໃນລະບົບການແຈກຢາຍ, ມັນຫມາຍຄວາມວ່າອາດຈະມີຫຼາຍຄໍາຮ້ອງສະຫມັກທີ່ພະຍາຍາມຂຽນຂໍ້ມູນໃສ່ສື່ທີ່ຕິດຄັດມາດຽວກັນ. ດັ່ງນັ້ນ, ບໍ່ພຽງແຕ່ແອັບພລິເຄຊັນຈະແຂ່ງຂັນກັນສໍາລັບແບນວິດການໂອນຂໍ້ມູນ (ເພື່ອສົ່ງຂໍ້ມູນໄປຍັງສື່), ແຕ່ລະບົບການເກັບຮັກສາຕົວມັນເອງຈະແຂ່ງຂັນສໍາລັບແບນວິດນີ້ໂດຍການສົ່ງຂໍ້ມູນທົ່ວແຜ່ນດິດ. ເນື່ອງຈາກຄວາມຖີ່ຂອງ POSIX, ຈໍານວນການໂທເຄືອຂ່າຍເພີ່ມຂຶ້ນຫຼາຍຄັ້ງ. ໃນທາງກົງກັນຂ້າມ, S3 API ສະຫນອງຄວາມແຕກຕ່າງທີ່ຊັດເຈນລະຫວ່າງການໂທເຄືອຂ່າຍລະຫວ່າງຜູ້ທີ່ມາຈາກລູກຄ້າໄປຫາເຄື່ອງແມ່ຂ່າຍແລະສິ່ງທີ່ເກີດຂື້ນພາຍໃນເຄື່ອງແມ່ຂ່າຍ.
• ຄວາມປອດໄພ: ຮູບແບບຄວາມປອດໄພ POSIX ຖືກອອກແບບມາສໍາລັບການມີສ່ວນຮ່ວມຂອງມະນຸດຢ່າງຫ້າວຫັນ: ຜູ້ບໍລິຫານກໍານົດລະດັບການເຂົ້າເຖິງສະເພາະສໍາລັບແຕ່ລະຜູ້ໃຊ້ຫຼືກຸ່ມ. ແຜນວາດນີ້ຍາກທີ່ຈະປັບຕົວເຂົ້າກັບໂລກທີ່ມີເມຄເປັນໃຈກາງ. ຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມແມ່ນຂຶ້ນກັບແບບຈໍາລອງຄວາມປອດໄພທີ່ອີງໃສ່ API, ບ່ອນທີ່ສິດການເຂົ້າເຖິງຖືກກໍານົດເປັນຊຸດຂອງນະໂຍບາຍ, ບັນຊີການບໍລິການ, ຂໍ້ມູນປະຈໍາຊົ່ວຄາວ, ແລະອື່ນໆ.
• ຄວບຄຸມໄດ້: ຕູ້ຄອນເທນເນີຂອງລັດມີການຄຸ້ມຄອງບາງສ່ວນ. ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການ synchronizing ການເຂົ້າເຖິງຂະຫນານກັບຂໍ້ມູນ, ຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນ, ທັງຫມົດນີ້ຮຽກຮ້ອງໃຫ້ມີການພິຈາລະນາຢ່າງລະມັດລະວັງວ່າຮູບແບບການເຂົ້າເຖິງຂໍ້ມູນໃດທີ່ຈະນໍາໃຊ້. ຊອບແວເພີ່ມເຕີມຕ້ອງໄດ້ຮັບການຕິດຕັ້ງ, ຕິດຕາມ, ແລະກໍາຫນົດຄ່າ, ບໍ່ໄດ້ກ່າວເຖິງຄວາມພະຍາຍາມໃນການພັດທະນາເພີ່ມເຕີມ.

ການໂຕ້ຕອບການເກັບຮັກສາຂໍ້ມູນຕູ້ຄອນເທນເນີ

ໃນຂະນະທີ່ Container Storage Interface (CSI) ໄດ້ເປັນການຊ່ວຍເຫຼືອອັນໃຫຍ່ຫຼວງໃນການຂະຫຍາຍຊັ້ນປະລິມານຂອງ Kubernetes, ບາງສ່ວນຂອງການ outsourcing ມັນໃຫ້ກັບຜູ້ຂາຍການເກັບຮັກສາພາກສ່ວນທີສາມ, ມັນຍັງໄດ້ປະກອບສ່ວນໂດຍບໍ່ໄດ້ຕັ້ງໃຈເຊື່ອວ່າວິທີການບັນຈຸ stateful ເປັນວິທີການແນະນໍາສໍາລັບ. ການເກັບຮັກສາຂໍ້ມູນໃນ Kubernetes.

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

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

ວິທີການທີ່ດີກວ່າ

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

ໃນຫຼັກການ, ຂໍ້ມູນຄໍາຮ້ອງສະຫມັກທັງຫມົດສາມາດແບ່ງອອກເປັນຫຼາຍປະເພດ:

• ຂໍ້ມູນບັນທຶກ
• ຂໍ້ມູນເວລາ
• ຂໍ້ມູນທຸລະກໍາ
• ເມຕາເດຕາ
• ຮູບພາບຕູ້ຄອນເທນເນີ
• ຂໍ້ມູນ Blob (binary large object).

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

ນອກຈາກນັ້ນ, ມັນມັກຈະມີປະສິດທິພາບໃນການສະຫນອງຊັ້ນ caching ຊົ່ວຄາວທີ່ເຮັດຫນ້າທີ່ເປັນບ່ອນເກັບໄຟລ໌ຊົ່ວຄາວສໍາລັບແອັບພລິເຄຊັນ, ແຕ່ແອັບພລິເຄຊັນບໍ່ຄວນຂຶ້ນກັບຊັ້ນນີ້ເປັນແຫຼ່ງຂອງຄວາມຈິງ.

ພື້ນທີ່ຈັດເກັບຂໍ້ມູນຂອງແອັບພລິເຄຊັນ

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

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

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

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

ການເຄື່ອນໄຫວທີ່ເຂັ້ມແຂງຕໍ່ກັບການແຍກຂໍ້ມູນຈາກການຄິດໄລ່

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

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

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

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