ເຄັດ​ລັບ & tricks ສໍາ​ລັບ​ການ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ Ceph ໃນ​ໂຄງ​ການ​ທີ່​ມີ​ຄວາມ​ຫຍຸ້ງ​ຍາກ​

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

• ການເຄື່ອນຍ້າຍຂໍ້ມູນຈາກ Ceph ເກົ່າໄປຫາອັນໃຫມ່ດ້ວຍການນໍາໃຊ້ບາງສ່ວນຂອງເຄື່ອງແມ່ຂ່າຍທີ່ຜ່ານມາໃນກຸ່ມໃຫມ່;
• ແກ້ໄຂບັນຫາການຈັດສັນພື້ນທີ່ດິດໃນ Ceph.

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

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

ຄໍານໍາກ່ຽວກັບ OSD

ເນື່ອງຈາກສອງໃນສາມສູດທີ່ໄດ້ສົນທະນາແມ່ນອຸທິດຕົນເພື່ອ OSD (Object Storage Daemon), ກ່ອນທີ່ຈະດໍານ້ໍາເຂົ້າໄປໃນພາກປະຕິບັດ - ໂດຍຫຍໍ້ກ່ຽວກັບສິ່ງທີ່ມັນຢູ່ໃນ Ceph ແລະເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ.

ກ່ອນອື່ນ ໝົດ, ມັນຄວນຈະເວົ້າວ່າກຸ່ມ Ceph ທັງຫມົດປະກອບດ້ວຍ OSD ຫຼາຍ. ຫຼາຍມີ, ປະລິມານຂໍ້ມູນຟຣີຫຼາຍໃນ Ceph. ມັນງ່າຍທີ່ຈະເຂົ້າໃຈຈາກທີ່ນີ້ ຟັງຊັນ OSD ຕົ້ນຕໍ: ມັນເກັບຮັກສາຂໍ້ມູນວັດຖຸ Ceph ຢູ່ໃນລະບົບໄຟລ໌ຂອງທຸກ nodes cluster ແລະສະຫນອງການເຂົ້າເຖິງເຄືອຂ່າຍກັບມັນ (ສໍາລັບການອ່ານ, ຂຽນ, ແລະການຮ້ອງຂໍອື່ນໆ).

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

ກໍລະນີທີ 1. ເອົາ OSD ອອກຈາກກຸ່ມ Ceph ຢ່າງປອດໄພໂດຍບໍ່ສູນເສຍຂໍ້ມູນ

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

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

ມາເບິ່ງສະພາບກ່ອນເລີ່ມວຽກ:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

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

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... ແລະອື່ນໆຈົນກ່ວາສູນ.

ຕ້ອງການການດຸ່ນດ່ຽງທີ່ລຽບງ່າຍເພື່ອບໍ່ໃຫ້ສູນເສຍຂໍ້ມູນ. ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະຖ້າ OSD ມີຂໍ້ມູນຈໍານວນຫລາຍ. ເພື່ອໃຫ້ແນ່ໃຈວ່າຫຼັງຈາກປະຕິບັດຄໍາສັ່ງ reweight ທຸກສິ່ງທຸກຢ່າງໄດ້ດີ, ທ່ານສາມາດເຮັດສໍາເລັດມັນ ceph -s ຫຼືຢູ່ໃນປ່ອງຢ້ຽມ terminal ແຍກຕ່າງຫາກດໍາເນີນການ ceph -w ເພື່ອສັງເກດການປ່ຽນແປງໃນເວລາທີ່ແທ້ຈິງ.

ເມື່ອ OSD ຖືກ "ເປົ່າ", ທ່ານສາມາດດໍາເນີນການມາດຕະຖານເພື່ອເອົາມັນອອກ. ເພື່ອເຮັດສິ່ງນີ້, ໂອນ OSD ທີ່ຕ້ອງການໄປຍັງລັດ down:

ceph osd down osd.${ID}

ໃຫ້ "ດຶງ" OSD ອອກຈາກກຸ່ມ:

ceph osd out osd.${ID}

