[Sammelthread] ZFS Stammtisch

Dani2070 schrieb:
Gibts eigentlich auch HDDs mit PLP?
Zum Vergrößern anklicken....

Bei Festplatten kann das OS einen Schreib-Plattencache einfach deaktivieren. Dann ist jeder bestätigte Schreibvorgang sicher auf Platte.

Bei SSDs hat man oft einen größeren Schreibcache ohne den die SSD lausig langsam werden. Den kann man nicht abschalten und dessen Inhalt darf/sollte bei einem Crash nicht verlorengehen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Moin zusammen,
mein Napp-It / ZFS Fileserver (VM) macht mir Kummer. Alles fing damit an, dass ich gestern eine Platte im Hotswap Rahmen im laufenden System einschieben wollte, um darauf einen neuen Pool anzulegen. Nachdem die Platte nicht erkannt wurde, habe ich den Server kurzerhand einfach neu gestartet, ohne vorher die anderen VMs herunterzufahren, die auf NFS Shares des Servers zugreifen. War vielleicht nicht ganz "nett"... Nach dem Neustart haben sich die anderen VMs beklahgt, dass die NFS-Shares nicht verfügbar seien und auch die SMB-Shares sind nicht mehr ansprechbar (bis auf eines). Ein Blick auf die Filesysteme hat gezeigt, dass bei allen Filesystemen bis auf das eine Special ACLs vergeben sind (was vorher nicht so war). Weiterer Blick in die Faults hat folgendes ergeben:

Code: 
--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Mar 14 10:51:43 cabb4b98-8966-41bc-8422-85a38e380338  SUNOS-8000-KL  Major     

Host        : san
Platform    : VMware-Virtual-Platform    Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : defect.sunos.kernel.panic
Affects     : sw:///:path=/var/crash/napp-it-32/.cabb4b98-8966-41bc-8422-85a38e380338
                  faulted but still in service
Problem in  : sw:///:path=/var/crash/napp-it-32/.cabb4b98-8966-41bc-8422-85a38e380338
                  faulted but still in service

Description : The system has rebooted after a kernel panic.  Refer to
              http://illumos.org/msg/SUNOS-8000-KL for more information.

Response    : The failed system image was dumped to the dump device.  If
              savecore is enabled (see dumpadm(1M)) a copy of the dump will be
              written to the savecore directory /var/crash/napp-it-32.

Impact      : There may be some performance impact while the panic is copied to
              the savecore directory.  Disk space usage by panics can be
              substantial.

Action      : If savecore is not enabled then please take steps to preserve the
              crash image.
              Use 'fmdump -Vp -u cabb4b98-8966-41bc-8422-85a38e380338' to view
              more panic detail.  Please refer to the knowledge article for
              additional information.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Jun 27 2020     1650b3f1-1743-e34e-da43-9d14a28328d8  ZFS-8000-HC    Major     

Host        : san
Platform    : VMware-Virtual-Platform    Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.io_failure_wait
Affects     : zfs://pool=Data
                  faulted but still in service
Problem in  : zfs://pool=Data
                  faulted but still in service

Description : The ZFS pool has experienced currently unrecoverable I/O
                      failures.  Refer to http://illumos.org/msg/ZFS-8000-HC for
              more information.

Response    : No automated response will be taken.

Impact      : Read and write I/Os cannot be serviced.

Action      : Make sure the affected devices are connected, then run
                      'zpool clear'.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Jun 27 2020     46246322-e872-4ac8-aecb-afb8602e2454  ZFS-8000-CS    Major     

Host        : san
Platform    : VMware-Virtual-Platform    Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.pool
Affects     : zfs://pool=Data
                  faulted but still in service
Problem in  : zfs://pool=Data
                  faulted but still in service

Description : A ZFS pool failed to open.  Refer to
              http://illumos.org/msg/ZFS-8000-CS for more information.

Response    : No automated response will occur.

Impact      : The pool data is unavailable

Action      : Run 'zpool status -x' and attach any missing devices, follow
              any provided recovery instructions or restore from backup.



