[Sammelthread] ZFS Stammtisch

[zos]

Eine Frage zum Thema Performance bzgl. MySQL im Zusammenhang mit ZIL mit/ohne SLOG:

Im Unterkapitel "MySQL" Bereich "Workload Tuning" auf der OpenZFS-Website heisst es zum Design der unterliegenden ZFS-Filesystems für eine MySQL-DB:

"Set logbias=throughput on the data to stop ZIL from writing twice."

Das kann doch nur gelten, sofern der zpool kein separates SLOG beinhaltet, oder? Nach meinem bisherigen Verständnis ist ein ZIL ja immer vorhanden, wird aber durch ein separates SLOG auf dieses verlagert*. D. h. sofern ein zpool aus HDDs zzgl. einer Optane als SLOG besteht, wäre es keine so gute Idee "logbias=throughput" zu setzen. Es würde doch nur dann Sinn machen, wenn in diesem Fall das Optane SLOG nicht vorhanden wäre, oder?

*EDIT: Um es präziser zu formulieren: Als RAM-Cache-Absicherung bei sync=always

 

[gea]

Ih weiß jetzt nicht was mit "stop ZIL from writing twice" meint. Logbios=throughput nutzt auf jeden Fall den Pool fürs Logging und nicht das Slog

Oracle schrieb mal dazu: Using the logbias=throughput value might improve performance for writing database files.

https://docs.oracle.com/cd/E19253-01/819-5461/givdo/index.html

Ich glaube aber nicht (Versuch macht klug) dass man aktuell im Vergleich zu einer Optane Slog was gewinnt.

 

[zos]

Ih weiß jetzt nicht was mit "stop ZIL from writing twice" meint. Logbios=throughput nutzt auf jeden Fall den Pool fürs Logging und nicht das Slog

Oracle schrieb mal dazu: Using the logbias=throughput value might improve performance for writing database files.

https://docs.oracle.com/cd/E19253-01/819-5461/givdo/index.html

Ich glaube aber nicht (Versuch macht klug) dass man aktuell im Vergleich zu einer Optane Slog was gewinnt.

Das ("stop ZIL from writing twice") ist vermutlich unglücklich formuliert. Gemeint ist wohl zu verhindern, dass die Daten ins ZIL und auf den endgültigen Speicherort geschrieben werden.

Das Ganze scheint jedenfalls vor einiger Zeit mal ein heißes Eisen gewesen zu sein (und war in einem Use-Case verhinderbar sehr inperformant, wurde aber inzwischen behoben), wenn man diese Diskussion mal verfolgt. Dort werden an einer Stelle auch die Begrifflichkeiten mal ganz gut erklärt. ZFS nutzt den Pool demnach zum Logging bei "logbias=throughput" wohl nur noch um dort Pointer auf die Daten abzulegen, aber nicht mehr die Daten selbst (die werden direkt an ihren endgültigen Speicherort geschrieben) und die Latenz ist dabei wurscht, es geht dafür aber nur die Hälfte der Daten (werden ja nicht mehr doppelt geschrieben) zzgl. Pointer über den Draht, wenn ic hdas alles richtig verstanden habe.

Jetzt weiß ich nicht, wie alt der Block zu MySQL auf openzfs.org jetzt ist, aber mit einer Optane als SLOG, "logbias="latency" und "sync=always" als ZFS File-Properties wird man sich wohl nicht unbedingt spürbare Performancenachteile ins Haus holen. Das ganze ist letztendlich auch erst für eher hohes IO-Aufkommen wirklich relevant.

 

[gea]

So wie ich das sehe ist der Ansatz folgender (sync=always)

1. Normalerweise landen alle Writes egal ob klein oder groß im Ramcache
und werden regelmäßig als großes sequentielles Write geschrieben.
Eine einzelne Platte kann dann z.B. 200 MB/s (großer Datenblock).
Bei kleinen Datenblöcken z.B. 4-8KB fällt die Performance aber vielleicht auf 5 MB/s.

Das direkte Schreiben auf Platte kleiner Blöcke ist daher unbedingt zu vermeiden, daher der Ram-Schreibcache -
und daher auch die Notwendigkeit den über ein Slog abzusichern.

2. Jeder einzelne Schreibvorgang der bestätigt ist (Commit) liegt zusätzlich im Slog als Sicherung gegen Crash.
Dies erfolgt zusätzlich zu 1. Jedes Byte wird also effektiv 2mal geschrieben.
Bei kleinen Datenblöcken ist das Slog sehr viel schneller als die Platte, bei großen eventuell nicht so sehr.

In jedem Fall ist dieses Verfahren das schnellste wenn man sync write und kleine Datenblöcke betrachtet-
auch wenn jedes Byte zweimal zu schreiben ist sowie bei mixed load.

