LVM ແລະ Matryoshka ມີຫຍັງຮ່ວມກັນ?

ເວລາທີ່ໃຊ້ເວລາຂອງມື້.
ຂ້ອຍຢາກແບ່ງປັນກັບຊຸມຊົນປະສົບການການປະຕິບັດຂອງຂ້ອຍໃນການສ້າງລະບົບການເກັບຮັກສາຂໍ້ມູນສໍາລັບ KVM ໂດຍໃຊ້ md RAID + LVM.

ໂຄງ​ການ​ຈະ​ປະ​ກອບ​ມີ​:

• ການກໍ່ສ້າງ md RAID 1 ຈາກ NVMe SSD.
• ການປະກອບ md RAID 6 ຈາກ SATA SSD ແລະໄດປົກກະຕິ.
• ຄຸນສົມບັດຂອງການປະຕິບັດການ TRIM/DISCARD ໃນ SSD RAID 1/6.
• ການສ້າງ md RAID 1/6 array ທີ່ສາມາດເລີ່ມຕົ້ນໄດ້ໃນຊຸດຂອງແຜ່ນທົ່ວໄປ.
• ການຕິດຕັ້ງລະບົບໃນ NVMe RAID 1 ເມື່ອບໍ່ມີການຮອງຮັບ NVMe ໃນ BIOS.
• ໃຊ້ LVM cache ແລະ LVM ບາງໆ.
• ການ​ນໍາ​ໃຊ້ BTRFS snapshots ແລະ​ສົ່ງ / ຮັບ​ສໍາ​ລັບ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​.
• ໃຊ້ຮູບຖ່າຍບາງໆ LVM ແລະ thin_delta ສຳລັບການສຳຮອງຂໍ້ມູນແບບ BTRFS.

ຖ້າທ່ານສົນໃຈ, ກະລຸນາເບິ່ງແມວ.

Statement

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

• ຂົ້ວ NVMe SSDs.
• ໃຊ້ຊັບພະຍາກອນການບັນທຶກແລະຄວາມລົ້ມເຫຼວຂອງ SSD drives ຢ່າງສົມບູນ.
• ການສູນເສຍຂໍ້ມູນທັງໝົດໃນໄດຣຟ໌ທັງໝົດ, ລວມທັງສຳເນົາສຳຮອງ.
• ຮາດແວຄອມພິວເຕີມີບັນຫາ.
• ເສຍເວລາ, ເສັ້ນປະສາດ ແລະເງິນ.
• ຜົນສະທ້ອນອື່ນໆທີ່ບໍ່ໄດ້ລະບຸໄວ້ຂ້າງເທິງ.

ເຫລໍກ

ມີຢູ່ຄື:

ເມນບອດຈາກປະມານ 2013 ກັບຊິບເຊັດ Z87, ສໍາເລັດດ້ວຍ Intel Core i7 / Haswell.

• ຫນ່ວຍປະມວນຜົນ 4 ແກນ, 8 threads
• RAM 32 GB DDR3
• 1 x 16 ຫຼື 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps SATA 3 ເຊື່ອມຕໍ່

ອະແດັບເຕີ SAS LSI SAS9211-8I ກະພິບເປັນໂໝດ IT / HBA. ເຟີມແວທີ່ເປີດໃຊ້ RAID ໄດ້ຖືກແທນທີ່ດ້ວຍເຟີມແວ HBA ໂດຍເຈດຕະນາເພື່ອ:

1. ທ່ານ​ສາ​ມາດ​ຖິ້ມ​ອະ​ແດບ​ເຕີ​ນີ້​ອອກ​ໄດ້​ທຸກ​ເວ​ລາ​ແລະ​ທົດ​ແທນ​ມັນ​ກັບ​ອັນ​ໃດ​ຫນຶ່ງ​ທີ່​ທ່ານ​ພົບ​ເຫັນ​.
2. TRIM/Discard ເຮັດວຽກຕາມປົກກະຕິໃນແຜ່ນ, ເພາະວ່າ... ໃນ RAID firmware ຄໍາສັ່ງເຫຼົ່ານີ້ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນທັງຫມົດ, ແລະ HBA, ໂດຍທົ່ວໄປ, ບໍ່ສົນໃຈວ່າຄໍາສັ່ງໃດຖືກສົ່ງຜ່ານລົດເມ.

ຮາດດິດ - 8 ຊິ້ນຂອງ HGST Travelstar 7K1000 ທີ່ມີຄວາມຈຸ 1 TB ໃນຮູບແບບ 2.5, ສໍາລັບແລັບທັອບ. ໄດຣຟ໌ເຫຼົ່ານີ້ໃນເມື່ອກ່ອນຢູ່ໃນອາເຣ RAID 6. ພວກເຂົາເຈົ້າຍັງຈະມີການນໍາໃຊ້ໃນລະບົບໃຫມ່. ເພື່ອເກັບຮັກສາສໍາຮອງຂໍ້ມູນໃນທ້ອງຖິ່ນ.

ເພີ່ມຕື່ມ:

6 ຊິ້ນ SATA SSD ຮຸ່ນ Samsung 860 QVO 2TB. SSDs ເຫຼົ່ານີ້ຕ້ອງການປະລິມານຂະຫນາດໃຫຍ່, ມີ cache SLC, ຄວາມຫນ້າເຊື່ອຖື, ແລະລາຄາຕໍ່າແມ່ນຕ້ອງການ. ຕ້ອງຮອງຮັບການຍົກເລີກ/ສູນ, ເຊິ່ງຖືກກວດສອບໂດຍແຖວໃນ dmesg:

kernel: ata1.00: Enabling discard_zeroes_data

2 ຊິ້ນຂອງ NVMe SSD ຮຸ່ນ Samsung SSD 970 EVO 500GB.

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

ອະແດັບເຕີ StarTech PEX8M2E2 ສໍາລັບ 2 x NVMe SSD ຕິດຕັ້ງຢູ່ໃນຊ່ອງ PCIe 3.0 8x. ນີ້, ອີກເທື່ອຫນຶ່ງ, ແມ່ນພຽງແຕ່ HBA, ແຕ່ສໍາລັບ NVMe. ມັນແຕກຕ່າງຈາກອະແດບເຕີລາຄາຖືກທີ່ມັນບໍ່ຕ້ອງການການສະຫນັບສະຫນູນ PCIe bifurcation ຈາກເມນບອດເນື່ອງຈາກມີສະວິດ PCIe ທີ່ມີໃນຕົວ. ມັນຈະເຮັດວຽກແມ້ແຕ່ຢູ່ໃນລະບົບເກົ່າແກ່ທີ່ສຸດກັບ PCIe, ເຖິງແມ່ນວ່າມັນເປັນຊ່ອງ x1 PCIe 1.0. ຕາມທໍາມະຊາດ, ໃນຄວາມໄວທີ່ເຫມາະສົມ. ບໍ່ມີ RAIDs ຢູ່ທີ່ນັ້ນ. ບໍ່ມີ BIOS ຢູ່ໃນເຄື່ອງ. ດັ່ງນັ້ນ, ລະບົບຂອງທ່ານຈະບໍ່ຮຽນຮູ້ທີ່ຈະບູດກັບ NVMe, ຫນ້ອຍລົງ NVMe RAID ຂອບໃຈອຸປະກອນນີ້.

ອົງປະກອບນີ້ແມ່ນຍ້ອນມີພຽງ 8x PCIe 3.0 ຟຣີດຽວໃນລະບົບ, ແລະຖ້າມີ 2 ສະລັອດຟຣີ, ມັນສາມາດທົດແທນໄດ້ຢ່າງງ່າຍດາຍດ້ວຍສອງ penny PEX4M2E1 ຫຼື analogues, ເຊິ່ງສາມາດຊື້ໄດ້ທຸກບ່ອນໃນລາຄາ 600. ຮູເບີນ.

ການປະຕິເສດທຸກປະເພດຂອງຮາດແວຫຼືຊິບເຊັດ / BIOS RAIDs ທີ່ຖືກສ້າງຂື້ນໂດຍເຈດຕະນາ, ເພື່ອໃຫ້ສາມາດທົດແທນລະບົບທັງຫມົດໄດ້ຢ່າງສົມບູນ, ຍົກເວັ້ນ SSD / HDD ຕົວເອງ, ໃນຂະນະທີ່ຮັກສາຂໍ້ມູນທັງຫມົດ. ໂດຍຫລັກການແລ້ວ, ເພື່ອໃຫ້ທ່ານສາມາດປະຫຍັດເຖິງແມ່ນລະບົບປະຕິບັດການທີ່ຕິດຕັ້ງໃນເວລາທີ່ຍ້າຍໄປຫາຮາດແວໃຫມ່ / ທີ່ແຕກຕ່າງກັນຫມົດ. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າມີພອດ SATA ແລະ PCIe. ມັນຄ້າຍຄືກັບແຜ່ນຊີດີທີ່ມີຊີວິດຊີວາຫຼື flash drive ທີ່ສາມາດເປີດໄດ້, ພຽງແຕ່ໄວຫຼາຍແລະ bulky ເລັກນ້ອຍ.

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

