ProHoster > Blog > Stjórnsýsla > Hvað eiga LVM og Matryoshka sameiginlegt?

Hvað eiga LVM og Matryoshka sameiginlegt?

Góður dagur.
Mig langar að deila með samfélaginu hagnýtri reynslu minni af því að byggja upp gagnageymslukerfi fyrir KVM með md RAID + LVM.

Dagskráin mun innihalda:

  • Byggja md RAID 1 frá NVMe SSD.
  • Að setja saman md RAID 6 frá SATA SSD og venjulegum diskum.
  • Eiginleikar TRIM/DISCARD aðgerða á SSD RAID 1/6.
  • Að búa til ræsanlegt md RAID 1/6 fylki á sameiginlegu setti diska.
  • Að setja upp kerfið á NVMe RAID 1 þegar enginn NVMe stuðningur er í BIOS.
  • Notar LVM skyndiminni og LVM þunnt.
  • Notaðu BTRFS skyndimyndir og sendu/móttöku fyrir öryggisafrit.
  • Notkun LVM þunnar skyndimyndir og thin_delta fyrir afrit í BTRFS stíl.

Ef þú hefur áhuga, vinsamlegast sjáðu köttinn.

Заявление

Höfundur ber enga ábyrgð á afleiðingum þess að nota eða nota ekki efni/dæmi/kóða/ráð/gögn úr þessari grein. Með því að lesa eða nota þetta efni á einhvern hátt, tekur þú ábyrgð á öllum afleiðingum þessara aðgerða. Hugsanlegar afleiðingar eru:

  • Stökksteiktir NVMe SSD diskar.
  • Fullkomlega notað upptökuforrit og bilun á SSD drifum.
  • Algjört tap á öllum gögnum á öllum drifum, þar á meðal öryggisafritum.
  • Bilaður tölvuvélbúnaður.
  • Sóun á tíma, taugum og peningum.
  • Allar aðrar afleiðingar sem ekki eru taldar upp hér að ofan.

Járn

Í boði voru:

Móðurborð frá um 2013 með Z87 flís, heill með Intel Core i7 / Haswell.

  • Örgjörvi 4 kjarna, 8 þræðir
  • 32 GB DDR3 vinnsluminni
  • 1 x 16 eða 2 x 8 PCIe 3.0
  • 1 x 4 + 1 x 1 PCIe 2.0
  • 6 x 6 GBps SATA 3 tengi

SAS millistykki LSI SAS9211-8I blikkaði í IT / HBA ham. RAID-virkjuðum fastbúnaði hefur verið viljandi skipt út fyrir HBA fastbúnað til að:

  1. Þú gætir hent þessum millistykki hvenær sem er og skipt honum út fyrir hvaða annan sem þú rekst á.
  2. TRIM/Discard virkaði venjulega á diskum, vegna þess að... í RAID fastbúnaði eru þessar skipanir alls ekki studdar og HBA er almennt sama hvaða skipanir eru sendar yfir strætó.

Harðir diskar - 8 stykki af HGST Travelstar 7K1000 með 1 TB afkastagetu í 2.5 formstuðli, eins og fyrir fartölvur. Þessir drif voru áður í RAID 6 fylki. Þeir munu einnig nýtast í nýja kerfinu. Til að geyma staðbundið afrit.

Auk þess bætt við:

6 stykki SATA SSD gerð Samsung 860 QVO 2TB. Þessar SSDs þurftu mikið magn, tilvist SLC skyndiminni, áreiðanleika og lágt verð var óskað. Stuðningur við hent/núll var krafist, sem er athugað með línunni í dmesg:

kernel: ata1.00: Enabling discard_zeroes_data

2 stykki af NVMe SSD gerð Samsung SSD 970 EVO 500GB.

Fyrir þessar SSDs er tilviljunarkenndur les-/skrifhraði og auðlindageta fyrir þarfir þínar mikilvægar. Ofn fyrir þá. Nauðsynlega. Algjörlega. Annars skaltu steikja þær þar til þær verða stökkar við fyrstu RAID samstillingu.

StarTech PEX8M2E2 millistykki fyrir 2 x NVMe SSD uppsett í PCIe 3.0 8x rauf. Þetta er aftur bara HBA, en fyrir NVMe. Það er frábrugðið ódýrum millistykki að því leyti að það þarf ekki PCIe tvískiptastuðning frá móðurborðinu vegna þess að innbyggður PCIe rofi er til staðar. Það mun virka jafnvel í elsta kerfinu með PCIe, jafnvel þótt það sé x1 PCIe 1.0 rauf. Auðvitað, á viðeigandi hraða. Það eru engin RAID þar. Það er ekkert innbyggt BIOS um borð. Svo, kerfið þitt mun ekki á töfrandi hátt læra að ræsa með NVMe, miklu síður gerir NVMe RAID þökk sé þessu tæki.

Þessi hluti var eingöngu vegna þess að aðeins einn ókeypis 8x PCIe 3.0 er í kerfinu, og ef það eru 2 ókeypis raufar er auðvelt að skipta honum út fyrir tvo eyri PEX4M2E1 eða hliðstæður, sem hægt er að kaupa hvar sem er á 600 verði. rúblur.

Höfnun á alls kyns vélbúnaði eða innbyggðu kubbasetti/BIOS RAID var vísvitandi gert til þess að geta algjörlega skipt út öllu kerfinu, að undanskildum SSD/HDD sjálfum, á sama tíma og öll gögnin varðveitt. Helst, svo að þú getir vistað jafnvel uppsett stýrikerfi þegar þú ferð yfir í alveg nýjan / annan vélbúnað. Aðalatriðið er að það eru SATA og PCIe tengi. Það er eins og lifandi geisladiskur eða ræsanlegt glampi drif, aðeins mjög hratt og svolítið fyrirferðarmikið.

HumorAnnars veistu hvað gerist - stundum þarftu að taka allt fylkið með þér til að taka með þér. En ég vil ekki missa gögn. Til að gera þetta eru allir nefndir miðlar þægilega staðsettir á glærunum í 5.25 hólfum venjulegu hulstrsins.