Stat: fmstat
  

  

  
module             ev_recv ev_acpt wait  svc_t  %w  %b  open solve  memsz  bufsz
cpumem-retire            0       0  0.0    0.0   0   0     0     0      0      0
disk-lights              0       0  0.0    0.1   0   0     0     0    28b      0
disk-transport           0       0  0.0    4.6   0   0     0     0    32b      0
eft                      1       0  0.0   19.2   0   0     0     0   1.4M      0
ext-event-transport       1       0  0.0   10.5   0   0     0     0    46b      0
fabric-xlate             0       0  0.0    0.0   0   0     0     0      0      0
fmd-self-diagnosis      24       0  0.0    0.0   0   0     0     0      0      0
io-retire                0       0  0.0    0.0   0   0     0     0      0      0
sensor-transport         0       0  0.0    0.8   0   0     0     0    36b      0
ses-log-transport        0       0  0.0    0.8   0   0     0     0    40b      0
software-diagnosis       0       0  0.0    0.0   0   0     0     0   316b      0
software-response        0       0  0.0    0.0   0   0     0     0   316b      0
sysevent-transport       0       0  0.0   87.2   0   0     0     0      0      0
syslog-msgs              0       0  0.0    0.0   0   0     0     0      0      0
zfs-diagnosis           12       0  0.0    0.5   0   0     1     0   184b   140b
zfs-retire              13       0  0.0    1.5   0   0     0     0   128b      0

Der oberste (Kernel Panic) ist vorhin entstanden, als ich alle VMs und zuletzt Napp-It heruntergefahren habe. Napp-It hat komischerweise kein Power-off gemacht, wie angefordert, sondern rebootet. Egal... Beim Neustart muss der Kernel Panic entstanden sein. Die anderen beiden Faults habe ich geprüft. Der angeblich betroffene Pool "Data" ist laut zpool status -x aber sauber (all pools are healthy). Auch ein zpool clear Data bringt keine Besserung.

Wie komme ich dem Fehler hier auf die Schliche? Die in den Faults referenzierten Hilfe-Seiten geben keine neuen Hinweise.

Danke vorab für Eure Unterstützung!
 
Im Prinzip ist OmniOS abgestürzt (Kernel Panic). Solche Fehler werden meist durch Hardware ausgelöst
und ein Kernelpanic versucht weiteren Schaden abzuwenden. Der Fehler hier war ein Disk i/o Problem.

Zur Analyse gibt es im Wesentlichen
System Logs (napp-it Menü System > Logs)
Fehlermanagement Logs (napp-it Menü System > Faults)
Pool Logs (napp-it Menü Pool > History)

Unabhängig davon (war ja eventuell nur ein temporäres Problem durch das Platteneinschieben), muss man den aktuellen Stand betrachten. Werden alle Pools sauber gemounted und sind alle Shares aktiv? Dann ist zunächst alles ok. Wenn der Pool Status ein (früheres) Problem anzeigt, kann man die Meldung mit zpool clear (napp-it Menü Pools) löschen.

Wenn beim Start von ESXi die NFS Shares nicht verfügbar sind, so werden die automatisch mit Verzögerung gemountet wenn sie wieder verfügbar sind.
 
Vielen Dank, @gea! Ich komme Stück für Stück weiter. Ich habe auf dem Pool jedes Filesystem (noch) doppelt: einmal unverschlüsselt (Filesystem hjat im Namen das Suffix _u für unencrypted) bekommen und einmal verschlüssselt. Die unverschlüsselten Filesysteme waren alle gemountet, alle verschlüsselten nicht. Die Keys waren aber geladen. Also alle Filesysteme gemountet, das hat soweit geklappt. Laut Übersicht sind auch alle Freigaben (NFS, SMB) aktiv, so wie gewünscht. De facto ist das aber nicht so. Ein showmount -e localhost zeigt, dass nur ein Filesystem exportiert ist?! Über SMB sind zwei Shares verfügbar, es sollten aber mehr sein. In der /etc/dfs/sharetab sind auch nur diese Filesysteme aufgeführt. Was ist da durcheinander gekommen? Laut Übersicht unter Napp-It FZS Dateisysteme sind alle gewünschten Dateisysteme über NFS bzw. SMB freigegeben, aber scheinbar ist spiegelt sich das in der sharetab nicht wider. Lässt sich das irgendwie wieder gerade ziehen oder muss ich die Freigaben alle von Hand eintragen?


