Rychlé úložiště pro virtualizaci

[CPU]

Mno kdyz je to iSCSI, tak to je blockdev, to muzes rovnou vysdilet procachovany hw raid (treba pres DM) a nemusis resit FS na strane toho uloziste jakoze vubec.

Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé.
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
Plus mi šlo o replikace a maximalizaci cache.
Pak tu jsou ty možnosti snapshootů a replikace na pozadí.

[Reklama]

[RDa]

Mno kdyz je to iSCSI, tak to je blockdev, to muzes rovnou vysdilet procachovany hw raid (treba pres DM) a nemusis resit FS na strane toho uloziste jakoze vubec.

Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé.
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
Plus mi šlo o replikace a maximalizaci cache.
Pak tu jsou ty možnosti snapshootů a replikace na pozadí.

Ano, proto jsem navrhoval tam vlozit jeste cache pres device mapper - jsou dva druhy, jedna umi cachovat jen cteni, druha i zapisy.

Snapshoty a replikace ci resizing jsou v dm/lvm ok, co je tusim vetsi nedoresenost je thin-provisioning, a prave ty qnap/synology tohle resi nejspise skrze FS ktery poskytuje sparse file support (pochybuji ze by to delali pres qcow2 format).

[CPU]

Nojo, ale jestli to není snazší přes to ZFS.

Všechno, co píšeš, dává smysl, ale aby to ve výsledku nebyla jen tako samodomo kopie ZFS.

ZFS umí slušně nakládat s RAM, podporuje L2ARC, solidní cache  a obecně, pokud bych se rozhodl přejít na HBA, cirkus nad tím zůstane. Mám standardní způsob replikací a prý by měly fungovat ZFS->QNAP replikace.

[pruzkumbojem]

trochu mi prijde, ze si budes vlastni Google bubble, vyhledavas podporu pro vlastni zamer. PLus zrejme chces mermomoci pouzit radic, co uz mas tak jako tak.

Porovnej rychlost te onboard 6 GB cache s tim planovanym 400GB L2ARC.., ocividne se to jen muze zpomalit? Pokud neni nedostatek RAM, jedina vyhoda L2ARC proti ARC je, ze to nezacina z nuly po restartu (a to jenom od nejake verze OpenZFS a nejsem si jist, zda je to zapnuto by default).

Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.

A udelej si ten A-B benchmark "za tim iSCSI"

citujes snad jediny  souhlasny nazor z veledlouhe diskuse

Martin Cracauer napsal:

ZFS will work just fine on the single block devices provided by the RAID controller.
As others have said, the important thing is how you notify yourself of disk breakages and how you manage disk replacements. If you are already comfortable with the support software for your controller that would be fine. Otherwise I would let FreeBSD do the mirrors.

https://forums.freebsd.org/threads/zfs-on-hardware-raid.84861/

Martin Cracauer se jako vývojář dost angažuje v ZFS:
https://www.cons.org/cracauer/
https://github.com/openzfs/zfs/issues/8396
https://medium.com/@MartinCracauer/stupid-zfs-tricks-expanding-zraid-79e716d41fad

Ale těch lidí je daleko víc, kteří tvrdí v podstatě to samé.
Tedy že na jedné straně se odřízneš od některých vychytávek, ale na straně druhé to je v podstatě v pohodě, pokud zajistíš výměnu selhávajícího HW a monitoring jinak.

[CPU]

Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS

To je zajímavá teze, takhle jsem na to nenahlížel. A nedokážu to v podstatě odmítnout. 

ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...

[Reklama]

[CPU]

V kazdem pripade pri tehle velikosti RAM uz L2ARC toho moc neprinese.

Pročetl jsem si dokumentaci k L2ARC.
Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.
Nově načtený blok se umístí na vrchol cache a poslední z ní vypadne. (Všechny se tam nevejdou že...)
Část těchto bloků je před zahozením vybrána, aby se jimi naplnila L2ARC. U L2ARC se očekává poměrně nízký poměr úspěšnosti, cokoliv na 25% je považováno za dobré. Doporučení pak jsou použít max. 512 GB NVMe a jeho kapacitu snížit na 460 GB, protože se určitě dřív nebo později zaplní a pak by mohl nastat poměrně intenzivní negativní dopad. (Úplně plná SSD se často chovají velmi divně.)

