ProHoster > Blog > Administrimi > ÇfarĂ« kanĂ« tĂ« pĂ«rbashkĂ«t LVM dhe matryoshka?

ÇfarĂ« kanĂ« tĂ« pĂ«rbashkĂ«t LVM dhe matryoshka?

Mirë se erdhët.
Dua të ndaj me komunitetin përvojën time praktikë në ndërtimin e një sistemi ruajtjeje për KVM duke përdorur md RAID + LVM.

Programi do të përfshijë:

  • Krijimi i md RAID 1 nga NVMe SSD.
  • Krijimi i md RAID 6 nga SATA SSD dhe disqe tĂ« zakonshme.
  • VeçoritĂ« e funksionimit TRIM/DISCARD nĂ« SSD RAID 1/6.
  • Krijimi i njĂ« grupi md RAID 1/6 bootable nĂ« njĂ« grup tĂ« zakonshĂ«m disqesh.
  • Instalimi i sistemit nĂ« NVMe RAID 1 nĂ« mungesĂ« tĂ« mbĂ«shtetjes NVMe nĂ« BIOS.
  • PĂ«rdorimi i LVM cache dhe LVM thin.
  • PĂ«rdorimi i snapshots BTRFS dhe send/receive pĂ«r backup.
  • PĂ«rdorimi i snapshots LVM thin dhe thin_delta pĂ«r backup nĂ« stilin BTRFS.

Nëse jeni të interesuar, ju lutem klikoni më poshtë.

Lajmërim

Autori nuk merr përsipër asnjë përgjegjësi për pasojat e përdorimit ose mos përdorimit të materialeve/shembujve/kodit/këshillave/të dhënave nga ky artikull. Duke lexuar ose duke përdorur këtë material në ndonjë mënyrë, ju merrni përsipër përgjegjësinë për të gjitha pasojat e këtyre veprimeve. Pasojat mund të përfshijnë:

  • NVMe SSD tĂ« skuqura deri nĂ« skuqje.
  • PĂ«rfundimi i burimeve tĂ« shkrimit dhe dĂ«shtimi i SSD-ve.
  • Humbje totale e tĂ« dhĂ«nave nĂ« tĂ« gjitha disqet, duke pĂ«rfshirĂ« backup-et.
  • Harduer i dĂ«shtuar kompjuterik.
  • Koha, nervat dhe paratĂ« e shpenzuara.
  • Çdo pasojĂ« tjetĂ«r qĂ« nuk Ă«shtĂ« pĂ«rmendur mĂ« lart.

Pajisjet

I pranishëm ishte:

Një motherboard nga rreth viti 2013 me chipset Z87 e shoqëruar me Intel Core i7 / Haswell.

  • Procesori me 4 bĂ«rthama, 8 fibra
  • 32 Gigabajt RAM DDR3
  • 1 x 16 ose 2 x 8 PCIe 3.0
  • 1 x 4 + 1 x 1 PCIe 2.0
  • 6 x 6 GBps SATA 3 porte

Adapter SAS LSI SAS9211-8I i flashuar në modin IT / HBA. Firmware me mbështetje për RAID u zëvendësua qëllimisht me firmware HBA për:

  1. Të mund të hidhte këtë adapter në çdo moment dhe të zëvendësohej me ndonjë tjetër që i bie rastësisht.
  2. TRIM/Discard ka funksionuar normalisht në disqe, pasi komanda të tilla nuk mbështeten realisht në firmware RAID, ndërsa HBA në përgjithësi nuk i intereson se cilat komanda dërgohen përmes shiritit.

Disqe tĂ« forta, — 8 copĂ« HGST Travelstar 7K1000 me kapacitet 1 TB nĂ« formatin 2.5, si pĂ«r laptopĂ«. KĂ«to disqe ishin mĂ« parĂ« nĂ« njĂ« grup RAID 6. NĂ« sistemin e ri do tĂ« gjejnĂ« gjithashtu pĂ«rdorim. PĂ«r ruajtjen e backup-eve lokale.

Për më tepër është shtuar:

6 copë SATA SSD model Samsung 860 QVO 2TB. Këto SSD kërkonin një volum të madh, praninë e SLC cache, preferohej besueshmëria, dhe një çmim të ulët. Mbështetje për discard/zero ishte e detyrueshme, e cila kontrollohet nga linja në dmesg:

kernel: ata1.00: Duke aktivizuar discard_zeroes_data

2 copë NVMe SSD model Samsung SSD 970 EVO 500GB.

PĂ«r kĂ«to SSD, shpejtĂ«sia e leximit/shkrimit tĂ« rastĂ«sishĂ«m Ă«shtĂ« e rĂ«ndĂ«sishme dhe burimi sipas nevojave tuaja. NjĂ« radiator pĂ«r to. Absolutisht. Dhe ndryshe, — do t’i skuqni deri nĂ« skuqje nĂ« sinkronizimin e parĂ« tĂ« RAID-it.

Adapteri StarTech PEX8M2E2 për 2 x NVMe SSD të instaluara në slotin PCIe 3.0 8x. Ky, gjithashtu, është thjesht HBA, por për NVMe. Dallohet nga adapterët e lirë me mungesën e kërkesës për mbështetje PCIe bifurcation nga motherboard-i falë pranishmërisë së një switch-i PCIe të integruar. Do të funksionojë edhe në sistemin më të vjetër që ka PCIe, madje edhe nëse është një slot x1 PCIe 1.0. Sigurisht, me shpejtësinë përkatëse. Atje nuk ka RAID. Nuk ka BIOS të integruar. Pra, sistemi juaj nuk do të mësojë magjikisht të boot nga NVMe dhe sidomos të krijojë NVMe RAID falë këtij pajisjeje.

Ky komponent ishte i justifikuar vetëm nga disponimi i një sloti 8x PCIe 3.0 të lirë në sistem, dhe, nëse do të kishin dy slot të lirë, lehtësisht mund të zëvendësohej me dy PEX4M2E1 të lirë ose analoge, të cilat mund të blihen kudo për një çmim që fillon nga 600 rubla.

Shkëlqimi nga çdo RAID-i harduerik ose të integruar në chipset/Bios u bë me vetëdije, me qëllim që të ketë mundësinë për të zëvendësuar krejtësisht të gjithë sistemin, përveç SSD/HDD-ve, duke ruajtur të dhënat e gjitha. Në mënyrë ideale, që të ruhej madje edhe sistemi operativ i instaluar kur kaloni në harduer të ri/të ndryshëm. E rëndësishme është që të ketë porte SATA dhe PCIe. Kjo është si një CD live ose një USB bootues, vetëm shumë e shpejtë dhe pak më e madhe.

HumorSepse, e dini si ndodh, — ndonjeherĂ« duhet tĂ« merrni tĂ« gjithĂ« grupin me vete. Dhe nuk dĂ«shironi tĂ« humbni tĂ« dhĂ«nat. PĂ«r kĂ«tĂ« arsye, tĂ« gjitha mediat e pĂ«rmendura janĂ« pozicionuar rehat nĂ« rrĂ«shqitĂ«se nĂ« disqet 5.25 tĂ« njĂ« kutie standarde.

Patjetër, edhe për eksperimente me metoda të ndryshme të caching SSD në Linux.

RAID-të harduerike janë të mërzitshme. I aktivizoni. Ai funksionon ose jo. Ndërsa me mdadm gjithmonë ka mundësi.

Softi

Më parë në harduer ishte instaluar Debian 8 Jessie që është afër EOL. Ishte krijuar një RAID 6 nga HDD-të e përmendura më lart në çift me LVM. Në të ishin të instaluara makinat virtuale në kvm/libvirt.

Përderisa autori ka përvojën e duhur në krijimin e flash drive-portabël SATA/NVMe, si dhe që të mos dëmtojë modelin e zakonshëm apt, sistemi që u zgjodh si qëllim ishte Ubuntu 18.04, i cili tashmë është mjaft stabilizuar, por ende ka 3 vjet mbështetje në perspektivë.

Në sistemin e përmendur janë të pranishëm të gjithë drejtuesit e nevojshëm të harduerit nga kutia. Nuk do të na nevojitet ndonjë softuer ose drejtues i jashtëm.

Përgatitja për instalim

Për instalimin e sistemit do të na nevojitet Ubuntu Desktop Image. Sistemi server ka një instalues shumë të avancuar, i cili tregon një autonomi të tepruar duke futur në mënyrë të detyruar një partition sistemik UEFI në një nga diskët duke prishur të gjithë bukurinë. Pra, instalohet vetëm në mënyrën UEFI. Nuk ofron alternativa.

Kjo nuk na kënaq.

Pse?Fatkeqësisht, ngarkimi UEFI është jashtëzakonisht i papërshtatshëm me RAID-in e programit, pasi rezervimi për partitionin ESP UEFI nuk ofrohet nga askush. Në internet ekzistojnë receta që sugjerojnë të vendoset partitioni ESP në një flash drive në portin USB, por, kjo është një pikë dëmtimi. Ekzistojnë receta që përdorin RAID 1 programatik mdadm me metadata version 0.9 që nuk pengojnë UEFI BIOS të kenë akses në këtë partition, por, kjo jeton deri në momentin e lumtur kur BIOS-i ose një sistem tjetër në hardware shkruan gjëra në ESP pa e bërë sinkronizimin me mirrorët e tjerë.

Përveç kësaj, ngarkimi UEFI varet nga NVRAM, i cili nuk do të transferohet së bashku me diskët në sistemin e ri, pasi është pjesë e pllakës amë.

Pra, ne nuk do të shpikim një biçikletë të re. Ne tashmë kemi një biçikletë të gatshme, të verifikuar me vite, e njohur si Legacy/BIOS boot, e cila mban emrin krenar CSM në sistemet e përshtatshme me UEFI. Ne thjesht do ta nxjerrim atë nga rafte, do ta vajosim, do të fryjmë gomarët dhe do ta fshijmë me një pecetë të lagur.

Versioni Desktop i Ubuntu gjithashtu nuk është i aftë të instalohet normalisht me ngarkuesin Legacy, por këtu, siç thonë, për të paktën ka mundësi.

Dhe kĂ«shtu, ne grumbullojmĂ« harduerin dhe ngarkojmĂ« sistemin duke pĂ«rdorur flash drive-nĂ« Ubuntu Live. Do tĂ« na nevojitet tĂ« shkarkojmĂ« paketat, kĂ«shtu qĂ« rregullojmĂ« rrjetin, çfarĂ«do qĂ« tĂ« jetĂ«. NĂ«se nuk funksionon — paketat e nevojshme mund tĂ« ngarkohen paraprakisht nĂ« flash drive.

Hyjmë në ambientin Desktop, hapim emulatorin e terminalit dhe, le të fillojmë:

#sudo bash

Si
?Rreshti i mësipërm është një triger kanonik për polemikat mbi sudo. Me fuqitë më të mëdha vjen edhe përgjegjësia më e madhe. Pyetja është, a do të jeni në gjendje ta merrni atë mbi vete? Shumë besojnë se përdorimi i sudo në këtë mënyrë është, të paktën, i pakujdesshëm. Megjithatë:oMë shumë mundësi vijnë me njëopërgjegjësi më të madhe. Pyetja është nëse do të jeni të aftë ta merrni atë mbi vete. Shumë mendojnë se përdorimi i sudo në këtë mënyrë është, të paktën, jo i kujdesshëm. Megjithatë:

Luaj videon

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

Pse jo ZFS
?Kur instalojmë software në kompjuterin tonë, në thelb, ne po e huazojmë harduerin tonë zhvilluesve të këtij software.
Kur besojmë se ky software do të mbajë të sigurt të dhënat tona, ne marrim një kredi që është e barabartë me vlerën e rikuperimit të këtyre të dhënave, për të cilat një ditë do të na duhet të paguajmë.

Nga ky këndvështrim, ZFS është një Ferrari, ndërsa mdadm+lvm më shumë ngjan me një biçikletë.

Subjektivisht, autori preferon të huazojë një biçikletë të marrë me kredi nga persona të panjohur në vend të një Ferrarien. Atje çështja e çmimit nuk është e lartë. Nuk ka nevojë për leje. Më e thjeshtë për t'u përdorur. Parkimi është falas. Kalueshmëria është më e mirë. Për biçikletën gjithmonë mund të shtoni këmbë, po ashtu dhe ta riparoni vetë.

Pse atĂ«herĂ« BTRFS
?PĂ«r tĂ« ngarkuar sistemin operativ na nevojitet njĂ« sistem skedarĂ«sh i mbĂ«shtetur nĂ« GRUB-in Legacy/BIOS nga kutia, dhe, pĂ«r mĂ« tepĂ«r, qĂ« mbĂ«shtet instant snapshot nĂ« jetĂ«n reale. Do ta pĂ«rdorim atĂ« pĂ«r partitionin /boot. PĂ«rveç kĂ«saj, autori preferon ta pĂ«rdorĂ« kĂ«tĂ« FS pĂ«r / (rrĂ«njĂ«), pa harruar tĂ« theksojĂ« se pĂ«r çdo soft tjetĂ«r mund tĂ« krijohen partitione tĂ« veçanta mbi LVM dhe tĂ« montohen nĂ« katalogĂ«t pĂ«rkatĂ«s.

As imazhe makinave virtualedhe as databaza nuk do të ruhen në këtë FS.
Kjo FS do të përdoret vetëm për krijimin e snapshots të menjëhershme të sistemit pa e fikur atë dhe më pas për transferimin e këtyre snapshots në një disk rezervë duke përdorur send/recieve.

Përveç kësaj, autori në përgjithësi preferon të mbajë minimumin e software-it drejtpërdrejt në harduer dhe të ekzekutojë të gjithë softin tjetër në makina virtuale duke përdorur gjëra si kalimi i GPU-s dhe kontrolleve PCI-USB Host në KVM përmes IOMMU.

NĂ« harduer mbeten vetĂ«m — ruajtja e tĂ« dhĂ«nave, virtualizimi dhe backupi.

Nëse ju besoni më shumë ZFS, atëherë, në parim, për përdorimin e përmendur ato janë të ndërrueshme.

Megjithatë, autori me vetëdije injoron funksionet e ndërtuara të pasqyrimit/RAID-it dhe tepricës që janë në ZFS, BRTFS dhe LVM.

Si një argument shtesë, BTRFS ka kaptimin e tij për të kthyer shkrimin rastësor në të njëjtën seri, e cila ndikon shumë pozitivisht në shpejtësinë e sinkronizimit të kopjeve rezervë / snapshots në HDD.

Do të skanojmë përsëri të gjitha pajisjet:

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

Do të shikojmë rreth:

#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

Strukturimi i "disqeve"

NVMe SSD

Por ne nuk do t'i ndajmĂ« ato. ÇfarĂ«do qoftĂ«, BIOS-i ynĂ« nuk e sheh kĂ«tĂ« ruajtje. Prandaj, ato do tĂ« shkojnĂ« krejtĂ«sisht nĂ« RAID software. As nuk do tĂ« krijojmĂ« ndarje atje. NĂ«se dĂ«shironi sipas "kanunit" ose "princit" — krijoni njĂ« ndarje tĂ« madhe, si nĂ« HDD.

SATA HDD

Këtu nuk nevojitet shumë shpikje. Ne do të krijojmë një ndarje për të gjithë. E krijojmë ndarjen sepse këto disqe i sheh BIOS-i dhe madje mund të përpiqet të bootstrap nga ato. Madje do të instalojmë më vonë GRUB në këto disqe që sistemi të arrijë ta bëjë atë.

#cat >hdd.part << EOF
etiketa: dos
etiketa-id: 0x00000000
dispositiv: /dev/sdg
njësia: sektore

/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

Këtu kemi gjërat më interesante.

Së pari, ruajtësit tanë kanë një madhësi prej 2 TB. Kjo është brenda limitit të lejuar për MBR, dhe ne do ta përdorim këtë. Nëse është e nevojshme, mund të zëvendësohet me GPT. Disku GPT ka një nivel përputhshmërie që lejon sistemet e përputhshme me MBR të shohin katër ndarjet e para nëse ato janë të vendosura brenda dy terabajtëve të parë. E rëndësishme është që ndarja boot dhe ndarja bios_grub në këto disqe të jenë në fillim. Kjo lejon madje edhe ngarkimin Legacy/BIOS nga disqet GPT.

Megjithatë, kjo nuk është rasti ynë.

Këtu do të krijojmë dy ndarje. E para do të ketë një madhësi prej 1 GB dhe do të përdoret për RAID 1 /boot.

E dyta do të përdoret për RAID 6 dhe do të marrë gjithë hapësirën e mbetur të lirë përveç një zone të vogël të pa ndarë në fund të ruajtësit.

ÇfarĂ« Ă«shtĂ« kjo zonĂ« e pa ndarĂ«?Sipas burimeve nĂ« internet, SATA SSD-tĂ« tona kanĂ« njĂ« cache SLC qĂ« zgjeron dinamikisht nga 6 deri nĂ« 78 gigabajt. 6 gigabajt i marrim "falas" pĂ«r shkak tĂ« diferencĂ«s midis "gigabajtĂ«ve" dhe "gibibajtĂ«ve" nĂ« kartelĂ«n teknike tĂ« ruajtĂ«sit. 72 gigabajt e tjera ndahen nga hapĂ«sira e papĂ«rdorur.