3. Schreibt man aber ausschließlich große Blöcke so könnte man die auch direkt auf Platte und nicht den Ramcache schreiben.
Bei großen Blöcken ist die Platte ja schnell genug - dann auch nicht ins ZIL/Slog. Der Commit kommt erst wenn Daten tatsächlich auf Platte sind. Die schreibende Anwendung muss also eventuell länger warten als wenn man ins RAM und Slog schreiben würde. Insgesamt könnte das bei großen Daten aber effektiver sein - bei kleinen eine Katastrophe.

Das ist was hier angedacht wird.

Normalerwesie hat man aber mixed Load und mit einem Slog in der Güteklasse einer Intel Optane verliert man selbst dann kaum etwas wenn man ausschließlich große Datenpackete hätte. Man muss sich schon den Workload sehr genau betrachten bei dem das überhaupt eine positive Rolle spielen könnte.

Was bei Datenbanken und eventuell VMs eine große Rolle spielt ist vermutlich recsize (dann z.B. 32k statt 128k-1M)


Diskussionen in der Richtung habe ich bei Solaris bisher nicht gesehen, nur bei ZoL.
Das war in den Anfängen aber auch deutlich langsamer bei sync write als Solaris.

 

[CommanderBond]

Habe nochmal paar Fragen und hoffe man kann mir weiterhelfen:

Wie ist das mit TrueNAS wenn man einen bestehenden Pool importiert den man einst mit OmniOS erstellt hat, kann dieser importiert werden, und was gibt es zu beachten? Habe mal gelesen dass TrueNAS, bzw der Vorgänger FreeNAS wohl die Datenträger partioniert, was wohl für OmniOS dann schwierigkeiten machen soll.
Kann man also sagen wenn man die Pools mit OmniOS erstellt, bekommt man hier keine Probleme in TrueNAS oder auch Linux mit ZFS?

OmniOS speichert die Ordner Berechtigungen ja direkt im ZFS Dateisystem, was TrueNAS soweit ich verstehe nicht kann. Was passiert mit diesen Berechtigungen eigentlich wenn man TrueNAS benutzt, den Pool benutzt, und irgendwann wieder zurück geht auf OmniOS. Sind diese Daten dann noch "intakt"? Oder muss man dann was nachpflegen?

Was ist von Proxmox zu halten mit einer OmniOS VM mit durchgereichtem Sata Controller? Meine Idee wäre: Proxmox, kann ja auch ZFS, würde ich dann also für die VMs benutzen, aber eine OmniOS VM für Daten die im Netzwerk verfügbar sein sollen wegen dem besseren SMB Server.
Sprich Proxmox auf USB Stick oder NVMe. VMs auf NVMe, entweder einzelnt oder dieselbe von der auch Proxmox bootet. Und Sata Controller durchreichen für Omnios.
Der Ansatz mit dem nappit AIO und den VMs dann per NFS Freigabe gefällt mir nicht. Da ich ja ohnehin dann einen Datenträger brauch für die Storage VM selbst. Wieso nicht gleich dann alle VMs da drauf packen denn Proxmox kann ja ZFS im Gegensatz zu Esxi. Auch würde man sich den Hardware Raid Controller sparen falls man für die VMs doch mal nen Mirror haben will, da man diesen dann direkt in Proxmox mit ZFS erstellen kann. Was für mich auch noch gegen Esxi spricht ist dass es net open source ist. Proxmox scheinen sehr viele zu benutzen, nur benutzen die meisten wohl den Samba Server und haben keine extra Storage VM dann.
Ich gehe mal davon aus dass es einem ZFS Pool egal ist ob dieser bei durchgereichtem Controller an die Storage VM übergeben wird, oder Baremetall.

Und noch ne Frage: Sind Replications unabhängig davon was man für ein OS benutzt? Also kann man diese zwischen TrueNAS, OmniOS, Proxmox nutzen oder muss Ziel und Quell OS identisch sein?

Verstehe auch nicht ganz wie das mit dem eval Key bei Nappit nun genau funktioniert beim neuinstallieren. Man hat dann ja die "Pro" Version (30Tage soweit ich weiß). Wenn die 30Tage abgelaufen sind und man hat keinen Pro Key, fällt man ja auf die "free" Version zurück. Aber da gewisse Bugfixes ja nur in der Pro drin zu sein scheinen (verstehe ich so), werden die "Bugs" dann quasi wieder "eingefügt" (am 30. Tag) oder werden einfach nur die Pro Extensions deaktiviert und man hätte quasi ne Version auf dem Stand der Pro die man dann beim installieren bzw letzten Update während der eval Phase hat?

Habe gemerkt dass mir die Temperatur der Datenträger nicht mehr angezeigt wird. Kann mir aber nicht vorstellen dass das mit Nappit zusammen hängt. Habe nur das OS mitsamt NVMe von einen Microserver in einen anderen eingebaut, baugleich bis auf die CPU und Ram. Kann das damit zusammenhängen und sollte ich es dann nochmal neu installieren?

 

