Het grote ZFS topic

[Goudduif]

Momenteel heb ik juist mijn eerste nexenta ZFS storage systeem geconfigureerd,

Deze heb ik in een vSphere 5.1 waar ik 1 SSD, en 4 x 2TB hdd's in heb zitten.
Nexenta op de SDD, en het grootste gedeelte van deze schijf als cache ingericht.
Vervolgens heb ik de 4 hdd's met vmkfstools aan mijn Nexenta systeem toegewezen.

Hier ben ik ook best wel tevreden mee.

Nu wil ik echter wel regelmatig een backup van mijn draaiende config maken.
Wie kan mij vertellen hoe dit werkt, en hoe ik deze vervolgens naar een windows systeem weg kan schrijven.

Ik kon dit namelijk nog niet in de documentatie terug vinden.

[FireDrunk]

Welke configuratie? Die van ESX of van Nexenta?

[Goudduif]

Die van Nexenta, die van ESXi is namelijk niet zo belangrijk, als je bij je storage kan zijn de VM's zo weer toegevoegd.

[FireDrunk]

Welke configuratieinstellingen wil je bewaren? Netwerk? ZFS? Applicaties?

Want je kan de VM zelf natuurlijk backuppen?

[Goudduif]

Ja van de VM kan ik eenvoudig een backup maken.
Maar als de SDD vervangen moet worden, en ik plaatst de VM op de nieuwe SDD werkt alles dan ook weer zoals voorheen?

[FireDrunk]

Je kan ESXi zelf op een USB stick zetten, en de SSD als datastore gebruiken.
Mocht je de SSD willen vervangen, plaats je die er gewoon bij, shut de VM's, moven, registeren, starten.

Daarna unmount je de oude datastore, en kan je de oude SSD verwijderen.

[Goudduif]

ESX start vanaf een USB,
Vervolgens heb ik Nexenta op de SDD geinstalleerd, en nu gaat het er mij om, dat als de SDD uitvalt, mijn data wel veilig is.

EEn nieuwe SDD plaatsen en NExenta instaleren steld niet veel voor, maar hoe zet ik dan mijn ZFS config terug.

Nexenta mailt met regelmaat ook verschillende .gz files. Zit hier ook de config in verwerkt?

En als dit het geval is hoe zet ik die dan weer terug?

Ik wil dit namelijk helemaal uittesten, zodat ik zeker weet, dat mijn dat veilig is, en er voor zorgen dat mocht mijn SDD uitvallen, ik ook weet hoe alles werkt.

[FireDrunk]

ZFS heeft geen config, de ZFS kernel modules scannen gewoon de disks, en zien gelijk je pool weer zoals hij was bij de vorige installatie. Je moet hem misschien importeren (daadwerkelijk mounten), maar meer niet.

Qua config weet ik niet precies hoe Nexenta werkt, maar als jij het hebt over .gz files, zullen dat inderdaad de specifieke configs zijn van Nexenta qua Netwerk, iSCSI en dat soort dingen.

[u_nix_we_all]

Goudduif schreef op woensdag 17 oktober 2012 @ 13:56:
ESX start vanaf een USB,
Vervolgens heb ik Nexenta op de SDD geinstalleerd, en nu gaat het er mij om, dat als de SDD uitvalt, mijn data wel veilig is.

EEn nieuwe SDD plaatsen en NExenta instaleren steld niet veel voor, maar hoe zet ik dan mijn ZFS config terug.

Nexenta mailt met regelmaat ook verschillende .gz files. Zit hier ook de config in verwerkt?

En als dit het geval is hoe zet ik die dan weer terug?

Ik wil dit namelijk helemaal uittesten, zodat ik zeker weet, dat mijn dat veilig is, en er voor zorgen dat mocht mijn SDD uitvallen, ik ook weet hoe alles werkt.

Nexenta heeft een prima User Guide, hoofdstuk 22.4: Saving and restoring configurations. Verder weet ik niet of de Nexenta GUI iets van beadm ondersteund, anders kun je dat via de commandline altijd gebruiken om snapshots van je rootpool te maken, zo kun je altijd terug als je iets sloopt. Niet dat dat je helpt tegen hardware-uitval, maar wel makkelijker dan een restore als je een foutje maakt

[analog_]

zpool import <pool-name> en dan met -f geven omdat hij anders weigert omdat de pool nog bij een andere 'machine' hoort. Nette manier is hem op voorhand exporteren natuurlijk.

[ Voor 18% gewijzigd door analog_ op 17-10-2012 17:26 ]

[enormhi]

Ik ben op het moment bezig om een ZFS storage server te bouwen. Deze server zal gebruikt worden om elke dag ('s nachts) full systems backups te maken van een hoop linux servers (webhosting). Nu vroeg ik me af of ik voordeel zal hebben met het gebruik van SSDs om te cachen (ZIL?).

[huiser]

enormhi schreef op vrijdag 19 oktober 2012 @ 15:19:
Ik ben op het moment bezig om een ZFS storage server te bouwen. Deze server zal gebruikt worden om elke dag ('s nachts) full systems backups te maken van een hoop linux servers (webhosting). Nu vroeg ik me af of ik voordeel zal hebben met het gebruik van SSDs om te cachen (ZIL?).

Waarschijnlijk niet, aangezien backups meestal redelijk sequentieel geschreven worden.
Voor databases waarin veel (en door meerderde clients tegelijk) geschreven kan een ZIL zeker nuttig zijn.
Dus mocht je backup-software zijn catalog in een database hebben staan, dan kan een ZIL wel helpen.

[enormhi]

En als ik het goed begrepen heb is ARC/L2ARC totaal nutteloos in deze situatie?

[huiser]

enormhi schreef op vrijdag 19 oktober 2012 @ 17:02:
En als ik het goed begrepen heb is ARC/L2ARC totaal nutteloos in deze situatie?

L2ARC is alleen nuttig als je vaak dezelfde files benaderd. Deze worden dan in je L2ARC gecached.

[Verwijderd]

Wat een onzin, ARC (L2 zegt alleen iets over de plek waar het staat) is veel "slimmer" dan alleen "vaak gebruikte" files.

[Verwijderd]

Ik heb de startpost iets herschreven. Ook heb ik een tweetal builds toegevoegd, al stelt dat niet veel voor. Ik zoek een beetje naar feedback wat er nog meer in de startpost thuishoort. Ik had ooit een heel document, maar dat kan ik nu niet meer vinden.

Wat denken jullie? Hoe kunnen we de startpost pimpen? Ik dacht aan meer builds misschien met wat plaatjes en ook meer aandacht voor de ZFS platforms.

Ook wilde ik een apart topic voor FreeNAS en ZFSGuru, die best goed bij elkaar passen en wat druk van de ketel haalt in het ZFS topic, die daardoor minder wordt belast met vragen over ZFS derivaten. Wat denken jullie?

[ Voor 42% gewijzigd door Verwijderd op 20-10-2012 03:23 ]

[onox]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 03:21:
Ik heb de startpost iets herschreven. Ook heb ik een tweetal builds toegevoegd, al stelt dat niet veel voor. Ik zoek een beetje naar feedback wat er nog meer in de startpost thuishoort. Ik had ooit een heel document, maar dat kan ik nu niet meer vinden.

Wat denken jullie? Hoe kunnen we de startpost pimpen? Ik dacht aan meer builds misschien met wat plaatjes en ook meer aandacht voor de ZFS platforms.

Wat praktische info over gebruik van ZFS? Je kan wat vertellen over ashift en het gnop truckje voor FreeBSD en wat vertellen over toepassen van L2ARC en ZIL. (Volgens mij heb je in een post wel eens wat verteld over hoe je dan partities op een mirror van twee kleine SSD's zou moeten indelen)

[ Voor 3% gewijzigd door onox op 20-10-2012 04:03 ]

[FireDrunk]

Lijkt het je wel slim om FreeNAS en ZFSGuru uit het ZFS topic te halen? Ik denk dat de discussie dan een beetje doodbloed... over ZFS zelf hoef je niet veel te praten, en als je het doet, is het in de context van een OS als FreeNAS en ZFSguru...

[EnerQi]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 03:21:
Ik heb de startpost iets herschreven. Ook heb ik een tweetal builds toegevoegd, al stelt dat niet veel voor. Ik zoek een beetje naar feedback wat er nog meer in de startpost thuishoort. Ik had ooit een heel document, maar dat kan ik nu niet meer vinden.

Wat denken jullie? Hoe kunnen we de startpost pimpen? Ik dacht aan meer builds misschien met wat plaatjes en ook meer aandacht voor de ZFS platforms.

Krachtige ZFS NAS
Processor: Intel 3570 (geen K versie want deze ondersteunt geen vt-d instructies voor PCI passthrough)

Graag uitleg geven waarom je vt-d wilt gebruiken, ikzelf heb het niet . Uitleg geven over zfs native draaien en virtueel (daarom heb je vt-d nodig, schat ik).
En ik mis de case voor de krachtige ZFS Nas . 20 disks is lastig om in 1 case te krijgen / suggesties.

Ik moet Firedrunk hierin gelijk geven, de operating system uit het topic halen, zorgt ervoor dat het hier doodbloed.

[Verwijderd]

Nouja ik denk wel dat we iets moeten doen. Dus óf de ZFS platforms in de topicstart flink uitbreiden, óf deze een eigen topic geven.

Alles in één topic vind ik prima, echter ontvang ik soms wel klachten van mensen op NOS die ZFS wel interessant vinden maar al het geneuzel over ZFSguru misschien niet. Vergelijkbaar probleem is het Synology topic waar ook wordt gevraagd deze op te splitsen.

Verder hoop ik dat er mensen zijn die wat willen schrijven over FreeNAS en napp-it; twee platforms waar ik te weinig gebruikservaring mee heb om daar echt wat nuttigs over te zeggen behalve de grote hoofdlijnen. ZFSguru kan ik vanzelfsprekend genoeg over zeggen, maar het lijkt me beter als een meer neutraal iemand over FreeNAS en/of napp-it schrijft. Voelt iemand zich geroepen?

[EnerQi]

Wat valt er over ZFS te vertellen zonder in te gaan op de OS? Volgens mij is er niet meer zoveel ontwikkeling in ZFS toen Oracle het closed source probeert te maken. Ook werkt het erg stabiel dus weinig bugs

[Verwijderd]

Heel veel ZFS vragen zijn platform-onafhankelijk. Uitleg over RAID-Z, snapshots, zfs send/receive, 4K sector optimalisatie. Ik begrijp wel je punt; je vindt dat er te weinig overblijft in het ZFS topic als we de platforms eruit halen. Misschien ben ik het daar wel mee eens. We kunnen om te beginnen gewoon de startpost bijwerken en flink meer aandacht gaan geven aan de appliances (FreeNAS, ZFSguru, napp-it en Nexenta). Mocht dan blijken dat het een gekkenhuis wordt hier - net zoals in het Synology topic men van oordeel is - dan kunnen we altijd nog besluiten het topic te splitsen.

De topicstart zoals hij nu is, is wel een aardig begin. Maar ik mis veel meer praktische informatie waarmee nieuwelingen bijna alle informatie kunnen vinden die nodig is om hun eigen ZFS NAS te kunnen bouwen en configureren. How-to guides voor de ZFS platforms bijvoorbeeld, waar ik naar kan linken in de topicstart. Als jullie wat zoekwerk willen verrichten: heel graag.

[webfreakz.nl]

Misschien een idee om boodschappenlijsten in de TS te verwerken eventueel inclusief de performance die met een dergelijke build gehaald wordt?

[analog_]

Er kan een micro build met een mitx basis (HP NS40L ding?, c60+lianli q07) en een micro atx variant waarbij je simpelweg wat meer disks kwijt kan met een micro atx mobo bijvoorbeeld dat ding van mux op z'n blog. Laatste kan een super build zijn met 19" norco, xeon e3 bord met ipmi ofzo. Dan dek je alle formfactors, disk hoeveelheden en variaties in zuinigheid en functionaliteit wel af denk ik.

[iRReeL]

Ik zou ook nog iets zeggen over ECC, dat heeft toch nog altijd de voorkeur? Meeste AM3 systemen kunnen overweg met ECC (maar ik weet dan niet helemaal zeker of het optimaal benut wordt). Ik ben nu toch ook overgestapt op een Am3 X2 met ECC omdat ik de supermicro alleen als fileserver gebruik en dat is toch overkill.

Verder zou ik ook de suggestie van MUX's blog om een G530 met Asrock bordje te gebruiken vermelden, dan heb je een goedkope (en zuinige) oplossing voor 8 schijven. Ik begrijp die C60 support maar 3. Zelf heb ik nu dan 10 disks in de AM3 en wil dan nog een G530 systeem voor 6 disks.

Verwijzing of informatie naar geteste hardware voor ZFS lijkt me ook handig. Ik zal nog een verder moeten zoeken naar informatie, meeste links wat ik heb zijn tamelijk oud en niet echt updated

[analog_]

iRReeL schreef op zaterdag 20 oktober 2012 @ 19:33:
Ik zou ook nog iets zeggen over ECC, dat heeft toch nog altijd de voorkeur? Meeste AM3 systemen kunnen overweg met ECC (maar ik weet dan niet helemaal zeker of het optimaal benut wordt). Ik ben nu toch ook overgestapt op een Am3 X2 met ECC omdat ik de supermicro alleen als fileserver gebruik en dat is toch overkill.

Verder zou ik ook de suggestie van MUX's blog om een G530 met Asrock bordje te gebruiken vermelden, dan heb je een goedkope (en zuinige) oplossing voor 8 schijven. Ik begrijp die C60 support maar 3. Zelf heb ik nu dan 10 disks in de AM3 en wil dan nog een G530 systeem voor 6 disks.

Verwijzing of informatie naar geteste hardware voor ZFS lijkt me ook handig. Ik zal nog een verder moeten zoeken naar informatie, meeste links wat ik heb zijn tamelijk oud en niet echt updated

Ik weet niet of het al zinvol is om over de details te speculeren, eerst eens zien wat de rest ervan vind. Maar ik zou oppassen met het aanraden van hardware die volgens de spec niet zou werken en dan heb ik het over >8GB op c60, ecc op desktop chipsets. Overigens zijn er genoeg mitx borden met 6 poorten. Indien je meer wilt moet je eigenlijk vrij snel naar een uitbreidingskaart kijken aangezien er maar weinig mobos met meer dan 8 poorten zijn. Ik wil hiermee wel helpen om het periodiek bij te werken.

[Verwijderd]

Interessante reacties, keep it up!

@webfreakz: het is lastig om echt performance te voorspellen; maar je kunt wel een bandbreedte geven van 3 schijven in RAID-Z dus 150 - 300MB/s kun je verwachten, conservatief genomen omdat je ook de minimale STR moet meenemen op het einde van de capaciteit van de platters. Kortom, dit kan al gauw tot oneerlijke vergelijkingen leiden.

@analog_: dus je zegt doe drie builds, waarbij de eerste Mini-ITX is, de tweede Micro-ATX en de derde een supermicro build in 4U casing, zoiets? Het instapmodel voldoet aan de Mini-ITX form factor, dus die kan wel blijven bestaan. Dan zou er tussen de 'Krachtige ZFS NAS' en het instapmodel dus nog een 'medium' build moeten komen, met gewoon 10 disks in RAID-Z2 bijvoorbeeld? Is best een realistische build denk ik voor iemand die het iets serieuzer wilt aanpakken.

@iRReeL: het C60 bordje heeft zes maal SATA/600 plus nog PCI-express 2.0 x4 (fysiek x16). Dus je kunt er met een IBM M1015 HBA in totaal 8+6 = 14 schijven aansluiten, bjivoorbeeld 10-disk RAID-Z2 + nog wat SSDs. Dus dat bordje heeft flink veel uitbreidingsmogelijkheden, maar het nadeel is wel dat je weinig CPU performance hebt. Je zult dingen als polling moeten proberen om de CPU usage naar beneden te krijgen, zoals laatst nog ter discussie kwam.

[Durandal]

Ik ben mijn ZFS array aan het testen op linux (ZFS-on-Linux). Nu nog met 6xWD Red 3T in raidz2, morgen ga ik naar 10 disks.

code:

# raw disk speed WD Red 3TB
root@server2:/tank# hdparm -t /dev/sdf
/dev/sdf:
 Timing buffered disk reads: 460 MB in  3.01 seconds = 152.85 MB/sec


# 6 disk raidz2 pool WD Reds, best of 3 runs
# writing, nocache
root@server2:/tank# dd if=/dev/zero of=10G.dat oflag=nocache iflag=nocache bs=1M  count=10k
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 42.1751 s, 255 MB/s
root@server2:/tank# dd if=/dev/zero of=1G.dat oflag=nocache iflag=nocache bs=1M  count=1k
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.82348 s, 589 MB/s

# reading, nocache
root@server2:/tank# dd of=/dev/null if=10G.dat oflag=nocache iflag=nocache bs=1M  count=10k
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 32.9226 s, 326 MB/s
root@server2:/tank# dd of=/dev/null if=1G.dat oflag=nocache iflag=nocache bs=1M  count=1k
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.808394 s, 1.3 GB/s

Kan iemand wat zinnigs zeggen over de bereikte snelheden? Is dit goed of moet ik me zorgen maken?

[Verwijderd]

Dat de nocache flags niet werken. Je moet 8 keer je RAM testen minimaal. Met 8GiB RAM dus 64GiB test size:

# schrijven
dd if=/dev/zero of=64G.dat bs=1m count=64000

# lezen
dd if=64G.dat of=/dev/null bs=1m

[ Voor 3% gewijzigd door Verwijderd op 20-10-2012 20:33 ]

[Dadona]

iRReeL schreef op zaterdag 20 oktober 2012 @ 19:33:
Ik zou ook nog iets zeggen over ECC, dat heeft toch nog altijd de voorkeur? Meeste AM3 systemen kunnen overweg met ECC (maar ik weet dan niet helemaal zeker of het optimaal benut wordt). Ik ben nu toch ook overgestapt op een Am3 X2 met ECC omdat ik de supermicro alleen als fileserver gebruik en dat is toch overkill.

Mixed emotions... Het is vooral dat het de zaak echt afmaakt. Maar met ZFS is het aantal gevallen (als manieren waarop het probleem kan optreden) lager dan met andere filesystems.
In deze topic is gathering.tweakers.net/forum/list_messages/1452380?data[filter_keywords]=ecc al een aantal keren bij stilgestaan. Link toegevoegd omdat helaas momenteel de in-topic search niet meer zichtbaar is.
Persoonlijk neig ik nu naar een opstelling dat ik voor ECC ga als de alternatieve opstelling niet veel beter is op cruciale vlakken. Helaas betekent dat in de praktijk dat ik momenteel toch een non-ECC opstelling inzet voor de server, simpelweg omdat het verbruik van FreeBSD 9 nog altijd relatief hoog is en mijn non-ECC opstelling een stuk zuiniger is.

[ Voor 4% gewijzigd door Dadona op 20-10-2012 20:56 . Reden: Link even onklaar gemaakt omdat de BB code de URL sloopt. ]

[onox]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 20:33:
Dat de nocache flags niet werken. Je moet 8 keer je RAM testen minimaal. Met 8GiB RAM dus 64GiB test size:

# schrijven
dd if=/dev/zero of=64G.dat bs=1m count=64000

# lezen
dd if=64G.dat of=/dev/null bs=1m

Zet dit ook maar in de start post En er was ook laatst nog een post over hoe je checkt of je onrepareerbare sectors hebt (1 van de waarden in SMART zou dan omlaag gaan o.i.d. -- weet niet meer precies) waarbij je een bepaalde hoeveelheid data moest lezen ofzo.

Nog een handige link voor mensen die FreeBSD 9 ZFS in een MBR partitie willen installeren (zoals ik): http://bsdn00b.blogspot.nl/2012/03/freebsd-with-zfs.html

[ Voor 12% gewijzigd door onox op 20-10-2012 21:06 ]

[webfreakz.nl]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 20:11:
@webfreakz: het is lastig om echt performance te voorspellen; maar je kunt wel een bandbreedte geven van 3 schijven in RAID-Z dus 150 - 300MB/s kun je verwachten, conservatief genomen omdat je ook de minimale STR moet meenemen op het einde van de capaciteit van de platters. Kortom, dit kan al gauw tot oneerlijke vergelijkingen leiden.

Sure, maar als je 3 schijven op zo'n ASUS C60 (IIRC??) bordje gebruikt dan haal je maar 60MB/s met Samba omdat het een single threaded performance is en die CPU niet sneller kan. Dat soort statistieken vind ik interessant om te weten: "welke minimale build trekt een enkele 1GbE verbinding vol?". Eventueel kitlists met PicoPSU's e.d.....

[Verwijderd]

Dat Asus bordje kan waarschijnlijk ook gigabit voltrekken, maar dan moet je dus wel wat moeite doen. Ik weet even niet meer om wie het ging, maar diegene was bijna een hele core kwijt aan interrupts. Dat kun je met polling flink reduceren waardoor je ook veel dichter bij gigabit zou moeten kunnen komen. Maar het is inderdaad interessant om dit te vermelden. Echter bedenk wel dat dit één geval betreft waarbij ook de client zijde belangrijk is. Ik heb bij mij thuis vooral gemerkt dat Windows gigabit performance erg afhangt van de drivers. Dus een Intel NIC als Windows client kan ook van invloed zijn op de performance die je krijgt.

[Dadona]

Dat is sloth, bij een FTP transfer (en ik zat ook met dergelijke hoge waarden).

[webfreakz.nl]

CiPHER, ik denk als je gaat filteren op jouw posts in dit topic, dat je dan zelf genoeg informatieve posts vind, dus zet ze allemaal maar in de TS Je hebt er wel een hoop gemaakt die wel echt informatief waren, over ashift, het nut van ECC memory, 4k sectors, de M1015 controller, FreeBSD roadmaps, uitleg over TLER, pas nog een test met energieverbruik met verschillende geheugen timings (toch?), PicoPSU tests, en zo nog een aantal... Maargoed, ik ga ze niet opgraven in een topic van 186 pagina's

[ Voor 13% gewijzigd door webfreakz.nl op 21-10-2012 01:13 ]

[gitaarwerk]

Dat zie ik ook wel graag , webfreaks.nl

Gaarne ook gelijk over ZIL heb nu een extra SSD aangeschaft om het bestandssysteem een beetje te gaan optimalsieren (intel 330 120GB) ,.. zit nog even na te lezen met de caching.. ik heb helaas niet meer ruimte in mijn kast dan twee SSD's en er moet ook ergens nog VM's op geplaatst worden.

Vraag is of het dan L2ARC moet worden of de ZIL welke op de SSD moet komen.

startpost is erg goed geschreven overigens.

verder moet ik goed bekijken of het mogelijk is om de /var/www/ en db op de ZFS storage te plaatsen, en dan laat ik linux lekker voor wat het is op de SSD. Aangezien mijn server zowel een NAS als een webserver, router, firewall moet worden.

[ Voor 63% gewijzigd door gitaarwerk op 21-10-2012 11:21 ]

[FireDrunk]

@Dadona, wat heb je in FreeBSD gedaan om het zuinig te krijgen? Hier zit ik op 45W met 10 disks in standby... en 80W met 10 disks opgespint.

[DarkFire1985]

Al een tijdje ben ik mij aan het orienteren op de mogelijkheden van ZFS in mijn toekomstige server.

Op dit moment gebruik ik nog mijn huidige desktop / gamestation als server en ik schrok laatst van het stroomverbruik in idle.
Het systeem zal voor de volgende dingen worden gebruikt:
- Serveren van Full HD media files aan 1-3 clients (XBMC op Windows of XBian) in het netwerk.
- Server voor verschillende lokale (ontwikkel) websites (php / mysql)
- In de toekomst replicatie naar een offsite locatie
- Usenet downloads (SABnzbd, Sickbeard, Couchpotato, Headphones, AutoSub, MovieGrabber,Gamez)
- Remote desktop (bijvb mbv Chrome Remote Desktop)
Zoals je ziet de gebruikelijke dingen.

De onderdelen die hiervoor nodig zijn is (CPU is wellicht overkill maar dat vind ik wel prettig. De PSU heb ik gekozen vanwege de hoge zuinigheid)

#	Product	Prijs	Subtotaal
1	Intel Core i3 3220 Boxed	€ 109,45	€ 109,45
1	MSI H77MA-G43	€ 69,10	€ 69,10
1	be quiet! Straight Power E9 400W	€ 64,99	€ 64,99
Bekijk collectie Importeer producten		Totaal	€ 243,54

Geheugen heb ik nog en de kast wordt mijn huidige MountainMod U2-UFO, deze bouw ik om tot duality.
Voor de opslag heb ik 5 x 2 TB Samsung F4 in gebruik en het wordt een ZFS-on-root systeem. Voor raid-z is 5 disks prima, voor raid-z2 zou 6 beter zijn. In dat geval koop ik er nog 1 bij.

Ik ben er op dit moment nog niet uit of ik ga voor raid-z of raid-z2.
De volgende vragen heb ik in dat kader:
- een vdev kan je niet uitbreiden met losse disks, een vpool kan je wel uitbreiden met vdev's.
Wat zijn de eisen van deze vdev's? Moeten die hetzelfde aantal disks hebben als de overige in de vpool?
In het geval dat ik een raid-z2 van 6 disks maak en ik wil later uitbreiden, moet ik dan weer 6 disks in 1 keer erbij plaatsen (of degraded met 5 of 4 disks)?
- Is het het beste om een SSD direct vanaf het begin erbij te halen voor de cache etc. of is het geen verschil bij het later toevoegen?
- Welk OS is aan te raden voor deze doeleinden en biedt mij ook nog de mogelijkheid tot het draaien van desktop apps als skype? Ik lees dat FreeNAS nogal lastig kan zijn bij alles buiten het NAS-gedeelte.
Ik denk zelf dat ZFSguru ruim voldoet in mijn vraag maar deze klinkt nogal beta, is het wel stabiel genoeg?

[Dadona]

FireDrunk, het is hierin cruciaal welke hardware je inzet. Ik heb nu diverse opstellingen geprobeerd en vooral de Intel kant lijkt het nog wel aardig te doen, maar bij AMD valt het toch tegen. Ik heb het idee dat dit komt omdat de IGP voluit actief blijft.
Momenteel draai ik de meest recente versie van ZFSguru out of the box. Ik heb al eens wat lopen rommelen in FreeBSD, waaronder het activeren dat de monitor echt uitging, maar de winst was uiterst beperkt.

Met 10 schijven in standby en dan 45W halen mee lijkt te vallen. Ik weet niet direct of ik daar ook kan komen, het zou best kunnen, maar het punt voor mij is dat het verbruik in vergelijking met andere besturingssystemen hoger ligt. Dit kan soms zelfs zo dramatisch zijn dat ESXi met powersaving geactiveerd nog lagere waarden weet neer te zetten dan FreeBSD / ZFSguru. (In dat geval ging het overigens wel over een Intel opstelling, maar dan wel een Supermicro + Xeon combinatie.)

[FireDrunk]

Ik heb powerd zelf ingesteld, dat heeft volgens mij wel een hoop geholpen:

Config:
i5-3550 op een Intel Q77MK bord, 16GB geheugen, een M1015 controller en 10*2TB disks.

powerd:

##Poll state every 5 seconds
powerd_options="-a adaptive -i 60 -r 95 -n adaptive -m 1600 -M 3300 -p 5000"

#Enable C3-Saving
performance_cx_lowest="C3"
adaptive_cx_lowest="C3"
economy_cx_lowest="C3"

[80000]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 17:24:
Nouja ik denk wel dat we iets moeten doen. Dus óf de ZFS platforms in de topicstart flink uitbreiden, óf deze een eigen topic geven.

Alles in één topic vind ik prima, echter ontvang ik soms wel klachten van mensen op NOS die ZFS wel interessant vinden maar al het geneuzel over ZFSguru misschien niet. Vergelijkbaar probleem is het Synology topic waar ook wordt gevraagd deze op te splitsen.

Verder hoop ik dat er mensen zijn die wat willen schrijven over FreeNAS en napp-it; twee platforms waar ik te weinig gebruikservaring mee heb om daar echt wat nuttigs over te zeggen behalve de grote hoofdlijnen. ZFSguru kan ik vanzelfsprekend genoeg over zeggen, maar het lijkt me beter als een meer neutraal iemand over FreeNAS en/of napp-it schrijft. Voelt iemand zich geroepen?

Mijn centen: Dankzij enkele topics op tweakers, onder andere deze (dank CIPHER!), heb ik nu sinds een maand een ESXi server, met daarin een VM die als SAN fungeert, welke ZFS als filesysteem heeft.
Echter heb ik niet de ZFSGuru route gevolgt, maar de Openindiana + napp-it route. Het geheel draait stabiel en vraagt nauwelijks onderhoud.

Ik volg dit topic nog wel, maar zijdelings aangezien het inderdaad grotendeels over ZFSguru gaat en napp-it mijn onderhoud vraagstukken ondervangt. Tevens laat napp-it, de zfs command zien, zodat je leert dit zelf op de command line te doen.

Ben het er trouwens wel mee eens, dat als je het OS eruit haalt, de topic wel zou kunnen doodbloeden.

Ik heb de ZFS introductie herlezen en ik mis maar 1 ding, ook als onderdeel van deze topic:
=> Waar gaat ZFS naartoe? Wat zijn nieuwe features die we kunnen verwachten en wat hebben we (als beginners) eraan?

Van Oracle met gesloten Solaris kunnen we niks verwachten. Echter veel ex SUN mederwerkers die aan ZFS werkten, werken nu aan de illumos kernel die feature flags voor ZFS implementeren en de basis is voor enkele distributies zoals openindiana.

Zo kwam ik 2 weken later achter na installatie van Openindiana 151a5, deze op ZFS version 5000 met feature flags zit, maar ik heb geen idee wat deze feature inhoudt (en ja ik heb de release notes gelezen, pool migratie naar een OS die achter loopt zit er even niet in, maar is ook niet belangrijk aangezien ik voor openidiana met community support gekozen heb).

[gitaarwerk]

Enkele laatste vraag betreft SSD's en ZFS.

ik lees dus dat gewenst is om een SC SSD te nemen voor de ZIL, en een MLC SSD voor de L2ARC. Nu zit ik dus helaas met een 6 poorten max waarvan al 4 bezet zijn. Ik zou eventueel in een pcie slot een controller kunnen stoppen, maar deze wil ik graag reserveren voor een infiniband kaart voor toekomstige uitbreiding naar een virtual desktop omgeving.

Nu is het niet optimaal, maar ik dacht het volgende;
Is het verstandandig om twee SSD's (intel 330 serie), van 120GB te pakken, en die in hardwarematig (onboard intel c202 chipset) in mirroring raid1 te zetten? (of is dat niet aan te raden ivm TRIM? )
Dan de schijven partitioneren in een 5GB voor de ZIL, 40GB voor wat VM's (freenas/zfsguru, debian, en wat andere kleine) en dan de rest voor L2ARC. (Server heeft 32GB ram ECC, unbuffered)

De ZFS VM stuurt 4x WE RED 3TB aan in RAIDZ2.

Via ESXi koppel ik interne switches en zorg dat data via het interne netwerk op de ZFS share komen. Hier ben ik nog niet over uit, maar is wel mijn plan.

Is dit aan te raden? of kan ik het beter anders indelen?

[Dadona]

FireDrunk schreef op zondag 21 oktober 2012 @ 13:01:
Ik heb powerd zelf ingesteld, dat heeft volgens mij wel een hoop geholpen:

Config:
i5-3550 op een Intel Q77MK bord, 16GB geheugen, een M1015 controller en 10*2TB disks.

powerd:

##Poll state every 5 seconds
powerd_options="-a adaptive -i 60 -r 95 -n adaptive -m 1600 -M 3300 -p 5000"

#Enable C3-Saving
performance_cx_lowest="C3"
adaptive_cx_lowest="C3"
economy_cx_lowest="C3"

Intel heeft bij de core-serie het grafische deel wat aangepakt, met gunstige gevolgen voor het verbruik. Zelfs met slechte support voor het grafische deel blijft het verbruik nog een beetje meevallen.

Maar goed, volgens mij was er ook het voorstel om op de kortere termijn eens een topic op te zetten om het verbruik van BSD terug te dringen. Net zoals er ooit een topic is gestart over het verbruik van machines met Linux als OS (en waar nu zeker goede resultaten mee te behalen zijn, zeker met recente versies, inclusief recente kernel).

[Nism0]

Mede Tweakers,
Momenteel ben ik bezig met een zelfbouw nas.
Ik was in eerste instantie van plan om met unraid aan de slag te gaan totdat ik op het zfs principe stuitte.
Ik ben me nu al een aantal dagen aan het verdiepen in zfs en ben hier zeer gecharmeerd van.
Er is alleen 1 ding wat ik graag wil bevestigen bij jullie.

Stel ik heb een pool van 5 disks in Raidz2 en ik wil daar 1 disk aan toevoegen, dan is dat wel of niet mogelijk?

[Verwijderd]

Nism0 schreef op zondag 21 oktober 2012 @ 15:07:
Stel ik heb een pool van 5 disks in Raidz2 en ik wil daar 1 disk aan toevoegen, dan is dat wel of niet mogelijk?

Volgens mij is het sowieso niet handig om 5 disks in raidz2 te hebben omdat je dan 3 disks over houd voor de data en 3 is geen macht van 2.

[IceTeaGX]

Een pool bestaat uit vdevs, die vdevs bestaan uit een of meerdere schijven.
Een pool kan je uitbereiden met een extra vdev, maar je kan geen schijf toevoegen aan een bestaande vdev.
De redundancy bestaat op vdev niveau.

Dus nee, je kan geen schijf toevoegen aan een Raidz2 vdev. (ZFS ondersteund geen on-/offline capacity expansion)
En wat de persoon hierboven heeft gezegd.

[Nism0]

Hmmm dus al ik in de toekomst wil uitbreiden dan is dat wel mogelijk maar dan moet ik een minimaal aantal disks toevoegen en een nieuwe vdev maken. Met in totaal dus minder opslag capaciteit als ik de vdev in 1 keer had aangemaakt?

Kan ik wel van verschillende vdevs 1 volume maken?

[FireDrunk]

gitaarwerk schreef op zondag 21 oktober 2012 @ 13:18:
Enkele laatste vraag betreft SSD's en ZFS.

ik lees dus dat gewenst is om een SC SSD te nemen voor de ZIL, en een MLC SSD voor de L2ARC. Nu zit ik dus helaas met een 6 poorten max waarvan al 4 bezet zijn. Ik zou eventueel in een pcie slot een controller kunnen stoppen, maar deze wil ik graag reserveren voor een infiniband kaart voor toekomstige uitbreiding naar een virtual desktop omgeving.

Nu is het niet optimaal, maar ik dacht het volgende;
Is het verstandandig om twee SSD's (intel 330 serie), van 120GB te pakken, en die in hardwarematig (onboard intel c202 chipset) in mirroring raid1 te zetten? (of is dat niet aan te raden ivm TRIM? )
Dan de schijven partitioneren in een 5GB voor de ZIL, 40GB voor wat VM's (freenas/zfsguru, debian, en wat andere kleine) en dan de rest voor L2ARC. (Server heeft 32GB ram ECC, unbuffered)

De ZFS VM stuurt 4x WE RED 3TB aan in RAIDZ2.

Via ESXi koppel ik interne switches en zorg dat data via het interne netwerk op de ZFS share komen. Hier ben ik nog niet over uit, maar is wel mijn plan.

Is dit aan te raden? of kan ik het beter anders indelen?

SLC voor SSD is idd verstandig vanwege het feit dat als de stroom uitvalt bij MLC SSD's er potentieel meer sectoren corrupt kunnen raken.

In mijn persoonlijke ervaring word er veel meer geschreven naar een L2ARC SSD, en word de ZIL in een thuissituatie wel gebruikt, maar hoeft geen terrabytes aan writes te verstoken.

Persoonlijk zeg ik, als je kan leven met hooguit een minuut aan writes verlies, kan je prima 1 SSD voor beide taken inzetten, en dan neem je een van Mux' printjes om je SSD tegen stroomuitval te beveiligen.

Partitioneer de SSD niet helemaal vol, en je hebt een prima systeem!

Voor de snelheid hoef je ZIL en L2ARC echt niet te scheiden, dat levert amper iets op.

Nism0 schreef op zondag 21 oktober 2012 @ 15:17:
Hmmm dus al ik in de toekomst wil uitbreiden dan is dat wel mogelijk maar dan moet ik een minimaal aantal disks toevoegen en een nieuwe vdev maken. Met in totaal dus minder opslag capaciteit als ik de vdev in 1 keer had aangemaakt?

In theorie niet, want je kan een vdev toevoegen zonder redundancy, en dus nooit verlies lijden.
Maar als ik jou goed begrijp bedoel je: "Als ik later disks toevoeg met hetzelfde redundancy level verlies ik dan capaciteit?"

Dan is het antwoord, ja, dat is correct.

Kan ik wel van verschillende vdevs 1 volume maken?

Jup.

[ Voor 15% gewijzigd door FireDrunk op 21-10-2012 15:26 ]

[IceTeaGX]

Nism0 schreef op zondag 21 oktober 2012 @ 15:17:
Hmmm dus al ik in de toekomst wil uitbreiden dan is dat wel mogelijk maar dan moet ik een minimaal aantal disks toevoegen en een nieuwe vdev maken. Met in totaal dus minder opslag capaciteit als ik de vdev in 1 keer had aangemaakt?

Kan ik wel van verschillende vdevs 1 volume maken?

Een vpool kan bestaan uit meerdere vdevs. Dit kan dan gebruikt worden als 1 volume. Dan kan van het begin zo zijn, of door expansie achteraf (simplistisch voorgesteld, maar klopt wel denk ik)

Met meerdere vdevs zal je inderdaad meer schijven nodig hebben voor dezelfde ruimte. Je hebt dan echter wel iets meer redundancy. Je zet dan eigenlijk meerdere RAID 5/6 arrays in een JBOD structuur (om standaard raid termen te gebruiken)

PS, ben geen ZFS expert, maar denk toch dat ik juist zit.

[Nism0]

Ok, daar was ik al bang voor.
thnx voor de info!

[Durandal]

Verwijderd schreef op zaterdag 20 oktober 2012 @ 20:33:
Dat de nocache flags niet werken. Je moet 8 keer je RAM testen minimaal.

Ok dan,

code:

# 6 disk raidz2 pool WD Reds, best of 3 runs
# write
root@server2:/tank# dd if=/dev/zero of=128G.dat bs=1M count=128k
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 566.746 s, 243 MB/s
# read
root@server2:/tank# dd of=/dev/null if=128G.dat bs=1M
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 461.601 s, 298 MB/s

Hoe ziet dat er uit?

[FireDrunk]

Mager, maar acceptabel. Dat kan volgens mij wel iets sneller.

[Durandal]

FireDrunk schreef op zondag 21 oktober 2012 @ 15:50:
Mager, maar acceptabel. Dat kan volgens mij wel iets sneller.

Dan neem ik aan dat je het vergelijkt met BSD. Dit is linux (ZoL). Wat vindt je een gemiddeld goede snelheid en heb je tips waar ik naar kan kijken?

[Verwijderd]

Voor ZFS-on-Linux is dit een goed resultaat. Performance is niet het probleem van ZoL maar de betrouwbaarheid met name. Integratie van ZFS in het OS is niet iets wat makkelijk is als je het goed wilt doen. Zo loopt BSD ook nog steeds achter op Solaris qua ZFS geheugenmanagement terwijl ZFS onder BSD toch aardig wat liefde krijgt. Probleem bij ZoL is dat het een hobbyproject blijft omdat bedrijven ZFS niet voorgecompileerd kunnen distribueren. Je moet als eindgebruiker de sourcecode compileren en de module installeren, alleen dan ben je niet illegaal bezig als ik goed heb begrepen. Deze beperking zorgt ervoor dat bedrijven ver weg blijven bij dit project, waardoor serieuze conformancetests achterwege blijven. ZFS op FreeBSD heeft ook jarenlang geduurd voordat de dataloss/corruptie bugs eruit waren.

Dan verwacht ik nog meer van het Debian/kFreeBSD project, wat in feite een Linux distributie is zonder Linux kernel maar met de BSD kernel. Dit betekent dus ook de BSD implementatie van ZFS. Dus als je een Linux achtig OS wilt gebruiken, zou dit een fantastisch alternatief kunnen vormen. Ik heb er zelf nog niet mee gespeeld, maar wil dat zeker wel eens doen!

@IceTeaGX: klopt helemaal alleen de vdevs worden niet in JBOD gezet maar in 'RAID0'. En dan ook nog een verbeterde RAID0 die de ene vdev sneller kan laten lopen dan de andere. Dus vdev1 = 200MB/s + vdev2 = 100MB/s = 300MB/s terwijl dit bij traditioneel RAID 100+100 zou worden.

[gitaarwerk]

FireDrunk schreef op zondag 21 oktober 2012 @ 15:21:
[...]


SLC voor SSD is idd verstandig vanwege het feit dat als de stroom uitvalt bij MLC SSD's er potentieel meer sectoren corrupt kunnen raken.

In mijn persoonlijke ervaring word er veel meer geschreven naar een L2ARC SSD, en word de ZIL in een thuissituatie wel gebruikt, maar hoeft geen terrabytes aan writes te verstoken.

Het is wel een beetje small business use.. twee personen, we maken veel gebruik van de NAS. Plan is om een soort webdav achtige constructie te maken zodat we op onze eigen schijven werken voorlopig, sowieso voor de snelheid. Later gebeurd dat met het virtuele werkstation ook. Langzamere drives is dus niet zo heel erg.
Waar ik wel een beetje mee zit is of dat het snel genoeg is voor een webserver. Vooral lezen gaat denk ik belangrijker worden dan schrijven. [/quote]

Persoonlijk zeg ik, als je kan leven met hooguit een minuut aan writes verlies, kan je prima 1 SSD voor beide taken inzetten, en dan neem je een van Mux' printjes om je SSD tegen stroomuitval te beveiligen.

Ja hoor.. met twee man valt dat allemaal best mee. Doen ook veel grafisch werk, en saven regelmatig. Vooral lezen is dus eigenlijk essentieel.

Partitioneer de SSD niet helemaal vol, en je hebt een prima systeem!
Voor de snelheid hoef je ZIL en L2ARC echt niet te scheiden, dat levert amper iets op.

Hoe bedoel je niet vol partitioneren? je zegt, gooi alles maar gewoon op een schijf?

Laatste vraag,.. is mirror een goede beslissing met een SSD? of een apart voor de ZIL + L2ARC en de andere voor VM's apart?

[Durandal]

Verwijderd schreef op zondag 21 oktober 2012 @ 17:13:
Voor ZFS-on-Linux is dit een goed resultaat. ...
Probleem bij ZoL is dat het een hobbyproject blijft omdat bedrijven ZFS niet voorgecompileerd kunnen distribueren. Je moet als eindgebruiker de sourcecode compileren en de module installeren, alleen dan ben je niet illegaal bezig als ik goed heb begrepen.

Bedankt. Hierbij wil ik, om anderen niet af te schrikken, wel aantekenen dat i.i.g. onder Ubuntu je de compiler niet meer ter hand hoeft te nemen; de package manager regelt dat voor je. Een ppa toevoegen en 'apt-get install ubuntu-zfs' zet alles voor je op, en dat is niet anders dan andere packages.

[ Voor 3% gewijzigd door Durandal op 21-10-2012 19:15 ]

[analog_]

Verwijderd schreef op zondag 21 oktober 2012 @ 17:13:

[...]Dan verwacht ik nog meer van het Debian/kFreeBSD project, wat in feite een Linux distributie is zonder Linux kernel maar met de BSD kernel. Dit betekent dus ook de BSD implementatie van ZFS. Dus als je een Linux achtig OS wilt gebruiken, zou dit een fantastisch alternatief kunnen vormen. Ik heb er zelf nog niet mee gespeeld, maar wil dat zeker wel eens doen![...]

Debian/kFreeBSD kernel met ZFS: Nexenta(Stor). Ik weet niet hoe het betreft betrouwbaarheid zit, maar traditioneel is OpenIndiana wat sneller dan NexentaStor op gelijke hardware.

Crap, nee Nexenta is illumos met debian userland, my bad. Ik heb die deb/kfreebsd overigens wel eens draaiend gehad maar toen was het project net nieuw (en kreeg ik het niet stabiel).

[ Voor 11% gewijzigd door analog_ op 21-10-2012 23:15 ]

[Durandal]

Durandal schreef op zondag 21 oktober 2012 @ 15:49:
[...]

code:

# 6 disk raidz2 pool WD Reds, best of 3 runs
# write
root@server2:/tank# dd if=/dev/zero of=128G.dat bs=1M count=128k
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 566.746 s, 243 MB/s
# read
root@server2:/tank# dd of=/dev/null if=128G.dat bs=1M
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 461.601 s, 298 MB/s

Ik heb m'n raidz2 uitgebreidt van 6 naar 10 disks en ben iets onverwachts tegengekomen;

code:

# 10 disk raidz2 pool WD Reds, best of 3 runs
# write
root@server2:/tank# dd if=/dev/zero of=128G.dat bs=1M count=128k
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB) copied, 230.992 s, 149 MB/s
# read
root@server2:/tank# dd of=/dev/null if=128G.dat bs=1M
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 309.264 s, 444 MB/s

Leessnelheid is met 49% toegenomen. Niet geheel onverwacht.
Schrijfsnelheid is echter met 39% afgenomen (243->149 MB/s). Wat is hier de oorzaak van? Is dat inherent aan ZFS?

Edit:
Oorzaak gevonden: copies=2

nu met copies=1

code:

# 10 disk raidz2 pool WD Reds, best of 3 runs
# write
root@server2:/media/data/video# dd if=/dev/zero of=128G.dat bs=1M count=128k
131072+0 records in
131072+0 records out
137438953472 bytes (137 GB) copied, 644.5 s, 213 MB/s

Toch nog een vertraging. 243->213 MB/s

[ Voor 12% gewijzigd door Durandal op 22-10-2012 04:27 ]

[FireDrunk]

Verwijderd schreef op zondag 21 oktober 2012 @ 17:13:
Voor ZFS-on-Linux is dit een goed resultaat. Performance is niet het probleem van ZoL maar de betrouwbaarheid met name. Integratie van ZFS in het OS is niet iets wat makkelijk is als je het goed wilt doen. Zo loopt BSD ook nog steeds achter op Solaris qua ZFS geheugenmanagement terwijl ZFS onder BSD toch aardig wat liefde krijgt. Probleem bij ZoL is dat het een hobbyproject blijft omdat bedrijven ZFS niet voorgecompileerd kunnen distribueren. Je moet als eindgebruiker de sourcecode compileren en de module installeren, alleen dan ben je niet illegaal bezig als ik goed heb begrepen. Deze beperking zorgt ervoor dat bedrijven ver weg blijven bij dit project, waardoor serieuze conformancetests achterwege blijven. ZFS op FreeBSD heeft ook jarenlang geduurd voordat de dataloss/corruptie bugs eruit waren.

Er is toch laatst een of ander groot bedrijf toch met ZFS-on-Linux in zee gegaan? Ik geloof dat het een of andere research facility was, die vanwege een special stukje cluster software toch op debian moesten blijven, en zelf kernel modules hadden gecompileerd, en daarom ZFS-on-Linux gingen gebruiken.

Zij hebben zelf ook een heleboel patches upstream gestuurd, waardoor ZFS-on-Linux best hard is gegroeid. Ben de naam van het bedrijf even kwijt.
Het was: Lustre: YouTube: ZFS on Linux for Lustre

[ Voor 4% gewijzigd door FireDrunk op 22-10-2012 10:20 ]

[enormhi]

Even terugkomend op het backup storage systeem die ik plan om te bouwen. (Er zullen backups van een hoop Linux (webhosting) servers worden opgeslagen). We willen op de server compressie en deduplication gaan gebruiken.

Waar kan ik dan het beste naar kijken tot betrekking tot performance? RAIDZ(1/2/3) of mirrored vdev pool?

Het is namelijk op het moment zo dat de huidige server 's nachts begint met het maken van backups, maar niet snel genoeg is waardoor hij tegen de middag nog bezig is.

[Durandal]

Er is toch laatst een of ander groot bedrijf toch met ZFS-on-Linux in zee gegaan? Ik geloof dat het een of andere research facility was, die vanwege een special stukje cluster software toch op debian moesten blijven, en zelf kernel modules hadden gecompileerd, en daarom ZFS-on-Linux gingen gebruiken.

Zij hebben zelf ook een heleboel patches upstream gestuurd, waardoor ZFS-on-Linux best hard is gegroeid. Ben de naam van het bedrijf even kwijt.
Het was: Lustre: YouTube: ZFS on Linux for Lustre

Ik heb een beetje rondgekeken op het web naar mensen die al een tijdje ervaring met het gebruik hebben en vaker dan niet zijn dat toch mensen die het in hun bedrijf gebruiken. Over het algemeen niet van die hele grote bedrijven naar toch.
Ook niet vergeten dat het project is gestart in het Lawrence Livermore National Laboratory om daar de opslag te doen en dat is ook geen kleintje.
Over de stabiliteit gesproken is 'het net' het er wel over eens dat het nog niet helemaal stabiel is; d.w.z. er zijn gevallen waar de server hangt o.i.d. dus gebruik het niet als je 100% uptime nodig hebt. Voor wat betreft dataveiligheid echter scoort het heel hoog - nog niemand is door ZoL zijn data kwijt geraakt en dat is uiteindelijk waar ik het voor nodig heb. Een mogelijke reboot of zfs import ooit kan ik mee leven.

[FireDrunk]

enormhi schreef op maandag 22 oktober 2012 @ 11:20:
Even terugkomend op het backup storage systeem die ik plan om te bouwen. (Er zullen backups van een hoop Linux (webhosting) servers worden opgeslagen). We willen op de server compressie en deduplication gaan gebruiken.

Waar kan ik dan het beste naar kijken tot betrekking tot performance? RAIDZ(1/2/3) of mirrored vdev pool?

Het is namelijk op het moment zo dat de huidige server 's nachts begint met het maken van backups, maar niet snel genoeg is waardoor hij tegen de middag nog bezig is.

Ik zou alleen compressie gebruiken, dedup kost echt heeel vee performance en nog veel meer geheugen.
Dedup tabellen nemen schijnbaar heel veel geheugen in.

Voor compressie snelheid is een redelijke CPU genoeg, of je nou RAIDZ1,2 of 3 of Mirrored VDEV's gebruikt, maakt denk ik niet zo heel veel uit.
Backups zijn eerder gebottlenecked aan de andere kant, of door je interface (netwerk).

[FireDrunk]

Durandal schreef op maandag 22 oktober 2012 @ 13:10:
[...]

Ik heb een beetje rondgekeken op het web naar mensen die al een tijdje ervaring met het gebruik hebben en vaker dan niet zijn dat toch mensen die het in hun bedrijf gebruiken. Over het algemeen niet van die hele grote bedrijven naar toch.
Ook niet vergeten dat het project is gestart in het Lawrence Livermore National Laboratory om daar de opslag te doen en dat is ook geen kleintje.
Over de stabiliteit gesproken is 'het net' het er wel over eens dat het nog niet helemaal stabiel is; d.w.z. er zijn gevallen waar de server hangt o.i.d. dus gebruik het niet als je 100% uptime nodig hebt. Voor wat betreft dataveiligheid echter scoort het heel hoog - nog niemand is door ZoL zijn data kwijt geraakt en dat is uiteindelijk waar ik het voor nodig heb. Een mogelijke reboot of zfs import ooit kan ik mee leven.

Mooi, CiPHER, kunnen we dan nu de claim dat ZoL pertinent instabiel is, van de baan vegen?

[Verwijderd]

FireDrunk schreef op maandag 22 oktober 2012 @ 13:16:
[...]


Ik zou alleen compressie gebruiken, dedup kost echt heeel vee performance en nog veel meer geheugen.
Dedup tabellen nemen schijnbaar heel veel geheugen in.

320 bytes per DDT entry. Met name je recordsize (default 128K) is veelal te groot bij dedup. Dedup vergt verder niet zo hee erg veel CPU (gezien de snelle CPU's die er zijn tegenwoordig) maar als je data niet de deduppen is moet je er zeker niet aan beginnen. Je kan overigens met zdb zien hoe groot je DDT tabellen zijn en anders met zpool status -D.

[enormhi]

FireDrunk schreef op maandag 22 oktober 2012 @ 13:16:
[...]


Ik zou alleen compressie gebruiken, dedup kost echt heeel veel performance en nog veel meer geheugen.
Dedup tabellen nemen schijnbaar heel veel geheugen in.

Voor compressie snelheid is een redelijke CPU genoeg, of je nou RAIDZ1,2 of 3 of Mirrored VDEV's gebruikt, maakt denk ik niet zo heel veel uit.
Backups zijn eerder gebottlenecked aan de andere kant, of door je interface (netwerk).

Ik zit op het moment te 'kijken' naar een server met 32GB RAM. Meer is eventueel mogelijk.

RAIDZ(1/2/3) vs. Mirrored vdevs heeft voornamelijk effect op de IOPS. Wat bedoel je precies met "gebottlenecked aan de andere kant"? RAM?

[servies]

Verwijderd schreef op zondag 21 oktober 2012 @ 17:13:
Probleem bij ZoL is dat het een hobbyproject blijft omdat bedrijven ZFS niet voorgecompileerd kunnen distribueren. Je moet als eindgebruiker de sourcecode compileren en de module installeren, alleen dan ben je niet illegaal bezig als ik goed heb begrepen.

Wat ik er tot nu toe van heb begrepen is dat dat indirect voor je kan worden geregeld door de packagemanager. Als je de DKMS versies van de rpms installeert wordt bij de installatie van een nieuwe kernel automatisch een nieuwe versie van de benodigde zfs modules gecompileerd.

[JMW761]

FireDrunk schreef op maandag 22 oktober 2012 @ 13:16:
[...]


Ik zou alleen compressie gebruiken, dedup kost echt heeel vee performance en nog veel meer geheugen.
Dedup tabellen nemen schijnbaar heel veel geheugen in.

Voor compressie snelheid is een redelijke CPU genoeg, of je nou RAIDZ1,2 of 3 of Mirrored VDEV's gebruikt, maakt denk ik niet zo heel veel uit.
Backups zijn eerder gebottlenecked aan de andere kant, of door je interface (netwerk).

Maar dedup werkt natuurlijk wel super super goed voor backups; omdat je klanten vaak het liefst hele backups maken ipv incrementals. Ook terugzetten is dan een stuk eenvoudiger.

Dus: snapshots maken iedere dag, deze X dagen/maanden bewaren.

Wij maken iig gebruik van dedup en compressie op 1 van onze backupplatforms en dat vinden iig onze klanten erg fijn; gewoon terugbladeren door naar je .zfs dir te gaan.

[enormhi]

JMW761 schreef op maandag 22 oktober 2012 @ 16:47:
[...]


Maar dedup werkt natuurlijk wel super super goed voor backups; omdat je klanten vaak het liefst hele backups maken ipv incrementals. Ook terugzetten is dan een stuk eenvoudiger.

Dus: snapshots maken iedere dag, deze X dagen/maanden bewaren.

Wij maken iig gebruik van dedup en compressie op 1 van onze backupplatforms en dat vinden iig onze klanten erg fijn; gewoon terugbladeren door naar je .zfs dir te gaan.

Ik geloof dat we op dit moment volledige system back-ups maken voor de klanten. De klanten kunnen niet zelf bij de back-ups. Hoe zit het met de hardware van dat backupplatform? Hoe is die ingericht? Zelf ben ik er nog niet helemaal over uit hoe ik hem in ga richten.

[Dadona]

JMW761 schreef op maandag 22 oktober 2012 @ 16:47:
[...]


Maar dedup werkt natuurlijk wel super super goed voor backups; omdat je klanten vaak het liefst hele backups maken ipv incrementals. Ook terugzetten is dan een stuk eenvoudiger.

FireDrunk gaf al aan dat dit wel behoorlijk wat geheugen gaat kosten, maar jij zou dus met real-life cijfers kunnen komen?
Ik kan mij alleen zo voorstellen dat bepaalde (client-side) backup oplossingen dit een heel stuk efficiënter kunnen afvangen. Los van het doodleuk iedere keer ontvangen van een full-backup, blijft sommige backup software actief monitoren wat nieuw is en kan ook op die manier de backup worden 'versneld'.
Wat de nadelen betreft, als ik kijk naar Crashplan dan is dat al behoorlijk efficiënt in het herstel. Standaard zie je de huidige staat van de backup. Maar ook bij bijvoorbeeld rdiff-backup kun je zo bij de data, als in, de files en mapping van de laatste backup staan in één map. De tijd zit vooral in het terughalen van een file die is verwijderd en die toch niet weg moest. Die zitten in archief mappen. Bij Crashplan is dat alsnog behoorlijk snel, Rdiff-backup wat langzamer.

[Durandal]

servies schreef op maandag 22 oktober 2012 @ 15:19:
[...]

Wat ik er tot nu toe van heb begrepen is dat dat indirect voor je kan worden geregeld door de packagemanager. Als je de DKMS versies van de rpms installeert wordt bij de installatie van een nieuwe kernel automatisch een nieuwe versie van de benodigde zfs modules gecompileerd.

Ja dat klopt. Dat heb ik zien gebeuren, ook als je bv zelf een nieuwe kernel bouwt.

[FireDrunk]

De ruimtebesparing van dedup weegt voor SMB in mijn ogen niet op tegen het performance verlies en geheugen gebruik. Zonder grote L2ARC en veel geheugen (>48GB) is dedup erg langzaam en kost het heel veel van je RAM en Caching, waardoor je andere files uit het cache gedrukt worden.

Je kan er natuurlijk je budget op aanpassen, maar persoonlijk verwacht ik (vooral bij webdevelopment) veeeel meer van compressie... Text files zijn namelijk goed te comprimeren... En plaatjes dan weer niet.

Wat je misschien kan doen, is meerdere ZVOL's aanmaken, waarvan je er één als backup definieert, en daarop Dedup aanzet, en op de rest uit laat.

[Verwijderd]

Na een tijd op het forum gekeken te hebben kwamen een aantal vragen in mij op.

Als eerste, wat zijn de prestaties van de Asus C60M1-I in combinatie met 5x2tb schijven in raid-z. zullen de prestaties sneller, langzamer of gelijk zijn in vergelijking met dezelfde hardware en 3x2tb schijven in raid-z.

Ook vroeg ik mij af of het beter is om een aparte boot schijf te gebruiken inplaats van via het zfs volume te booten.

[enormhi]

FireDrunk schreef op maandag 22 oktober 2012 @ 21:23:
De ruimtebesparing van dedup weegt voor SMB in mijn ogen niet op tegen het performance verlies en geheugen gebruik. Zonder grote L2ARC en veel geheugen (>48GB) is dedup erg langzaam en kost het heel veel van je RAM en Caching, waardoor je andere files uit het cache gedrukt worden.

Je kan er natuurlijk je budget op aanpassen, maar persoonlijk verwacht ik (vooral bij webdevelopment) veeeel meer van compressie... Text files zijn namelijk goed te comprimeren... En plaatjes dan weer niet.

Wat je misschien kan doen, is meerdere ZVOL's aanmaken, waarvan je er één als backup definieert, en daarop Dedup aanzet, en op de rest uit laat.

We gaan waarschijnlijk iSCSI gebruiken, maakt dat nog een verschil?

Compressie op text files lijkt me ook een goed punt. Echter met dedup kun je ook aardig wat ruimte besparen aangezien een hoop config files hetzelfde zijn tussen de servers.

[FireDrunk]

Maaruh, je hebt het hier over configs van hooguit 100KiB? Als de dedup echt goed lukt, heb je dus als je 50 servers hetzelfde hebt, een winst van 49 keer 100KiB... een dikke, 4.9MB.

Niet echt nuttig dus...

Dedup komt pas echt tot zijn recht op bijvoorbeeld VDI NFS shares, waar 500 VDI machine Images staan die elk 1% anders zijn... Dan kan je theoretische winst al gauw in de TiB's lopen...

iSCSI maakt het zeker anders, je writes zijn dan allemaal synchroon, hierdoor heb je veel profijt van een goede ZIL opstelling.

[ Voor 21% gewijzigd door FireDrunk op 23-10-2012 09:18 ]

[EnerQi]

Verwijderd schreef op maandag 22 oktober 2012 @ 22:23:
Na een tijd op het forum gekeken te hebben kwamen een aantal vragen in mij op.

Als eerste, wat zijn de prestaties van de Asus C60M1-I in combinatie met 5x2tb schijven in raid-z. zullen de prestaties sneller, langzamer of gelijk zijn in vergelijking met dezelfde hardware en 3x2tb schijven in raid-z.

Ook vroeg ik mij af of het beter is om een aparte boot schijf te gebruiken inplaats van via het zfs volume te booten.

Over de prestaties weet ik niet. Ikzelf heb een iets snellere processor gekozen (intel G530 met intel moederbord). Ikzelf ben nog niet tegen limieten aangekomen mbt de CPU/RAM. Het netwerk hier (Gigabit) is duidelijk de bottleneck hier.

Overigens zorgen meer harde schijven voor meer snelheid (als het netwerk het aankan ). Dat is bij 1 harde schijf namelijk al een probleem. pricewatch: Seagate Barracuda 7200.14 ST3000DM001, 3TB harde schijf kan al 140 MB/s schrijven, volgens mij gaat de prestatie langzaam naar de 90 MB als de schijf voller raakt. Je netwerk (Gigabit ga ik even vanuit ) kan max 125 MB/s (100 MB is reëel) verzenden/ontvangen en dan mag er geen storing of iets met internet openstaan.

[enormhi]

FireDrunk schreef op dinsdag 23 oktober 2012 @ 09:16:
Maaruh, je hebt het hier over configs van hooguit 100KiB? Als de dedup echt goed lukt, heb je dus als je 50 servers hetzelfde hebt, een winst van 49 keer 100KiB... een dikke, 4.9MB.

Niet echt nuttig dus...

Dedup komt pas echt tot zijn recht op bijvoorbeeld VDI NFS shares, waar 500 VDI machine Images staan die elk 1% anders zijn... Dan kan je theoretische winst al gauw in de TiB's lopen...

iSCSI maakt het zeker anders, je writes zijn dan allemaal synchroon, hierdoor heb je veel profijt van een goede ZIL opstelling.

Hmm, ja dat is waar.. Dan ga ik me nog maar eens goed verdiepen in de ZIL.

[FireDrunk]

Bedenk goed hoeveel je uit wil geven, want als je 100% veilig wil, en 100% robuust kan het nog een aardige duit kosten (Mirrored SLC SSD's en een UPS).

Als je wat minder eisen stelt, kan 1 Samsung 830 SSD met een goede UPS al voldoende zijn.

[enormhi]

Daar moet ik het nog eens goed met de rest van de IT over hebben.

[Verwijderd]

EnerQi schreef op dinsdag 23 oktober 2012 @ 09:56:
[...]


Over de prestaties weet ik niet. Ikzelf heb een iets snellere processor gekozen (intel G530 met intel moederbord). Ikzelf ben nog niet tegen limieten aangekomen mbt de CPU/RAM. Het netwerk hier (Gigabit) is duidelijk de bottleneck hier.

Overigens zorgen meer harde schijven voor meer snelheid (als het netwerk het aankan ). Dat is bij 1 harde schijf namelijk al een probleem. pricewatch: Seagate Barracuda 7200.14 ST3000DM001, 3TB harde schijf kan al 140 MB/s schrijven, volgens mij gaat de prestatie langzaam naar de 90 MB als de schijf voller raakt. Je netwerk (Gigabit ga ik even vanuit ) kan max 125 MB/s (100 MB is reëel) verzenden/ontvangen en dan mag er geen storing of iets met internet openstaan.

Wat is het stroomverbruik van jouw setup?

[analog_]

Inmiddels al mijn Crucials M4's bijgewerkt naar de recentste FW netzoals de IBM M1015 die nu de P14 IT FW draait. Er blijft één SSD nu write errors genereren. Heb de bekabeling al vervangen, heeft iemand enig idee of de drive met een bepaalde tool zichzelf als 'kapot' kan aangeven (smart?) zodat garantie wat makkelijk verloopt. Heb het vermoeden dan een printje van 'zpool status vol' niet genoeg gaat zijn.

[FireDrunk]

Tooling van Crucial zelf?

[EnerQi]

Verwijderd schreef op dinsdag 23 oktober 2012 @ 14:24:
[...]


Wat is het stroomverbruik van jouw setup?

De ZFSguru NAS die ik heb verbruikt met 6 schijven idle 52.6 watt (gemeten met de voltcraft energie monitor 3000), het piekvermogen zit op 136.6 watt. Zonder harde schijven zit het op 21/22 watt.
Wat ik nog moet uitzoeken, is hoe de harde schijven in slaapstand terecht komen. Nu zijn ze altijd paraat

#	Product	Prijs	Subtotaal
1	Intel Celeron G530 Boxed	€ 37,50	€ 37,50
1	MSI B75MA-P45	€ 54,95	€ 54,95
6	Seagate Barracuda 7200.14 ST3000DM001, 3TB	€ 124,90	€ 749,40
1	Antec Three Hundred Two	€ 53,40	€ 53,40
2	Kingston KVR1333D3N9/8G	€ 29,90	€ 59,80
1	FSP Aurum Gold 400	€ 56,84	€ 56,84
Bekijk collectie Importeer producten		Totaal	€ 1.011,89

[Verwijderd]

EnerQi schreef op dinsdag 23 oktober 2012 @ 18:47:
De ZFSguru NAS die ik heb verbruikt met 6 schijven idle 52.6 watt (gemeten met de voltcraft energie monitor 3000), het piekvermogen zit op 136.6 watt. Zonder harde schijven zit het op 21/22 watt.
Wat ik nog moet uitzoeken, is hoe de harde schijven in slaapstand terecht komen. Nu zijn ze altijd paraat

Bedankt voor je informatie, Zelf ben ik nu op de volgende configuratie gekomen.

#	Product	Prijs	Subtotaal
1	Intel Celeron G530 Boxed	€ 37,50	€ 37,50
1	MSI B75MA-P45	€ 54,95	€ 54,95
3	Seagate Barracuda 7200.14 ST2000DM001, 2TB	€ 85,90	€ 257,70
3	Nexus Real Silent D12SL-12 BW, 120mm	€ 5,45	€ 16,35
1	Corsair CMV8GX3M1A1333C9	€ 28,95	€ 28,95
1	Sharkoon WPM400	€ 40,95	€ 40,95
Bekijk collectie Importeer producten		Totaal	€ 436,40

Een kast heb ik nog liggen er zitten alleen geen fans in vandaar deze in de lijst.
Ik ben ook van plan om ZFSguru te gaan gebruiken.
Om te beginnen heb ik 3 disks genomen om deze in raid-z te kunnen draaien. Is het mogelijk deze later te formatteren en opnieuw te gebruiken in een 5 disk raid-z?
En zie ik het goed dat jij gewoon boot van harddisks?

[Durandal]

Je kan die 3 disks gewoon gebruiken in een nieuwe 5 disk raidz zpool. Formatteren hoeft niet.
Doe je het met de command line moet je een -f (force) optie meegeven. Via de UI weet ik het niet maar er zal wel een vinkje oid zitten.

[FireDrunk]

Iemand die een goede simpele IOPS test weet voor FreeBSD? Ik vind Bonnie erg omslachtig...

[NightH4wk]

FireDrunk schreef op woensdag 24 oktober 2012 @ 10:14:
Iemand die een goede simpele IOPS test weet voor FreeBSD? Ik vind Bonnie erg omslachtig...

sysutils/ioping wellicht?

[FireDrunk]

Werkt niet goed samen met ZFS, al geprobeerd. Krijg hele rare getallen (van 60 IOPS tot 8GB/s sequentieel)

[NightH4wk]

diskinfo(8) kent ook een simpele benchmark.

[FireDrunk]

Die kan alleen devices benchmarken, geen directories.

[Verwijderd]

Je kunt natuurlijk met rawio aan de slag, maar dat ioping is best een gaaf benchmarkje. Aangezien je op ZFS werkt moet je natuurlijk wel de grootte flink omhoogtrappen anders wordt het een RAM-benchmark.

[root@msi /samsung/testfs]# ioping -q -i 0 -w 10m -S 20g .

--- . (zfs samsung/testfs) ioping statistics ---
33910 requests completed in 600000.7 ms, 57 iops, 0.2 mb/s
min/avg/max/mdev = 0.0/17.7/808.0/10.5 ms

10 minuutjes en 20GB testsize. Liever wil je 30 minuten en 8*RAM testsize. 57 iops klopt gewoon aangezien ik 5400rpm draai. En 1000/60 = 16.6ms dus dat klopt wel aardig. Ook maar een testje tussendoor; achtergrond I/O heb ik niets aan gedaan.

[analog_]

bonnie++ / dd op 3 m4's in raid 0. Niet helemaal tevreden nog (vooral de write), krijg vooral de indruk dat een Quad Phenom I op 2.2GHz hem niet genoeg kan bezig houden wat wel problematisch kan worden als ik IB toevoeg (welliswaar dan met recentere s1155 pentium).

Eens kijken naar die IOping.

[ Voor 11% gewijzigd door analog_ op 24-10-2012 18:06 ]

[enormhi]

We zijn bijna rond met de nieuw backup server. Ik heb alleen nog even een vraag over de HDD's. Is er nog een verschil tussen Nearline SAS en SATA in combinatie met ZFS?

[FireDrunk]

Als je goede HBA's gebruikt niet. De Nearline SAS heeft een kortere TLER en zou potentieel eerder wat data verliezen tegenover een gewone sata disk, maar dat is per fabrikant anders, en geen pijl op te trekken.

Gewoon voor de goedkoopste (supported) gaan.

[Verwijderd]

NL-SAS geniet de voorkeur. SATA veroorzaakt bus-storm-resets, iets wat je niet wilt als je 100 disken in 1 pool hebt, helemaal achter expanders is het een recept voor downtijd.

[FireDrunk]

SATA bus storm reset? Wazzda? nog nooit van gehoord...
Heb je een linkje? Ben heel benieuwd!

[Verwijderd]

http://gdamore.blogspot.n...te-on-sata-expanders.html meest recente die ik kon vinden, maar er zijn nog meerdere.

[FireDrunk]

http://hardforum.com/show...=1038375679&postcount=793

Deze is iets uitgebreider.

Interresante info!

[Verwijderd]

haha die is er ook dat is een collega van me

[FireDrunk]

Ik moet wel zeggen dat het ruikt naar een Nexenta/Illumos/Solaris only, omdat ik niet het gevoel heb dat alle device drivers/ controller drivers die resets sturen als een disk failed.

Maar ik kan het uiteraard mis hebben.

[Verwijderd]

Als je goed leest staat er dat het onderdeel is van het protocol. Het zit er in opgesloten en elke drive kan er dus voor zorgen dat er hele bus er aan gaat, waardoor de andere drives (die in principe gewoon goed zijn) ook gaan resetten met als gevolg een reset storm. Nu zijn er wel manieren om de impact hiervan minder te maken maar over het algemeen, is het de meerprijs (4 euro ofzo geloof ik ) SATA vs SAS het wel waard. Vooral als je kijkt naar mpath etc, iets dat je bij een beetje storage oplossing wel nodig hebt.