[Sammelthread] ZFS Stammtisch

[snipor]

Was es bewirken soll? Keine Ahnung, ich versuche ja nur herauszufinden wie ich mein System irgendwie verbessern kann. Das war einer der Tipps aus einem der FreeNas Threads.
Wenn ich den CDM Benches trauen kann, dann ist die Random Lese- und Schreibperformance mit 128k deutlich schlechter als mit kleineren Werten.
Wenn Du mir jetzt aber sagst, dass das Quatsch ist dann werde ich wohl wieder auf 128k stellen.
Andere User scheinen die Probleme aber ja nicht zu haben, also scheint es an irgendetwas an meinem System zu liegen.
Ich weiß nur nicht an welcher Stelle ich sonst schrauben soll.....

 

[gea]

4K Read QD1 bedeutet zunächst nur das Lesen kleiner Datenblöcke ohne Lese Optimierungen oder parallele Operationen. Da kann eine kleine Recordsize tatsächlich helfen. Daher auch die Empfehlung z.B. für einen SQL Datenbankserver eine Recordsize von z.B. 32K zu nehmen.

Kleine Random Datenblöcke werden bei ZFS aber ausserhalb von Benchmarks im Realbetrieb aus dem RAM Lesecache geliefert. Man sollte Benchmarks da nicht überbewerten. Ich nutze Benchmarks (und dann lokale z.B. Pools > Benchmarks damit Netz und Dienste das nicht verfälschen) eher für vergleichende Optimierungen.

 

[snipor]

Und wie sieht es bei den Random Write Tests aus? Sind diese auch nicht mit dem Realbetrieb vergleichbar? Was passiert wenn viele sehr kleine Dateien geschrieben werden, so dass die im Moment 3GB Schreibcache voll werden?

 

[gea]

Mit ausreichend RAM gibt es bei ZFS (im Normalbetrieb bis auf sync-write) keine ganz kleinen Random-Writes da diese im RamCache gesammelt werden und als größeres sequentielles Write auf die Platte gehen. Die sequentielle Pool-Performance muss dann nur größer sein als die Netzperformance.

Bei OmniOS geht das dynamisch. Der Cache hat eine bestimmte Größe und wird bei einem bestimmten Füllgrad auf Platte geschrieben und nimmt parallel dazu weitere Writes auf. Ziel ist eine gleichmäßige Schreibleistung.

Solaris arbeitet zeitbasiert. Da werden z.B. 5s lang alle Writes gesammelt und dann geschrieben. Das führt zu einer besseren Performance bei kurzer Last. Die Schreibperformance kann da aber bei konstanter Last kurz einbrechen. Sieht man z.B. bei einem AJA Videotest mit großen Datenmengen.

Hat natürlich alles seine Grenzen. In den Metadaten und den Datenblöcken bleiben kleine Dateneinheiten. Man spart nur beim Schreiben Zeit und nutzt die Platten iops besser aus. Wenns kritisch wird mit kleinen random writes, hilft wohl nur rohe Poolperformance z.B. mit Optane

 

[you]

A
Hier gehts darum wie schnell und sicher "sicheres Löschen" ist.
Selbstverschlüsselnde Festplatten (SSD, self encrypting drives) Un|SicherheitsBlog
Wenn das egal ist, die billigste nehmen.

Wenn man einen Expander vorhat, SAS nehmen

B
Für ZFS und aktuelle Systeme egal. Die nutzen in beiden Fällen 4k physical und ashift=12.
512E ist zusätzlich kompatibel mit älteren Systemen

Danke Gea.

 

[snipor]

In welchen Fällen sollte man überhaupt sync-write nutzen? Bzw. welche Einstellung (standard, always, disabled) ist die geeignetste wenn ich wie in meinem Fall diese Konfiguration habe?
StorageVm(napp-it) --> Storage-Pool --> NFS --> ESXi --> Windows Server VM --> Datenfreigabe --> Client (Netzlaufwerk)

Und sollte ich dann eher auf 32k, 64k oder 128k stellen?

Danke

 

[gea]