ດີ, ແລະ, ແນ່ນອນ, ສໍາລັບການທົດລອງກັບວິທີການທີ່ແຕກຕ່າງກັນຂອງ SSD caching ໃນ Linux.

ການໂຈມຕີຮາດແວແມ່ນຫນ້າເບື່ອ. ເປີດມັນ. ມັນເຮັດວຽກຫຼືບໍ່ໄດ້. ແລະກັບ mdadm ມີທາງເລືອກສະເຫມີ.

ຊອບແວ

ກ່ອນຫນ້ານີ້, Debian 8 Jessie ໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນຮາດແວ, ເຊິ່ງຢູ່ໃກ້ກັບ EOL. RAID 6 ໄດ້ຖືກປະກອບມາຈາກ HDDs ທີ່ກ່າວມາຂ້າງເທິງທີ່ຈັບຄູ່ກັບ LVM. ມັນແລ່ນເຄື່ອງ virtual ໃນ kvm/libvirt.

ເນື່ອງຈາກວ່າ ຜູ້ຂຽນມີປະສົບການທີ່ເຫມາະສົມໃນການສ້າງ flash drives SATA / NVMe ທີ່ສາມາດ bootable portable, ແລະເຊັ່ນດຽວກັນ, ເພື່ອບໍ່ໃຫ້ທໍາລາຍແມ່ແບບປົກກະຕິ, Ubuntu 18.04 ໄດ້ຖືກເລືອກເປັນລະບົບເປົ້າຫມາຍ, ເຊິ່ງມີຄວາມຫມັ້ນຄົງພຽງພໍແລ້ວ, ແຕ່ຍັງມີເວລາ 3 ປີ. ສະຫນັບສະຫນູນໃນອະນາຄົດ.

ລະບົບທີ່ໄດ້ກ່າວມາປະກອບມີໄດເວີຮາດແວທັງຫມົດທີ່ພວກເຮົາຕ້ອງການອອກຈາກກ່ອງ. ພວກເຮົາບໍ່ຕ້ອງການຊອບແວພາກສ່ວນທີສາມຫຼືໄດເວີ.

ການກະກຽມການຕິດຕັ້ງ

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

ພວກເຮົາບໍ່ພໍໃຈກັບເລື່ອງນີ້.

ເປັນຫຍັງ?ແຕ່ຫນ້າເສຍດາຍ, boot UEFI ແມ່ນເຂົ້າກັນໄດ້ບໍ່ດີກັບຊອບແວບູດ RAID, ເພາະວ່າ ບໍ່ມີໃຜສະເຫນີໃຫ້ພວກເຮົາຈອງສໍາລັບການແບ່ງສ່ວນ UEFI ESP. ມີສູດໃນອິນເຕີເນັດທີ່ແນະນໍາການວາງ ESP partition ໃສ່ flash drive ໃນພອດ USB, ແຕ່ນີ້ແມ່ນຈຸດທີ່ລົ້ມເຫລວ. ມີສູດທີ່ໃຊ້ຊອບແວ mdadm RAID 1 ທີ່ມີ metadata ຮຸ່ນ 0.9 ທີ່ບໍ່ປ້ອງກັນບໍ່ໃຫ້ UEFI BIOS ເຫັນພາທິຊັນນີ້, ແຕ່ນີ້ມີຊີວິດຢູ່ຈົນກ່ວາເວລາທີ່ມີຄວາມສຸກໃນເວລາທີ່ BIOS ຫຼືລະບົບປະຕິບັດການອື່ນໃນຮາດແວຂຽນບາງສິ່ງບາງຢ່າງໃສ່ ESP ແລະລືມ synchronize ມັນ. ກັບກະຈົກອື່ນໆ.

ນອກຈາກນັ້ນ, UEFI boot ແມ່ນຂຶ້ນກັບ NVRAM, ເຊິ່ງຈະບໍ່ຍ້າຍໄປພ້ອມກັບແຜ່ນດິດໄປຫາລະບົບໃຫມ່, ເພາະວ່າ. ແມ່ນສ່ວນຫນຶ່ງຂອງເມນບອດ.

ດັ່ງນັ້ນ, ພວກເຮົາຈະບໍ່ປະດິດລໍ້ໃໝ່. ພວກ​ເຮົາ​ມີ​ລົດ​ຖີບ​ຂອງ​ພໍ່​ຕູ້​ທີ່​ມີ​ການ​ທົດ​ສອບ​ທີ່​ກຽມ​ພ້ອມ​ແລ້ວ, ໃນ​ປັດ​ຈຸ​ບັນ​ມີ​ຊື່​ວ່າ Legacy/BIOS boot, ມີ​ຊື່​ທີ່​ພາກ​ພູມ​ໃຈ​ຂອງ CSM ໃນ​ລະ​ບົບ​ທີ່​ເຂົ້າ​ກັນ​ໄດ້ UEFI. ພວກເຮົາພຽງແຕ່ເອົາມັນອອກຈາກຊັ້ນວາງ, ຫລໍ່ລື່ນມັນ, ສູບຢາງລົດແລະເຊັດມັນດ້ວຍຜ້າປຽກ.

ເວີຊັນ desktop ຂອງ Ubuntu ຍັງບໍ່ສາມາດຕິດຕັ້ງໄດ້ຢ່າງຖືກຕ້ອງກັບ Legacy bootloader, ແຕ່ໃນທີ່ນີ້, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, ຢ່າງຫນ້ອຍມີທາງເລືອກ.

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

ພວກເຮົາເຂົ້າໄປໃນສະພາບແວດລ້ອມ desktop, ເປີດຕົວ emulator terminal, ແລະພວກເຮົາໄປ:

#sudo bash

ແນວໃດ…?ເສັ້ນຂ້າງເທິງນີ້ແມ່ນຕົວກະຕຸ້ນ canonical ສໍາລັບ holiwars ກ່ຽວກັບ sudo. ຄ ຂоໂອກາດອັນໃຫຍ່ຫຼວງມາແລະоຄວາມຮັບຜິດຊອບຫຼາຍກວ່າເກົ່າ. ຄໍາຖາມແມ່ນວ່າທ່ານສາມາດເອົາມັນໃສ່ຕົວທ່ານເອງໄດ້. ຫຼາຍຄົນຄິດວ່າການໃຊ້ sudo ໃນວິທີການນີ້ແມ່ນຢ່າງຫນ້ອຍບໍ່ລະມັດລະວັງ. ແນວໃດກໍ່ຕາມ:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

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

ຈາກຈຸດນີ້, ZFS ແມ່ນ Ferrari, ແລະ mdadm+lvm ແມ່ນຄ້າຍຄືລົດຖີບຫຼາຍ.

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

ເປັນຫຍັງ BTRFS...?ເພື່ອເລີ່ມຕົ້ນລະບົບປະຕິບັດງານ, ພວກເຮົາຕ້ອງການລະບົບໄຟລ໌ທີ່ສະຫນັບສະຫນູນໃນ Legacy/BIOS GRUB ອອກຈາກກ່ອງ, ແລະໃນເວລາດຽວກັນສະຫນັບສະຫນູນການຖ່າຍພາບສົດ. ພວກເຮົາຈະໃຊ້ມັນສໍາລັບ /boot partition. ນອກຈາກນັ້ນ, ຜູ້ຂຽນມັກໃຊ້ FS ນີ້ສໍາລັບ / (ຮາກ), ຢ່າລືມສັງເກດວ່າສໍາລັບຊອບແວອື່ນໆທີ່ທ່ານສາມາດສ້າງການແບ່ງປັນແຍກຕ່າງຫາກໃນ LVM ແລະຕິດຕັ້ງພວກມັນຢູ່ໃນໄດເລກະທໍລີທີ່ຈໍາເປັນ.

ພວກເຮົາຈະບໍ່ເກັບຮັກສາຮູບພາບຂອງເຄື່ອງຈັກ virtual ຫຼືຖານຂໍ້ມູນໃດໆຢູ່ໃນ FS ນີ້.
FS ນີ້ພຽງແຕ່ຈະຖືກນໍາໃຊ້ເພື່ອສ້າງ snapshots ຂອງລະບົບໂດຍບໍ່ມີການປິດມັນແລະຫຼັງຈາກນັ້ນໂອນ snapshots ເຫຼົ່ານີ້ກັບແຜ່ນສໍາຮອງໂດຍໃຊ້ send/recieve.

ນອກຈາກນັ້ນ, ຜູ້ຂຽນໂດຍທົ່ວໄປມັກຮັກສາຕໍາ່ສຸດທີ່ຂອງຊອບແວໂດຍກົງໃນຮາດແວແລະດໍາເນີນການຊອບແວອື່ນໆທັງຫມົດໃນເຄື່ອງ virtual ໂດຍໃຊ້ສິ່ງຕ່າງໆເຊັ່ນການສົ່ງຕໍ່ GPUs ແລະ PCI-USB Host controllers ກັບ KVM ຜ່ານ IOMMU.

ສິ່ງດຽວທີ່ເຫລືອຢູ່ໃນຮາດແວແມ່ນການເກັບຮັກສາຂໍ້ມູນ, virtualization ແລະການສໍາຮອງຂໍ້ມູນ.

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

