Shared ZFS video editing storage für MacPro bzw Windows mit 10Gb

gea

Urgestein
Thread Starter
Mitglied seit
16.11.2010
Beiträge
5.644
Ich habe ein paar Test gemacht um Antworten zu finden über:

- Reicht Shared ZFS Storage für eine bestimmte Videoqualität
- SMB1 vs SMB2
- mtu 1500 vs MTU 9000 (Jumboframes)
- NVMe vs SSD vs Disks
- Raid 0/Mirror vs RaidZ
- Single user vs multiple user
- Single pool vs multi pools

Nur ein paar schnelle Tests um Prinzipielles zu erkennen.
http://napp-it.org/doc/downloads/performance_smb2.pdf

- - - Updated - - -

Dazu passend:
Grade eben kam die Mail, dass OmniOS bloody mit SMB 2 verfügbar ist.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Update

Ich habe die gleichen SMB2 Tests mit 10G Ethernet und OSX auf OmniOS 151017 bloody gemacht
und das pdf ergänzt.

Fazit des Schnellchecks

- Treiber und OS Version sind ultra kritisch
- Auf OSX ist SMB2+ Pflicht
- Performance geht nur mit Jumboframes
- Von Windows aus ist Solaris und OmniOS ähnlich schnell
- OSX ist mit SMB2 deutlich schneller als Windows und schneller auf Solaris als OmniOS
- Eine lokale NVMe disk wie eine Samsung Pro M2 ist etwas schneller als ein Shared Storage
- Shared Storage ist aber mit 10G Ethernet schneller als eine 6G SSD

- SMB2 Performance geht am Mac bis > 600 MB/s schreiben und > 800 MB/s lesen
- SMB Performance geht unter Windows bis > 300 MB/s schreiben und 600 MB/s lesen.

Insgesamt sieht das doch recht tauglich für Video aus.
Unter Windows muss man eventuell nochmal verschiedene Einstellungen testen.

Überrscht hat mich, wie schnell OSX 10.11 out of the box mit 10G ist.
 
Wie wäre es mit einem Test über NFS? Sollte sich bei OSX doch eigentlich anbieten oder?
Mich würde interessieren, wie sich das Protokoll auf Datendurchsatz und CPU Last auf Client und Server auswirkt.
Ich habe 2 ZFS Systeme im Einsatz die ich fast nur über NFS nutze, SMB/SMB2 könnte aber auch mal interessant werden.
 
NFS ist eigentlich nur für ESXi interessant (mit Vollzugriff).
Unter OSX war NFS für mich bisher allenfalls der Notnagel wenn ich Performance ohne Authentifizierung brauchte.

Immer wenn Authentifizierung oder Authorisierung gebraucht wird, ist SMB das Protokoll der Wahl und mit SMB2 und Jumbofarmes auch richtig schnell. SMB ist zudem das aktuelle Apple Strandard Filesharingprotokoll.
 
Update

Ich habe noch Tests mit NFS unter OSX 10.11 gemacht.
Dabei ergaben sich Stabilitätsprobleme (Verbindungsabbrüche) und eine Schreibperformance von 70 MB/s und 150 MB/s lesen.

NFS muss erheblich schneller sein. Ich schiebe das mal auf OSX wo ich auch früher gerne NFS Probleme hatte,
Auf jeden Fall ist es keine Option für OSX, dazu ist auch der Apple eigene SMB2 Stack zu gut.
 
Danke fürs testen, da scheint aber wirklich etwas extrem schief zu laufen.
In meiner Umgebung bekomme ich mit NFS das 10GBit Interface ausgelastet ohne viel CPU Last zu erzeugen.
Wir haben hier ein paar vereinzelte MACs in Büros stehen, die berichten in letzter Zeit auch von Verbindungsabbrüchen mit SMB(ohne v2). Seit dem letzten OSX update scheint da etwas nicht mehr rund zu laufen.
Vor einiger Zeit hatten wir mal ein NFS Share an OSX angebunden, lief damals überraschenderweise stressfrei mit zentraler LDAP Nutzerverwaltung. War aber nur ein Testlauf und nie produktive Lösung hier.

Was ist für SMB2 deine Authentifizierungsquelle, melden die sich alle an einem AD an? Sind die MAC user mit denen im AD synchronisiert oder werden die Shares nur mit Nutzerkontext verbunden?
 