ໃຫ້ຢຸດເຊົາການບໍລິການ OSD ແລະ unmount partition ຂອງມັນຢູ່ໃນ FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

ເອົາ OSD ອອກຈາກ CRUSH ແຜນທີ່:

ceph osd crush remove osd.${ID}

ໃຫ້ລຶບຜູ້ໃຊ້ OSD:

ceph auth del osd.${ID}

ແລະສຸດທ້າຍ, ໃຫ້ເອົາ OSD ຕົວມັນເອງອອກ:

ceph osd rm osd.${ID}

Примечание: ຖ້າທ່ານກໍາລັງໃຊ້ Ceph Luminous ຮຸ່ນຫຼືສູງກວ່າ, ຫຼັງຈາກນັ້ນຂັ້ນຕອນການໂຍກຍ້າຍ OSD ຂ້າງເທິງສາມາດຖືກຫຼຸດລົງເປັນສອງຄໍາສັ່ງ:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

ຖ້າ, ຫຼັງຈາກສໍາເລັດຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ, ທ່ານດໍາເນີນການຄໍາສັ່ງ ceph osd tree, ຫຼັງຈາກນັ້ນມັນຄວນຈະເປັນທີ່ຊັດເຈນວ່າໃນເຄື່ອງແມ່ຂ່າຍທີ່ເຮັດວຽກໄດ້ຖືກປະຕິບັດບໍ່ມີ OSDs ທີ່ດໍາເນີນການຂ້າງເທິງນີ້:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

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

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

ຖ້າບໍ່ມີ OSDs ເຫຼືອຢູ່ໃນເຊີບເວີນີ້, ຫຼັງຈາກນັ້ນ, ຫຼັງຈາກເອົາພວກມັນອອກແລ້ວ, ທ່ານ ຈຳ ເປັນຕ້ອງຍົກເວັ້ນເຄື່ອງແມ່ຂ່າຍຈາກແຜນທີ່ OSD. hv-2ໂດຍການແລ່ນຄໍາສັ່ງຕໍ່ໄປນີ້:

ceph osd crush rm hv-2

ລົບ mon ຈາກເຄື່ອງແມ່ຂ່າຍ hv-2ໂດຍການດໍາເນີນການຄໍາສັ່ງຂ້າງລຸ່ມນີ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍອື່ນ (i. e. ໃນກໍລະນີນີ້, on hv-1):

ceph-deploy mon destroy hv-2

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

ກໍລະນີທີ 2. ການແຈກຢາຍພື້ນທີ່ດິດຢູ່ໃນກຸ່ມ Ceph ທີ່ສ້າງຂຶ້ນແລ້ວ

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

ດັ່ງນັ້ນ: ຫນຶ່ງໃນບັນຫາທົ່ວໄປໃນເວລາທີ່ໃຊ້ Ceph ແມ່ນຈໍານວນທີ່ບໍ່ສົມດຸນຂອງ OSD ແລະ PG ລະຫວ່າງສະນຸກເກີໃນ Ceph.

ກ່ອນອື່ນ ໝົດ, ເນື່ອງຈາກວ່ານີ້, ສະຖານະການອາດຈະເກີດຂື້ນເມື່ອມີ PGs ຫຼາຍເກີນໄປຖືກລະບຸໄວ້ໃນສະນຸກເກີຂະຫນາດນ້ອຍ, ເຊິ່ງເປັນສິ່ງຈໍາເປັນທີ່ຈະໃຊ້ພື້ນທີ່ດິດໃນກຸ່ມທີ່ບໍ່ສົມເຫດສົມຜົນ. ອັນທີສອງ, ໃນທາງປະຕິບັດມີບັນຫາທີ່ຮ້າຍແຮງກວ່າ: ຂໍ້ມູນລົ້ນໃນຫນຶ່ງຂອງ OSD. ອັນນີ້ເຮັດໃຫ້ກຸ່ມຄົນທຳອິດປ່ຽນໄປສູ່ລັດ HEALTH_WARN, ແລະຫຼັງຈາກນັ້ນ HEALTH_ERR. ເຫດຜົນສໍາລັບການນີ້ແມ່ນວ່າ Ceph, ເມື່ອຄິດໄລ່ຈໍານວນຂໍ້ມູນທີ່ມີຢູ່ (ທ່ານສາມາດຊອກຫາມັນໄດ້ໂດຍ MAX AVAIL ໃນ​ການ​ອອກ​ຄໍາ​ສັ່ງ​ ceph df ສໍາລັບແຕ່ລະສະນຸກເກີແຍກຕ່າງຫາກ) ແມ່ນອີງໃສ່ຈໍານວນຂໍ້ມູນທີ່ມີຢູ່ໃນ OSD. ຖ້າບໍ່ມີພື້ນທີ່ພຽງພໍໃນຢ່າງຫນ້ອຍຫນຶ່ງ OSD, ບໍ່ມີຂໍ້ມູນໃດໆທີ່ສາມາດຂຽນໄດ້ຈົນກ່ວາຂໍ້ມູນຖືກແຈກຢາຍຢ່າງຖືກຕ້ອງໃນບັນດາ OSD ທັງຫມົດ.

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

