besterino
Legende
Hallo zusammen, ich hätte da eine wahrscheinlich ganz dumme Frage (und habe auch ehrlich gesagt nicht alle 200+ Seiten gelesen):
Hat schon einmal jemand erfolgreich ein ZFS Storage System in einer Gast-VM unter einem Hyper-V aufgesetzt?
Ich spiele gerade generell mit Hyper-V herum, insbesondere natürlich für WindowsVMs, um damit ein paar Erfahrungen zu sammeln. Zum Beispiel habe ich bereits meinen alten Ion/atom-32bit-ubuntu-Linux-server erfolgreich auf Hyper-V migriert/virtulisiert und teste gerade Windows 10 Server und Client in entsprechenden VMs. Wenn man es einmal geschafft hat, grds. den Hyper-v (halt ohne GUI weil für umme) von einem win-client zu administrieren...
Nun überlege ich halt, ob ich mal ein NAS mit ZFS als VM auf dem Hyper-V aufsetze. Da ich aber von ZFS bisher null Peilung habe, wollte ich vorher lieber mal einen Machbarkeitscheck bei Euch Experten starten, bevor ich nach 5 Tagen Flicken und Lesen feststellen muss, es geht schlicht nicht.
Performanz ist zunächst mal nebensächlich.
Hat schon einmal jemand erfolgreich ein ZFS Storage System in einer Gast-VM unter einem Hyper-V aufgesetzt?
Ich spiele gerade generell mit Hyper-V herum, insbesondere natürlich für WindowsVMs, um damit ein paar Erfahrungen zu sammeln. Zum Beispiel habe ich bereits meinen alten Ion/atom-32bit-ubuntu-Linux-server erfolgreich auf Hyper-V migriert/virtulisiert und teste gerade Windows 10 Server und Client in entsprechenden VMs. Wenn man es einmal geschafft hat, grds. den Hyper-v (halt ohne GUI weil für umme) von einem win-client zu administrieren...
Nun überlege ich halt, ob ich mal ein NAS mit ZFS als VM auf dem Hyper-V aufsetze. Da ich aber von ZFS bisher null Peilung habe, wollte ich vorher lieber mal einen Machbarkeitscheck bei Euch Experten starten, bevor ich nach 5 Tagen Flicken und Lesen feststellen muss, es geht schlicht nicht.
Performanz ist zunächst mal nebensächlich.
Zuletzt bearbeitet:
LichtiF
Enthusiast
Hier mal ein Link zu dem Thema :
ZFS on Linux in Hyper-V with napp-it Web ManagementServeTheHome – Server and Workstation Reviews
ZFS on Linux in Hyper-V with napp-it Web ManagementServeTheHome – Server and Workstation Reviews
besterino
Legende
Jau, danke, auf den und ein paar andere bin ich auch bereits gestoße. Es geht also grds., hatte nur auf ein paar Eindrücke aus erster Hand hier im Forum gehofft. Na, zur Not liefere ich die dann halt. :-D
D Meine 4x4 TB WD Reds stecken zwar zurzeit in einem MS Storage Pool, aber sobald ich da mal ein paar Tests/Benchmarks habe laufen lassen, kann ich den auch wieder platt machen.
D Meine 4x4 TB WD Reds stecken zwar zurzeit in einem MS Storage Pool, aber sobald ich da mal ein paar Tests/Benchmarks habe laufen lassen, kann ich den auch wieder platt machen.
LichtiF
Enthusiast
Ich denke die meisten die ZFS als VM benutzen haben halt ESXi wegen dem durchreichen des HBAs und den Smartwerten der Platten die hast du unter Hyper-V leider nicht.
besterino
Legende
Das coole an Hyper-V ist ja, dass man nicht den ganzen HBA durchreichen muss, sondern einzelne Platten auswählen kann, egal woran sie hängen. Das funktioniert also eigentlich viel komfortabler als bei den anderen Hypervisoren. Dafür ist aber die Treiberunterstützung an anderer Stelle wohl deutlich schlechter. Ich teste das mal am Wochenende mit FreeNAS, NAS4free. Ubuntu mit ZoL wurde ja schon in dem oben genannten Link als funktionsfähig genannt. Aber wenn ich das richtig verstanden habe, ist ZoL weniger "produktiv" als BSD-basierte settings.
Zuletzt bearbeitet:
automatenraum
Enthusiast
- Mitglied seit
- 15.02.2013
- Beiträge
- 179
Das sehe ich aber ganz anders, besonders in Bezug auf Performance, naja mach mal deine eigenen Erfahrungen, dann wirst du das ganze Thema mit Sicherheit etwas differenzierter betrachten als im Moment.
Versuch macht klug
Das nennt sich unter ESXi physical Raw Disk Mapping (RDM). Damit geht sogar noch Smart.
Ist aber auch unter ESXi nur die zweitbeste Wahl gegenüber dem Direktzugriff auf die Storagehardware mit OS-Treibern der Storage-VM (z.B. Solaris/OmniOS) anstatt über ESXi oder Windows Treibern.
Ich habe übrigens auch mit Hyper-V 2008 angefangen. Ist auch nicht schlecht geraten. Die Wurzeln sollen auch in Xen liegen. Nachdem ich aber einmal einen Absturz hatte und die VMs trotz Datensicherung nicht meht importieren konnte (Kein Import ohne vorherigen Export, weiß nicht ob das immer noch so ist) und ich alle zwei Wochen "wichtige Updates" samt Neustart einspielen durfte, habe ich das zugunsten ESXi geerdet - Zumal ESXi alles unterstützt.
Zuletzt bearbeitet:
besterino
Legende
Jo, werde es wohl wirklich einfach mal versuchen müssen. =) Zweitbeste Wahl in Sachen Performance dürfte für mich grds. immer noch gut genug sein, da die Box nur fürs Heim gedacht ist und eben auch noch anderen Zwecken dienen soll.
Ansonsten muss ich halt mal das neue ESXi 6 ausprobieren...
Ansonsten muss ich halt mal das neue ESXi 6 ausprobieren...
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Meiner Meinung nach reicht für den privaten Gebrauch ein oder zwei vdevs, egal bei welchem RAIDZ-Level. Der Flaschenhals wird eh dein Netzwerk sein, außer du hast ein 10GB Netz aufgebaut.
Bei den einzelnen HDDs hat ja auch noch ESXi das sagen, deshalb sind die so langsam.
Beim all-in-one reichst du ja per passthrough den HBA an die omnios-vm weiter und so weis ESXi nicht mehr was dort drauf abgeht.
Ja sind sie.
Ich hab spaßeshalber mal von meinem Backupserver (RAIDz2 mit 18 HDDs, 1 vdev) den gleichen Heimatfilm auf 3 PCs gleichzeitig laufen lassen und da hat nichts geruckelt.
Tu dir selbst einen Gefallen und nutze momentan noch ESXi 5.5 mit Omnios r151012, aber noch nicht ESXi 6.0 mit r151014.
Es scheint, dass es mal wieder mit NFS Probleme gibt und das brauchst du ja, um in ESXi einen datastore einzubinden.
Nimm in jedem Falle Intel Netzwerkkarten. Hast du dir deine Hardware schon rausgesucht?
Ich denke dieser Wert gilt beim Internen kopieren oder von VM auf VM, wenn beide vmxnet3 Treiber und den gleichen vswitch haben.
Hier erreiche ich Werte von 80-90 MB/sek von Win7 Kiste auf Omnios.
Pool auf autoexpand umstellen
1. alte Platte raus und durch neue Größere ersetzen
ZFS resilvert
2. alte Platte raus und durch neue Größere ersetzen
ZFS resilvert
...
...
wenn alle HDDs eines vdevs ersetzt sind, hast du die neue Poolgröße
Zuletzt bearbeitet:
Es gibt Berichte, dass OmniOS 151014 unter NFS Probleme mit ESXi bereiten kann (ESXi 5.5 und 6.0)
Diskussion (Mailarchiv ist nicht tagesaktuell, am Besten Mailliste abonnieren):
https://www.mail-archive.com/omnios-discuss@lists.omniti.com/msg04173.html
Diskussion (Mailarchiv ist nicht tagesaktuell, am Besten Mailliste abonnieren):
https://www.mail-archive.com/omnios-discuss@lists.omniti.com/msg04173.html
-Meiner Meinung nach reicht für den privaten Gebrauch ein oder zwei vdevs, egal bei welchem RAIDZ-Level. Der Flaschenhals wird eh dein Netzwerk sein, außer du hast ein 10GB Netz aufgebaut.
Ich werde mir wohl nich einen Backupserver anschaffen, dafür würde ich mir überlegen ein 10GBit LAN zwischen Server und Backup aufzubauen. Ansonsten wechsel ich mir ja die Hände blutig wenn ich 20 Backup HDD's hätte^^.
Tu dir selbst einen Gefallen und nutze momentan noch ESXi 5.5 mit Omnios r151012, aber noch nicht ESXi 6.0 mit r151014.
Es scheint, dass es mal wieder mit NFS Probleme gibt und das brauchst du ja, um in ESXi einen datastore einzubinden.
Bis jetzt hatte ich keine Probleme mit dem NFS Laufwerk beim Einbinden, usw... aber wenn es welche geben sollte werd ich wohl mal die 5.5 wieder raus kramen
Nimm in jedem Falle Intel Netzwerkkarten. Hast du dir deine Hardware schon rausgesucht?
Ich habe 2x Intel PRO/1000 PT Netzwerkkarten (jede ist eine Dual Port) + die LAN Adapter bei meinem SM Mainb.
Meine Hardware hab ich ja schon (SM X9SRL-F, E5-1620v2, 16GB DDR3-1600 ECC RAM, LSI 9201-16i HBA), sollte auf jedenfall dicke ausreichen
Allerdings werde ich wohl den RAM auf 32GB oder 64GB aufrüsten. ZFS ist ja nicht das einzigste was da so läuft
Ich denke dieser Wert gilt beim Internen kopieren oder von VM auf VM, wenn beide vmxnet3 Treiber und den gleichen vswitch haben.
Hier erreiche ich Werte von 80-90 MB/sek von Win7 Kiste auf Omnios.
Mit write-sync? Allerdings ist 80-90MB/sek nur ein wenig weniger als das was ich bis jetzt gewohnt bin, was mich jetzt aber auch nicht stören würde
Pool auf autoexpand umstellen
1. alte Platte raus und durch neue Größere ersetzen
ZFS resilvert
2. alte Platte raus und durch neue Größere ersetzen
ZFS resilvert
...
...
wenn alle HDDs eines vdevs ersetzt sind, hast du die neue Poolgröße
Ja das habe ich schon getestet, ging super. Waren zwar nur kleine virtuelle HDD's aber das Prinzip bleibt ja gleich.
War autoexpand nicht immer auf on bei napp-it?!
Zuletzt bearbeitet:
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Was du willst ein händisches Backup machen und dein HBA nimmt 16 HDDs, dein Board weitere 8 auf?
Na, dann viel Spaß dabei.
Bei mir steht "EXP" auf off.
Ne das das möchte ich dann nicht mehr machen. Deswegen dann der Backup Server.
Ich werde dafür wieder zu Supermicro greifen (X10SL7-F mit E3-1230v3)
automatenraum
Enthusiast
- Mitglied seit
- 15.02.2013
- Beiträge
- 179
Zum Thema ESXi und NFS, ich bin wieder zurück von 6 auf 5.5 weil ich Probleme mit NFS hatte. Mittlerweile habe ich unter 5.5 auf OmniOS 151014 upgedated und konnte keine Probleme mehr feststellen.
Es liegt also entweder an ESXi 6 oder an einer Kombi von 6 und 151014.
Es liegt also entweder an ESXi 6 oder an einer Kombi von 6 und 151014.
Also xpenology und esxi 6 macht keine Probleme mit nfs.... Nur mal so reingeworfen.
Die Berichte in der OmniOS Mailing Liste legen nahe, dass es sich um ein Locking Problem mit der neuen 151014 unter ESXi (5.5u2 und 6.0, bei 5.5u1 war ja NFS seitens Vmware generell instabil) handeln könnte. Auf jeden Fall würde ich mit der neuen OmniOS Version noch abwarten wenn damit NFS Storage für ESXi bereitgestellt werden soll. OmniTi hat die Verfügbarkeit auch bisher nur "inoffiziell" in der Mailllinglist kundgetan. Auf der Homepage ist nur 151012 verfügbar.
update: 151014 ist seit heute offiziell auf der Homepage von OmniTi
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
wieso werden meine Snapshots nicht gelöscht?
Habe es wie folgt eingerichtet:
keep 10 daily hld 10 - every every 6 0
aber hab jetzt immer noch täglich einen Snapshot ab dem 26.03. (da hatte ich es eingerichtet). Das sind zum einen deutlich mehr wie 10 Stück und auch deutlich älter als 10 Tage.
Habe es wie folgt eingerichtet:
keep 10 daily hld 10 - every every 6 0
aber hab jetzt immer noch täglich einen Snapshot ab dem 26.03. (da hatte ich es eingerichtet). Das sind zum einen deutlich mehr wie 10 Stück und auch deutlich älter als 10 Tage.
Bei mir wird es mal wieder Zeit fuer ein Upgrade beim Mediengrab.
Derzeitig laeuft folgendes als zfs Volume:
8x 2TB Samsung raidz2
8x2TB Samsung/Hitachi raidz2
4x3TB Seagate NAS radiz
Das Ganze hat relativ wenig Schreiblast aber bis zu 5 gleichzeitige Streams(1080p Material) sollten schon drinnen sein. Ich denke mal bei keiner der Konstellation sollte das wirklich ein Problem sein und das ist der Extremfall, normal sind eher 2-3 Streams.
Ich haette aber gern ein wenig Luft nach oben, da 4k Material ja auch langsam kommt.
Die alte Hardware ausser den Platten werde ich beibehalten:
Intel Xeon L3426
Supermicro X8SIE-F
12GB ECC
Das ganze soll ersetzt werden aber ich bin nicht sicher welche Konstellation am ehesten in Frage kommt:
1) hoechste Performance kleinster Preis, wenig Erweiterbarkeit:
18x WD red 4TB konfiguriert als 3x Raidz2
2)kleinste Performance, aehnlicher Preis wie 1. aber viel Erweiterbarkeit:
11x WD red 6TB als Raidz3
3) hoester Preis, mittlere Performance und gute Erweiterbarkeit:
12x WD red 6TB als 2x Raidz2
Meine derzeitigen Favoriten sind die 2. und 3. Option, da ich denke dass es laenger dauern wird bis the 6TB Platten obsolet sind und ich bei beiden Optionen zur Erweiterung einfach ein vdev dazu packen kann.
Eine andere Ueberlegung war die Seagate Archiv 8TB Platten zu nutzen, aber da habe ich bisher noch keine Praxisberichte von ZFS und SMR Platten gesehen.
Derzeitig laeuft folgendes als zfs Volume:
8x 2TB Samsung raidz2
8x2TB Samsung/Hitachi raidz2
4x3TB Seagate NAS radiz
Das Ganze hat relativ wenig Schreiblast aber bis zu 5 gleichzeitige Streams(1080p Material) sollten schon drinnen sein. Ich denke mal bei keiner der Konstellation sollte das wirklich ein Problem sein und das ist der Extremfall, normal sind eher 2-3 Streams.
Ich haette aber gern ein wenig Luft nach oben, da 4k Material ja auch langsam kommt.
Die alte Hardware ausser den Platten werde ich beibehalten:
Intel Xeon L3426
Supermicro X8SIE-F
12GB ECC
Das ganze soll ersetzt werden aber ich bin nicht sicher welche Konstellation am ehesten in Frage kommt:
1) hoechste Performance kleinster Preis, wenig Erweiterbarkeit:
18x WD red 4TB konfiguriert als 3x Raidz2
2)kleinste Performance, aehnlicher Preis wie 1. aber viel Erweiterbarkeit:
11x WD red 6TB als Raidz3
3) hoester Preis, mittlere Performance und gute Erweiterbarkeit:
12x WD red 6TB als 2x Raidz2
Meine derzeitigen Favoriten sind die 2. und 3. Option, da ich denke dass es laenger dauern wird bis the 6TB Platten obsolet sind und ich bei beiden Optionen zur Erweiterung einfach ein vdev dazu packen kann.
Eine andere Ueberlegung war die Seagate Archiv 8TB Platten zu nutzen, aber da habe ich bisher noch keine Praxisberichte von ZFS und SMR Platten gesehen.
besterino
Legende
Also, ich habe soeben mal auf meinem Hyper-V (zur Erinnerung: Win10 Tech Preview Build 9841) ZFS mit ZoL auf einer Ubuntu 14.04LTS-VM eingerichtet.
Bin begeistert (warum, dazu unten mehr).
Setup:
Hardware:
Dell T20 Xeon E3-1225 v3
Dell Perc PowerRaid H200 (crossgeflashed auf LSI/IT-mode - wäre aber für Funktion nicht nötig)
24GB RAM (wird demnächst aufgestockt auf 32GB)
Samsung SSD 830 256GB als Boot/VM-Speicherplatz (an Onboard-SATA)
4x 4TB WD Red als Datengrab (am H200)
Phys. Netzwerk: 1GBit
Hyper-V VM-Settings:
Generation 2
16GB RAM fix (werde später noch mit weniger testen)
4 Virtual Processors
1x HDD als VHDX als Bootdrive (liegt auf der SSD)
4x die WD Reds an VM durchgereicht als "physical drives"
Ubuntu/Software-Setup:
Zunächst nach Gea's Linux-Manual für Napp-it installiert, ich brauchte eigentlich nur die wenigen Befehle für die ZFS-Installation im engeren Sinne ab "## var 1: install ZoL manually on Ubuntu 14 LTS" ausführen.
Dann lief Napp-it grundsätzlich. Allerdings hatte ich das Problem, dass die unter Napp-it angelegten pools (vermutlich aufgrund irgendwelcher alten auf den HDDs zurückgebliebenen Rest-Partitionen) nur pro Disk 128MB groß waren... damit kann man ja nicht wirklich arbeiten. Da ich zu blöd war, die notwendigen Befehle in Napp-it selbst zu finden, habe ich mich etwas schlau gemacht und die pools jeweils dann per Hand auf der Konsole angelegt, in meinem Fall mit:
Für Mirror (quasi Raid10 bzw. "mirror" setting unter Windows Storage Pools?):
Für RaidZ (quasi Raid5 bzw. "Parity"-Setting unter Windows Storage Pools?):
Dann tauchten auch die pools jeweils richtig (und in voller Größe) in napp-it auf. Das ZFS-Filesystem habe ich dann mit napp-it angelegt.
Erste Benchmarks:
Soweit so hübsch! Warum bin ich begeistert? In meinem Fall scheint die Geschwindigkeit bei ZFS sowohl im mirror- als auch im RaidZ-Mode schreibend am Maximum der Netzwerkgeschwindigkeit zu sein und lesend nur "geringfügig" darunter:
ZoL Mirror:
ZoL RaidZ:
EDIT: Die 85MB/s waren wohl eher ein Messfehler. Pendelt sich leider eher so bei 65MB/s ein. Kann man das evtl. noch irgendwie tunen? ;-)
Zum Vergleich: Der Windows-Server ist zwar mit NTFS im Mirrored-Mode lesend flotter, dafür bricht aber die Schreib-Performance im Parity-Mode total ein:
Win10 Mirrored NTFS:
Win10 Parity NTFS:
Win10 Parity ReFS:
Will aber nicht verheimlichen, die native lese-performance in der Win10-VM allerdings deutlich höher ist (Netz bremst):
DiskMark habe ich jeweils in der 64Bit-Version mit Standard-Einstellungen laufenlassen, ausgeführt auf einem Win7-Client, der auf das ZFS-Filesystem über eine SMB-Freigabe zugegriffen hat.
Soweit meine ersten Erkenntnisse. Falls Ihr noch Anregungen habt oder ich im Setup irgend etwas völlig verbockt habe (und damit meine ich NICHT die Verwendung von ZoL, und dann auch noch Ubuntu (statt Debian ;-), und dann auch noch in einer VM, und dann auch noch Hyper-V...), bin ich immer für Hinweise dankbar.
Falls übrigens jemand weiß, wie ich unter Ubuntu-Server mal einen vergleichbaren Benchmark in der VM selbst laufen lassen kann, bitte gerne...
Nachtrag 1:
Der Napp-it Benchmark auf dem ZFS spuckt Folgendes aus (würde das gerne in einen Spoiler setzen, bin aber zu blöd dafür):
Bin begeistert (warum, dazu unten mehr).
Setup:
Hardware:
Dell T20 Xeon E3-1225 v3
Dell Perc PowerRaid H200 (crossgeflashed auf LSI/IT-mode - wäre aber für Funktion nicht nötig)
24GB RAM (wird demnächst aufgestockt auf 32GB)
Samsung SSD 830 256GB als Boot/VM-Speicherplatz (an Onboard-SATA)
4x 4TB WD Red als Datengrab (am H200)
Phys. Netzwerk: 1GBit
Hyper-V VM-Settings:
Generation 2
16GB RAM fix (werde später noch mit weniger testen)
4 Virtual Processors
1x HDD als VHDX als Bootdrive (liegt auf der SSD)
4x die WD Reds an VM durchgereicht als "physical drives"
Ubuntu/Software-Setup:
Zunächst nach Gea's Linux-Manual für Napp-it installiert, ich brauchte eigentlich nur die wenigen Befehle für die ZFS-Installation im engeren Sinne ab "## var 1: install ZoL manually on Ubuntu 14 LTS" ausführen.
Dann lief Napp-it grundsätzlich. Allerdings hatte ich das Problem, dass die unter Napp-it angelegten pools (vermutlich aufgrund irgendwelcher alten auf den HDDs zurückgebliebenen Rest-Partitionen) nur pro Disk 128MB groß waren... damit kann man ja nicht wirklich arbeiten. Da ich zu blöd war, die notwendigen Befehle in Napp-it selbst zu finden, habe ich mich etwas schlau gemacht und die pools jeweils dann per Hand auf der Konsole angelegt, in meinem Fall mit:
Für Mirror (quasi Raid10 bzw. "mirror" setting unter Windows Storage Pools?):
Code:
1. zpool create tank mirror sdb sdc
2. zpool add tank mirror sdd sdeFür RaidZ (quasi Raid5 bzw. "Parity"-Setting unter Windows Storage Pools?):
Code:
zpool create tank raidz sdb sdc sdd sdeDann tauchten auch die pools jeweils richtig (und in voller Größe) in napp-it auf. Das ZFS-Filesystem habe ich dann mit napp-it angelegt.
Erste Benchmarks:
Soweit so hübsch! Warum bin ich begeistert? In meinem Fall scheint die Geschwindigkeit bei ZFS sowohl im mirror- als auch im RaidZ-Mode schreibend am Maximum der Netzwerkgeschwindigkeit zu sein und lesend nur "geringfügig" darunter:
ZoL Mirror:
ZoL RaidZ:
EDIT: Die 85MB/s waren wohl eher ein Messfehler. Pendelt sich leider eher so bei 65MB/s ein. Kann man das evtl. noch irgendwie tunen? ;-)
Zum Vergleich: Der Windows-Server ist zwar mit NTFS im Mirrored-Mode lesend flotter, dafür bricht aber die Schreib-Performance im Parity-Mode total ein:
Win10 Mirrored NTFS:
Win10 Parity NTFS:
Win10 Parity ReFS:
Will aber nicht verheimlichen, die native lese-performance in der Win10-VM allerdings deutlich höher ist (Netz bremst):
DiskMark habe ich jeweils in der 64Bit-Version mit Standard-Einstellungen laufenlassen, ausgeführt auf einem Win7-Client, der auf das ZFS-Filesystem über eine SMB-Freigabe zugegriffen hat.
Soweit meine ersten Erkenntnisse. Falls Ihr noch Anregungen habt oder ich im Setup irgend etwas völlig verbockt habe (und damit meine ich NICHT die Verwendung von ZoL, und dann auch noch Ubuntu (statt Debian ;-), und dann auch noch in einer VM, und dann auch noch Hyper-V...), bin ich immer für Hinweise dankbar.
Falls übrigens jemand weiß, wie ich unter Ubuntu-Server mal einen vergleichbaren Benchmark in der VM selbst laufen lassen kann, bitte gerne...
Nachtrag 1:
Der Napp-it Benchmark auf dem ZFS spuckt Folgendes aus (würde das gerne in einen Spoiler setzen, bin aber zu blöd dafür):
Code:
MemTotal: 16422652 kB
write 12.8 GB via dd, please wait...
time dd if=/dev/zero of=/tank/dd.tst bs=2048000 count=6250
write:
time 6250+0 records in
6250+0 records out
12800000000 bytes (13 GB) copied, 29.1478 s, 439 MB/s
0.00user 5.16system 0:29.15elapsed 17%CPU (0avgtext+0avgdata 3696maxresident)k
0inputs+25000000outputs (0major+3485minor)pagefaults 0swaps
wait 40 s
read 12.8 GB via dd, please wait...
time dd if=/tank/dd.tst of=/dev/null bs=2048000
read
time 6250+0 records in
6250+0 records out
12800000000 bytes (13 GB) copied, 29.8363 s, 429 MB/s
0.00user 2.85system 0:29.84elapsed 9%CPU (0avgtext+0avgdata 3616maxresident)k
25138424inputs+0outputs (0major+1474minor)pagefaults 0swaps
Zuletzt bearbeitet:
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
@skelleton
wenn Performance wischtisch ist. dann solltest du mal einen Blick auf die HGST NAS Platten werfen, die drehen mit 7200 statt 5400 >> kürzere Zugriffszeit und höhere Transferrate
Nebenbei bemerkt: Die WD Red ist für kleine NASen bis 8 Laufwerke spezifiziert ( die Red Pro bis 16), HGST macht hier keine Angaben.
Bedenke: Bei 1 und 3 dürfen nur 2 beliebige Platten ausfallen, geht einer der Vdevs hops, ist der Pool übern Jordan.
Version 2 ist aus diesem Gesichtspunkt die sicherste Variante.
wenn Performance wischtisch ist. dann solltest du mal einen Blick auf die HGST NAS Platten werfen, die drehen mit 7200 statt 5400 >> kürzere Zugriffszeit und höhere Transferrate
Nebenbei bemerkt: Die WD Red ist für kleine NASen bis 8 Laufwerke spezifiziert ( die Red Pro bis 16), HGST macht hier keine Angaben.
Bedenke: Bei 1 und 3 dürfen nur 2 beliebige Platten ausfallen, geht einer der Vdevs hops, ist der Pool übern Jordan.
Version 2 ist aus diesem Gesichtspunkt die sicherste Variante.
Zuletzt bearbeitet:
Danke fuer die Hinweise. Dann wird es wohl auf den RaidZ3 rauslaufen. Da ich die Performance meine geringste Sorge ist. Ich bin vorher nicht auf Idee gekommen auch die Ausfallwahrscheinlichkeit einzuberechnen.
Die HGST sind zwar relativ interessant, vorallem da auch der Preis fast der selbe ist. Aber die Transferraten sind nicht viel hoeher als die der REDs und ich habe die Befuerchtung dass die HGST um einiges mehr Abwaerme haben werden. (Habe da leider keinen direkten Vergleich gefunden)
Die Schwingungen bei mir sollten sich auch in Grenzen halten, da die Platten bei mir in einem Lian Li D8000 verbaut werden.
Aber ich werde die HGST in betracht ziehen, aber auch die Verfuegbarkeit sieht etwas schlechter aus als bei den WD.
Die HGST sind zwar relativ interessant, vorallem da auch der Preis fast der selbe ist. Aber die Transferraten sind nicht viel hoeher als die der REDs und ich habe die Befuerchtung dass die HGST um einiges mehr Abwaerme haben werden. (Habe da leider keinen direkten Vergleich gefunden)
Die Schwingungen bei mir sollten sich auch in Grenzen halten, da die Platten bei mir in einem Lian Li D8000 verbaut werden.
Aber ich werde die HGST in betracht ziehen, aber auch die Verfuegbarkeit sieht etwas schlechter aus als bei den WD.
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
ich habe 5 HGST NAS 4TB Platten in meinem N54L drin, die werden nicht besonders heiss, Lautstärke ist auch OK - für mich.
Nochmal zum Thema Ausfallsicherheit. Du kannst natürlich auch mehrere Raidz2 betreiben, nur solltest du die nicht in einen gemeinsamen Poll packen. Hier laufen 2 Argumente Konträr, die Performance des Pools steigt zwar mit jedem Vdev, die Redundanz bleibt aber die des Vdevs mit dem geringsten Redundanzlevel bei einem höherem Gesamtverlustrisiko. Es soll ja Leute geben, die ein Stripeset mit einem Raidz3 mischen - oder denke ich mir das gerade aus?!?!? Wer weiss, wer weiss. *gfg*
Nochmal zum Thema Ausfallsicherheit. Du kannst natürlich auch mehrere Raidz2 betreiben, nur solltest du die nicht in einen gemeinsamen Poll packen. Hier laufen 2 Argumente Konträr, die Performance des Pools steigt zwar mit jedem Vdev, die Redundanz bleibt aber die des Vdevs mit dem geringsten Redundanzlevel bei einem höherem Gesamtverlustrisiko. Es soll ja Leute geben, die ein Stripeset mit einem Raidz3 mischen - oder denke ich mir das gerade aus?!?!? Wer weiss, wer weiss. *gfg*
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
@skelleton
Ich hab über 30 HDDs Hitachi und HGST verbaut und nur eine Einzige war gleich am ersten Tag hinüber. Alle Anderen verrichten unauffällig ihren Dienst.
@skelleton und @Digi-Quick
Es gibt auch noch die Möglichkeit eine Spare-Platte dem pool hinzuzufügen. Das hat den Vorteil, dass wenn eine HDD ausfällt und ZFS Dies erkennt, die Spare sofort einspringt und ein resilver gestartet wird.
@Digi-Quick
Deine Argumentation versteh ich jetzt nicht. Du wirst doch nicht RAIDz2 und RAIDz3 mischen wollen?
2vdev in einem Schritt:
# zpool create tank raidz(1-3) c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0 raidz(1-3) c1t0d0 c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0 spare c0t6d0
oder in zwei Schritte, wenn du den pool (später) erweitern willst
# zpool create tank raidz(1-3) c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0 spare c0t6d0
# zpool add tank raidz(1-3) c1t0d0 c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0
Die spare springt für beide vdevs ein.
Ich hab über 30 HDDs Hitachi und HGST verbaut und nur eine Einzige war gleich am ersten Tag hinüber. Alle Anderen verrichten unauffällig ihren Dienst.
@skelleton und @Digi-Quick
Es gibt auch noch die Möglichkeit eine Spare-Platte dem pool hinzuzufügen. Das hat den Vorteil, dass wenn eine HDD ausfällt und ZFS Dies erkennt, die Spare sofort einspringt und ein resilver gestartet wird.
@Digi-Quick
Deine Argumentation versteh ich jetzt nicht. Du wirst doch nicht RAIDz2 und RAIDz3 mischen wollen?
2vdev in einem Schritt:
# zpool create tank raidz(1-3) c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0 raidz(1-3) c1t0d0 c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0 spare c0t6d0
oder in zwei Schritte, wenn du den pool (später) erweitern willst
# zpool create tank raidz(1-3) c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0 spare c0t6d0
# zpool add tank raidz(1-3) c1t0d0 c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0
Die spare springt für beide vdevs ein.
wie ist das eigentlich mit der Parität wenn ich den Pool so anlegen würde?
pool: Pool1
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess
Pool1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t2d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t3d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
raidz1-1 ONLINE 0 0 0
c2t4d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t5d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t6d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
habe ich jeweils eine Festplatte die ausfallen darf (also im raidz1-0 und im raidz1-1) oder zählt das als ganzes und es darf instgesamt nur eine Festplatte ausfallen?
pool: Pool1
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess
Pool1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t2d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t3d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
raidz1-1 ONLINE 0 0 0
c2t4d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t5d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
c2t6d0 ONLINE 0 0 0 10.7 GB Virtual disk S:0 H:0 T:0
habe ich jeweils eine Festplatte die ausfallen darf (also im raidz1-0 und im raidz1-1) oder zählt das als ganzes und es darf instgesamt nur eine Festplatte ausfallen?
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Ein Pool mit mehreren VDEVS hat nur die Verfügbarkeit / den Paritätslevel eines einzelnen VDEVS, da nur die gleiche Anzahl an beliebigen Platten ausfallen darf, wie für das einzelne VDEV. Eine Platte mehr die ausfällt, und dein ganzer Pool ist im Ar... - wenn's die falsche ist - und nach Murphys Law tritt genau das ein!
Natürlich können unterm Strich mehr Platten ausfallen, nämlich für jedes VDEV die "erlaubte" Anzahl von Platten, aber genau diese Argumentation darf man nicht zu Grunde legen.
@Layerbreak
Für den Rest hast du wohl das *GFG* übersehen (von wegen Mischen verschiedener Paritätslevel in einem pool)
Natürlich können unterm Strich mehr Platten ausfallen, nämlich für jedes VDEV die "erlaubte" Anzahl von Platten, aber genau diese Argumentation darf man nicht zu Grunde legen.
@Layerbreak
Für den Rest hast du wohl das *GFG* übersehen (von wegen Mischen verschiedener Paritätslevel in einem pool)
Ähnlich wie bei Raid 50 hat man hier zwei Raid-Z1 die gestript werden.
In jedem Raid-Z1 vdev darf eine Platte ausfallen.
Bei großen oder vielen Platten sollte man daher eher Raid-Z2 (idealerweise je 6 oder 10 Platten) nehmen und ein hotspare für alle vdevs vorhalten.