KĂ«tu duhet tĂ« theksohet se cache Ă«shtĂ« SLC, dhe vendi merret nĂ« mĂ«nyrĂ« 4 bit MLC. ÇfarĂ« do tĂ« thotĂ« efektivisht pĂ«r ne Ă«shtĂ« se pĂ«r çdo 4 gigabajt hapĂ«sirĂ« tĂ« lirĂ« do tĂ« marrim vetĂ«m 1 gigabajt cache SLC.

Shumojmë 72 gigabajt me 4 dhe marrim 288 gigabajt. Ky është vendi i lirë që ne nuk do ta ndajmë, në mënyrë që të lejojmë ruajtësit të përdorin plotësisht SLC cache.

Në këtë mënyrë, ne do të arrijmë efektivisht deri në 312 gigabajt SLC cache në total nga gjashtë ruajtësit. Nga të gjithë ruajtësit, 2 do të përdoren në RAID për redundancë.

Kjo sasi caches do të na mundësojë të përballemi shumë rrallë me situatën kur shkrimi nuk bëhet në cache. Kjo kompenson jashtëzakonisht mirë disavantazhin më të keq të memories QLC, - shkallën shumë të ulët të shkrimit kur të dhënat shkruhen jashtë caches. Nëse ngarkesat e tuaja nuk përputhen me këtë, rekomandoj të mendoni seriozisht se sa do të durojë SSD-të tuaja nën një ngarkesë të tillë duke pasur parasysh TBW nga pasaporta teknike.

#cat >ssd.part << EOF
etiketa: dos
etiketa-id: 0x00000000
dispozitiv: /dev/sda
njësia: sektore

/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

Krijimi i grupeve

Për fillim, duhet të rishikojmë emrin e makinës. Kjo është e nevojshme, sepse emri i host-it është një pjesë e emrit të grupit diku brenda mdadm dhe ndikon në diçka. Grupet sigurisht që mund të rishikohen më vonë, por kjo është një veprim shtesë.

#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

Pse –assume-clean
?PĂ«r tĂ« mos inicializuar grupet. PĂ«r tĂ« dy nivelet RAID 1 dhe 6, kjo Ă«shtĂ« e pranueshme. TĂ« gjitha mund tĂ« funksionojnĂ« edhe pa inicializim, nĂ«se ky Ă«shtĂ« njĂ« grup i ri. PĂ«r mĂ« tepĂ«r, inicializimi i njĂ« grupi SSD gjatĂ« krijimit Ă«shtĂ« njĂ« humbje e kotĂ« e burimeve TBW. Ne pĂ«rdorim TRIM/DISCARD kur Ă«shtĂ« e mundur nĂ« grupet SSD tĂ« ndĂ«rtuara pĂ«r t'i 'inicializuar'.

Grupet SSD RAID 1 mbështesin DISCARD nga kutia.

Te grupet SSD RAID 6, DISCARD duhet të aktivizohet në parametrat e modulit të bërthamës.

Kjo duhet bërë vetëm kur të gjitha SSD-të që përdoren në grupet e niveleve 4/5/6 në këtë sistem kanë mbështetje të funksionit discard_zeroes_data. Nganjëherë hasen disqe të çuditshme, të cilat njoftojnë bërthamën për mbështetje të këtij funksioni, por në fakt, nuk e kanë, ose funksioni nuk funksionon gjithmonë. Në këtë moment, mbështetja ka pothuajse kudo, megjithatë, disqet më të vjetra dhe firmware të gabuara ndodhin. Për këtë arsye, mbështetja DISCARD është e çaktivizuar si parazgjedhje për RAID 6.

Kujdes, komanda e ardhshme do të shkatërrojë të dhënat në disqet NVMe duke 'inicializuar' grupin me 'zero'.

#blkdiscard /dev/md0

Nëse diçka shkoi keq, provoni të specifikoni hapat.

#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

Pse kaq e madhe
?Rritja e chunk-size ka një ndikim pozitiv në shpejtësinë e leximit të rastësishëm në blloqe deri në chunk-size përfshirë. Kjo ndodh për shkak se një operacion përkatës i këtij madhësie ose më i vogël mund të realizohet plotësisht në një pajisje. Prandaj, IOPS nga të gjitha pajisjet përmbledhin. Sipas statistikave, 99% e IO nuk i tejkalon 512K.

Te RAID 6, IOPS për shkrim përherë më pak ose barabartë me IOPS të një disku. Ndërsa për leximin e rastësishëm, IOPS mund të jetë shumë më i madh se ai i një disku, dhe këtu madhësia e bllokut ka një rëndësi kyç.
Autori nuk sheh kuptim në përpjekjet për të optimizuar parametrin që është i dobët te RAID 6 për natyrë dhe përkundrazi optimizon atë çka RAID 6 tregon rezultate të mira.
Do ta kompensojmë shkrimin e dobët të rastësishëm të RAID 6 me një cache në NVMe dhe me truke të thin-provisioning.

Për momentin nuk kemi aktivizuar DISCARD për RAID 6. Prandaj, nuk do ta 'inizializojmë' këtë grup akoma. Do ta bëjmë më vonë, pas instalimit të OS.

SATA HDD

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

LVM mbi NVMe RAID

Për shpejtësi, do të vendosim sistemin e skedarëve rrënjësor në NVMe RAID 1 që është /dev/md0.
Megjithatë, ky grup i shpejtë do të na nevojitet edhe për nevoja të tjera si swap, metadata dhe cache LVM-cache dhe metadata LVM-thin, prandaj, në këtë grup do të krijojmë LVM VG.

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

Do të krijojmë një ndarje për sistemin e skedarëve rrënjësor.

#lvcreate -L 128G --name root root

Do të krijojmë një ndarje për swap me madhësi të memories operative.

#lvcreate -L 32G --name swap root

Instalimi i OS

Pra, kemi gjithçka të nevojshme për të instaluar sistemin.

Nisim master-in e instalimit të sistemit nga ambienti Ubuntu Live. Instalimi i zakonshëm. Vetëm gjatë fazës së zgjedhjes së disqeve për instalim, duhet të tregojmë se:

  • /dev/md1, — Ń‚ĐŸŃ‡ĐșĐ° ĐŒĐŸĐœŃ‚ĐžŃ€ĐŸĐČĐ°ĐœĐžŃ /boot, ЀХ — BTRFS
  • /dev/root/root (a.k.a /dev/mapper/root-root), — Ń‚ĐŸŃ‡ĐșĐ° ĐŒĐŸĐœŃ‚ĐžŃ€ĐŸĐČĐ°ĐœĐžŃ / (ĐșĐŸŃ€Đ”ĐœŃŒ), ЀХ — BTRFS
  • /dev/root/swap (a.k.a /dev/mapper/root-swap), — ĐžŃĐżĐŸĐ»ŃŒĐ·ĐŸĐČать ĐșĐ°Đș разЎДл ĐżĐŸĐŽĐșачĐșĐž
  • Instalimi i boot loader-it nĂ« /dev/sda

Kur zgjidhni BTRFS si sistemin e skedarëve rrënjësor, instaluesi automatikisht do të krijojë dy volume BTRFS me emrat '@' për / (rrënjën), dhe '@home' për /home.

Nisim instalimin


Instalimi do të përfundojë me një dialog modal që njofton për një gabim të instalimit të boot loader-it. Fatkeqësisht, nuk do të mund të dalim nga ky dialog me mjete standarde dhe të vazhdojmë instalimin. Bëjmë logout nga sistemi dhe loginohemi përsëri, duke arritur në një desktop të pastër Ubuntu Live. Hapur terminalin, dhe përsëri:

#sudo bash

Krijojmë një ambient chroot për të vazhduar instalimin:

#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

Konfigurojmë rrjetin dhe hostname-in në chroot:

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

Hyjmë në ambientin chroot:

#chroot /mnt/chroot

E para që do të bëjmë është të instalojmë paketat:

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

Do të kontrollojmë dhe rregullojmë të gjitha paketat që janë instaluar keq për shkak të një instalimi të papërfunduar të sistemit:

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

NĂ«se diçka nuk funksionon, ndoshta do t’ju nevojitet tĂ« redaktoni mĂ« parĂ« /etc/apt/sources.list

Rregullojmë parametrat për modulin RAID 6 për të aktivizuar TRIM/DISCARD:

#cat >/etc/modprobe.d/raid456.conf << EOF
opsione raid456 pajisje_handle_discard_safely=1
EOF

Pak do ta rregullojmë grupin tonë:

#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

ÇfarĂ« ishte kjo..?Kemi krijuar njĂ« grup rregullash udev qĂ« do tĂ« bĂ«jnĂ« kĂ«tĂ«:

  • TĂ« vendosin njĂ« madhĂ«si tĂ« pĂ«rshtatshme pĂ«r 2020-n pĂ«r cache bllokesh pĂ«r RAID 6. Vlera nĂ« default, duket, nuk ka ndryshuar qĂ« nga krijimi i Linux-it dhe nuk Ă«shtĂ« mĂ« e pĂ«rshtatshme.
  • TĂ« rezervojnĂ« minimal IO pĂ«r periudha verifikimi/sinkronizimi tĂ« grupeve. Kjo Ă«shtĂ« e nevojshme qĂ« grupet tuaja tĂ« mos ngecin nĂ« njĂ« gjendje sinkronizimi tĂ« pĂ«rjetshĂ«m nĂ«n ngarkesĂ«.
  • TĂ« kufizojnĂ« maksimal IO pĂ«r periudha verifikimi/sinkronizimi tĂ« grupeve. Kjo Ă«shtĂ« e nevojshme qĂ« sinkronizimi/verifikimi i RAID-Ă«ve SSD tĂ« mos i mbushĂ« disqet tuaj deri nĂ« skuqje. VeçanĂ«risht nĂ« rastin e NVMe. (Mos harroni pĂ«r radiatorin? Nuk isha duke shkruar pa arsye.)
  • TĂ« ndalojnĂ« pĂ«rmes APM disqet qĂ« tĂ« ndalin rrotullimin e shpindĂ«s, (HDD) dhe tĂ« vendosin njĂ« afat pĂ«r gjumin e kontrolleve tĂ« disqeve prej 7 orĂ«sh. Mund tĂ« çaktivizoni plotĂ«sisht APM nĂ«se disqet tuaja e pĂ«rballojnĂ« kĂ«tĂ« (-B 255). Me vlerĂ«n nĂ« default, disqet do tĂ« ndalojnĂ« pas pesĂ« sekondash. Pastaj OS do tĂ« dĂ«shirojĂ« tĂ« rikthejĂ« cache-in e disqeve, disqet do tĂ« rrotullohen pĂ«rsĂ«ri, dhe gjithçka do tĂ« fillojĂ« nga e para. Disku ka njĂ« numĂ«r maksimal tĂ« rrotullimeve tĂ« shpindĂ«s. Ky cikĂ«l i thjeshtĂ« nĂ« default mund ta vrasĂ« lehtĂ«sisht disqet tuaja brenda disa vitesh. Kjo nuk ndodh me tĂ« gjithĂ« disqet, por disqet tona 'laptop', me cilĂ«sime tĂ« pĂ«rshtatshme nĂ« default, tĂ« cilat e bĂ«jnĂ« RAID-in njĂ« kopje tĂ« deformuar tĂ« mini-MAID.
  • TĂ« vendosin readahead nĂ« disqet (tĂ« rrotullueshme) nĂ« 1 megabajt - dy bllokĂ« tĂ« pĂ«rbashkĂ«t/chunk RAID 6
  • TĂ« ndalojnĂ« readahead nĂ« vetĂ« grupet.

Le të rregullojmë /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
Pse kështu..?Ndarja /boot do ta kërkojmë sipas UUID sepse emërtimi i grupeve teorikisht mund të ndryshojë.

Ndarjet e tjera do t’i kĂ«rkojmĂ« sipas emrave LVM nĂ« notacionin /dev/mapper/vg-lv, pasi ato identifikojnĂ« mjaft unikisht ndarjet.

Nuk përdorim UUID për LVM pasi UUID i volumit dhe snapshot-ëve të LVM mund të përshtaten.Mund të montojmë dy herë /dev/mapper/root-root..?Po. Pikërisht kështu. Një veçori e BTRFS. Ky sistem skedarësh mund të montohet disa herë me subvol të ndryshëm.

Si pasojë e kësaj veçorie, rekomandoj kurrë të krijoni snapshot-e LVM të grupeve aktive BTRFS. Mund të keni një surprizë gjatë rinisjes.

Rregullojmë konfigurimin e mdadm:

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

Të rregullojmë cilësimet 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

ÇfarĂ« ishte kjo..?Kemi aktivizuar zgjerimin automatik tĂ« grupeve LVM thin kur arrijmĂ« 90% tĂ« hapĂ«sirĂ«s sĂ« zĂ«nĂ« pĂ«r 5% tĂ« kapacitetit.

Kemi rritur numrin maksimal të blloqeve të memorizimit për LVM cache.

Kemi ndaluar LVM të kërkojë volume LVM (PV) në:

  • disqe qĂ« pĂ«rmbajnĂ« LVM cache (cdata)
  • disqe tĂ« memorizuara me ndihmĂ«n e LVM cache duke shmangur memorizimin (<lv_name>_corig). MegjithatĂ«, disku i memorizuar do tĂ« skanohet pĂ«rmes memorizimit (thjesht <lv_name>).
  • disqe qĂ« pĂ«rmbajnĂ« metadata tĂ« LVM cache (cmeta)
  • tĂ« gjitha disqet nĂ« VG me emrin images. KĂ«tu do tĂ« kemi imazhe tĂ« disqeve tĂ« makinave virtuale, dhe ne nuk dĂ«shirojmĂ« qĂ« LVM nĂ« host tĂ« aktivizojĂ« volume qĂ« i pĂ«rkasin sistemit operativ mysafir.
  • tĂ« gjitha disqet nĂ« VG me emrin backup. KĂ«tu do tĂ« kemi kopje rezervĂ« tĂ« imazheve tĂ« makinave virtuale.
  • tĂ« gjitha disqet emri i tĂ« cilave pĂ«rfundon me «gpv» (guest physical volume)

Kemi aktivizuar mbështetje për DISCARD kur lirohet hapësira e lirë në LVM VG. Kini kujdes. Kjo do ta bëjë fshirjen e LV në SSD mjaft të gjatë. Kjo vlen veçanërisht për SSD RAID 6. Megjithatë, sipas planit, do të përdorim thin provisioning, kështu që, kjo nuk do të na pengojë aspak.

Do të përditësojmë imazhin initramfs:

#update-initramfs -u -k all

Do të instalojmë dhe konfigurojmë grub:

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

Cilat disqe të zgjedhim?Të gjitha që janë sd*. Sistemi duhet të jetë në gjendje të ngarkohet nga çdo disk SATA ose SSD i punueshëm.

Pse e ndalëm os-prober..?Për vetë-këmbëngulësinë e tepruar dhe duarsh të padisiplinuara.

Ai nuk punon siç duhet nëse një nga RAID-et është në një gjendje të degraduar. Ai përpiqet të kërkojë sistemin operativ në particionet që përdoren në makinat virtuale që punojnë në këtë harduer.

Nëse ju nevojitet, mund ta lini, por keni parasysh të gjitha këto. Rekomandoj të kërkoni receta për të hequr duarsh e padisiplinuara në internet.

Me kĂ«tĂ«, ne pĂ«rfundoi instalimin fillestar. ËshtĂ« koha tĂ« rinisni nĂ« sistemin operativ tĂ« sapo instaluar. Mos harroni tĂ« hiqni CD/USB Live tĂ« ngarkuesit.

#exit
#reboot

Si pajisje ngarkimi zgjedhim një nga SATA SSD.

LVM në SATA SSD

Në këtë pikë, ne tashmë kemi ngarkuar në sistemin e ri, kemi konfiguruar rrjetin, apt, hapëm emulatorin e terminalit dhe nisëm:

#sudo bash

Të vazhdojmë.

«Inicializojmë» masivin nga SATA SSD:

#blkdiscard /dev/md2

NĂ«se nuk funksionon, provoni:

#blkdiscard --step 65536 /dev/md2
Krijojmë LVM VG në SATA SSD:

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

Pse një tjetër VG..?Vërtet, ne tashmë kemi një VG me emrin root. Pse të mos shtojmë gjithçka në një VG?

Nëse në VG ka disa PV, për aktivizimin e saktë të VG-së, të gjithë PV-të duhet të jenë të pranishëm (online). Përjashtim është LVM RAID, të cilin ne nuk do ta përdorim me qëllim.

Ne dëshirojmë që në rastin e ndalimit (lexo humbje të të dhënave) në ndonjë nga masivët RAID 6, sistemi operativ të ngarkohet normalisht dhe të na japë mundësinë për të zgjidhur problemin.

