Mis seondub LVM-i ja matrjoškadega?

Tere!
Soovin jagada kogukonnaga praktilisi kogemusi KVM-i andmesalvestussüsteemi ülesehitamisest, kasutades md RAID + LVM-i.

Programmis on:

• md RAID 1 koostamine NVMe SSD-dest.
• md RAID 6 koostamine SATA SSD-dest ja tavalisest kettast.
• TRIM/DISCARD funktsiooni eripära SSD RAID 1/6-s.
• Käivitava md RAID 1/6 massiivi loomine üldiste ketaste kogumiga.
• Süsteemi installimine NVMe RAID 1-le ilma NVMe toe olemasoluta BIOS-is.
• LVM cache ja LVM thin kasutamine.
• BTRFS-i snapshotide ja send/receive kasutamine varukoopiate tegemiseks.
• LVM thin snapshotide ja thin_delta kasutamine BTRFS-i stiilis varukoopiate tegemiseks.

Kui see huvitab, palun vaata edasi.

Tõend

Autor ei vastuta selle artikli materjalide/näidete/koodi/nõuannete/andmete kasutamisest või mitte kasutamisest tulenevate tagajärgede eest. Lugedes või muul viisil seda materjali kasutades võtaksite enda kanda kõik nende tegevuste tagajärjed. Tagajärgedeks võivad olla:

• Küpsetatud krõbedaks NVMe SSD-d.
• SSD-mäluseadmest täielikult ammendatud kirjutamisressurss ja rikkeilmumine.
• Kogu andmete kaotus kõikidel salvestusseadmetel, sealhulgas varukoopiatel.
• Defektsed arvutitooted.
• Kulutatud aeg, närvid ja raha.
• Igasugused muud tagajärjed, mida ei ole ülal loetletud.

Riistvara

Olime omandanud:

Emaplaat, mis on toodetud kuskil 2013. aastal Z87 kiibistikuga koos Intel Core i7 / Haswell-iga.

• Protsessor 4 tuuma ja 8 vooga.
• 32 gigabaiti DDR3 RAM-i.
• 1 x 16 või 2 x 8 PCIe 3.0.
• 1 x 4 + 1 x 1 PCIe 2.0.
• 6 x 6 GBps SATA 3 pesad.

SAS-adapter LSI SAS9211-8I on uuendatud IT/HBA režiimi. RAID-toe tarkvara asendati tahtlikult HBA tarkvaraga, et:

1. Saaksin igal ajal selle adapteri välja vahetada ja asendada selle mingi muu esimese ettejuhtuva adapteriga.
2. TRIM/DISCARD töötas kettadel normaalselt, kuna RAID-tarkvaras ei toetata neid käske üldse, kuid HBA ei hooli, millised käsud bussil edastatakse.

Kõvakettad — 8 tk HGST Travelstar 7K1000, 1 TB suuruses 2.5-tollise vormitegija nagu sülearvutitel. Need kettad olid varem RAID 6 massiivis. Uues süsteemis on neil samuti kasutust, et salvestada lokaalseid varukoopiaid.

Lisaks soetati:

6 tk SATA SSD-d mudelist Samsung 860 QVO 2TB. Nendelt SSD-delt nõuti suurt mahtu, SLC vahemälu olemasolu, soovitav oli usaldusväärsus ja madal hind. Kohustuslik oli discard/zero toete olemasolu, mida kontrollitakse dmesg’i rida järgi:

kernel: ata1.00: Aktiveerimine discard_zeroes_data

2 tükki NVMe SSD mudelilt Samsung SSD 970 EVO 500GB.

Nende SSD-de jaoks on oluline juhuslike lugemise/kirjutamise kiirus ja ressurss teie vajadustele. Radiaator nende jaoks. Hädavajalik. Tõeliselt hädavajalik. Vastasel juhul — küpsetate need ära kohe RAID-sünkroonimise ajal.

StarTech PEX8M2E2 adapter 2 x NVMe SSD jaoks, mis paigaldatakse PCIe 3.0 8x pesasse. See on jälle lihtsalt HBA, aga NVMe jaoks. Erineb odavatest adapteritest PCIe bifurcation'i toe nõudmise puudumise tõttu emaplaadilt, tänu sisseehitatud PCIe lülitile. Töötab isegi kõige vanemas süsteemis, kus on PCIe, isegi kui see oleks x1 PCIe 1.0 pesa. Loomulikult vastava kiirusaga. RAID-e seal ei ole. Integratsiooni BIOS-i ei ole. Nii et teie süsteem ei õpi maagiliselt NVMe-lt käivituma ja kindlasti ei tee see NVMe RAID-i tänu sellele seadmele.

See komponent oli tingitud ainult ühest vabast 8x PCIe 3.0 pesast süsteemis ja kui oleks kaks vaba pesa, saaks selle hõlpsasti asendada kahe odava PEX4M2E1-ga või analoogidega, mida saab osta igalt poolt alates 600 rubla.

Erakäiguga loobuti igasugustest riistvaralistest või emaplaadi/BIOSe integreeritud RAID-idest, et oleks võimalik täielikult asendada kogu süsteem, välja arvatud SSD/HDD, säilitades kõik andmed. Ideaalis nii, et saaks isegi paigaldatud operatsioonisüsteemi säilitada uuele/teisele riistvarale ülemisel. Peamine, et oleks SATA ja PCIe portid. See on nagu live CD või käivitatav USB, vaid väga kiire ja veidi mahukas.