Nicméně doporučení ohledně L2ARC cache jsou taková, že její použití dává smysl jen když je opravdu hodně operační paměti a poměr úspěšnosti ARC je dost pod 90%. Jeden z důvodů je ten, že L2ARC stojí operační paměť (snižuje ARC) a L2ARC by se měla nacházet na rychlém NVMe disku.

Vyčetl jsem, že řada lidí L2ARC s dostatečně velkou RAM L2ARC skutečně vůbec nepoužívá, přesně jak říkal pruzkumbojem.

This isn't an exact parallel, but I have 256G of RAM in my E5-2637 V4 system and there are just short of 20 VM's (on separate ESXi server) on this NFS pool and this is what my ARC stats look like. I have an Optane SLOG and I debated using some of that for L2ARC, but I can't see a reason to do it. (ARC =>99)

Naopak disky Intel Optane jsou považovány za vhodné na SLOG.

[CPU]

Zajímavé pak jsou rychlosti ZFS vs EXT.

Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.
https://gist.github.com/saurabhnanda/6720c13fe02c4ffd950c80f41091e199

A nejsou to ojedinělé výkřiky do tmy...takových postů je dost. Tak velký rozdíl ve výkonu jsem skutečně nečekal.
U nějaké mini databáze to je asi fuk, ale nějaké hlavní databáze je potřeba přenastavit s ohledem na ZFS.

Důvod bude asi podobný jako u MySQL:
http://download.nust.na/pub6/mysql/tech-resources/articles/mysql-zfs.html

A je na to řešení (resp. dá se to vyřešit - změnit chování DB):
https://bun.uptrace.dev/postgres/tuning-zfs-aws-ebs.html#logbias
https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_zfs_best_practices.pdf
https://vadosware.io/post/everything-ive-seen-on-optimizing-postgres-on-zfs-on-linux/

Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4. 

[rokk42]

Pár poznámek k této diskuzi:

3x mirrorovaný SLOG

Zde bych upozornil na málo známý fakt že SLOG stačí jen o velikosti jednotek GB. Praktické maximum jsou 4GB. A SLOG sníži jen latenci, nezlepší propustnost a funguje jen u synchronních zápisů.

- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)

Hlavní problém je že přijdete o ochranu před bitflipem na disku. Pokud dojde k bitflipu tak HW raid to neumí detekovat a předá vadná data ZFS. A ZFS sice detekuje že jsou data poškozená ale když vidí jen hw raid tak nemůže ty data opravit.
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z

ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"

S tím většinou nemám problém. Ve většině případů se mi podaří vyladit ZFS že je rychlejší než ext4. Někdy i výrazně. Ale ano, je to alchymie s parametry modulu, parametry datasetu a případně způsobem vytvoření poolu a výsledek není jistý

p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.

Jo, special device to umí hodně zrychlit. Ale určitě bych se ho nebál. Trojitý mirror nemá smysl. V tomto případě když se řeší RAID5 odolný proti výpadku jednoho disku tak nemá smysl míd metadata odolná proti výpadku 2 disků. Provozuji i RAIDZ2 (odolný proti výpadku 2 disků) s metadaty v mirroru. Protože zfs umí od verze 2.0 sekvenční rebuild. Takže pokud by mi odešel jeden z SSD disků s metadaty tak se rebuild toho mirroru provede sekvenčně a tedy rychlostí SSD (450-500MB). Takže redundanci mám obnovenou za čtvrt hodiny. A většinou vím podle smartu včas že SSD odchází tak udělám dočasně mirror ze 3 disků a pak ten opotřebený odeberu.

Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.

L2ARC se hodí pokud víme velikost working setu se kterým se často pracuje. Pak můžeme dát tak velkou L2 cache aby se to do ní vešlo. Ale zase je to docela alchymie. L2ARC má své hlavičky v ARC. Takže když se dá neadekvátně velká L2 cache tak se významně sníží použitelná ARC cache a to může mít naopak negativní dopad na výkon.
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.

ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...