Bei ZFS gehen ja alle Schreibvorgänge in den Ram-Schreibcache und werden gegenüber dem schreibenden Prozess bestätigt. Gibt es nun einen Crash ist der Inhalt des Schreibcaches verloren. Im Gegensatz zu ext4 oder ntfs kann es dadurch zwar wegen CopyOnWrite zu keinem korrupten Dateisystem kommen, dennoch sind bestätigte Schreibvorgänge ganz oder teilweise verloren. Für Datenbank Transaktionen z.B. Abbuchen von einem Konto + Aufbuchen auf ein anderes oder alte Dateisysteme wo abhängige Schreibaktionen wie aktualisiere Daten, dann aktualisiere Metadaten üblich sind kann das fatal sein (Inkonsistente Datenbank oder inkonsistentes Dateisystem).

Bei einem Hardware-Raid würde man nun einen Controller mit Cache und Flash/BBU Sicherung nehmen. Bei ZFS aktiviert man einfach sync-write um jeden bestätigten Schreibvorgang zu protokollieren, entweder im onpool-ZIL oder einem schnelleren Slog. Bestätigte Schreibvorgange werden dann nach Crash und Reboot nachgeholt. Bei einem Produktions-VM-Storage ist also sync-write absolute Pflicht.

Bei der Voreinstellung sync=default entscheidet der schreibende Prozess ob der Schreibvorgang syncron oder asyncron erfolgt. ESXi über NFS möchte gerne syncron schreiben. Mit always und disabled kann man sync immer erzwingen oder abschalten.

Für einen normalen Filer ist eine große recordsize eher schneller/vorteilhaft. Für VMs würde ich mit 32k oder 64k eher bessere Werte erwarten.

 

[Trambahner]

Mit der Recordsize hab ich das für OpenZFS aber so verstanden, dass die Property lediglich die maximale Größe angibt. D.h. ZFS kann durchaus z.B. nur einen 32K oder 64K Block belegen, wenn recordsize=1M (IMO das höchste freigegebene) gesetzt ist, oder?

 

[gea]

Das ist korrekt.
ZFS (Original Solaris ZFS und Open-ZFS) verteilen eine Schreibaktion z.B. 168 K zunächst in Blöcken in Recsize z.B. 128K und einen eventuellen Rest in kleinere Häppchen, also in diesem Beispiel je einmal 128K + 32K + 8K

Bei einer recsize von 32K wären das 5 Blöcke à 32K und ein Block von 8K

(nicht zu verwechseln mit der Platten-Blocksize von immer 512B oder 4K je nach Plattentyp)

 

[Trambahner]

Jetzt kommts mir erst. Erst dachte ich vereinfacht: "ok, dann immer 1M".
Aber wenn eine VM dann permanent viel kleine random-Blöcke liest und schreibt und diese in großen ZFS-Blöcken liegen, immer die großen Blöcke gelesen werden, auch wenn nur 1 Byte geändert wird.
Und dann wieder weggeschrieben.. D.h. wenn nur genug VMs (oder eine heavy) das tun, kleistert mir das sinnlos die Bandbreite zu. Bei schnellen Pools merk ich das halt nicht sofort.

Ich mein, ich hab auf meinen Medien-, Software- und Archivdatasets (wo also große, fast nie beschriebene Files) 1M gesetzt und bei den allg. Datenshares sowie nfs-Shares für VMs 128K (default).

 

[CommanderBond]

Gibt übrigens nun centos7 als LX Container, hoffe mal Debian9 folgt auch in nicht all zu ferner Zukunft.

 

[snipor]

Wie ist eigentlich in meinem Fall (StorageVm(napp-it) --> Storage-Pool --> NFS --> ESXi --> Windows Server VM) der Zusammenhang zwischen der ntfs block size (z.B. 4k) und der ZFS recordsize (z.B. 128k)?

 

[gea]

ESXi stellt eine vdisk als Blockdevice bereit die mit ntfs formatiert wird. Mehr ist für Windows nicht wichtig.

Ist bei SSDs ja ähnlich. Auch da ist die SSD intern in pages und teils Megabyte großen Blocks organisiert
ohne dass ESXi oder Windows davon was wissen muss, Solid-State Drive – Thomas-Krenn-Wiki

 

[you]

In meinem NAS habe ich die SATA-HDs am Broadcom 3008 (12GBs) und die SATA-SSDs am PCI H310/9211 (6GBs).

Ist das OK oder sollte ich tauschen?

Bisher war ich davon ausgegangen, dass es egal ist, wie ich die Drives den Controllern zuordne, da beide, HDs/SSD, eh nur 6GBs können. Bin grad aber unsicher, ob ich da was außer Acht lasse.

 

