ProHoster > Blogs > Administrācija > Kas kopīgs LVM un MatrjoŔkai?

Kas kopīgs LVM un MatrjoŔkai?

Laba diena.
Vēlos dalÄ«ties ar sabiedrÄ«bu ar savu praktisko pieredzi, veidojot datu glabāŔanas sistēmu KVM, izmantojot md RAID + LVM.

Programma ietvers:

  • Md RAID 1 izveide no NVMe SSD.
  • Md RAID 6 salikÅ”ana no SATA SSD un parastajiem diskdziņiem.
  • TRIM/DISCARD darbÄ«bas iezÄ«mes SSD RAID 1/6.
  • Sāknējama md RAID 1/6 masÄ«va izveide kopējā disku komplektā.
  • Sistēmas instalÄ“Å”ana uz NVMe RAID 1, ja BIOS nav NVMe atbalsta.
  • Izmantojot LVM keÅ”atmiņu un LVM thin.
  • BTRFS momentuzņēmumu izmantoÅ”ana un nosÅ«tÄ«Å”ana/saņemÅ”ana dublÄ“Å”anai.
  • LVM plānu momentuzņēmumu un thin_delta izmantoÅ”ana BTRFS stila dublÄ“Å”anai.

Ja jūs interesē, lūdzu, skatiet kaķi.

Paziņojums

Autors neuzņemas nekādu atbildÄ«bu par sekām, kas izriet no Ŕī raksta materiālu/piemēru/koda/padomu/datu izmantoÅ”anas vai neizmantoÅ”anas. Izlasot vai jebkādā veidā izmantojot Å”o materiālu, jÅ«s uzņematies atbildÄ«bu par visām Å”o darbÄ«bu sekām. Iespējamās sekas ir Ŕādas:

  • KraukŔķīgi cepti NVMe SSD.
  • PilnÄ«bā iztērēts ierakstÄ«Å”anas resurss un SSD disku kļūme.
  • PilnÄ«ga visu datu zudums visos diskos, ieskaitot rezerves kopijas.
  • Bojāta datora aparatÅ«ra.
  • Iztērēts laiks, nervi un nauda.
  • Visas citas sekas, kas nav uzskaitÄ«tas iepriekÅ”.

dzelzs

Pieejami bija:

Apmēram 2013. gada mātesplate ar Z87 mikroshēmojumu, komplektā ar Intel Core i7 / Haswell.

  • Procesors 4 kodoli, 8 pavedieni
  • 32 GB DDR3 RAM
  • 1 x 16 vai 2 x 8 PCIe 3.0
  • 1 x 4 + 1 x 1 PCIe 2.0
  • 6 x 6 GBps SATA 3 savienotāji

SAS adapteris LSI SAS9211-8I pārslēdzās uz IT / HBA režīmu. Ar RAID iespējota programmaparatūra ir apzināti aizstāta ar HBA programmaparatūru, lai:

  1. Jūs jebkurā laikā varat izmest Ŕo adapteri un aizstāt to ar jebkuru citu, ar kuru esat saskāries.
  2. TRIM/Discard uz diskiem strādāja normāli, jo... RAID programmaparatūrā Ŕīs komandas vispār netiek atbalstītas, un HBA kopumā ir vienalga, kādas komandas tiek pārsūtītas pa kopni.

Cietie diski - 8 gabali HGST Travelstar 7K1000 ar ietilpÄ«bu 1 TB ar 2.5 formas koeficientu, tāpat kā klēpjdatoriem. Å ie diskdziņi iepriekÅ” bija RAID 6 masÄ«vā. Tie bÅ«s noderÄ«gi arÄ« jaunajā sistēmā. Vietējo dublējumkopiju glabāŔanai.

Papildus pievienots:

6 gab SATA SSD modelis Samsung 860 QVO 2TB. Å iem SSD bija nepiecieÅ”ams liels apjoms, SLC keÅ”atmiņa, uzticamÄ«ba un zema cena. Bija nepiecieÅ”ams atmest/nulles atbalsts, ko pārbauda dmesg rinda:

kernel: ata1.00: Enabling discard_zeroes_data

2 gabali NVMe SSD modeļa Samsung SSD 970 EVO 500GB.

Å iem SSD ir svarÄ«gs nejauÅ”s lasÄ«Å”anas/rakstÄ«Å”anas ātrums un resursu ietilpÄ«ba jÅ«su vajadzÄ«bām. Radiators viņiem. Obligāti. PilnÄ«gi noteikti. Pretējā gadÄ«jumā pirmās RAID sinhronizācijas laikā apcepiet tos, lÄ«dz tie kļūst kraukŔķīgi.

StarTech PEX8M2E2 adapteris 2 x NVMe SSD, kas instalēts PCIe 3.0 8x slotā. Tas atkal ir tikai HBA, bet paredzēts NVMe. Tas atŔķiras no lētiem adapteriem ar to, ka tam nav nepiecieÅ”ams PCIe bifurkācijas atbalsts no mātesplates, jo tajā ir iebÅ«vēts PCIe slēdzis. Tas darbosies pat senākajā sistēmā ar PCIe, pat ja tas ir x1 PCIe 1.0 slots. Protams, atbilstoŔā ātrumā. Tur nav RAID. Uz kuÄ£a nav iebÅ«vēta BIOS. Tātad, pateicoties Å”ai ierÄ«cei, jÅ«su sistēma maÄ£iski neiemācÄ«sies sāknēties ar NVMe, vēl jo mazāk ā€” NVMe RAID.

Šis komponents radās tikai tāpēc, ka sistēmā bija tikai viens bezmaksas 8x PCIe 3.0, un, ja ir 2 brīvi sloti, to var viegli nomainīt ar diviem pensiem PEX4M2E1 vai analogiem, kurus var iegādāties jebkurā vietā par cenu 600. rubļi.

Visa veida aparatÅ«ras vai iebÅ«vēto mikroshēmojumu/BIOS RAID noraidÄ«Å”ana tika veikta apzināti, lai varētu pilnÄ«bā nomainÄ«t visu sistēmu, izņemot paÅ”u SSD/HDD, saglabājot visus datus. Ideāli, lai, pārejot uz pilnÄ«gi jaunu/citu aparatÅ«ru, varētu saglabāt pat instalēto operētājsistēmu. Galvenais, ka ir SATA un PCIe porti. Tas ir kā dzÄ«vs CD vai sāknējams zibatmiņas disks, tikai ļoti ātrs un nedaudz apjomÄ«gs.

Š®Š¼Š¾Ń€Pretējā gadÄ«jumā jÅ«s zināt, kas notiek - dažreiz jums steidzami jāpaņem lÄ«dzi viss masÄ«vs, lai to aizvestu. Bet es nevēlos zaudēt datus. Lai to izdarÄ«tu, visi minētie datu nesēji ir ērti izvietoti uz priekÅ”metstikliņiem standarta korpusa 5.25 nodalÄ«jumos.

Nu, un, protams, eksperimentÄ“Å”anai ar dažādām SSD keÅ”atmiņas metodēm Linux.

Aparatūras reidi ir garlaicīgi. Ieslēdziet to. Tas vai nu strādā, vai ne. Un ar mdadm vienmēr ir iespējas.

Programmatūra

