[ZFS] Storage server advies

[Megalith]

Hallo allen,

Ik ben me al een ruime tijd aan het oriënteren om thuis een dedicated storage server te bouwen. Op dit moment heb ik een Windows server 2008 draaien met 4 x WD 2TB schijven en drie RE4 WD2503ABYX in RAID 0 waar de VMDK's op staan van de Hyper-V machines. De specs:

• MSI H67MA-ED55
• Core i5 2400
• 4x4GB Kingston DDR3
• Intel SASUC8i
• 4 x WD2503ABYX
• 4 x WD20EARS

Omdat ik nu geen enkele redundantie heb voor mijn data, zit ik er aan te denken om hiervoor een aparte machine in te richten waar alle harde schijven in komen te hangen die geshared worden middels NFS. Ik wil hier graag software RAID op gaan draaien en ZFS lijkt me daarvoor de meest geschikte optie. (Goedkoper, veiliger en toch snel)

De nieuwe setup moet er als volgt uit komen te zien:
• Intel Xeon E3-1230 Boxed
• Supermicro X9SCM-F
• Kingston ValueRAM KVR1333D3E9SK2/8G 2x ICIDU Value DDR3,1333-8GB KIT
• be quiet! Pure Power L7 430W Corsair HX650
• 6x Western Digital Caviar GreenPower WD20EARS, 2TB
• 4 x Western Digital RE4 WD2503ABYX, 250GB
• Intel SASUC8i
• Norcotek RPC 3116

Toelichting hierbij:
Met een quadcore processor zal ik altijd wel goed zitten, maar misschien kan hij het ook met een dualcore af?
Supermicro serverbord beschikt over 2x Gigabit LAN en IPMI, moet erg makkelijk te beheren zijn op afstand.
16GB ECC geheugen, non ECC werkt niet met dit bord. Heb de vuistregel 1TB -> 1GB ram gehanteerd, daarnaast lust ZFS wel wat RAM.

Ik ben er nog niet over uit of ik de 6 2TB schijven in een RAIDZ1 of RAIDZ2 wil laten draaien. RAIDZ1 met 1 hotspare is ook een optie maar dan lijkt me RAIDZ2 toch veiliger, altijd wel een webshop die één of twee van deze schijven op voorraad heeft.
De 4 RE4 250GB schijven ga ik denk ik in RAID 0 zetten. Hier komt alleen de data voor de virtuele machines op te staan, en er wordt, waarschijnlijk meerdere malen per dag gebackupped naar de hoofd array.

Ook ben ik er nog niet uit welk OS ik hiervoor ga gebruiken. Freenas is wat mij betreft eerste keus, makkelijk te beheren via de webinterface maar schijnt minder "robuust" te zijn dan Solaris zoals OpenIndiana? Kan ik dit het beste vanaf een USB stick draaien of is een laptop schijfje beter?

Ik had nog een aantal wat specifiekere vragen maar deze ben ik op het moment even kwijt. Zal ze toevoegen zodra ik er weer op kom.

[Anoniem: 15758]

Wel aardige config, mijn op- en aanmerkingen:

• Je gebruikt 4K sector schijven; een 6x RAID-Z is daarvoor niet optimaal; 6x RAID-Z2 wel en zal betere performance geven ook al heb je effectief een disk minder. Een RAID-Z2 biedt veel betere bescherming voor je data; dan wordt de kans dat je data verliest toch behoorlijk klein; ik zou voor die optie gaan dus.
• Je 250GB schijven verbruiken elk evenveel als 2x 2TB EARS; superveel dus! Om 1TB in de lucht te houden verbruik je dus evenveel als 8x 2TB = 16TB met nieuwe schijven. Als je deze schijven wilt gebruiken zou ik zeker spindown instellen anders ben je veel energie kwijt!
• ECC geheugen kan goedkoper als je het niet erg vindt om Brand-on-3rd te kopen, zoals dit Micron geheugen: pricewatch: ICIDU Value DDR3,1333-8GB KIT
• Voeding van 430 kan krap worden. Je 4x 250GB schijven verbruiken tegen de 120W bij opspinnen, je 6x EARS verbruiken rond de 108W. Het zou kunnen maar als je nog meer schijven in de toekomst wilt is het handig een voeding met een hoger +12V vermogen op een enkele rail te kopen, zoals Corsair 850W uit mijn hoofd.
• Bij zo'n build hoort een SSD als L2ARC + SLOG. Misschien kun je de SSDs ook gebruiken voor je VMs? Zelf raad ik de Intel 320 aan, vanwege de supercaps kun je deze ook heel goed als SLOG gebruiken en daarmee je hele pool versnellen. Je kunt een SSD door middel van partities voor meerdere doeleinden gebruiken; alhoewel dat alleen correct en veilig onder FreeBSD platform kan, niet onder Solaris platform.

Dan nog een andere overweging: als je niet persé op korte termijn wilt/hoeft te kopen, kun je nog even wachten op het AMD bulldozer platform; dat zou low-power, high performance en goedkope toegang tot ECC moeten combineren. Je mist dan wel IPMI bij normale consumentenborden; dat SuperMicro bord is opzich wel fijn voor een server natuurlijk. Voordeel van bulldozer zou zijn dat je minder geld uitgeeft en toch grofweg twee keer zo snelle CPU kracht hebt; voor weinig centen kun je daar een mooie 8-core in gooien waar ZFS uitstekend mee kan omgaan. Dan kun je cpu-heavy functies als compressie, encryptie en de-dup gebruiken mocht je daar nu of in de toekomst behoefte aan hebben. In principe kan een dualcore ook; maar Bulldozer is wel mijn aanstaande favoriet voor een serieuze ZFS setup. Je krijgt zo meer voor minder geld; met name goedkoop ECC en lekker veel cores. Omdat AMD nu eindelijk ook een 32nm High-K Metal Gate procédé heeft kun je ook erg lage idle waardes verwachten dus qua energieverbruik zou het ondanks hoge TDP toch erg economisch moeten zijn. In principe de perfecte combinatie: heel veel CPU-power als je het nodig hebt maar toch erg laag idle verbruik voor de periodes waarbij de NAS in rust is.

Veel overwegingen, kun je denk ik weer even mee vooruit.

[Megalith]

Dank voor je uitgebreide reactie!
Dan wordt het filesysteem sowieso RAID-Z2.
Ik heb een aantal maanden bewust gekozen voor deze 250GB schijven omdat ze in vergelijking met "green" schijven toch merkbaar sneller zijn. Op dit moment heb ik 6 virtuele machines aanstaan met 2 (kleine) SQL databases en dan is dat toch wel erg fijn. Omdat die disks eigenlijk altijd wel worden gebruikt heeft een spindown denk ik niet zo'n groot effect.