[Phantomias88]

In meinem NAS habe ich die SATA-HDs am Broadcom 3008 (12GBs) und die SATA-SSDs am PCI H310/9211 (6GBs).

Ist das OK oder sollte ich tauschen?

Bisher war ich davon ausgegangen, dass es egal ist, wie ich die Drives den Controllern zuordne, da beide, HDs/SSD, eh nur 6GBs können. Bin grad aber unsicher, ob ich da was außer Acht lasse.

Hallo, es sieht so aus, als hättest du dein Easter-Egg gefunden.
Die 12Gbs und 6Gbs beziehen sich auf die SAS Schnittstelle, nicht aus SATA.
Nur der mit 12Gbs kann auch die vollen 6Gbs mit SATA die SSD heute schon gut ausnutzen, vor allem wenn mehrer SSD dran hängen sind 6Gbs Pflicht.
Gbs = GigaBits
GBs= GigaBytes

 

[Trambahner]

Der H310/9211 (SAS 2008) ist PCIe 2.0, de 3008er PCI 3.0. Bei PCIe2x8 ist also spätestens bei etwa 3,5 GB/s Ende, da am Bus nicht mehr durchgeht. Ob der Chip selbst intern diese Bandbreite verarbeiten kann: k.a.
Der 3008er hat auch intern mehr Leistung/Verarbeitungskapazität.

SSD-Pools > 4 oder 5 SSD würde ich daher auf den 3008 umhängen.

 

[you]

Danke Euch beiden. Hat mein Bauchgefühl bestätigt. Ich hatte das bisher nur noch nie zu Ende gedacht

 

[Phantomias88]

Danke Euch beiden. Hat mein Bauchgefühl bestätigt. Ich hatte das bisher nur noch nie zu Ende gedacht

Der Unterschied zwischen den beiden Kontroller liegt allein in der Bandbreite bei 600 MB/s vs 6000 MB/s.
Die Latenz wird auch besser sein, da Erweiterungskarten immer etwas weiter weg sind auf dem PCB.

Nimm die Summe deiner Lese-Leistung aller Daten-Träger und teile es entsprechend auf.
Mit 600MB/s sind ~ 6 HDDs zeitgleich möglich.

Am besten so viele Benchmark Fenster öffnen wie Laufwerke vorhanden sind und alle nacheinander starten.

 

[snipor]

Lässt sich ACL in napp-it eigentlich abschalten? Würde das Sinn machen wenn man die Pools lediglich per NFS für ESXi bereitstellt und dort dann eine Windows Server VM die Rechteverwaltung übernimmt. Kein SMB oder ähnliches.

Gibt es irgendwie eine Erklärung der Abkürzungen, z.B. für die Reservations RES und RFRES, oder bei den Quotas QUO und RFQU, wofür steht das RF?
Habe zwar schon danach gesucht aber vermutlich nach den falschen Begriffen

 

[gea]

Nein.
Dateirechte, egal ob traditionelle Unix Permissions oder ACL (Bei Solarish Windowsartige NFS4 ACL) müssen immer beachtet werden.

Da NFS v3 keine Authentifizierung kann, muss man je nach Client everyone, nobody oder der UID Zugriffsrechte geben. Da es keinen wirklichen Schutz bei NFS v3 innerhalb eines Netzwerks gibt (bis auf Firewall und goodwill IP Settings), kann man einfachhalber rekursiv everyone@=modify setzen.

Unix Permissions und ACL sind auch kein entweder/oder sondern ACL sind eine Erweiterung die viel feinere Möglichkeiten und Vererbung bietet. Sind ACLs gesetzt, werden sie beachtet. Die Basis ACL entsprechen dabei den Unix Permissions. Werden Unix Permissions gesetzt, wird bei den ACL allerdings die Vererbung gelöscht da es sowas bei traditionellen Unix Rechten (owner, group,everyone) nicht gibt. Idealerweise daher immer mit ACL arbeiten, am Einfachsten über ein zusätzliches SMB Share zu der NFS Freigabe (gibt dann auch über Windows und vorherige Version Zugriff auf ZFS Snaps) und SMB Anmeldung als root bzw via napp-it ACL extension.

Zu den Quotas und Reservierungen (Quotas/ Reservation and Refquotas/Refreservation) und dem Unterschied:
z.B. Setting ZFS Quotas and Reservations (Solaris ZFS Administration Guide)