IepriekÅ” Debian 8 Jessie tika instalēta aparatÅ«rā, kas ir tuvu EOL. RAID 6 tika samontēts no iepriekÅ” minētajiem HDD, kas savienoti pārÄ« ar LVM. Tas palaida virtuālās maŔīnas kvm/libvirt.

Jo Autoram ir piemērota pieredze portatÄ«vo bootable SATA/NVMe zibatmiņu veidoÅ”anā, kā arÄ«, lai nesalauztu ierasto trāpÄ«go veidni, par mērÄ·a sistēmu tika izvēlēta Ubuntu 18.04, kas jau ir pietiekami nostabilizējusies, bet tai joprojām ir 3 gadi. atbalstu nākotnē.

Minētajā sistēmā ir visi nepiecieÅ”amie aparatÅ«ras draiveri. Mums nav nepiecieÅ”ama treŔās puses programmatÅ«ra vai draiveri.

SagatavoŔana uzstādīŔanai

Lai instalētu sistēmu, mums ir nepiecieÅ”ams Ubuntu darbvirsmas attēls. Serveru sistēmai ir sava veida enerÄ£isks instalētājs, kas parāda pārmērÄ«gu neatkarÄ«bu, ko nevar atspējot, iegrūžot UEFI sistēmas nodalÄ«jumu vienā no diskiem, sabojājot visu skaistumu. AttiecÄ«gi tas ir instalēts tikai UEFI režīmā. Nepiedāvā nekādas iespējas.

Mēs ar to neesam apmierināti.

Kāpēc?Diemžēl UEFI sāknÄ“Å”ana ir ārkārtÄ«gi slikti saderÄ«ga ar sāknÄ“Å”anas programmatÅ«ras RAID, jo... Neviens mums nepiedāvā UEFI ESP nodalÄ«juma rezervācijas. TieÅ”saistē ir receptes, kas iesaka ievietot ESP nodalÄ«jumu zibatmiņas diskā USB portā, taču tas ir neveiksmes punkts. Ir receptes, kurās tiek izmantota programmatÅ«ra mdadm RAID 1 ar metadatu versiju 0.9, kas neliedz UEFI BIOS redzēt Å”o nodalÄ«jumu, bet tas dzÄ«vo lÄ«dz laimÄ«gajam brÄ«dim, kad BIOS vai cita aparatÅ«ras operētājsistēma kaut ko ieraksta ESP un aizmirst to sinhronizēt ar citu. spoguļi.

Turklāt UEFI sāknÄ“Å”ana ir atkarÄ«ga no NVRAM, kas nepārvietosies kopā ar diskiem uz jauno sistēmu, jo ir daļa no mātesplates.

Tātad, mēs neizgudrosim jaunu riteni. Mums jau ir gatavs, laika pārbaudÄ«ts vectēva velosipēds, ko tagad sauc par Legacy/BIOS boot un kas nes lepno nosaukumu CSM uz UEFI saderÄ«gām sistēmām. Mēs to vienkārÅ”i noņemsim no plaukta, eļļosim, uzpumpēsim riepas un noslaukÄ«sim ar mitru drānu.

ArÄ« Ubuntu darbvirsmas versiju nevar pareizi instalēt ar Legacy bootloader, taču Å”eit, kā saka, vismaz ir iespējas.

Mēs savācam aparatÅ«ru un ielādējam sistēmu no Ubuntu Live sāknējamā zibatmiņas diska. Mums bÅ«s jālejupielādē pakotnes, tāpēc mēs iestatÄ«sim jums piemērotu tÄ«klu. Ja tas nedarbojas, varat iepriekÅ” ielādēt nepiecieÅ”amās pakotnes zibatmiņas diskā.

Mēs pārejam uz darbvirsmas vidi, palaižam termināļa emulatoru un dodamies tālāk:

#sudo bash

Kāā€¦?IepriekÅ” redzamā rindiņa ir kanoniskais sudo holiwars aktivizētājs. C bŠ¾nāk lielākas iespējas unŠ¾lielāka atbildÄ«ba. Jautājums ir, vai jÅ«s varat to uzņemties pats. Daudzi cilvēki domā, ka sudo lietoÅ”ana Ŕādā veidā vismaz nav piesardzÄ«ga. Tomēr:

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

Kāpēc ne ZFS...?Instalējot programmatÅ«ru savā datorā, mēs bÅ«tÄ«bā aizdodam savu aparatÅ«ru Ŕīs programmatÅ«ras izstrādātājiem, lai tie vadÄ«tu.
Uzticot Å”ai programmatÅ«rai savu datu droŔību, mēs ņemam aizdevumu, kas ir vienāds ar Å”o datu atjaunoÅ”anas izmaksām, kas mums kādreiz bÅ«s jāatmaksā.

No Ŕī viedokļa ZFS ir Ferrari, un mdadm+lvm vairāk atgādina velosipēdu.

SubjektÄ«vi autors dod priekÅ”roku nepazÄ«stamām personām uz kredÄ«ta aizdot velosipēdu, nevis Ferrari. Tur emisijas cena nav augsta. Nav vajadzÄ«gas tiesÄ«bas. VienkārŔāk nekā satiksmes noteikumi. Autostāvvieta ir bezmaksas. Krosa spējas ir labākas. Velosipēdam vienmēr var piestiprināt kājas, un velosipēdu var salabot ar savām rokām.

Kāpēc tad BTRFS...?Lai palaistu operētājsistēmu, mums ir nepiecieÅ”ama failu sistēma, kas jau sākotnēji tiek atbalstÄ«ta Legacy/BIOS GRUB, un tajā paŔā laikā tiek atbalstÄ«ti tieÅ”raides momentuzņēmumi. Mēs to izmantosim /boot nodalÄ«jumam. Turklāt autors izvēlas izmantot Å”o FS for / (root), neaizmirstot atzÄ«mēt, ka jebkurai citai programmatÅ«rai LVM var izveidot atseviŔķus nodalÄ«jumus un uzstādÄ«t tos nepiecieÅ”amajos direktorijos.

Mēs Å”ajā FS neuzglabāsim nekādus virtuālo maŔīnu vai datu bāzu attēlus.
Å is FS tiks izmantots tikai, lai izveidotu sistēmas momentuzņēmumus, to neizslēdzot, un pēc tam pārsÅ«tÄ«tu Å”os momentuzņēmumus uz rezerves disku, izmantojot sÅ«tÄ«t/saņemt.

Turklāt autors parasti dod priekÅ”roku programmatÅ«ras minimumam tieÅ”i aparatÅ«rā un visu pārējo programmatÅ«ru palaist virtuālajās maŔīnās, izmantojot tādas lietas kā GPU un PCI-USB resursdatora kontrolleru pārsÅ«tÄ«Å”ana uz KVM, izmantojot IOMMU.

VienÄ«gais, kas paliek aparatÅ«rā, ir datu glabāŔana, virtualizācija un dublÄ“Å”ana.

Ja vairāk uzticaties ZFS, tad principā norādītajai lietojumprogrammai tie ir savstarpēji aizstājami.

Tomēr autors apzināti ignorē iebÅ«vētās spoguļoÅ”anas/RAID un dublÄ“Å”anas funkcijas, kas ir ZFS, BRTFS un LVM.

Kā papildu arguments BTRFS ir iespēja nejauÅ”us ierakstus pārvērst par secÄ«giem, kas ārkārtÄ«gi pozitÄ«vi ietekmē momentuzņēmumu/dublējumu sinhronizācijas ātrumu HDD.