Wat de voeding betreft ga ik denk ik voor de Corsair HX650. Die kan 624 Watt over een enkele 12V rail leveren (dat ding wat ik nu gebruik maar 216 Watt ). De HX650 is wel wat minder efficiënt dan de HX750/850 dus dat moet ik nog even tegen elkaar afwegen.

Een SSD als cache inderdaad, die was ik in de openingspost vergeten. Voor de VM array zal het vast veel nut hebben, maar op de 12TB array staan alleen maar muziek, foto's en films. Om daar een SSD aan te hangen is denk ik overbodig.
Stel ik sluit een 120GB Intel 320 aan alleen voor de VM's, dan zou ik misschien wel één of twee van die energievretende schijven weg kunnen laten, aangezien die er niet zijn voor de capaciteit maar om een hogere IO te halen.

Ik weet nog niet wanneer ik van plan ben dit aan te schaffen. Ik wil eigenlijk zo snel mogelijk
Het Supermicro bord wat ik nu heb lijkt me super en de quadcore zal ook vast niet traag zijn. Maar een 8core processor klinkt ook best leuk , en daarmee spaar ik een paar tientjes uit aan ECC geheugen. Ligt eraan op welke termijn Bulldozer beschikbaar komt, als het niet te lang duurt ben ik nog wel bereid om er op te wachten.

[Gertjan]

Hoeveel ruimte heb je netto in je NAS nodig? Wil je performance en veiligheid, gebruik dan RAID 10. RAIDZ2 is leuk, maar performed niet (net als RAIDZ1). Je kunt met RAIDZ1 of -2 nooit meer prestaties halen dan die van een enkele disk!
Wil je toch voor RAIDZ gaan, gebruik dan zeker SSD's als read- en writecache!

Ik heb zelf geen ervaring met SATA-schijven met ZFS, maar ik lees op mailinglists slechte verhalen over de 4K-disks, zeker in combinatie met OpenSolaris/OpenIndiana/Nexenta. Er schijnen truuks te zijn, zoals het aanmaken van een iSCSI-LUN en die aan ZFS aanbieden om de sectors te alignen, maar dat is voor mij een kwestie van klok-klepel . Ik heb alleen ervaring met enterprise-grade SAS-disks.

Verder is ZFS erg geheugenhongerig. Welke features van ZFS wil je gebruiken? Deduplicatie raad ik af, de implementatie in ZFS is niet volwassen. Mocht je het toch overwegen, investeer dan zeker in meer geheugen. Meer RAM is altijd beter wat ZFS aangaat, wellicht zou je zelfs voor 16 GB kunnen gaan.

Qua software: kijk eens naar Nexenta als je een handige GUI belangrijk vind (aangezien je over FreeNAS begint). Het is gebaseerd op OpenSolaris, maar heeft beschikking over de GNU-tools van Debian. De Community Edition is gratis te gebruiken tot 18 TB (bruto) storage.

[Megalith]

Bij elkaar heb ik nu ongeveer 2,2 TB in gebruik. Met de VMDK files erbij 200GB extra, maar die reken ik even niet mee in dit verhaal omdat die op een andere array staan.
Ik heb totaal geen idee meer wat ik kan verwachten van de snelheid van een RAIDZ2 array. Op sommige forums kom ik vragen tegen of het überhaupt wel mogelijk is om 50MB's write speed te halen met vier 2TB schijven in RAIDZ. Een ander heeft een verhaal dat hij makkelijk 100+ MB's schrijft op een RAIDZ array.

Mijn doelstelling is eigenlijk wel om meer dan 100MB per seconde weg te kunnen schrijven, en al helemaal rap te kunnen lezen (200+ MB's). Kan iemand mij vertellen of dit reëel is? Stel dat ik RAIDZ2 ga gebruiken met 6x 2TB schijven ik er ook een 80GB SSD bij hang voor cache en er 16GB RAM in hang.

RAID10 is inderdaad ook een interessante optie, maar dan ben je meteen weer zoveel ruimte kwijt, en met een beetje pech kunnen er niet eens twee disks failen.

[Gertjan]

Sequentieel 100MB/s zou misschien kunnen, omdat 1 enkele disk dat onder extreem gunstige omstandigheden ook zou kunnen. Ik zou er echter niet te veel op rekenen, en zeker niet op goede random I/O performance. Want 1) je gebruikt SATA-disks, en 2) RAIDZ. Random I/O kun je met goede SSD's wel flink versnellen.

fcg123 schreef op zaterdag 09 juli 2011 @ 15:44:
Bij elkaar heb ik nu ongeveer 2,2 TB in gebruik. Met de VMDK files erbij 200GB extra, maar die reken ik even niet mee in dit verhaal omdat die op een andere array staan.
...
RAID10 is inderdaad ook een interessante optie, maar dan ben je meteen weer zoveel ruimte kwijt, en met een beetje pech kunnen er niet eens twee disks failen.

Elk voordeel heb z'n nadeel . Met RAID-10 zou je in jouw setup in theorie zelfs 3 diskcrashes kunnen overleven, met RAIDZ2 ben je dan gegarandeerd alles kwijt. Een extra voordeel van RAID-10: het is makkelijker uitbreidbaar. Een RAIDZ2-groep kun je niet uitbreiden, de enige mogelijkheid om extra storage toe te voegen is extra RAID-devices toe te voegen aan de zpool. Je zit dan al snel aan een tweede RAIDZ2-groep met evenveel disks, om het ZFS niet te moeilijk te maken.
RAID-10 is gemakkelijk uit te breiden, door er twee nieuwe disks in RAID-1 aan toe te voegen. Wil je meer zekerheid? Breid bestaande RAID-1 groepjes uit met een extra disk.

Zeker als je nu wel wil investeren in 6 grote disks, maar de ruimte niet direct nodig hebt, zou ik zeker voor RAID-10 gaan.

[Anoniem: 15758]

Gertjan schreef op zaterdag 09 juli 2011 @ 12:07:
Wil je performance en veiligheid, gebruik dan RAID 10.

RAID10 is niet zo heel veilig hoor. Stel je hebt één failed disk dan kun je al kapotte files hebben door bad sectors op de remaining disk. Met RAID-Z2 is je data vrijwel indestructable, omdat je 2 redundante bronnen voor alle data hebt.

RAID10 gaat snel zijn qua lezen (bijna net zo snel als RAID0 onder ZFS) maar qua schrijven is het langzamer dan RAID-Z of RAID-Z2. Qua random reads en writes wel stukken sneller dan RAID-Z/2

RAIDZ2 is leuk, maar performed niet (net als RAIDZ1). Je kunt met RAIDZ1 of -2 nooit meer prestaties halen dan die van een enkele disk!

Je mag daar wel bij vertellen dat dit geldt voor random I/O; niet voor sequential I/O! Je random reads en writes zijn dus in principe gelijk aan dat van een enkele disk.