HuumorTeate, kuidas see vahel on — vahel tuleb kogu massiiv kiiresti kaasa võtta. Ja andmeid ei taha kaotada. Selleks on kõik mainitud kandjad mugavalt paigutatud 5.25 standardse korpuse sahtlitesse.

Ja muidugi katsetamiseks erinevate SSD vahemälu meetoditega Linuxis.

Riistvarased RAID-id on igavad. Lülitate sisse. See kas töötab või ei. Aga mdadm-iga on alati variandid.

Push-teated

Varem oli riistvaras paigaldatud Debian 8 Jessie, mis on peaaegu EOL. Koostati RAID 6 ülalmainitud HDD-de paarist LVM-iga. Sellel töötasid virtuaalmasinaid kvm/libvirt.

Kuna autoril on sobiv kogemus portatiivsete laadimis-SATA/NVMe mälupulkade loomiseks ning et mitte rikkuda tuttavat apt-malli, valiti sihtsüsteemiks Ubuntu 18.04, mis on juba piisavalt stabiilne, kuid omab siiski veel 3 aasta toetust.

Mainitud süsteemis on olemas kõik vajalikud riistvara draiverid kohe välja pakutud. Me ei vaja mingeid kolmandate osapoolte tarkvara ega draivereid.

Paigaldamise ettevalmistus

Süsteemi paigaldamiseks on meil vaja Ubuntu Desktop Images. Serveriversioonil on mingisugune tuumne paigaldaja, mis näitab liialt suurt iseseisvust, pannes UEFI süsteemiosa automaatselt ühte kandidaatide ketast, rikkudes kogu ilu. Seega installitakse see ainult UEFI režiimis. Alternatiive ei pakuta.

See meid ei rahulda.

Miks?Kahjuks on UEFI laadimine äärmiselt halvasti kooskõlas lauaarvuti tarkvaraliselt RAID-iga, kuna UEFI ESP jaotise jaoks ei pakuta mingit varundust. Internetis on retsepte, mis soovitavad paigutada ESP jaotise mälupulgale USB-porti, kuid see on rikkepunkt. On retsepte, mis kasutavad tarkvaralist mdadm RAID 1 versiooni 0.9 metaandmetega, mis ei takista UEFI BIOS-il seda jaotist nägemast, kuid see elab kuni õnneliku hetkeni, mil BIOS või mõni muu OS riistvaral kirjutab ESP-le, unustades sünhroniseerida teised peeglid.

Lisaks sõltub UEFI laadimine NVRAM-ist, mis ei liigu koos ketastega uude süsteemi, kuna see on osa emaplaadist.

Nii et me ei hakka uut jalgratast leiutama. Meil on juba valmis, aastate jooksul proovitud vanakooli jalgratas, mida tänapäeval tuntakse Legacy/BIOS käivitamisena, kuid selle uhke nimega CSM UEFI ühilduvates süsteemides. Me lihtsalt võtame selle riiulilt, määrime kokku, pumpame rehvid üles ja puhastame niiske lapiga.

Ubuntu töölauaversioon ei oska ka korralikult Legacy laadijaga paigalduda, kuid nagu öeldakse, siin on vähemalt valikud olemas.

Nii et kogume riistvara ja laadime süsteemi Ubuntu Live laadimismälupulgalt. Me peame pakette allalaadima, seega seadistame võrgu, mis teile tööle hakkab. Kui see ei toimi — vajalikud paketid saab eelnevalt mälupulgale laadida.

Siseneme töölauakeskkonda, käivitame terminali emulatori ja alustame:

#sudo bash

Kuidas…?Ülalolev rida on kanonisest vallandav tegur sudo vaidlustest. Alustame.ilotkaSuurem vastutusega kaasneb ka suurem vastutus. Küsimus on, kas suudate selle endale võtta. Paljud arvavad, et sudo kasutamine sellisel viisil on vähemalt ettevaatamatu. Kuid:ilotkaMiks mitte ZFS…?

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

Kui me installime tarkvara oma arvutisse, rendime põhimõtteliselt oma riistvara selle tarkvara arendajatele.Kui usaldame seda tarkvara oma andmete kaitsmiseks, võtame omale laenu, mis vastab nende andmete taastamise maksumusele, mille eest tuleb kunagi tasuda.
Sellest vaatenurgast on ZFS nagu Ferrari, kuid mdadm+lvm sarnaneb rohkem jalgrattaga.

Subjektiivselt eelistab autor laenata tundmatutele isikutele laenatud jalgratta, mitte Ferrarit. Seal on ka küsimus madalam hind. Pole vajadust õiguste järele. Lihtsam liiklusreeglite järgimine. Parkimine on tasuta. Läbivus on parem. Jalgrattale saab alati jalad külge panna ning tasuks jalgratast saab ka ise parandada.

Miks siis BTRFS…?

Käitusüsteemi laadimiseks vajame failisüsteemi, mis toetab Legacy/BIOS GRUB-i kastis ja samal ajal toetab elus snapshots. Kasutame seda /boot jagu jaoks. Lisaks eelistab autor kasutada seda failisüsteemi ka / (juurkataloog) jaoks, unustamata, et igasugusele muule tarkvarale võib luua eraldi lõike LVM-iga ja paigaldada need vajalikesse kataloogidesse.Ei pilte