To je pravda, režie tam je a není úplně malá. Zase na druhou stranu zfs má integrovanou kompresi a například u DB se běžně dostávám na kompresní poměr větší než 2. To výrazně pomáhá. Zapíše se méně dat a kvůli tomu že data v ARC jsou komprimovaná tak se do ARC cache vejde víc logických dat což pomáhá při čtení.

Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.

Na tak úplně. ARC opět není jen ZFS cool název pro LRU. ARC cache algoritmus byl vyvinutý nezávisle na ZFS a ZFS ho jen jako jediné využilo. Hlavní rozdíl je že ARC je složeno z MRU (most recently used) a MFU (most frequently used) cache a interně vyvažuje poměr mezi těmito cachemi podle toho jaký mají hitrate. Tím že bere  úvahu i frekvenci použití tak dosahuje výrazně vyššího hitrate než cache v kernelu. Navíc kvůli tomu je scan resistent, ted jednorázové čtení nějakých jindy nevyužitých dat nezaplní ram zbytečnými daty a nesníží hitrate.

Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.

Například Lets Encrypt si svoji novou DB postavil na ZFS s 24xNVMe, 2TB RAM a 2x64c EPYC. a hodně si to tam chválí. A je tam i proklik do gitu kde mají tunning pro zfs i mysql který používají.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html

Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4.

Tohle je například tím že zfs má defaultní record_size 128kB a mysql má v inndob pagesize 8kB. Takže pokud vezmu defaultní nastavení zfs a rozjedu nad tím mysql tak bude amplifikace zápisu 16x. S něčím sice pomůže komprese ale i tak ten výkon bude tragický. Pokud ale snížím recordsize například na 16kB (sweet spot mezi malým recordsize které snižuje write amplification a velkým recordsize které zlepšuje kompresi) tak se při zapnuté kompresi dostanu na rychlosti jako má ext4 nebo lepší (samozřejmě existují patologické případy kdy je zfs pomalejší). Druhá věc je že například zfs umí atomicky modifikovat data až do velikosti record_size. Takže je bezpečné vypnout doublewrite v mysql protože se oproti ext4 nikdy nestane že by se z 8kB InnoDB stránky zapsala jen první polovina a druhá zůstala stará (například kvůli pádu serveru uprostřed zápisu).

[CPU]

Váš příspěvek lze označit jako maximálně přínosný!

[pruzkumbojem]

Jak jsem presel na 64-128 GB RAM, tak L2ARC uz nepozoruju zadny prinos.

RAIDZx jsem prestal pouzivat, straslive pomaly resilvering (a vubec zapisovy vykon).

kdyz udelam RAID10 nebo RAID20 (2x10), tak budu mit plus minus redundancy 2 a 4disky (jasne, se to muze strefit do paru). Mit v tomhle okamziku Metadata Special Device jen RAID1 mi prijde opravdu vyrazne slabe misto v porovnani s tim zbytkem. Bych si tipnul, ze spousta lidi to bude mit jako dve male NVME na jedne PCIe karte pres bifurging {protoze to nema smysl natlacit na SATA zarizeni, ktere je extra pomale u malych dat a soucasne ty PCIe sbernice nerostou na stromech) a to je opravdu Single point of failure.

Otazka je, zda to Metadata Special Device ma smysl v okamziku, kdy cely pool je ciste NVME, coz je jednoznacne budoucnost.

a nejvetsi prinos pro zapis je koupit bazarovy Mellanox se SFP28, vysledkem je write cache pro 5 sec x25Gb/s = nejakych 15GB nacpanych do pameti,  co rychlost site dovoli. S incrementalnimi backupy desktopu s NVME to dela zazraky.

Priorita ZFS vzdy bylo zajisteni dat, do OpenZFS 2.0+ se cpe hodne cool vykonostnich vylepseni (pro specialni scenare) a dle udalosti poslednihch dvou  tydnu mne to zacina desit.

Pár poznámek k této diskuzi:

3x mirrorovaný SLOG

Zde bych upozornil na málo známý fakt že SLOG stačí jen o velikosti jednotek GB. Praktické maximum jsou 4GB. A SLOG sníži jen latenci, nezlepší propustnost a funguje jen u synchronních zápisů.

- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)

Hlavní problém je že přijdete o ochranu před bitflipem na disku. Pokud dojde k bitflipu tak HW raid to neumí detekovat a předá vadná data ZFS. A ZFS sice detekuje že jsou data poškozená ale když vidí jen hw raid tak nemůže ty data opravit.
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z

ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"