ຢ່າງໃດກໍຕາມ, ຜູ້ຂຽນໂດຍເຈດຕະນາບໍ່ສົນໃຈກັບລັກສະນະ mirroring / RAID ທີ່ມີການກໍ່ສ້າງແລະຊ້ໍາຊ້ອນທີ່ ZFS, BRTFS ແລະ LVM ມີ.

ໃນຖານະເປັນການໂຕ້ຖຽງເພີ່ມເຕີມ, BTRFS ມີຄວາມສາມາດໃນການປ່ຽນການຂຽນແບບສຸ່ມເຂົ້າໄປໃນລໍາດັບ, ເຊິ່ງມີຜົນກະທົບທາງບວກຫຼາຍຕໍ່ຄວາມໄວຂອງການ synchronizing snapshots / ສໍາຮອງຂໍ້ມູນໃນ HDD.

ມາສະແກນອຸປະກອນທັງໝົດຄືນໃໝ່:

#udevadm control --reload-rules && udevadm trigger

ລອງເບິ່ງຮອບໆ:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


ການຈັດວາງແຜ່ນ

NVMe SSD

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

SATA HDD

ບໍ່ຈໍາເປັນຕ້ອງປະດິດສິ່ງພິເສດຢູ່ທີ່ນີ້. ພວກເຮົາຈະສ້າງພາກຫນຶ່ງສໍາລັບທຸກສິ່ງທຸກຢ່າງ. ພວກເຮົາຈະສ້າງພາທິຊັນເພາະວ່າ BIOS ເຫັນແຜ່ນເຫຼົ່ານີ້ແລະອາດຈະພະຍາຍາມບູດຈາກພວກມັນ. ພວກເຮົາຈະຕິດຕັ້ງ GRUB ໃນແຜ່ນເຫຼົ່ານີ້ຕໍ່ມາເພື່ອໃຫ້ລະບົບສາມາດເຮັດສິ່ງນີ້ໄດ້ຢ່າງກະທັນຫັນ.

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

ນີ້ແມ່ນບ່ອນທີ່ສິ່ງທີ່ຫນ້າສົນໃຈສໍາລັບພວກເຮົາ.

ກ່ອນອື່ນ ໝົດ, ໄດຂອງພວກເຮົາມີຂະ ໜາດ 2 TB. ນີ້ແມ່ນຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້ສໍາລັບ MBR, ເຊິ່ງແມ່ນສິ່ງທີ່ພວກເຮົາຈະໃຊ້. ຖ້າຈໍາເປັນ, ສາມາດຖືກແທນທີ່ດ້ວຍ GPT. ແຜ່ນ GPT ມີຊັ້ນຄວາມເຂົ້າກັນໄດ້ທີ່ອະນຸຍາດໃຫ້ລະບົບທີ່ເຂົ້າກັນໄດ້ກັບ MBR ເພື່ອເບິ່ງ 4 ພາກສ່ວນທໍາອິດຖ້າພວກມັນຕັ້ງຢູ່ພາຍໃນ 2 ເທຣາໄບທໍາອິດ. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າ boot partition ແລະ bios_grub partition ໃນແຜ່ນເຫຼົ່ານີ້ຄວນຈະຢູ່ໃນຕອນຕົ້ນ. ນີ້ຍັງອະນຸຍາດໃຫ້ທ່ານສາມາດ boot ຈາກ GPT Legacy/BIOS drives.

ແຕ່ນີ້ບໍ່ແມ່ນກໍລະນີຂອງພວກເຮົາ.

ໃນທີ່ນີ້ພວກເຮົາຈະສ້າງສອງພາກ. ອັນທໍາອິດຈະເປັນຂະຫນາດ 1 GB ແລະໃຊ້ສໍາລັບ RAID 1 / boot.

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

ພື້ນທີ່ທີ່ບໍ່ມີເຄື່ອງຫມາຍນີ້ແມ່ນຫຍັງ?ອີງຕາມແຫຼ່ງຂໍ້ມູນໃນເຄືອຂ່າຍ, SATA SSDs ຂອງພວກເຮົາມີ cache SLC ທີ່ສາມາດຂະຫຍາຍໄດ້ແບບເຄື່ອນໄຫວທີ່ມີຂະຫນາດຕັ້ງແຕ່ 6 ຫາ 78 gigabyte. ພວກເຮົາໄດ້ຮັບ 6 gigabytes "ຟຣີ" ເນື່ອງຈາກຄວາມແຕກຕ່າງລະຫວ່າງ "gigabytes" ແລະ "gibibytes" ໃນເອກະສານຂໍ້ມູນຂອງໄດ. ສ່ວນທີ່ຍັງເຫຼືອ 72 gigabytes ຖືກຈັດສັນຈາກພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້.

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

ຄູນ 72 gigabytes ຄູນ 4 ແລະໄດ້ຮັບ 288 gigabyte. ນີ້​ແມ່ນ​ຊ່ອງ​ຫວ່າງ​ທີ່​ພວກ​ເຮົາ​ຈະ​ບໍ່​ໄດ້​ຫມາຍ​ອອກ​ໃນ​ຄໍາ​ສັ່ງ​ທີ່​ຈະ​ອະ​ນຸ​ຍາດ​ໃຫ້​ການ​ຂັບ​ເພື່ອ​ນໍາ​ໃຊ້​ຢ່າງ​ເຕັມ​ທີ່​ຂອງ​ຖານ​ຄວາມ​ຈໍາ SLC​.

ດັ່ງນັ້ນ, ພວກເຮົາຈະໄດ້ຮັບເຖິງ 312 gigabyte ຂອງ SLC cache ປະສິດທິພາບຈາກທັງຫມົດຫົກໄດ. ຂອງໄດທັງໝົດ, 2 ຈະຖືກໃຊ້ໃນ RAID ສໍາລັບການຊໍ້າຊ້ອນ.

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

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


ການສ້າງ Arrays

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

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

ເປັນຫຍັງ -ສົມມຸດວ່າສະອາດ...?ເພື່ອຫຼີກເວັ້ນການເລີ່ມຕົ້ນ arrays. ສໍາລັບທັງສອງລະດັບ RAID 1 ແລະ 6 ນີ້ແມ່ນຖືກຕ້ອງ. ທຸກສິ່ງທຸກຢ່າງສາມາດເຮັດວຽກໄດ້ໂດຍບໍ່ມີການເລີ່ມຕົ້ນຖ້າມັນເປັນ array ໃຫມ່. ຍິ່ງໄປກວ່ານັ້ນ, ການເລີ່ມຕົ້ນ SSD array ເມື່ອສ້າງແມ່ນເສຍຊັບພະຍາກອນ TBW. ພວກເຮົາໃຊ້ TRIM/DISCARD ບ່ອນທີ່ເປັນໄປໄດ້ໃນ SSD arrays ທີ່ປະກອບເພື່ອ "ເລີ່ມຕົ້ນ" ພວກມັນ.

ສໍາລັບ SSD arrays, RAID 1 DISCARD ແມ່ນສະຫນັບສະຫນູນອອກຈາກກ່ອງ.

ສໍາລັບ SSD RAID 6 DISCARD arrays, ທ່ານຕ້ອງເປີດໃຊ້ມັນຢູ່ໃນຕົວກໍານົດການໂມດູນ kernel.

ອັນນີ້ຄວນຈະເຮັດໄດ້ພຽງແຕ່ຖ້າ SSD ທັງໝົດທີ່ໃຊ້ໃນລະດັບ 4/5/6 arrays ໃນລະບົບນີ້ມີການສະຫນັບສະຫນູນການເຮັດວຽກຂອງ discard_zeroes_data. ບາງຄັ້ງທ່ານພົບໄດຣຟ໌ແປກໆທີ່ບອກ kernel ວ່າຟັງຊັນນີ້ຖືກສະຫນັບສະຫນູນ, ແຕ່ຄວາມຈິງແລ້ວມັນບໍ່ແມ່ນຢູ່, ຫຼືຟັງຊັນບໍ່ເຮັດວຽກສະເຫມີ. ໃນປັດຈຸບັນ, ການສະຫນັບສະຫນູນແມ່ນມີຢູ່ເກືອບທຸກບ່ອນ, ຢ່າງໃດກໍຕາມ, ມີໄດເກົ່າແລະເຟີມແວທີ່ມີຂໍ້ຜິດພາດ. ດ້ວຍເຫດຜົນນີ້, ການຮອງຮັບ DISCARD ຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນຂອງ RAID 6.

ເອົາ​ໃຈ​ໃສ່, ຄໍາ​ສັ່ງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ຈະ​ທໍາ​ລາຍ​ຂໍ້​ມູນ​ທັງ​ຫມົດ​ໃນ NVMe drives ໂດຍ "ການ​ເລີ່ມ​ຕົ້ນ​" array ກັບ "ສູນ​"​.

#blkdiscard /dev/md0

ຖ້າມີບາງຢ່າງຜິດພາດ, ລອງລະບຸຂັ້ນຕອນ.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