, ei andmebaase me sellel failisüsteemil hoidma ei hakka. virtuaalmasinateSeda failisüsteemi kasutatakse ainult süsteemi hetkeseisude loomiseks ilma selle väljalülitamiseta ja nende hetkeseisude järgneks edastamiseks varukoopiaketale send/receive abil.
Lisaks eelistab autor hoida otse riistvaral minimaalset tarkvara ja käivitada kogu muu tarkvara virtuaalmasinates, kasutades selliseid lahendusi nagu GPU ja PCI-USB host-kontrollerite edastamine KVM-i kaudu IOMMU abil.

Riistvarale jääb ainult – andmete salvestamine, virtualiseerimine ja varundamine.

Kui usaldad rohkem ZFS-i, siis on põhimõtteliselt nende kasutamine sarnane.

Siiski, autor ignoreerib teadlikult ZFS-s, BTRFS-is ja LVM-is olemasolevaid peegeldamise / RAID ja üleliigsete funktsioone.

Siiski autor ignoreerib teadlikult ZFS, BRTFS ja LVM-i sisseehitatud peegeldamis- ja üleliigsuse funktsioone.

BTRFS-l on lisafunktsioon, mis muudab juhuslikud kirjutused järjestikusteks, mis omakorda parandab varundamise ja ülesvõtmise kiirus HDD-l.

Skaneerime kõik seadmed uuesti:

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

Uurime ümber:

#lsscsi && nvme list
[0:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] ketas ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] ketas ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] ketas ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] ketas ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] ketas ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] ketas ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] ketas ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] ketas ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] ketas ATA HGST HTS721010A9 A3J0 /dev/sdn
Sõlm SN Mudel Nimi Kasutamine Formaat 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


Diskide jaotamine

NVMe SSD

Me ei hakka neid kuidagi jaotama. Igal juhul ei jõua meie BIOS nende mäluseadmeteni. Nii et need lähevad täielikult tarkvara RAID-i. Isegi jaotusi me seal ei loo. Kui soovid „reetme” või „printsiibina” — loo üks suur jaotus nagu HDD-l.

SATA HDD

Siin ei ole eriliselt midagi välja mõelda. Loome ühe jaotuse kõigile. Jaotuse loome, sest need diskid on BIOSis nähtavad ja võivad isegi proovida süsteemi laadida. Hiljem paigaldame neist diskidest GRUB-i, et süsteem saaks ootamatult käima.

#cat >hdd.part << EOF
silt: dos
silt-id: 0x00000000
seade: /dev/sdg
üksus: sektorid

/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

Siin on meil kõige huvitavam.

Esiteks, meie mäluseadmed on suurusega 2 TB. See on MBR-i jaoks lubatud, mida me ka kasutame. Vajadusel võib asendada GPT-ks. GPT diskidel on ühilduvuskihid, mis võimaldavad MBR-ühilduvatel süsteemidel näha esimesi 4 jaotust, kui need asuvad esimeses 2 terabaidis. Peamine on, et alglaadimise jaotus ja bios_grub jaotus oleksid nende diskide alguses. See võimaldab isegi GPT diskilt Legacy/BIOS laadimist.

Kuid see ei ole meie juhtum.

Siin loome kaks jaotust. Esimene jaotus on suurusega 1 GB ja seda kasutatakse RAID 1 /boot-iks.

Teine jaotus kasutatakse RAID 6 jaoks ja hõivab kogu ülejäänud vaba ruumi, välja arvatud väike jaotamata ala, mis jääb seadme lõppu.

Mis on see jaotamata ala?Võrgus olevate allikate kohaselt on meie SATA SSD-del dünaamiliselt laiendatav SLC vahemälu suurusega 6 kuni 78 gigabaidi. 6 gigabaidi saame „tasuta” mäluseadme tehniliste andmete „gigabaitide” ja „gibibaitide” erinevuse tõttu. Ülejäänud 72 gigabaidi eraldatakse kasutamata ruumi tõttu.

Siinkohal on oluline märkida, et meil on SLC vahemälu, kuid ruum on hõivatud 4 bitti MLC režiimis. See tähendab, et iga 4 gigabaidi vaba ruumi puhul saame vaid 1 gigabaidi SLC vahemälu.

Korrutame 72 gigabaidi neljaga ja saame 288 gigabaidi. Just see on see vaba ruum, mida me ei hakka jaotama, et võimaldada mäluseadmetel täielikult kasutada SLC vahemälu.

Seega saame tõhusalt kuni 312 gigabaidi SLC vahemälu kuuest mäluseadmest. Kahest mäluseadmest kaks kasutatakse RAID-is üleliigsete elementide jaoks.

Selline kogus vahemälu võimaldab meil väga harva otsepraktikas kokku puutuda olukorraga, kus kirjutamine ei toimu vahemälus. See kompenseerib äärmiselt hästi kõige kurvemad QLC mälu puudused – äärmiselt madal kirjutamiskiirus, kui andmed kirjutatakse vahemälust mööda. Kui teie koormused sellele ei vasta, soovitan tõsiselt mõelda, kui kaua teie SSD-d sellise koormuse all töötavad, arvestades TBW tehnikaspetsifikatsioone.