ດັ່ງນັ້ນ, ໃຫ້ຈິນຕະນາການຮູບພາບຕໍ່ໄປນີ້: ກຸ່ມມີສະຖານະພາບ HEALTH_WARN ເນື່ອງຈາກໜຶ່ງໃນ OSD ໝົດພື້ນທີ່. ນີ້ຈະຖືກສະແດງໂດຍຄວາມຜິດພາດ HEALTH_WARN: 1 near full osd. ຂ້າງລຸ່ມນີ້ແມ່ນສູດການຄິດໄລ່ສໍາລັບການອອກຈາກສະຖານະການນີ້.

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

ceph osd reweight osd.${ID} 0.95

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

ໃນກໍລະນີພິເສດຂອງພວກເຮົາ, ມັນທັງຫມົດມາເຖິງ:

• ມູນຄ່າສູງເກີນໄປ replication_count ໃນ​ຫນຶ່ງ​ຂອງ​ສະ​ນຸກ​ເກີ​,
• PG ຫຼາຍເກີນໄປໃນສະນຸກເກີຫນຶ່ງແລະຫນ້ອຍເກີນໄປໃນອີກ.

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

Примечание: ຖ້າທ່ານກໍາລັງຕັ້ງ Ceph cluster ຈາກ scratch, ຫນ້າທີ່ທີ່ເປັນປະໂຫຍດອີກອັນຫນຶ່ງຂອງເຄື່ອງຄິດເລກແມ່ນການຜະລິດຄໍາສັ່ງທີ່ຈະສ້າງ pools ຈາກ scratch ກັບພາລາມິເຕີທີ່ລະບຸໄວ້ໃນຕາຕະລາງ.

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

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

ceph osd pool $pool_name set $replication_size

ແລະຫຼັງຈາກສໍາເລັດຂອງມັນ, ພວກເຮົາປ່ຽນຄ່າພາລາມິເຕີ pg_num и pgp_num ດັ່ງຕໍ່ໄປນີ້:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

ທີ່ສໍາຄັນ: ພວກເຮົາຕ້ອງປ່ຽນຈໍານວນ PGs ຕາມລໍາດັບໃນແຕ່ລະສະນຸກເກີແລະບໍ່ປ່ຽນຄ່າໃນສະນຸກເກີອື່ນຈົນກ່ວາຄໍາເຕືອນຈະຫາຍໄປ "ການຊ້ໍາຊ້ອນຂອງຂໍ້ມູນຊຸດໂຊມ" и "n-ຈໍານວນຂອງ pgs ຫຼຸດລົງ".

ນອກນັ້ນທ່ານຍັງສາມາດກວດເບິ່ງວ່າທຸກສິ່ງທຸກຢ່າງໄປໄດ້ດີໂດຍໃຊ້ຄໍາສັ່ງອອກ ceph health detail и ceph -s.

ກໍລະນີທີ 3. ການເຄື່ອນຍ້າຍເຄື່ອງ virtual ຈາກ LVM ໄປ Ceph RBD

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

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

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

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