ເປັນຫຍັງໃຫຍ່...?ການເພີ່ມຂະຫນາດ chunk ມີຜົນກະທົບທາງບວກຕໍ່ຄວາມໄວຂອງການອ່ານແບບສຸ່ມໃນບລັອກເຖິງຂະຫນາດ chunk ລວມ. ອັນນີ້ເກີດຂຶ້ນຍ້ອນວ່າການດໍາເນີນການຫນຶ່ງຂອງຂະຫນາດທີ່ເຫມາະສົມຫຼືຂະຫນາດນ້ອຍກວ່າສາມາດສໍາເລັດທັງຫມົດໃນອຸປະກອນດຽວ. ດັ່ງນັ້ນ, IOPS ຈາກອຸປະກອນທັງຫມົດແມ່ນສະຫຼຸບ. ອີງຕາມສະຖິຕິ, 99% ຂອງ IO ບໍ່ເກີນ 512K.

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

ພວກເຮົາຍັງບໍ່ໄດ້ເປີດໃຊ້ DISCARD ສໍາລັບ RAID 6. ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ "ເລີ່ມຕົ້ນ" array ນີ້ສໍາລັບໃນປັດຈຸບັນ. ພວກເຮົາຈະເຮັດອັນນີ້ໃນພາຍຫຼັງ, ຫຼັງຈາກການຕິດຕັ້ງ OS.

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

LVM ໃນ NVMe RAID

ສໍາລັບຄວາມໄວ, ພວກເຮົາຕ້ອງການວາງລະບົບໄຟລ໌ຮາກໃສ່ NVMe RAID 1 ເຊິ່ງເປັນ /dev/md0.
ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຈະຍັງຕ້ອງການ array ໄວນີ້ສໍາລັບຄວາມຕ້ອງການອື່ນໆ, ເຊັ່ນ: swap, metadata ແລະ LVM-cache ແລະ LVM-thin metadata, ດັ່ງນັ້ນພວກເຮົາຈະສ້າງ LVM VG ໃນ array ນີ້.

#pvcreate /dev/md0
#vgcreate root /dev/md0

ໃຫ້ສ້າງພາທິຊັນສໍາລັບລະບົບໄຟລ໌ຮາກ.

#lvcreate -L 128G --name root root

ໃຫ້ພວກເຮົາສ້າງພາທິຊັນສໍາລັບ swapping ຕາມຂະຫນາດຂອງ RAM.

#lvcreate -L 32G --name swap root

ການຕິດຕັ້ງ OS

ໃນຈໍານວນທັງຫມົດ, ພວກເຮົາມີທຸກສິ່ງທຸກຢ່າງທີ່ຈໍາເປັນໃນການຕິດຕັ້ງລະບົບ.

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

• /dev/md1, - mount ຈຸດ /boot, FS - BTRFS
• /dev/root/root (aka /dev/mapper/root-root), - ຈຸດເຊື່ອມຕໍ່ / (ຮາກ), FS - BTRFS
• /dev/root/swap (aka /dev/mapper/root-swap), - ໃຊ້ເປັນ swap partition
• ຕິດຕັ້ງ bootloader ໃນ /dev/sda

ເມື່ອທ່ານເລືອກ BTRFS ເປັນລະບົບໄຟລ໌ຮາກ, ຕົວຕິດຕັ້ງຈະສ້າງສອງປະລິມານ BTRFS ໂດຍອັດຕະໂນມັດທີ່ມີຊື່ວ່າ "@" ສໍາລັບ / (ຮາກ), ແລະ "@home" ສໍາລັບ /home.

ມາເລີ່ມການຕິດຕັ້ງກັນເລີຍ...

ການ​ຕິດ​ຕັ້ງ​ຈະ​ສິ້ນ​ສຸດ​ລົງ​ດ້ວຍ​ປ່ອງ modal ຊີ້​ບອກ​ເຖິງ​ຄວາມ​ຜິດ​ພາດ​ໃນ​ການ​ຕິດ​ຕັ້ງ bootloader ໄດ້​. ຂໍອະໄພ, ທ່ານຈະບໍ່ສາມາດອອກຈາກກ່ອງໂຕ້ຕອບນີ້ໄດ້ໂດຍໃຊ້ວິທີມາດຕະຖານ ແລະສືບຕໍ່ການຕິດຕັ້ງ. ພວກເຮົາອອກຈາກລະບົບແລະເຂົ້າສູ່ລະບົບອີກເທື່ອຫນຶ່ງ, ສິ້ນສຸດໃນ desktop Ubuntu Live ທີ່ສະອາດ. ເປີດ terminal, ແລະອີກເທື່ອຫນຶ່ງ:

#sudo bash

ສ້າງສະພາບແວດລ້ອມ chroot ເພື່ອສືບຕໍ່ການຕິດຕັ້ງ:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

ມາຕັ້ງຄ່າເຄືອຂ່າຍ ແລະຊື່ເຈົ້າພາບໃນ chroot:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

ໃຫ້ເຂົ້າໄປໃນສະພາບແວດລ້ອມ chroot:

#chroot /mnt/chroot

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາຈະຈັດສົ່ງຊຸດ:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

ໃຫ້ກວດເບິ່ງ ແລະ ແກ້ໄຂແພັກເກັດທັງໝົດທີ່ຕິດຕັ້ງຜິດກົດໝາຍ ເນື່ອງຈາກການຕິດຕັ້ງລະບົບບໍ່ສົມບູນ:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

ຖ້າບາງສິ່ງບາງຢ່າງບໍ່ເຮັດວຽກ, ທ່ານອາດຈະຕ້ອງແກ້ໄຂ /etc/apt/sources.list ກ່ອນ

ມາປັບຄ່າພາລາມິເຕີສຳລັບໂມດູນ RAID 6 ເພື່ອເປີດໃຊ້ TRIM/DISCARD:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

ໃຫ້ປັບ arrays ຂອງພວກເຮົາເລັກນ້ອຍ:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

ມັນແມ່ນຫຍັງ..?ພວກເຮົາໄດ້ສ້າງຊຸດຂອງກົດລະບຽບ udev ທີ່ຈະເຮັດດັ່ງຕໍ່ໄປນີ້:

• ກໍານົດຂະຫນາດ block cache ສໍາລັບ RAID 2020 ພຽງພໍສໍາລັບ 6. ຄ່າເລີ່ມຕົ້ນ, ມັນເບິ່ງຄືວ່າ, ບໍ່ໄດ້ປ່ຽນແປງນັບຕັ້ງແຕ່ການສ້າງ Linux, ແລະບໍ່ພຽງພໍສໍາລັບເວລາດົນນານ.
• ຈອງຕໍາ່ສຸດທີ່ຂອງ IO ສໍາລັບໄລຍະເວລາຂອງການກວດສອບ array / synchronizations. ນີ້ແມ່ນເພື່ອປ້ອງກັນບໍ່ໃຫ້ arrays ຂອງທ່ານຕິດຢູ່ໃນສະພາບຂອງການ synchronization ນິລັນດອນພາຍໃຕ້ການໂຫຼດ.
• ຈໍາ​ກັດ IO ສູງ​ສຸດ​ໃນ​ລະ​ຫວ່າງ​ການ​ກວດ​ສອບ / synchronization ຂອງ arrays​. ນີ້ແມ່ນສິ່ງຈໍາເປັນເພື່ອວ່າການ synchronizing / ການກວດສອບ SSD RAIDs ບໍ່ໄດ້ເຮັດໃຫ້ໄດຂອງທ່ານມີຄວາມຄົມຊັດ. ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະສໍາລັບ NVMe. (ຈື່ໄດ້ບໍ? ຂ້ອຍບໍ່ໄດ້ເວົ້າຕະຫຼົກ.)
• ຫ້າມດິສຈາກການຢຸດການຫມຸນ spindle (HDD) ຜ່ານ APM ແລະຕັ້ງເວລານອນສໍາລັບຕົວຄວບຄຸມດິສກ໌ເປັນ 7 ຊົ່ວໂມງ. ທ່ານສາມາດປິດການໃຊ້ງານ APM ໄດ້ຢ່າງສົມບູນຖ້າໄດຂອງທ່ານສາມາດເຮັດມັນໄດ້ (-B 255). ດ້ວຍຄ່າເລີ່ມຕົ້ນ, drives ຈະຢຸດຫຼັງຈາກຫ້າວິນາທີ. ຫຼັງຈາກນັ້ນ, OS ຕ້ອງການຣີເຊັດແຄດດິສກ໌, ແຜ່ນຈະໝຸນຂຶ້ນອີກຄັ້ງ, ແລະທຸກຢ່າງຈະເລີ່ມໃໝ່ອີກຄັ້ງ. ແຜ່ນມີຈໍານວນຈໍາກັດສູງສຸດຂອງການຫມຸນ spindle. ວົງຈອນເລີ່ມຕົ້ນທີ່ງ່າຍດາຍດັ່ງກ່າວສາມາດຂ້າແຜ່ນດິດຂອງທ່ານໄດ້ຢ່າງງ່າຍດາຍໃນສອງສາມປີ. ບໍ່ແມ່ນແຜ່ນທັງຫມົດທົນທຸກຈາກສິ່ງນີ້, ແຕ່ຂອງພວກເຮົາແມ່ນ "ຄອມພິວເຕີ" ທີ່ມີການຕັ້ງຄ່າເລີ່ມຕົ້ນທີ່ເຫມາະສົມ, ເຊິ່ງເຮັດໃຫ້ RAID ເບິ່ງຄືວ່າ mini-MAID.
• ຕິດຕັ້ງ readahead ໃນແຜ່ນ (rotating) 1 megabyte - ສອງ blocks ຕິດຕໍ່ກັນ / chunk RAID 6
• ປິດການໃຊ້ງານ readahead ໃນ arrays ເອງ.