#cat >ssd.part << EOF
silt: dos
silt-id: 0x00000000
seade: \/dev\/sda
üksus: sektorid

/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

Massiivide loomine

Alustuseks peame masina ümber nimetama. Seda on vaja, kuna hosti nimi on osa massiivi nimest, kuski mdadm sees, ja see mõjutab mingil määral. Massiive võib muidugi hiljem ümber nimetada, kuid see on liigsed toimingud.

#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

Miks –assume-clean…?Kuna massiivide initsialiseerimine ei ole vajalik. RAID 1 ja 6 tasemete puhul on see lubatud. Kõik võib töötada ka ilma initsialiseerimiseta, kui see on uus massiiv. Veelgi enam, SSD massiivi initsialiseerimine loomisel on TBW ressursi raiskamine. Me kasutame TRIM/DISCARD seal, kus võimalik, kokku pandud SSD massiivide „initsialiseerimiseks“.

SSD RAID 1 massiivide puhul on DISCARD kohe toetatud.

SSD RAID 6 massiivide puhul tuleb DISCARD seadistada tuuma mooduli parameetrites.

Seda tasub teha ainult siis, kui kõik SSD-d, mida kasutatakse tasemete 4/5/6 massiivides, toetavad discard_zeroes_data. Mõnikord satub kummalisi seadmeid, mis teatavad tuumale selle funktsiooni toimest, kuid tegelikkuses seda ei ole või funktsioon ei toimi alati. Praegu on tugi praktiliselt kõikjal olemas, kuid vanade seadmete ja vigaste püsivara puhul on siiski juhtumeid. Seetõttu on RAID 6 jaoks DISCARD vaikimisi välja lülitatud.

Tähelepanu, järgmine käsk hävitab kõik andmed NVMe mäluseadmetel, „initsialiseerides“ massiivi „nullideks“.

#blkdiscard /dev/md0

Kui midagi läks valesti, proovige näidata sammu.

#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

Miks nii suur…?Chunk-size suurendamine mõjutab positiivselt juhusliku lugemise kiiruseni chunk-size kaasaarvatud. See juhtub, kuna vastava suurusega või väiksema operatsiooni saab täielikult teostada ühes seadmes. Seetõttu summeeritakse kõikide seadmete IOPS. Statistika kohaselt ei ületa 99% IO-d 512K.

RAID 6 kirjutus-IOPS on alati vähem või võrdne ühe seadme IOPS-iga. Samas võib juhuslik lugemine olla mitu korda kõrgem kui ühel seadmel, ja siin on ploki suurus võtmetähtsusega.
Autor ei näe mõtet optimeerida parameetrit, mis on RAID 6 puhul algselt halb, ja selle asemel optimeerib ta seda, kus RAID 6 end hästi näitab.
Halba juhuslikku kirjutamist RAID 6 kompenseerime NVMe vahemäluga ja õhukese provisionimise trikkidega.

Me ei ole veel lubanud DISCARD RAID 6 jaoks. Seega ei hakka me seda massiivi "käivitama" praegu. Teeme seda hiljem, - pärast operatsioonisüsteemi installimist.

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-il

Kiirusest lähtuvalt soovime paigutada juur-FS NVMe RAID 1 peale, mille aadress on /dev/md0.
Kuid seda kiiret massiivi vajame veel muudeks vajadusteks, nagu vahetus, metaandmed ja LVM-vahemälu ning LVM-õhuke metaandmed, seetõttu loome sellel massiivil LVM VG.

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

Loome jaotuse juur-FS jaoks.

#lvcreate -L 128G --name root root

Loome vahetusjaotuse, mille suurus on sama, mis RAM-i.

#lvcreate -L 32G --name swap root

Operatsioonisüsteemi installimine

Kokkuvõttes on meil kõik vajalikud, et süsteemi installida.

Käivitame süsteemi installimisviisardi Ubuntu Live keskkonnast. Tavaline installatsioon. Ainult, et installimise ajal ketaste valimisel tuleb järgmist märkida:

• /dev/md1, — точка монтирования /boot, ФС — BTRFS
• /dev/root/root (a.k.a /dev/mapper/root-root), — точка монтирования / (корень), ФС — BTRFS
• /dev/root/swap (a.k.a /dev/mapper/root-swap), — использовать как раздел подкачки
• Käivitaja installige /dev/sda peale

Kui valitakse BTRFS juur-FS-ina, siis loob installija automaatselt kaks BTRFS-mahtu nimedega "@" juur (/)-le ja "@home" /home jaoks.

Käivitame installi…

Installimine lõpeb moodsa dialoogiboksiga, mis teavitab installimise käivitaja tõrkest. Kahjuks ei saa sellest dialoogist normaalselt lahkuda ja jätkata installimist. Logime süsteemist välja ja logime uuesti sisse, jõudes puhtale Ubuntu Live töölauale. Avame terminali ja uuesti:

#sudo bash

Loome chroot keskkonna, et jätkata installimist:

#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

Seame võrgu ja hostinime chrootis:

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

Siseneme chroot keskkonda:

#chroot /mnt/chroot

Esimese asjana installime paketid:

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