[gea]

Habe nochmal paar Fragen und hoffe man kann mir weiterhelfen:

Wie ist das mit TrueNAS wenn man einen bestehenden Pool importiert den man einst mit OmniOS erstellt hat, kann dieser importiert werden, und was gibt es zu beachten? Habe mal gelesen dass TrueNAS, bzw der Vorgänger FreeNAS wohl die Datenträger partioniert, was wohl für OmniOS dann schwierigkeiten machen soll.
Kann man also sagen wenn man die Pools mit OmniOS erstellt, bekommt man hier keine Probleme in TrueNAS oder auch Linux mit ZFS?

Da Free-BSD featuremäßig jetzt wieder weitgehend identisch zu Illumos und ZoL ist, sollte man eine gute Chance haben dass ein Pool move (export + import) klappt.

OmniOS speichert die Ordner Berechtigungen ja direkt im ZFS Dateisystem, was TrueNAS soweit ich verstehe nicht kann. Was passiert mit diesen Berechtigungen eigentlich wenn man TrueNAS benutzt, den Pool benutzt, und irgendwann wieder zurück geht auf OmniOS. Sind diese Daten dann noch "intakt"? Oder muss man dann was nachpflegen?

ZFS ist ein Unix Dateisystem bei dem die Rechte zunächst auf UID und GID abgebildet werden. Das ist auf allen Plattformen gleich. Der Solarish SMB Server speichert zusätzlich die Windows SID (z.B. der Domäne) und nfs4 ACL. Auch kann nur Solarish SMB Gruppen (Gruppen in Gruppen, Unix Gruppenverwaltung kann das nicht). Diese ACL die über einfache Linux/Unix Permissions hinausgehen, gehen verloren.

Wenn man aber nicht gerade eine Domäne nutzt, muss man aber eh meist alle Rechte zurücksetzen und wie gewünscht neu setzen. Das hat man auch wenn man unter Windows eine Platte woanders ansteckt.

Was ist von Proxmox zu halten mit einer OmniOS VM mit durchgereichtem Sata Controller? Meine Idee wäre: Proxmox, kann ja auch ZFS, würde ich dann also für die VMs benutzen, aber eine OmniOS VM für Daten die im Netzwerk verfügbar sein sollen wegen dem besseren SMB Server.
Sprich Proxmox auf USB Stick oder NVMe. VMs auf NVMe, entweder einzelnt oder dieselbe von der auch Proxmox bootet. Und Sata Controller durchreichen für Omnios.

Kommt darauf an, wie gut und performant man Unix virtualisieren kann. Ich würde es auf Proxmox wie auf SmartOS sehen, nehmen was da ist und den Rest per CLI lernen.

Der Ansatz mit dem nappit AIO und den VMs dann per NFS Freigabe gefällt mir nicht. Da ich ja ohnehin dann einen Datenträger brauch für die Storage VM selbst. Wieso nicht gleich dann alle VMs da drauf packen denn Proxmox kann ja ZFS im Gegensatz zu Esxi.

Es geht nicht nur um das Dateisystem. Unabhängigkeit der Funktionen VM und Storage, Wiederherstellungszeit von VMs, Unterstützung von Betriebssystemen, wie kompakt ist der Virtualisierer sind weitere Aspekte.

Auch würde man sich den Hardware Raid Controller sparen falls man für die VMs doch mal nen Mirror haben will, da man diesen dann direkt in Proxmox mit ZFS erstellen kann. Was für mich auch noch gegen Esxi spricht ist dass es net open source ist. Proxmox scheinen sehr viele zu benutzen, nur benutzen die meisten wohl den Samba Server und haben keine extra Storage VM dann.
Ich gehe mal davon aus dass es einem ZFS Pool egal ist ob dieser bei durchgereichtem Controller an die Storage VM übergeben wird, oder Baremetall.

Ja

Und noch ne Frage: Sind Replications unabhängig davon was man für ein OS benutzt? Also kann man diese zwischen TrueNAS, OmniOS, Proxmox nutzen oder muss Ziel und Quell OS identisch sein?

Prinzipiell bei aktuellen Systemen ja.

Verstehe auch nicht ganz wie das mit dem eval Key bei Nappit nun genau funktioniert beim neuinstallieren. Man hat dann ja die "Pro" Version (30Tage soweit ich weiß). Wenn die 30Tage abgelaufen sind und man hat keinen Pro Key, fällt man ja auf die "free" Version zurück. Aber da gewisse Bugfixes ja nur in der Pro drin zu sein scheinen (verstehe ich so), werden die "Bugs" dann quasi wieder "eingefügt" (am 30. Tag) oder werden einfach nur die Pro Extensions deaktiviert und man hätte quasi ne Version auf dem Stand der Pro die man dann beim installieren bzw letzten Update während der eval Phase hat?