Jæja, og auðvitað fyrir að gera tilraunir með mismunandi aðferðir við SSD skyndiminni í Linux.

Vélbúnaðarárásir eru leiðinlegar. Kveiktu á því. Annað hvort virkar það eða ekki. Og með mdadm eru alltaf valkostir.

Hugbúnaður

Áður var Debian 8 Jessie sett upp á vélbúnaðinum, sem er nálægt EOL. RAID 6 var sett saman úr ofangreindum harðdiska sem voru paraðir við LVM. Það keyrði sýndarvélar í kvm/libvirt.

Vegna þess að Höfundur hefur viðeigandi reynslu af því að búa til færanlegan ræsanleg SATA/NVMe glampi drif, og einnig, til að brjóta ekki venjulegt viðeigandi sniðmát, var Ubuntu 18.04 valið sem markkerfi, sem hefur þegar verið nægilega stöðugt, en hefur samt 3 ár af stuðning í framtíðinni.

Nefnt kerfi inniheldur alla vélbúnaðarrekla sem við þurfum úr kassanum. Við þurfum engan hugbúnað eða rekla frá þriðja aðila.

Undirbúningur fyrir uppsetningu

Til að setja upp kerfið þurfum við Ubuntu Desktop Image. Miðlarakerfið er með einhvers konar öflugt uppsetningarforrit, sem sýnir óhóflegt sjálfstæði sem ekki er hægt að gera óvirkt með því að troða UEFI kerfisþilinu á einn diskinn, sem spillir allri fegurðinni. Samkvæmt því er það aðeins sett upp í UEFI ham. Býður ekki upp á neina möguleika.

Við erum ekki ánægð með þetta.

Hvers vegna?Því miður er UEFI ræsing mjög illa samhæf við ræsihugbúnað RAID, vegna þess að... Enginn býður okkur pantanir fyrir UEFI ESP skiptinguna. Það eru til uppskriftir á netinu sem benda til þess að ESP skiptingin sé sett á glampi drif í USB tengi, en þetta er bilun. Það eru til uppskriftir sem nota hugbúnaðinn mdadm RAID 1 með lýsigagnaútgáfu 0.9 sem koma ekki í veg fyrir að UEFI BIOS sjái þessa skiptingu, en þetta lifir fram á ánægjulega stundina þegar BIOS eða annað vélbúnaðarkerfi skrifar eitthvað til ESP og gleymir að samstilla það við aðra spegla.

Að auki fer UEFI ræsingin eftir NVRAM, sem mun ekki flytjast ásamt diskunum yfir í nýja kerfið, vegna þess að er hluti af móðurborðinu.

Þannig að við munum ekki finna upp nýtt hjól. Við erum nú þegar með tilbúið, tímaprófað afahjól, sem nú heitir Legacy/BIOS stígvél, sem ber hið stolta nafn CSM á UEFI-samhæfðum kerfum. Við tökum það bara af hillunni, smyrjum það, dælum upp dekkin og þurkum það af með rökum klút.

Það er heldur ekki hægt að setja upp skrifborðsútgáfuna af Ubuntu almennilega með Legacy ræsiforritinu, en hér, eins og sagt er, eru að minnsta kosti valkostir.

Og svo söfnum við vélbúnaðinum og hleðum kerfinu frá Ubuntu Live ræsanlegu glampi drifinu. Við þurfum að hlaða niður pakka, svo við setjum upp netið sem virkar fyrir þig. Ef það virkar ekki geturðu hlaðið nauðsynlegum pakka inn á glampi drif fyrirfram.

Við förum inn í skjáborðsumhverfið, ræsum flugstöðvahermi, og við förum:

#sudo bash

Hvernig…?Línan hér að ofan er kanónísk kveikja fyrir holiwars um sudo. C bоmeiri tækifæri koma ogоmeiri ábyrgð. Spurning hvort þú getir tekið það á þig. Margir halda að notkun sudo á þennan hátt sé að minnsta kosti ekki varkár. Hins vegar:

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

Af hverju ekki ZFS...?Þegar við setjum upp hugbúnað á tölvunni okkar, lánum við í raun vélbúnað okkar til þróunaraðila þessa hugbúnaðar til að keyra.
Þegar við treystum þessum hugbúnaði fyrir öryggi gagna okkar, tökum við lán sem jafngildir kostnaði við að endurheimta þessi gögn, sem við verðum að borga upp einhvern daginn.

Frá þessu sjónarhorni er ZFS Ferrari og mdadm+lvm er meira eins og reiðhjól.

Huglægt vill höfundur frekar lána óþekktum einstaklingum hjól á lánsfé í stað Ferrari. Þar er verðið á útgáfunni ekki hátt. Engin þörf fyrir réttindi. Einfaldara en umferðarreglur. Bílastæði eru ókeypis. Göngufærni er betri. Þú getur alltaf fest fætur á reiðhjól og þú getur gert við reiðhjól með eigin höndum.

Af hverju þá BTRFS...?Til þess að ræsa stýrikerfið þurfum við skráarkerfi sem er stutt í Legacy/BIOS GRUB úr kassanum og styður á sama tíma lifandi skyndimyndir. Við munum nota það fyrir /boot skiptinguna. Að auki kýs höfundur að nota þennan FS fyrir / (rót), ekki gleyma að hafa í huga að fyrir annan hugbúnað er hægt að búa til aðskildar sneiðar á LVM og tengja þær í nauðsynlegar möppur.

Við munum ekki geyma neinar myndir af sýndarvélum eða gagnagrunnum á þessu FS.
Þessi FS verður aðeins notaður til að búa til skyndimyndir af kerfinu án þess að slökkva á því og flytja síðan þessar skyndimyndir yfir á öryggisafrit með því að nota send/recieve.

Að auki kýs höfundur almennt að hafa lágmarks hugbúnað beint á vélbúnaðinum og keyra allan annan hugbúnað í sýndarvélum með því að nota hluti eins og að senda GPU og PCI-USB Host stýringar til KVM í gegnum IOMMU.

Það eina sem eftir er á vélbúnaðinum er gagnageymsla, sýndarvæðing og öryggisafrit.

