Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 110, views: 176.803 •

Conclusie

Het Zettabyte File System is uniek door de integratie van bestandssysteem en volumemanager, de goede bewaking van data-integriteit, de zelfreparerende eigenschappen, de ondersteuning van snapshots en deduplicatie, en de mogelijkheid om ssd's voor caching in te zetten. Zfs mag zich daarom met recht een van de meest geavanceerde bestandssystemen van dit moment noemen.

In combinatie met het Comstar-framework kunnen er eenvoudig scsi-targets opgezet worden die via diverse soorten interfaces, zoals ethernet, fibrechannel en serial attached scsi, toegankelijk gemaakt kunnen worden. Storage area networks zijn in het bedrijfsleven al langer onmisbaar, en op kleinere schaal kunnen ze ook in thuisnetwerken hun nut bewijzen. Door opslag te consolideren kunnen capaciteit en prestaties beter benut worden, en is het mogelijk om een stil en compact werkstation te bouwen dat toch toegang heeft tot vele terabytes aan storage.

Onze benchmarks wijzen uit dat een zfs-san prestaties kan halen die vergelijkbaar of beter zijn dan die van direct aangesloten harde schijven. Met behulp van low-power-harddisks, voldoende werkgeheugen en een snelle cache-ssd zijn er prestaties mogelijk op het niveau van eerstegeneratie-ssd's. Dat is een prima prestatie, zeker omdat de topologie van een storage area network veel complexer is dan die van direct aangesloten opslag, en omdat zfs zich met onder andere checksums meer werk op de hals haalt dan een normaal bestandssysteem.

Met het gebruik van ssd's voor read caching wordt een belangrijke beperking van normale raidsystemen op basis van harde schijven aangepakt. Die systemen presteren alleen beter met sequentiële of gelijktijdige i/o. Door de hoge toegangstijden van harde schijven schalen de prestaties slecht bij willekeurige transfers met een lage concurrency, zoals die bijvoorbeeld op bootdrives plaatsvinden. Ssd's excelleren in dergelijke workloads, en zfs kan de sterke eigenschappen van ssd's combineren met de lage kosten per gigabyte van harde schijven. De hardwarekosten zijn bovendien lager omdat zfs geen raid-controller nodig heeft. In systemen met veel disks kunnen er zo honderden euro's bespaard worden.

Het beheer van zfs via de command-line is goed te doen voor iedereen die basale kennis van unix-besturingssystemen heeft. Voor tweakers die de command-line eng vinden, zijn er webbased oplossingen zoals Napp-it en het Nexenta-besturingssysteem. Tweakers die een zfs-systeem willen bouwen en ervaring hebben met conventionele raid-controllers, zullen zich echter wel vertrouwd moeten maken met een aantal eigenaardigheden van zfs.

Zo is het bijvoorbeeld niet mogelijk om de capaciteit van een vdev in een storage pool uit te breiden. Dit kan alleen door extra vdev's toe te voegen, wat minimaal twee harde schijven per keer kost om een redundante vdev te maken. Omdat de inhoud van een blok altijd over alle harde schijven in een vdev wordt weggeschreven, schalen de random i/o-prestaties minder goed dan bij normale raid 5- en raid 6-arrays. De oplossing is om een pool uit meerdere vdev's op te bouwen. Deze kunnen dan wel weer onafhankelijk van elkaar aan verschillende lees- en schrijftransacties werken.

Hoewel de testresultaten in deze review bemoedigend zijn, moet gezegd dat de resultaten zijn verkregen met een veel snellere netwerkinterface dan de gigabit-ethernetverbinding die de meeste tweakers hebben liggen. De vierpoorts 4Gbps-fibrechannel-adapters die we voor onze tests gebruikten, kunnen samen met de benodigde optische kabels op eBay bij elkaar gescharreld worden voor rond de vijfhonderd euro. Dat is veel geld om een snelle brug tussen twee systemen te bouwen. Om de vier poorten tegelijkertijd te gebruiken is er bovendien een besturingssysteem nodig met ondersteuning voor multipath-i/o. Die ondersteuning is er in onder andere Linux, OS X Lion en Windows Server 2008, maar is door Microsoft in Windows 7 weggelaten.