Bei der Neuinstallation erhält man eine v18 free. Mit dem zusätzlichen evalkey kann man Pro Funktionen der v.18 nutzen oder bis auf v20 updaten. Läuft der Eval Key ab, muss man zurück auf die v18 free (auch kommerziell) oder v19 homeuse. Pro Funktionen (Cluster, Monitoring etc) laufen nicht mehr. Für einen Server at home sind aber v18 oder v19 ausreichend. Die Pro gibt Funktionen extra und Support.

Habe gemerkt dass mir die Temperatur der Datenträger nicht mehr angezeigt wird. Kann mir aber nicht vorstellen dass das mit Nappit zusammen hängt. Habe nur das OS mitsamt NVMe von einen Microserver in einen anderen eingebaut, baugleich bis auf die CPU und Ram. Kann das damit zusammenhängen und sollte ich es dann nochmal neu installieren?

Temperatur wird über smartmontools ausgelesen, geht ohne napp-it oder mit napp-it free.

 

[CommanderBond]

Was heißt denn man muss zurück?
Wenn ich während der Evaluation auf v20 bin wird danach dann automatisch downgegradet ohne dass ich was machen muss? Dass pro Features nicht mehr verfügbar sind weis ich ergibt auch Sinn, aber was ist mit kleineren bugfixes wie zb kosmetische Dinge oder fixes bei den autojobs was die Zeiten betrifft. Frage mich da ob das downgrade auch dazu führt dass dann ein Autojob nach den 30tagen plötzlich fehlerbehaftet läuft weil der entsprechende bugfix dann zum Ende der Evaluation Phase wieder entfernt wurde?

Beitrag automatisch zusammengeführt: 20.01.2021

ZFS ist ein Unix Dateisystem bei dem die Rechte zunächst auf UID und GID abgebildet werden. Das ist auf allen Plattformen gleich. Der Solarish SMB Server speichert zusätzlich die Windows SID (z.B. der Domäne) und nfs4 ACL. Auch kann nur Solarish SMB Gruppen (Gruppen in Gruppen, Unix Gruppenverwaltung kann das nicht). Diese ACL die über einfache Linux/Unix Permissions hinausgehen, gehen verloren.

Was heißt gehen verloren? Sind die nicht im Dataset gespeichert? Also überschreibt FreeBSD die dann einfach bei einem pool Import? Hatte eher gedacht die werden ignoriert beim Betrieb bleiben aber erhalten und können dann weitergenutzz werden wenn man den Pool wieder in ominos importiert?

 

[gea]

Kritische Bugs z.B. auch Unterstützung neuerer Betriebssysteme werden auch in die v18 free und v19 home rückportiert.
Neueste Bugfixes sind allerdings nur in der allerneuesten Pro/Dev Version.

Ein Pool Import überschreibt nichts. Wird allerdings eine Datei editiert (angelegt Solaris SMB, editiert SAMBA egal auf welcher Plattform/ auch mit Solarish SAMBA) so werden die speziellen Solaris SMB Features (Windows sid, nfs4 ACL, SMB Gruppen) vermutlich verlorengehen.

 

[AliManali]

Hi

Bin grad einen Cloud Server für Familienfotos und so was am aufsetzen. Der Server ist ein ESXi, auf dem hinter einem virtualisierten openVPN Server ein Xigmanas hängt. Vom Desktop aus kann ich per SMB und ftp zugreifen, von den VPN Clients nur per ftp (über Firewall geregelt). Klappt soweit ganz gut. D.h. ich kann im Moment am Desktop per root oder Benutzer auf das NAS zugreifen, und da wenigstens mal die rudimentären ftp Rechte setzten.

Nun kann aber sozusagen nur ich selbst als root die Rechte setzen, bzw muss die Files im Benutzerkontext hochladen. Die Benutzer können wohl Sachen hochladen, aber schön wäre halt, wenn die dann selbsständig auch für die anderen Nutzer die Sachen einzeln freigeben könnten. Ist da ftp und SMB das Mittel zur Wahl? Ich dachte erst, die laden was hoch, und ich kann (muss) dann per SMB in ein freigegebenes Verzeichnis verschieben, was bislang nicht klappt. Aber per ftp scheint mir bislang nicht mehr die ideale Lösung zu sein was ich so gesehen habe.

Gibt es da eine bessere Lösung für die Familienfotos? Oder bin ich da auf dem richtigen Pfad mit xigmanas und ftp? AD habe ich auch eingerichtet auf dem xigmanas, aber ich bin da schon seit 2k3 raus in dem Bereich. Mit einem NAS habe ich das noch gar nie getestet. Würde mich das weiter bringen?

 

[asche77]

S3/minio? Oder eine nextcloud o.ä. (da würde ich das VM Template von Hansson IT nehmen)

 

[VirtuGuy]

Hi