Ef þú treystir ZFS meira, þá eru þeir í grundvallaratriðum skiptanlegir fyrir tilgreint forrit.

Hins vegar hunsar höfundurinn vísvitandi innbyggðu speglun/RAID og offramboðseiginleika sem ZFS, BRTFS og LVM hafa.

Sem viðbótarrök, BTRFS hefur getu til að breyta tilviljunarkenndum skrifum í röð, sem hefur afar jákvæð áhrif á hraða samstillingar skyndimynda/afrita á HDD.

Við skulum endurskanna öll tæki:

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

Við skulum líta í kringum okkur:

#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

Uppsetning diska

NVMe SSD

En við munum ekki merkja þá á nokkurn hátt. Sama, BIOS okkar sér ekki þessi drif. Þannig að þeir fara algjörlega í hugbúnaðar RAID. Við munum ekki einu sinni búa til hluta þar. Ef þú vilt fylgja „canon“ eða „aðallega“ skaltu búa til eina stóra skipting, eins og HDD.

SATA HDD

Hér þarf ekki að finna upp neitt sérstakt. Við munum búa til einn hluta fyrir allt. Við munum búa til skipting vegna þess að BIOS sér þessa diska og gæti jafnvel reynt að ræsa frá þeim. Við munum jafnvel setja GRUB á þessa diska seinna svo að kerfið geti allt í einu gert þetta.

#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

Þetta er þar sem hlutirnir verða áhugaverðir fyrir okkur.

Í fyrsta lagi eru drif okkar 2 TB að stærð. Þetta er innan viðunandi marka fyrir MBR, sem er það sem við munum nota. Ef nauðsyn krefur, er hægt að skipta út fyrir GPT. GPT diskar eru með samhæfnislag sem gerir MBR-samhæfðum kerfum kleift að sjá fyrstu 4 skiptingarnar ef þær eru staðsettar innan fyrstu 2 terabætanna. Aðalatriðið er að boot partition og bios_grub skipting á þessum diskum ætti að vera í byrjun. Þetta gerir þér jafnvel kleift að ræsa frá GPT Legacy/BIOS drifum.

En þetta er ekki okkar mál.

Hér munum við búa til tvo hluta. Sá fyrsti verður 1 GB að stærð og notaður fyrir RAID 1 /boot.

Sá síðari verður notaður fyrir RAID 6 og mun taka allt laust pláss sem eftir er nema lítið óúthlutað svæði í lok drifsins.

Hvað er þetta ómerkta svæði?Samkvæmt heimildum á netinu eru SATA SSD diskarnir okkar með virkt stækkanlegt SLC skyndiminni sem er á bilinu 6 til 78 gígabæta. Við fáum 6 gígabæta „ókeypis“ vegna munarins á „gígabætum“ og „gíbíbætum“ í gagnablaði drifsins. 72 gígabætunum sem eftir eru er úthlutað úr ónotuðu plássi.

Hér skal tekið fram að við erum með SLC skyndiminni og plássið er upptekið í 4 bita MLC ham. Sem fyrir okkur þýðir í raun að fyrir hver 4 gígabæta af lausu plássi munum við aðeins fá 1 gígabæt af SLC skyndiminni.

Margfaldaðu 72 gígabæt með 4 og fáðu 288 gígabæt. Þetta er laust plássið sem við munum ekki merkja út til að leyfa drifunum að nýta SLC skyndiminni að fullu.

Þannig munum við í raun fá allt að 312 gígabæta af SLC skyndiminni frá samtals sex drifum. Af öllum drifum verða 2 notaðir í RAID fyrir offramboð.

Þetta magn af skyndiminni gerir okkur afar sjaldan í raunveruleikanum kleift að lenda í aðstæðum þar sem skrif fara ekki í skyndiminni. Þetta bætir einstaklega vel upp sorglegasta galla QLC minnis - afar lágan skrifhraða þegar gögn eru skrifuð framhjá skyndiminni. Ef álagið þitt samsvarar ekki þessu, þá mæli ég með því að þú hugsir vel um hversu lengi SSD-inn þinn endist undir slíku álagi, að teknu tilliti til TBW frá gagnablaðinu.

#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

Að búa til fylki

Fyrst þurfum við að endurnefna vélina. Þetta er nauðsynlegt vegna þess að hýsilnafnið er hluti af fylkisnafninu einhvers staðar inni í mdadm og hefur einhvers staðar áhrif á eitthvað. Auðvitað er hægt að endurnefna fylki síðar, en þetta er óþarfa skref.

#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

Hvers vegna -gera ráð fyrir-hreint...?Til að forðast að frumstilla fylki. Fyrir bæði RAID stig 1 og 6 gildir þetta. Allt getur virkað án frumstillingar ef það er nýtt fylki. Þar að auki, að frumstilla SSD fylkið við stofnun er sóun á TBW auðlind. Við notum TRIM/DISCARD þar sem hægt er á samsettum SSD fylkjum til að „frumstilla“ þau.

Fyrir SSD fylki er RAID 1 DISCARD studd úr kassanum.

Fyrir SSD RAID 6 DISCARD fylki verður þú að virkja það í færibreytum kjarnaeiningarinnar.

Þetta ætti aðeins að gera ef allir SSD diskar sem notaðir eru í stigi 4/5/6 fylki í þessu kerfi hafa virka stuðning fyrir discard_zeroes_data. Stundum rekst maður á undarlega drif sem segja kjarnanum að þessi aðgerð sé studd, en í raun er hún ekki til staðar, eða aðgerðin virkar ekki alltaf. Í augnablikinu er stuðningur í boði nánast alls staðar, hins vegar eru gamlir drif og fastbúnaður með villum. Af þessum sökum er DISCARD stuðningur sjálfkrafa óvirkur fyrir RAID 6.

Athugið, eftirfarandi skipun mun eyða öllum gögnum á NVMe drifum með því að „frumstilla“ fylkið með „núllum“.

#blkdiscard /dev/md0

Ef eitthvað fer úrskeiðis, reyndu að tilgreina skref.

#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