Er is een betaalbaardere oplossing om de gigabit-barrière te doorbreken: infiniband. Voor 200 euro is het mogelijk om twee dual-port 10Gbps-infiniband-adapters met bijbehorende kabels op de kop te tikken. Zonder multipath-i/o bieden die al een theoretische doorvoer van ongeveer een gigabyte per seconde. In het vervolg op dit artikel zullen we onderzoeken hoe gigabit-ethernet, fibrechannel en infiniband ten opzichte van elkaar presteren.


Reacties (110)

Reactiefilter:-11100109+192+213+30
1 2 3 ... 6
Wat een juweeltje van een artikel zeg. Prachtig werk. Ik denk dat ik binnenkort even wat van m'n oude hardware ga bundelen tot een mooie ZFS server aan de hand van dit artikel.
inderdaad ! dit is weer eens een echt ouderwets Tweakers-artikel ! mijn complimenten aan Femme _/-\o_
Top artikel: Na 4 pagina`s droge stof laat ik de rest even liggen tot vanavond.
Dat gebeurd me niet vaak op t.net :-)
Misschien kan Femme op de Open Storage Summit in mei ook komen vertellen over zijn ervaringen met ZFS. http://www.openstoragesummit.org/
Absoluut, mogen ze vaker doen van mij.

Zelf gebruik ik alweer dik een jaar FreeNAS met ZFS in een ESXi 5.0 omgeving.
Onder andere een 3g 8 poorts SAS van LSI in gebruik, zie mijn inventaris/server voor details.

Leuke van SAS controllers is de mogelijkheid een paar kleine 10k/15k sas schijven te kunnen combineren met goedkope grote sata schijven voor de opslag.
Helemaal mee eens, ik hoop dat we dit soort artikelen vaker gaan zien op Tweakers!
Dit is inderdaad weer een artikel van ouderwetse kwaliteit. Mooi om te zien dat het nog steeds kan!
Inderdaad het is lang geleden dat er een zo informatief artikel op tweakers te vinden was en ik vermoed dat het voor veel mensen een aanleiding zal zijn om toch eens na te denken over een SAN voor op zolder of in de kelder....

Ik hoop dat er meer artikels zullen volgen die op deze manier de techniek, de voor en de nadelen hier van zo uitvoerig en duidelijk uitleggen aan de vele tweakers die geinteresseerd zijn in dit soort oplossingen.

Ik heb me al een tijdje willen verdiepen in deze materie en ik denk dat dit artikel precies het geen is dat ik nodig heb om daar nu eindelijk eens aan te beginnen. Of ik de SSD's ook echt nodig zal hebben is een ander verhaal, ik denk dat voor de meeste huis tuin en keuken benodigdheden de opslag belangrijker is dan de snelheid die een oplossing als deze kan bieden aan de andere kant als je ruw weg 2500 euro uit geeft aan een nieuw opslag systeem voor thuis dan kun je er neem ik aan ook wel een paar SSD's bij hangen om het nog even sneller te laten gaan.
Ik denk dat bekabeling en controllers wel het kleinste probleem zijn.

In de huidige tijd zijn harde schijven bijna niet meer te betalen. Zolang daar geen drastische verandering in komt zie ik dit soort producten ook niet tot een succes uitgroeien.
Complimenten voor deze zeer uitgebreide review! ^^

Leuk zo'n systeempje, als ik nog wat geld had liggen zou ik zoiets wel willen hebben thuis! :o
Femme, leef je nog?!

Goed artikel :)
Iets wat ik graag zou zien in een vervolg artikel of anderzijds reactie is hoe dit presteert als je de storage buiten's huis plaatst. Hoe presteert dit bv als je thuis 100/100 of zelfs 1000/1000 hebt met de storage in de colo bij een provider. Nederland is klein genoeg om met minimale latency iedere provider binnenslands te bereiken. Ik denk dan aan applicaties als mediacenter of back-up doos via ZFS replicatie.

Dit kan zeer interessant zijn als je thuis niet de optie hebt om een storage server neer te zetten of simpel weg niet het lawaai en de hitte ontwikkeling wilt hebben.

Verder is dit inderdaad een erg goed artikel, erg blij te zien dat Tweakers nog steeds dergelijke stukken weet te produceren.

[Reactie gewijzigd door Sorcerer op 16 maart 2012 10:39]

Latency is echt killing voor de performance. Op ons Enterprise SAN halveerde de doorvoer toen we 30KM verderop gingen zitten (als test), terwijl de latency slechts met een paar ms toenam. Je storage wil je echt zo dicht mogelijk bij de serversystemen hebben.
let daarbij ook wel even op, twee locaties kunnen dan wel een paar km uit elkaar liggen, maar als je datastroom vervolgens via bv een provider loopt die eerst alles richting Amsterdam of waar dan ook haalt is de daadwerkelijke afstand al snel een paar honderd KM. Op een darkfiber van 30 km zou ik geen ms latency verwachten maar een aantal microseconden
Heb vergelijkbare issues meegemaakt na verhuizing van ťťn van onze datacenters naar een externe locatie (via dark-fibre gekoppeld). De doorvoer snelheid van I/O viel terug van 350MB/s naar 40MB/s!

Na uitgebreid onderzoek bleek dat een extra licentie (!) en herconfiguratie van de gebruikte poorten op onze Brocade SAN switches de oplossing hiervoor te bieden.
Toen de switch poorten op zgn. Long-Distance mode ingesteld waren (hierdoor kwamen er veel meer Buffer Credits beschikbaar op de poort groep) waren de prestaties op het oude niveau terug.

[Reactie gewijzigd door Lomu op 20 maart 2012 14:54]

Hoezo doorvoer halveerde. Doe je a-synchrone replicatie... Ik bedoel er maar mee 2 san's synchroon en 30KM verderop a-synchroon en vice versa. Het probleem zit hem in dat de SAN's op elkaar gaan wachten en dat wil je niet. Het enige probleem is dat als je de data op meerdere locaties tegelijk benaderd je waarschijnlijk een cluster filesystem moet hebben maar goed dat is weer een ander verhaal.

Greetzzz,

Netranger1989
De prestaties zullen veel lager zijn dan een lokaal netwerk maar voor bijv. incrementele backups of het streamen van video kan het voldoende zijn. Wellicht dat ik er nog een keer naar ga kijken (dan vooral vanuit de insteek van online backup en eventueel een vergelijking met commerciŽle diensten).
Wat ik er nog wel een keer bij zou willen zien is toch misschien, gewoon ter vergelijking, 3 SSDs als L2ARC en 1 als ZIL. Als je toch al 4 van die dingen aanschaft dan zit je al niet meer op het niveau dat 48 gig[2] cache meer of minder nou per definitie het verschil maakt, en ik zou het wel spannend vinden om te zien of dat nu beter of slechter is dan de 4x60/4x4 config hier.

Ook al zou ik persoonlijk[1] waarschijnlijk niet meer dan 2+1 gaan draaien, evt met de 1 een speciaal klein format extra snel driveje (Intel 310 comes to mind).

Wat ik bij de workstation/server verbinding vergelijking ook nog graag zou zien: Gewoon SAS, en evt eSATA. Hoe snel is zo'n 4xSAS 6G bundel als je hem zo inzet? Evt 2 4x bundels, aangezien je toch 8ports kaarten moet hebben dan, die je neem ik aan niet gedeeld kunt inzetten met 4 poort initiator en 4 target.

Weliswaar minder geschikt voor remote opstellen, maar wel heel betaalbaar.

[1] Als ik al naar dit soort dingen zou gaan.

[2] 4x60=240, 3x64=192.
In de tests die ik heb gedraaid (Windows-host met ntfs-bestandssysteem, NAS Performance Toolkit als lood generator en write cache op het volume ingeschakeld) werden er vrijwel geen synchrone schrijfacties gedaan en werd er dus ook nauwelijks geschreven naar de zil. Dit gedrag lijkt me representatief voor iedereen die ntfs draait op een zvol dat via comstar als logical unit wordt geŽxporteerd. Het is nogal jammer om een dedicated ssd te gebruiken voor een zil die niets doet. Als je zfs gebruikt voor een nas icm nfs krijg je wellicht wel meer sync writes maar dat heb ik nog niet zelf kunnen testen.
Volgens mij zal ZFS sowieso zolang de Write Cache op het volume aan staat de ZIL vrijwel niet aanspreken, ergens op de nexenta forums vond ik daar eerder wat over. schakel die eens uit voor je test, dan word die wel gebruikt (alleen geeft het onder de streep vaak minder performance)
Wonderschoon artikel!

Goed uitgebreid en duidelijk!
Zijn er ook mogelijkheden om ZFS redundant op te zetten over 2 of meer fysieke systemen? Onder Linux heb je normaal gesproken DRBD (soort RAID 1 over het netwerk) als optie met een filesystem daar bovenop, alleen is het bij ZFS natuurlijk mooier om direct de disks aan te spreken.

Ik zag wel dat Nexenta een soort van High Availability iets heeft, maar ik kan niet vinden of zoiets ook voor een eigen ZFS opstelling te doen is.

Voor thuis is het misschien niet direct nodig om het HA op te zetten, maar op kantoor waar een dure Equallogic SAN overkill is, wil je niet dat je storage een uur of langer wegvalt door bijv. een defect moederbord.

[Reactie gewijzigd door Cybje op 16 maart 2012 10:44]

Voor zover ik weet is het enige wat je op dit moment gewoon met ZFS kunt doen repliceren. Dat kan natuurlijk wel heel vaak; je hoeft alleen de wijzigingen te repliceren.

Als je dat elke 5 minuten doet ben je in de meeste gevallen safe. Repliceren doe je middels 't maken van snapshots en dan het zfs-send en zfs-receive principe.
Je kan gewoon 2 servers neerzetten, en daar dan een (soft)raid 1 over maken in windows. Je krijgt gewoon 2 luns dus daar kun je een raid over maken.

Het nadeel is natuurlijk wel dat wanneer 1 vd 2 servers wegvalt je een best lange rebuild time hebt omdat alle data weer heen en weer geschreven moet worden ;)
Ik vind het missen van 5 minuten aan data wel een groot probleem een belangrijke reden om dan voor DRBD+Ext4 te kiezen ipv ZFS. Om nog maar even niet te spreken over de inconsistentie die je gaat krijgen als je er bijv. een database op draait.

Daarnaast is het zo dat als je er echt systemen van laat booten via iSCSI (ofwel als VM, ofwel als fysiek systeem), die systemen niet gelukkig worden van dat hun image ineens 5 minuten terug in de tijd gaat. Dan ga je echt heel rare filesystemproblemen krijgen.
DRBD is ook niet feilloos, zowel niet qua werking als performance... Er zijn mooie oplossingen mee te bouwen hoor maar het heeft zeker ook nadelen.

Inconsistentie in je database kun je oplossen door zoiets te scripten... flushen van data naar disk, freeze en snapshot... Beetje gelijkwaardig aan het Microsoft VSS framework... Zal niet elke db ondersteunen overigens... Zelfde probleem heb je trouwens ook met DRBD, de consisente database is data op disk + data nog in memory... Beter is het om voor dat soort zaken gewoon database replicatie in te richten.
Ligt er natuurlijk aan hoeveel je gaat cachen, maar DRBD heeft wel de mogelijkheid om te wachten tot ook de secondary de data heeft weggeschreven. Gaat alleen wel ten koste van de performance. Daardoor is het wel goed te gebruiken als bijv. redundante SAN.
Helaas geeft DRBD alleen een Distributed Replicated Block Device, wat natuurlijk niet hetzelfde is als een onderwater sychroon gerepliceerde ZFS oplossing.

Nexenta heeft ook nog zoiets wat AutoCDP heet wat prima werkt voor kleinere hoeveelheden data waar niet al te vaak naar geschreven wordt. Dat lijkt wel een beetje op de DRBD oplossing, maar dan met ZFS er bovenop.
FreeBSD heeft hiervoor het HAST framework

"HAST allows to transparently store data on two physically separated machines connected over the TCP/IP network"

kan dus ook icm met ZFS en failsafe network.

[Reactie gewijzigd door matty___ op 16 maart 2012 11:22]

HAST is toch in principe vergelijkbaar met DRBD? Het is jammer als je ZFS op HAST of DRBD moet zetten, want je mist dan een paar leuke ZFS features, zoals het goed kunnen gebruiken van RAID-Z.
nee hoezo?

elke machine levert via hast de disk aan en op deze virtuele disk bouw je zfs op..


Als beide machines 3 disks hebben kun elke van deze disk los doorgeven via hast

vervolgens bouw je zfs pool op uit een 2x3 disk mirror oid.


je kunt ook van elke disk een mirror via hast laten maken (misschien zelf de betere optie)

dus elke disk wordt 1 mirror disk via hast
en dan bouw je een zfs raidz1 uit 3 disks op

dat er 2 servers achter hangen weet zfs dan niet en maakt ook niet uit

[Reactie gewijzigd door matty___ op 16 maart 2012 11:38]

Ik ga het wel testen dan, klinkt wel veelbelovend :)

Nadeel aan DRBD is dat het eigenlijk domweg een soort van netwerk RAID 1 is. Je kunt dan wel 3 DRBD's aanmaken over 3 disks, maar dat wordt toch redelijk ugly. ZFS vindt het namelijk prettig om direct toegang tot disks te hebben, ipv een laag ertussen. Maar als het anders is dan DRBD zou het mogelijk wel zinnig kunnen zijn.
onder linux heb je in principe ook nog network-blockdevice support, die kanj e dan ook weer gebruiken in je zfs zetup.
volgens mij is bij HAST het voor ZFS transparant .Dus voor hem is het gewoon een disk (die dan weer uit 2 disk op 2 verschillende servers bestaat)


Maar er is genoeg informatie te vinden over zfs hast en carp als je echt uit je dak wilt gaan
Ik zag wel dat Nexenta een soort van High Availability iets heeft, maar ik kan niet vinden of zoiets ook voor een eigen ZFS opstelling te doen is.
Nexenta heeft zelfs een heuse HA Cluster plugin, wat eigenlijk een voor Nexenta aangepaste versie van de RSF1 software van highavailability.com is. Met deze HA Cluster plugin maak je in een handomdraai een volledige High Available oplossing zonder SPOFS. :)

Dat werkt ongeveer zo:
Je heb een of meerdere disk array's die met SAS2 of Fiber Channel gekoppeld zijn aan twee Nexenta servers. Op de disken wordt een zpool gemaakt die vervolgens door een van de twee Nexenta servers aan de clients wordt aangeboden via NFS, iSCSI of Fiber Channel. Als deze actieve server om welke reden dan ook niet meer functioneert neemt de tweede Nexenta server de zpool over (die wordt geimporteerd).

Het is dus een Active/Passive failovercluster wat Nexenta biedt. Natuurlijk kun je op de disk arrays onder je Nexenta ook twee zpools aanmaken zodat je het cluster Active/Active kunt draaien.

Nexenta heeft sinds kort ook iets wat Metro Cluster heet waarmee je over twee locaties een HA cluster kunt bouwen, daar moet je dan even bij een van de Nexenta partners naar vragen, maar dat werkt zo:
Je hebt twee Nexenta servers, op iedere locatie een, met daaronder een Fiber Channel netwerk, aan dat Fiber Channel netwerk hangen dan weer twee andere Nexenta servers. Aan deze servers hangt de daadwerkelijke storage. Dat hoeft niet in een disk Array, dat mag ook gewoon in de Nexenta server zelf. Op de servers waar de disken aan hangen worden al zpools gemaakt die vervolgens via Fiber Channel worden aangeboden aan de Nexenta servers die de storage uiteindelijk aan de clients aanbieden. In deze servers wordt er dan weer een vorm van een mirror over de twee eronder liggende systemen gemaakt.

De goedkoopste manier om HA te bereiken met twee Nexenta servers is door twee blokken te carven uit twee Nexenta servers en daar dan weer in de client een mirror overheen te zetten, zoals Kees hieronder ook al voorstelt.
Jammer is alleen dat de HA nexenta plugin alleen al een paar K kost, buiten de eisen voor Gold Support en System checkup.
Over in depth articles gesproken. Heel mooi verhaal hierboven, waarvoor hulde! :) Ik ben zelf bezig met een NAS op basis van ZSF (waarschijnlijk FreeNAS) maar op een wat kleinere schaal dan dit testsysteem ;) 4 schijven en vooralsnog geen L2ARC device. Toch staat in dit artikel veel informatie waar ik veel van heb geleerd.
Wow gaaf, wat is nu het totaal-plaatje aan kosten voor dit juweeltje geworden?
Ik wil in de toekomst een vergelijking doen van nas- en san-prestaties van een zfs-server met ssd-caching, een Windows-machine voorzien van hardware raid en een off-the-shelf nas. Drie betaalbare configuraties met ongeveer dezelfde totaalprijs. De configuratie die ik heb gebruikt kost ruim 3000 euro en is natuurlijk nogal ruim bemeten, maar bood wel de mogelijkheid om het nut van extra harde schijven, ssd's en werkgeheugen te kunnen testen.
Deze kan ik nomineren voor beste artikel in 2012!
Ten eerste super artikel!!

over iscsi, je hebt dus met ZFS een drive gemaakt volledig redundant, etc. Maar zodra je een iscsi target aanmaakt deel je de disk op block level niveau en is de data alleen benaderbaar op de computer waarmee je een drive hebt geformatteerd, je wilt immer de data over het iscsi protocol en niet over tcp/ip (daarom deel je de drive niet via windows).

Kun je de data ook delen over iscsi met meerdere computers? dus dat het een nas wordt?

Sorry als ik het niet goed begrijp, ik ben een bedrijfskunde student met IT hobby :Y)
zelf heb ik dus geknutseld met iscsi en infiniband wat zeer goede snelheden haalt via een RAM drive (letterlijk je RAM als storage)

edit// oja wat kan Thunderbolt gaan brengen voor de cunsument mbt tot NAS/SAN

[Reactie gewijzigd door laurensxeon op 16 maart 2012 11:20]

in principe gebruik je de host waar je de iscsi target mount als ingang voor je data. In dit geval wordt daar een windows machine voor gebruikt, daar zou je het fs kunnen sharen via bv smb of nfs
Als je een server bestanden wil laten delen zodat die voor verschillende clients toegankelijk zijn kun je beter een nas bouwen. Dat kan ook uitstekend met zfs en OpenIndiana of FreeBSD als basis.
1 2 3 ... 6

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Tablets Luchtvaart Samsung Crash Smartphones Microsoft Apple Games Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013