Bin grad einen Cloud Server für Familienfotos und so was am aufsetzen. Der Server ist ein ESXi, auf dem hinter einem virtualisierten openVPN Server ein Xigmanas hängt. Vom Desktop aus kann ich per SMB und ftp zugreifen, von den VPN Clients nur per ftp (über Firewall geregelt). Klappt soweit ganz gut. D.h. ich kann im Moment am Desktop per root oder Benutzer auf das NAS zugreifen, und da wenigstens mal die rudimentären ftp Rechte setzten.

Nun kann aber sozusagen nur ich selbst als root die Rechte setzen, bzw muss die Files im Benutzerkontext hochladen. Die Benutzer können wohl Sachen hochladen, aber schön wäre halt, wenn die dann selbsständig auch für die anderen Nutzer die Sachen einzeln freigeben könnten. Ist da ftp und SMB das Mittel zur Wahl? Ich dachte erst, die laden was hoch, und ich kann (muss) dann per SMB in ein freigegebenes Verzeichnis verschieben, was bislang nicht klappt. Aber per ftp scheint mir bislang nicht mehr die ideale Lösung zu sein was ich so gesehen habe.

Gibt es da eine bessere Lösung für die Familienfotos? Oder bin ich da auf dem richtigen Pfad mit xigmanas und ftp? AD habe ich auch eingerichtet auf dem xigmanas, aber ich bin da schon seit 2k3 raus in dem Bereich. Mit einem NAS habe ich das noch gar nie getestet. Würde mich das weiter bringen?

Mit smb/ftp/s3 ist sowas eher umständlich, dafür würde ich ganz klar auf Nextcloud o.ä. Lösungen setzen. Zum einen hast du dann eine passable Foto Integration, zum anderen kannst du etwaige Uploads gleich direkt per App erledigen.

 

[gea]

SMB ist im Internet ein NoGo. Darf man nicht machen. Selbst einfaches ftp ist da noch sicherer.
NextCloud ist die Komplettlösung vor allem wenn man noch Multiuser-Office, Kalender oder weitere integrierte Tools braucht. Ist dafür das absolute Überteil das einen kompletten Apache Webserver/PHP/SQL Stack bringt. Sowas will gut gepflegt sein.

S3 (Amazon simple storage) ist Performance und Einfachheit. Ein S3 kompatibler Server wie minIO ist nur eine Datei auf dem Server ohne irgendwelche Abhängigkeiten. Das muss man nicht virtualisieren sondern kann im einfachsten Fall einen Ordner auf dem NAS ins Internet freigeben. Einfach eine gemeinsame Cloud Ablage für die es viele sync tools gibt, auch fürs Handy z.B. https://play.google.com/store/apps/details?id=com.sme.s3 (nur als Beispiel, habe es nicht selbst im Einsatz)

S3 ist nicht umständlich, ist eher DAU sicher. Einschalten und tut. Nichts zu konfigurieren für einen Haupt-User und Zugriff per Browser oder Sync Tool. Konfigurierten müsste man allenfalls weitere User und deren Rechte.

MinIO z.B. ist für fast jede X Plattform verfügbar. Ich nutze es unter dem Solaris Fork OmniOS (wo ZFS herkommt). Da ist es direkt aus dem Repository installierbar, https://forums.servethehome.com/index.php?threads/amazon-s3-compatible-zfs-cloud-with-minio.27524/

 

[AliManali]

Hi

Supi, danke!

Ich habe gestern eine SSD an napp-it gehängt und nextcloud via NFS mit 2 VMDK (Debian System und Daten) installiert. Ich bin mir jetzt nicht sicher, ob das per NFS eine gute Idee war. Die Daten VMDK habe ich nach der Installation Ext4 formatiert, dort ein Verzeichnis angelegt und unter /Media/sdb1 gemountet. Anschliessend habe ich nextcloud installiert und das Datenverzeichnis angegeben.

Funktioniert soweit auch.

• brauche ich da das VPN überhaupt? Es handelt sich eh nur um eine sehr beschränkte Anzahl von Benutzer
• ist das überhaupt eine schlaue Idee, das per NFS zur Verfügung zu stellen? Oder ist das wumpe, wo die VMDK liegen?

Dann habe ich mit napp-it rumgebastelt. Statt der neuen SSD wollte ich da mein napp-it formatieren. Zum Glück wurde da ein Fehler ausgegeben und nicht formatiert. Bei den ZFS Filesystemen taucht die Bootdisk jetzt fälschlicherweise und mit falscher SMB Freigabe auf.

• Wie kriege ich das wieder weg?

Dann bei der WDGold1 habe ich bei perm 777 drin.

• macht das was aus, brauch ich da ACL?

Gruss

 

[AliManali]

hat nicht grad was mit ZFS zu tun, trotzdem noch zwei Fragen zu nextcloud:

• wie kann ich da eine weitere HDD an nextcloud anhängen? Die 350GB sind bisschen knapp
• was macht er nach dem Hochladen eigentlich noch (bearbeiten...). Nextcloud braucht doppelt so lange zum bearbeiten (?) wie zum hochladen?

 

[asche77]

Du kannst auch Netzwerkspeicher bei nextcloud einbinden (SMB share zB).

Bearbeiten: nicht sicher, aber nextcloud legt wohl jede gelöschte (und jede bearbeitete??) Datei in seinem lokalen Cache ab (nicht auf dem eingebundenen storage). Das kann dann die vorgesehene VM schnell sprengen.

 

[Gen8 Runner]

hat nicht grad was mit ZFS zu tun, trotzdem noch zwei Fragen zu nextcloud:

• wie kann ich da eine weitere HDD an nextcloud anhängen? Die 350GB sind bisschen knapp
• was macht er nach dem Hochladen eigentlich noch (bearbeiten...). Nextcloud braucht doppelt so lange zum bearbeiten (?) wie zum hochladen?

Increase NextCloud 13 VM Storage - Panda Tech LLC

NextCloud is one of the most popular ways for users to take control of their data again. Users can use NextCloud to manage their Contacts, Calendars, Files, etc. NextCloud 13 uses the ZFS file system to manage storage, and it is incredibly easy to increase NextCloud 13 storage compared to before.

www.pandatech.co

Dank ZFS sehr einfach.

 

[gea]

Hi

Supi, danke!

Ich habe gestern eine SSD an napp-it gehängt und nextcloud via NFS mit 2 VMDK (Debian System und Daten) installiert. Ich bin mir jetzt nicht sicher, ob das per NFS eine gute Idee war. Die Daten VMDK habe ich nach der Installation Ext4 formatiert, dort ein Verzeichnis angelegt und unter /Media/sdb1 gemountet. Anschliessend habe ich nextcloud installiert und das Datenverzeichnis angegeben.

Funktioniert soweit auch.

• brauche ich da das VPN überhaupt? Es handelt sich eh nur um eine sehr beschränkte Anzahl von Benutzer
• ist das überhaupt eine schlaue Idee, das per NFS zur Verfügung zu stellen? Oder ist das wumpe, wo die VMDK liegen?

Dann habe ich mit napp-it rumgebastelt. Statt der neuen SSD wollte ich da mein napp-it formatieren. Zum Glück wurde da ein Fehler ausgegeben und nicht formatiert. Bei den ZFS Filesystemen taucht die Bootdisk jetzt fälschlicherweise und mit falscher SMB Freigabe auf.

• Wie kriege ich das wieder weg?

Dann bei der WDGold1 habe ich bei perm 777 drin.

• macht das was aus, brauch ich da ACL?

Anhang anzeigen 579107

Gruss

VPN ist ein zusätzlicher Schutz für den Zugang ins lokale Netz aus dem bösen Internet. Hinter einem VPN Zugane ist sogar SMB problemlos möglich oder ein ungepflegtes älteres NextCloud mit diversen Apache oder php Bugs.

Napp-it blendet ZFS System-Dateisysteme auf rpool aus. Man sollte normalerweise rpool auch nicht für Daten nutzen. Es gibt aber Anwendungsfälle, wo man nur die Bootplatte für Daten hat. Wenn man dann ein Dateisystem auf rpool anlegt, so wird das angezeigt und man kann das per SMB freigeben. Will man rpool dann wieder nur fürs System nutzen, das Dateisystem löschen oder auf den Datenpool verschieben.

Ein Unix Dateisystem wie ZFS muss immer "traditionelle" Rechte wie 777 (Eigentümer, Gruppe und alle) unterstützen. ACL sind viel feingliedriger und haben viel mehr Möglichkeiten. Es ist aber kein entweder oder. Ausgehend von einer bestimmten Rechtesituation bewirkt ein Ändern der ACL oder der traditionellen Rechte immer eine Anpassung der Alternative auf eine Situation die beiden Varianten gerecht wird.

Eine Besonderheit gibt es aber beim Solaris SMB Server im Gegensatz zu SAMBA. Der in ZFS integrierte SMB Solarisserver benutzt ausschließlich nfs4 ACL (Windows ntfs artig). Da spielen Vererbungen eine große Rolle. Traditionelle Unix Rechte wie 777 kennen das Vererbungskonzept so nicht. Wenn man dann z.B. per chmod 755 traditionelle Rechte auf einen Ordner setzt, so ändern sich die ACL so dass damit nicht mehr möglich ist als es mit traditionellen Rechten möglich wäre. Die Rechtevererbung auf tieferliegende Ordner geht aber komplett verloren.