Kontrollime ja parandame kõik paketid, mis on valesti paigaldatud lõpetamata installimise tõttu:

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

Kui midagi läks valesti, võib tekkida vajadus enne seda muuta /etc/apt/sources.list:

Parandame RAID 6 mooduli seadeid TRIM/DISCARD lubamiseks:

#cat >/etc/modprobe.d/raid456.conf << EOF
valikud raid456 seadmed_käsitlema_hülgamine_turvaliselt=1
EOF

Veidi seadistame meie massiive:

#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

Mis see oli..?Oleme loonud набор udev reegleid, mis teevad järgmist:

• Seada 2020. aasta jaoks sobivat RAID 6 plokkide vahemälu suurust. T vaikimisi väärtus ei tundu olevat muutunud alates Linuxi loomise ajast ning ei ole juba pikka aega olnud sobiv.
• Reserveerige minimaalselt I/O-d, kui kontrollite/sünkroonite massiive. See on vajalik, et teie massiivid ei takerduks igavese sünkroniseerimise seisundisse koormuse all.
• Piirake maksimum I/O-d, kui kontrollite/sünkroonite massiive. See on vajalik, et SSD RAID-i sünkroniseerimine/kontroll ei kõrvetaks teie mäluseadmeid. See on eriti aktuaalne NVMe puhul. (Kas mäletate jahutusradiaatorit? Ma ei naljatanud.)
• Keelake APM-l kettadelt spindli peatumise lubamine (HDD) ja seadke kettade kontrollerite puhkuse ajaline piir 7 tunniks. Kui teie kettad seda toetavad, võite APM-i täiesti välja lülitada (-B 255). Vaikimisi peatavad kettad oma pöörlemise viie sekundi jooksul. Siis soovib operatsioonisüsteem kettaketti tühjendada, kettad hakkavad uuesti pöörlema ja kõik kordub. Kettadel on piiratud maksimaalne spindli pöörde arv. Selline lihtne tsükkel vaikimisi võib kergesti teie kettad mõne aasta jooksul ära tappa. Kõik kettad ei kannata seda, kuid meie
• Seadke pöörlevate ketaste readahead 1 megabaidiks — kaks järjestikust plokki/RAID 6 chunk.
• Keelake readahead ise massiivides.

Tegime muudatused /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
Miks nii..?Otsime /boot partitsiooni UUID järgi, kuna massiivide nimetused võivad teoreetiliselt muutuda.

Otsime ülejäänud partitsioone LVM nimede järgi kujul /dev/mapper/vg-lv, kuna need tuvastavad partitsioonid piisavalt unikaalselt.

Ärge kasutage UUID-d LVM jaoks, kuna LVM mahutite ja nende varukoopiate UUID-d võivad kattuda.Kas mäletame /dev/mapper/root-root'i kaks korda..?Jah. Just nii. BTRFS eripära. Seda failisüsteemi saab mountida mitu korda erinevate subvol'idega.

Selle sama eripära tõttu soovitan mitte luua LVM varukoopiaid aktiivsetest BTRFS mahutitest. Võite saada üllatuse pärast taaskäivitamist.

Genereerime mdadm konfiguratsiooni uuesti:

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

Korrigeerime LVM seadeid:

#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

Mis see oli..?Oleme lülitanud LVM thin basseinide automaatse laienemise sisse, kui kasutatud ruum ulatub 90% mahust, suurendades mahtu 5% võrra.

Oleme suurendanud LVM cache maksimaalset vahemälu plokkide arvu.

Oleme LVM-le keelanud otsimise LVM mahtude (PV) peale:

• seadmetes, mis sisaldavad LVM cache (cdata)
• seadmetes, mis on LVM cache'iga vahele lülitatud (<lv_name>_corig). Sellegipoolest skannitakse vahepeal kätkist seadet läbi vahecache'i (lihtsalt <lv_name>).
• seadmetes, mis sisaldavad LVM cache metainformatsiooni (cmeta)
• kõikides seadmetes VG, mille nimi on images. Siin on meil virtuaalmasinate diskipildid, ja me ei soovi, et LVM hostis aktiveeriks külalisoperatsioonisüsteemile kuuluvad mahud.
• kõikides seadmetes VG, mille nimi on backup. Siin on meil virtuaalmasinate piltide varukoopiad.
• kõikides seadmetes, mille nimi lõpeb sõnadega «gpv» (guest physical volume)

Oleme lülitanud DISCARD toetuse sisse, kui vabastame ruumi LVM VG-s. Olge ettevaatlik. See muudab LV eemaldamise SSD-l piisavalt ajaliseks. Eriti kehtib see SSD RAID 6 puhul. Kuid plaanis on kasutada thin provisioning'it, seega ei sega see meid üldse.

Uuendame initramfs'i pilti:

#update-initramfs -u -k all

Paigaldame ja konfigureerime grub'i:

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

Milliseid kettaid valida?Kõiki, mis on sd*. Süsteem peaks olema suuteline käivituma mis tahes töötavast SATA ketast või SSD-st.

Miks me os-prober'i kinni panime..?Liigne iseseisvus ja ulakad käed.

See ei tööta korralikult, kui üks RAID on degradatsioonis. See proovib otsida OS-i osadest, mida kasutatakse virtuaalmasinates, mis töötavad selle riistvara peal.