Për këtë, në nivelin e parë të abstraksionit, ne do të izolojmë çdo lloj fiziku "mbajtësi" në një VG të veçantë.

Nëse flasim shkencërisht, masivët e ndryshëm RAID i përkasin domenesh të ndryshëm besueshmërie. Nuk ka kuptim të krijojmë një pikë të përbashkët dështimi duke i ngjeshur ato në një VG.

Prania e LVM në nivelin "harduer" do të na lejojë të presim pjesë të ndryshme nga masivat e ndryshme RAID duke i kombinueshëm ndryshe. Për shembull, - të nisni në të njëjtën kohë bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, një konfigurim të komplikuar ZFS me kashë ose çdo përzierje tjetër infernale për ta prekur dhe krahasuar.

Në nivelin "harduer" ne nuk do të përdorim asgjë tjetër përveç LVM volumesh "të trasha" të vjetra të mira. Përjashtimi nga ky rregull, ndoshta, do të jetë ndarja për kopje rezervë.

Mendoj se në këtë pikë, shumë lexues tashmë kanë filluar të dyshojnë për diçka rreth matreshkës.

LVM në SATA HDD

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

Përsëri një VG e re..?Ne shumë dëshirojmë që në rastin e ndalimit të masivit të disqeve që do të përdorim për kopje rezervë të të dhënave, sistemi ynë operativ të vazhdojë të funksionojë normalisht, duke ruajtur gjithashtu qasjen në të dhënat jo të rezervuara. Prandaj, për të shmangur problemet e aktivizimit të VG-së, - krijojmë një VG të veçantë.

Konfigurimi i LVM cache

Do të krijojmë LV në NVMe RAID 1 për ta përdorur si pajisje memorizimi.

#lvcreate -L 70871154688B --name cache root

Pse ka kaq pak
?Fjala është se edhe NVMe SSD tona kanë memorizim SLC. 4 gigabajt "falas" dhe 18 gigabajt të dinamikëve për shkak të hapësirës së lirë të zënë në 3-bit MLC. Me përfundimin e këtij memorizimi, NVMe SSD do të bëhen jo shumë më të shpejtë se SATA SSD tonë me memorizim. Në fakt, për këtë arsye nuk ka kuptim të krijojmë një ndarje LVM cache shumë më të madhe se dyfishi i volumit të SLC memorizimit të njësisë NVMe. Për njësitë NVMe që përdoren, autori mendon se është e arsyeshme të bëhet 32-64 gigabajtë memorizim.

Madhësia e dhënë e ndarjes është e nevojshme për organizimin e 64 gigabajtëve të memorizimit, vendosjen e metadata të memorizimit dhe kopjimin e metadata.

SĂ« fundi, do tĂ« veçoj se pas njĂ« ndĂ«rprerjeje tĂ« papritur tĂ« sistemit, LVM do tĂ« shĂ«nojĂ« tĂ« gjithĂ« ĐșДшin si tĂ« ndotur dhe do tĂ« fillojĂ« njĂ« sinkronizim tĂ« ri. PĂ«r mĂ« tepĂ«r, kjo do tĂ« ndodhĂ« çdo herĂ« kur tĂ« pĂ«rdoret lvchange nĂ« kĂ«tĂ« pajisje deri nĂ« njĂ« rinisje tĂ« re tĂ« sistemit. Prandaj, rekomandoj qĂ« tĂ« krijoni menjĂ«herĂ« ĐșДшin me skenarin pĂ«rkatĂ«s.

TĂ« krijojmĂ« LV nĂ« SATA RAID 6 pĂ«r ta pĂ«rdorur si pajisje qĂ« mund tĂ« ruhet nĂ« ĐșДш.

#lvcreate -L 3298543271936B --name cache data

Pse vetĂ«m tre terabajtĂ«..?NĂ« mĂ«nyrĂ« qĂ«, nĂ« rast nevoje, tĂ« mund tĂ« pĂ«rdoret SATA SSD RAID 6 pĂ«r ndonjĂ« qĂ«llim tjetĂ«r. MadhĂ«sia e hapĂ«sirĂ«s sĂ« keshit mund tĂ« rritet dinamikisht, nĂ« fluks, pa ndalur punĂ«n e sistemit. PĂ«r kĂ«tĂ«, Ă«shtĂ« e nevojshme tĂ« ndalohet pĂ«rkohĂ«sisht dhe tĂ« riaktivohet ĐșДшi, por, avantazhi i dallueshĂ«m i LVM-cache ndaj, pĂ«r shembull, bcache, Ă«shtĂ« se kjo mund tĂ« bĂ«het nĂ« fluks.

TĂ« krijojmĂ« njĂ« VG tĂ« re pĂ«r ĐșДшin.

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

TĂ« krijojmĂ« LV nĂ« pajisjen qĂ« mund tĂ« ruhet nĂ« ĐșДш.

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

Këtu ne kemi kërkuar menjëherë të gjithë hapësirën e lirë në /dev/data/cache në mënyrë që të gjitha pjesët e nevojshme të krijohen menjëherë në /dev/root/cache. Nëse keni krijuar diçka diku tjetër, mund ta transferoni me pvmove.

TĂ« krijojmĂ« dhe tĂ« aktivizojmĂ« ĐșДшin:

#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

Pse një chunksize të tillë..?Me anë të eksperimentimeve praktike, autori ka arritur të zbulojë se rezultati më i mirë arrihet kur madhësia e bllokut të LVM cache përputhet me madhësinë e bllokut të LVM thin. Në këtë rast, sa më e vogël të jetë madhësia, aq më mirë do të sillet konfigurimi në rastin e shkrimeve të rastësishme.

64k është madhësia minimale e bllokut të pranueshme për LVM thin.

Kujdes writeback..!Po. Ky lloj keshit shtyn sinkronizimin e shkrimeve nĂ« pajisjen qĂ« mund tĂ« ruhet nĂ« ĐșДш. Kjo çon nĂ« atĂ« qĂ«, nĂ« rast humbjeje tĂ« ĐșДшit, mund tĂ« humbni tĂ« dhĂ«na nĂ« pajisjen qĂ« mund tĂ« ruhet. MĂ« vonĂ«, autori do tĂ« flasĂ« pĂ«r masat, pĂ«rveç NVMe RAID 1, qĂ« mund tĂ« merren pĂ«r tĂ« kompensuar kĂ«tĂ« rrezik.

Ky lloj keshit është zgjedhur me qëllim, për t'u kompensuar rendimenti i ulët i RAID 6 në rastin e shkrimeve të rastësishme.

Të kontrollojmë se çfarë kemi arritur:

#lvs -a -o lv_name,lv_size,devices --units B cache
Pajisjet LV LSize
[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)

Në /dev/data/cache duhet të ndodhet vetëm [cachedata_corig]. Nëse diçka nuk shkon si duhet, përdorni pvmove.

Mund tĂ« çaktivizoni ĐșДшin nĂ« rast nevoje me njĂ« komandĂ«:

#lvconvert -y --uncache cache/cachedata

Kjo bĂ«het on-line. LVM thjesht sinkronizon ĐșДшin nĂ« disk, e heq atĂ« dhe e riemĂ«ron cachedata_corig pĂ«rsĂ«ri nĂ« cachedata.

Konfigurimi LVM thin

Të vlerësojmë përafërsisht se sa hapësirë na nevojitet për të dhënat e LVM thin:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
sipërfaqja e parashikuar e metadatave - 3385794560 byte për "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

Të rrumbullakosim deri në 4 gigabajtë: 4294967296B

Të shumëzojmë me dy dhe të shtojmë 4194304B për të dhënat LVM PV: 8594128896B
Të krijojmë një pjesë të veçantë në NVMe RAID 1 për të vendosur të dhënat e LVM thin dhe kopjen e tyre të rezervuar:

#lvcreate -L 8594128896B --name images root

Pse..?Këtu mund të lindë pyetja, pse të vendosen të dhënat e LVM thin veçmas, nëse ato do të keshin përfundimisht në NVMe dhe do të funksiononin shpejt.

ShpejtĂ«sia kĂ«tu Ă«shtĂ« e rĂ«ndĂ«sishme, por nuk Ă«shtĂ« shkaku kryesor. E gjithĂ« çështja Ă«shtĂ« qĂ« ĐșДшi Ă«shtĂ« njĂ« pikĂ« dĂ«shtimi. Mund tĂ« ndodhĂ« diçka me tĂ«, dhe, nĂ«se tĂ« dhĂ«nat e LVM thin janĂ« tĂ« kesh-uar, kjo do tĂ« çojĂ« nĂ« njĂ« humbje tĂ« plotĂ«. Pa tĂ« dhĂ«na tĂ« plota, krijimi i volumeve tĂ« hollĂ« do tĂ« jetĂ« pothuajse i pamundur.

