[Sammelthread] ZFS Stammtisch

Hallo zusammen,

wenn ich nachträglich auf einem FS die Kompression anmache, ist dass dann auch für schon vorhandene Dateien oder erst für neue ? Und ist es überhaupt ratsam diese nachträglich zu aktivieren ?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ja kann man nachträglich aktivieren. Die alten Daten werden nicht komprimiert. Dafür müsstest du diese Daten neu auf den pool schreiben.
 
Hallo zusammen,

ich erweitere gerade meinen Storage und überlege, einen Teil meiner Daten auf den neuen Platten verschlüsselt abzulegen. Es läuft Omnios auf ESXi 6.7 (mit napp-it) auf halbwegs potenter (Home-) Server-Hardware (Xeon E3-1240, 32GB RAM). Beim Herumspielen mit der Verschlüsselungsfunktion habe ich ein merkwürdiges Verhalten bei napp-it festgestellt - vielleicht verstehe ich die Hintergründe aber nicht so ganz:

Wenn ich auf einem Pool ein verschlüsseltes Dateisystem lösche (über ZFS Filesystems/Destroy), dann habe ich für diesen Pool nicht mehr die Möglichkeit, neue verschlüsselte Filesysteme anzulegen. Die entsprechenden Optionen unter "Encryption settings" fehlen dann einfach.
napp-it.png

Mache ich etwas falsch oder ist das ein Bug?

Da ich beim Testen dadurch z.Z. ein wenig eingeschränkt bin, zwei Fragen zum Thema Verschlüsselung:
  1. Muss ich (auf o.g. Hardware) beim Einsatz von Verschlüsselung gegenüber einem unverschlüsselten Pool mit größeren Performance-Einbrüchen rechnen? Es geht um einen RaidZ-Pool von 5 Platten (7200rpm) mit je 12TB.
  2. Ist über die freie napp-it Variante auch ein "auto-unlock" beim Booten möglich oder ist diese Funktion den Pro-Version vorbehalten?

Danke vorab!
 
Zuletzt bearbeitet:
Sieht nach einem Bug in nappit aus @gea
1. Wenn der Prozessor AES-NI kann, geringe Verluste, sonst hohe.
2. auto-unlock in welcher Form? Irgendwo muss der key ja liegen. Wenn der plain in der nappit Partition läge, könntest Du es Dir ja auch direkt sparen. Wie Solaris mit TPM zusammenarbeitet, weiß ich nicht. Aber auch mit tpm kann der Räuber den ganzen PC anderswo anschließen und in Ruhe die Shares angreifen...
 
Danke, @martingo

zu 1) der Xeon sollte aus meiner Sicht AES-NI beherrschen - aber wird das unter ESXi in eine VM "durchgereicht"?
zu 2) vom Konzept wollte ich mich mit "auto-unlock" natürlich an das anlehnen, was napp-it anbietet: Entweder ein Keyfile auf einem USB-Stick oder auf einem Webserver
 
Ich habe den Fehler behoben. Bitte die 19.12b7 free erneut laden (About > Update)
Der Automount mit einem Keyfile z.B. von einem USB Stick geht auch mit 19.12 free
 
19.12b7 installiert - Problem behoben, vielen Dank!