Edit: Ich gebe gerade die Shares von Hand wieder frei über zfs share {Filesystemname}. Und stelle dabei fest, dass scheinbar alle Zugriffsberechtigungen flöten gegangen sind? Wie es scheint, kann jeder auf alles zugreifen? Share ACL auf full_set? Kann es wirklich sein, dass sämtliche Berechtigungseinstellungen weg sind und jeder auf alles zugreifen darf? Ich bin maximal irritiert...
 
Zuletzt bearbeitet:
Zur Info, falls hier irgendjemand minio unter OmniOS nutzt:

Die aktuellste Version ("minio -v" gibt "minio version RELEASE.2021-03-12T00-00-47Z" aus) schmeisst bei mir beim Login-Versuch den Fehler "Invalid UI version in the JSON-RPC response".
Da minio ja nur aus einem einzigen binary besteht, habe ich von einem anderen (noch nicht upgedateten) Server das dortige binary (Version "minio version RELEASE.2021-01-16T02-19-44Z") auf den aktualisierten Server rüberkopiert, den Dienst neu gestartet und dann lief es wieder.
 
  • Danke
Reaktionen: gea
kandamir schrieb:
Edit: Ich gebe gerade die Shares von Hand wieder frei über zfs share {Filesystemname}. Und stelle dabei fest, dass scheinbar alle Zugriffsberechtigungen flöten gegangen sind? Wie es scheint, kann jeder auf alles zugreifen? Share ACL auf full_set? Kann es wirklich sein, dass sämtliche Berechtigungseinstellungen weg sind und jeder auf alles zugreifen darf? Ich bin maximal irritiert...
Zum Vergrößern anklicken....

Share ACL werden nicht im Dateisystem gespeichert sondern sind Rechte auf eine Share Kontrolldatei die beim Freigeben angelegt (mit everyone=full) und beim Beenden des Shares gelöscht wird. Sie dienen hautpsächlich dazu die Rechte kurzfristig einzuschränken. Alternativ muss man die beim erneuten Freigeben erneut setzen (manuell oder per Script). Dauerhafte ACL sind Datei-ACL. Das sind Eigenschaften einer Datei oder eines Ordners. Üblicherweise nutzt man daher Datei ACL und nicht Share ACL für dauerhafte Sachen. Systemddateien sollte man nicht ohne Not editieren. Man gibt ein Dateisystem per NFS/SMB frei und beendet die Freigabe per zfs set share (oder napp-it Menü ZFS Dateisysteme) und gut.

Beitrag automatisch zusammengeführt:

zos schrieb:
Zur Info, falls hier irgendjemand minio unter OmniOS nutzt:

Die aktuellste Version ("minio -v" gibt "minio version RELEASE.2021-03-12T00-00-47Z" aus) schmeisst bei mir beim Login-Versuch den Fehler "Invalid UI version in the JSON-RPC response".
Da minio ja nur aus einem einzigen binary besteht, habe ich von einem anderen (noch nicht upgedateten) Server das dortige binary (Version "minio version RELEASE.2021-01-16T02-19-44Z") auf den aktualisierten Server rüberkopiert, den Dienst neu gestartet und dann lief es wieder.
Zum Vergrößern anklicken....

Alternativ (bis ein neueres Update wieder geht) das OmniOS extra Repo z.B. auf 151034 stellen und von da updaten/installieren. Wirklich sehr angenehm dass OmniOS je OS Release ein eigenes Software Repo hat.
Beitrag automatisch zusammengeführt:

MisterY schrieb:
Niemand eine Idee?
Zum Vergrößern anklicken....
ZFS Trim hatte in der Anfangszeit vor ca 1,5 Jahren mehrere Probleme. Auch gab es SSD/NVMe die Probleme mit Trim machten, bis zu korrupten Pools. Das kann immer noch passieren, ZFS erkennt inzwischen aber recht gut ob es funktionierten könnte, Einfach mal Trim aktivieren und längere Zeit Last erzeugen. Wenn es da keine Probleme gibt kann man es nutzen. Zu Proxmox habe ich aber keine tieferen Erkenntnisse.

Unabhängig davon ist eine EVO keine gute Server SSD und kann auch kein plp was sie für VM Storage untauglich macht. Funktionieren wird es dann wenn das Mainboard Bifurkation z.B. 8x-> 4X4X oder 16x->4x4x4x4x unterstützt.
 