Duke e transferuar tĂ« dhĂ«nat nĂ« njĂ« vĂ«llim tĂ« shpejtĂ« qĂ« nuk Ă«shtĂ« i kesh-uar, ne garantojmĂ« ruajtjen e tĂ« dhĂ«nave nĂ« rast humbjeje ose dĂ«mtimi tĂ« ĐșДшit. NĂ« kĂ«tĂ« rast, tĂ« gjitha dĂ«mtimet tĂ« shkaktuar nga humbja e ĐșДшit do tĂ« jenĂ« tĂ« lokalizuara brenda volumenve tĂ« hollĂ«, duke e bĂ«rĂ« procedurĂ«n e rikuperimit shumĂ« mĂ« tĂ« lehtĂ«. NĂ« mĂ«nyrĂ« tĂ« madhe, kĂ«to dĂ«mtime do tĂ« mund tĂ« rikuperohen me anĂ« tĂ« regjistrimeve tĂ« FS.

PĂ«r mĂ« tepĂ«r, nĂ«se mĂ« parĂ« Ă«shtĂ« krijuar njĂ« kopje e menjĂ«hershme e volumit tĂ« hollĂ«, dhe pas kĂ«saj, ĐșДшi Ă«shtĂ« sinkronizuar tĂ« paktĂ«n njĂ« herĂ«, pĂ«r shkak tĂ« veçorive tĂ« brendshme tĂ« LVM thin, integriteti i kopjĂ«s do tĂ« garantohet nĂ« rast humbjeje tĂ« ĐșДшit.

Të krijojmë një VG të re që do të jetë përgjegjëse për thin-provisioning:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Të krijojmë një vend:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Pse -Z yPĂ«rveç asaj pĂ«r tĂ« cilĂ«n ky mod Ă«shtĂ« paracaktuar, — pĂ«r tĂ« mos lejuar qĂ« tĂ« dhĂ«nat nga njĂ« makinĂ« virtuale tĂ« shkojnĂ« nĂ« njĂ« makinĂ« tjetĂ«r virtuale gjatĂ« riparĂ«s sĂ« hapĂ«sirĂ«s, — zeroing pĂ«rdoret gjithashtu pĂ«r tĂ« rritur shpejtĂ«sinĂ« e shkrimeve tĂ« rastĂ«sishme me blloqe mĂ« tĂ« vogla se 64k. Çdo shkrim mĂ« i vogĂ«l se 64k nĂ« njĂ« zonĂ« tĂ« papĂ«rcaktuar tĂ« volumit tĂ« hollĂ« do tĂ« shndĂ«rrohet nĂ« 64K tĂ« pĂ«rshtatur me kufirin e ĐșДшit. Kjo do tĂ« lejojĂ« qĂ« operacioni tĂ« ekzekutohet plotĂ«sisht pĂ«rmes ĐșДшit, duke kaluar pĂ«rtej pajisjes qĂ« mund tĂ« ruhet.

Të transferojmë LV në PV-të përkatëse:

#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

Kontrolloni:

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

Të krijojmë një volum të hollë për teste:

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

Të instalojmë paketat për teste dhe vëzhgim:

#apt-get install sysstat fio

Kështu mund të vëzhgojmë sjelljen e konfigurimit tonë të ruajtjes në kohë reale:

#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)'

Kështu mund të testojmë konfigurimin tonë:

#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

Kujdes! Burimi!Ky kyç do të ekzekutojë 36 teste të ndryshme, secili prej të cilëve do të zgjasë 4 sekonda. Gjysma e testeve janë për shkrim. Në 4 sekonda mbi NVMe, mund të bëni shumë shkrime. Deri në 3 gigabajt në sekondë. Pra, çdo ekzekutim i testeve për shkrim mund të konsumojë deri në 216 gigabajt resurs SSD.

Lexim dhe shkrim të përzier?Po. Ka kuptim të ekzekutoni testet për lexim dhe për shkrim veç e veç. Për më tepër, ka kuptim të sigurohesh që të gjitha cache-t janë sinkronizuar, për të mos lejuar që një shkrim i bërë më parë të ndikojë në lexim.

Rezultatet do të ndryshojnë ndjeshëm gjatë ekzekutimit të parë dhe pasuesve të tij, ndërsa cache-i dhe volume i hollë janë duke u mbushur, gjithashtu, në varësi të faktit nëse sistemi kishte arritur të sinkronizojë cache-t e mbushura gjatë ekzekutimit të kaluar.

Përveç kësaj, rekomandoj të masni shpejtësinë në një volum të hollë të mbushur, nga i cili sapo është bërë një snapshot. Autori kishte mundësinë të vëzhgonte se si shkrimi i rastësishëm përshpejtohej menjëherë pas krijimit të snapshot-it të parë, veçanërisht kur cache-i nuk ishte plotësisht mbushur. Kjo ndodh falë semantikës së shkrimit copy-on-write, përputhjes së blloqeve të cache dhe volumit të hollë, dhe sepse shkrimi i rastësishëm në RAID 6 shndërrohet në lexim të rastësishëm me RAID 6 dhe një shkrim të mëvonshëm në cache. Në konfigurimin tonë, leximi i rastësishëm me RAID 6 është deri në 6 herë (numri i SATA SSD-ve në grup) më i shpejtë se shkrimi. Duke qenë se blloqet për CoW alokohen një pas një nga pool-i i hollë, atëherë shkrimi, në shumicën e rasteve, kthehet gjithashtu në një tërësi.

Të dy këto karakteristika mund të shfrytëzohen përfitueshëm.

Snapshot-et "koherente" në cache

Për të zvogëluar rrezikun e humbjes së të dhënave në rast dëmtimi/përgjakjeje të cache-it, autori sugjeron të bëjë praktikën e rotacionit të snapshot-eve për të garantuar integritetin e tyre në këtë rast.

Së pari, falë faktit që metadatë e volumit të hollë ndodhen në një pajisje që nuk është në cache, metadatë do të jenë të integruara, dhe humbjet e mundshme do të izolohen brenda blloqeve të të dhënave.

Cikli i ardhshëm i rotacionit të snapshot-eve ofron një garanci për integritetin e të dhënave brenda snapshot-eve në rast të humbjes së cache-it:

  1. Për çdo volum të hollë me emrin krijojmë një snapshot me emrin .cached
  2. Do të vendosim pragun e migrimit në një vlerë të arsyeshme të lartë: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
  3. Në cikël kontrollojmë numrin e blloqeve të ndotura në cache: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' derisa të arrijmë zero. Nëse zero nuk është arritur për një kohë të gjatë, mund të krijohet përkohësisht duke e kaluar cache-in në modalitetin writethrough. Megjithatë, duke marrë parasysh karakteristikat e shpejtësisë së grupeve tona SATA dhe NVMe SSD, si dhe burimin e tyre TBW, ju do të jeni ose në gjendje ta kapni momentin mjaft shpejt edhe pa ndryshuar modalitetin e cache-it, ose pajisjet tuaja do ta konsumojnë të gjithë burimin e saj brenda disa ditësh. Për shkak të kufizimeve të burimit, sistemi në thelb nuk është në gjendje të qëndrojë nën 100% ngarkesë në shkrim gjithmonë. NVMe SSD-të tona nën 100% ngarkesë në shkrim do të shpenzojnë plotësisht burimin brenda 3-4 ditëve. SATA SSD do të jetojnë vetëm dyfish më gjatë. Prandaj, do të supozojmë se pjesa më e madhe e ngarkesës shkon në lexim, ndërsa për shkrimin kemi shpërthime të përkohshme të aktivitetit shumë të lartë së bashku me ngarkesë të ulët në mesatar.
  4. Sa herë që kapim (apo bëjmë) zéro - e ndryshojmë .cached në .committed. Në këtë rast, fshijmë të vjetrën .committed.
  5. Opcionalisht, nëse cache-i është plotësisht i mbushur, mund të rikrikohet me një skenar, duke e pastruar kështu. Me një cache të gjysmë të mbushur, sistemi funksionon shumë më shpejt në shkrim.
  6. Do të vendosim pragun e migrimit në zero: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Kjo përkohësisht do të ndalojë sinkronizimin e cache-it në pajisjen kryesore.
  7. Pritni derisa të grumbullohen mjaft ndryshime në cache #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' apo deri sa të aktivizohet timer-i.
  8. Përsëritim përsëri.