ps
Wenn man SMB Sharing über Windows auf Basis einer VM oder ZFS zvol macht gewinnt man SMB3 (hat erst Original Solaris) verliert aber den filebasierten Zugriff auf ZFS Snaps über "vorherige Version". Windows Shadow Copies sind da nur ein müder Abklatsch und bieten auch keinen Schutz gegen Ransomware.

 

[snipor]

Gea, danke für die Infos und den Link.

Ich habe den Pool über NFS3 an ESXi angebunden. Unter ESXi ist hier ein eigenes, virtuelles Storage Network angelegt. Hier sollte eigentlich kein zusätzlicher Zugriffsschutz nötig sein(NFS4) oder liege ich hier falsch? Oder wäre da dann ISCSI besser? Das wäre aber vermutlich wieder langsamer. Verwendung ist ja ausschließlich Homeuse.

D.h. wenn ich den Pool über NFS an ESXi und dort an die Windows Server VM übergebe und dort die Rechtevergabe und Dateifreigabe über Windows mache funktionieren keine ZFS Snaps mehr?

Oder welche Funktion meinst Du mit "vorherige Version"?

 

[gea]

Gea, danke für die Infos und den Link.

Ich habe den Pool über NFS3 an ESXi angebunden. Unter ESXi ist hier ein eigenes, virtuelles Storage Network angelegt. Hier sollte eigentlich kein zusätzlicher Zugriffsschutz nötig sein(NFS4) oder liege ich hier falsch? Oder wäre da dann ISCSI besser? Das wäre aber vermutlich wieder langsamer. Verwendung ist ja ausschließlich Homeuse.

D.h. wenn ich den Pool über NFS an ESXi und dort an die Windows Server VM übergebe und dort die Rechtevergabe und Dateifreigabe über Windows mache funktionieren keine ZFS Snaps mehr?

Oder welche Funktion meinst Du mit "vorherige Version"?

Ich nehm auch immer NFS3, wenn nötig in einem eigenen Netz oder mit Firwallschutz. Ist einfach, schnell und hat im Gegensatz zu iSCSI auch kein Problem mit verzögerten Mount (Storage VM stellt NFS mit weiteren VMs ja erst mit einer Verzögerung bereit). Performancemäßig ist NFS mit gleichen Einstellungen wie sync=on und iSCSI mit writeback=off ähnlich schnell.

Vorherige Version ist ein Windows Feature (Dateiexplorer > Datei/Ordner > Eigenschaft > vorherige Version) um unter ntfs auf Windows Shadow Copies zuzugreifen. Ist der Server ZFS/Solarish so greift man stattdessen auf die ZFS Snaps des Dateisystems zu.

Nutzt man Windows um ein ZFS Dateisystem (zvol) oder Datei (ESXi vdisk) zu sharen, so greift vorherige Version nur auf Windows Shadow Copies zu. ZFS Snaps kann man zwar für das zvol oder das NFS Dateisystem anlegen. Das wirkt jedoch dann auf das ganze Dateisystem das man dann nur komplett per Rollback zurückstellen kann. Es gibt keinen dateibasierten Zugriff mehr auf ZFS Snaps. Das geht nur wenn man das ZFS Dateisystem direkt über den Solarish SMB Server freigibt.

- - - Updated - - -

Das würde mich jetzt auch mal interessieren. Wie geht das überhaupt.

Wenn man Windows als Dateiserver für ZFS Storage nutzen möchte, so legt man üblicherweise unter ZFS ein Zvol an (Dateisystem als Blockdevice). Daraus erstellt man ein iSCSI Target und mountet das daraus erzeugte LUN mit dem in Windows beiliegenden iSCSI Initiator Service. Das ZFS LUN wird dann als lokale Platte verwaltet die man per SMB freigeben kann.

 

[snipor]

I]
Wenn man Windows als Dateiserver für ZFS Storage nutzen möchte, so legt man üblicherweise unter ZFS ein Zvol an (Dateisystem als Blockdevice). Daraus erstellt man ein iSCSI Target und mountet das daraus erzeugte LUN mit dem in Windows beiliegenden iSCSI Initiator Service. Das ZFS LUN wird dann als lokale Platte verwaltet die man per SMB freigeben kann.

Geht das auch mit NFS über ESXi? Oder muss es dann iSCSI sein?

