Lohnt sich ein SSD-ZFS Volume?

LL0rd

Experte
Thread Starter
Mitglied seit
21.02.2018
Beiträge
97
Hallo Leute,

ich bin grade am überlegen, ob es Sinn macht sich ein ZFS-Volume nur aus SSDs zu bauen. Anwendungsfall ist Videobearbeitung. Momentan sind in dem Server 8x10TB verbaut als raidz. ca. 800MB/s schafft die Kiste problemlos und haut damit das 10GbE zu. Nun soll die nächste Stufe her. Mit 40GbE und 8k Footage. Und da vermute ich mal, dass die Platten dann doch relativ stark arbeiten werden.

Eine HDD (Ich setze im Moment nur Exos ein) ist halb so schnell wie eine SSD. Eine 4TB SSD kostet etwa genauso viel wie 2x 16TB HDD. Macht es Sinn überhaupt auf SSDs zu gehen? In dem Server habe ich aktuell noch Platz. Statt jetzt 9-10x4TB als SSD zu nehmen, könnte ich die Kiste mit 24 HDDs als RaidZ2 voll machen.

Was würde mehr Sinn machen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie viele Nutzer greifen denn gleichzeitig auf das Material zu? Die Red Monstro schreibt mit 300mb/s auf die minimags. Denke Mal mit deinen 800mb/s bist du du doch super aufgestellt.

Ich bearbeite c300 MK3 RAW momentan auf SSDs mit ~380mb/s Speed und das funktioniert wunderbar - bei einem Nutzer.
 
ZFS ist kein PerformanceFilesystem.

Lesen mag man >1GB/s kommen, Schreiben wird man bei 0,5GB/s (als Größenordnung) bleiben.
Von daher musst du dich entscheiden, was du denn willst, Kapa oder Speed.

Wenn man mehr also die 0,5GB/s schreiben, fängt der Spaß an.
Am ehesten macht nen Mirror aus NVMe SSD Sinn. Da dann eben zu 8TB SSDs oder gar größer greifen. Da kann man dann die Arbeitsfiles drauf ablegen. Da sollte gut Speed durchgehen.
Und dann eben nen HDD Array für die Speicherung.

So wie ich das einschätze, brauchst du nicht erwarten, dass du da (bei deinem Ansatz) irgendwo in Richtung 1GB/s Schreiben kommst. Von daher wäre die 40GBE nur für Read gut.
Wenn du mehr Schreibperformance brauchst, dann go for klassisches RAID5/6 und verzichte auf ZFS. -> hmmm ?_?
 
Ich würde Mal behaupten daß die Schreibgeschwindigkeit sekundär ist weil er die Daten auf dem Server liegend bearbeiten will.
 
Wie willst du das Rohmaterial bearbeiten - lokal oder remote auf dem Fileserver? Aber normalerweise wird bei der Auflösung ja mit Proxies gearbeitet. Ansonsten zum Bearbeiten auf ein RAID 0 Volume und zum Aufbewahren RAID 5/6 oder entsprechend ZFS.
 
Warum proxies, red RAW lässt sich eigentlich wunderbar verarbeiten. Genau wie Canon RAW
 
Ich würde Mal behaupten daß die Schreibgeschwindigkeit sekundär ist weil er die Daten auf dem Server liegend bearbeiten will.
Ich nehme mal an, dass da am Ende ein Video rauspurzelt, was dann auch persistent gespeichert werden soll und das dann nicht lokal erfolgen soll.
Die Frage ist also, was erhofft er sich vom Storagesystem und was muss dieses dazu bereitstellen.
Wenn es darum geht, 2TB Rohmaterial vom Server zu laden, um des dann lokal zu bearbeiten und nach 1 Woche dann das fertige Outputfile hochzuladen mag das gehen.
Wenn es darum geht das Ding als Remotestorage zu benutzen und dort dann eben auch immer zu speichern, sieht das wieder anders aus.
 
Zuletzt bearbeitet:
Selbst wenn der Output 40gb sind oder 150gb, hat er mit 500mb/s absolut vertretbare Geschwindigkeiten zum Sichern, verschieben etc.