kurz gefasst
Wenn man ACL benutzt, darf man die nicht mit traditionellen Rechten überschreiben. Das gibt dann eventuell unerwünschte Effekte auf tieferliegende Dateistrukturen. Unter Solaris setzt man ausschließlich ACL wenn man Rechte setzt. 777 bedeutet da, dass Vollzugriff besteht und noch keine ACL (mit Vererbung) gesetzt wurden

.

 

[CommanderBond]

Ist da ftp und SMB das Mittel zur Wahl?

SMB ist nix für nicht Admins in meinen Augen. Die Rechtevergabe ist doch recht kompliziert für wen der sich gar nicht auskennt. Ich deaktiviere das gern entsprechend weil die Gefahr dass die Personen da irgendwie Chaos veranstalten höher ist als dass am Ende was sinnvolles dabei raus kommt. Also am besten vorher einfach einmalig alles so einrichten wies sein soll. Wollen sie dann Dinge freigeben dafür nen eigenen Ordner vorsehen wo sie die Sachen dann hinschieben bzw kopieren.

Oder eben wie schon angesprochen Dinge nutzen die genau dafür gedacht sind. Die ganzen Möglichkeiten mit SMB sind jedenfalls viel zu komplex für den Normalo. Der kennt maximal "ReadOnly" und "Lesen und Schreiben"

 

[gea]

Wichtiges OmniOS Security Update r36m, r34am, r30cm - Security / Features/ Bugfixes

"Support for secure RPC for the Netlogon protocol between OmniOS systems and Microsoft Active Directory servers is added to all OmniOS versions under support. This is required to fully mitigate CVE-2020-1472, and will shortly be enforced by Windows domain controllers."

Wer Windows Active Directory nutzt, sollte das auf jeden Fall in Betracht ziehen.

Release Notes

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support

omniosce.org

 

[Ceiber3]

So nach dem ich zu großen Leistungsverlust bei der CPU unter UnRaid hatte, habe ich jetzt doch wieder Nativ Windows 10 installiert. Da ich aber Bitrotschutz haben wollte, musste ich Alternativen für das Software Raid ausprobieren. Jetzt habe ich OpenZFS for Windows ausprobiert und bin wirklich sehr zufrieden mit der Performance. Vorher BTRFS ausprobiert, das läuft aber wirklich schlecht auf Windows und war doch recht Bugi.
Hoffe OpenZFS wird für Windows noch weiterentwickelt, gefällt mir bis jetzt echt gut. 👍

 

[CommanderBond]

Mal ne kurze frage zu Replications: Bekäme man es theoretisch mittels Script hin dass ein BackupNAS nur dann hochgefahren wird wenn es bei dem täglichen Replications Job auch Daten zum übertragen gibt? Also bei 0bytes einfach das ganze für den aktuellen Tag aussetzen würde?

 

[gea]

Das Script müßte einen Test-Snap anlegen und prüfen ob dieser und alle anderen (z.B. manuelle oder normale auto-snap) seit dem letzten Basissnap (mit der höchsten Replikationsnummer) used=0 haben. Dann wurde seitdem nichts geändert.

 

[v3nom]

Habe momentan 4x12TB als RaidZ1 laufen. Wenn ich nun nochmal 4x12TB hinzufügen würde, wäre das am besten nochmal ein RaidZ1 was ich dann hinzufügen würde? Oder lieber alle Daten vom ersten Raid runter und dann mit 8x12TB ein RaidZ2 aufbauen?

 

[gea]

Ganz eindeutig:
Wenn irgendwie möglich bei vielen Platten oder großen Pools weg von Z1 und auf Z2 gehen

 

[CommanderBond]

Ist eigentlich noch damit zu rechnen dass irgendwann endlich mal der Bug gefixt wird dass man auch von USB2/3 booten kann?
Bei meinem Microserver G7 war dies damals noch kein Problem, da dieser eh nur USB2 hatte. Mein nächster Server hatte dann USB2 und USB3 und obwohl es einzelne USB2 only Ports gab ließ sich das Problem nur dadurch lösen indem man USB3 im Bios gänzlich abgeschaltet hat.
Mein neuestes System bietet diese Option nun nicht mehr. Es besitzt zwar einen USB2 Port, hat aber auch einen Controller der USB3 kann.

Install media not available by using USB 3.0 device · Issue #505 · omniosorg/illumos-omnios

It's not possible to install OmniOS if the install media is an USB 3.0 flash drive because the device is not detected during boot. This issue is only related to USB 3.0 flash drives, so the install...

github.com

Bug #9863: [OpenIndiana Hipster] Live DVD and USB hang / freeze during boot - illumos gate - illumos

Redmine

www.illumos.org

Topicbox

illumos.topicbox.com

Andere Systeme schaffen es irgendwie auch von USB zu booten