Kui see on teile vajalik, võite selle jätta, kuid pidage meeles kõiki eelnevalt loetletud asju. Soovitan otsida internetist retsepte, kuidas vabaneda ulakatest kätest.

Sellega lõpetasime algse installi. On aeg taaskäivitada äsja paigaldatud operatsioonisüsteemi. Ärge unustage eemaldada käivitatavat Live CD/USB-d.

#exit
#reboot

Käivitusseadmeks valime mis tahes SATA SSD.

LVM SATA SSD-l

Selleks ajaks oleme juba käivitanud uue operatsioonisüsteemi, seadistanud võrgu, apt, avanud terminali emulaatori ja käivitanud:

#sudo bash

Jätkame.

«Algatame» SATA SSD massiivi:

#blkdiscard /dev/md2

Kui ei toimi, siis proovime:

#blkdiscard --step 65536 /dev/md2
Loome LVM VG SATA SSD-l:

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

Miks veel üks VG..?Tõepoolest, meil on juba VG nimega root. Miks mitte lisada kõik ühte VG?

Kui VG-l on mitu PV-d, peavad kõik need PV-d olema kohal (veebis), et VG-d õigesti aktiveerida. Erandiks on LVM RAID, mida me sihikindlalt ei kasuta.

Tahame väga, et RAID 6 massiivi andmete kadumise (loe: andmete kaotuse) korral saaks operatsioonisüsteem sujuvalt käivituda ja annaks meile võimaluse probleem lahendada.

Selleks isoleerime me esimesel abstraktsioonitasemel iga füüsilise "kandja" tüübi eraldi VG-sse.

Teaduslikult öeldes kuuluvad erinevad RAID massiivid erinevatesse "usaldusdomäänidesse". Ei ole mõistlik luua neile täiendavat ühest rikekohta, koondades need ühte VG-sse.

LVM olemasolu "riistvaratasemel" võimaldab meil jagada erinevaid RAID massiive erinevalt ning neid kuju kombineerida. Näiteks - käivitada samal ajal bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, keeruline ZFS konfigureerimine vahemällu või mõni muu segane segu, et kõik see proovida ja võrrelda.

Riistvaratasemel ei kasuta me midagi muud kui häid ja vanu "paksu" LVM-volume. Erandiks reeglist võib olla varukoopia jagu.

Mõtlen, et selleks ajaks on paljud lugejad juba hakanud midagi kahtlustama matroška osas.

LVM SATA HDD-l

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

Jälle uus VG..?Tahame väga, et meie varukoopia andmeid sisaldava ketta massiivi rikke korral saaks meie operatsioonisüsteem jätkata sujuvalt töötamist, hoides samas ligipääsu mitte-varukoopia andmetele. Seetõttu, et vältida VG aktiveerimise probleeme, loome eraldi VG.

LVM vahemälu seadistamine

Loome LV NVMe RAID 1-l, et kasutada seda vahemälu seadmena.

#lvcreate -L 70871154688B --name cache root

Miks nii vähe…?Asi on selles, et meie NVMe SSD-del on samuti SLC vahemälu. 4 gigabaiti "tasuta" ja 18 gigabaiti dünaamiliselt vabastatud ruumi, mis on hõivatud 3-bit MLC. Pärast seda vahemälu ammendumist ei saa NVMe SSD-d palju kiiremini kui meie SATA SSD vahemäluga. Just sellepärast ei ole mõtet luua LVM vahemälu jagu märkimisväärselt suurem kui kaks korda NVMe salvestusseadmest SLC vahemälu maht. Kasutatavate NVMe salvestusseadmete puhul peab autor mõistlikuks luua 32-64 gigabaiti vahemälu.

Esitatud jagu on vajalik 64 gigabaiti vahemälu organiseerimiseks, vahemälude metateabe salvestamiseks ja metateabe varukoopia loomiseks.

Lisaks märgin, et pärast süsteemi ebaõiget väljalülitamist märgib LVM kogu vahemälu räpasena ja sünkroniseerib selle uuesti. Veelgi enam, see kordub iga kord, kui kasutate lvchange selle seadme peal kuni järgmise süsteemi taaskäivitamiseni. Seetõttu soovitan vahemälu kohe vastava skripti abil ümber luua.

Loome LV SATA RAID 6, et kasutada seda vahemäluna.

#lvcreate -L 3298543271936B --name cache data

Miks just kolm terabaiti?..Et vajadusel saaks kasutada SATA SSD RAID 6 teisteks vajadusteks. Vahemälu suurust saab dünaamiliselt suurendada, ilma et süsteem peatuks. Selleks on vajalik vahemälu ajutiselt peatada ja uuesti sisse lülitada, kuid LVM-cache'i eripära võrreldes näiteks bcache'iga on see, et seda saab teha ilma süsteemi seiskamata.

Loome uue VG vahemäluks.

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

Loome LV vahemäluseadmel.

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

Siin kasutasime kohe kogu vabast ruumist /dev/data/cache, et kõik muud vajalikud jaotised luuakse kohe /dev/root/cache. Kui teil on midagi valesti koha peal, saate selle pvmove abil ümber paigutada.

Loome ja aktiveerime vahemälu:

#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