Nu zijn alle HDDs supertraag met welke random I/O dan ook; vandaar dat we SSDs gebruiken om dit te versnellen. Dus de combinatie RAID-Z2 met SSD als L2ARC + SLOG is zowel supersnel met sequential I/O (HDD) als met random I/O (SSD). Dan heb je het beste van beide werelden.

Ik heb zelf geen ervaring met SATA-schijven met ZFS, maar ik lees op mailinglists slechte verhalen over de 4K-disks, zeker in combinatie met OpenSolaris/OpenIndiana/Nexenta.

Omdat:
1) solaris smerige partities gebruikt die op sector 63 beginnen; net zoals Windows XP doet (iew!)
2) solaris geen sector size boven de 512 bytes native ondersteunt (hardcoded)
3) solaris geen GEOM framework heeft om van een 512 byte sectorsize disk een 4K native sectorsize disk te maken

Dit zijn allemaal beperkingen van het Solaris platform. Als je voor Solaris wilt gaan is het handig je pool aan te maken onder FreeBSD met het geom trucje; dan importeren in Solaris. Daarnaast geldt dat sommige configuraties met 4K disks van nature goed performen, zoals:
- 6 of 10 disk RAID-Z2 (4 of 8 data disks)
- 5 of 9 disk RAID-Z (4 of 8 data disks)

Dus een 6 disk RAID-Z2 zal veel beter performen dan een 6-disk RAID-Z; terwijl je dus effectief één schijf minder hebt voor write operaties.

Deduplicatie raad ik af, de implementatie in ZFS is niet volwassen.

Kun je dat onderbouwen? Ik denk dat dedup voor het gros van de consumenten niet interessant is; maar je kunt het voor kleine datasets zeker overwegen. Bijvoorbeeld als je meerdere VMs hebt met grotendeels identieke data; dan kun je heel goed dedup op die dataset activeren.

Mocht je het toch overwegen, investeer dan zeker in meer geheugen. Meer RAM is altijd beter wat ZFS aangaat, wellicht zou je zelfs voor 16 GB kunnen gaan.

Eens.

Qua software: kijk eens naar Nexenta als je een handige GUI belangrijk vind (aangezien je over FreeNAS begint). Het is gebaseerd op OpenSolaris, maar heeft beschikking over de GNU-tools van Debian. De Community Edition is gratis te gebruiken tot 18 TB (bruto) storage.

Weet je wel bewust van de beperkingen van het Solaris platform. Zo kun je SSD niet veilig voor zowel cache (L2ARC) als buffer (SLOG) gebruiken. En zit je met het probleem van 4K disks onder Solaris. Ook kun je niet booten van je RAID-Z/2 pool. Verder wel een goede keuze; alhoewel het natuurlijk niet/nauwelijks open source is en een beperkte (maar sterke) community heeft.

Voordat je een definitieve keuze maakt kun je meerdere platforms uitproberen, dat lijkt me wel verstandig. Ook is het handig je ZFS pool versie ietwat laag te houden (i.e. niet boven de 28) zodat je kunt switchen tussen BSD en Solaris platform.

Mijn doelstelling is eigenlijk wel om meer dan 100MB per seconde weg te kunnen schrijven, en al helemaal rap te kunnen lezen (200+ MB's). Kan iemand mij vertellen of dit reëel is? Stel dat ik RAIDZ2 ga gebruiken met 6x 2TB schijven ik er ook een 80GB SSD bij hang voor cache en er 16GB RAM in hang.

Met 6x RAID-Z2 in FreeBSD of optimale config onder Solaris kun je goede performance halen. 550MB/s write en 600MB/s read is theoretisch mogelijk; je zal daar misschien net iets onder zitten. Maar als je minder dan 400MB/s write zou halen zou ik dat langzaam vinden. Je hoort dus prima je performance target te bereiken. De horror-verhalen zijn afkomstig van 4K disks met smerige partities of non-optimale configuraties (zoals 6 disk RAID-Z).

[Voor 9% gewijzigd door Anoniem: 15758 op 09-07-2011 19:44]

[ufear]

ZFS is niet echt mijn specialiteit maar wil toch even reageren, heb pas wel een soortgelijk machine gebouwd voor op kantoor; dan wel met een P410/512Mb/BBWC controller en dat werkt echt als een trein.

Ik wil je even waarschuwen dat je gekozen voeding standaard NIET gaat werken met je gekozen moederbord (X9SCM-F) gezien deze echt een EPS-voeding nodig heeft; met een kabel van 12V ATX naar EPS werkt het wel, maar lijkt me niet optimaal. Zou dus zeker gezien je aantal schijven een ietwat sterkere voeding met EPS ondersteuning kiezen.

Verder is de X9SCM-F een zeer mooi bord met fijne webinterface/iKVM, draait ook ESXi zonder problemen! Succes met je systeem

[Megalith]

Hmm, interesssant

Vast staat wel, vanwege de beperkingen van Solaris, dat ik FreeNAS ga draaien. Array expanding is niet heel erg belangrijk voor mij. De 2,2 TB die ik nu heb is ook al bijna een collectie van 2 jaar dus met 6 of 8 TB ga ik het heel lang uithouden.

Features als dedup, encryptie en dat soort zaken ben ik waarschijnlijk helemaal niet nodig. Het is belangrijk dat er een machine staat met veel opslagcapaciteit die snel en redundant is. Het enigste wat me van RAIDZ(2) weerhoudt zijn de verschillen in read/write speed. Gertjan heeft het erover dat de array nooit sneller zal zijn dan één fysieke harde schijf, maar de 400/500 MBps van cipher is nogal een enorm verschil. (je hebt het hier wel over megabytes toch?)

Ik ben nu op een virtuele testbak even FreeNAS aan het proberen en het ziet er allemaal erg gelikt uit. Die BeQuiet voeding heb ik trouwens laten vallen, dat wordt nu een Corsair HX650, die wel EPS ondersteunt .

Naast de 8TB datapool zal ik ook vier 250GB schijven in RAID0 zetten. Omdat deze geen gebruik van pariteit maakt kun je hier die SSD niet voor inzetten ofwel?

EDIT: ik zal die twee blogs even doorlezen.

Ik weet nog niet zeker van wat voor een volume de server moet gaan booten. Ik heb over USB nagedacht maar één (of twee) laptopschijven lijkt me veiliger, in RAID1 dan. Die RAID1 array zou ik dan aan kunnen maken in freenas en daarna er vanaf kunnen booten?

[Voor 12% gewijzigd door Megalith op 09-07-2011 20:33]

[Gertjan]

Leuke discussie . Wellicht meer iets voor het algemene ZFS-topic in NOS, maar we zien wel waar we uitkomen.

Anoniem: 15758 schreef op zaterdag 09 juli 2011 @ 19:40:
RAID10 is niet zo heel veilig hoor. Stel je hebt één failed disk dan kun je al kapotte files hebben door bad sectors op de remaining disk. Met RAID-Z2 is je data vrijwel indestructable, omdat je 2 redundante bronnen voor alle data hebt.

Klopt, regelmatig scrubben dus . Maar ik heb liever wat corrupte files dan een unrecoverable pool. Bij 4+ disks is RAID-10 de veiligste optie.

Anoniem: 15758 schreef op zaterdag 09 juli 2011 @ 19:40:
RAID10 gaat snel zijn qua lezen (bijna net zo snel als RAID0 onder ZFS) maar qua schrijven is het langzamer dan RAID-Z of RAID-Z2. Qua random reads en writes wel stukken sneller dan RAID-Z/2

[...]

Je mag daar wel bij vertellen dat dit geldt voor random I/O; niet voor sequential I/O! Je random reads en writes zijn dus in principe gelijk aan dat van een enkele disk.

Mja, wanneer kun je profiteren van de snelheid van sequential I/O? Bij het lezen en schrijven van grote bestanden of streaming media, met 1 client. Als de belasting iets complexer wordt (meerdere clients, andere usage, verlies je al je voordeel. Het gros van de I/O is random, dus kun je daar beter op voorbereid zijn als performance een van je eisen is: RAID-10 doet zowel sequential als random I/O goed, RAIDZ zal alleen goed presteren bij sequentiele I/O.
Ik moet zeggen dat ik niet heel veel ervaring heb met het hosten van VM's, maar ik zou dat zeker onder random I/O scharen.

@TS: lees in elk geval
deze en deze blogposts even door voor wat achtergrondinformatie over RAIDZ versus mirroring.

Omdat:
1) solaris smerige partities gebruikt die op sector 63 beginnen; net zoals Windows XP doet (iew!)
2) solaris geen sector size boven de 512 bytes native ondersteunt (hardcoded)
3) solaris geen GEOM framework heeft om van een 512 byte sectorsize disk een 4K native sectorsize disk te maken