Pse kaq shumĂ« ndĂ«rlikim me pragun e migrimit
?E gjithĂ« arsyeja Ă«shtĂ« se nĂ« praktikĂ«, ‘shkrimi i rastĂ«sishĂ«m’ nĂ« tĂ« vĂ«rtetĂ« nuk Ă«shtĂ« aq rastĂ«sor. NĂ«se kemi shkruar diçka nĂ« njĂ« sektor prej 4 kilobyte, ka shumĂ« tĂ« ngjarĂ« qĂ« gjatĂ« dy po minutave tĂ« ardhshme do tĂ« bĂ«het njĂ« shkrim nĂ« kĂ«tĂ« sektor ose nĂ« njĂ« nga fqinjtĂ« (+- 32K).

Duke vendosur pragun e migrimit në zero, ne çojmë vonesën e sinkronizimit të shkrimit në SATA SSD dhe grumbullojmë disa ndryshime të një blloku 64K në cache. Kështu ruhet ndjeshëm burimi i SATA SSD.

Po ku Ă«shtĂ« kodi..?FatkeqĂ«sisht, autori e konsideron veten jo tĂ« mjaftueshĂ«m kompetent pĂ«r zhvillimin e skenarĂ«ve bash, pasi Ă«shtĂ« 100% vetĂ«-mĂ«suar dhe praktikon zhvillimin e drejtuar nga ‘google’, kĂ«shtu qĂ« mendon se ai kod i tmerrshĂ«m qĂ« del nga duart e tij, mĂ« mirĂ« tĂ« mos pĂ«rdoret nga askush tjetĂ«r.

Mendoj se profesionistët do të jenë në gjendje të krijojnë logjikën e përshkruar më lart nëse nevojitet dhe, ndoshta, madje ta paraqesin bukur në formën e një shërbimi systemd, ashtu siç përpiqej të bënte autori.

Një skemë e tillë e thjeshtë e rotacionit të snapshot-ëve do të na lejojë të kemi gjithmonë një snapshot të plotë të sinkronizuar në SATA SSD, si dhe do të na lejojë me ndihmën e utilitarit thin_delta të kuptojmë cilat blloqe janë ndryshuar pas krijimit të tij, duke lokalizuar kështu dëmtimet në volumet kryesore, duke e bërë shumë më të lehtë rikuperimin.

TRIM/DISCARD në libvirt/KVM

Duke qenë se depoja e të dhënave do të përdoret për KVM nën menaxhimin e libvirt, do të ishte mirë të mësonim VM-të tona të mos vetëm të zënë hapësirën e lirë, por edhe të lirojnë atë që tashmë nuk është më e nevojshme.

Kjo bëhet përmes simulimit të mbështetjes TRIM/DISCARD në disqet virtuale. Për këtë, duhet të ndryshoni tipin e kontrollorit në virtio-scsi dhe të redaktoni 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'/>


</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>


</controller>

DISCARD-ët e tillë nga sistemet operative të mysafirëve përpunohen saktë nga LVM, dhe blloqet lirohen saktë si në cache, ashtu edhe në rezervuarin e hollë. Në rastin tonë, kjo ndodh kryesisht vonë, gjatë fshirjes së një snapshot-i.

Kopjimi i BTRFS

Përdorimi i skripteve të gatshme me ekstrem kujdes dhe në rrezikun tuaj. Autori e shkroi këtë kod vetë dhe ekskluzivisht për veten e tij. Jam i sigurt se shumë përdorues të avancuar të Linux kanë kosto të ngjashme në punimet e tyre, dhe nuk është e nevojshme të kopjoni të tjera.

Le të krijojmë një vëllim në pajisjen e rezervës:

#lvcreate -L 256G --name backup backup

Formatojeni në BTRFS:

#mkfs.btrfs /dev/backup/backup

Krijoni pikat e montimit dhe montoni nëndivizionet e sistemit të skedarëve:

#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

Krijoni katalogët për kopjimet:

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

Krijoni një katalog për skriptet e kopjimit:

#mkdir /root/btrfs-backup

Kopjoni skriptin:

Më shumë kod bash shqetësues. Përdoreni në rrezik tuaj. Mos dërgoni letra të zemëruara autorit...#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 "Duke pritur për bllokimin..."
wait_lock || terminate "Dështoi të merrte bllokimin. Po del..."
echo "Mori bllokimin..."
}

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 e gjetur"
else
echo "$SOURCE_BASE_PATH File nuk u gjet, duke krijuar snapshot të $SOURCE_PATH në $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ]
then
echo "$TARGET_BASE_PATH e gjetur jashtë sinkronizimit me burimin... duke e hequr..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ]
then
echo "$TARGET_BASE_PATH e gjetur"
else
echo "$TARGET_BASE_PATH nuk u gjet. Po sinkronizohet në $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 e gjetur duke u hequr..."
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 e gjetur duke u hequr..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Duke dërguar $SOURCE_PEND_PATH në $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")"
ndërsa lexon -r SNAPSHOT; bëj
heq "$1" "$SNAPSHOT"
bërë < <(list "$1" | grep "$FILTER")

}

(
URDHRI="$1"
zhvendosje

rast "$URDHRI" në
"--help")
echo "Ndihmë"
;;
"sufiks")
sufiks
;;
"filter")
filtroni "$1"
;;
"backup")
prisni_lock_ose_terminoni
kopjoni "$1"
;;
"list")
list "$1"
;;
"heq")
prisni_lock_ose_terminoni
heq "$1" "$2"
;;
"heqalle")
prisni_lock_ose_terminoni
heqalle "$1" "$2"
;;
*)
echo "Asnjë.."
;;
esac
) 98>$LOCK_FILE

EOF

ÇfarĂ« bĂ«n kjo..?PĂ«rmban njĂ« grup komandash tĂ« thjeshta pĂ«r tĂ« krijuar snapshot BTRFS dhe pĂ«r t'i kopjuar ato nĂ« njĂ« sistem tjetĂ«r pĂ«rmes BTRFS dĂ«rgo/nxjerr.

Starti i parë mund të jetë relativisht i gjatë, pasi të gjitha të dhënat do të kopjohen në fillim. Fillimet e mëvonshme do të jenë shumë të shpejta, pasi do të kopjohen vetëm ndryshimet.

Një skenar tjetër që do ta fusim në cron:

Pak më shumë kod 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 ditë"
$BACKUP_SCRIPT kopjoni root/@
$BACKUP_SCRIPT heqalle root/@ "$RETENTION"
$BACKUP_SCRIPT kopjoni root/@home
$BACKUP_SCRIPT heqalle root/@home "$RETENTION"
$BACKUP_SCRIPT kopjoni boot/
$BACKUP_SCRIPT heqalle boot/ "$RETENTION"
EOF

ÇfarĂ« bĂ«n ajo..?Krijon dhe sinkronizon nĂ« sistemin e rezervĂ«s snapshot incremental tĂ« volumeve tĂ« listuara BTRFS. Pas kĂ«saj, fshin tĂ« gjitha snapshotet e krijuara 60 ditĂ« mĂ« parĂ«. Pas ekzekutimit, nĂ« nĂ«nkatalogĂ«t /backup/btrfs/back/remote/ do tĂ« shfaqen snapshotet e datuara tĂ« volumeve tĂ« listuara.

Të japim kodit të drejta për ekzekutim:

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

Të kontrollojmë dhe ta fusim në 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

Kopjimi rezervë LVM thin

Krijojmë një rezervuar të hollë në pajisjen e rezervës:

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

Instaloni ddrescue, pasi skenaret do të përdorin këtë mjet:

#apt-get install gddrescue

Krijojmë një katalog për skenaret:

#mkdir /root/lvm-thin-backup

Kopjojmë skenaret:

Shumë shumë bash brenda...#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 "Duke pritur për bllokimin..."
wait_lock || terminate "Dështoi të merrte bllokimin. Po del..."
echo "Mori bllokimin..."
}

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"
}

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

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

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

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

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

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

funksioni aktivizo_volume {
lvchange -ay -Ky "$1/$2"
}

funksioni deaktivo_volume {
lvchange -an "$1/$2"
}

funksioni lexoni_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

funksioni 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)

nëse [ "$DIFF_SOURCE_POOL" == "" ]
then
(>&2 echo "LV burimi nuk është i hollë.")
exit 1
fi

nëse [ "$DIFF_TARGET_POOL" == "" ]
then
(>&2 echo "LV qëllimi nuk është i hollë.")
exit 1
fi

nëse [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ]
then
(>&2 echo "LV burim dhe LV qëllimi i përkasin rezervuareve të ndryshme të holla.")
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)