Wenn du 8k aus der r5 nimmst hast du pro Clip ~212mb/s. Hast du mehrere gleichzeit im Schnitt und die Daten müssen geliefert werden wird's halt irgendwann eng und das ist dann ein Problem. Nicht das wegsichern der Ausgabe.

Aber was soll's, am besten sagt der TE erstmal was dazu
 
Keine Frage, es ist aber dennoch ein Unterschied, ob ich mit 0,5GB/s oder 2GB/s auf nem Remotestorage schreiben kann oder auf einem lokalen mit 4GB/s.

Das wird nen Officeuser nicht jucken und nen Wald und Wiesen MS Moviemaker Zusammenschneider etwas mehr und nen (semi)prof. User hingegen schon und nen Familienabend "jeder schneidet sein 8k Vid vom Urlaub* noch mehr.

Alles ne Frage der Workload.
 
Einmal kurz das Setup: Es gibt den Fileserver und es gibt 3 feste Rechner für den Schnitt + die Möglichkeit Notebooks zu verwenden. An einem Projekt / Video werden also verschiedene Leute arbeiten.

Nun was ist "das Projekt". Das besteht im Moment aus Multicam 4k Videos (ProRes RAW aus den Atomos Recordern), Multitrack WAV Files, B-Roll und Stock Videos. Mit 4k funktioniert im Moment alles wunderbar. Bald soll alles auf 8k umgestellt werden.

Es müssen eigentlich zwei Dinge beschleunigt werden:
1) Der Kopiervorgang von den SSDs der Recorder auf den Server. Jede SSD wird dann ca. 1,5TB Daten haben, also 4,5TB die auf den Server drauf müssen (ich gehe jetzt von 3 Cams aus). Dann sollte ich schon mit 1,5GB/s auf das Volume auf dem Server schreiben können.

2) Das Lesen des Footage. Einmal der Daten, die aus dem Shooting kommt und dann die Sachen "aus der Konserve" wie B-Roll oder Stock. Und das Scrubben durch die Footage ist insbesondere Zeitaufwendig. Und nein, wir arbeiten nicht mit Proxies. Mit Proxies kann man arbeiten, wenn man Zeit hat. Denn das Erstellen der Proxies dauert. Also liegt alles Remote.

3) Kleine Volumes ala NVMEs irgendwo zu haben, funktioniert nicht. Man braucht schon Größenordnungen rund um die 30TB. Denn sonnst heißt es: Ja, es ist nicht genug Platz auf dem Volume, da Projekt A, B und C noch nicht fertig sind. Und das Runterkopieren der Daten dauert. Und solche Engpässe tauchen immer dann auf, wenn man sie nicht braucht.

4) Am Ende kommt dann eine 100GB Video Datei heraus, die ebenfalls auf dem Server landet. Die ist aber in der Regel nicht der Flaschenhals.
 
Man braucht schon Größenordnungen rund um die 30TB.
Kann man alles kaufen.
Sowas im ZFS Mirror sollte keine Performanceprobleme bekommen. RAIDZ haut halt voll rein.
Evtl. kann @gea was dazu sagen.

Ansonsten sollte man sich von ZFS verabschieden, zumindest für diesen UseCase.
Ein klassisches RAID5/6 mit SAS SSDs kommt auf jeden Fall auf seine 3GB/s schreibend sequentiell.
ZFS macht auf jeden Fall Sinn für ein Backup der Files (kann dann ja im Hintergrund laufen) und als longterm Storage.

EDIT:
Ich bin der Meinung, dass LinusTechTips auch mal was in Richtung Remotestorage für seinen Videoschnitt gemacht hat. In dem Fall aber mit nem 100GBE Uplink des Servers.
Der hat da auch mit nem Haufen SSDs rumgespielt. Aber keine Ahnung was genau und welches OS bzw. Filesystem.
 
Zuletzt bearbeitet:
8k Videoschnitt ist sehr anspruchsvoll. Als erstes würde ich mir Gedanken um die benötigten Datenraten machen. 8k unkomprimiert würde ich mal mit 20 Gbit/s (gut 2GB/s) ansetzen. Bei mehreren gleichzeitigen Streams/Nutzern arbeitet ZFS durch seine sehr guten rambasierten Schreib/ Lesecaches sehr effektiv. Ich würde mal konstante 3 GB/s als notwendig ansetzen.