Atkārtoti skenēsim visas ierīces:

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

Paskatīsimies apkārt:

#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

Diska izkārtojums

NVMe SSD

Bet mēs tos nekādā veidā neatzÄ«mēsim. Tomēr mÅ«su BIOS neredz Å”os diskus. Tātad viņi pilnÄ«bā pāries uz programmatÅ«ras RAID. Mēs tur pat neveidosim sadaļas. Ja vēlaties ievērot ā€œkanonuā€ vai ā€œprincipāā€, izveidojiet vienu lielu nodalÄ«jumu, piemēram, HDD.

SATA HDD

Å eit nekas Ä«paÅ”s nav jāizdomā. Mēs izveidosim vienu sadaļu visam. Mēs izveidosim nodalÄ«jumu, jo BIOS redz Å”os diskus un var pat mēģināt no tiem palaist. Mēs pat vēlāk instalēsim GRUB Å”ajos diskos, lai sistēma pēkŔņi varētu to izdarÄ«t.

#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

Šeit lietas mums kļūst interesantas.

Pirmkārt, mÅ«su diskdziņi ir 2 TB lieli. Tas ir MBR pieņemamā diapazonā, ko mēs izmantosim. Ja nepiecieÅ”ams, var aizstāt ar GPT. GPT diskiem ir saderÄ«bas slānis, kas ļauj ar MBR saderÄ«gām sistēmām redzēt pirmos 4 nodalÄ«jumus, ja tie atrodas pirmajos 2 terabaitos. Galvenais, lai sāknÄ“Å”anas nodalÄ«jums un bios_grub nodalÄ«jums Å”ajos diskos bÅ«tu sākumā. Tas pat ļauj palaist no GPT Legacy/BIOS diskdziņiem.

Bet tas nav mūsu gadījums.

Å eit mēs izveidosim divas sadaļas. Pirmais bÅ«s 1 GB liels un tiks izmantots RAID 1 / sāknÄ“Å”ana.

Otrais tiks izmantots RAID 6 un aizņems visu atlikuÅ”o brÄ«vo vietu, izņemot nelielu nepieŔķirtu laukumu diska beigās.

Kas ir Ŕī neatzÄ«mētā zona?Saskaņā ar avotiem tÄ«klā, mÅ«su SATA SSD ir dinamiski paplaÅ”ināma SLC keÅ”atmiņa, kuras izmērs ir no 6 lÄ«dz 78 gigabaitiem. Mēs saņemam 6 gigabaitus ā€œbez maksasā€, pateicoties atŔķirÄ«bai starp ā€œgigabaitiemā€ un ā€œgibibaitiemā€ diska datu lapā. AtlikuÅ”ie 72 gigabaiti tiek atvēlēti no neizmantotās vietas.

Å eit jāatzÄ«mē, ka mums ir SLC keÅ”atmiņa, un vieta tiek aizņemta 4 bitu MLC režīmā. Kas mums faktiski nozÄ«mē, ka uz katriem 4 gigabaitiem brÄ«vas vietas mēs iegÅ«sim tikai 1 gigabaitu SLC keÅ”atmiņas.

Reiziniet 72 gigabaitus ar 4 un iegÅ«stiet 288 gigabaitus. Å Ä« ir brÄ«vā vieta, kuru mēs neatzÄ«mēsim, lai diskdziņi varētu pilnÄ«bā izmantot SLC keÅ”atmiņu.

Tādējādi mēs efektÄ«vi iegÅ«sim lÄ«dz 312 gigabaitiem SLC keÅ”atmiņas no kopumā seÅ”iem diskdziņiem. No visiem diskdziņiem 2 tiks izmantoti RAID dublÄ“Å”anai.

Šāds keÅ”atmiņas apjoms ļaus mums ļoti reti reālajā dzÄ«vē sastapties ar situāciju, kad ieraksts nenonāk keÅ”atmiņā. Tas ārkārtÄ«gi labi kompensē visbēdÄ«gāko QLC atmiņas trÅ«kumu ā€“ ārkārtÄ«gi zemo rakstÄ«Å”anas ātrumu, kad dati tiek rakstÄ«ti, apejot keÅ”atmiņu. Ja jÅ«su slodzes tam neatbilst, tad iesaku rÅ«pÄ«gi padomāt, cik ilgi jÅ«su SSD izturēs pie Ŕādas slodzes, ņemot vērā TBW no datu lapas.

#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

Masīvu izveide

Pirmkārt, mums ir jāpārdēvē maŔīna. Tas ir nepiecieÅ”ams, jo resursdatora nosaukums ir daļa no masÄ«va nosaukuma kaut kur iekŔā mdadm un kaut kur kaut ko ietekmē. Protams, masÄ«vus vēlāk var pārdēvēt, taču tas ir lieks solis.

#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

Kāpēc -pieņemt-tÄ«ru...?Lai izvairÄ«tos no masÄ«vu inicializācijas. Tas attiecas gan uz RAID 1., gan 6. lÄ«meni. Viss var darboties bez inicializācijas, ja tas ir jauns masÄ«vs. Turklāt SSD masÄ«va inicializācija pēc izveides ir TBW resursu izŔķērdÄ“Å”ana. Mēs izmantojam TRIM/DISCARD, kur iespējams, samontētajiem SSD masÄ«viem, lai tos ā€œinicializētuā€.

SSD masīviem RAID 1 DISCARD tiek atbalstīts jau no komplektācijas.

SSD RAID 6 DISCARD masīviem tas ir jāiespējo kodola moduļa parametros.

Tas jādara tikai tad, ja visiem SSD, kas tiek izmantoti 4./5./6. lÄ«meņa masÄ«vos Å”ajā sistēmā, ir pieejams discard_zeroes_data atbalsts. Dažreiz jÅ«s saskaraties ar dÄ«vainiem diskdziņiem, kas norāda kodolam, ka Ŕī funkcija tiek atbalstÄ«ta, bet patiesÄ«bā tās nav, vai arÄ« funkcija ne vienmēr darbojas. PaÅ”laik atbalsts ir pieejams gandrÄ«z visur, tomēr ir veci diskdziņi un programmaparatÅ«ra ar kļūdām. Å Ä« iemesla dēļ RAID 6 pēc noklusējuma ir atspējots atbalsts DISCARD.

UzmanÄ«bu, Ŕī komanda iznÄ«cinās visus datus par NVMe diskdziņiem, ā€œinicializējotā€ masÄ«vu ar ā€œnullesā€.

#blkdiscard /dev/md0

Ja kaut kas noiet greizi, mēģiniet norādīt darbību.

#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

Kāpēc tik liels...?Daļas lieluma palielināŔana pozitÄ«vi ietekmē nejauÅ”as nolasÄ«Å”anas ātrumu blokos lÄ«dz pat gabala izmēram ieskaitot. Tas notiek tāpēc, ka vienu atbilstoÅ”a izmēra vai mazāku darbÄ«bu var pilnÄ«bā veikt vienā ierÄ«cē. Tāpēc IOPS no visām ierÄ«cēm tiek summēts. Saskaņā ar statistiku, 99% IO nepārsniedz 512K.

RAID 6 IOPS rakstÄ«Å”anai vienmēr mazāks vai vienāds ar viena diska IOPS. Ja, nejauÅ”i lasot, IOPS var bÅ«t vairākas reizes lielāks nekā viena diska, un Å”eit bloka lielumam ir galvenā nozÄ«me.
Autors neredz jēgu mēģināt optimizēt parametru, kas ir slikts RAID 6 dizainā, un tā vietā optimizē to, kas RAID 6 ir labs.
Mēs kompensēsim slikto RAID 6 nejauÅ”o rakstÄ«Å”anu ar NVMe keÅ”atmiņu un plānas nodroÅ”ināŔanas trikiem.

Mēs vēl neesam iespējojuÅ”i DISCARD RAID 6. Tāpēc mēs pagaidām "neinicializēsim" Å”o masÄ«vu. Mēs to darÄ«sim vēlāk, pēc OS instalÄ“Å”anas.

SATA HDD

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

LVM uz NVMe RAID

Ātruma labad mēs vēlamies ievietot saknes failu sistēmu NVMe RAID 1, kas ir /dev/md0.
Tomēr Å”is ātrais masÄ«vs mums joprojām bÅ«s vajadzÄ«gs citām vajadzÄ«bām, piemēram, mijmaiņas, metadatu un LVM keÅ”atmiņas un LVM plāna metadatu vajadzÄ«bām, tāpēc mēs izveidosim LVM VG Å”ajā masÄ«vā.

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

Izveidosim nodalījumu saknes failu sistēmai.

#lvcreate -L 128G --name root root

Izveidosim nodalÄ«jumu maiņai atbilstoÅ”i RAM izmēram.

#lvcreate -L 32G --name swap root

OS instalēŔana

Kopumā mums ir viss nepiecieÅ”amais sistēmas uzstādÄ«Å”anai.

Palaidiet sistēmas instalÄ“Å”anas vedni no Ubuntu Live vides. Parasta uzstādÄ«Å”ana. Tikai instalÄ“Å”anas disku atlases posmā ir jānorāda:

  • /dev/md1, - pievienoÅ”anas punkts /boot, FS - BTRFS
  • /dev/root/root (aka /dev/mapper/root-root), - pievienoÅ”anas punkts / (sakne), FS - BTRFS
  • /dev/root/swap (aka /dev/mapper/root-swap), - izmantojiet kā mijmaiņas nodalÄ«jumu
  • Instalējiet sāknÄ“Å”anas ielādētāju vietnē /dev/sda

Atlasot BTRFS kā saknes failu sistēmu, instalÄ“Å”anas programma automātiski izveidos divus BTRFS sējumus ar nosaukumu "@" / (sakne) un "@home" /home.

Sāksim instalÄ“Å”anu...

InstalÄ“Å”ana beigsies ar modālu dialoglodziņu, kas norāda uz kļūdu, instalējot sāknÄ“Å”anas ielādētāju. Diemžēl jÅ«s nevarēsit iziet no Ŕī dialoglodziņa, izmantojot standarta lÄ«dzekļus, un turpināt instalÄ“Å”anu. Mēs izrakstāmies no sistēmas un piesakāmies vēlreiz, nokļūstot tÄ«rā Ubuntu Live darbvirsmā. Atveriet termināli un vēlreiz:

#sudo bash

Lai turpinātu instalÄ“Å”anu, izveidojiet chroot vidi:

#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

Konfigurēsim tīklu un resursdatora nosaukumu programmā chroot:

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

Pāriesim chroot vidē:

#chroot /mnt/chroot

Pirmkārt, mēs piegādāsim pakas:

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

PārbaudÄ«sim un izlabosim visas paketes, kas tika instalētas nepareizi nepilnÄ«gas sistēmas instalÄ“Å”anas dēļ:

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

Ja kaut kas nedarbojas, iespējams, vispirms būs jārediģē /etc/apt/sources.list

Pielāgosim RAID 6 moduļa parametrus, lai iespējotu TRIM/DISCARD:

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

Nedaudz pielabosim savus masīvus:

#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

Kas tas bija..?Mēs esam izveidojuÅ”i udev noteikumu kopu, kas veiks Ŕādas darbÄ«bas:

  • Iestatiet RAID 2020 bloka keÅ”atmiņas lielumu, lai tas bÅ«tu piemērots 6. gadam. Å Ä·iet, ka noklusējuma vērtÄ«ba nav mainÄ«jusies kopÅ” Linux izveides un nav bijusi piemērota ilgu laiku.
  • Rezervējiet vismaz IO masÄ«va pārbaužu/sinhronizācijas ilgumam. Tas ir paredzēts, lai novērstu jÅ«su masÄ«vu iestrēgÅ”anu mūžīgās sinhronizācijas stāvoklÄ« slodzes laikā.
  • Ierobežojiet maksimālo IO masÄ«vu pārbaužu/sinhronizācijas laikā. Tas ir nepiecieÅ”ams, lai, sinhronizējot/pārbaudot SSD RAID, jÅ«su diskdziņi netiktu izcepti. Tas jo Ä«paÅ”i attiecas uz NVMe. (Atceries par radiatoru? Es nejokoju.)
  • Aizliegt diskiem apturēt vārpstas rotāciju (HDD), izmantojot APM, un iestatÄ«t diska kontrolleru miega taimautu uz 7 stundām. Varat pilnÄ«bā atspējot APM, ja jÅ«su diskdziņi to spēj (-B 255). Izmantojot noklusējuma vērtÄ«bu, diskdziņi apstāsies pēc piecām sekundēm. Pēc tam OS vēlas atiestatÄ«t diska keÅ”atmiņu, diski atkal sagriezÄ«sies un viss sāksies no jauna. Diskiem ir ierobežots maksimālais vārpstas apgriezienu skaits. Šāds vienkārÅ”s noklusējuma cikls var viegli iznÄ«cināt jÅ«su diskus pāris gadu laikā. Ne visi diski no tā cieÅ”, bet mÅ«sējie ir ā€œklēpjdatoriā€ ar atbilstoÅ”iem noklusējuma iestatÄ«jumiem, kas padara RAID lÄ«dzÄ«gu mini-MAID.
  • Instalējiet priekÅ”lasÄ«Å”anas uz diskiem (rotējoÅ”s) 1 megabaits ā€” divi secÄ«gi bloki/gabals RAID 6
  • Atspējot priekÅ”lasÄ«Å”anu paÅ”os masÄ«vos.

Rediģēsim /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
Kāpēc ir tā, ka..?Mēs meklēsim /boot nodalÄ«jumu pēc UUID. MasÄ«vu nosaukÅ”ana teorētiski varētu mainÄ«ties.

Pārējās sadaļas meklēsim pēc LVM nosaukumiem /dev/mapper/vg-lv apzīmējumā, jo tie identificē nodalījumus diezgan unikāli.

Mēs neizmantojam UUID priekÅ” LVM, jo LVM sējumu un to momentuzņēmumu UUID var bÅ«t vienāds.Pievienojiet /dev/mapper/root-root.. divreiz?Jā. TieÅ”i tā. BTRFS iezÄ«me. Å o failu sistēmu var uzstādÄ«t vairākas reizes ar dažādiem apakÅ”voliem.

Å Ä«s paÅ”as funkcijas dēļ es iesaku nekad neveidot LVM momentuzņēmumus no aktÄ«vajiem BTRFS sējumiem. Atsāknējot, jÅ«s varat saņemt pārsteigumu.

Reģenerēsim mdadm konfigurāciju:

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

Pielāgosim LVM iestatījumus:

#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

Kas tas bija..?Esam iespējojuÅ”i LVM plāno baseinu automātisku paplaÅ”ināŔanu, sasniedzot 90% no aizņemtās platÄ«bas par 5% no tilpuma.

Mēs esam palielinājuÅ”i LVM keÅ”atmiņas maksimālo keÅ”atmiņas bloku skaitu.

Mēs neļāvām LVM meklēt LVM sējumus (PV) vietnē:

  • ierÄ«ces, kas satur LVM keÅ”atmiņu (cdata)
  • ierÄ«ces keÅ”atmiņā, izmantojot LVM keÅ”atmiņu, apejot keÅ”atmiņu ( _corig). Å ajā gadÄ«jumā pati keÅ”atmiņā saglabātā ierÄ«ce joprojām tiks skenēta, izmantojot keÅ”atmiņu (tikai ).
  • ierÄ«ces, kas satur LVM keÅ”atmiņas metadatus (cmeta)
  • visas VG ierÄ«ces ar nosaukumu attēliem. Å eit mums bÅ«s virtuālo maŔīnu diska attēli, un mēs nevēlamies, lai LVM resursdatorā aktivizētu sējumus, kas pieder viesu OS.
  • visas VG ierÄ«ces ar nosaukuma dublējumu. Å eit mums bÅ«s virtuālās maŔīnas attēlu rezerves kopijas.
  • visas ierÄ«ces, kuru nosaukums beidzas ar ā€œgpvā€ (viesa fiziskais apjoms)

Mēs esam iespējojuÅ”i DISCARD atbalstu, atbrÄ«vojot brÄ«vu vietu LVM VG. Esi uzmanÄ«gs. Tādējādi LV dzÄ“Å”ana SSD diskā bÅ«s diezgan laikietilpÄ«ga. ÄŖpaÅ”i tas attiecas uz SSD RAID 6. Taču saskaņā ar plānu izmantosim plāno nodroÅ”inājumu, tāpēc tas mums nekādi netraucēs.

Atjaunināsim initramfs attēlu:

#update-initramfs -u -k all

Instalējiet un konfigurējiet grub:

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

Kādus diskus izvēlēties?Visi, kas ir sd*. Sistēmai jāspēj palaist no jebkura strādājoÅ”a SATA diskdziņa vai SSD.

Kāpēc viņi pievienoja os-prober..?Par pārmērīgu neatkarību un rotaļīgām rokām.

Tas nedarbojas pareizi, ja viens no RAID ir degradētā stāvoklÄ«. Tas mēģina meklēt OS nodalÄ«jumos, kas tiek izmantoti virtuālajās maŔīnās, kas darbojas ar Å”o aparatÅ«ru.

Ja jums tas ir nepiecieÅ”ams, varat to atstāt, taču paturiet prātā visu iepriekÅ” minēto. Iesaku internetā meklēt receptes, kā atbrÄ«voties no nerātnām rokām.

Ar to mēs esam pabeiguÅ”i sākotnējo instalÄ“Å”anu. Ir pienācis laiks restartēt tikko instalēto OS. Neaizmirstiet noņemt sāknējamo Live CD/USB.

#exit
#reboot

Kā sāknÄ“Å”anas ierÄ«ci atlasiet jebkuru no SATA SSD.

LVM uz SATA SSD

Å ajā brÄ«dÄ« mēs jau esam sāknējuÅ”i jauno OS, konfigurējuÅ”i tÄ«klu, atvēruÅ”i termināļa emulatoru un palaiduÅ”i:

#sudo bash

Turpināsim.

"Inicializējiet" masīvu no SATA SSD:

#blkdiscard /dev/md2

Ja tas nedarbojas, mēģiniet:

#blkdiscard --step 65536 /dev/md2
Izveidojiet LVM VG uz SATA SSD:

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

Kāpēc vēl VG..?Patiesībā mums jau ir VG ar nosaukumu sakne. Kāpēc ne pievienot visu vienā VG?

Ja VG ir vairāki PV, tad, lai VG tiktu pareizi aktivizēts, visiem PV ir jābÅ«t klāt (tieÅ”saistē). Izņēmums ir LVM RAID, ko mēs apzināti neizmantojam.

Mēs patieŔām vēlamies, lai, ja kādā no RAID 6 masÄ«viem rodas kļūme (lasÄ«Å”anas datu zudums), operētājsistēma sāks normāli un dos mums iespēju atrisināt problēmu.

Lai to izdarÄ«tu, pirmajā abstrakcijas lÄ«menÄ« mēs izolēsim katru fizisko ā€œmedijuā€ veidu atseviŔķā VG.

Zinātniski runājot, dažādi RAID masÄ«vi pieder pie dažādiem ā€œuzticamÄ«bas domēniemā€. Jums nevajadzētu radÄ«t viņiem papildu kopÄ«gu neveiksmes punktu, ievietojot tos vienā VG.

LVM klātbÅ«tne ā€œaparatÅ«rasā€ lÄ«menÄ« ļaus mums patvaļīgi izgriezt dažādu RAID masÄ«vu gabalus, kombinējot tos dažādos veidos. Piemēram ā€“ skrien vienlaicÄ«gi bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, sarežģīta ZFS konfigurācija ar keÅ”atmiņām vai kāds cits elliŔķīgs maisÄ«jums, lai mēģinātu to visu salÄ«dzināt.

ā€œAparatÅ«rasā€ lÄ«menÄ« neko citu kā vecos labos ā€œbiezoā€ LVM sējumus neizmantosim. Izņēmums no Ŕī noteikuma var bÅ«t rezerves nodalÄ«jums.

Domāju, ka Ŕajā brīdī daudzi lasītāji jau bija sākuŔi kaut ko aizdomāties par ligzdojoŔo lelli.

LVM uz SATA HDD

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

Atkal jauns VG..?Mēs patieŔām vēlamies, lai gadÄ«jumā, ja diska masÄ«vs, ko izmantosim datu dublÄ“Å”anai, neizdosies, mÅ«su operētājsistēma turpinās darboties normāli, vienlaikus saglabājot piekļuvi datiem, kas nav dublēti, kā parasti. Tāpēc, lai izvairÄ«tos no VG aktivizÄ“Å”anas problēmām, mēs izveidojam atseviŔķu VG.

LVM keÅ”atmiņas iestatÄ«Å”ana

Izveidosim LV uz NVMe RAID 1, lai to izmantotu kā keÅ”atmiņas ierÄ«ci.

#lvcreate -L 70871154688B --name cache root

Kāpēc ir tik maz...?Fakts ir tāds, ka mÅ«su NVMe SSD ir arÄ« SLC keÅ”atmiņa. 4 gigabaiti ā€œbezmaksasā€ un 18 gigabaiti dinamiskā, pateicoties 3 bitu MLC aizņemtajai brÄ«vajai vietai. Kad Ŕī keÅ”atmiņa bÅ«s izsmelta, NVMe SSD nebÅ«s daudz ātrāki par mÅ«su SATA SSD ar keÅ”atmiņu. Faktiski Ŕī iemesla dēļ mums nav jēgas padarÄ«t LVM keÅ”atmiņas nodalÄ«jumu daudz lielāku par divreiz lielāku par NVMe diska SLC keÅ”atmiņu. Izmantotajiem NVMe diskdziņiem autors uzskata par saprātÄ«gu izveidot 32-64 gigabaitu keÅ”atmiņu.