nëse [ "$DIFF_POOL_METADATA_SNAP" != "-" ]
then
(>&2 echo "Snapshot-i i metadata e rezervuarit të hollë tashmë ekziston. Supozojmë një të vjetër. Do të lirojmë snapshot-in e metadata në 5 sekonda.")
flini 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)

nëse [ "$DIFF_POOL_METADATA_SNAP" == "-" ]
then
(>&2 echo "Dështoi për të krijuar snapshot-in e metadata të rezervuarit të hollë.")
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 'ndryshe|vetem_ndjek|vetem_drejt' | sed 's/<|"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/ndryshe/copje/g' | sed 's/vetem_ndjek/copje/g' | sed 's/vetem_drejt/hidh/g'

}

funksioni 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)

aktivizo_volume $SYNC_VG $SYNC_PEND

ndërsa lexon -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; bëj
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
nëse [ "$SYNC_ACTION" == "copje" ]
then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

nëse [ "$SYNC_ACTION" == "hidh" ]
then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
bëj < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

funksioni discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
nëse [ "$DISCARD_LV_PATH" != "" ]
then
echo "$DISCARD_LV_PATH u gjet"
else
echo "$DISCARD_LV nuk u gjet në $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" || dil 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || dil 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")

nëse [ "$SOURCE_BASE_LV_PATH" != "" ]
then
echo "$SOURCE_BASE_LV_PATH u gjet"
else
echo "Baza e burimit nuk u gjet, duke krijuar një snapshot të $SOURCE_VG/$SOURCE_LV në $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || dil 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
aktivizo_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Duke hedhur $SOURCE_BASE_LV_PATH pasi na nevojitet të 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
nëse [ "$TARGET_BASE_LV_PATH" != "" ]
then
echo "$TARGET_BASE_LV_PATH u gjet jashtë sync me burimin... po heq..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || dil 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")
nëse [ "$TARGET_BASE_LV_PATH" != "" ]
then
echo "$TARGET_BASE_LV_PATH u gjet"
else
echo "$TARGET_VG/$TARGET_LV nuk u gjet. Duke krijuar një volum të zbrazët."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || dil 1
echo "Duhet të ri-bootstrap. Duke hedhur burimin në $SOURCE_BASE_LV_PATH"
aktivizo_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 "Duke hedhur targetin në $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
nëse [ "$SOURCE_PEND_LV_PATH" != "" ]
then
echo "$SOURCE_PEND_LV_PATH u gjet po heq..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || dil 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || dil 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
nëse [ "$TARGET_PEND_LV_PATH" != "" ]
then
echo "$TARGET_PEND_LV_PATH u gjet po heq..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || dil 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"
aktivizo_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Duke sinkronizuar $SOURCE_PEND_LV_PATH me $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || dil 1
sync

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

funksioni verifiko()
{
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")

nëse [ "$SOURCE_BASE_LV_PATH" != "" ]
then
echo "$SOURCE_BASE_LV_PATH u gjet"
else
echo "$SOURCE_BASE_LV_PATH nuk u gjet"
exit 1
fi
nëse [ "$TARGET_BASE_LV_PATH" != "" ]
then
echo "$TARGET_BASE_LV_PATH u gjet"
else
echo "$TARGET_BASE_LV_PATH nuk u gjet"
exit 1
fi
aktivizo_volume "$TARGET_VG" "$TARGET_BASE_LV"
aktivizo_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Krahasimi "$SOURCE_BASE_LV_PATH" me "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deaktivizo_volume "$TARGET_VG" "$TARGET_BASE_LV"
deaktivizo_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")

nëse [ "$SOURCE_BASE_LV_PATH" != "" ]
then
echo "$SOURCE_BASE_LV_PATH u gjet"
else
echo "$SOURCE_BASE_LV_PATH nuk u gjet"
exit 1
fi
nëse [ "$TARGET_BASE_LV_PATH" != "" ]
then
echo "$TARGET_BASE_LV_PATH u gjet"
else
echo "$TARGET_BASE_LV_PATH nuk u gjet"
exit 1
fi
aktivizo_volume "$TARGET_VG" "$TARGET_BASE_LV"
aktivizo_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...
deaktivizo_volume "$TARGET_VG" "$TARGET_BASE_LV"
deaktivizo_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")"
ndërsa lexon -r SNAPSHOT; bëj
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
URDHRI="$1"
zhvendosje

rast "$URDHRI" në
"--help")
echo "Ndihmë"
;;
"sufiks")
sufiks
;;
"filter")
filtroni "$1"
;;
"backup")
prisni_lock_ose_terminoni
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
prisni_lock_ose_terminoni
verify "$1" "$2"
;;
"resync")
prisni_lock_ose_terminoni
resync "$1" "$2"
;;
"heq")
prisni_lock_ose_terminoni
remove "$1"
;;
"heqalle")
prisni_lock_ose_terminoni
removeall "$1" "$2" "$3"
;;
*)
echo "Asnjë.."
;;
esac
) 98>$LOCK_FILE

EOF

ÇfarĂ« bĂ«n
?PĂ«rmban njĂ« set komandash pĂ«r manipulimin e snapshot-eve tĂ« hollĂ« dhe sinkronizimin e diferencĂ«s midis dy snapshot-Ă«ve tĂ« hollĂ«, tĂ« marrĂ« nĂ«pĂ«rmjet thin_delta, nĂ« njĂ« pajisje tĂ« tjera blloku duke pĂ«rdorur ddrescue dhe blkdiscard.

Një skript tjetër, që do ta vendosim në cron:

Pak më shumë 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 ditë"

$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

ÇfarĂ« bĂ«n
?PĂ«rdor skriptin e mĂ«parshĂ«m pĂ«r tĂ« krijuar dhe sinkronizuar kopje rezervĂ« tĂ« volumĂ«ve tĂ« hollĂ« tĂ« pĂ«rmendur. Skripti do tĂ« lĂ«rĂ« snapshot-et inaktive tĂ« volumĂ«ve tĂ« pĂ«rmendura, tĂ« cilat janĂ« tĂ« nevojshme pĂ«r tĂ« ndjekur ndryshimet nga sinkronizimi i fundit.

Ky skript duhet të redaktohet, duke treguar listën e volumëve të hollë për të cilët kërkohen kopje rezervë. Emrat e dhënë janë vetëm për shembuj. Nëse dëshironi, mund të shkruani një skript që do të sinkronizojë të gjithë volumët.

Të japim të drejtat:

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

Të kontrollojmë dhe ta fusim në 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

E para herë do të zgjasë gjatë, sepse volumet e hollë do të sinkronizohen plotësisht duke kopjuar të gjithë hapësirën e përdorur. Falë meta të dhënave të LVM thin, ne dimë se cilat blloqe janë përdorur në të vërtetë, kështu që do të kopjohen vetëm blloqet e përdorura realisht të volumëve të hollë.

Herët e ardhshme do të kopjojnë të dhënat në mënyrë incrementale falë ndjekjes së ndryshimeve përmes meta të dhënave të LVM thin.

Le të shohim se çfarë dolën;

#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 mar 26 09:11 .
drwxr-xr-x 1 root root 16 mar 6 09:30 ..
drwxr-xr-x 1 root root 322 mar 26 02:00 .@base
drwxr-xr-x 1 root root 516 mar 6 09:39 .@snap.2020-03-06-09-39-37
drwxr-xr-x 1 root root 516 mar 6 09:39 .@snap.2020-03-06-09-39-57
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 mar 26 09:11 .
drwxr-xr-x 1 root root 16 mar 6 09:30 ..
drwxr-xr-x 1 root root 240 mar 26 09:11 @.@base
drwxr-xr-x 1 root root 22 mar 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 mar 6 09:39 @home.@snap.2020-03-06-09-39-35
drwxr-xr-x 1 root root 22 mar 6 09:39 @home.@snap.2020-03-06-09-39-57
...
drwxr-xr-x 1 root root 240 mar 6 09:39 @.@snap.2020-03-06-09-39-26
drwxr-xr-x 1 root root 240 mar 6 09:39 @.@snap.2020-03-06-09-39-56
...

#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

Cila është lidhja me matreshkët?

Së bashku me LVM, volumet logjike LV mund të jenë volumet fizike LVM PV për VG të tjera. LVM mund të jetë rekurziv, si matreshkat. Kjo i jep LVM një fleksibilitet të jashtëzakonshëm.

P.S.

Në artikullin e ardhshëm do të përpiqemi të përdorim disa të ngjashme me mobil Storage/KVM si bazë për krijimin e një klasteri vm-geo-distribuar me kopje rezervë në disa kontinente përmes desktopëve shtëpiakë, internetit shtëpiak dhe rrjeteve P2P.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster