Technomorous

V.D.O. (3)

Sdílet: Twitter - Facebook

Co se tedy může zvrtnout?

Ideální situace pro VDO je, že máte velké pole, které není ani náhodou plné a vy si ho pomocí VDO ještě zvětšíte. Z deseti terabajtů hardwarových máte dvanáct-třináct terabajtů virtuálních a je to v pohodě, protože na nich leží sotva pět terabajtů dat a uživatelé vám přisypou maximálně několik giga dat nových za den. Slunce svítí, kytičky kvetou, ptáčci zpívají, lepší to už ani být nemůže. Co se tedy může pokazit?

V zásadě jsou to dvě věci:

  1. Může dojít místo na virtuálním disku
  2. Může dojít místo na fyzickém disku

A co s nimi?

Došlo místo na virtuálním disku

Jinými slovy, komprimovalo a deduplikovalo se více, než jste čekali, df -h hlásí plno, ale pomocí vdostats vidíte, že ještě plno není. Tohle je ta jednodušší situace:

 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   12G  2.6G  8.6G  23% /mnt/looptest
 # cd /
 # umount /mnt/looptest
 # vdo growLogical --name=vdo1 --vdoLogicalSize=13G
 # e2fsck -f /dev/mapper/vdo1
 # resize2fs /dev/mapper/vdo1
 # mount /dev/mapper/vdo1 /mnt/looptest
 # cd /mnt/looptest
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  2.6G  9.5G  22% /mnt/looptest
 

I když na mém loopback device místo bylo, zvětšit jeho virtuální kapacitu o jeden gigabajt se zjevně povedlo. Pokud by snad na disk byla i nadále ukládána dobře komprimovatelná data, dá se to opakovat dál a dál.

Došlo místo na fyzickém disku

V tomto okamžiku slunce zašlo za mrak, kytičky spálil mráz a ptáčci chcípli. Když se pokusíte uložit něco na disk, jehož filesystém hlásí spoustu volného místa, ale fyzický disk vespod už žádné nemá, nastane peklo. Poslední operace zápisu selže, data se neuloží, vy se to ale na první pohled nedozvíte. Chyby se totiž objeví pouze v dmesg jako I/O error, disk se následně přepne do read-only režimu a končíte:

 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  5.6G  6.5G  47% /mnt/looptest
 
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      7.4G      0.6G  93%           37%
 
 # dd if=/dev/urandom of=grand-finale.bin bs=131072 count=8192
 8192+0 records in
 8192+0 records out
 1073741824 bytes (1.1 GB) copied, 5.31326 s, 202 MB/s
 
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  6.6G  5.5G  55% /mnt/looptest
 
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      8.0G      0.0G 100%           34%
 
 # dmesg | tail
 [93859.978067]	EXT4-fs warning (device dm-0): ext4_end_bio:302: 
 		I/O error -28 writing to inode 19 (offset 520093696
 		size 8364032 starting block 1750055)
 [93859.978071]	Buffer I/O error on device dm-0, logical block 1750055
 [93864.336428]	JBD2: Detected IO errors while flushing file data on dm-0-8
 [93864.339959]	Aborting journal on device dm-0-8.
 [93864.340463]	Buffer I/O error on dev dm-0, logical block 1606659,
 		lost sync page write
 [93864.340476]	JBD2: Error -5 detected when updating journal superblock
 		for dm-0-8.
 
 #mount | grep vdo1
 /dev/mapper/vdo1 on /mnt/looptest type ext4 (ro,relatime,data=ordered)
 

Pěkné, což? Ale co s tím?

V reálném světě byste přihodili další disk do RAID pole, na kterém máte data fyzicky uložená, počkali až se rebuildne a pak přes něj roztáhli VDO. V naší malé simulaci pomocí loopback device se to dá vyzkoušet taky. Nejdříve si zvětšíme "fyzické úložiště":

 # umount /mnt/looptest
 # vdo stop --name=vdo1
 # losetup -D
 # dd if=/dev/zero of=fakedisk2.img bs=131072 count=16384
 # cat fakedisk2.img >> fakedisk1.img
 # losetup -fP ./fakedisk1.img
 # lsblk
 NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
 loop0            7:0    0    10G  0 loop  
 

Disk je tedy větší, teď je třeba modifikovat VDO a následně ho rebuildnout:

 # vdo start --name=vdo1
 # vdo growPhysical --name=vdo1
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1         10.0G      8.0G      2.0G  80%           34%
 

A je to. VDO je zase použitelné, filesystém uvnitř žádnou změnu ani nezaznamenal, od počátku viděl kapacitu jinou. Jelikož ale poslední operace nedoběhla správně, je samozřejmě před připojením lepší udělat fsck.ext4. Vzhledem k žurnálovacímu filesystému byste neměli přijít o nic víc, než právě o poslední neúspěšný zápis.

-

Závěrem ještě dvě věci, které nutno specificky zmínit:

  • Virtuální zařízení založené na VDO se standardně chová jako SSD i když jde fyzicky o plotnový disk. Tedy při mazání nedochází k uvolňování místa, je zapotřebí pravidelně používat fstrim nebo - pokud používáte filesystém, který to umí sám rovnou - připojovat s parametrem discard.
  • Jde o původně proprietární technologii, kterou RedHat pořídil a otevřel světu. Udělal to relativně nedávno, takže jde zatím o doménu hlavně RHEL, CentOS a Fedory. Z distribucí, které zajímají mě (Slackware, Void, Devuan, Gentoo) jsem nějaké zmínky našel akorát u Gentoo, jak jsou na tom mainstreamové, morem a cholerou prolezlé distribuce, nevím.
PS: Asi tyto tři články časem spojím do jednoho a vydám na starém blogu.

Jméno
Web
E-Mail
Jsem stroj
Text komentáře

TOPlist