NorādÄ«tais nodalÄ«juma lielums ir nepiecieÅ”ams, lai organizētu 64 gigabaitus keÅ”atmiņas, keÅ”atmiņas metadatus un metadatu dublējumu.

Turklāt es atzÄ«mēju, ka pēc netÄ«ras sistēmas izslēgÅ”anas LVM atzÄ«mēs visu keÅ”atmiņu kā netÄ«ru un atkal sinhronizēs. Turklāt tas tiks atkārtots katru reizi, kad Å”ajā ierÄ«cē tiek izmantots lvchange, lÄ«dz sistēma tiks atkārtoti palaists. Tāpēc es iesaku nekavējoties atjaunot keÅ”atmiņu, izmantojot atbilstoÅ”o skriptu.

Izveidosim LV uz SATA RAID 6, lai to izmantotu kā keÅ”atmiņā saglabātu ierÄ«ci.

#lvcreate -L 3298543271936B --name cache data

Kāpēc tikai trÄ«s terabaiti..?Lai vajadzÄ«bas gadÄ«jumā varētu izmantot SATA SSD RAID 6 kādām citām vajadzÄ«bām. KeÅ”atmiņas vietas lielumu var palielināt dinamiski, lidojuma laikā, neapturot sistēmu. Lai to izdarÄ«tu, jums ir Ä«slaicÄ«gi jāaptur un atkārtoti jāiespējo keÅ”atmiņa, taču LVM keÅ”atmiņas Ä«paŔā priekÅ”rocÄ«ba salÄ«dzinājumā ar, piemēram, bcache ir tā, ka to var izdarÄ«t lidojuma laikā.

Izveidosim jaunu VG keÅ”atmiņai.

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

KeÅ”atmiņā saglabātajā ierÄ«cē izveidosim LV.

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

Å eit mēs uzreiz aizņēmām visu brÄ«vo vietu /dev/data/cache, lai visi pārējie nepiecieÅ”amie nodalÄ«jumi tiktu izveidoti uzreiz /dev/root/cache. Ja kaut ko izveidojāt nepareizā vietā, varat to pārvietot, izmantojot pvmove.

Izveidosim un iespējosim keÅ”atmiņu:

#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

Kāpēc tādi gabaliņi..?Veicot praktiskus eksperimentus, autors varēja noskaidrot, ka vislabākais rezultāts tiek sasniegts, ja LVM keÅ”atmiņas bloka izmērs sakrÄ«t ar LVM plānā bloka izmēru. Turklāt, jo mazāks izmērs, jo labāk konfigurācija darbojas nejauŔā ierakstā.

64k ir minimālais pieļaujamais LVM plānais bloka izmērs.

Esiet uzmanÄ«gi rakstot..!Jā. Šāda veida keÅ”atmiņa atliek rakstÄ«Å”anas sinhronizāciju ar keÅ”atmiņā saglabāto ierÄ«ci. Tas nozÄ«mē, ka, ja tiek zaudēta keÅ”atmiņa, varat zaudēt datus keÅ”atmiņā saglabātajā ierÄ«cē. Vēlāk autors pastāstÄ«s, kādus pasākumus papildus NVMe RAID 1 var veikt, lai kompensētu Å”o risku.

Å is keÅ”atmiņas veids tika izvēlēts ar nolÅ«ku, lai kompensētu RAID 6 slikto nejauŔās rakstÄ«Å”anas veiktspēju.

Pārbaudīsim, ko esam ieguvuŔi:

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

Tikai [cachedata_corig] ir jāatrodas mapē /dev/data/cache. Ja kaut kas nav kārtībā, izmantojiet pvmove.

Ja nepiecieÅ”ams, keÅ”atmiņu var atspējot ar vienu komandu:

#lvconvert -y --uncache cache/cachedata

Tas tiek darÄ«ts tieÅ”saistē. LVM vienkārÅ”i sinhronizēs keÅ”atmiņu ar disku, noņems to un pārdēvēs cachedata_corig atpakaļ uz cachedata.

LVM plāna iestatīŔana

Aptuveni novērtēsim, cik daudz vietas mums ir nepiecieÅ”ams LVM plānajiem metadatiem:

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

Noapaļot lÄ«dz 4 gigabaitiem: 4294967296B

Reiziniet ar divi un pievienojiet 4194304B LVM PV metadatiem: 8594128896B
Izveidosim atseviŔķu nodalījumu NVMe RAID 1, lai tajā ievietotu LVM plānos metadatus un to rezerves kopiju:

#lvcreate -L 8594128896B --name images root

Par ko..?Å eit var rasties jautājums: kāpēc LVM plānos metadatus ievietot atseviŔķi, ja tie joprojām tiks saglabāti keÅ”atmiņā NVMe un darbosies ātri.

Lai gan ātrums Å”eit ir svarÄ«gs, tas nebÅ«t nav galvenais iemesls. Lieta tāda, ka keÅ”atmiņa ir neveiksmes punkts. Ar to var kaut kas notikt, un, ja LVM plānie metadati tiks saglabāti keÅ”atmiņā, viss tiks pilnÄ«bā zaudēts. Bez pilnÄ«giem metadatiem bÅ«s gandrÄ«z neiespējami salikt plānus sējumus.

Pārvietojot metadatus uz atseviŔķu keÅ”atmiņu neglabātu, bet ātru sējumu, mēs garantējam metadatu droŔību keÅ”atmiņas zuduma vai sabojāŔanas gadÄ«jumā. Å ajā gadÄ«jumā visi bojājumi, ko izraisa keÅ”atmiņas zudums, tiks lokalizēti nelielos sējumos, kas vienkārÅ”os atkopÅ”anas procedÅ«ru par lielumu. Ar lielu varbÅ«tÄ«bu Å”ie bojājumi tiks atjaunoti, izmantojot FS žurnālus.

Turklāt, ja iepriekÅ” tika uzņemts neliela apjoma momentuzņēmums un pēc tam keÅ”atmiņa vismaz vienu reizi tika pilnÄ«bā sinhronizēta, tad LVM thin iekŔējās konstrukcijas dēļ momentuzņēmuma integritāte tiks garantēta keÅ”atmiņas zuduma gadÄ«jumā. .

Izveidosim jaunu VG, kas būs atbildīgs par plānoŔanu:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Izveidosim baseinu:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Kāpēc -Z yPapildus tam, kam Å”is režīms patiesÄ«bā ir paredzēts - lai, pārdalot vietu, dati no vienas virtuālās maŔīnas nenoplÅ«stu uz citu virtuālo maŔīnu, papildus tiek izmantota nullÄ“Å”ana, lai palielinātu nejauŔās rakstÄ«Å”anas ātrumu blokos, kas mazāki par 64k. JebkurÅ” ieraksts, kas ir mazāks par 64 k uz iepriekÅ” nepieŔķirtu plānā sējuma apgabalu, keÅ”atmiņā tiks izlÄ«dzināts ar malu lÄ«dz 64 K. Tas ļaus operāciju pilnÄ«bā veikt caur keÅ”atmiņu, apejot keÅ”atmiņā saglabāto ierÄ«ci.