Af hverju svona stór...?Að stækka klumpastærðina hefur jákvæð áhrif á hraða handahófskenndra lestrar í blokkum upp að klumpastærð meðtöldum. Þetta gerist vegna þess að hægt er að ljúka einni aðgerð af viðeigandi stærð eða minni að öllu leyti á einu tæki. Þess vegna er IOPS frá öllum tækjum tekin saman. Samkvæmt tölfræði fer 99% af IO ekki yfir 512K.

RAID 6 IOPS fyrir hverja skrif alltaf minna en eða jafnt og IOPS eins drifs. Þegar, sem handahófskennd aflestur, getur IOPS verið nokkrum sinnum stærra en einn drif, og hér skiptir blokkastærð höfuðmáli.
Höfundur sér ekki tilganginn í því að reyna að fínstilla færibreytu sem er slæm í RAID 6 by-hönnun og fínstilla þess í stað það sem RAID 6 er gott í.
Við munum bæta upp fyrir lélega tilviljunarkennd skrif á RAID 6 með NVMe skyndiminni og þunn-útvegun brellum.

Við höfum ekki enn virkjað DISCARD fyrir RAID 6. Þannig að við munum ekki „frumstilla“ þessa fylki í bili. Við gerum þetta síðar, eftir að stýrikerfið hefur verið sett upp.

SATA HDD

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

LVM á NVMe RAID

Fyrir hraða viljum við setja rótarskráarkerfið á NVMe RAID 1 sem er /dev/md0.
Hins vegar munum við enn þurfa þessa hröðu fylki fyrir aðrar þarfir, svo sem swap, lýsigögn og LVM-skyndiminni og LVM-þunn lýsigögn, þannig að við munum búa til LVM VG á þessu fylki.

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

Við skulum búa til skipting fyrir rót skráarkerfið.

#lvcreate -L 128G --name root root

Við skulum búa til skipting til að skipta í samræmi við stærð vinnsluminni.

#lvcreate -L 32G --name swap root

OS uppsetning

Alls höfum við allt sem þarf til að setja upp kerfið.

Ræstu kerfisuppsetningarhjálpina frá Ubuntu Live umhverfinu. Venjuleg uppsetning. Aðeins á því stigi að velja diska til uppsetningar þarftu að tilgreina eftirfarandi:

  • /dev/md1, - mount point /boot, FS - BTRFS
  • /dev/root/root (aka /dev/mapper/root-root), - festingarpunktur / (rót), FS - BTRFS
  • /dev/root/swap (aka /dev/mapper/root-swap), - nota sem skipta skipting
  • Settu upp ræsiforritið á /dev/sda

Þegar þú velur BTRFS sem rótarskráarkerfið mun uppsetningarforritið sjálfkrafa búa til tvö BTRFS bindi sem heita "@" fyrir / (rót) og "@home" fyrir /home.

Byrjum uppsetninguna...

Uppsetningunni lýkur með valmynd sem gefur til kynna villu í uppsetningu ræsiforritsins. Því miður muntu ekki geta farið úr þessum glugga með stöðluðum hætti og haldið uppsetningunni áfram. Við skráum okkur út úr kerfinu og inn aftur og endum á hreinu Ubuntu Live skjáborði. Opnaðu flugstöðina og aftur:

#sudo bash

Búðu til chroot umhverfi til að halda uppsetningunni áfram:

#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

Við skulum stilla netið og hýsingarheitið í chroot:

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

Förum inn í chroot umhverfið:

#chroot /mnt/chroot

Fyrst af öllu munum við afhenda pakkana:

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

Við skulum athuga og laga alla pakka sem voru settir upp skakkt vegna ófullkominnar kerfisuppsetningar:

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

Ef eitthvað gengur ekki upp gætirðu þurft að breyta /etc/apt/sources.list fyrst

Við skulum stilla breytur fyrir RAID 6 eininguna til að virkja TRIM/DISCARD:

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

Við skulum fínstilla fylkin okkar aðeins:

#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

Hvað var það..?Við höfum búið til sett af udev reglum sem gera eftirfarandi:

  • Stilltu stærð skyndiminni blokkar fyrir RAID 2020 til að vera fullnægjandi fyrir 6. Sjálfgefið gildi virðist ekki hafa breyst síðan Linux var stofnað og hefur ekki verið fullnægjandi í langan tíma.
  • Pantaðu lágmarks IO meðan á fylkisskoðun/samstillingu stendur. Þetta er til að koma í veg fyrir að fylkin þín festist í ástandi eilífrar samstillingar undir álagi.
  • Takmarkaðu hámarks IO við athugun/samstillingu fylkja. Þetta er nauðsynlegt svo að samstilling/athugun á SSD RAID steiki ekki diskana þína. Þetta á sérstaklega við um NVMe. (Manstu eftir ofninum? Ég var ekki að grínast.)
  • Bannaðu diskum að stöðva snúnings snúning (HDD) í gegnum APM og stilltu svefntíma fyrir diskastýringar á 7 klukkustundir. Þú getur algjörlega slökkt á APM ef diskarnir þínir geta það (-B 255). Með sjálfgefna gildinu munu drif hætta eftir fimm sekúndur. Þá vill stýrikerfið endurstilla diskinn skyndiminni, diskarnir snúast upp aftur og allt byrjar upp á nýtt. Diskar hafa takmarkaðan hámarksfjölda snúnings snúninga. Svo einföld sjálfgefna hringrás getur auðveldlega drepið diskana þína á nokkrum árum. Ekki eru allir diskar sem þjást af þessu, en okkar eru „fartölvur“, með viðeigandi sjálfgefna stillingum, sem láta RAID líta út eins og mini-MAID.
  • Settu upp readahead á diskum (snúningur) 1 megabæti - tvær blokkir í röð/klumpur RAID 6
  • Slökktu á readahead á fylkjunum sjálfum.

Við skulum breyta /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
Afhverju er það..?Við munum leita að /boot skiptingunni með UUID. Nafnefni fylkis gæti fræðilega breyst.

Við munum leita að þeim hlutum sem eftir eru eftir LVM nöfnum í /dev/mapper/vg-lv nótunum, vegna þess að þeir auðkenna skipting alveg einstaklega.