Dit zijn allemaal beperkingen van het Solaris platform. Als je voor Solaris wilt gaan is het handig je pool aan te maken onder FreeBSD met het geom trucje; dan importeren in Solaris.

Yep, dat klopt. Wij gebruiken alleen SAS-disks voor onze ZFS-servers, met het OS op twee dedicated disks in RAID-1. Dergelijke beperkingen heb ik dus geen last van. Het trucje met FreeBSD kende ik niet, hoe verstandig is dat met het oog op eventuele problemen die je later in Solaris kunt krijgen, en het debuggen? Partities, labels, slices, etc? Heb je hier misschien een linkje over?

Daarnaast geldt dat sommige configuraties met 4K disks van nature goed performen, zoals:
- 6 of 10 disk RAID-Z2 (4 of 8 data disks)
- 5 of 9 disk RAID-Z (4 of 8 data disks)

Wat is goed? Ten opzichte van RAIDZ2 met 7 disks? Of ten opzichte van RAID-10 met 6 disks? Ik ben erg nieuwsgierig naar de onderliggende redenen, heb je daar meer info over?

Kun je dat onderbouwen? Ik denk dat dedup voor het gros van de consumenten niet interessant is; maar je kunt het voor kleine datasets zeker overwegen. Bijvoorbeeld als je meerdere VMs hebt met grotendeels identieke data; dan kun je heel goed dedup op die dataset activeren.

Nee, ik kan het niet onderbouwen met hard bewijs, maar kan wel uit ervaring spreken. Juist bij VM's kan het verleidelijk zijn om te deduppen, omdat je veel dezelfde data zal hebben. Ik heb op onze ZFS-servers echter filesystems van een paar 100 GB gehad die dedup aan hadden staan. Het verwijderen daarvan kan letterlijk uren duren, omdat ZFS voor elk block dat het moet verwijderen moet bekijken of het nog in een andere dataset gebruikt worden. Ik kan je vertellen: een drukke fileserver vindt dit niet cool.
Verder zou ik eens op de zfs-discuss mailinglist rondkijken. Verschillende mensen raden af om het te gebruiken op serieuze fileservers.
Begrijp me niet verkeerd: de dedup-implementatie van ZFS werkt en is stabiel. Ik kan je echter op een briefje geven dat je ooit een moment krijgt waarop je denkt 'had ik het maar nooit aangezet' .

Weet je wel bewust van de beperkingen van het Solaris platform. Zo kun je SSD niet veilig voor zowel cache (L2ARC) als buffer (SLOG) gebruiken. En zit je met het probleem van 4K disks onder Solaris. Ook kun je niet booten van je RAID-Z/2 pool. Verder wel een goede keuze; alhoewel het natuurlijk niet/nauwelijks open source is en een beperkte (maar sterke) community heeft.

Goede punten. Eén SSD voor zowel read als writecache vind ik sowieso een vrij vieze oplossing . En je writecache wil je eigenlijk wel gemirrored hebben. Booten van de pool kan inderdaad wel belangrijk zijn. Topicstarter, is dat een vereiste? Of heb je nog een losse bootdisk?

Ook is het handig je ZFS pool versie ietwat laag te houden (i.e. niet boven de 28) zodat je kunt switchen tussen BSD en Solaris platform.

Dat is een goede tip, zeker doen! Upgraden kan altijd nog als je bepaalde features echtechtecht wil gebruiken, downgraden kan niet. 28 is een prima versie waarmee je zowel met BSD, Nexenta als OpenIndiana uit de voeten kan, en weinig belangrijke features mist.

Met 6x RAID-Z2 in FreeBSD of optimale config onder Solaris kun je goede performance halen. 550MB/s write en 600MB/s read is theoretisch mogelijk; je zal daar misschien net iets onder zitten. Maar als je minder dan 400MB/s write zou halen zou ik dat langzaam vinden.

In benchmarks: ja, dan zul je waarschijnlijk de 400+ wel aantikken bij tests op sequentiele I/O. IRL? Meh

[Gertjan]

fcg123 schreef op zaterdag 09 juli 2011 @ 20:12:
Vast staat wel, vanwege de beperkingen van Solaris, dat ik FreeNAS ga draaien.

Op basis van welke beperkingen besluit je dit? (Sorry, ben beetje Solaris-fan )

Gertjan heeft het erover dat de array nooit sneller zal zijn dan één fysieke harde schijf, maar de 400/500 MBps van cipher is nogal een enorm verschil. (je hebt het hier wel over megabytes toch?)

Zoals cipher al aangaf is het belangrijk om te weten of je over random of sequentiele I/O praat. In mijn ervaring is het real-life gebruik van zo'n systeem altijd random, tenzij je de enige gebruiker bent en alleen films erop kopieert en afspeelt (parren en unrarren zou alweer vrij random worden ).

