Názory k článku Virtualizace pomocí bhyve s využitím ZFS na FreeBSD 13

Dík za hezký článek.

Ať se 14 podaří!

Jeste v alternativach chybi zminka o proxmox.

Proxmox ten je zastoupen KVM - https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment

Díky za pěkný článek. Od virtualizace se v dnešní době ale taky žádá například vysoká dostupnost, tak se těším na druhý díl, kde bude nějaký cluster popsán.

Ciste bhyve nic takoveho zatim neumi. Ovsem zajimava distribuce je CBSD - https://www.bsdstore.ru/en/broker_driven_sample_ssi.html

bhyve využívá i Oxide Computer v Propolis: https://github.com/oxidecomputer/propolis mluvili o tom v podcastu Oxide and Friends třeba zde: https://www.youtube.com/watch?v=eQR98smFYTc
Takže samotný bhyve to možná neumí, ale lze to tam dodat v nadstavbě/ pomocí dalších nástrojů.

ZFS neni dobry FS/RAID
1) Pokud se poskodi, coz se deje uplne bezne, nejde opravit, ani namountovat, je treba obnovit data ze zalohy - udajne se to nikdy nestane, ja to videl 3x - vzdy to melo pod sebou diskove pole, ktere zadnou chybu nemelo.
2) Nejde zvetsit Z-raid o dalsi disk - Oracle mi tvrdil, ze to neumi zadne enterprise diskove pole NAS - rak jsme jim rekl ze to umi NetApp a ze umi zvetit RG o dlsi diskm, ne jen aggr. o dalsi RG - nasledne me Oracle smazal - misto aby rekli, neumime to a neplanujeme - jenze mi se to sakra hodi.

Takze Z-pool je mozno rozsirit jen a pouze o dlasi Z-RAID - ale Z-raid nejde zvetsit o dalsi disky, coz se casto hodi, ze pridate treba jen 2 disky a rebalancujete.

3) Jeho deduplikace z ravost RAM je priserna a nepouzitelna na velke uloziste - prtiom treba prave NetApp s timhle nema problem, na spindlech to resi naslednym procesem a na full-flash to dela on deamand jako na ZFS - jen nesezere desitky az stovky GB RAM

A vyhody ZFS - no kopiruji wafl FS z NetAppu a tak celkem slusne funguje a ma v sobe FS i raid - coz treba BTRFS nema - ale neumi se zotavit z havarie a misto opravy je treba kompletni restore - coz je dost na h* - treba netapp mi data neztratil nikdy - spravoval jsme mnoho netappu s mnoha PT dat a statisice volum na ruznych netappech - ZFS se ke me dostalo prave kdyz me lidi zadali o pomoc, jak to rozjet - nikdy se to nepodarilo opravit - coz je pro me podstana vec, to uz bych potreboval asi replikaci, nez obnovovat mnoho TB ztracenych dat

"Oracle mi tvrdil"

Umi to emc/dell ... uplne bezne.

"ma v sobe FS i raid - coz treba BTRFS nema" ????

btrfs samozrejme raid ma.

BTRFS zadny raid nema ;-) ma jen mirror a vse ostatni experimentalni - nefunkcni, ale uz to pry jede, jen na opravu je treba mit medatadata na DUP a ne na raid, coz je pro me OK - ale i tak raid5/6 tam je experimentalni a nestabilni -> NEMA

Jste si jistý že běželo ZFS na ECC paměti, což je jedna z podmínek bezpečného provozu?

Netapp můžu někde volně stáhnout a provozovat?

Dal se stáhnout netapp simulátor/emulátor (nebo jak se to jmenovalo), ale ten se mi nikdy nepodařilo rozjet a co mi říkal kolega který ho rozjetý měl, bylo použitelné jen pro výuku.

Ano HPE server s Advanced ECC

A kde se da stahnout 30TB SSD disk ? volne ? a kde se da stahnout diskove pole ?
NetApp stoji pro full flash mene nez treba PureStorage - na ktery si muzete dat to nestabilni ZFS - ktere vam pak poskodi data ;-)

Zatimco NetApp uz je nativni NAS - umi i iscsi a FC, dokonce nove i ObjectStorage-S3

Cili diskove pole potrebuji VZDY - nebo nekomu muzu dat jbody z 3PAR ;-) - nebo si ja radeji kupte na ebay ;-)

Cili k cemu vam bude to ZFS kdyz nebudete mit disky, nebo diskove pole

Jo doma mam NAS s ECC a BTRFS nad nim SW-RAID - PC mam bez ECC a chci jej casem upgardovat na Theripper s ECC - nebot bezne desktopy ECC nepodporuji

Máme na ZFS několik PB dat a nikdy nic poškozeno.

Domnívám se tedy, že ten tvůj pláč, jak ZFS rozbijí data, bude spíše problémem mezi klávesnicí a židlí.

BTW: ECC podporují i nejlevnější Ryzeny bez GPU.

ZFS ECC nevyžaduje o nic míň ani víc než jiná FS. Viz značně výmluvný článek zde: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ Na konci je odkaz na komentář Matthew Ahrense: "There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS."

https://arstechnica.com/civis/threads/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux.1235679/page-4#post-26303271

BTRFS jsme videli na lopatkach nekolikrat.

ZFS pouzivame v produkci x let a prezilo to strasne pekla.

NetApp - jak pise kolega, kde se to da stahnout? :) -> porovnavate hrusky a jabka. Pokud tomu nerozumis/nemas lidi a mas prachy - kup si to jinak je za mne ZFS lepsi volba.

Nove BTRFS nikomu koho znam nikdy nespadlo, aspon ne tak, aby neslo opravit - jen tem, co tam meli RAID.

Ja provozuji BRTFS volummai v radech stovek TB a zadna nikdy nespadla, ano FC pole, LUN a jen nad nim data, metadata DUP - je to doprucovano kvuli opravam a data single, nebot RAID zajistuje diskove pole.

To moze byt aj tym, ze ma nepoznas. :-) Produkcne pouzivane ZFS, ale aj moje domace ulozisko si ziju svojim zivotom. Bez padov, alebo OOPSov ktore som zazival s btrfs. Ale dufam ze sa to zmeni. Btrfs by som rad videl aj u nas v produkcii.

1) ZFS chce vidět raw disky jako HBA právě ze zkušenosti vývojářů, že různé řadiče atd. mají tendenci různě zamlžovat či rovnou lhát. Můžete prosím popsat co nejlépe, jaký byl setup, který kompletně zničil data? Jen tak se z toho může někdo poučit. Jinak Váš komentář působí trochu jako FUD.

2) RAID-Z expanze je něco, na čem se pracuje: https://freebsdfoundation.org/blog/raid-z-expansion-feature-for-zfs/ a jsou k tomu PR: https://github.com/openzfs/zfs/pull/12225 a https://github.com/openzfs/zfs/pull/15022 Problém u toho je, že u CoW souborového systému obecně již zapsané bloky nechcete přesouvat, protože je to mnohem komplexnější než u souborového systému, který si vše řídí mutabilně. V ZFS proto řada věcí funguje až pro nově zapsaná data, což bude ten případ i zde, což využitelnost v praxi komplikuje.

Dá se předpokládát, že v 2.3 expanze RAID-Z asi bude, když je teď 2.2.0 venku. Jinak ale na spoustu věcí se prostě doporučuje spíše skousnout mirror/ RAID-10, nebo dělat malé RAID-Z. 3 disky pro RAID-Z1, 6 disků pro RAID-Z2: https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz a rozšiřovat po VDEVs.

3) Důležité je rozlišovat in-band a out-of-band deduplikaci. In-band deduplikace dat na ZFS není ideální a všichni to ví a zařizují se podle toho (používají ji jen lidi, kteří ví, co dělají a proč). Pracuje se na různých zlepšeních, ale pokud vím, tak to nebude hotové úplně hned. Out-of-band deduplikace do jisté míry lze dělat na ZFS dnes s verzí 2.2.0 pomocí "Block cloning": https://github.com/openzfs/zfs/releases/tag/zfs-2.2.0 v Linuxu tedy ZFS bude podporovat reflinky.
Offline/ Out-of-band deduplikace má výhodu, že nemusí celou tabulku hashů držet pořád v RAM, aby bylo vše dostatečně rychlé. Porovnáváte jablka s hruškami.

Zdá se, že máte zkušenosti z první ruky, proč prostě nenapíšete přesnější okolnosti, za kterých Vám ZFS ztratilo data? Dalo by se potom třeba nějak konstruktivně reagovat.

Do produkčního prostředí se zatím moc nehodí, chybí možnost snapshotu při spuštěném virtuálu. Pro každý snapshot je potřeba virtuál nejdříve vypnout.

To by mne zajimalo, japa se bez snapshotovani presune virtual (za behu) na jiny HW ... bez toho zadna virtualizace fungovat vubec nemuze, nedava to zadny smysl.

Souhlasím. Jaké by byly technické důvody k takovému omezení?

Nechteji resit dorovnavani casu?

Co tím konkrétně myslíš?

Viz můj komentář v jiném vlákně, parafrázuji:

Samotný bhyve virtualizaci času možná neumí/ neumí dostatečně pro live migraci out of the box, ale lze to tam dodat v nadstavbě/ pomocí dalších nástrojů.

bhyve např. využívá i Oxide Computer v Propolis: https://github.com/oxidecomputer/propolis mluvili o tom v podcastu Oxide and Friends třeba zde: https://www.youtube.com/watch?v=eQR98smFYTc
Zdá se mi, že zrovna live migraci VM budou asi mít vyřešenou dobře.

Problém bude nejspíše v tom, že bhyve neumí virtuál uspat aby mohl udělat pořádný obraz. On ten snapshot jde vynuceně udělat ale data pak nejsou úplně konzistentní a třeba v případě běžící DB aj.. je to problém.

A ted k Virtulizaci, ZFS neni clustered FS ze? - ale co si budem, on ani GFS2, ktery je clusterovaný, kazdy node ma svuj index neni zadne hype - dnes uz je to lepsi, ale byl celkem pomaly, ale na virt. celkem OK

Suma sumarum je pak skoro nejlepsi NFS - no a jsme u toho, jeden z nejlepsich NFS serveru/NAS je prave ten NetApp - a kdyz mate metrocluster, tak mate zajistenou i repliku do dalsiho DC o kterou se ani nemusite starat, nebot funguje sama a muzete pak nody rozhodit natvrdo mezi datacentry

Uz ti to tady rekli jini, michas jabka s hruskama.