virsh pool-dumpxml $ceph_pool

ລາຍລະອຽດຂອງສະນຸກເກີຕ້ອງມີຂໍ້ມູນການເຊື່ອມຕໍ່ກັບ Ceph ກັບຂໍ້ມູນການອະນຸຍາດ.

ຂັ້ນຕອນຕໍ່ໄປແມ່ນວ່າຮູບພາບ LVM ຖືກປ່ຽນເປັນ Ceph RBD. ເວລາປະຕິບັດແມ່ນຂຶ້ນກັບຂະຫນາດຂອງຮູບຕົ້ນຕໍ:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

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

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... ແລະດັດແກ້ຕົ້ນສະບັບ (vm_name.xml). ໃຫ້ຊອກຫາບລັອກທີ່ມີຄໍາອະທິບາຍຂອງແຜ່ນ (ເລີ່ມຕົ້ນດ້ວຍເສັ້ນ <disk type='file' device='disk'> ແລະສິ້ນສຸດດ້ວຍ </disk>) ແລະ​ຫຼຸດ​ລົງ​ເປັນ​ຮູບ​ແບບ​ຕໍ່​ໄປ​ນີ້​:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

ໃຫ້ເບິ່ງລາຍລະອຽດບາງຢ່າງ:

1. ກັບພິທີການ source ທີ່ຢູ່ໃນການເກັບຮັກສາໃນ Ceph RBD ແມ່ນຊີ້ໃຫ້ເຫັນ (ນີ້ແມ່ນທີ່ຢູ່ຊີ້ບອກຊື່ຂອງສະນຸກເກີ Ceph ແລະຮູບພາບ RBD, ເຊິ່ງຖືກກໍານົດຢູ່ໃນຂັ້ນຕອນທໍາອິດ).
2. ຢູ່ໃນທ່ອນໄມ້ secret ປະເພດແມ່ນຊີ້ໃຫ້ເຫັນ ceph, ເຊັ່ນດຽວກັນກັບ UUID ຂອງຄວາມລັບເພື່ອເຊື່ອມຕໍ່ກັບມັນ. uuid ຂອງມັນສາມາດພົບໄດ້ໂດຍໃຊ້ຄໍາສັ່ງ virsh secret-list.
3. ຢູ່ໃນທ່ອນໄມ້ host ທີ່ຢູ່ກັບ Ceph monitors ແມ່ນຊີ້ໃຫ້ເຫັນ.

ຫຼັງ​ຈາກ​ການ​ແກ້​ໄຂ​ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ແລະ​ສໍາ​ເລັດ​ການ​ປ່ຽນ LVM ເປັນ RBD​, ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ການ​ດັດ​ແກ້​ແລະ​ເລີ່ມ​ຕົ້ນ​ເຄື່ອງ virtual ໄດ້​:

virsh define $vm_name.xml
virsh start $vm_name

ມັນເຖິງເວລາທີ່ຈະກວດເບິ່ງວ່າເຄື່ອງ virtual ໄດ້ເລີ່ມຕົ້ນຢ່າງຖືກຕ້ອງ: ທ່ານສາມາດຊອກຫາ, ສໍາລັບການຍົກຕົວຢ່າງ, ໂດຍການເຊື່ອມຕໍ່ກັບມັນຜ່ານ SSH ຫຼືຜ່ານ. virsh.

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

lvremove main/$vm_image_name

ສະຫລຸບ

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

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ມືຂອງພວກເຮົາບໍ່ແມ່ນສໍາລັບການເບື່ອ: ການຟື້ນຟູກຸ່ມ Rook ໃນ K8s"
• «ໄປ Rook ຫຼືບໍ່ Rook - ນັ້ນແມ່ນຄໍາຖາມ"
• «Rook - ຄັງຂໍ້ມູນ "ບໍລິການຕົນເອງ" ສໍາລັບ Kubernetes"
• «ການສ້າງບ່ອນເກັບຂໍ້ມູນຄົງທີ່ດ້ວຍການສະໜອງໃນ Kubernetes ໂດຍອີງໃສ່ Ceph".

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