S tím většinou nemám problém. Ve většině případů se mi podaří vyladit ZFS že je rychlejší než ext4. Někdy i výrazně. Ale ano, je to alchymie s parametry modulu, parametry datasetu a případně způsobem vytvoření poolu a výsledek není jistý

p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.

Jo, special device to umí hodně zrychlit. Ale určitě bych se ho nebál. Trojitý mirror nemá smysl. V tomto případě když se řeší RAID5 odolný proti výpadku jednoho disku tak nemá smysl míd metadata odolná proti výpadku 2 disků. Provozuji i RAIDZ2 (odolný proti výpadku 2 disků) s metadaty v mirroru. Protože zfs umí od verze 2.0 sekvenční rebuild. Takže pokud by mi odešel jeden z SSD disků s metadaty tak se rebuild toho mirroru provede sekvenčně a tedy rychlostí SSD (450-500MB). Takže redundanci mám obnovenou za čtvrt hodiny. A většinou vím podle smartu včas že SSD odchází tak udělám dočasně mirror ze 3 disků a pak ten opotřebený odeberu.

Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.

L2ARC se hodí pokud víme velikost working setu se kterým se často pracuje. Pak můžeme dát tak velkou L2 cache aby se to do ní vešlo. Ale zase je to docela alchymie. L2ARC má své hlavičky v ARC. Takže když se dá neadekvátně velká L2 cache tak se významně sníží použitelná ARC cache a to může mít naopak negativní dopad na výkon.
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.

ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...

To je pravda, režie tam je a není úplně malá. Zase na druhou stranu zfs má integrovanou kompresi a například u DB se běžně dostávám na kompresní poměr větší než 2. To výrazně pomáhá. Zapíše se méně dat a kvůli tomu že data v ARC jsou komprimovaná tak se do ARC cache vejde víc logických dat což pomáhá při čtení.

Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.

Na tak úplně. ARC opět není jen ZFS cool název pro LRU. ARC cache algoritmus byl vyvinutý nezávisle na ZFS a ZFS ho jen jako jediné využilo. Hlavní rozdíl je že ARC je složeno z MRU (most recently used) a MFU (most frequently used) cache a interně vyvažuje poměr mezi těmito cachemi podle toho jaký mají hitrate. Tím že bere  úvahu i frekvenci použití tak dosahuje výrazně vyššího hitrate než cache v kernelu. Navíc kvůli tomu je scan resistent, ted jednorázové čtení nějakých jindy nevyužitých dat nezaplní ram zbytečnými daty a nesníží hitrate.

Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.

Například Lets Encrypt si svoji novou DB postavil na ZFS s 24xNVMe, 2TB RAM a 2x64c EPYC. a hodně si to tam chválí. A je tam i proklik do gitu kde mají tunning pro zfs i mysql který používají.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html

Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4.

Tohle je například tím že zfs má defaultní record_size 128kB a mysql má v inndob pagesize 8kB. Takže pokud vezmu defaultní nastavení zfs a rozjedu nad tím mysql tak bude amplifikace zápisu 16x. S něčím sice pomůže komprese ale i tak ten výkon bude tragický. Pokud ale snížím recordsize například na 16kB (sweet spot mezi malým recordsize které snižuje write amplification a velkým recordsize které zlepšuje kompresi) tak se při zapnuté kompresi dostanu na rychlosti jako má ext4 nebo lepší (samozřejmě existují patologické případy kdy je zfs pomalejší). Druhá věc je že například zfs umí atomicky modifikovat data až do velikosti record_size. Takže je bezpečné vypnout doublewrite v mysql protože se oproti ext4 nikdy nestane že by se z 8kB InnoDB stránky zapsala jen první polovina a druhá zůstala stará (například kvůli pádu serveru uprostřed zápisu).

[František Ryšánek]

PMR/CMR "desktop grade" disk se 7200 ot/min dá nějakých 75 random IOps, a moc neškáluje při seřazení požadavků.