Naast de 8TB datapool zal ik ook vier 250GB schijven in RAID0 zetten. Omdat deze geen gebruik van pariteit maakt kun je hier die SSD niet voor inzetten ofwel?

Een SSD (zowel read- als writecache) kan altijd slechts door 1 zpool gebruikt worden. In elk geval in Solaris, misschien kun je in FreeBSD met partitionering wel verschillende partities aan verschillende pools hangen, dat weet ik niet.
Writecache hangt altijd aan de hele pool, bij readcache kun je per filesystem aangeven of die de readcache mag gebruiken (l2arc).

[Megalith]

Ik zet me een beetje af van Solaris vanwege het feit dat ik 4k schijven heb en het spul wil installeren, neerzetten en er verder geen omkijken meer naar heb. Daarmee doel ik vooral op deze drie punten:

1) solaris smerige partities gebruikt die op sector 63 beginnen; net zoals Windows XP doet (iew!)
2) solaris geen sector size boven de 512 bytes native ondersteunt (hardcoded)
3) solaris geen GEOM framework heeft om van een 512 byte sectorsize disk een 4K native sectorsize disk te maken

De oplosing zou dan kunnen zijn om een pool te maken in freenas en dan exporteren naar een Solaris platform, maar dat soort dingen wil ik eigenlijk vermijden met deze storage server. Klooien doe ik wel in Hyper-V

Ik heb er inderdaad voornamelijk films op staan, maar ook software, muziek en foto's. Rarren en parren horen daar ook bij inderdaad . Het zal in totaal door circa vier personen gebruikt worden maar met name door mij. Het komt bijna nooit voor dat bepaalde bestanden door meerdere gebruikers tegelijk gelezen/geschreven worden.

EDIT: ik zal die twee blogs even doorlezen.

Ik weet nog niet zeker van wat voor een volume de server moet gaan booten. Ik heb over USB nagedacht maar één (of twee) laptopschijven lijkt me veiliger, in RAID1 dan. Die RAID1 array zou ik dan aan kunnen maken in freenas en daarna er vanaf kunnen booten?

[Anoniem: 15758]

ufear schreef op zaterdag 09 juli 2011 @ 19:48:
ZFS is niet echt mijn specialiteit maar wil toch even reageren, heb pas wel een soortgelijk machine gebouwd voor op kantoor; dan wel met een P410/512Mb/BBWC controller en dat werkt echt als een trein.

Dat is wel een heel andere setup. Met een RAID controller gebruik je ZFS dus in feite als een non-redundante single-disk pool. Nadeel hiervan is dat veel unieke ZFS-features verloren gaat. Zo kan ZFS niet de redundante metadata op andere disks plaatsen; omdat het geen weet heeft van op welke fysieke disk de data staat. Zo'n RAID array wordt door ZFS gezien als een enkele disk. Ook kun je hierdoor geen redundante data gebruiken om bad sectors mee te fixen; en geef je de integriteit van de RAID uit handen aan de RAID controller. De RAID controller kan geen onderscheid maken tussen corrupte en niet-corrupte data. Als de data corrupt is en de parity niet, dan zal de controller de parity overschrijven met parity gebaseerd op de corrupte data; en dus juist de enige bron van niet-corrupte data vernietigen.

Voordeel is wel dat je host minder RAM en kracht moet hebben; ZFS hoeft zelf geen read-ahead uit te voeren of write buffering; de RAID controller verzorgt de performance en dus kun je met veel minder RAM af.

fcg123 schreef op zaterdag 09 juli 2011 @ 20:12:
Het enigste wat me van RAIDZ(2) weerhoudt zijn de verschillen in read/write speed. Gertjan heeft het erover dat de array nooit sneller zal zijn dan één fysieke harde schijf, maar de 400/500 MBps van cipher is nogal een enorm verschil. (je hebt het hier wel over megabytes toch?)

Dat 'niet sneller dan een enkele disk' gaat alleen over random I/O; dus als je een 10 disk RAID-Z2 hebt zonder SSD dan:

1) heb je 1200MB/s sequential read (bij voldoende RAM voor prefetching)
2) heb je 800MB/s+ sequential write (bij voldoende RAM voor grote transaction groups)
3) heb je de random read prestaties van een enkele disk
4) heb je de random write prestaties van een enkele disk

Merk op dat een normale RAID5 een veel lagere random write heeft dan dat van een enkele disk; RAID-Z heeft dus van nature een voordeel dat het ongeveer gelijk is aan de IOps van een enkele disk; maar heeft weer een nadeel met lagere random reads t.o.v. traditioneel RAID5.

Maargoed, gebruik je dus een SSD voor L2ARC+SLOG dan heb je dit nadeel niet meer en heb je de voordelen van zowel HDD (hoge doorvoer) en SSD (hoge random I/O). Dat zijn dé killer ZFS features.

Naast de 8TB datapool zal ik ook vier 250GB schijven in RAID0 zetten. Omdat deze geen gebruik van pariteit maakt kun je hier die SSD niet voor inzetten ofwel?

Jawel; geldt hetzelfde voor. 4x RAID0 heeft de random I/O prestaties vier keer zo hoog als een enkele disk; maar dat is nog steeds weinig vergeleken met wat je SSD kunt doen. Maar om heel eerlijk te zijn; qua stroomverbruik is dit niet erg economisch. Je kunt evengoed je VMs op je RAID-Z2 zetten en versnellen met je SSD; desnoods koop je een 2e SSD extra ofzo als je echt brute random I/O snelheid wilt hebben.

Alleen voor non-ZFS zouden die 4 disks in RAID0 wel fijn zijn omdat je dan random I/O versnelt. Maar 4x 80 IOps is nog steeds niks vergeleken met de 35.000 IOps van een enkele SSD. Qua random write kun je rekenen op 4000 IOps ofzo; nog steeds ver boven dat van hardeschijven.

Ik weet nog niet zeker van wat voor een volume de server moet gaan booten. Ik heb over USB nagedacht maar één (of twee) laptopschijven lijkt me veiliger, in RAID1 dan. Die RAID1 array zou ik dan aan kunnen maken in freenas en daarna er vanaf kunnen booten?

Ja maar is dat nodig? Zo'n zonde daar twee HDDs voor te gebruiken voor een paar honderd MB. Een USB stick gaat juist perfect met FreeNAS. Je kunt altijd de USB stick klonen. Bovendien schrijft FreeNAS niet/nauwelijks naar de USB stick; het gebruikt een memory filesystem daarvoor. Alleen je configuratie/settings van FreeNAS zelf worden op USB opgeslagen.

[Anoniem: 15758]

Gertjan schreef op zaterdag 09 juli 2011 @ 20:25:
Leuke discussie . Wellicht meer iets voor het algemene ZFS-topic in NOS, maar we zien wel waar we uitkomen.