ມາແກ້ໄຂ /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
ເປັນຫຍັງຄື..?ພວກເຮົາຈະຄົ້ນຫາ /boot partition ໂດຍ UUID. ການຕັ້ງຊື່ Array ສາມາດປ່ຽນແປງໃນທາງທິດສະດີ.

ພວກເຮົາຈະຄົ້ນຫາພາກສ່ວນທີ່ຍັງເຫຼືອໂດຍຊື່ LVM ໃນສັນຍາລັກ /dev/mapper/vg-lv, ເພາະວ່າ ພວກເຂົາເຈົ້າກໍານົດການແບ່ງສ່ວນທີ່ຂ້ອນຂ້າງເປັນເອກະລັກ.

ພວກເຮົາບໍ່ໄດ້ໃຊ້ UUID ສໍາລັບ LVM ເພາະວ່າ UUID ຂອງປະລິມານ LVM ແລະພາບຖ່າຍຂອງພວກມັນສາມາດຄືກັນ.Mount /dev/mapper/root-root.. ສອງເທື່ອບໍ?ແມ່ນແລ້ວ. ຢ່າງ​ແນ່​ນອນ. ຄຸນນະສົມບັດຂອງ BTRFS. ລະບົບໄຟລ໌ນີ້ສາມາດຕິດຕັ້ງໄດ້ຫຼາຍຄັ້ງດ້ວຍ subvols ທີ່ແຕກຕ່າງກັນ.

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

ມາສ້າງການຕັ້ງຄ່າ mdadm ຄືນໃໝ່:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

ມາປັບການຕັ້ງຄ່າ LVM:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

ມັນແມ່ນຫຍັງ..?ພວກ​ເຮົາ​ໄດ້​ເປີດ​ໃຫ້​ໃຊ້​ງານ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ອັດ​ຕະ​ໂນ​ມັດ​ຂອງ​ສະ​ນຸກ​ເກີ​ບາງ LVM ເມື່ອ​ເຖິງ 90% ຂອງ​ພື້ນ​ທີ່​ຄອບ​ຄອງ​ໂດຍ 5% ຂອງ​ປະ​ລິ​ມານ.

ພວກເຮົາໄດ້ເພີ່ມຈໍານວນສູງສຸດຂອງຕັນ cache ສໍາລັບ LVM cache.

ພວກເຮົາໄດ້ປ້ອງກັນບໍ່ໃຫ້ LVM ຊອກຫາປະລິມານ LVM (PV) ໃນ:

• ອຸປະກອນທີ່ມີແຄດ LVM (cdata)
• ອຸປະກອນ cache ໂດຍໃຊ້ LVM cache, bypassing cache ( _corig). ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ອຸ​ປະ​ກອນ​ຖານ​ຄວາມ​ຈໍາ​ຕົວ​ມັນ​ເອງ​ຈະ​ຍັງ​ໄດ້​ຮັບ​ການ​ສະ​ແກນ​ໂດຍ​ຜ່ານ​ຖານ​ຄວາມ​ຈໍາ (ພຽງ​ແຕ່​ ).
• ອຸປະກອນທີ່ມີ LVM cache metadata (cmeta)
• ອຸປະກອນທັງຫມົດໃນ VG ທີ່ມີຮູບພາບຊື່. ໃນທີ່ນີ້ພວກເຮົາຈະມີຮູບພາບແຜ່ນຂອງເຄື່ອງ virtual, ແລະພວກເຮົາບໍ່ຕ້ອງການ LVM ໃນໂຮດເພື່ອເປີດໃຊ້ປະລິມານທີ່ເປັນຂອງ OS ແຂກ.
• ອຸປະກອນທັງໝົດໃນ VG ດ້ວຍການສຳຮອງຊື່. ໃນທີ່ນີ້ພວກເຮົາຈະມີສໍາເນົາສໍາຮອງຂອງຮູບພາບເຄື່ອງ virtual.
• ອຸປະກອນທັງໝົດທີ່ມີຊື່ລົງທ້າຍດ້ວຍ “gpv” (ປະລິມານຕົວຈິງຂອງແຂກ)

ພວກເຮົາໄດ້ເປີດໃຊ້ການຮອງຮັບ DISCARD ເມື່ອສ້າງພື້ນທີ່ຫວ່າງຢູ່ໃນ LVM VG. ລະ​ມັດ​ລະ​ວັງ. ນີ້ຈະເຮັດໃຫ້ການລຶບ LVs ໃນ SSD ຂ້ອນຂ້າງໃຊ້ເວລາຫຼາຍ. ນີ້ໂດຍສະເພາະແມ່ນໃຊ້ກັບ SSD RAID 6. ຢ່າງໃດກໍຕາມ, ອີງຕາມແຜນການ, ພວກເຮົາຈະນໍາໃຊ້ການສະຫນອງບາງໆ, ດັ່ງນັ້ນນີ້ຈະບໍ່ຂັດຂວາງພວກເຮົາເລີຍ.

ມາອັບເດດຮູບພາບ initramfs:

#update-initramfs -u -k all

ຕິດຕັ້ງແລະຕັ້ງຄ່າ grub:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

ຈະເລືອກແຜ່ນໃດ?ທຸກຄົນທີ່ເປັນ sd*. ລະບົບຈະຕ້ອງສາມາດບູດຈາກໄດ SATA ຫຼື SSD ທີ່ເຮັດວຽກໄດ້.

ເປັນຫຍັງເຂົາເຈົ້າຈຶ່ງເພີ່ມ os-prober..?ສໍາລັບເອກະລາດຫຼາຍເກີນໄປແລະມືຫຼິ້ນ.

ມັນບໍ່ເຮັດວຽກຢ່າງຖືກຕ້ອງຖ້າຫນຶ່ງໃນ RAIDs ຢູ່ໃນສະພາບທີ່ຊຸດໂຊມ. ມັນພະຍາຍາມຄົ້ນຫາ OS ໃນພາທິຊັນທີ່ໃຊ້ໃນເຄື່ອງ virtual ທີ່ເຮັດວຽກຢູ່ໃນຮາດແວນີ້.

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

ດ້ວຍນີ້ພວກເຮົາໄດ້ສໍາເລັດການຕິດຕັ້ງເບື້ອງຕົ້ນ. ມັນເຖິງເວລາແລ້ວທີ່ຈະປິດເປີດ OS ທີ່ຕິດຕັ້ງໃໝ່. ຢ່າລືມເອົາ Live CD/USB ທີ່ສາມາດເປີດໄດ້.

#exit
#reboot

ເລືອກໃດໆຂອງ SATA SSDs ເປັນອຸປະກອນ boot.

LVM ໃນ SATA SSD

ໃນຈຸດນີ້, ພວກເຮົາໄດ້ booted ເຂົ້າໄປໃນ OS ໃຫມ່ແລ້ວ, ຕັ້ງຄ່າເຄືອຂ່າຍ, ເຫມາະສົມ, ເປີດ terminal emulator, ແລະເປີດຕົວ:

#sudo bash

ໃຫ້ສືບຕໍ່.

"ເລີ່ມຕົ້ນ" array ຈາກ SATA SSD:

#blkdiscard /dev/md2

ຖ້າມັນບໍ່ເຮັດວຽກ, ຫຼັງຈາກນັ້ນພະຍາຍາມ:

#blkdiscard --step 65536 /dev/md2
ສ້າງ LVM VG ໃນ SATA SSD:

#pvcreate /dev/md2
#vgcreate data /dev/md2

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

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

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

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

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

ການປະກົດຕົວຂອງ LVM ໃນລະດັບ "ຮາດແວ" ຈະຊ່ວຍໃຫ້ພວກເຮົາສາມາດຕັດຊິ້ນສ່ວນຕ່າງໆຂອງ RAID arrays ທີ່ແຕກຕ່າງກັນໂດຍການສົມທົບພວກມັນດ້ວຍວິທີຕ່າງໆ. ຕົວຢ່າງ - ແລ່ນ ໃນເວລາດຽວກັນ bcache + LVM ບາງໆ, bcache + BTRFS, LVM cache + LVM ບາງໆ, ການຕັ້ງຄ່າ ZFS ທີ່ຊັບຊ້ອນກັບ cache, ຫຼືປະສົມ hellish ອື່ນໆເພື່ອລອງປຽບທຽບມັນທັງຫມົດ.

ໃນລະດັບ “ຮາດແວ”, ພວກເຮົາຈະບໍ່ໃຊ້ອັນອື່ນນອກຈາກປະລິມານ LVM “ໜາ” ເກົ່າທີ່ດີ. ຂໍ້ຍົກເວັ້ນຕໍ່ກົດລະບຽບນີ້ອາດຈະເປັນການແບ່ງປັນສໍາຮອງຂໍ້ມູນ.