Við notum ekki UUID fyrir LVM vegna þess UUID LVM binda og skyndimyndir þeirra geta verið þau sömu.Tengja /dev/mapper/root-root.. tvisvar?Já. Einmitt. Eiginleiki BTRFS. Þetta skráarkerfi er hægt að setja upp nokkrum sinnum með mismunandi undirbólum.

Vegna þessa sama eiginleika mæli ég með að búa aldrei til LVM skyndimyndir af virkum BTRFS bindum. Þú gætir komið á óvart þegar þú endurræsir.

Við skulum endurskapa mdadm stillinguna:

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

Við skulum stilla LVM stillingarnar:

#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

Hvað var það..?Við höfum virkjað sjálfvirka stækkun LVM þunnra lauga þegar þeir hafa náð 90% af uppteknu plássi um 5% af rúmmálinu.

Við höfum aukið hámarksfjölda skyndiminniblokka fyrir LVM skyndiminni.

Við höfum komið í veg fyrir að LVM leiti að LVM bindi (PV) á:

  • tæki sem innihalda LVM skyndiminni (cdata)
  • tæki í skyndiminni með LVM skyndiminni, framhjá skyndiminni ( _corig). Í þessu tilviki verður skyndiminni sjálft enn skannað í gegnum skyndiminni (bara ).
  • tæki sem innihalda LVM skyndiminni lýsigögn (cmeta)
  • öll tæki í VG með nafnmyndum. Hér munum við hafa diskamyndir af sýndarvélum og við viljum ekki að LVM á gestgjafanum virki bindi sem tilheyra gestastýrikerfinu.
  • öll tæki í VG með nafninu öryggisafrit. Hér munum við hafa afrit af sýndarvélamyndum.
  • öll tæki sem endar á „gpv“ (gestastyrkur)

Við höfum virkjað DISCARD stuðning þegar losað er um laust pláss á LVM VG. Farðu varlega. Þetta mun gera það nokkuð tímafrekt að eyða LV á SSD. Þetta á sérstaklega við um SSD RAID 6. Hins vegar, samkvæmt áætluninni, munum við nota þunnt útvegun, svo þetta mun alls ekki hindra okkur.

Við skulum uppfæra initramfs myndina:

#update-initramfs -u -k all

Settu upp og stilltu grub:

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

Hvaða diska ættir þú að velja?Allir sem eru sd*. Kerfið verður að geta ræst úr hvaða SATA-drifi sem er eða SSD sem virkar.

Af hverju bættu þeir við os-prober..?Fyrir óhóflegt sjálfstæði og fjörugar hendur.

Það virkar ekki rétt ef eitt af RAID-tækjunum er í niðurbrotnu ástandi. Það reynir að leita að stýrikerfinu á skiptingum sem eru notuð í sýndarvélum sem keyra á þessum vélbúnaði.

Ef þú þarft það geturðu skilið það eftir, en hafðu í huga allt ofangreint. Ég mæli með að leita að uppskriftum til að losa sig við óþekkar hendur á netinu.

Með þessu höfum við lokið fyrstu uppsetningu. Það er kominn tími til að endurræsa í nýuppsett stýrikerfi. Ekki gleyma að fjarlægja ræsanlega Live CD/USB.

#exit
#reboot

Veldu einhvern af SATA SSD diskunum sem ræsibúnað.

LVM á SATA SSD

Á þessum tímapunkti höfum við nú þegar ræst inn í nýja stýrikerfið, stillt netið, apt, opnað flugstöðvarkeppinautinn og keyrt:

#sudo bash

Höldum áfram.

„Frumstilla“ fylkið frá SATA SSD:

#blkdiscard /dev/md2

Ef það virkar ekki, reyndu þá:

#blkdiscard --step 65536 /dev/md2
Búðu til LVM VG á SATA SSD:

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

Af hverju annað VG..?Reyndar erum við nú þegar með VG sem heitir root. Af hverju ekki að bæta öllu inn í eitt VG?

Ef það eru nokkrir PV í VG, þá verða allir PV að vera til staðar (á netinu) til að VG sé virkjað rétt. Undantekningin er LVM RAID, sem við notum vísvitandi ekki.

Við viljum virkilega að ef það verður bilun (les gagnatap) á einhverju RAID 6 fylki, þá ræsist stýrikerfið eðlilega og gefur okkur tækifæri til að leysa vandamálið.

Til að gera þetta, á fyrsta stigi abstraktsins munum við einangra hverja tegund af líkamlegum „miðlum“ í sérstakt VG.

Vísindalega séð tilheyra mismunandi RAID fylki mismunandi „áreiðanleikasviðum“. Þú ættir ekki að búa til fleiri algengan bilunarpunkt fyrir þá með því að troða þeim í eitt VG.

Tilvist LVM á „vélbúnaðar“ stigi mun gera okkur kleift að skera af geðþótta stykki af mismunandi RAID fylki með því að sameina þau á mismunandi vegu. Til dæmis - hlaupa samtímis bcache + LVM þunnt, bcache + BTRFS, LVM skyndiminni + LVM þunnt, flókin ZFS stillingar með skyndiminni, eða einhverja aðra helvítis blöndu til að reyna að bera þetta allt saman.

Á „vélbúnaðarstigi“ munum við ekki nota neitt annað en gamla góða „þykka“ LVM bindi. Undantekningin frá þessari reglu gæti verið varahlutinn.

Ég held að á þessari stundu hafi marga lesendur þegar farið að gruna eitthvað um varpdúkkuna.

LVM á SATA HDD

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

Nýtt VG aftur..?Við viljum virkilega að ef diskafylkingin sem við munum nota til að afrita gögn mistekst muni stýrikerfið okkar halda áfram að virka eðlilega á sama tíma og það hefur aðgang að gögnum sem ekki eru afrituð eins og venjulega. Þess vegna, til að forðast VG virkjunarvandamál, búum við til sérstakan VG.

Setja upp LVM skyndiminni

Við skulum búa til LV á NVMe RAID 1 til að nota það sem skyndiminni.

#lvcreate -L 70871154688B --name cache root