Wenn man kein Echtzeitschreiben/Lesen mehrerer Streams benötigt sondern nur die Videos schneiden/zusammenführen möchte (mit Unterstützung einer lokalen MNVMe) kann es wohl weniger sein. Man benötigt auf jeden Fall neben einer potenten CPU viel RAM, leistungsfähige Platten und muss alles ausschöpfen was ZFS performancemäßig anbietet Neben den 3GB/s müssen ja noch Prüfsummen geschrieben/gelesen/verarbeitet werden. Die Garantie dass Daten garantiert in Ordnung sind und das automatische Reparieren bei Fehlern wäre mir aber jeden Aufwand wert.

ZFS Copy on Write sorgt dafür dass man kein korruptes Dateisystem bei einem Crash hat. Auch ist es Vorraussetzung für Snaps/Versionierung ohne Zeitverzug und Platzverbrauch nur für geänderte ZFS Datenblöcke. Der Preis ist normalerweise eine höhere Fragmentierung, bei SSD nicht so wichtig und kostet dann kaum Performance.

Ich würde auf 12G SAS SSD setzen. Das ist nicht so exorbitant teuer und aufwändig wie NVMe. Eine SSD kann man mit 1 GB/s ansetzen, mit Multipath und parallellen Zugriffen das Doppelte. ZFS skaliert lesend/schreibend mit der Anzahl der Datenplatten, jedoch nicht linear. Auch wird der Leistungszuwachs mit höherem Durchsatz immer geringer. Ich würde 6 SSD als Minimum ansehen und es erst mal wegen der besseren Nutzkapazität mit einem ZFS Z1 oder Z2 versuchen. Ein Pool aus 3x striped Mirror wäre die Alternative mit ähnlicher sequentieller Leistung aber 3x soviel Schreib iops und 6x soviel Lese-iops und weniger CPU Last. Alternativ ein NVMe Mirror oder Raid-10. Weniger Hochleistungsplatten sind schneller als viele "langsame" Platten.

Ich würde auf einen Expander verzichten, jedoch 2 x 12G BroadCOM LSI HBA einsetzen um Multipath zu nutzen (bis 2 GB/s je SSD bei parallelen Zugriffen), z.B. WD SS530/540 oder Samsung PM.. SAS SSD. Dazu eine Recsize von 1M damit ZFS möglichst effektiv mit großen Daten arbeitet. Ein persistent L2Arc mit einer ca 50-100 GB großen Intel Optane könnte hilfreich sein genau wie ein gleichartiges Mirror für ein special vdev zum Speichern der Metadaten. LZ4 Kompress müsste man testen, Atime sollte man ausschalten. Wenn man nicht gerade Optane einsetzt ist auch aktiviertes SSD autotrim Pflicht. Bei meinen letzten Tests mit HD/4k Video war Oracle Solaris mit native ZFS am schnellsten, kostet aber minimum 1k Euro/Jahr für den nötigen Support Vertrag. Open-ZFS hat aber aufgeholt, vgl https://napp-it.org/doc/downloads/performance_smb2.pdf (etwas älter) und https://napp-it.org/doc/downloads/epyc_performance.pdf.

Neben der Storageleistung braucht man 40G, mit Abstrichen je 10G per Client mit Jumboframes. Daneben muss das Netzwerkprotokoll schnell genug sein (NFS, SMB, FC/iSCSI). Prinzipiell ist da oft Feintuning und Tests nötig, z.B. mit mehreren parallel laufenden AJA Tests oder lokal mit einem fivestreamread/write Filebench.

ps
gleich ein zweites gleichgroßes oder besser größeres langsameres Storage mit Platten für Backup bzw Versionierung nehmen. Mit ZFS Replikation kann man das Storage auch unter Vollast und mit offenen Dateien mit Snaps sichern/in Sync halten.
 
Zuletzt bearbeitet:
ZFS ist kein PerformanceFilesystem.