Zuletzt bearbeitet:
Wie kann man unter Windows auslesen, ob eine SSD DRAT oder RZAT unterstützt? Unter linux geht das ja.
Da die Dell Rx20er Serie kein Bifurcation unterstützt, würden es wohl eher zwei M2->PCIe adapter werden mit je einer NVME.
Möglich, dass eine EVO nicht das Optimum für einen Server ist, da wir hier aber von HOMEservern reden und genügend regelmäßig backups gemacht werden, finde ich das nicht so tragisch. In den letzten 5 Jahren, wo ich Consumer-SSDs verwende (sogar noch bevor ZFSonLinux Trim unterstützte), hatte ich noch nie Datenverlust, selbst bei zwei Stromausfällen nicht (und das bei sync=disable).
 
gea schrieb:
Share ACL werden nicht im Dateisystem gespeichert sondern sind Rechte auf eine Share Kontrolldatei die beim Freigeben angelegt (mit everyone=full) und beim Beenden des Shares gelöscht wird. Sie dienen hautpsächlich dazu die Rechte kurzfristig einzuschränken. Alternativ muss man die beim erneuten Freigeben erneut setzen (manuell oder per Script). Dauerhafte ACL sind Datei-ACL. Das sind Eigenschaften einer Datei oder eines Ordners. Üblicherweise nutzt man daher Datei ACL und nicht Share ACL für dauerhafte Sachen. Systemddateien sollte man nicht ohne Not editieren. Man gibt ein Dateisystem per NFS/SMB frei und beendet die Freigabe per zfs set share (oder napp-it Menü ZFS Dateisysteme) und gut.
Zum Vergrößern anklicken....

Hm, vielen Dank, aber so richtig bringt mich das jetzt nicht weiter, denn zum einen finde ich unter Napp-It nichts zu Datei-ACL, sondern nur Share ACL und Folder ACL. Sind Folder ACL = Datei ACL? Da habe ich nichts geändert, aber ich habe ja auch nix gemacht (außer Systemneustart), das dazu hätte führen dürfen, dass die Dateisysteme nicht gemountet werden... Zugegebenermaßen könnte ich jetzt nicht sagen, ob ich die Zugriffsrechte über Folder ACL oder Share ACL gesetzt hatte. Ich habe die Freigabe auch nicht aktiv beendet und ich fürchte nun, dass die Freigaben anderweitig verloren gegangen sind, im Zusammenhang mit dem nicht mounten der Dateisysteme... Interessanterweise waren die Dateisysteme laut Napp-It freigegeben. De facto aber halt eben nicht.

Gibt es die Möglichkeit, über alte Snapshots die Berechtigungen wieder zu rekonstruieren? Ich fürchte ja, dass nicht.
 
kandamir schrieb:
Gibt es die Möglichkeit, über alte Snapshots die Berechtigungen wieder zu rekonstruieren? Ich fürchte ja, dass nicht.
Zum Vergrößern anklicken....

ACLs sind Bestandteil von Snapshots, insofern sollte es also möglich sein, diese aus Deinen Snapshots zu rekonstruieren, sofern Du diese einst gesetzt hast.

Aber möglicherweise ist das auch nur ein Phantomproblem und wir reden hier aneinander vorbei. Zugriffsrechte bei smb-shares sehe ich mit "showmount" oder "cat /etc/dfs/sharetab" doch eh nicht, dennoch gibt es diese ggf. Letztendlich kann sich nur ein in der StorageVM bzw. dem Storage-Host angelegter User überhaupt über smb anmelden (sofern Du den Gastzugriff nicht explizit über die Filesytem-property "sharesmb" mit "sharesmb=name=freigabename,guestok=true" erlaubt hast). Erst wenn dieser sich dann per User/Passwort angemeldet hat, kommen die aktuell vorhandenen Zugriffsrechte zum Zuge, also u. U. ein @evereyone "full_set". Diese Zugriffsrechte kannst Du mit einem gewissen Aufwand aus vorhandenen Snapshots auch sicher rekonstruieren, sofern diese wirklich alle weg sein sollten. Aber vorher würde ich nochmal genauer hinsehen.