Af hverju er svona lítið...?Staðreyndin er sú að NVMe SSD diskarnir okkar eru líka með SLC skyndiminni. 4 gígabæt af „ókeypis“ og 18 gígabæta af krafti vegna laust pláss sem er upptekið í 3-bita MLC. Þegar þetta skyndiminni er uppurið verða NVMe SSD diskar ekki mikið hraðari en SATA SSD okkar með skyndiminni. Reyndar, af þessari ástæðu, er ekkert vit í því fyrir okkur að gera LVM skyndiminni skiptinguna miklu stærri en tvöfalt stærri en SLC skyndiminni NVMe drifsins. Fyrir NVMe drif sem notuð eru telur höfundur eðlilegt að búa til 32-64 gígabæta af skyndiminni.

Tilgreind skiptingarstærð er nauðsynleg til að skipuleggja 64 gígabæta af skyndiminni, skyndiminni lýsigögnum og öryggisafriti af lýsigögnum.

Að auki tek ég fram að eftir óhreina kerfislokun mun LVM merkja allt skyndiminni sem óhreint og mun samstilla aftur. Þar að auki verður þetta endurtekið í hvert sinn sem lvchange er notað á þessu tæki þar til kerfið er endurræst aftur. Þess vegna mæli ég með því að endurskapa skyndiminni strax með því að nota viðeigandi forskrift.

Við skulum búa til LV á SATA RAID 6 til að nota það sem skyndiminni tæki.

#lvcreate -L 3298543271936B --name cache data

Af hverju bara þrjú terabæt..?Svo að ef nauðsyn krefur geturðu notað SATA SSD RAID 6 fyrir aðrar þarfir. Stærð skyndiminni rýmisins er hægt að auka á kraftmikinn hátt, á flugu, án þess að stöðva kerfið. Til að gera þetta þarftu að stoppa tímabundið og virkja skyndiminni aftur, en sérstakur kostur LVM-skyndiminni umfram td bcache er að þetta er hægt að gera á flugu.

Búum til nýtt VG fyrir skyndiminni.

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

Við skulum búa til LV á skyndiminni tækinu.

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

Hér tókum við strax upp allt laust pláss á /dev/data/cache þannig að allar aðrar nauðsynlegar skiptingar voru búnar til strax á /dev/root/cache. Ef þú bjóst til eitthvað á röngum stað geturðu flutt það með pvmove.

Við skulum búa til og virkja skyndiminni:

#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

Af hverju svona chunksize..?Með hagnýtum tilraunum tókst höfundi að komast að því að bestur árangur næst ef stærð LVM skyndiminni blokkarinnar er í samræmi við stærð LVM þunnra blokkarinnar. Þar að auki, því minni sem stærðin er, því betri skilar uppsetningin sig í handahófskenndri upptöku.

64k er lágmarks blokkastærð sem leyfð er fyrir LVM þunnt.

Farðu varlega í skrifum..!Já. Þessi tegund af skyndiminni frestar samstillingu ritunar í skyndiminni tækið. Þetta þýðir að ef skyndiminni glatast gætirðu glatað gögnum í skyndiminni tækinu. Síðar mun höfundur segja þér hvaða ráðstafanir, auk NVMe RAID 1, er hægt að gera til að bæta upp fyrir þessa áhættu.

Þessi skyndiminnistegund var valin viljandi til að bæta upp fyrir lélegan handahófskennda skrifframmistöðu RAID 6.

Við skulum athuga hvað við fengum:

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

Aðeins [cachedata_corig] ætti að vera staðsett á /dev/data/cache. Ef eitthvað er að, notaðu þá pvmove.

Þú getur slökkt á skyndiminni ef þörf krefur með einni skipun:

#lvconvert -y --uncache cache/cachedata

Þetta er gert á netinu. LVM mun einfaldlega samstilla skyndiminni við diskinn, fjarlægja það og endurnefna cachedata_corig aftur í skyndiminni.

Að setja upp LVM þunnt

Við skulum áætla í grófum dráttum hversu mikið pláss við þurfum fyrir LVM þunn lýsigögn:

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

Round upp í 4 gígabæta: 4294967296B

Margfaldaðu með tveimur og bættu við 4194304B fyrir LVM PV lýsigögn: 8594128896B
Við skulum búa til sérstaka skiptingu á NVMe RAID 1 til að setja LVM þunn lýsigögn og öryggisafrit þeirra á það:

#lvcreate -L 8594128896B --name images root

Til hvers..?Hér gæti spurningin vaknað: hvers vegna að setja LVM þunn lýsigögn sérstaklega ef þau verða enn í skyndiminni á NVMe og munu virka hratt.

Þótt hraði skipti máli hér er það langt frá því að vera aðalástæðan. Málið er að skyndiminni er bilunarpunktur. Eitthvað gæti komið fyrir það og ef LVM þunn lýsigögn eru í skyndiminni mun það valda því að allt glatast algjörlega. Án fullkominna lýsigagna verður nánast ómögulegt að setja saman þunn bindi.

Með því að færa lýsigögnin í sérstakt bindi sem ekki er í skyndiminni, en hratt, tryggjum við öryggi lýsigagnanna ef skyndiminni tapast eða spillist. Í þessu tilviki verður allt tjón af völdum skyndiminnistaps staðbundið í þunnu bindi, sem mun einfalda endurheimtarferlið eftir stærðargráðum. Með miklum líkum verða þessar skemmdir endurheimtar með því að nota FS logs.

Þar að auki, ef skyndimynd af þunnu magni var áður tekin, og eftir það var skyndiminni að fullu samstillt að minnsta kosti einu sinni, þá, vegna innri hönnunar LVM þunnt, verður heilleiki skyndimyndarinnar tryggður ef skyndiminni tapast .

Búum til nýtt VG sem mun sjá um þynnkuveitingu:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Við skulum búa til sundlaug:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Hvers vegna -Z yTil viðbótar við það sem þessi háttur er í raun ætlaður fyrir - til að koma í veg fyrir að gögn frá einni sýndarvél leki yfir í aðra sýndarvél þegar plássi er endurdreift - er núllstilling að auki notuð til að auka hraða handahófskenndar skrifunar í blokkum sem eru minni en 64k. Sérhver skrif sem er minna en 64k á áður óúthlutað svæði þunnu bindisins verður 64K brún-jafnað í skyndiminni. Þetta gerir aðgerðina kleift að framkvæma algjörlega í gegnum skyndiminni, framhjá tækinu sem er í skyndiminni.