Miks selline chunksize..?Praktiliste katsetuste käigus suudeti autoril välja selgitada, et parim tulemus saavutatakse, kui LVM cache ploki suurus vastab LVM thin ploki suurusele. Sel juhul, mida väiksem on suurus, seda paremini näitab konfiguratsioon juhusliku kirjutamise korral.

64k on minimaalne ploki suurus, mis on lubatud LVM thin jaoks.

Olge ettevaatlik writeback..!Jah. See vahemälu tüüp lükkab kirjutamise sünkroniseerimise vahemäluga seadmele. See tähendab, et kui vahemälu on kadunud, võib kaotada andmeid vahemälu seadmes. Hiljem räägib autor, millised meetmed, peale NVMe RAID 1, on võimalikud selle riski kompenseerimiseks.

See vahemälu tüüp on valitud teadlikult, et kompenseerida RAID 6 madalat tulemuslikkust juhusliku kirjutamise korral.

Kontrollime, mida oleme saavutanud:

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

/dev/data/cache peavad olema ainult [cachedata_corig]. Kui midagi on valesti, kasutage pvmove.

Vahemälu saab vajadusel ühe käsuga keelata:

#lvconvert -y --uncache cache/cachedata

See toimub reaalajas. LVM sünkroniseerib lihtsalt vahemälu kettale, eemaldab selle ja nimetab cachedata_corig uuesti cachedata'ks.

LVM thin seadistamine

Hinnanguliselt hindame, kui palju ruumi vajame LVM thin metadate jaoks:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 baitsi hinnanguline metaandmete piirkonna suurus "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

Ümardame 4 gigabaidini: 4294967296B

Korrutame kahega ja liidame 4194304B LVM PV metaandmete jaoks: 8594128896B
Loome eraldi jaotuse NVMe RAID 1-s, et paigaldada sinna LVM thin metaandmed ja nende varukoopia:

#lvcreate -L 8594128896B --name images root

Miks..?Siin võib tekkida küsimus, miks paigutada LVM thin metaandmed eraldi, kui need siiski vahemälus salvestatakse ja töötavad kiiresti.

Kiirus on küll oluline, kuid mitte peamine põhjus. Asi on selles, et vahemälu on rikke punkt. See võib rikke korral välja kukkuda ja kui LVM thin metaandmed on vahemälu salvestatud, toob see kaasa kogu kaotuse. Ilma täiuslike metaandmeteta on õhukeste mahtude taastamine praktiliselt võimatu.

Kandudes metaandmed eraldi, mitte vahemälusse, kuid kiiresse mahtu, tagame metaandmete turvalisuse, juhul kui vahemälu kaob või kahjustub. Sellisel juhul jäävad vahemälu kadumise tõttu tekkinud kahjustused õhukeste mahtude piiridesse, mis lihtsustab taastamisprotsessi oluliselt. Suure tõenäosusega saab neid kahjustusi taastada failisüsteemi logide abil.

Veelgi enam, kui varem on tehtud hetkepilt õhukesest mahust ja pärast seda on vahemälu vähemalt üks kord täielikult sünkroonitud, siis tänu LVM thin sisemistele tunnustele tagatakse hetkpildi terviklikkus vahemälu kadumise korral.

Loome uue VG, mis vastutab thin-provisioning'i eest:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Loome basseini:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Miks -Z yLisaks sellele, milleks see režiim on ette nähtud - ei lase andmetel ühest virtuaalsest masinast teise lekkida ruumi jaotamisel, kasutatakse nullimist ka juhuslike kirjutuste kiiruse suurendamiseks, kui plokkide suurus on väiksem kui 64k. Igany kirjutamine, mis on alla 64k varem mitte-eraldatud valdkonnas õhukeses mahus, muudetakse 64K-s, mis on joondatud vahemälu piiriga. See võimaldab täita operatsiooni täielikult vahemälu kaudu, mööda vahemälus välja antud seadmest.

Kandume LV vastavatesse PV-desse:

#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

Kontrollime:

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

Loome õhukese mahuti katsetamiseks:

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

Paigaldame paketid testimiseks ja jälgimiseks:

#apt-get install sysstat fio

Nii on võimalik jälgida meie salvestusseadmete konfiguratsiooni käitumist reaalajas:

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

Nii on võimalik meie konfiguratsiooni katsetada:

#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

Oht! Ressurss!See kood käivitab 36 erinevat testi, millest igaüks kestab 4 sekundi. Pool testidest on kirjutamiste testid. 4 sekundi jooksul saab NVMe-l kirjutada väga palju. Kuni 3 gigabitti sekundis. Seega võib iga kirjutamiste testide käivitamine kasutada teie SSD-st kuni 216 gigabaiti ressurssi.

Lugemine ja kirjutamine vaheldumisi?Jah. Lugemise ja kirjutamise testide käivitamine on mõttekas eraldi. Veelgi enam, on mõttekas veenduda, et kõik vahemälud on sünkroonitud, et eelneval kirjutamisel ei oleks lugemisele mõju.

Tulemused erinevad oluliselt esimesel käivitamisel ja edasistel, sõltuvalt vahemälude täitmisest ja õhukese keti täiuslikkusest, samuti sellest, kas süsteem on jõudnud sünkroonida eelnevalt täidetud vahemälud.