Lesen mag man >1GB/s kommen, Schreiben wird man bei 0,5GB/s (als Größenordnung) bleiben.
Von daher musst du dich entscheiden, was du denn willst, Kapa oder Speed.
...
Also das ZFS iSER SAN für die ESXi Umgebung meines letzten Arbeitgebers, schreibt und liest auch ganz locker mit >200Gbit/s.
 
Prinzipiell kosten die ZFS Sicherheitsfeautures Prüfsummen auf Daten und Metadaten und Copy on Write Performance. Wenn man darauf verzichtet geht mehr bei gleicher Hardware. Was nicht heißt dass ZFS prinzipiell langsam ist oder sein muss. Der Aufwand wird aber höher.

Ein ZFS Pool mit mehreren GB/s lesend und schreibend ist aber immer drin. Netzwerk ist dann eine andere Frage (FC, iSCSI, IB, iSER bzw NFS, SMB)
 
Das ist natürlich mit checksumm und sync always.
 
Gut, evtl. war ich da nicht präzise genug.

Ich habe jetzt von "normalen" Installationen gesprochen, die man für gewöhnlich @home/SOHO so einsetzt.

Mir sind jetzt vom Free/TrueNAS nur die oben genannten Zahlen/Größenordnungen bekannt.
Wo da jetzt das bottleneck ist, weiß ich nicht., mag auch an der Implementierung liegen.
Oracle ist halt ne andere Nummer als TrueNAS, die sitzen ja an der Quelle.

Evtl. kann @gea ja mal ein paar Zahlen von seiner Implementierung nennen.
Mir scheint aber, dass man neben der HW sehr stark auf die OS-Ebene (und damit die Implementierung) achten muss und damit ggf. noch andere Herausforderungen beim TE.
ZFS ist halt nicht ZFS und ZoL schon dreimal nicht.
 
Zuletzt bearbeitet:
Gut, evtl. war ich da nicht präzise genug.

Ich habe jetzt von "normalen" Installationen gesprochen, die man für gewöhnlich @home/SOHO so einsetzt.

Mir sind jetzt vom Free/TrueNAS nur die oben genannten Zahlen/Größenordnungen bekannt.
Wo da jetzt das bottleneck ist, weiß ich nicht., mag auch an der Implementierung liegen.
Oracle ist halt ne andere Nummer als TrueNAS, die sitzen ja an der Quelle.

Evtl. kann @gea ja mal ein paar Zahlen von seiner Implementierung nennen.
Mir scheint aber, dass man neben der HW sehr stark auf die OS-Ebene (und damit die Implementierung) achten muss und damit ggf. noch andere Herausforderungen beim TE.
ZFS ist halt nicht ZFS und ZoL schon dreimal nicht.

Meine Hardware:
SuperMicro H12SSL-C, Epyc 7302 128 GB RAM, SAS 3008 (BTO system) 7 x WD Ultrastar 8TB, 3 x Optane 900, 3 x Intel DC 750 (traditional Flash NVMe), OmniOS (Solaris Fork), jeweils Raid-Z1. Ich habe virtualisiert mal die Kerne halbiert und kam auf fast gleiche Werte. Braucht also nicht unbedingt 16/32 Core.

Plattenpool ca 1100 MB/s schreibend (lesen abhängig vom Cache, normalerweise mindest gleichschnell)
Flash NVMe Pool 1500-1800 MB/s
Optane Pool 3300-3500 MB/s

@Sir Diablo
200 Gbit/s sync=always habe ich noch nie gesehen. Ich halte das selbst bei rambasierten Systemen für kaum erreichbar. Mit einem Pool aus drei Optane 900 im Raid-0 kam ich gerade mal auf knapp 1500 MB/s sync auf einem 16/32Core AMD Epyc mit 128 GB RAM.
 
Das ist ein "volles" SuperStorage 2029P-DN2R24L, Zugriff von drei ESXi Hosts parallel. Da werden die beiden 100GbE Karten (je Node) voll ausgereizt.
 
Ich glaube das waren 24 Samsung PM1725a gesplittet in je 2 vDisks (für jedes Node eine vDisk), 192GB RAM (je Node), 2* Xeon 62(1?)44 (je Node) und 2* Mellanox CX4 (je Node). Je Node ein RaidZ über 17 Disks, ein StipedMirror über 4 Disks und der Rest HotSpare.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh