[Kaufberatung] 10Gbit ZFS NAS 19" 70-100TiB + VM Storage

[gea]

Müsste das Verteilen von 1M blöcken mit nichts als Nullen + Prüfsumme auf ein balancierten leeren Pool von RAIDZ2 nicht auch in seqentieller Schreiblast pro HDD enden? Wenn der RAM genug Platz hat sehe ich keine Notwendigkeit für irgendein lesenden Zugriff oder ein springenden Lesekopf. Aber wahrscheinlich sind meine ZFS Kentnisse nur zu beschränkt. Filebench -> singlestreamread.f erreicht mit 2799.1mb/s auch eher Werte wie ich sie erwarten würde.
Ich nehme auf jedenfall aus den bisherigen Benchmarks mit, das es sich auch bei 24 HDDs für mich noch nicht wirklich lohnen würde mehr als 2 x 10G NICs einzusetzen.

Ich stelle mir das vereinfacht eher so vor
ZFS möchte einen Datenblock z.B. 1M auf den Pool schreiben. Damit der Pool ausgewogen bleibt, wird der Block über die vdevs verteilt wobei ein leereres vdev mehr Daten erhält. Innerhalb des vdevs müssen nun Raid-Stripes erstellt werden. Dazu müssen jedesmal die Metadaten gelesen werden um festzustellen welche Platten-Blöcke frei sind (nicht belegt oder durch einen Snap gesperrt). Ohne genügend RAM als Lesecache muss auch beim Schreiben dauernd von Platte gelesen werden. Wenn die Platte eher leer ist gibt es aber hohe Wahrscheinlichkeit dass die Stripes eher sequentiell geschrieben werden. Ist die Platte eher voll müssen Lücken gefüllt werden. Die Performance von ZFS sinkt damit zudem mit dem Füllgrad deutlich.

Gute ZFS Performance ist damit bei sehr schnellen Pools (SSD) oder alternativ mit viel RAM und bei Pools erreichbar die nicht allzu voll sind. Mit ausreichend RAM kann man bis zu 80% und mehr aller Lesezugriffe aus dem RAM bedienen. Der RAM-Schreibcache sorgt dafür dass praktisch keine kangsamen kleinen Random-Writes sondern ausschliesslich große sequentielle Writes über den Cache stattfinden. Unabhängig davon müssen für jeden ZFS Block beide Kopien der Metadaten aktualisiert werden.

Daher ist bei ZFS vor allem wenn es sich nicht nur um einen Pool aus einer Platte handelt Pool-iops oder alternativ RAM als Schreib/Lesecache so wichtig. Bei konventionellen Platten nimmt man daher gerne Multi-Mirrors weil man da mehr iops hat als bei Raid-Z. (iops skaliert mit Anzahl der vdevs)

 

[Bccc1]

@Trambahner: Deine Werte sehen in etwa so aus wie ich mir das vorgestellt habe. Ich werde das nochmal mit ZFS auf FreeBSD testen.


Ich habe aus neugierde schonmal dem SSD Pool Thema etwas vorgegriffen. Die SSDs die ich dafür nehmen möchte habe ich noch gar nicht gekauft, aber ich hatte eine Samsung 830 512GB übrig und habe damit angefangen rumzutesten. In meinem Nutzungsszenario Kontakt Libraries darauf zu lagern ist SMB leider viel zu langsam. Also deutlich mehr als doppelt so langsam wie eine lokale SSD. Für aussagekräftige und reproduzierbare Messungen muss ich mir noch ein System überlegen weil Windows und Kontakt beide Caching betreiben.
Mit iSCSI ist die Performance bei ~80% der lokalen SSD.

@gea: In deinem optane slog pool performance Dokument hast du ja auch iSCSI Performance Messungen drin. Wie sind die Messungen gemacht worden? Bei dir ist ja für sync=disabled write fast immer schneller als read. Bei mir sieht das drastisch anders aus:

 

[gea]

@gea: In deinem optane slog pool performance Dokument hast du ja auch iSCSI Performance Messungen drin. Wie sind die Messungen gemacht worden? Bei dir ist ja für sync=disabled write fast immer schneller als read. Bei mir sieht das drastisch anders aus:
Anhang anzeigen 440897

Die Tests wurden mit Solaris 11 bzw OmniOS und Windows 10 gemacht.
Verbunden waren die über Intel 10G nics (Windows mit aktuellen Intel Treibern und Int-Throttelling off)