Was gibt denn der Befehl "ls -l <filesystem>" aus? Wenn die erste ausgegebene Spalte ein "+" am Ende hat (z. B. "drwx------+"), dann sind ACLs vorhanden. Die kannst Du Dir dann mit "/usr/bin/ls -V <filesystem>" anzeigen lassen. Wenn kein "+" da ist, sind auch keine ACLs gesetzt. Bei den nfs-shares solltest Du nachsehen, wie denn die Filesystem-property "sharenfs" bei dem betreffenden Filesystem aktuell gesetzt ist ("zfs get sharenfs <filesystem>").
 
Danke für die Rückmeldung, @zos! ACL sind definitiv vorhanden, das von Dir beschriebene + am Ende der Berechtigungen ist da. Dass es ein Problem mit den Zugriffsrechten gibt habe ich relativ schnell daran bemerkt, dass ich mit meinem persönlichen (also nicht Admin/Root) Account per SMB auf Daten anderer Nutzer zugreifen darf, was bislang nicht ging.

Zu sharenfs:
root@san:~# zfs get sharenfs Data/filesystemA
NAME PROPERTY VALUE SOURCE
Data/filesystemA sharenfs on received

Wie rekonstruiere ich die Berechtigungen aus den Snapshots? Da ist eine ausreichend weit zurück reichende Historie an Snapshots vorhanden.
 
kandamir schrieb:
Danke für die Rückmeldung, @zos! ACL sind definitiv vorhanden, das von Dir beschriebene + am Ende der Berechtigungen ist da. Dass es ein Problem mit den Zugriffsrechten gibt habe ich relativ schnell daran bemerkt, dass ich mit meinem persönlichen (also nicht Admin/Root) Account per SMB auf Daten anderer Nutzer zugreifen darf, was bislang nicht ging.

Zu sharenfs:
root@san:~# zfs get sharenfs Data/filesystemA
NAME PROPERTY VALUE SOURCE
Data/filesystemA sharenfs on received

Wie rekonstruiere ich die Berechtigungen aus den Snapshots? Da ist eine ausreichend weit zurück reichende Historie an Snapshots vorhanden.
Zum Vergrößern anklicken....
Hast Du auch nachgesehen, welche ACLs sich konkret hinter dem "+" verbergen, also noch vorhanden sind?

Dazu entweder für eine ausführliche Darstellung

/usr/bin/ls -v <file, filesystem oder directory>

oder für die kompakte Darstellung

/usr/bin/ls -V <file, filesystem oder directory>

eingeben.

Es ist wichtig den Befehl "ls" mit vorangestellten "/usr/bin/" aufzurufen, da es zwei Versionen von "ls" gibt (die Defaultvariante liegt unter "/usr/gnu/bin" und diese kann keine ACLs lesen bzw. ausgeben). Wenn Du das gemacht hast, solltest Du sehen können, was genau an Deinen aktuellen ACLs "krumm" ist.

Ob es wirklich Sinn macht ACLs aus Snapshots wiederherzustellen steht auf einem anderen Blatt und ich würde das zunächst mal bezweifeln. Ich kenne zwar Deinen Use-Case nicht, würde aber behaupten, dass Du diese im SOHO-Umfeld mittels eines Windows-Rechners über SMB schneller wieder eingerichtet hast (geht auch mit Napp-it, ist aber m.W. eine "Pro-Extension"). Über Snapshots wird der Weg ggf. aufwändiger sein, denn dazu wirst Du Dir u. U. ein Bash-Script basteln müssen, welches die ACLs aus dem aktuellsten Snapshots ausliest und neu setzt (dabei gehen Dir natürlich die Daten durch, die zum Zeitpunkt der Snapshoterstellung noch nicht vorhanden waren).

EDIT: Oder Du machst einen Rollback, wenn sich seit Deinem letzten Snapshot nicht allzu viele Änderungen ergeben haben. Aktuellere Dateien kannst Du Dir vorher ja sichern....
 
Also ich sehe bei usr/bin/ls -V schon die ganzen Berechtigungen, das klappt schon. Wie die Berechtigungen im Vergleich zu „vorher“ sind, müsste ich tatsächlich abgleichen, bestenfalls wirklich im Vorher-/Nachher-Vergleich, denn im Kopf habe ich das nicht mehr alles. Möglicherweise reicht es wirklich, die Share-ACL zu korrigieren, aber auch da hätte ich eben gerne de Vorher-Nachher-Vergleich - daher meine Frage, inwiefern und mit welchem Aufwand es möglich ist, sich diesen alten Stand anzuschauen.