ຂ້າພະເຈົ້າຄິດວ່າໃນເວລານີ້, ຜູ້ອ່ານຈໍານວນຫຼາຍໄດ້ເລີ່ມສົງໄສບາງສິ່ງບາງຢ່າງກ່ຽວກັບ doll ຮັງ.

LVM ໃນ SATA HDD

#pvcreate /dev/md3
#vgcreate backup /dev/md3

VG ໃໝ່ອີກແລ້ວ..?ພວກເຮົາຕ້ອງການແທ້ໆວ່າຖ້າ disk array ທີ່ພວກເຮົາຈະໃຊ້ສໍາລັບການສໍາຮອງຂໍ້ມູນຂໍ້ມູນລົ້ມເຫລວ, ລະບົບປະຕິບັດການຂອງພວກເຮົາຈະສືບຕໍ່ເຮັດວຽກເປັນປົກກະຕິ, ໃນຂະນະທີ່ຮັກສາການເຂົ້າເຖິງຂໍ້ມູນທີ່ບໍ່ແມ່ນການສໍາຮອງຂໍ້ມູນຕາມປົກກະຕິ. ດັ່ງນັ້ນ, ເພື່ອຫຼີກເວັ້ນບັນຫາການເປີດໃຊ້ VG, ພວກເຮົາສ້າງ VG ແຍກຕ່າງຫາກ.

ຕັ້ງຄ່າ cache LVM

ມາສ້າງ LV ໃນ NVMe RAID 1 ເພື່ອໃຊ້ມັນເປັນອຸປະກອນເກັບຂໍ້ມູນ.

#lvcreate -L 70871154688B --name cache root

ເປັນຫຍັງຈຶ່ງມີໜ້ອຍ...?ຄວາມຈິງແມ່ນວ່າ NVMe SSDs ຂອງພວກເຮົາຍັງມີ cache SLC. 4 gigabytes ຂອງ "ຟຣີ" ແລະ 18 gigabyte ຂອງໄດນາມິກເນື່ອງຈາກພື້ນທີ່ຫວ່າງຄອບຄອງຢູ່ໃນ 3-bit MLC. ເມື່ອ cache ນີ້ຫມົດແລ້ວ, NVMe SSDs ຈະບໍ່ໄວກວ່າ SATA SSD ຂອງພວກເຮົາທີ່ມີ cache. ຕົວຈິງແລ້ວ, ສໍາລັບເຫດຜົນນີ້, ມັນບໍ່ມີຄວາມຫມາຍສໍາລັບພວກເຮົາທີ່ຈະເຮັດໃຫ້ການແບ່ງສ່ວນແຄດ LVM ຂະຫນາດໃຫຍ່ກວ່າສອງເທົ່າຂອງຂະຫນາດ SLC cache ຂອງ NVMe drive. ສໍາລັບໄດ NVMe ທີ່ໃຊ້, ຜູ້ຂຽນຖືວ່າມັນສົມເຫດສົມຜົນທີ່ຈະເຮັດໃຫ້ 32-64 gigabytes ຂອງ cache.

ຂະຫນາດພາທິຊັນທີ່ໃຫ້ມາແມ່ນຕ້ອງການເພື່ອຈັດລະບຽບ cache, cache metadata, ແລະ metadata backup 64 gigabyte.

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

ມາສ້າງ LV ໃນ SATA RAID 6 ເພື່ອໃຊ້ມັນເປັນອຸປະກອນທີ່ເກັບໄວ້ໃນຖານຄວາມຈໍາ.

#lvcreate -L 3298543271936B --name cache data

ເປັນຫຍັງພຽງແຕ່ສາມ terabytes ..?ດັ່ງນັ້ນ, ຖ້າຈໍາເປັນ, ທ່ານສາມາດນໍາໃຊ້ SATA SSD RAID 6 ສໍາລັບຄວາມຕ້ອງການອື່ນໆ. ຂະໜາດຂອງພື້ນທີ່ເກັບຂໍ້ມູນສາມາດເພີ່ມຂຶ້ນແບບເຄື່ອນໄຫວ, ໃນເວລາບິນ, ໂດຍບໍ່ມີການຢຸດລະບົບ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງຢຸດຊົ່ວຄາວແລະເປີດໃຊ້ cache ອີກເທື່ອຫນຶ່ງ, ແຕ່ປະໂຫຍດທີ່ໂດດເດັ່ນຂອງ LVM-cache over, ສໍາລັບການຍົກຕົວຢ່າງ, bcache ແມ່ນວ່ານີ້ສາມາດເຮັດໄດ້ທັນທີ.

ມາສ້າງ VG ໃໝ່ສຳລັບການເກັບຂໍ້ມູນ.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

ມາສ້າງ LV ໃນອຸປະກອນແຄດ.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

ໃນທີ່ນີ້ພວກເຮົາທັນທີໄດ້ເອົາພື້ນທີ່ຫວ່າງທັງຫມົດໃນ /dev/data/cache ເພື່ອໃຫ້ທຸກພາກສ່ວນທີ່ຈໍາເປັນອື່ນໆຖືກສ້າງຂື້ນໃນ /dev/root/cache. ຖ້າທ່ານສ້າງສິ່ງທີ່ຜິດພາດ, ທ່ານສາມາດຍ້າຍມັນໄດ້ໂດຍໃຊ້ pvmove.

ມາສ້າງ ແລະເປີດໃຊ້ cache:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

ເປັນຫຍັງຂະໜາດນີ້..?ໂດຍຜ່ານການທົດລອງປະຕິບັດ, ຜູ້ຂຽນສາມາດຄົ້ນພົບວ່າຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດແມ່ນບັນລຸໄດ້ຖ້າຂະຫນາດຂອງ LVM cache block ກົງກັບຂະຫນາດຂອງ LVM ບາງໆ. ຍິ່ງໄປກວ່ານັ້ນ, ຂະຫນາດຂະຫນາດນ້ອຍກວ່າ, ການຕັ້ງຄ່າທີ່ດີກວ່າປະຕິບັດໃນການບັນທຶກແບບສຸ່ມ.

64k ແມ່ນຂະຫນາດບລັອກຕໍາ່ສຸດທີ່ອະນຸຍາດໃຫ້ສໍາລັບ LVM ບາງໆ.

ລະວັງຂຽນຄືນ..!ແມ່ນແລ້ວ. ປະເພດຂອງ cache ນີ້ defers ຂຽນ synchronization ກັບອຸປະກອນ cache. ນີ້ຫມາຍຄວາມວ່າຖ້າ cache ສູນເສຍ, ທ່ານອາດຈະສູນເສຍຂໍ້ມູນໃນອຸປະກອນ cache. ຕໍ່ມາ, ຜູ້ຂຽນຈະບອກທ່ານວ່າມາດຕະການໃດ, ນອກເຫນືອຈາກ NVMe RAID 1, ສາມາດຖືກປະຕິບັດເພື່ອຊົດເຊີຍຄວາມສ່ຽງນີ້.

ປະເພດ cache ນີ້ໄດ້ຖືກເລືອກໂດຍເຈດຕະນາເພື່ອຊົດເຊີຍການປະຕິບັດການຂຽນແບບສຸ່ມທີ່ບໍ່ດີຂອງ RAID 6.

ໃຫ້ກວດເບິ່ງສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

ພຽງແຕ່ [cachedata_corig] ຄວນຢູ່ໃນ /dev/data/cache. ຖ້າມີບາງຢ່າງຜິດພາດ, ຫຼັງຈາກນັ້ນໃຊ້ pvmove.

ທ່ານສາມາດປິດການໃຊ້ງານ cache ຖ້າຈໍາເປັນດ້ວຍຄໍາສັ່ງດຽວ:

#lvconvert -y --uncache cache/cachedata

ນີ້ແມ່ນເຮັດອອນໄລນ໌. LVM ພຽງແຕ່ຈະ sync cache ກັບ disk, ເອົາມັນອອກ, ແລະປ່ຽນຊື່ cachedata_corig ກັບຄືນໄປບ່ອນ cachedata.

ການຕັ້ງຄ່າ LVM ບາງ

ຂໍໃຫ້ຄາດຄະເນປະມານວ່າພວກເຮົາຕ້ອງການພື້ນທີ່ຫຼາຍປານໃດສໍາລັບ LVM ບາງ metadata:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

ຮອບເຖິງ 4 ກິກາໄບ: 4294967296B

ຄູນດ້ວຍສອງ ແລະເພີ່ມ 4194304B ສໍາລັບ LVM PV metadata: 8594128896B
ໃຫ້ສ້າງພາທິຊັນແຍກຕ່າງຫາກກ່ຽວກັບ NVMe RAID 1 ເພື່ອວາງ LVM ບາງ metadata ແລະສໍາເນົາສໍາຮອງຂອງເຂົາເຈົ້າໃສ່ມັນ:

#lvcreate -L 8594128896B --name images root

