[Sammelthread] ZFS Stammtisch

[CommanderBond]

Ich hab nun den Unifi Controller in einem LX Container (Debian) am laufen unter OmniOS+Nappit. Einrichtung war insgesamt völlig problemlos man musste nur in der zone.cfg die IP ändern. Als nächstes mal Plex versuchen.

 

[zapopost]

Bin gerade dabei mich in napp-it und ZFS einzuarbeiten und verwende dazu gerne den Midnight Commander mc. Leider hängt er sich in napp-it ständig auf und ich muss den Prozess killen und von vorne anfangen. Passiert immer beim wechseln in leere Verzeichnisse.

Irgendeine Idee?

 

[gea]

welches OS und aus welchem Repo ist mc?

Unter OmniOS hatte ich auch schon Probleme mit dem mc aus dem Repo der Uni Maryland. Das ist nicht ganz aktuell. Als schnelles Workaround kopierte ich aktuelle binaries von mc aus OI nach OmniOS. Vielleicht hilft das.

http://www.napp-it.org/doc/downloads/mc.zip
Einfach Inhalt mit WinSCP nach / kopieren.

 

[CommanderBond]

Was ist eigentlich die "best practise" für lx branded zones? Pro Anwendung eine eigene Zone? Oder hat es irgendwelche Vorteile mehrere in eine zu packen?

Also wenn man jeweils ne eigene macht für plex, unifi, pyload, wäre das klever oder aus irgendeinem Grund nicht?

 

[zapopost]

welches OS und aus welchem Repo ist mc?

Ist napp-it ToGo VM unter OmniOS, was halt dabei ist.

Das binary funktioniert, Danke!
Musste aber noch die Rechte von mc setzen.

Wenn das der schnelle Workaround ist, wie wäre denn der bessere Weg?

 

[gea]

Da mc im Repo vom OmniOS nicht enthalten ist, hat zwei Optionen
- selber kompilieren
- ein anderes Repo nutzen (z.B. pkgin von Joyent/SmartOS)

War mir wegen eines einfachen Utilitiy das problemlos nach einem Copy läuft aber auch zu aufwändig.

- - - Updated - - -

Was ist eigentlich die "best practise" für lx branded zones? Pro Anwendung eine eigene Zone? Oder hat es irgendwelche Vorteile mehrere in eine zu packen?

Also wenn man jeweils ne eigene macht für plex, unifi, pyload, wäre das klever oder aus irgendeinem Grund nicht?

Komplexe Sachen die schwierig aufzusetzen sind packt man am Besten in getrennte Linux Zonen. Kleinere unkomplizierte Anwendungen kann man auch in einer Linux Zone zusammenfassen.

 

[CommanderBond]

okay ich denke ich werde es aber erstmal mit getrennten Zonen versuchen.

Der Solaris NFS Server ist innerhalb der Zone nicht verfügbar wie ich das verstehe, aber ein NFS share mounten, also als client sollte klappen denke ich oder?

 

[gea]

Viel einfacher
LX Zonen haben direkten Zugriff auf die ZFS OmniOS/SmartOS Dateisysteme als mountpoint in der Linux Zone.

 

[CommanderBond]

Ja das weiß ich, aber das Share ist auf einer anderen Maschine im Netzwerk

P.S.: Aber wegen den Mountpoints: Eine Begrenzung der Anzahl gibt es da nicht? Also man kann auch beispielsweise 5 ZFS Dateisysteme einbinden?

 

[gea]

Dann halt per iSCSI, NFS oder SMB

 

[zapopost]

Kann ich in napp-it die autosnap jobs auch nicht rekursiv ausführen lassen?

 

[gea]

Kann ich in napp-it die autosnap jobs auch nicht rekursiv ausführen lassen?

Autosnap arbeitet derzeit immer recursiv ab dem eingestellten Dateisystem.

Man könnte mehrere Jobs auf untergeordnete Dateisysteme erstellen.
Dann hätte das Eltern-Dateisystem aber keine Snaps.


Update:
Ich habe die Jobfunktion in der 17.07 dev/ 16.11. überarbeitet.
Man kann da recursive ausschalten siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux Changelog

Wird in der nächsten napp-it drin sein.

 

[zapopost]

Wenn ich das richtig sehe, kann ich die 17.07 dev als free User nicht nutzen, oder? (Für mich ist napp-it relativ neu)
Wann kann man ungefähr mit der neuen Version rechnen?

Hintergrund: Ich baue grade einiges um, von Linux ext4 auf napp-it zfs und könnte meine Dateisystem-Hierarchie nochmal anpassen, aber eigentlich gefällt es mir so.
Nur habe ich in einigen Dateisystemen weitere Unter-Dateisysteme für die Snapshots keinen Sinn machen.