Ich habe mal geschaut, wie sich die Verschlüsselung auf die Performance auswirkt. Einfacher Test: Kopieren einer 15GB Datei von einer (SATA-) SDD auf ein jungfräuliches Filesystem (RaidZ-Pool aus 5x12TB 7200k-Platten):
  • unverschlüsselt: >>550MB/s (mehr sollte bei SATA-SSDs auch nicht gehen, oder?
  • verschlüsselt: <<100MB/s
Das scheint darauf hinzudeuten, dass in meiner OmniOS-VM AES-NI nicht funktioniert, oder? Ist das ein erwartetes Verhalten unter ESXi?
Kann man das irgendwie verifizieren? Bei Debian-VMs auf dem gleichen Host zeigt mir /proc/cpuinfo "AES" als Feature an, CPU-Z in einer Windows-VM ebenfalls...

Update: isainfo -v zeigt an, dass anscheinend die OmniOS-VM ebenfalls "aes" als Feature aktiviert hat...
 
Zuletzt bearbeitet:
Schon sehr schade. Wenn ich mal so überlege, Ich bin ursprünglich erwartungsvoll ans werk zur Umstellung gegangen um zum schluss zu merken, das OmniOS wenn Crypted nicht annähernd die Leistung bring. Es hat mich n Haufen Zeit gekostet, und unterm Strich ist nix dabei rum gekommen.
Daten hin und her kopieren, testen etc.. Ich Lass in jedem Falle die Finger davon bis hier im besten Falle irgendwann mal sich was tut bzgl. der Crypted Performance. Sonst hab ich keinen Bedarf umzustellen.
Das hatte mich schon genug geärgert.
 
Es macht wenig Sinn sich über Versäumnisse zur Illumos ZFS Verschlüssellung aus 2015 zu ärgern. Die aktuelle Open-ZFS Verschlüssellung basiert zwar auf dem damaligen Stand in Illumos, wurde jedoch von Datto unter ZoL fertig entwickelt. Inwieweit es innerhalb der verschiedenen Open-ZFS Varianten Unterschiede gibt kann ich nicht sagen, die Codebasis ist aber die Gleiche. Die Betriebssysteme aus 2015 sind auf jeden Fall nicht mehr die Gleichen.

Solange man im LAN mit 1 G unterwegs ist, reicht zudem 1G Verschlüssellungsperformance. Man kann dann noch die Verschlüssellungsstärke (256->128) herabsetzen oder schauen wieviel virtuelle CPUs man der VM zuweisen kann.


In Oracle Solaris ist ZFS Verschlüssellung seit 10 Jahren. Klar dass das ausgereifter ist. In Open-ZFS ist es gerade seit letzten Sommer. Dafür ist bereits sehr ausgereift. Featuremäßig kann es sogar bereits mehr als Original ZFS Solaris, insbesondere was ZFS Replikation verschlüsselter (unlocked) Dateisysteme angeht. Das kann Solaris aktuell nicht.
 
Zuletzt bearbeitet:
gea schrieb:
Solange man im LAN mit 1 G unterwegs ist, reicht zudem 1G Verschlüssellungsperformance. Man kann dann noch die Verschlüssellungsstärke (256->128) herabsetzen oder schauen wieviel virtuelle CPUs man der VM zuweisen kann.

In Oracle Solaris ist ZFS Verschlüssellung seit 10 Jahren. Klar dass das ausgereifter ist. In Open-ZFS ist es gerade seit letzten Sommer. Dafür ist bereits sehr ausgereift. Featuremäßig kann es sogar bereits mehr als Original ZFS Solaris, insbesondere was ZFS Replikation verschlüsselter (unlocked) Dateisysteme angeht. Das kann Solaris aktuell nicht.
Zum Vergrößern anklicken....

Bezüglich der Last wenn cryted hab ich ebenfalls keine gute Erfahrung gemacht. Die Last zu meinem Test war wesentlich höher. Was eindeutig Kapazität nimmt für andere Anwendungen.

Ich akzeptiere ja, das es evtl. schon mehr Features gibt, aber wenn doch etwas für mich / den einen oder andern zumindest essentielles nicht funktioniert, kann man leider so viel schön reden wie man möchte.
Es gibt halt verschiedene use cases. Je nach dem setzt man prioritäten. Man misst halt an funktionierend bestehendem, auch wenn es evtl. nicht der absolut korrekte Vergleich ist.
Ich zumindest warte eben bis sich hoffentlich mal was in die richtige Richtung bewegt.
Hätte ja gern umgestellt, aber nicht um jeden Preis. Verhältnissmäßig gute Hardware haben um zum Schluss minderwertige Performance zu bekommen wie auch hohe Auslastung ist für mich ein no go. Dafür hat es zu viel geld gekostet.
Bin bis jetzt mit den Solaris Features absolut zufrieden. Und was soll ich sagen Solaris und Nappit als Team läuft einfach stabil und performant. Warum sollte man das aufs Spiel setzen?

Kommt Zeit kommt hoffentlich Rat. Dann bekommt es wieder eine Chance. Die Zeit wird zeigen in welche Richtung es geht.
 
@gea die ZFS Verschlüsselung benutzt aber das Illumos KCF (bei Solarish), daher ist auch hier das alte Performance Problem weiterhin existent.

cu
 
OpenIndiana 2020.04 ist verfügbar

OpenIndiana ist wie OmniOS ein Solaris Fork und basiert auf Illumos. Im Gegensatz zu OmniOS gibt es kein stable/long term stable und auch keine kommerzielle Supportoption oder ständige Sicherheitsupdates teils mehrfach pro Monat. OpenIndiana ist quasi die Referenzinstallation von Illumos. OpenIndiana gibt es als Minimal, Text (ähnlich zu OmniOS) und Desktop Version mit Browser und Office Apps. Jedes "pkg update" ergibt stets die allerneueste Illumos Version. OpenIndiana wird daher gerne als Home ZFS Server eingesetzt. Für ein produktives ZFS Storagesystem ist OmniOS geeigneter.

2020.04 Release Notes - OpenIndiana Docs

docs.openindiana.org docs.openindiana.org
 
Das mit dem suboptimalen AES-NI bei OmniOS ist schade :(

Was nun, wenn man auf Verschlüsselung "angewiesen" ist und nicht CPU.Resourcen zum Fenster rauswerfen möchte? Eine Linux-Basis-Installation, die die physischen Datenträger verschlüsselt und ein virtualisiertes OmniOS, das virtuelle Datenträger von Linux bekommt und so selber nicht für die Verschlüsselung zuständig ist?
 
Ich habe mal ein paar Tests mit einer Intel Optane gemacht. Im aktuellen Pool > Benchmark in napp-it habe ich dazu die Verschlüssellung als anwählbaren Parameter eingefügt (bei langsamer Hardware kann der CGI Test selbst unter Chrome zu einem Timeout führen). War nicht ganz befriedigend mit OmniOS. Unter ESXi mit aktueller Hardware und einem Xeon silver oder mit einer älteren Bareboneinstallation und einem Xeon von 2011 kam ich da sequentiell auf 350-400 MB/s mit Filebench. Ohne Verschlüssellung ein mehrfaches.

Reicht aber selbst für ein normales 10G Netzwerk, hat aber noch Luft nach oben für einfachere CPUs. Die Ergebnisse sind viel besser als 2015 mit einem normalen Illumos lt http://zfs-create.blogspot.com/2014/05/optimizing-illumos-kernel-crypto.html jedoch bei weitem nicht so gut wie mit dem da angedachten fastpath fix.

ZoL?
Hat natürlich seine Vorteile. Der "tut einfach" Faktor gehört mit ZFS nicht dazu. Dafür nehme ich gerne in Kauf dass unter Solarish nur professionelle Hardware unterstützt wird oder ich bei OmniOS eine stärkere CPU brauche. Ist ja noch weit von z.B. Apples Premium Preisaufschlägen für Problemfreiheit entfernt.
 
Zuletzt bearbeitet:
Im Rahmen der Umstellung meiner Plattenkonfiguration hatte ich auch beschlossen, die Omnios-VM mal neu aufzusetzen. Ich habe dazu das aktuelle napp-it-OVA unter von gea unter ESXi eingespielt, Omnios auf die aktuellste Version gebracht und meine User und Gruppen wieder eingerichtet. Nach dem ersten Neustart schien es Probleme mit den eingerichteten Gruppen zu geben, so dass ich diese gelöscht und neu eingerichtet habe. Soweit lief dann alles für ein paar Tage.
Eben hatte ich dann aber wieder das Problem, das sich im laufenden Betrieb auf einmal nicht mehr auf meine SMB-Shares kam. Ein Blick in napp-it offenbarte folgendes:
napp-it.png


"smbadm show" zeigt mir ebenfalls die vordefinierten Gruppen an und dann auch nur "An error occured while retrieving group data. Check the system log for more information."
Hat das schon mal jemand gehabt und einen Ansatzpunkt? In welches "system log" sollte man denn schauen?
Google hat nicht geholfen, in fand nur einen Link hier in das Forum zu einem Post aus 2012 - ohne Lösung...
 
/var/log/syslog

Ich denke, derr hat noch die alten Gruppen im Bauch. Ohne Domäne extrem nervig.
 
In /var/log/syslog hatte ich schon geschaut - leer, Größe 0... merkwürdig

Alte Gruppen gab es ja keine, das System war quasi jungfräulich...
 
negotiator schrieb:
Ein Blick in napp-it offenbarte folgendes:
Anhang anzeigen 505860
Zum Vergrößern anklicken....

Solaris/ OmniOS hat für eine bessere Windowskompatibilität des ZFS/kernelbasierten SMB Servers im Vergleich zum SAMBA SMB Server eine eigenständige Verwaltung von SMB Gruppen - zusätzlich zu den Unix Gruppen. Da ZFS ein Unix Dateisystem ist, müssen letzendlich jedoch Unix uid/gid beim Zugriff auf das Dateisystem beachtet werden.

Legt man jetzt SMB Gruppen an und löscht dann die zugrundeliegenden Unix Gruppen oder Unix User mit dieser Gruppe ohne vorher die SMB Gruppe zu löschen, so passiert genau das.

Ich würde nach Möglichkeit auf ein früheres BE zurückgehen bei dem die SMB Gruppen noch funktionierten. Wenn man noch weiß, welche User man angelegt hatte, kann man diese mit den alten UID/GID erneut anlegen. Dann funktioniert es auch wieder.
 
Zuletzt bearbeitet:
gea schrieb:
Solaris/ OmniOS hat für eine bessere Windowskompatibilität des ZFS/kernelbasierten SMB Servers im Vergleich zum SAMBA SMB Server eine eigenständige Verwaltung von SMB Gruppen - zusätzlich zu den Unix Gruppen. Da ZFS ein Unix Dateisystem ist, müssen letzendlich jedoch Unix uid/gid beim Zugriff auf das Dateisystem beachtet werden.
Zum Vergrößern anklicken....

Nur eine kleine Korrektur, Samba hat seit gut 10 Jahren ein eigenständiges Gruppenmanagement.
 
SAMBA hat viele Features die der kernelbasierte SMB Server nicht hat. Dessen Gruppen Integration geht dafür weiter.

- Windows SMB Gruppenmanagement direkt in einem Unix Betriebssystem
- Windows User und Gruppen sid werden als ZFS Attribute gespeichert. Damit muss man sich nach einem Backup/Restore auf einem Domänenserver keine Gedanken um Rechte beim Restore machen
- Lokale Windows Gruppen in lokalen Windows Gruppen per Windows sid.

Bei meinen Versuchen meine Windows Filer durch ZFS Filer zu ersetzen hat das mit SAMBA nicht so funktioniert wie ich mir das vorgestellt habe.
 
Zuletzt bearbeitet:
gea schrieb:
SAMBA hat viele Features die der kernelbasierte SMB Server nicht hat. Dessen Gruppen Integration geht dafür weiter.

- Windows SMB Gruppenmanagement direkt in einem Unix Betriebssystem
Zum Vergrößern anklicken....


Ich bin mir nicht ganz sicher was du damit meinst, aber die Nutzung von AD Gruppen innerhalb eines *nix Systems ist für die gängigen Systeme ein alter Hut?


gea schrieb:
- Windows User und Gruppen sid werden als ZFS Attribute gespeichert. Damit muss man sich nach einem Backup/Restore auf einem Domänenserver keine Gedanken um Rechte beim Restore machen
Zum Vergrößern anklicken....

Die AD ACL`s im Filesystem ist eigentlich auch kein Feature das 2020 extra noch herausgestrichen werden muss?


gea schrieb:
Bei meinen Versuchen meine Windows Filer durch ZFS Filer zu ersetzen hat das mit SAMBA nicht so funktioniert wie ich mir das vorgestellt habe.
Zum Vergrößern anklicken....

Naja, für simple Filer tut es ja noch. Aber selbst im MIttelstand setzen sich active/active SOFS Filer durch, gibts da schon "freie" Ansätze wie bei Samba?
 
Solarish kennt lokale SMB Gruppen zusätzlich zu den üblichen lokalen Unix Gruppen. Mitglieder dieser lokalen SMB Gruppen können weitere lokale oder AD SMB Gruppen sein. Es geht also nicht nur um AD. Das funktioniert auch im Workgroup Modus.

Die direkte Speicherung von Windows sid zusätzlich zu den Unix uid/gid auf einem Unix Dateisystem ist schon etwas besonderes. Nur ein Windows Dateisystem wie ntfs speichert ansonst sid als Sicherheitsbezug. Üblich im Linux/Unixbereich ist ansonst ein Mapping Unix uid/gid aus dem Dateisystem <-> Windows sid.
 
Moin zusammen, wir reden ja viel und oft über "wieviel RAM" braucht so ein ZFS Storage. Aber mich interessiert gerade die CPU-Leistung. Was meint Ihr (oder noch besser, wisst Ihr) was die CPU bringen muss?
Konkret frage ich weil ich etwas basteln will und folgendes hier liegen habe:
- Supermicro X11SSM-F mit 32GB ECC RAM
-Celeron G3900, 2x 2,8GHz, kein HT
- X520 von Intel
- paar Server SSD + NAS HDD

Der Spielgedanke ist damit einen reinen bare metal Filer zu bauen.
Schafft die Kiste damit halbwegs was Richtung 10GBit, oder ist die CPU eher zu schwach? Habe sonst nur VM´s mit 2-3 vCPU aus Xeons laufen und bisher normal nur so 4-5GHz Verbraucht in der Anzeige gesehen?
Gibt es da einen "Richtwert"?
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
533
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
309
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