Ich könnte durchaus versuchen, das auch einfach alles wieder von Hand neu zu berechtigen - betroffen ist ein einstelliger Kreis an Nutzern, hier kommen NFS-Shares für unterschiedliche Services zum Einsatz (beispielsweise eine Nextcloud Instanz, welche die Storage VM als Ablage nutzt, ebenso Medienserver usw.), Mac Clients, keine Windows Clients. Aber das von Grund auf wieder neu zu berechtigen kostet mich vermutlich doch eine Menge Zeit, die ich aktuell eigentlich dafür nicht spendieren wollte, wenn dann nur zähneknirschend, falls Du verstehst. ;-) Und wenn ich den Aufwand treiben müsste, dann vermutlich gleich richtig mit LDAP o.ä., damit die User- und Gruppen-IDs über alle Systeme wirklich konsistent sind (den Aufwand habe ich bislang nie getrieben, aber es funktionierte bislang zufriedenstellend).
 
kandamir schrieb:
Also ich sehe bei usr/bin/ls -V schon die ganzen Berechtigungen, das klappt schon. Wie die Berechtigungen im Vergleich zu „vorher“ sind, müsste ich tatsächlich abgleichen, bestenfalls wirklich im Vorher-/Nachher-Vergleich, denn im Kopf habe ich das nicht mehr alles. Möglicherweise reicht es wirklich, die Share-ACL zu korrigieren, aber auch da hätte ich eben gerne de Vorher-Nachher-Vergleich - daher meine Frage, inwiefern und mit welchem Aufwand es möglich ist, sich diesen alten Stand anzuschauen.

Ich könnte durchaus versuchen, das auch einfach alles wieder von Hand neu zu berechtigen - betroffen ist ein einstelliger Kreis an Nutzern, hier kommen NFS-Shares für unterschiedliche Services zum Einsatz (beispielsweise eine Nextcloud Instanz, welche die Storage VM als Ablage nutzt, ebenso Medienserver usw.), Mac Clients, keine Windows Clients. Aber das von Grund auf wieder neu zu berechtigen kostet mich vermutlich doch eine Menge Zeit, die ich aktuell eigentlich dafür nicht spendieren wollte, wenn dann nur zähneknirschend, falls Du verstehst. ;-) Und wenn ich den Aufwand treiben müsste, dann vermutlich gleich richtig mit LDAP o.ä., damit die User- und Gruppen-IDs über alle Systeme wirklich konsistent sind (den Aufwand habe ich bislang nie getrieben, aber es funktionierte bislang zufriedenstellend).
Zum Vergrößern anklicken....

Die Share ACL sind keine Datei ACL und man kann die daher nicht aus einem Snap wiederherstellen. Es sind ACL auf die Share-Steuerdatei z.B. /tank/data/.zfs/shares/data und diese Systemdatei ist nicht im Snap.

Auch muss man aufpassen. Der Solarish SMB Server arbeitet mit ntfs artigen nfs4 ACL und Windows SID. NFS3 mit uid/gid. Das ist nur schwer und mit mappings unter einen Hut zu bringen. Ich mache das so dass sich wo es geht SMB einsetze und NFS nur wo absolut nötig (ESXi) und das dann netzwerk/firewallmäßig absichere.
 
  • Danke
Reaktionen: zos
Zuletzt bearbeitet:
OmniOS 151038, Stable and Long-Term-Supported (LTS) Release, TBC of May 2021
github.com

omnios-build/doc/ReleaseNotes.md at master · omniosorg/omnios-build

Build system for OmniOS. Contribute to omniosorg/omnios-build development by creating an account on GitHub.
github.com github.com

Im nächsten OmniOS LTS ab Mai gibts ein paar wichtige neue Features wie persistent l2arc, Verbesserungen bei LX/Bhyve Container/Zonen, Hardware wie AMD Zen, Intel X710 oder neuere Chipsets. Wer vorab die neuen Features testen möchte, kann OmniOS bloody 151037 installieren und das im Mai auf 038 updaten.
 
Gude,