Wenn es nicht mehr allzu lange für ein neues Release hin ist, würde ich die autosnap jobs so laufen lassen und die Snapshots der Unter-Dateisysteme per Script wieder löschen. Das sollte doch funktionieren, oder?

 

[gea]

In der Regel versuche ich die Basis / Free Version alle 6 Monate zu aktualisieren.
Die nächste Free wird also 2018.01

Wer aber die aktuelle dev Software testen mag (LUXX und servethehome Benutzern gebe ich da gerne Extra Support):

complete luxx - 17.11-2017::mVqmVqsmVlTTVPqVVwsmVPqsmVPTTDhsm
Die obige Zeile bei Extension > Register eingeben dann kann man auf die dev updaten - Ich hab ja auch was davon.

 

[besterino]

Nur ein Tipp von mir: als ich damals von Linux/ext4 mit seinen Ordnerstrukturen zu Solarish/ZFS gewechselt bin, habe ich am Ende vor dem Hintergrund unterschiedlicher Snap- und Replikationmodelle dann doch meine Ordnerstrukturen zum Teil aufgelöst und deutlich mehr Datasets im „Hauptverzeichnis“ des Pools angelegt als vorher. Nachteil bei im Netzwerk freigegebenen Datasets: die sind halt alle eine eigene „SMB/CIFS“ Freigabe, was u.U. das Einbinden auf Clientseite etwas nerviger macht. Diese Nachteile werden aber auf der anderen Seite für mich mehr als wett gemacht, wenn man nicht mit den Komplikationen bei rekursiven snaps & co. hantieren muss.

 

[zapopost]

Wer aber die aktuelle dev Software testen mag (LUXX und servethehome Benutzern gebe ich da gerne Extra Support):

Die dev funktioniert bisher super, vielen Dank!

Nur ein Tipp von mir: als ich damals von Linux/ext4 mit seinen Ordnerstrukturen zu Solarish/ZFS gewechselt bin, habe ich am Ende vor dem Hintergrund unterschiedlicher Snap- und Replikationmodelle dann doch meine Ordnerstrukturen zum Teil aufgelöst und deutlich mehr Datasets im „Hauptverzeichnis“ des Pools angelegt als vorher.

Ja, so habe ich es im Moment auch vor, versuche halt einen Mittelweg zu finden damit die Nachteile nicht überwiegen.
Dafür ist der Umzug ganz schön nervig, da ich die meisten Ordner/Datasets einzeln per NFS/Rsync umziehen muss.

 

[gea]

Ja, so habe ich es im Moment auch vor, versuche halt einen Mittelweg zu finden damit die Nachteile nicht überwiegen.
Dafür ist der Umzug ganz schön nervig, da ich die meisten Ordner/Datasets einzeln per NFS/Rsync umziehen muss.

Etwas langsamer dafür viel komfortabler und eventuelle Windows Rechte bleiben erhalten: Kopieren zwischen zwei NAS Systemen via Windows. Ansonsten interessiert sich rsync nicht für ZFS Dateisysteme. Damit kann man einen Verzeichnisbaum direkt von ext4 nach ZFS umziehen (Rechte gehen aber verloren). NFS oder SMB ist da unterschiedlich da das bei Solaris in den Kernel und in ZFS (Eigenschaft eines ZFS Dateisystems) integriert ist.

 

[Trambahner]

Ich hab bei mir (BSD) z.B. mehrere "Media"-Datasets und den Pfad drüber als SMB-Share freigegeben:
z.B. als Datasets:
/mnt/hddpool/Media
/mnt/hddpool/Media/Video
/mnt/hddpool/Media/Musik
/mnt/hddpool/Media/Bilder
/mnt/hddpool/Media/WWW

und als SMB-Share eingetragen ist /mnt/hddpool/Media/ im Samba.

Somit hab ich auf dem Windows-Client das Media-Gerümpel unter einem Netzlaufwerk gemapped und auf dem Server doch eigene Datasets drunter, die getrennt Eigenschaften haben können und z.B. getrennt gebackuped und gesnapped werden. Auf dem Windows schaut es dann aus wie mehrere Ordner in einem Laufwerk.

 

[Stangensellerie]

Bin seit längerer Zeit im Ausland und hab meinen Server angeschalte zu Hause gelassen (haengt an einer USV, Uptime 140 Tage). Ich hab ihn in letzter Zeit kaum verwendet, heute habe ich mich mal in die napp it Console eingeloggt weil auf einmal verschiedene VMs nicht mehr zur Verfügung waren. Und was sehe ich da. Ich hab 3 SSDs verloren... Ich verwende (besser gesagt ich verwendete) 2x 120GB SSD Mirror Pools (mit Sandisk SSD Plus SSDs).