Pārvietosim LV uz atbilstoŔajiem PV:

#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

Pārbaudīsim:

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

Izveidosim nelielu sējumu testiem:

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

Mēs uzstādīsim paketes testiem un uzraudzībai:

#apt-get install sysstat fio

Šādi varat reāllaikā novērot mūsu krātuves konfigurācijas darbību:

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

Tādā veidā mēs varam pārbaudīt mūsu konfigurāciju:

#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

UzmanÄ«gi! Resurss!Å is kods veiks 36 dažādus testus, katrs 4 sekundes. Puse no testiem ir paredzēta ierakstÄ«Å”anai. JÅ«s varat ierakstÄ«t daudz NVMe 4 sekundēs. LÄ«dz 3 gigabaitiem sekundē. Tādējādi katrs rakstÄ«Å”anas tests var patērēt lÄ«dz 216 gigabaitiem SSD resursa.

Jaukta lasÄ«Å”ana un rakstÄ«Å”ana?Jā. Ir lietderÄ«gi palaist lasÄ«Å”anas un rakstÄ«Å”anas testus atseviŔķi. Turklāt ir lietderÄ«gi nodroÅ”ināt, lai visas keÅ”atmiņas tiktu sinhronizētas, lai iepriekÅ” veikta rakstÄ«Å”ana neietekmētu lasÄ«Å”anu.

Rezultāti ļoti atŔķirsies pirmās palaiÅ”anas un turpmāko palaiÅ”anas laikā, jo aizpildās keÅ”atmiņa un mazais apjoms, kā arÄ« atkarÄ«bā no tā, vai sistēmai izdevās sinhronizēt pēdējās palaiÅ”anas laikā aizpildÄ«tās keÅ”atmiņas.

Cita starpā es iesaku izmērÄ«t ātrumu jau pilnÄ«bā plānā skaļumā, no kura tikko tika uzņemts momentuzņēmums. Autoram bija iespēja novērot, kā nejauÅ”as rakstÄ«Å”anas strauji paātrinās uzreiz pēc pirmā momentuzņēmuma izveidoÅ”anas, it Ä«paÅ”i, ja keÅ”atmiņa vēl nav pilnÄ«bā pilna. Tas notiek, pateicoties kopÄ“Å”anas un rakstÄ«Å”anas rakstÄ«Å”anas semantikai, keÅ”atmiņas izlÄ«dzināŔanai un plāniem apjoma blokiem, kā arÄ« faktam, ka nejauÅ”a ierakstÄ«Å”ana RAID 6 pārvērÅ”as nejauŔā lasÄ«Å”anā no RAID 6, kam seko rakstÄ«Å”ana keÅ”atmiņā. MÅ«su konfigurācijā nejauÅ”a nolasÄ«Å”ana no RAID 6 ir lÄ«dz pat 6 reizēm (SATA SSD skaits masÄ«vā) ātrāk nekā rakstÄ«Å”ana. Jo bloki CoW tiek pieŔķirti secÄ«gi no plānas pÅ«les, tad ieraksts lielākoties arÄ« pārvērÅ”as par secÄ«gu.

Abas Ŕīs funkcijas var izmantot savā labā.

Saglabājiet "saskaņotus" momentuzņēmumus keÅ”atmiņā

Lai samazinātu datu zuduma risku keÅ”atmiņas bojājuma/zaudÄ“Å”anas gadÄ«jumā, autore ierosina ieviest momentuzņēmumu rotācijas praksi, lai Å”ajā gadÄ«jumā garantētu to integritāti.

Pirmkārt, tā kā maza apjoma metadati atrodas ierÄ«cē, kas nav saglabāta keÅ”atmiņā, metadati bÅ«s konsekventi un iespējamie zudumi tiks izolēti datu blokos.

Å is momentuzņēmumu rotācijas cikls garantē momentuzņēmumos esoÅ”o datu integritāti keÅ”atmiņas zuduma gadÄ«jumā:

  1. Katram plānajam sējumam ar nosaukumu <nosaukums> izveidojiet momentuzņēmumu ar nosaukumu <name>.cached
  2. Iestatīsim migrācijas slieksni uz saprātīgi augstu vērtību: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
  3. Ciklā mēs pārbaudām netÄ«ro bloku skaitu keÅ”atmiņā: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' lÄ«dz sasniegsim nulli. Ja nulle trÅ«kst pārāk ilgi, to var izveidot, Ä«slaicÄ«gi pārslēdzot keÅ”atmiņu uz ierakstÄ«Å”anas režīmu. Tomēr, ņemot vērā mÅ«su SATA un NVMe SSD masÄ«vu ātruma raksturlielumus, kā arÄ« to TBW resursus, jÅ«s vai nu varēsit ātri uztvert mirkli, nemainot keÅ”atmiņas režīmu, vai arÄ« jÅ«su aparatÅ«ra pilnÄ«bā apēdÄ«s visus savus resursus. dažas dienas. Resursu ierobežojumu dēļ sistēma principā nevar visu laiku bÅ«t zem 100% rakstÄ«Å”anas slodzes. MÅ«su NVMe SSD diski ar 100% rakstÄ«Å”anas slodzi pilnÄ«bā iztērēs resursus 3-4 dienas. SATA SSD kalpos tikai divreiz ilgāk. Tāpēc pieņemsim, ka lielākā daļa slodzes ir lasÄ«Å”anai, un mums ir salÄ«dzinoÅ”i Ä«slaicÄ«gi ārkārtÄ«gi augstas aktivitātes uzliesmojumi apvienojumā ar vidēji zemu slodzi rakstÄ«Å”anai.
  4. TiklÄ«dz esam nozvejojuÅ”i (vai izveidojuÅ”i) nulli, mēs pārdēvējam <name>.cached par <name>.committed. Vecais <name>.committed ir dzēsts.
  5. Pēc izvēles, ja keÅ”atmiņa ir 100% pilna, to var atkārtoti izveidot ar skriptu, tādējādi notÄ«rot to. Ar pustukÅ”u keÅ”atmiņu sistēma rakstot strādā daudz ātrāk.
  6. Iestatiet migrācijas slieksni uz nulli: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Tas Ä«slaicÄ«gi neļaus keÅ”atmiņai sinhronizēties ar galveno datu nesēju.
  7. Mēs gaidām, kamēr keÅ”atmiņā sakrājas diezgan daudz izmaiņu #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' vai taimeris izslēgsies.
  8. Mēs atkārtojam vēlreiz.

Kāpēc grÅ«tÄ«bas ar migrācijas slieksni...?Lieta ir tāda, ka reālajā praksē ā€œnejauÅ”sā€ ieraksts patiesÄ«bā nav pilnÄ«gi nejauÅ”s. Ja kaut ko ierakstÄ«jām 4 kilobaitu lielumā sektorā, pastāv liela varbÅ«tÄ«ba, ka tuvāko pāris minÅ«Å”u laikā tiks veikts ieraksts tajā paŔā vai kādā no blakus esoÅ”ajiem (+- 32K) sektoriem.

Iestatot migrācijas slieksni uz nulli, mēs atliekam rakstÄ«Å”anas sinhronizāciju SATA SSD un apkopojam vairākas izmaiņas vienā 64K blokā keÅ”atmiņā. Tas ievērojami ietaupa SATA SSD resursus.