Wir nutzen Windows Active Directory. Unsere Pool-PC sind Domänenmitglied, unsere Pool-Macs nutzen nur einen lokalen Defaultuser "Student" mit eingeschränkten Rechten bzw einen lokalen Account bei Mitarbeitern. AD und Profile am Mac wären mit den kleinen MacPro Platten eh problematisch. Lediglich beim Anmelden an den Fileservern wird der Domänenaccount auch am Mac benutzt (Der OmniOS Filer ist Domänenmitglied).

Wir nutzen an unseren Macs ausschliesslich SMB - auch wegen der Kompatibilität zu Windows und der Rechteverwaltung per AD. Das ist mit AFP oder NFS nicht so einfach oder gar nicht möglich. Die bisherige geringe Performance von SMB1 unter OSX ist ja mit SMB2 obsolet - ist sogar schneller als SMB unter Windows - Mal sehen wie man Windows noch etwas tunen kann.
 
Ich habe noch etwas mit den Windows Netwerkeinstellungen unter 10G herumgespielt

Aktueller Stand:

Server ist OmniOS 151017 bloody
OSX mit 10G Sanlink 2, Jumboframes MTU 9000, SMB2 (smb://omnios): über 600MB/s write und 800 MB/s read
Windows 8.1/10 mit Intel X540, Jumboframes MTO 9014 und Interupt Throtteling aus: 600 MB/s write und 700 MB/s read

so gefällt mir das langsam
http://napp-it.org/doc/downloads/performance_smb2.pdf
 
Hast du unter windows außer "Deactivate Interrupt throttling on Windows and enable Jumboframes (9014) " noch etwas angepasst?
Und nutzt du wirklich einen pool pro user?
Für ordentliche Performance hat man mir immer große striped mirrors empfohlen. Aber du willst vermutlich garantieren, dass jeder user eine garantierte performance von Storage erwarten kann oder? Wenn das der Fall ist, wie hast du die Netzwerkanbindung dann realisiert? Aggregierte 10GBit links am Storage?
 
Im Moment reicht mir ein Raid-Z2 Pool (single vdev mit 10 x HGST 2TB) und single link 10 GbE völlig aus da bestenfalls Video bis HD geschnitten wird (Studierenden Pool für Animation und Video mit 12 Rechnern wobei nicht alle dauernd Video schneiden). Das wird sich eventuell ändern wenn mal etwas mit höherer Auflösung geplant ist. Da geht ein Pool doch zu sehr in die Knie. Dann würde ich mir einen Pool je Arbeitsplatz oder für das eine oder andere Spezialprojekt überlegen. Dann wäre Link Aggregation eine weitere Option. Der HP 5900 Switch an dem das hängt hat Reserven und 40 GbE.

Zumindest bei meinen sequentiellen Tests war der Unterschied zwischen Raid Z2 und multiple Raid-0/Mirror bei single user access vernachlässigbar. Bei 6 gleichzeitigen Usern/Mac Pro insbesondere mit weniger RAM war dann iops wichtig und da gehts eher Richtung SSDs.

Ich habe übrigens mal gerade testhalber den RAM von 40 GB auf 8GB reduziert. Bei Single user Access auf den Z2 Pool hatte ich immer noch 400 MB/s schreiben und 600 MB/s lesen. Bei 6 gleichzeitig aktiven Rechnern ging das dann auf 70 MB/s und 200 MB/s herunter. Bei einem SSD Pool ergaben sich da doppelt so gute Werte. Mit 6 Usern und 40GB RAM nochmal eine Verdoppelung.

Entscheidend für Performance ist 10G, SMB2, Jumboframes und z.B. die Einstellung IRQ throttling bei Windows (sonst habe ich bei Windows nichts geändert, hier war die entscheidende Verbessererung). Viel RAM wird erst bei Multi-User oder absolut sehr hohen Ansprüchen entscheidend.

Aktualisierter Stand mit wenig RAM
http://napp-it.org/doc/downloads/performance_smb2.pdf
 
Zuletzt bearbeitet:
Ein pool layout, dass auch bei mehreren Zugriffen noch das Netzwerkinterface auslasten kann wäre ja meine Strategie. Hätte sonst sorge das die performance der kleinen pools bei hohem Füllstand einbricht.
Ein großer Pool und entsrechende Quotas haben den Vorteil, dass sich die Platten gleichmäßig füllen.

Ich habe hier einen ZFS Filer mit 10GBit Interface auf dem größere Datenmengen für Visualisierung liegen. Daten werden da also einmal hingeschoben und dann intensiv ausgewertet, daher gibt es wenig writes, noch weniger random writes und verhältnismäßig viele lesenden Zugriffe.
Da habe ich 2 striped raidz2 pools aus je 11 3TB HDDs, also keine besonders performantes layout. Mit 256GB RAM limitiert bei vielen workloads trozdem das Netzwerkinterface.
Mit mehr striped pools oder SSDs anstelle der HDDs kann man die write performance an den eigenen Bedarf anpassen. Zeus-ram oder ähnliches soll bei mehr random i/o helfen. Aber fürs lesen ist ein großer ARC cache schon extrem hilfreich.
Wenn dein ARC cache groß genug ist um die Daten von ein paar Nutzern komplett zu puffern wird die pool performance weniger kritisch.
Die 256GB RAM im Filer entsprechen bei uns ca. 2x maximale filesize zum visualisieren. Da im Rechner für die Visualisierung 128GB RAM verbaut sind machen größere Datensätze keinen Sinn. So können wir 2-3 oder mehr Bearbeitungsschritte im ARC halten und reduzieren die Zugriffe auf die verhältnismäßig langsamen pools.
Aber bei uns limitiert da eher der Rechner der die Daten zu verarbeiten hat als das Storage.

Datensätze mit vielen kleinen Files liegen eher auf einem anderen Storage mit SSD cache für kleine files und metadaten.
 
@gea Fr@ddy
Ich nehme an ihr arbeitet in grösseren Unternehmen?
Ganz geile Arbeit und danke für eure Posts, sehr aufschlussreich (besonders deine Tests gea).
Von solcher Arbeit als Engineer/Admin (im industriellen Gewerbe) aka Mädchen für alles (KMU halt^^) kann ich nur träumen
 
Es gibt halt kein universell bestes "ZFS Layout" ausser man nimmt immer das Maximale.

Insbesonders viel RAM geht richtig ins Geld zumal es beim Schreiben nichts bringt - oder nur über den Umweg geringerer paralleler Lesezugriffe. Da sind mehrere kleinere schnelle Projektpools z.b. SSD mirrors günstiger bei schreiblastigen Workloads wie Videoediting.
Für das Meiste reicht ja ein normaler Raid-Z Pool, eventuell ein größerer SSD Pool auch aus - wird ja immer billiger.

Ein NVMe L2Arc mit set zfs:l2arc_noprefetch=0 damit es auch sequentielle Daten cacht wäre eventuell noch ein Kompromiss.


@Shiga
Ich arbeite hauptberuflich im Hochschulbereich wo Innovation wichtiger ist als sofortige Produktivität -
wobei es dafür gerne an Geld und Personal hapert.
 
Zuletzt bearbeitet:
Naja die streamed write performance ist auch bei HDDs nicht schlecht wenn man genügend pools striped. Man kann sie nur viel einfacher mit ein paar random Zugriffen ruinieren als bei SSDs.
Ich hatte vor der Beschaffung unseres größeren Filers auch mal über einen SSD only pool nachgedacht, aber die Preise für SAS SSDs waren da noch recht hoch. NVME Support gab es noch nicht und mit SATA konnte man nur kleinere Systeme realisieren, da von SATA devices hinter SAS Adaptern in Verbindung mit ZFS abgeraten wurde. Da hatte sich das schnell erledigt.
Aber RAIDZ Pools mit SSD only sind auch interessante Layouts. Damit bekommt man schon beeindruckende Performance hin. Wenn man sich überlegt was Systeme mit ähnlicher I/O Leistung vor ein paar Jahren gekostet haben und wie viel Aufwand einige Hersteller dafür betrieben haben.

Ich bin auch gespannt wie sich deine SSD pools bei hohem Füllstand verhalten und nach mehrmaligem überschreiben. Das sind Infos mit denen viele Hersteller nicht gern rausrücken.

@Shiga
Bin ebenfalls nicht in der freien Wirtschaft beschäftigt sondern an einem forschendem Institut an einer Uni.
Produktivität spielt bei uns schon eine Rolle. Ausfälle können teuer werden wenn man einen HPC Cluster betreibt.

Ich denke die meisten Jobs haben so ihre Vor- und Nachteile. Das schöne daran ist aber, dass selber einen großen Einfluss darauf hat welchen man ausübt.
Auch wenn wahrscheinlich die wenigsten uneingeschränkt glücklich mit ihrem job sind und irgendwo Kompromisse machen müssen.

Ein Traumjob ist meiner mit Sicherheit auch nicht, aber sind alles Kompromisse mit denen ich leben kann.
 
Naja die streamed write performance ist auch bei HDDs nicht schlecht wenn man genügend pools striped. Man kann sie nur viel einfacher mit ein paar random Zugriffen ruinieren als bei SSDs.
Ich hatte vor der Beschaffung unseres größeren Filers auch mal über einen SSD only pool nachgedacht, aber die Preise für SAS SSDs waren da noch recht hoch. NVME Support gab es noch nicht und mit SATA konnte man nur kleinere Systeme realisieren, da von SATA devices hinter SAS Adaptern in Verbindung mit ZFS abgeraten wurde. Da hatte sich das schnell erledigt.
Aber RAIDZ Pools mit SSD only sind auch interessante Layouts. Damit bekommt man schon beeindruckende Performance hin. Wenn man sich überlegt was Systeme mit ähnlicher I/O Leistung vor ein paar Jahren gekostet haben und wie viel Aufwand einige Hersteller dafür betrieben haben.

Ich bin auch gespannt wie sich deine SSD pools bei hohem Füllstand verhalten und nach mehrmaligem überschreiben. Das sind Infos mit denen viele Hersteller nicht gern rausrücken.

Man sollte ZFS Pools aus Platten nicht ganz füllen, da dann die Performance wegen der Fragmentierung nachlässt. Ich versuche immer unter 80% zu bleiben. Bei SSDs gibt es kein Fragmentierungsproblem jedoch Probleme dadurch daß das Schreiben mit 4k Pages erfolgt, die vorher gelöscht werden müssen, damit Probleme mit Trim und Garbagecollection sowie Probleme durch die begrenzte Anzahl von Schreibzyklen pro Zelle.

Wenn man daraus Raid Pools bauen möchte, dann ist wichtig
- möglichst guter Controller/ Firmware für gute interne Garbage Collection
- möglichst hohes Overprovisioning (Platz für den Controller zum Optimieren)
- möglichst gutes, schnelles und langlebiges Flash

- wenn transaktionssicheres Schreiben benötigt wird: Powerloss Protection im Raid oder auf einem Slog

Meine erste Wahl bei kritischen Pools ist Intel. Ich setze gerade ältere SSD Pools auf S3610 um, sehr gute Erfahrung bisher. Wenn es mehr um Lesen geht, dann die S3500 und für beste Schreib-IO die S37x0.

Ich habe auch Storage mit den älteren Desktop SSDs Sandisk Pro extreme und Winkom Pro. Die waren günstig und bieten ein relativ hohes Overprovisioning per default. Das kann man z.B. per Host protected area selber vergrößern, das soll aber bei manchen neueren SSDs Probleme machen. Ich hatte die Winkom bisher im Mailserver. Der ist nach Umstellung auf S3610 deutlich reaktiver geworden.

Nach ca 3 Jahren tausche ich aber momentan die SSD (gehen dann in die Rechnerpools oder in Arbeitsplätze)
 
Zuletzt bearbeitet:
Ich habe es zwischenzeitlich mit etwas OmniOS Tuning geschafft, die Performance nochmal um 20-30% zu steigern.
Unter Windows erhalte ich jetzt Schreibraten mit SMB 2.1 von 800-900 MB/s und Leseraten von 600 MB/s bis 700 MB/s zu einer einzelnen Intel P750 als ZFS Basispool.

Um das Tuning zu vereinfachen, habe ich in napp-it 16.1p ein Tuningpanel mit einer Basis Tuningkonfiguration im Menü System > Tuning hinzugefügt,
in dem auch bis zu 10 eigene Einstellungen anlegen, speichern und setzen kann, wahlweise mit BE und direktem Reboot.

Ich habe die pdf ergänzt.
http://napp-it.org/doc/downloads/performance_smb2.pdf
 
Sehr schön!

Werde auch mal testen bei Gelegenheit, erwarte es bei mir grundsätzlich nur eher umgekehrt: lesend deutlich schneller als schreibend (4 consumer SSDs im "no-Parity-Pool") - ist jetzt auch schon so.
 
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