Wo kann man einsehen, warum die SSDs nicht mehr zur Verfuegung stehen. Ich kann mir kaum vorstellen, dass alle 3 defekt sind... Ich hatte kaum Schreibleistung auf den SSDs

Siehe Anhang

Doch die können ausfallen. Die "Sandisk SSD Plus" ist sehr temperatursensitiv und kann sich bei Zweckentfremdung, sprich Dauerbetrieb, doch unerwartet stark erwärmen. Mein ESXi-Log listete viele Einträge sowohl irgendwas mit "Performance verringert/wiederhergestellt" als auch Temperatureinträge zur SSD. Die erwärmt sich im Laufe der Zeit immer weiter und ihr Plastikgehäuse wirkt eher wie ein Backofen. Keine Ahnung ob der ESXi die SSD überhaupt in einen Idle-Mode geschickt hat, zumindest hat er die SSD als SSD erkannt...


Meine Anfrage in Post [Sammelthread] ZFS Stammtisch - Seite 321 ist hinfällig, weil die Sandisk SSD Plus jetzt Schrott ist. Neben nappit-AiO hatte die SSD nur noch den ESXi-Scratchfile, diverse ESXi-Logs und die USV-VM zu verarbeiten. Ich hab inzwischen erneut die AiO-Appliance allerdings nun in Version 024 ausgerollt und beim NIC-Einrichten wieder mal die mir bekannten Syntax-Probleme gehabt. Die Empfehlung mit dem OVF-Export zur schnellen Appliance-Sicherung ließ sich auch nicht umsetzen, weil ich meinen LSI-Controller per Passthrough reingereicht habe und der Export daher mit einer entsprechenden Fehlermeldung abbricht.

Beim Ausrollen der AiO-Appliance ist mir zudem die erneut grössere vDISK aufgefallen. Ich meine mich zu entsinnen, daß N-2-Go und N-AiO mal mit demselben, deutlich kleineren Footprint daherkamen und das trotzdem sehr viel Luft enthalten war. Mich stört dabei eher weniger der Platz ansich, sondern das sich jetzt beim Backup volle 40GB durch mein GE-Netzwerk quälen müssen, wo doch die vDISK selbst bei 16GB nicht mal zu 40% belegt wäre.

 

[gea]

Tja, die aktuelle Generation von 500 Euro Mainboards unterstützt bis 1TB DRAM. Nächstes Jahr kommt Optane als Arbeitsspeicher. Die RAM Bestückung wird daher deutlich zunehmen. Wenn man der Empfehlung von Oracle folgt, so sollte man ca 1/4 RAM als Swap und bei Bedarf das gleiche für Dump rechnen. Beide liegen auf der Systemplatte. Die aktuelle Größe der StorageVM ist daher ausgelegt auf mehr als 64 GB RAM für die Storage VM - soviel wie man auch für ein aktuelles professionelles Barebone Storage rechnen würde. Die bisherige VM hatte 10GB weniger und war für weniger RAM ausgelegt. OmniOS braucht aktuell ca 20GB. Wenn man bei Updates die Vorversion als Bootenvironment halten möchte entsprechend mehr. Die jetzigen 40GB sehe ich daher als vernünftig an.

Fürs Backup nimmt man am Besten ZFS Replikation. Das behält thin provisioning bei und hat selbst bei PetaByte kein Problem die Dateisysteme übers Netz in Sync zu halten - selbst unter Hochlast.

Die Storage VM selber muss man nicht sichern. Bei Problemen neu bereitstellen, Pass-through aktivieren, ZFS Pool importieren und schon kommt ESXi wieder per NFS ans seine VMs - Komplexität gleich Null und Zeitaufwand ca 5-10 Min. Zusätzliche womöglich komplexe Dienste auf die Strage VM zu packen ist eh nicht empfehlenswert. Dafür gibts ja dann ESXi und ZFS. Selbst bei einem Totalabsturz der Bootplatte inkl ESXi kommt lediglich das Importieren der VMs per ESXi Dateibrowser und Maus-Rechtsklick auf die .vmx Datei dazu.

Planning for Swap Space - System Administration Guide: Devices and File Systems

 

[Stangensellerie]

Die Oracle-Empfehlung war mir nicht bekannt und von daher bin ich froh, daß es nur 40GB sind.

Mit ZFS-Replication muß ich mich wohl mal eingehender beschäftigen. Allerdings habe ich nur die Appliance am Laufen und somit kein wirkliches ZFS-Ziel. Problematisch dürfte sicherlich auch werden, daß ich die Free-Version einsetze. Pläne, das zu ändern, gibt es bereits, wird aber noch etwas Überzeugungsarbeit mit der Cheffin erfordern.

Mit der Appliance neu bereitstellen ist es bei mir nicht getan, weil es bei mir keinen DHCP-Server gibt und wenn man nicht täglich mit Solarish zu tun hat, ist die Umstellung von der Komplexität leider grösser Null. Auf der Appliance laufen auch keine weiteren Dienste. Die hat bei mir nix weiter zu tun, als dem ESXi sein Storage bereit zu stellen. Alle anderen Dienste liefen bereits auch vorher schon in separaten VMs und das wird auch so bleiben. Mal von der Netzwerk-Geschichte abgesehen, habe ich wirklich keine 5min gebraucht, damit der ESXi wieder an seine VMs gekommen ist und alles lief. Da konnte ich mir echt ein Grinsen nicht verkneifen.

 

[besterino]

Wenn Du die Ausfallsicherheit wegen eines Festplattendefekts erhöhen willst, kannst Du den rpool auch mit einem Software-RAID über 2 VMDKs auf 2 verschiedenen Datenträgern verteilen. Lässt sich prima auch nachträglich einrichten, habe ich für Solaris 11.3 so gemacht und hier auch irgendwo mal beschrieben - bootet dann egal von welcher VMDK. Hilft natürlich nicht gegen eigenes Verfummeln der VM, ESXi-Fehler, Viren o.ä.

Auch musst Du die ESXi-Settings der storage-VM manuell noch woanders hinlegen, die liegen ja nicht auf dem rpool.

Nachteil: du brauchst halt einen weiteren Datenträger als VM-Storage.

Noch entspannter wäre nur noch ein Hardware-RAID für ESX+StorageVMi. Das ist aber schon ein wenig Overkill für eine VM, die sich noch dazu ja recht flott wieder aufsetzen lässt.

 

[CommanderBond]

Mal eine Frage zum Rechtemanagement bei den Zones. Ich habe ein ZFS Dataset "shares" auf das alle Zone drauf zugreifen können. Jetzt möchte ich aber auch Dinge abspeichern können die von den anderen Zones nicht gesehen werden können. Wie mache ich das? Die Zones haben ja keinen wirklichen "user". Oder geht das nur über getrennte Ordner die man einbindet? Oder gibt es andere Lösungen?

 

[gea]

Die Zonen erhalten die ZFS Dateisysteme als einfache Mountpoints. Da ist nichts mit Authorisierung/Rechte, es gibt ja auch keine Authentifizierung. Also entweder getrennte Ordner oder Zugriff über SMB/NFS4.

 

[gea]

ZFS ist absturzsicher!.
Das bedeutet dass ein plötzlicher Stromausfall ein CopyOnWrite Dateisystem wie ZFS nicht beschädigt. ZFS nutzt aber einen Schreibcache (Voreinstellung 4GB RAM - wenn man ausreichend RAM hat) und der bewirkt dass eine Datenbank oder eine VM korrupt ist wenn plötzlich das System abstürzt (Man denke an ein Buchhaltungssystem das einen Betrag von einem Konto abbucht - aber abstürzt bevor der Betrag auf einem anderen Konto gutgeschreiben ist. Das Geld ist im Datennirwana).

Um das zu verhindern bietet ZFS Sync-Write bei dem jede bestätigte Schreibaktion protokolliert wird. Stürzt das System ab (Stromausfall etc) so wird das beim nöchsten Boot nachgeholt. Leider geht Sync Write massiv auf die Performance. Bei Sync-Schreiben kann es passieren, dass die Performance um 90% einbricht (mit langsamen Platten).

ZFS bieten dafür Slog, eine schnelle Extra-Platte für diese Protokollierung. Ein gutes Slog Laufware war bis vor kurzem sehr teuer (wegen geforderter Powerloss Protection und Low-Latency) und trotzden nicht so schnell wie ein Schreiben ohne diese Extra Sicherheit. Die neue Intel X-Point Technologie, z.B. mit einer Intel 900P NVMe ist da ein Quantensprung. Die NVMe gibts es zwischenzeitlich unter 400 Euro und die ermöglicht selbst sequentielle sync Schreibraten nahe den Werten die ohne Sync Write möglich sind. Darüberhinaus ermöglicht die neue SSD Technologie ganz neue ZFS Storage-Geschwindigkeiten.

siehe dazu eine Testreihe die ich gerade bearbeite:Ich bin beeindruckt!
http://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

 

[besterino]