Kur ir kods..?Diemžēl autors uzskata sevi par nepietiekami kompetentu bash skriptu izstrādē, jo ir 100% autodidakts un praktizē ā€œgoogleā€ vadÄ«tu izstrādi, tāpēc uzskata, ka Å”ausmÄ«go kodu, kas nāk no viņa rokām, nedrÄ«kst izmantot neviens. cits.

Domāju, ka Ŕīs jomas profesionāļi vajadzÄ«bas gadÄ«jumā spēs patstāvÄ«gi attēlot visu iepriekÅ” aprakstÄ«to loÄ£iku un, iespējams, pat skaisti noformēt to kā sistēmisku servisu, kā to centās darÄ«t autors.

Šāda vienkārÅ”a momentuzņēmuma rotācijas shēma ļaus mums ne tikai pastāvÄ«gi pilnÄ«bā sinhronizēt vienu momentuzņēmumu SATA SSD, bet arÄ«, izmantojot utilÄ«tu thin_delta, noskaidrot, kuri bloki tika mainÄ«ti pēc tā izveidoÅ”anas, un tādējādi lokalizēt bojājumus galvenie apjomi, ievērojami vienkārÅ”ojot atgÅ«Å”anu.

TRIM/DISCARD programmā libvirt/KVM

Jo datu krātuve tiks izmantota KVM darbināŔanai libvirt, tad derētu iemācÄ«t mÅ«su VM ne tikai aizņemt brÄ«vu vietu, bet arÄ« atbrÄ«vot to, kas vairs nav vajadzÄ«gs.

Tas tiek darīts, emulējot TRIM/DISCARD atbalstu virtuālajos diskos. Lai to izdarītu, ir jāmaina kontrollera veids uz virtio-scsi un jārediģē 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>

LVM pareizi apstrādā Ŕādus DISCARD failus no viesu OS, un bloki tiek pareizi atbrÄ«voti gan keÅ”atmiņā, gan plānā. MÅ«su gadÄ«jumā tas notiek galvenokārt aizkavētā veidā, dzÄ“Å”ot nākamo momentuzņēmumu.

BTRFS dublējums

Izmantojiet gatavus skriptus ar ekstrēms piesardzÄ«ba un uz savu risku. Autors Å”o kodu uzrakstÄ«ja pats un tikai sev. Esmu pārliecināts, ka daudziem pieredzējuÅ”iem Linux lietotājiem ir lÄ«dzÄ«gi rÄ«ki, un nav nepiecieÅ”ams kopēt kādu citu.

Izveidosim sējumu rezerves ierīcē:

#lvcreate -L 256G --name backup backup

Formatēsim to BTRFS:

#mkfs.btrfs /dev/backup/backup

Izveidosim stiprinājuma punktus un montēsim failu sistēmas saknes apakÅ”sadaļas:

#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

Izveidosim direktorijus dublēŔanai:

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

Izveidosim direktoriju rezerves skriptiem:

#mkdir /root/btrfs-backup

Kopēsim skriptu:

Daudz biedējoÅ”u bash koda. Izmantojiet uz savu risku. Neraksti autoram dusmÄ«gas vēstules...#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

Ko tas vispār dara..?Satur vienkārÅ”u komandu kopu, lai izveidotu BTRFS momentuzņēmumus un kopētu tos uz citu FS, izmantojot BTRFS sÅ«tÄ«Å”anu/saņemÅ”anu.

Pirmā palaiÅ”ana var bÅ«t salÄ«dzinoÅ”i ilga, jo... Sākumā visi dati tiks kopēti. Turpmākās palaiÅ”anas bÅ«s ļoti ātras, jo... Tiks kopētas tikai izmaiņas.

Vēl viens skripts, ko ievietosim cron:

Vēl kāds bash kods#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

Ko tas dara..?Izveido un sinhronizē papildu momentuzņēmumus no uzskaitÄ«tajiem BTRFS sējumiem dublējuma FS. Pēc tam tiek izdzēsti visi attēli, kas izveidoti pirms 60 dienām. Pēc palaiÅ”anas /backup/btrfs/back/remote/ apakÅ”direktorijās tiks parādÄ«ti uzskaitÄ«to sējumu datēti momentuzņēmumi.

PieŔķirsim koda izpildes tiesības:

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

Pārbaudīsim to un ievietosim kronā:

#/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 plānā dublējums

Izveidosim plānu kopu rezerves ierīcē:

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

Instalēsim ddrescue, jo... skripti izmantos Å”o rÄ«ku:

#apt-get install gddrescue

Izveidosim skriptu direktoriju:

#mkdir /root/lvm-thin-backup

Kopēsim skriptus:

IekŔā daudz trakulības...#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

Ko tas dara...?Ietver komandu kopu, lai manipulētu ar plāniem momentuzņēmumiem un sinhronizētu atŔķirÄ«bu starp diviem plāniem momentuzņēmumiem, kas saņemti, izmantojot thin_delta, ar citu bloka ierÄ«ci, izmantojot ddrescue un blkdiscard.

Vēl viens skripts, ko ievietosim cron:

Nedaudz vairāk 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

Ko tas dara...?Izmanto iepriekŔējo skriptu, lai izveidotu un sinhronizētu uzskaitÄ«to plāno sējumu dublējumus. Skripts atstās neaktÄ«vus uzskaitÄ«to sējumu momentuzņēmumus, kas nepiecieÅ”ami, lai izsekotu izmaiņām kopÅ” pēdējās sinhronizācijas.

Šis skripts ir jārediģē, norādot plānu sējumu sarakstu, kuriem jāizveido rezerves kopijas. Norādītie nosaukumi ir paredzēti tikai ilustratīviem nolūkiem. Ja vēlaties, varat uzrakstīt skriptu, kas sinhronizēs visus sējumus.

Dosim tiesības:

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

Pārbaudīsim to un ievietosim kronā:

#/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

Pirmā palaiÅ”ana bÅ«s ilga, jo... plānie sējumi tiks pilnÄ«bā sinhronizēti, kopējot visu izmantoto vietu. Pateicoties LVM plānajiem metadatiem, mēs zinām, kuri bloki faktiski tiek izmantoti, tāpēc tiks kopēti tikai faktiski izmantotie plānie apjoma bloki.

Turpmākās darbÄ«bas pakāpeniski kopēs datus, pateicoties izmaiņu izsekoÅ”anai, izmantojot LVM plānos metadatus.

Apskatīsim, kas notika:

#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

Kāds tam sakars ar ligzdoÅ”anas lellēm?

Visticamāk, ņemot vērā, ka LVM LV loÄ£iskie apjomi var bÅ«t LVM PV fiziskie apjomi citiem VG. LVM var bÅ«t rekursÄ«vs, piemēram, ligzdotas lelles. Tas nodroÅ”ina LVM ārkārtēju elastÄ«bu.

PS

Nākamajā rakstā mēs mēģināsim izmantot vairākas lÄ«dzÄ«gas mobilās atmiņas sistēmas/KVM kā pamatu Ä£eogrāfiski sadalÄ«tas krātuves/vm klastera izveidei ar dublÄ“Å”anu vairākos kontinentos, izmantojot mājas galddatorus, mājas internetu un P2P tÄ«klus.

Avots: www.habr.com

Pievieno komentāru