ZFS thread staat ook in OM; is een alias gemaakt in NOS. Maar ik ben bezig de topicstart uit te breiden met extra info; dus dat komt wel goed.

Klopt, regelmatig scrubben dus . Maar ik heb liever wat corrupte files dan een unrecoverable pool. Bij 4+ disks is RAID-10 de veiligste optie.

Als je pech hebt en tijdens het rebuilden van één mirror de overblijvende disk in die mirror het ook begeeft, is je hele pool naar de klote. Bij RAID6 / RAID-Z2 kun je twee willekeurige disk failures hebben zonder dat je data hoeft te verliezen. Dus ik zou een RAID6 / RAID-Z2 zeker als veiliger beschouwen als een mirror ofwel RAID10.

Voordeel van de mirror is zoals je al noemde het makkelijk uitbreiden met 2 schijfjes tegelijk en het feit dat je random IOps beter schaalt (zonder SSDs) en kortere rebuildtijden en minder CPU overhead. Maar voor thuisgebruikers is RAID-Z1/2 erg interessant.

Mja, wanneer kun je profiteren van de snelheid van sequential I/O? Bij het lezen en schrijven van grote bestanden of streaming media, met 1 client. Als de belasting iets complexer wordt (meerdere clients, andere usage, verlies je al je voordeel. Het gros van de I/O is random, dus kun je daar beter op voorbereid zijn als performance een van je eisen is: RAID-10 doet zowel sequential als random I/O goed, RAIDZ zal alleen goed presteren bij sequentiele I/O.
Ik moet zeggen dat ik niet heel veel ervaring heb met het hosten van VM's, maar ik zou dat zeker onder random I/O scharen.

Voor thuisgebruik is sequential I/O de belangrijkste spec; veel mensen slaan met name grote bestanden op. En bestanden van 1MB+ valt al onder sequential I/O. Voor die VMs doe je inderdaad vooral random reads en writes; daar heb je dan je SSDs voor.

Overigens interessant: in ZFS pool versie 31 heb je hybrid allocator; wat de metadata mirrort ipv in de parity RAID integreert. Dat is fijn omdat je hiermee random reads (zonder SSDs) al een stuk sneller maakt op RAID-Z1/2/3 zodra deze van metadata afhankelijk zijn. Bedenk bijvoorbeeld het zoeken op je RAID-Z waarbij je voornamelijk metadata opvraagt. Helaas nog niet beschikbaar in BSD platforms.

Yep, dat klopt. Wij gebruiken alleen SAS-disks voor onze ZFS-servers, met het OS op twee dedicated disks in RAID-1. Dergelijke beperkingen heb ik dus geen last van. Het trucje met FreeBSD kende ik niet, hoe verstandig is dat met het oog op eventuele problemen die je later in Solaris kunt krijgen, en het debuggen? Partities, labels, slices, etc? Heb je hier misschien een linkje over?

Trucje van in FreeBSD pool aanmaken met GEOM truc en dan in Solaris importeren zorgt ervoor dat je pool wordt aangemaakt met 'ashift=12' ipv 'ashift=9'; dat laatste betekent dat ZFS de disks behandelt als sectorsize 512-bytes; ashift=12 is geoptimaliseerd voor 4K sector disks. (2^12 = 4096 bytes)

Dat werkt zo:
1) je maakt onder FreeBSD een disk aan met GNOP met een andere sectorsize:
gnop create -S 4096 /dev/ada1
2) nu heb je een /dev/ada1.nop device; de .nop toevoeging is de schijf die een sectorsize van 4096 bytes heeft, dit kun je controleren met: diskinfo -v /dev/ada1.nop
3) nu maak je een pool aan:
zpool create tank raidz /dev/ada1.nop /dev/ada2 /dev/ada3 /dev/ada4
4) nu controleer je ashift=12 (vervang tank door de naam van de pool)
zdb -e tank | grep ashift
4) nu exporteer je de pool
zpool export tank
5) nu switch je naar Solaris en je pool zou prima moeten werken en geoptimaliseerd voor 4K disks

Onder Solaris heb je wel een aangepaste binary die alle pools als ashift=12 beschouwt; dit kan bestaande pools corrumperen en de hele pool vernietigen; dat is dus gewoon onveilig en moet je dus gewoon niet doen! De methode hierboven is 100% veilig. Aangezien Solaris niet correct GPT partities ondersteunt heb ik het alleen getest door geen partities te gebruiken; maar je zou eventueel goed-alignde MBR paritites (start offset 2048 sectors van 512-bytes = 1MiB) kunnen gebruiken.

Wat is goed? Ten opzichte van RAIDZ2 met 7 disks? Of ten opzichte van RAID-10 met 6 disks? Ik ben erg nieuwsgierig naar de onderliggende redenen, heb je daar meer info over?

Dit is een vrij technisch verhaal, maar here goes:

RAID-Z werkt heel apart; het is meer een RAID3 dan een RAID5. Traditioneel RAID5 heeft namelijk read-modify-write cycles die vaak bij random writes voorkomen; bij RAID-Z bestaan zulke cycles niet! Dat betekent wel dat elke I/O request alle disks zal betrekken in de I/O - vandaar ook dat je bij RAID-Z maar de performance van een enkele disk hebt bij random I/O; heel anders dan RAID5 waarbij de random reads bijna zo hoog zijn als RAID0 en random writes juist veel lager dan een enkele disk door de read-modify-write cycles.

RAID-Z verspreidt de recordsize (128KiB) uit over alle data disks (totale disks minus parity) dus bij een 7x RAID-Z2 heb je een slechte configuratie voor 4K sector disks:
7-2 = 5 data disks en 128KiB / 5 = 25.6KiB wat een raar getal is; en dus soms 25.5KiB en soms 26.0KiB wordt afgerond door de 512-byte sectors. Beide zijn heel slecht voor 4K sector disks; vandaar dat je flink lagere performance krijgt.

Bij een 6-disk RAID-Z2 heb je 4 data disks en dus 128KiB / 4 = 32KiB wat een exacte breuk is en een veelvoud van 4KiB sectors; dat werkt dus perfect zonder problemen.

Deze 'beperking' geldt alleen voor RAID-Z en niet voor mirroring. Het komt er dus op neer dat je optimale configuraties wilt hebben bij RAID-Z1/2/3 en 4K sector schijven:
- 2 data disks: 3-disk RAID-Z of 4-disk RAID-Z2 of 5-disk RAID-Z3
- 4 data disks: 5-disk RAID-Z of 6-disk RAID-Z2 of 7-disk RAID-Z3
- 8 data disks: 9-disk RAID-Z of 10-disk RAID-Z2 of 11-disk RAID-Z3

Als je een sub-optimale configuratie gebruikt, is het truucje met ashift=12 zoals hierboven besproken een grote aanrader; anders kun je lage performance verwachten.

Juist bij VM's kan het verleidelijk zijn om te deduppen, omdat je veel dezelfde data zal hebben. Ik heb op onze ZFS-servers echter filesystems van een paar 100 GB gehad die dedup aan hadden staan. Het verwijderen daarvan kan letterlijk uren duren, omdat ZFS voor elk block dat het moet verwijderen moet bekijken of het nog in een andere dataset gebruikt worden. Ik kan je vertellen: een drukke fileserver vindt dit niet cool.

Had je wel genoeg RAM + L2ARC op de dataset? Die de-dup tables moeten namelijk in RAM+L2ARC passen; als de mechanische disks daarvoor moeten worden betrokken dan gaat het even snel als stront door een trechter. Maar in mijn geval kon ik toch vrij deftige performance halen; maar ik heb dan ook geen echt drukke VMs die veel random writes doen. Toch zou ik zeggen: probeer het nog eens met veel RAM én L2ARC; dan zou dedup met verify aan toch redelijk goed moeten werken. Wel is het zo dat je (zeker met verify) beter reads kunt doen dan writes/modifies.

De-dup op honderden gigabytes data is enorm zwaar en heb je serieus veel RAM + L2ARC voor nodig. L2ARC alleen heeft ook extra RAM nodig; dus reken op 64GiB RAM. Dan kom je dus in de buurt van een serieuze enterprise server en dat valt een beetje buiten de scope van deze thread/forum.

Ben wel mee eens dat de-dup voor thuisgebruikers eigenlijk niet interessant is.

Eén SSD voor zowel read als writecache vind ik sowieso een vrij vieze oplossing . En je writecache wil je eigenlijk wel gemirrored hebben.

Hoezo vies? Het wordt afgeraden alleen omdat Solaris hier een hele belangrijke beperking heeft; Solaris kan op een SSD met meerdere partities (één voor L2ARC ander voor SLOG) geen FLUSH commando's sturen; die zijn cruciaal om de integriteit van je data te garanderen. Dus deze setup is alleen veilig onder FreeBSD die een heel mooi GEOM framework heeft die alle 'chains' in de GEOM-chain netjes de flush commando's kan doorsturen.

Mirroren klinkt leuk, maar SSDs zonder supercapacitors die stroom verliezen kunnen allebei tegelijk of stuk of corrupt raken. Dus dat is gewoon geen echte oplossing. Neem een Intel 320 als je SLOG wilt gebruiken dan heb je een VEILIGE SSD zonder risico van een corrupte pool.

De meest veilige oplossing is FreeBSD met één of meerdere Intel 320 SSDs voor zowel L2ARC als SLOG (en andere storage eventueel zoals je VMs/ZVOLs/iSCSI). De Intel 320 heeft én redundant NAND én supercapacitors; twee features die de Intel X25-M niet hebben. Met recht is dit dus dé SSD voor gebruik van SLOG. L2ARC is veel veiliger; corrupte data op je SSD wordt gedetecteerd en dan alsnog van HDD pool gelezen, dus daar geldt bovenstaand advies niet/minder voor.

28 is een prima versie waarmee je zowel met BSD, Nexenta als OpenIndiana uit de voeten kan, en weinig belangrijke features mist.

Enige leuke feature hierboven is de hybrid allocator (31 dacht ik) - maar volgens mij is ZFS v28 de laatste versie onder CDDL uitgebracht. Nu is het aan IllumOS en FreeBSD om ZFS verder te ontwikkelen. Zolang deze ontwikkelingen de on-disk data format niet veranderen blijft het volledig cross-compatible met Solaris.

Enige wat ik nog wel wil zien is block-pointer rewrite zodat je kunt defragmenteren en top-level vdevs kunt verwijderen en RAID-Z's kunt expanden/shrinken. Voor enterprise gebruikers niet zo heel belangrijk, maar voor sommige thuisgebruikers wel een obstakel om ZFS te gebruiken, helaas. Deze feature zal wel door Oracle moeten gebeuren ben ik bang; want daar zal zeker de on-disk data format voor verandert moeten worden.

[Oid]

Dat werkt zo:
1) je maakt onder FreeBSD een disk aan met GNOP met een andere sectorsize:
gnop create -S 4096 /dev/ada1
2) nu heb je een /dev/ada1.nop device; de .nop toevoeging is de schijf die een sectorsize van 4096 bytes heeft, dit kun je controleren met: diskinfo -v /dev/ada1.nop
3) nu maak je een pool aan:
zpool create tank raidz /dev/ada1.nop /dev/ada2 /dev/ada3 /dev/ada4
4) nu controleer je ashift=12 (vervang tank door de naam van de pool)
zdb -e tank | grep ashift
4) nu exporteer je de pool
zpool export tank
5) nu switch je naar Solaris en je pool zou prima moeten werken en geoptimaliseerd voor 4K disks

Kan je dat ook nog doen wanneer je raidz2 al bestaat, of moet je dan opnieuw beginnen?

De meest veilige oplossing is FreeBSD met één of meerdere Intel 320 SSDs voor zowel L2ARC als SLOG (en andere storage eventueel zoals je VMs/ZVOLs/iSCSI). De Intel 320 heeft én redundant NAND én supercapacitors; twee features die de Intel X25-M niet hebben. Met recht is dit dus dé SSD voor gebruik van SLOG. L2ARC is veel veiliger; corrupte data op je SSD wordt gedetecteerd en dan alsnog van HDD pool gelezen, dus daar geldt bovenstaand advies niet/minder voor.

Wanneer je 6x 2TB heb, is dan een 40GB SSD genoeg hiervoor? Of wat is aan te raden?

[Voor 27% gewijzigd door Oid op 10-07-2011 10:56]

[Anoniem: 15758]

Je kunt de ashift niet verhogen van een bestaande pool. Merk ook op dat alle huidige ashift=9 (default) pools geen disks met native 4 kilobyte sectorsize kunnen verdragen; de sectorsize moet gelijk zijn of lager dan de huidige disks in de pool.

Merk ook op dat alle huidige 4K sector disks in feite 512 byte sector disks zijn die intern de sectorsize naar 4K vertalen; ofwel 4K sector disks met 512-byte emulation. Zo blijven ze compatible met 512-byte sectorsize disks en OSen die dit verwachten.

40GB is in principe genoeg. Je hebt 2-4GB voor SLOG nodig en 36GB aan L2ARC is al een behoorlijke hoeveelheid. Maar het grootste nadeel is dat de 40GB SSDs een stuk langzamer zijn. De Intel 320 doet dan zo'n 45MB/s write; wat beperkt is. De Intel 320 120GB is de sweet spot maar ook een stuk duurder. Eventueel kun je ook de 80GB versie overwegen. Maar die 40GB zal al enorm veel performance verschil geven met helemaal geen SSD.

[Megalith]

Als ik zo'n ZFS setup zou gaan bestellen zou ik er een 80GB Intel 320 SSD instoppen. Die ga ik 50/50 verdelen over de twee pools (data en virtuele machines pool). Dan blijft er een kleine 40GB voor elke pool over. De datapool zal wel genoeg hebben aan die 40GB. Op dit moment heb ik ongeveer vijf virtuele machines actief met elk een VHD van ca. 20GB. Is ZFS slim genoeg om een deel van die 20GB af te "snijden" en in cache te zetten? Op die manier zou je veel meer machines kunnen versnellen, en zou ik één of twee van die energieslurpende RE4 schijven weg kunnen laten.

Heb afgelopen dagen de server omgezet naar een 19" chassis en in een nieuw aangekocht rack geplaatst, dus het geld is voorlopig eventjes op. Ik ben nu drie WD GP 1TB schijven aan het testen onder Windows Server 2k8 RAID5, maar hij is al twee dagen bezig met bouwen. Ik ga er niet vanuit dat het performed, en het is verre van ideaal denk ik, maar wil het toch even proberen. Daarna ga ik proberen de 3 schijven te pass-troughen naar een VM met FreeNAS en kijken hoe een RAIDZ pool dan presteert.
De storage op virtueel laten draaien is natuurlijk veel goedkoper en zuiniger maar bare metal draaien is voor m'n gevoel toch veiliger. Ik ga me hier toch eens wat meer in verdiepen.

[Anoniem: 15758]

Op dit moment heb ik ongeveer vijf virtuele machines actief met elk een VHD van ca. 20GB. Is ZFS slim genoeg om een deel van die 20GB af te "snijden" en in cache te zetten?

Ik snap niet helemaal wat je bedoelt. L2ARC werkt geheel transparant. ZFS kijkt welke datablokken er vaak worden opgevraagd. Alleen die data die vaak random wordt opgevraagd zal in de L2ARC terecht komen, inclusief metadata wat je nodig hebt om snel door alle files/dirs te kunnen zoeken. ZFS regelt dus helemaal zelf welke data gecached wordt en welke niet; alhoewel je caching voor specifieke datasets wel expliciet kunt in- of uitschakelen.

Wel geldt dat L2ARC per pool gaat; als je je SSD dus voor twee pools wilt gebruiken moet je je SSD partitioneren. Dat moet je sowieso als je wilt dat je SSD ook als een SLOG functioneert.

In jouw geval zou ik het als volgt doen:
- 10GB L2ARC voor je data pool (2TB disks)
- 10GB L2ARC voor je VM pool (250GB disks)
- 4GB SLOG voor je data pool
- 4GB SLOG voor je VM pool
- 40GB primary storage ("ssd" pool)
- 10GB unpartitioned als extra spare space

De L2ARC hoef je dus niet zo groot te maken; alleen de random I/O komt hierop. Merk op dat je voor L2ARC ook al snel veel extra geheugen kwijt bent. Ik ben even mijn lijstje kwijt; maar afhankelijk van hoe klein je requests zijn heb je al snel meerdere gigabytes RAM nodig voor een 40GB L2ARC. 10GB is eigenlijk al een grote hoeveelheid waar je ontzettend veel gegevens mee kunt accelereren. 10TB met 20GB L2ARC kan een prima balans zijn; het hangt er vanaf hoe veel data op je HDD pool random wordt ingelezen. Bij je VM images is dat een groot percentage; maar voor mixed data kan het minder dan 1% zijn van de totale opslag.

In het voorbeeld hierboven heb ik 40GB als primary dataset aangehouden; dat houdt in een normale pool. Eigenlijk denk ik dat je je 250GB schijven achterwege kunt laten en deze VMs direct op je SSD opslaan dan heb je dus één data pool met 2TB schijven en één pool met je SSD voor de VM images. Eigenlijk zijn er drie opties:


Optie 1 - je originele plan
1) data pool met 2TB disks met:
- 20GB L2ARC
- 4GB SLOG
2) VM pool met 250GB disks met:
- 20GB L2ARC
- 4GB SLOG
(de rest van de ruimte op de SSD als spare space laten)


Optie 2 - mijn favoriet; ditch de 250GB disks
1) data pool met 2TB disks met:
- 10GB L2ARC
- 4GB SLOG
2) SSD pool voor je VM images (geen L2ARC of SLOG nodig)


Optie 3 - een combinatie van bovenstaande twee
1) data pool met 2TB disks met:
- 40GB L2ARC
- 4GB SLOG
(slechts één pool waarop ook je VM images komen te staan; je vertrouwt op de SSD om de hele pool te versnellen maar de VM images staan dan dus op je 2TB disks)


Elke optie zal je prima performance kunnen geven; L2ARC + SLOG met voldoende RAM betekent dat je van de beste eigenschappen van SSDs en HDDs gebruik maakt: SSDs voor de random I/O en HDDs voor de sequential I/O.

Op zich maakt partities op je SSD niet uit; mits ze aligned zijn. Je draait geen Solaris dus partities op je SSD betekent geen veiligheidsrisico. Ook zal het geen performance probleem zijn voor de SSD om dingen tegelijk te doen; dat kunnen SSDs prima! Echter is wel één probleem. De Hyper-V oplossing. Voor zover weet kun je alleen als IDE draaien met FreeBSD/FreeNAS onder Hyper-V en dat betekent dus oudere IDE drivers en geen features als hot-plug, TRIM en het belangrijkste: NCQ. Dat laatste is cruciaal zodat de SSD meerdere I/O tegelijkertijd kan verwerken. De Intel controller heeft 10 kanalen maar zonder NCQ kun je er maar één gebruiken. Alleen sequential I/O kunnen meerdere kanalen gebruiken omdat daarvoor geen NCQ nodig is door de read-ahead prediction. L2ARC zal dus een performance-hit krijgen van het gebrek aan NCQ.

Je kunt zien aan de device naming of je IDE of AHCI draait. IDE disks krijgen /dev/ad4 bijvoorbeeld en AHCI disks krijgen dan /dev/ada4; dus ada in plaats van ad.

Zelf zou ik FreeNAS dus niet virtualizen; maar je kunt het proberen natuurlijk. Ook adviseer ik je om veel ruimte van je SSD niet te gebruiken! Door alle random writes heb je namelijk veel spare space nodig - dat doe je door ruimte op je SSD niet te gebruiken en het liefst dus ook niet te partitioneren. Als je partities gebruikt, gebruik dan GPT partities normale MBR partities zijn beperkt in functionaliteit. Waarschijnlijk wil je de SSD handmatig onder SSH configureren en dus niet via de FreeNAS web-gui.

Genoeg stof tot nadenken.