Við skulum færa LV í samsvarandi 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

Við skulum athuga:

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

Við skulum búa til þunnt bindi fyrir prófanir:

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

Við munum setja upp pakka fyrir prófanir og eftirlit:

#apt-get install sysstat fio

Svona geturðu fylgst með hegðun geymslustillingar okkar í rauntíma:

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

Svona getum við prófað stillingar okkar:

#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

Varlega! Úrræði!Þessi kóði mun keyra 36 mismunandi prófanir, hver í gangi í 4 sekúndur. Helmingur prófana er til upptöku. Þú getur tekið upp mikið á NVMe á 4 sekúndum. Allt að 3 gígabæt á sekúndu. Þannig að hver ritunarpróf getur borðað allt að 216 gígabæta af SSD auðlind frá þér.

Að lesa og skrifa í bland?Já. Það er skynsamlegt að keyra les- og skrifaprófin sérstaklega. Þar að auki er skynsamlegt að tryggja að öll skyndiminni séu samstillt þannig að áður gerð skrif hafi ekki áhrif á lesturinn.

Niðurstöðurnar verða mjög mismunandi við fyrstu ræsingu og síðari þegar skyndiminni og þunnt rúmmál fyllast, og einnig eftir því hvort kerfinu hafi tekist að samstilla skyndiminni sem fyllt var við síðustu ræsingu.

Ég mæli meðal annars með því að mæla hraðann á þegar fullþunnu magni sem mynd var tekin af. Höfundur hafði tækifæri til að fylgjast með því hvernig skrif af handahófi hraðast verulega strax eftir að fyrstu skyndimyndin var búin til, sérstaklega þegar skyndiminni er ekki enn fullkomlega fullt. Þetta gerist vegna afrita-í-skrifa skrifmerkingarfræði, röðun skyndiminni og þunnra bindiblokka, og þeirrar staðreyndar að handahófskennd skrif á RAID 6 breytist í handahófskenndan lestur frá RAID 6 fylgt eftir með ritun í skyndiminni. Í uppsetningu okkar er handahófskenndur lestur frá RAID 6 allt að 6 sinnum (fjöldi SATA SSD diska í fylkinu) hraðari en að skrifa. Vegna þess að kubbum fyrir CoW er úthlutað í röð úr þunnri laug, þá breytist upptakan að mestu leyti einnig í röð.

Báða þessa eiginleika er hægt að nota þér til hagsbóta.

Skyndiminni „samhangandi“ skyndimyndir

Til að draga úr hættu á gagnatapi ef skyndiminni skemmist/tapið, leggur höfundur til að innleiða þá venju að snúa skyndimyndum til að tryggja heilleika þeirra í þessu tilfelli.

Í fyrsta lagi, vegna þess að þunnt rúmmál lýsigögn eru á óafstaðinni tæki, verða lýsigögnin samkvæm og hugsanlegt tap verður einangrað innan gagnablokka.

Eftirfarandi snúningslotu skyndimynda tryggir heilleika gagnanna inni í skyndimyndunum ef skyndiminni tapast:

  1. Fyrir hvert þunnt bindi með nafninu <nafn> skaltu búa til skyndimynd með nafninu <nafn>.cached
  2. Við skulum stilla flutningsþröskuldinn á hæfilega hátt gildi: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
  3. Í lykkjunni athugum við fjölda óhreina blokka í skyndiminni: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' þangað til við fáum núll. Ef núllið vantar of lengi er hægt að búa það til með því að skipta skyndiminni tímabundið yfir í ritunarham. Hins vegar, að teknu tilliti til hraðaeiginleika SATA og NVMe SSD fylkanna okkar, sem og TBW auðlindar þeirra, muntu annaðhvort geta náð augnablikinu fljótt án þess að breyta skyndiminni, eða vélbúnaðurinn þinn mun alveg éta upp alla auðlind sína í nokkrir dagar. Vegna takmarkana á tilföngum getur kerfið í grundvallaratriðum ekki verið undir 100% skrifhleðslu allan tímann. NVMe SSD diskarnir okkar undir 100% skrifhleðslu munu tæma auðlindina alveg 3-4 dagar. SATA SSD diskar endast tvisvar sinnum lengur. Þess vegna munum við gera ráð fyrir að megnið af álaginu fari í lestur og við erum með tiltölulega stuttan tíma af mjög mikilli virkni ásamt lágu álagi að meðaltali til að skrifa.
  4. Um leið og við náðum (eða gerðum) núll, endurnefna við <name>.cached í <name>.committed. Gamla <nafn>.committed er eytt.
  5. Valfrjálst, ef skyndiminni er 100% fullt, er hægt að endurskapa það með handriti og hreinsa það þannig. Með hálftómu skyndiminni virkar kerfið mun hraðar þegar skrifað er.
  6. Stilltu flutningsþröskuldinn á núll: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Þetta kemur tímabundið í veg fyrir að skyndiminni samstillist við aðalmiðilinn.
  7. Við bíðum þar til töluvert mikið af breytingum safnast upp í skyndiminni #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' eða tímamælirinn slokknar.
  8. Við endurtökum aftur.

Hvers vegna erfiðleikar með fólksflutningaþröskuld...?Málið er að í raun og veru er „tilviljunarkennd“ upptaka í raun ekki alveg tilviljunarkennd. Ef við skrifuðum eitthvað í geira sem er 4 kílóbæti að stærð, þá eru miklar líkur á að á næstu mínútum verði skráning gerð í sama eða einn af nálægum (+- 32K) geirum.

Með því að stilla flutningsþröskuldinn á núll frestum við samstillingu skrifa á SATA SSD og tökum saman nokkrar breytingar á einum 64K blokk í skyndiminni. Þetta sparar verulega úrræði SATA SSD.

Hvar er kóðinn..?Því miður telur höfundurinn sig ekki nægilega hæfan í þróun bash-handrita vegna þess að hann er 100% sjálfmenntaður og stundar „google“-drifna þróun, þess vegna telur hann að hinn hræðilegi kóða sem kemur úr höndum hans ætti ekki að vera notaður af neinum Annar.

Ég held að sérfræðingar á þessu sviði geti sjálfstætt lýst allri rökfræðinni sem lýst er hér að ofan, ef þörf krefur, og jafnvel fallega hannað hana sem kerfisþjónustu, eins og höfundurinn reyndi að gera.

Svo einfalt skyndimynd snúningskerfi gerir okkur ekki aðeins kleift að vera stöðugt með eina skyndimynd að fullu samstillt á SATA SSD, heldur gerir okkur einnig kleift, með því að nota thin_delta tólið, að komast að því hvaða kubbum var breytt eftir að það var búið til og staðsetja þannig skemmdir á helstu bindi, mjög einfalda bata.

TRIM/FARGA í libvirt/KVM

Vegna þess að gagnageymslan verður notuð fyrir KVM sem keyrir libvirt, þá væri góð hugmynd að kenna tölvum okkar ekki bara að taka upp laust pláss heldur líka að losa um það sem ekki er lengur þörf á.

Þetta er gert með því að líkja eftir TRIM/DISCARD stuðningi á sýndardiska. Til að gera þetta þarftu að breyta stjórnunargerðinni í virtio-scsi og breyta 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>

Slík DISCARD frá gestastýrikerfi eru rétt unnin af LVM og blokkir eru losaðar á réttan hátt bæði í skyndiminni og í þunnu lauginni. Í okkar tilviki gerist þetta aðallega seint þegar næsta skyndimynd er eytt.

BTRFS öryggisafrit

Notaðu tilbúnar forskriftir með öfgafullt varúð og á eigin ábyrgð. Höfundur skrifaði þennan kóða sjálfur og eingöngu fyrir sjálfan sig. Ég er viss um að margir reyndir Linux notendur hafa svipuð verkfæri og það er engin þörf á að afrita einhver annar.

Við skulum búa til hljóðstyrk á öryggisafritunartækinu:

#lvcreate -L 256G --name backup backup

Við skulum forsníða það í BTRFS:

#mkfs.btrfs /dev/backup/backup

Við skulum búa til tengipunkta og festa rótarhluta skráarkerfisins:

#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

Við skulum búa til möppur fyrir afrit:

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

Við skulum búa til möppu fyrir varaforskriftir:

#mkdir /root/btrfs-backup

Við skulum afrita handritið:

Fullt af ógnvekjandi bash kóða. Notkun á eigin ábyrgð. Ekki skrifa reið bréf til höfundar...#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

Hvað gerir það meira að segja..?Inniheldur sett af einföldum skipunum til að búa til BTRFS skyndimyndir og afrita þær yfir á annan FS með því að nota BTRFS senda/móttaka.

Fyrsta kynningin getur verið tiltölulega löng, vegna þess að... Í upphafi verða öll gögn afrituð. Frekari kynningar verða mjög hraðar vegna þess að... Aðeins breytingar verða afritaðar.

Annað handrit sem við munum setja í cron:

Einhver fleiri bash kóða#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

Hvað gerir það..?Býr til og samstillir stigvaxandi skyndimyndir af skráðum BTRFS bindum á öryggisafritinu FS. Eftir þetta eyðir það öllum myndum sem voru búnar til fyrir 60 dögum síðan. Eftir ræsingu munu dagsettar skyndimyndir af skráðum bindum birtast í /backup/btrfs/back/remote/ undirmöppunum.

Við skulum gefa kóðans framkvæmdarréttindi:

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

Við skulum athuga það og setja það í cron:

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

LVM þunnt öryggisafrit

Við skulum búa til þunnt laug á öryggisafritunartækinu:

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

Við skulum setja upp ddrescue, því... forskriftir munu nota þetta tól:

#apt-get install gddrescue

Við skulum búa til möppu fyrir forskriftir:

#mkdir /root/lvm-thin-backup

Við skulum afrita forskriftirnar:

Mikið bash inni...#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

Hvað gerir það...?Inniheldur sett af skipunum til að vinna með þunnar skyndimyndir og samstilla muninn á milli tveggja þunna skyndimynda sem berast um thin_delta við annað blokkartæki með ddrescue og blkdiscard.

Annað handrit sem við munum setja í cron:

Aðeins meira 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

Hvað gerir það...?Notar fyrri skriftu til að búa til og samstilla afrit af þunnu bindi á listanum. Handritið mun skilja eftir óvirkar skyndimyndir af skráðum bindum, sem þarf til að fylgjast með breytingum frá síðustu samstillingu.

Þessu handriti verður að breyta og tilgreina lista yfir þunn bindi sem taka ætti öryggisafrit af. Nöfnin sem gefin eru eru eingöngu til skýringar. Ef þú vilt geturðu skrifað handrit sem mun samstilla öll bindi.

Gefum réttindin:

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

Við skulum athuga það og setja það í 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

Fyrsta kynningin verður löng, því... þunn bindi verða að fullu samstillt með því að afrita allt notað pláss. Þökk sé LVM þunn lýsigögn vitum við hvaða blokkir eru í raun í notkun, þannig að aðeins notaðir þunnt bindiblokkir verða afritaðir.

Síðari keyrslur munu afrita gögnin smám saman þökk sé breytingarakningu í gegnum LVM þunn lýsigögn.

Við skulum sjá hvað gerðist:

#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

Hvað hefur þetta með hreiðurdúkkur að gera?

Líklegast, í ljósi þess að LVM LV rökræn rúmmál geta verið LVM PV líkamleg rúmmál fyrir aðra VG. LVM getur verið endurkvæmt, eins og hreiðurdúkkur. Þetta gefur LVM mikinn sveigjanleika.

PS

Í næstu grein munum við reyna að nota nokkur svipuð farsímageymslukerfi/KVM sem grunn til að búa til landdreifðan geymslu/vm þyrping með offramboði í nokkrum heimsálfum með því að nota heimaskjáborð, heimanetið og P2P net.

Heimild: www.habr.com

Bæta við athugasemd