habe mal aus interesse meinen Filer (Solaris 11.4) mit Zenmap (intense scan) gescannt...
Das spannende Ergebnis war, dass danach alle Filesysteme gelockt waren (sind alle verschlüsselt)
Ist dass nun ein Sicherheitsmerkmal von Solaris oder ist mein "Server" mit der Auslastung überfordert und "verschluckt" sich whatever ?

Also ggf. vorsicht - wenn das als VM Storage etc eingesetzt wird...

War mit einem zweiten Scan reproduzierbar.
 
Zuletzt bearbeitet:
Ich kann die Frage nicht beantworten (müßte man Oracle fragen), halte es aber für denkbar dass es ein Sicherheitsmerkmal ist. Eine Lastsituation kann jedenfalls nicht dafür sorgen dass alle Filesysteme in den lock Modus gehen.

ps
Bei VM Storage sollte man sync aktivieren. Ich habe jetzt keine Tests mit Oracle Solaris sondern mit OmniOS gemacht, da ist aber sync + enc sehr langsam. Original ZFS wird sich bei kleinen io (encrypted sync) kaum anders verhalten als Open-ZFS, https://napp-it.org/doc/downloads/epyc_performance.pdf
 
Zuletzt bearbeitet:
Hi,

ich bräuchte mal einen Tipp zum ESXi-Netzwerk-Setup. Ich hatte da noch einen offensichtlichen Fehler, den ich nun anscheinend korrigiert habe. Die VM's auf dem vom napp-it bereitgestellten NFS-Speicher waren recht lahm (10 MB/s). Es stellte sich heraus, dass der Traffic über das physische Netz ging. Da bin ich mir jetzt doch etwas unsicher, ob mein Aufbau so ist wie man es machen sollte. Der Server hat 2 physische NICs 1GBit/10GBit. Das omnios hat zwei virtuelle Netzwerkkarten. Die übrigen VM's liegen auf dem NFS Speicher und haben nur eine virtuelle NIC.
 

Anhänge

  • vSw1.jpg
    vSw1.jpg
    24,6 KB · Aufrufe: 95
  • vSw10.jpg
    vSw10.jpg
    35,4 KB · Aufrufe: 97
Sieht fuer mich falsch aus.

Du legst ein Storage VSwitch an ohne Uplink nach draußen.

Wozu soll da nen physischer Adapter dran haengen?

Storage Services für 'außen' macht die 2. Virtuelle Netzwerkkarte deiner Storage-VM, an der die physische NIC angeschlossen ist.
 
Das macht Sinn. Neue Version anbei.
Was mir jetzt nur noch nicht ganz klar ist, ist die Konfiguration der Management-Netze.
Ich wollte es eigentlich so haben, dass ich sowohl das ESXi als auch OmniOS über beide physischen Karten ansprechen kann (beide Adapter hängen allerdings im gleichen Netz).

Das OmniOS hat jetzt schon drei virtuelle NICs:
- Management - hängt am ersten (1GBit) vSwitch (derzeit zu Testzwecken als nicht verbunden konfiguriert)
- allg. Storage-Zugriff für das gesamte Netz - vSwitch10G
- NFS-Storage für VMs - vSwitchStorage

Beim ESXi kann ich zwar einen weiteren VMkernel-Adapter für das 10GBit-Netz hinzufügen, aber zugreifen kann ich nicht mehr so wie das 1GBit-Kabel getrennt wird.
Das Problem scheint hier wohl zusätzlich das Grund-Setup in der ESXi-Konsole zu sein?! Dort ist derzeit nur die 1GBit-NIC für das Management-Netzwerk ausgewählt. Kann man das so lassen und ausschließlich über vmk-NICs mit Management-Dienst "erweitern"? Mir scheint es so, dass dafür auch die physische Karte mit DHCP konfiguriert sein muss.

Ich hatte die Tage Probleme, dass nach einer kurzen Unterbrechung auf dem 1 GBit-Netz (Kabel kurz abgesteckt) der ESXi-Host 192.168.10.23 gar nicht mehr erreichbar sein wollte. Auch nicht unter seiner 10GBit-Adresse.
Selbst nach einem Restart des Management Netzwerkes über die ESXi-Konsole direkt am Rechner. Ursache ist evtl. DHCP. Bislang läuft bei mir alles über statisches DHCP (außer das neue Storage-Netz ohne Uplink).
 