ເພື່ອ​ຫຍັງ..?ໃນທີ່ນີ້ຄໍາຖາມອາດຈະເກີດຂື້ນ: ເປັນຫຍັງວາງ LVM ບາງ metadata ແຍກຕ່າງຫາກຖ້າມັນຍັງຈະຖືກເກັບໄວ້ໃນ NVMe ແລະຈະເຮັດວຽກໄດ້ໄວ.

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

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

ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າພາບຖ່າຍຂອງປະລິມານບາງໆໄດ້ຖືກປະຕິບັດກ່ອນຫນ້ານີ້, ແລະຫຼັງຈາກນັ້ນ cache ໄດ້ຖືກ synchronized ຢ່າງເຕັມສ່ວນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ, ຫຼັງຈາກນັ້ນ, ເນື່ອງຈາກການອອກແບບພາຍໃນຂອງ LVM ບາງ, ຄວາມສົມບູນຂອງ snapshot ຈະໄດ້ຮັບການຮັບປະກັນໃນກໍລະນີຂອງການສູນເສຍ cache. .

ຂໍໃຫ້ສ້າງ VG ໃຫມ່ທີ່ຈະຮັບຜິດຊອບສໍາລັບການສະຫນອງບາງໆ:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
ມາສ້າງສະລອຍນ້ຳ:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
ເປັນຫຍັງ -Z yນອກເຫນືອຈາກສິ່ງທີ່ໂຫມດນີ້ມີຈຸດປະສົງຢ່າງແທ້ຈິງ - ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນຈາກເຄື່ອງ virtual ຈາກການຮົ່ວໄຫລໄປຫາເຄື່ອງ virtual ອື່ນໃນເວລາທີ່ການແຈກຢາຍພື້ນທີ່ - zeroing ຍັງຖືກນໍາໃຊ້ເພື່ອເພີ່ມຄວາມໄວຂອງການຂຽນແບບສຸ່ມໃນບລັອກຂະຫນາດນ້ອຍກວ່າ 64k. ການຂຽນໃດໆທີ່ຫນ້ອຍກວ່າ 64k ໄປຫາພື້ນທີ່ທີ່ບໍ່ໄດ້ຈັດສັນກ່ອນຫນ້ານີ້ຂອງປະລິມານບາງໆຈະກາຍເປັນ 64K edge-aligned ໃນ cache. ນີ້ຈະອະນຸຍາດໃຫ້ດໍາເນີນການທັງຫມົດໂດຍຜ່ານ cache, bypassing ອຸປະກອນ cache.

ໃຫ້ຍ້າຍ LVs ໄປຫາ PVs ທີ່ສອດຄ້ອງກັນ:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

ໃຫ້ກວດເບິ່ງ:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

ໃຫ້ສ້າງປະລິມານບາງໆສໍາລັບການທົດສອບ:

#lvcreate -V 64G --thin-pool thin-pool --name test images

ພວກເຮົາຈະຕິດຕັ້ງຊຸດສໍາລັບການທົດສອບແລະການຕິດຕາມ:

#apt-get install sysstat fio

ນີ້ແມ່ນວິທີທີ່ທ່ານສາມາດສັງເກດພຶດຕິກໍາຂອງການຕັ້ງຄ່າການເກັບຮັກສາຂອງພວກເຮົາໃນເວລາຈິງ:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

ນີ້ແມ່ນວິທີທີ່ພວກເຮົາສາມາດທົດສອບການຕັ້ງຄ່າຂອງພວກເຮົາ:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

ລະມັດລະວັງ! ຊັບພະຍາກອນ!ລະຫັດນີ້ຈະດໍາເນີນການ 36 ການທົດສອບທີ່ແຕກຕ່າງກັນ, ແຕ່ລະແລ່ນສໍາລັບ 4 ວິນາທີ. ເຄິ່ງຫນຶ່ງຂອງການທົດສອບແມ່ນສໍາລັບການບັນທຶກ. ທ່ານສາມາດບັນທຶກຫຼາຍໃນ NVMe ໃນ 4 ວິນາທີ. ສູງສຸດ 3 ກິກະໄບຕໍ່ວິນາທີ. ດັ່ງນັ້ນ, ແຕ່ລະໄລຍະຂອງການທົດສອບການຂຽນສາມາດກິນເຖິງ 216 gigabytes ຂອງຊັບພະຍາກອນ SSD ຈາກທ່ານ.

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

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

ໃນບັນດາສິ່ງອື່ນໆ, ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ວັດແທກຄວາມໄວໃນປະລິມານທີ່ບາງໆເຕັມທີ່ແລ້ວຈາກການຖ່າຍຮູບທີ່ພຽງແຕ່ຖືກຖ່າຍ. ຜູ້ຂຽນໄດ້ມີໂອກາດສັງເກດເຫັນວິທີການຂຽນແບບສຸ່ມເລັ່ງຢ່າງໄວວາຫຼັງຈາກສ້າງພາບຖ່າຍທໍາອິດ, ໂດຍສະເພາະໃນເວລາທີ່ cache ຍັງບໍ່ທັນເຕັມ. ອັນນີ້ເກີດຂຶ້ນຍ້ອນການຄັດລອກ-on-write write semantics, ການຈັດລຽງຂອງ cache ແລະ block volume ບາງໆ, ແລະຄວາມຈິງທີ່ວ່າການຂຽນແບບສຸ່ມໃສ່ RAID 6 ກາຍເປັນການອ່ານແບບສຸ່ມຈາກ RAID 6 ຕິດຕາມດ້ວຍການຂຽນໃສ່ cache. ໃນການຕັ້ງຄ່າຂອງພວກເຮົາ, ການອ່ານແບບສຸ່ມຈາກ RAID 6 ແມ່ນສູງເຖິງ 6 ເທື່ອ (ຈໍານວນ SATA SSDs ໃນອາເລ) ໄວກວ່າການຂຽນ. ເນື່ອງຈາກວ່າ ຕັນສໍາລັບ CoW ຖືກຈັດສັນຕາມລໍາດັບຈາກສະນຸກເກີບາງໆ, ຫຼັງຈາກນັ້ນການບັນທຶກ, ສໍາລັບສ່ວນໃຫຍ່, ຍັງປ່ຽນເປັນລໍາດັບ.

ທັງສອງລັກສະນະເຫຼົ່ານີ້ສາມາດຖືກນໍາໃຊ້ເພື່ອປະໂຫຍດຂອງທ່ານ.

Cache ພາບຖ່າຍ “ສອດຄ່ອງ”

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

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

ວົງຈອນການຫມຸນຂອງ snapshot ຕໍ່ໄປນີ້ຮັບປະກັນຄວາມສົມບູນຂອງຂໍ້ມູນພາຍໃນ snapshots ໃນກໍລະນີຂອງການສູນເສຍ cache:

1. ສໍາລັບແຕ່ລະປະລິມານບາງໆທີ່ມີຊື່ <name>, ສ້າງ snapshot ທີ່ມີຊື່ <name>.cached
2. ໃຫ້ກໍານົດຂອບເຂດການເຄື່ອນຍ້າຍເປັນມູນຄ່າສູງທີ່ສົມເຫດສົມຜົນ: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. ໃນ loop ພວກເຮົາກວດເບິ່ງຈໍານວນຂອງຕັນເປື້ອນໃນ cache: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' ຈົນກ່ວາພວກເຮົາໄດ້ຮັບສູນ. ຖ້າສູນຫາຍໄປດົນເກີນໄປ, ມັນສາມາດຖືກສ້າງໂດຍການປ່ຽນ cache ຊົ່ວຄາວເປັນຮູບແບບການຂຽນຜ່ານ. ຢ່າງໃດກໍຕາມ, ການຄໍານຶງເຖິງຄຸນລັກສະນະຄວາມໄວຂອງ SATA ແລະ NVMe SSD arrays ຂອງພວກເຮົາ, ເຊັ່ນດຽວກັນກັບຊັບພະຍາກອນ TBW ຂອງເຂົາເຈົ້າ, ທ່ານຈະສາມາດຈັບເວລາຢ່າງໄວວາໂດຍບໍ່ມີການປ່ຽນ cache mode, ຫຼືຮາດແວຂອງທ່ານຈະກິນຊັບພະຍາກອນທັງຫມົດຂອງມັນຢູ່ໃນ. ສອງ​ສາມ​ມື້. ເນື່ອງຈາກຂໍ້ຈໍາກັດຂອງຊັບພະຍາກອນ, ໃນຫຼັກການ, ລະບົບແມ່ນບໍ່ສາມາດຢູ່ພາຍໃຕ້ 100% ຂອງການໂຫຼດໄດ້ຕະຫຼອດເວລາ. NVMe SSDs ຂອງພວກເຮົາພາຍໃຕ້ການໂຫຼດການຂຽນ 100% ຈະຫມົດຊັບພະຍາກອນໃນ 3-4 ມື້. SATA SSDs ຈະມີອາຍຸພຽງແຕ່ສອງເທົ່າ. ດັ່ງນັ້ນ, ພວກເຮົາຈະສົມມຸດວ່າການໂຫຼດສ່ວນໃຫຍ່ໄປຫາການອ່ານ, ແລະພວກເຮົາມີການລະເບີດໃນໄລຍະສັ້ນຂອງກິດຈະກໍາທີ່ສູງທີ່ສຸດລວມກັບການໂຫຼດຕ່ໍາໂດຍສະເລ່ຍສໍາລັບການຂຽນ.
4. ທັນທີທີ່ພວກເຮົາຈັບໄດ້ (ຫຼືເຮັດໃຫ້) ເປັນສູນ, ພວກເຮົາປ່ຽນຊື່ <name>.cached ເປັນ <name>.committed. <name>.committed ເກົ່າຖືກລຶບ.
5. ທາງເລືອກ, ຖ້າແຄດເຕັມ 100%, ມັນສາມາດຖືກສ້າງໃຫມ່ໂດຍສະຄິບ, ດັ່ງນັ້ນການລ້າງມັນ. ດ້ວຍ cache ເຄິ່ງຫວ່າງເປົ່າ, ລະບົບເຮັດວຽກໄວຂຶ້ນຫຼາຍເມື່ອຂຽນ.
6. ຕັ້ງເກນການເຄື່ອນຍ້າຍເປັນສູນ: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata ນີ້ຈະປ້ອງກັນບໍ່ໃຫ້ cache ຈາກການ synchronizing ກັບສື່ຕົ້ນຕໍຊົ່ວຄາວ.
7. ພວກເຮົາລໍຖ້າຈົນກ່ວາຂ້ອນຂ້າງຫຼາຍຂອງການປ່ຽນແປງສະສົມຢູ່ໃນ cache #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' ຫຼືເຄື່ອງຈັບເວລາຈະປິດ.
8. ພວກເຮົາເຮັດຊ້ໍາອີກຄັ້ງ.

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