Enterprise disky (blahé paměti Seagate Cheetah, WD Raptor a další SCSI/SAS 10-15k RPM) uměly nativně tuším něco jako 150 random IOps, a při seřazení požadavků ještě trochu škálovaly (někam ke 300 IOps per spindle? už nevím).

Šindelové disky jsou zřejmě docela svinstvo - ale pravda je, že "enterprise šindelové" jsem v ruce nedržel, možná jsou trochu poladěné.

Pokud pod "chytrý" FS typu ZFS vložíte blokový HW RAID, oberete ZFS o část příležitostí k optimalizaci IOps, pokud Vám o toto jde. RAID5 je rychlý při čtení a sekvenčním zápisu, naopak při random zápisu umí být hnusně pomalý.

Před poměrně mnoha lety jsme prodávali nějaké DAS RAIDy, řekněme do 16 nebo 24 disků. (Mou oblíbenou značkou řadičů je dodnes Areca.) Bylo to v dobách, kdy se rozjela určitá skupina internetových služeb, kde hejno drobných sosačů v divokém internetu cucají každý svůj soubor, a cucají ho sice sekvenčně, ale relativně pomalu. V té době nebylo snadné najít/poskládat webový server, který by zařídil smysluplný read-ahead per soubor = aby se soubory (před)načítaly po blocích dostatečně velkých na to, aby se průchodnost v MBps blížila sekvenčnímu stropu jednotlivých disků i při worst-case IOps (zmíněných cca 75 pro levné nešindelové točivé disky). Zavelet to kernelu paušálně nešlo. Je na to odjakživa nějaké ioctl() na otevřený soubor, ale webservery si o to neuměly říct. Nevím, zda se situace v dnešní době někam pohnula. Každopádně mi tehdy tvrdil jeden odcházející zákazník, že jim tenhle problém vyřešilo právě ZFS.

Odbočím maličko od původního dotazu:

Nedávno jsem pro nenáročnou interní potřebu a vlastní potěchu/vzdělání řešil, jak navrstvit QEMU VM na hostitele (HV), ve kterém chci snapshoty, aspoň trochu komfortní SW RAID0, možnost expanze kapacity v HV a nějaké trochu úsporné ukládání QCOW images. Po relativně dlouhém bádání jsem to navrstvil takto:

Ve virtuálu Linux, virtio blokové zařízení mountuji s podporou discard
VM images podávám QEMU, se zapnutým mapováním discard na sparse file (QCOW image)
BTRFS subvolume pro každý virtuál, v něm jeden či více VM images, které k danému virtuálu patří
BTRFS s potlačeným COW (aby VM image přepisoval in-place, jenom při uloupnutí snapshotu na omezenou dobu jede COW)
MD RAID 1  (při expanzi kapacity bych musel přidat další MD RAID) - je to nakonec menší opruz, než BTRFS RAID
holé disky (JBOD) - nemám bohužel failure LEDky

Při kopírování VM images je potřeba dát pozor, aby se zachoval sparse charakter souborů. Jsou na to zaklínadla pro cp a dd. Toto najde využití při testování variantních změn konfigurace uvnitř VM, při hledání odkdy se vleče skryté poškození čehosi apod. Backup a restore sparse souborů umí například Borg. Snapshot se dělá nikoli z jednotlivého souboru "QCOW image", ale z BTRFS subvolume (jako prostý adresář, ale s touhle čarovnou schopností navíc). Je to způsob, jak zálohovat debilní VM, jehož obsah nedává smysl zálohovat nějak interně/nativně.

Má to vespod jenom dva disky na data (další dva v mirroru slouží čistě pro boot HV).
Když startuje jediný virtuál, je to pěkně svižné - ale kdyby jich startovalo deset simultánně (nikoli ze sdíleného systémového image), byla by to asi smutná podívaná. Padesát VM? Děsivá představa. Virtuály možná nejlíp startovat a típat naschvál sekvenčně. A to se bavím jenom o startu a vypnutí. Pokud virtuály potřebují nějaké nenulové nekešovatelné IOps ke svému životu, je to na točivých discích asi smuténka. Samozřejmě důsledně všechny oddíly mountuju s opšnou noatime.

Počítám, že to co jsem uplácal holýma rukama, by takový Proxmox mohl umět komfortně a bez namáčení.
A tohle vše nejspíš už zhruba 20 let jde postavit na DM volume manageru, jak už někdo zmínil přede mnou. Err... nevím jak passthrough pro "-o discard => sparse image" skrz QEMU, to je tuším relativní novinka.

Veliká cache (jedno na jaké vrstvě) má šanci pomoct pro čtená data, pokud se do ní vejdou. Pro write-back je přínos v podstatě maličký, protože v mixu zápisových operací se vyskytuje poměrně velké množství bariérových operací (seřazení) a dokonce tvrdých synců. Tuším na některých vrstvách lze zakázat bariérové operace (FS mount option? block device?), což Vám dá možnost naplnit celou RAMku write-back bufferem, ale přijdete tím o důležitou záruku konzistence dat na disku (pro případ pádu stroje) a nakonec pokud těch zápisových IOps je i tak v průměru prostě moc, tak po zaplnění cache začnou VM guesti drhnout i tak, bariéry nebariéry. Protože prostým seřazením operací velkého škálování nedosáhnete (otestováno) pokud zápisy přesně nenavazují.

Ten pokrok je stejně svinstvo. Za starých časů si študáci na hraní stavěli servery pro přístup přes telnet a IRC, kde vesele chatovalo třeba 200 lidí. Každý měl spotřebu pár desítek kB RAM. Dneska má člověk na hraní 50 virtuálů :-)

[František Ryšánek]

... Každopádně mi tehdy tvrdil jeden odcházející zákazník, že jim tenhle problém vyřešilo právě ZFS.

Pardon... už si nejsem jistej, jestli pomohlo ZFS, nebo spíš Solaris.

[František Ryšánek]

Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé.
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
...

Je na místě otázka, kterou implementaci iSCSI targetu jste na storage serveru použil. Vím zhruba o čtyřech. Asi nejstarší byl iSCSI Enterprise Target, modernější jsou STGT, SCST a LIO.
https://scst.sourceforge.net/scstvsstgt.html

Osobně jsem kdysi, v dobách svého obcování s RAIDem, testoval tuším SCST = to je ta věc, co žije v kernelu (bohužel navždycky mimo mainline). Hrotil jsem maximální průchodnost. Mírně se lišily varianty konfigurace "skrz blokovou cache" vs. "direct" (tuším nastojato předává SCSI příkazy z iSCSI skrz HBA připojenému SCSI target zařízení). Tušímže ve variantě "skrz blokovou cache" jsem dokázal vystropovat 10Gb Ethernet při přenosu do cache - ale jak se muselo sahat na fyzické zařízení, nevystropoval jsem ani sekvenční rychlost připojeného SAS RAIDu (tuším to dalo asi 3 Gbps max). A při variantě "direct" jsem vystropoval připojený SAS RAID (6 Gbps), ale zase jsem pochopitelně neměl k dispozici blokovou cache iSCSI serveru. Toto vše se zapnutými jumbo frejmy na přímém propoji 10Gb Eth client-server, síťové karty Myricom. Jak dlouho to může být... před 15 lety?

Pokud vím, ostatní implementace iSCSI žijí v user space.

Pokud otevřete v user space blokové zařízení jako soubor, máte možnost použít nebo nepoužít flag tuším O_DIRECT. Ten ovládá, zda se jede skrz blokovou cache nebo bez cache. Která varianta je rychlejší, to záleží na charakteru zátěže, typu a konfiguraci IO scheduleru, na výkonu CPU...

Ne že bych chtěl iSCSI nějak propagovat, nebo snad že bych s ním měl rozsáhlejší zkušenosti.

[RDa]

:
Pokud vím, ostatní implementace iSCSI žijí v user space.
:

LIO (LinuxIO) is the in-kernel iSCSI target (since Linux 2.6.38).
https://wiki.archlinux.org/title/ISCSI/LIO

[František Ryšánek]

Matně si vybavuju, že když LIO integrovali, tak mělo zhruba nejrozsáhlejší doprovodnou podporu / nejlepší dokumentaci managementu, integraci v ekosystému. Snadný start. Bolkhovitin s jeho SCST je bohužel mimo kernel, asi nepomáhalo že je Rus, a sice byl docela silný "pod kapotou" (výkon/features), ale management v user space neměl mnoho plyšáků.