Anhänge

  • ESXi Netzwerkkonfiguration.jpg
    ESXi Netzwerkkonfiguration.jpg
    65,9 KB · Aufrufe: 110
Nabend, mich würde mal Eure Meinung zu folgender Situation interessieren.
Ich habe aktuelle 8x 4TB SSDs (4x ZFS Mirror), alles spitze und pfeilschnell.
Leider reicht mir der Platz nicht mehr, größere SSDs ist momentan "nicht drinnen" und für weitere fehlt der Platz im Gehäuse.

Der Pool dient eigentlich nur als Mediengrab für Plex etc., alle VMs/LXCs laufen in einem eigenen ZFS SSD Mirror.

Eine 16TB USB HDD als Backup ist vorhanden, ich würde am liebsten 8x Single Vdevs machen da mir die Ausfallsicherheit gar nicht mal sooo wichtig ist.
Wenn mir eine SSD bzw. ein Vdev verreckt ist aber der gesamte Pool zerstört, richtig ?
Klar gibts ein Backup aber es bleibt doch ein relativ hohes Risiko bei 8 SSDs, muss ja nicht sein :-)

  • Z1 wäre mir Platztechnisch am liebsten, 2x Z1 mit je 4 SSDs oder 1x Z1 mit 8 SSDs ?
  • Z2 wäre auch noch im Rahmen, 1x Z2 mit 8 SSDs ?
  • Umstieg auf LVM etc. ?

Vielen Dank !
 
Zuletzt bearbeitet:
Ich würde einen Pool mit einem Z2 vdev aus 8 SSD machen. Da dürfen 2 SSD ausfallen. 2 x Z1 ist recht sinnfrei bei SSD da dies lediglich mehr iops bringt (unkritisch bei SSD).
 
Hey gea,

vielen dank für die prompte Antwort, dann werd ich das genauso machen :-)

Letzte Frage, aktuell managed PVE bei mir ZFS, ein LXC Container spielt SMB/NFS Server, funktioniert soweit.
Spricht etwas dagegen die SSDs bzw. den HBA an eine VM durchzureichen für zB. OmniOS ?
Einfach zwecks Webinterface für ZFS sowie Management meiner Shares etc., quasi weg von der Konsole xD
 
@synci: Da bin ich gespannt, ob dir OmniOS mit durchgereichtem HBA gelingt. Wäre schön, wenn Du da mal Feedback geben kannst. Sei mit den Daten vorsichtig, wenn Du es ausprobierst und exitierende Pools ggf. sogar importierst. OmniOS ohne HBA läuft bei mir. Sobald ich aber einen HBA (2008/3008) durchreiche, gibt es unkalkulierbare Kernelfehler. Teilweise beim Booten, teilweise nach einer gewissen Zeit im Betrieb. Im Internet gibt es leider gegen NULL Informationen, was man da tun kann. Außer, dass schon Einige es aufgegeben haben.

Ich betreibe mein Storage jetzt mit Truenas, würde aber gerne zur virtualisierten napp-it unter Proxmox zurück gehen.
 
Eigentlich wollte ich einen neues ZFS-Server aufsetzen und als Platten 6x 14TB Ironwolf Pro nutzen. Leider kann ich die Platen nicht mehr so günstig bekommen wie gehofft und frage jetzt welche Probleme auftreten können wenn man die Ironwolf mit EXOS mischen würde... Bin gerade echt gefrustet... 5 Ironwolf hatten bereits den Weg zu mir gefunden...
 
you schrieb:
Ich betreibe mein Storage jetzt mit Truenas, würde aber gerne zur virtualisierten napp-it unter Proxmox zurück gehen.
Zum Vergrößern anklicken....
Kannst Du nicht das proxmox ZFS nativ nutzen und mit napp-it verwalten? Das lässt sich doch Dank gea's Mühen auch unter Linux installieren und nutzen?

Nur SMB dann evtl etwas umständlich...
 
Würde jetzt ehrlichgesagt keine Problem mit der einen Exos erwarten wenn sie die gleiche Sektorconfig (512e nehm ich an) hat; sie wird halt im Zugriff etwas lauter sein.

Ein Performance-Bottleneck sollte sie nicht werden und von der Last-Auslegung ist sie ja nochmal über der Ironwolf Pro angesiedelt.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
857
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
575
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
518
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
298
AliManali
AliManali
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