ໂດຍກໍານົດຂອບເຂດການເຄື່ອນຍ້າຍເປັນສູນ, ພວກເຮົາເລື່ອນການຂຽນ synchronization ຢູ່ໃນ SATA SSD ແລະລວບລວມການປ່ຽນແປງຈໍານວນຫນຶ່ງໄປຫາຫນຶ່ງ 64K block ໃນ cache. ນີ້ຊ່ວຍປະຢັດຊັບພະຍາກອນຂອງ SATA SSD ຢ່າງຫຼວງຫຼາຍ.

ລະຫັດຢູ່ໃສ..?ແຕ່ຫນ້າເສຍດາຍ, ຜູ້ຂຽນຖືວ່າຕົນເອງມີຄວາມສາມາດບໍ່ພຽງພໍໃນການພັດທະນາ bash scripts ເພາະວ່າລາວສອນຕົນເອງ 100% ແລະປະຕິບັດການພັດທະນາ "google" ທີ່ຂັບເຄື່ອນ, ດັ່ງນັ້ນລາວເຊື່ອວ່າລະຫັດຂີ້ຮ້າຍທີ່ອອກມາຈາກມືຂອງລາວບໍ່ຄວນຖືກໃຊ້ໂດຍໃຜ. ອື່ນ.

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

ຮູບແບບການຫມູນວຽນ snapshot ງ່າຍໆດັ່ງກ່າວຈະຊ່ວຍໃຫ້ພວກເຮົາບໍ່ພຽງແຕ່ມີ snapshot ສະເຫມີ synchronized ຢ່າງເຕັມສ່ວນໃນ SATA SSD, ແຕ່ຍັງຈະຊ່ວຍໃຫ້ພວກເຮົາ, ການນໍາໃຊ້ utility thin_delta, ເພື່ອຊອກຫາວ່າ block ໃດໄດ້ຖືກປ່ຽນແປງຫຼັງຈາກການສ້າງຂອງມັນ, ແລະດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ຄວາມເສຍຫາຍຢູ່ໃນທ້ອງຖິ່ນ. ປະ​ລິ​ມານ​ຕົ້ນ​ຕໍ​, ການ​ຟື້ນ​ຕົວ​ຢ່າງ​ງ່າຍ​ດາຍ​ຫຼາຍ​.

TRIM/DISCARD ໃນ libvirt/KVM

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

ອັນນີ້ແມ່ນເຮັດໄດ້ໂດຍການຈຳລອງການຮອງຮັບ TRIM/DISCARD ໃນແຜ່ນສະເໝືອນ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງປ່ຽນປະເພດຕົວຄວບຄຸມເປັນ virtio-scsi ແລະແກ້ໄຂ xml.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

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

BTRFS Backup

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

ມາສ້າງປະລິມານໃນອຸປະກອນສຳຮອງ:

#lvcreate -L 256G --name backup backup

ໃຫ້ຈັດຮູບແບບໃນ BTRFS:

#mkfs.btrfs /dev/backup/backup

ມາສ້າງຈຸດ mount ແລະ mount ສ່ວນຍ່ອຍຮາກຂອງລະບົບໄຟລ໌:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

ມາສ້າງໄດເລກະທໍລີສຳລັບການສຳຮອງຂໍ້ມູນ:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

ມາສ້າງໄດເລກະທໍລີສຳລັບສະຄຣິບສຳຮອງ:

#mkdir /root/btrfs-backup

ຂໍໃຫ້ສຳເນົາສະຄຣິບ:

ລະຫັດ bash ທີ່ຫນ້າຢ້ານຫຼາຍ. ໃຊ້ຢູ່ໃນຄວາມສ່ຽງຂອງທ່ານເອງ. ຫ້າມ​ຂຽນ​ຈົດໝາຍ​ໃຈ​ຮ້າຍ​ໃຫ້​ຜູ້​ຂຽນ...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


ມັນເຮັດຫຍັງ..?ປະກອບດ້ວຍຊຸດຂອງຄໍາສັ່ງງ່າຍໆສໍາລັບການສ້າງພາບຖ່າຍ BTRFS ແລະຄັດລອກພວກມັນໄປຫາ FS ອື່ນໂດຍໃຊ້ BTRFS ສົ່ງ / ຮັບ.

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

script ອື່ນທີ່ພວກເຮົາຈະໃສ່ເຂົ້າໃນ cron:

ບາງລະຫັດ bash ເພີ່ມເຕີມ#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


ມັນເຮັດຫຍັງ..?ສ້າງ ແລະ synchronizes snapshots ເພີ່ມຂຶ້ນຂອງປະລິມານ BTRFS ທີ່ມີລາຍຊື່ຢູ່ໃນ FS ສໍາຮອງຂໍ້ມູນ. ຫຼັງ​ຈາກ​ນີ້​, ມັນ​ລຶບ​ຮູບ​ພາບ​ທັງ​ຫມົດ​ທີ່​ສ້າງ​ຕັ້ງ​ຂຶ້ນ 60 ມື້​ກ່ອນ​ຫນ້າ​ນີ້​. ຫຼັງ​ຈາກ​ການ​ເປີດ​ຕົວ​, ຮູບ​ພາບ​ປະ​ຈໍາ​ວັນ​ຂອງ​ປະ​ລິ​ມານ​ທີ່​ລະ​ບຸ​ໄວ້​ຈະ​ປາ​ກົດ​ຢູ່​ໃນ /backup/btrfs/back/remote/ subdirectories.

ໃຫ້ສິດປະຕິບັດລະຫັດ:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

ໃຫ້ກວດເບິ່ງມັນແລະໃສ່ໃນ cron:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVM ສໍາຮອງຂໍ້ມູນບາງໆ

ມາສ້າງສະນຸກເກີບາງໆໃນອຸປະກອນສຳຮອງ:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

ໃຫ້ຕິດຕັ້ງ ddrescue, ເພາະວ່າ ... ສະຄຣິບຈະໃຊ້ເຄື່ອງມືນີ້:

#apt-get install gddrescue

ມາສ້າງໄດເລກະທໍລີສໍາລັບ scripts:

#mkdir /root/lvm-thin-backup

ໃຫ້ສຳເນົາຕົວໜັງສື:

ບ້າ​ຫຼາຍ​ພາຍ​ໃນ ...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


ມັນເຮັດຫຍັງ...?ປະກອບດ້ວຍຊຸດຂອງຄໍາສັ່ງສໍາລັບການຈັດການ snapshots ບາງໆແລະ synchronizing ຄວາມແຕກຕ່າງລະຫວ່າງສອງ snapshots ບາງທີ່ໄດ້ຮັບໂດຍຜ່ານ thin_delta ກັບອຸປະກອນ block ອື່ນໂດຍໃຊ້ ddrescue ແລະ blkdiscard.

script ອື່ນທີ່ພວກເຮົາຈະໃສ່ໃນ cron:

bash ຫຼາຍເລັກນ້ອຍ#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


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

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

ໃຫ້ສິດທິ:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

ໃຫ້ກວດເບິ່ງມັນແລະໃສ່ໃນ cron:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

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

ການແລ່ນຕໍ່ໄປຈະຄັດລອກຂໍ້ມູນເພີ່ມຂຶ້ນຍ້ອນການປ່ຽນແປງການຕິດຕາມຜ່ານ LVM ບາງ metadata.

ມາເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນ:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


ອັນນີ້ເຮັດຫຍັງແດ່ກັບ dolls ຮັງ?

ສ່ວນຫຼາຍອາດຈະ, ເນື່ອງຈາກປະລິມານໂລໂກ້ LVM LV ສາມາດເປັນປະລິມານທາງກາຍະພາບຂອງ LVM PV ສໍາລັບ VGs ອື່ນໆ. LVM ສາມາດ recursive, ເຊັ່ນ dolls ຮັງ. ນີ້ເຮັດໃຫ້ LVM ມີຄວາມຍືດຫຍຸ່ນທີ່ສຸດ.

PS

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

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