Na, vielleicht finde ich ja hier einen Sinn für die Optane m.2 - selbst wenn nur 32GB, aber für Slog brauchte man doch ohnehin gar nicht so Monster-Datenmengen, oder?

 

[Luckysh0t]

A disk based pool always need a good Slog for fast random sync ans sequential writes. Only the 900P improves also sequential writes to a similar value as unsync writes so sync=always is always a suggested setting there - even for a filer.

Aus Geas PDF - Sinn gefunden ^.^.Jetzt ist nur die Frage ob die 32 GB Optane auch schnell genug wäre. Mir ist zwar klar, dass eine SSD schneller als eine HDD ist, aber bei einem Slog sollte diese ja deutlich schneller sein.
In meinem Fall würde ich die dann wohl bei meinem ZFS mirror von zwei 10 TB ST10000NM0206 einsetzen - sobald es mit dem Server mal losgeht.

 

[morph027]

Intel Optane Memory m.2 16GB and 32GB: They work in servers and as ZFS cache devices

We do not recommend using these drives in production servers. You are better off buying more RAM or a larger NVMe SSD. Furthermore, the Intel DC P4800X is a much better product and much faster. However, if you wanted to spend under $100 and try Optane in a server, they will work.

 

[gea]

Die kleinen Cache Optane bringen es gar nicht.

Möchte man die für L2ARC wegen read ahead caching so sind sie eigentlich zu klein.
Für Slog wären 16GB vollkommen ausreichend. Allerdings ist der Sinn von sync write ja der Schutz der Daten im rambasierten Schreibcache vor Stromausfall. Da ist powerloss protection Pflicht was erst die 900P und die 4800x haben. Ansonsten würde man den Server durch Aktivieren von sync langsamer machen ohne dafür einen Schutz vor Datenkorruption zu haben.

Bisher war es ja so
Sync aktiviert man für transaktionssichers Schreiben (Datenbanken und VMs) und akzeptiert notgedrungen geringe randon und sequentielle Schreibraten.

Bei einem reinen Fileserver ist der Sicherheitsgewinn mit sync viel geringer, daher schaltete man das immer aus.

Sehr schnelle SSD Pools oder langsamere Pools mit Optane als Slog sind allerdings im Sync-Modus so schnell dass man sich sync generell überlegen kann. Optane oder NVMe allgemein ändert da das Denken über Storagekonzeption völlig.

 

[gea]

Aufgrund meiner aktuellen Benchmarks mit All-In-One und Optane als Datastore unter ESXi

Disk Pool 8k sync/unsync /s random sync/unsync/s seq sync/unsync/s dd sync /unsync /s
no slog 520K / 1.9M 1.6M / 65.8M 41,8M/ 1024M 283M/ 939M
Optane Slog 1.6M / 1.9M 39.4M/ 68.4M 512M / 1023M 849M/961M

SSD Pool 8k sync/unsync /s random sync/unsync/s sequ sync /unsync /s dd sync/unsync/s
no slog 1.5M/ 1.9M 16M / 50.2M 341M/ 1023M 423M/ 806M
Optane Slog 1.6M / 1.9M 38.2M/50.2M 512M/ 1023M 731M/ 806M


werde ich meine künftigen AiO wohl so bauen:

- ESXi auf einem USB Bootsstick (dis Booten von Optane geht)
- ein lokaler Datastore auf einer Optane 900P
- ein LSI Controller oder Sata für Datenplatten/ Daten-SSD (pass-through)

- eine 20G virtuelle Platte als Slog (das ist neu, hätte ich vorher nicht gemacht)
- eine weitere virtuelle Platte als L2Arc (5-10x RAM) als Cache mit aktiviertem Read-Ahead

Für die Optane sollte der gleichzeitige Lese-Schreibzugriff von OS, Slog und L2Arc unkritisch sein.
Performancemäßig ist das jenseits von gut und böse (sync Schreibwerte 700-800 MB/s aus 4 Platten, das gabs bisher einfach nicht).

Da es keinen Controller oder Disk Cache gibt, sehe ich auch keine Sicherheitsproblem mit Sync Write
über eine virtuelle Platte.

ps
Ich habe die Benchmarks um die AiO Werte ergänzt
http://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

- - - Updated - - -

Wär ja auch zu schön gewesen.

Die Optane 900P lag letzte Woche bei 600 Euro, aktuell ist sie bei 380 Euro,

Jetzt wird klar warum. Die Optane 900 P wird nicht mehr mit Powerloss Protection gelistet.
Intel Product Specification Advanced Search

so die einzige Optane mit powerloss protection ist im Moment die 4800X-375 für 1500 Euro