Lisaks soovitan mõõta kiirus juba täidetud õhukesel kettal, millelt just tehti snapshot. Autor on kogenud, et juhuslik kirjutamine kiireneb dramaatiliselt kohe pärast esimese snapshot'i loomist, eriti kui vahemälu pole veel täielikult täidetud. See toimub copy-on-write kirjutamise semantika tõttu, vahemälu ja õhukese keti plokkide joondumise tõttu ning selle tõttu, et juhuslik kirjutamine RAID 6-l muutub juhuslikuks lugemiseks koos hilisema kirjutamisega vahemällu. Meie konfiguratsioonis on juhuslik lugemine RAID 6-l kuni 6 korda (SATA SSD-de arv maatriksis) kiirem kui kirjutamine. Kuna CoW plokid eraldatakse järjestikku õhukesest reservist, muutub kirjutamine valdavalt järjestikuseks.

Mõlemat nendest omadustest saab soodsalt kasutada.

Vahemälu "koherentsete" snapshot'id

Andmete kaotsimineku riski vähendamiseks vahemälu kahjustumise/kaotuse korral soovitab autor rakendada snapshot'ide rotatsiooni praktikat, mis tagab nende terviklikkuse.

Esiteks, kuna õhukeste keti metaandmed asuvad mitte-vahemälus seadmes, on metaandmed terved ja võimalike kaotuste tagajärjed piirduvad andmeplokkidega.

Järgmine snapshot'ide rotatsiooni tsükkel tagab andmete terviklikkuse snapshot'ides, juhul kui vahemälu on kaotatud:

1. Igale õhukesele ketale nimega <имя> loome snapshot'i nimega <имя>.cached
2. Seame ülekande lävise mõistlikult kõrgele väärtusele: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. Tsüklis kontrollime vahemälu räpane plokkide arvu: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' kuni, kuni ei ole nulli, on võimalik ajutiselt luua see, muutes vahemälu writethrough režiimiks. Kuid arvestades meie SATA ja NVMe SSD-de kiirusomadusi ning nende TBW ressursse, suudate kas piisavalt kiiresti hetke tabada ilma vahemälu režiimi muutmata või teie riistvara kulutab oma ressursid mõne päevaga ära. Ressursipiirangute tõttu ei suuda süsteem põhimõtteliselt pidevalt olla 100% kirjutamise koormusel. Meie NVMe SSD-d kulutavad oma ressursid 100% kirjutamise koormuse all täielikult ära 3-4 päeva. SATA SSD-d elavad aga vaid kaks korda kauem. Seetõttu eeldame, et enamus koormusest on lugemine ja kirjutamine — suhteliselt lühiajalised kõrge aktiivsusega puhangud koos keskmise madala koormusega.
4. Niipea kui olete (või olete teinud) nulli — nimetage .cached ümber .committed. Eemaldame vana .committed.
5. Valikuliselt, kui vahemälu on 100% täis, saab selle skripti abil uuesti luua, puhastades sellega. Osaliselt tühja vahemäluga töötab süsteem kirjutamise osas palju kiiremini.
6. Seame migreerimise künnise nullile: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata See keelab ajutiselt vahemälu sünkroniseerimise põhikandjale.
7. Ootame, kuni vahemälus koguneb piisavalt muudatusi #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' või töötaks taimer.
8. Kordame uuesti.

Miks sellised raskused migreerimise künnisega…?Asi on selles, et reaalses praktikas ei ole "juhuslik" kirjutamine tegelikult päris juhuslik. Kui me kirjutame midagi 4 kilobaiti suurusesse sektorisse, on suur tõenäosus, et järgmise paari minuti jooksul tehakse kirjutamine sellesse või üheks naaber (+- 32K) sektoriks.

Seades migreerimise künnise nullile, lükkame SATA SSD-le kirjutamise sünkroniseerimise edasi ja kogume mitu muudatust ühe 64K ploki jaoks vahemälus. Nii säästame märgatavalt SATA SSD ressursse.

Aga koodi kuskil..?Kahjuks peab autor end bash-skriptide arendamisel ebakompetentseks, kuna on 100% isehakanud ja praktiseerib "google"-põhist arendust, seega arvab, et see hirmuäratav kood, mis tema käest välja tuleb, ei peaks keegi teine kasutama.

Arvan, et asja professionaalid saavad vajadusel kogu ülaltoodud loogika iseseisvalt luua ja võib-olla isegi ilusasti systemd teenuse vormis kujundada, nagu autor seda üritas.

Sarnane lihtne snapshotide rotatsiooni skeem võimaldab meil mitte ainult pidevalt omada ühte täielikult sünkroniseeritud SATA SSD snapshotit, vaid ka thanks utiliidi thin_delta kaudu teada saada, millised plokid on pärast selle loomist muutunud, ja seeläbi lokaliseerida kahjustusi peamistel mahtudel, muutes taastamise kordades lihtsamaks.

TRIM/DISCARD libvirt/KVM-s

Kuna andmete salvestamine kasutatakse KVM-i libvirt'i halduses, oleks hea õpetada meie VM-id mitte ainult tasuta ruumi võtmist, vaid ka vabastama enam mittevajalikku.

Seda tehakse TRIM/DISCARD toe simuleerimise kaudu virtuaalsetes diskides. Selleks tuleb muuda kontrolleri tüüp virtio-scsi-ks ja redigeerida 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'/>