Ich fahre auch schon seit Jahren sehr gut damit Sata nur noch für Datenplatten herzunehmen, aber dieser nervige Bug der nicht gefixt wird lässt mich dann doch so langsam irgendwie in Richtung eines anderen OS schielen. M.2, U.2 und Sata Ports sind in meinen Augen Verschwendung wenn man einen "relativ einfachen" Server aufsetzen will, weil dann fehlen mir auf der Datenseite die "highperformance" Schnittstellen wieder

Es ist ja nicht nur dass man nicht von USB booten kann. Auch die ilo5 beim Microserver ist im Grunde unbenutzbar zusammen mit omnios da weder iso mount noch die Tastatur funktioniert. Sprich man kann darüber quasi sich nur den Bildschirm anzeigen lassen, aber nichts eingeben... Ergo unbenutzbar. Man sieht dann ein Problem auf dem entfernen Computer ein Problem, kann aber nichts machen....

Verstehe nicht wieso man dieses Problem mit USB nicht löst, was es scheinbar schon seit Jahren gibt. Ist OmniOS als reines VM Gast System gedacht?

 

[gea]

Verstehe nicht wieso man dieses Problem mit USB nicht löst, was es scheinbar schon seit Jahren gibt. Ist OmniOS als reines VM Gast System gedacht?

Ganz im Gegenteil. Erst als ich die AiO Idee vorstellte wurde das populär. Davor wurde von einem virtualisierten Storageserver strikt abgeraten - bei Solaris und noch mehr bei Free-BSD. Es ist aber eher so, dass die Firmen die hauptsächlich hinter der Entwicklung stehen wie Nexenta oder Joyent das kommerziell einsetzen und da hat niemand USB Boot oder es gibt einfach Vorgaben welche Hardware zu benutzen ist wie bei SmartOS das ja ausschließlich auf USB Boot setzt. Bei OmniOS CE, der wichtigste OpenSource Distribution sieht das nicht anders aus. Dahinter stehen zwei Firmen aus UK und Schweiz die das intern kommerziell nutzen und da ist USB Boot eine Unbekannte.

Ist halt nicht so wie bei Linux wo von 1000 Optionen 999 unterstützt werden. Bei den Unix Distributionen muss man nehmen was unterstützt ist und nicht was man gerade hat.

Die einzige Option wäre es, in Illumos-dev eine Anfrage zu stellen oder in Illumos Issues einen Bugreport bzw. ein Feature request, https://www.illumos.org/issues

 

[CommanderBond]

Es betrifft aber nicht nur USB boot Gea. Offensichtlich wird die virtuelle Tastatur auch irgendwie über USB emuliert. Kurzum ich kann jetzt zwar übers Netzwerk den Bildschirm sehen, aber habe keine Tastatur.

Ich frage mich hier folgendes: Ist das so im Sinne des Erfinders? Also wird OmniOS nur da genutzt wo immer jemand vor Ort ist? Dann kann man sich ilo aber halt auch sparen.

Bin da grad etwas pisst dass offenbar jeder es schafft das es funktioniert, nur einzig und allein bei OmniOS geht es nicht... Mit FreeNAS hab ich das Problem nicht. Mit Windows hab ich das Problem nicht. Mit sämtlichen Linux Systemen hab ich das Problem nicht...

Ich dachte OmniOS würde man im professionellen Umfeld einsetzen. Wie kann es dann sein dass so eine wichtige Funktion dann nicht geht? bzw bin ich der erste dem es überhaupt auffällt? Kann ich mir nicht vorstellen.

Einzige Erklärung für mich ist nun irgendwie dass wohl kaum jemand OmniOS nicht virtualisiert einsetzt.

Oder sollte man generell von HPE abraten wenn ilo nicht funktioniert?
Ich habe im Bios auch schonmal die USB Ports alle deaktiviert, dies deaktiviert aber den USB Controller selbst nicht, den diesen zu deaktivieren ist nicht vorgesehen im Bios. Sprich selbst mit deaktivierten Ports kommen weiterhin die Fehlermeldungen in OmniOS bezüglich des USB Controllers.
Im hochgefahrenen Zustand sind aber USB Festplatten dann dennoch nutzbar anscheinend.

 

[gea]

Nützt ja nichts. '
Ich hatte mit ipmi bisher noch nie Probleme (SuperMicro), weder mit OmniOS. OI oder Solaris. SmartOS das ja fast ausschließlich USB Boot will, habe ich nur zum Testen probiert. Jede Variante hat aber einen anderen Bootloader.

Wenn ilo aber über USB arbeitet kann das aber schon eine Folge des gleichen Problems sein.

 

[CommanderBond]

Aber mal ne gute Nachricht. Die iOS App "Files" von Apple die in iOS integriert ist funktioniert mittlerweile mit dem SMB Server und hängt sich nicht mehr auf wenn man eine Datei versucht zu öffnen.

 

[Rach78]

Was ist momentan eigentlich der beste Weg um ein unverschlüsseltes Dataset komplett mit allen Snaps in ein verschlüsseltes zu überführen? Also quasi 1:1