Geht das auch wenn der Windows Server keine SMB sondern eine NFS Freigabe macht?

 

[gea]

1.
Windows braucht eine lokale ntfs formatierte Festplatte.
Mit NFS ginge das nur über den Umweg ESXi und vdisk (langsam)

2.
Windows Server kann eine lokale ntfs Festplatte auch als NFS freigeben

Bleibt die Frage warum?
oder warum einfach wenn es auch kompliziert geht. Solaris ist ein viel besserer NFS Server (Sun hats ja erfunden) und in vielen Punkten ein besserer SMB Server (ZFS Snaps, Performance, Schutz vorheriger Versionen gegen Ransomware, keine dauernden Reboots wegen kritischen Updates, Replikation einzelner Dateisysteme etc.). Windows macht nur Sinn wenn man ein spezielles Feature braucht wie z.B. SMB3 Multipath.

 

[gea]

Mit SMB Multichannel kann man Netzwerk Performance und Verfügbarkeit bei mehreren Netzwerkarten im Server und Client verbessern. ZFS gibt überragende Datensicherheit und hat im Vergleich zu btrfs/ReFS mehr Features, Stabilität und Performance.

Wenn es um Performance geht ist 10G das Mittel der Wahl und nicht der Aufwand mehrerer Netzwerkkarten. Man kann SMB3 und ZFS aber nicht gegeneinander aufrechnen.

Für @home wäre eventuell Solaris 11.4 noch eine Option. Kostet da nichts, hat SMB3 und ist überragend schnell mit einzigartigen Features wie ZFS Verschlüssellung, NFS 4.1 oder sequentielles schnelles Resilvering.

 

[snipor]

Wie sieht eigentlich die Umsetzung im komerziellen/professionellen Umfeld aus wenn ZFS zum Einsatz kommt? Ist da dann nicht meist auch ein Windows Server für Dateifreigaben involviert? Oder sieht da die Umsetzung in der Regel anders aus?

 

[gea]

Soweit wie ich das überblicken kann ist ein Windows Fileserver mit ZFS Backend eine eher exotische Lösung. Entweder nimmt man Windows only, allenfalls mit ReFS für höhere Datensicherheit oder man nimmt ZFS und ein Unix (BSD, Solarish) oder Linux System direkt als Fileserver. Wenn man ntfs artige ACL braucht eine Solaris Variante.

Meine SMB Fileserver sind alle OmniOS. Mein Mailserver ist Windows (wegen AD) und da setze ich iSCSI auf ZFS darunter (wegen Ramcache, Replikation, Datensicherheit und schnellem syncronen Schreiben) - aber nicht mit SMB.

 

[you]

Ich habe ein All-In-One, welches einen SSD-ZFS-Pool (2x2 mirror) per NFS an ESXI weiter gibt. Darauf sind alle non-NAS-VMs untergebracht.

Angebunden wird ESXI an das NFS über einen eigenen vSwitch, eigener IP-Adressbereich, vmxnet, MTU9000 (sowohl im vSwitch als auch im napp-it für die NIC)

Wenn ich nun testweise ein ISO-File von einem lokalen Datastore (SSD, SATAIII) auf den NFS-SSD-ZFS-Pool kopiere, dann komme ich auf Übertragungsraten von um die 100 Megabyte/Sekunde. Dies scheint mir vor dem Hintergrund der Möglichkeiten von SATAIII und der rein softwaremäßigen Kommunikation über den vSwitch von ESXI doch gering?

 

[snipor]

Das heißt dass ZFS bisher eher selten zum Einsatz kommt wenn eine Rechteverwaltung über Windows AD in einer Firma umgesetzt ist? Daher sind wohl die Hardware Raid Lösungen dort immer noch so weit verbreitet?

 

[gea]

Ich würde eher sagen, dass eine Firma die Windows einsetzt eher weniger auch noch Unix/Linux nutzt während eine Firma die Unix/ Linux einsetzt eher seltener Windows Server einsetzt zumal SAMBA einen AD Server ersetzen kann und Solarish ACL-rechtemäßig einen Windows Fileserver im AD Betrieb ersetzen kann.

Hardware-Raid ist eigentlich Schnee von gestern, sowohl was Performance wie was Sicherheit angeht (Write Hole Problem). Unter Windows mit ntfs (ohne Storage Spaces) wird es mangels brauchbarem Software-Raid aber noch oft genommen.