[Sammelthread] ZFS Stammtisch

Bisher war ESXi das Mittel der Wahl. Kein anderer Virtualisierer bis auf XEN ist derart resourcenschonend. Ich selber werde solange wie möglich auf ESXi bleiben. Der einzige Nachteil von ESXi ist ja das Auslaufen der kostenlosen Version. Proxmox als Virtualisierer ist aber sicher eine Alternative und kann mit den genannten Einstellungen auch OmniOS/ Solaris virtualisieren.

Napp-it cs ist beta und ganz neu. Es ist eine client server Anwendung bei der man beliebige ZFS Server(gruppen) remote managen kann, also sowas wie Vsphere light für ZFS Storage. Es ist eine Ergänzung zum normalen napp-it auf Solaris oder für ZFS Server die keine adäquate GUI haben (Free-BSD, OSX, Proxmox, Windows) oder für gemischte ZFS Umgebungen (BSD, Illumos, OpenIndiana, OSX, Linux, SmartOS, Solaris, TrueNAS, Windows, Qnap oder Nexenta o.ä. muss noch getestet werden)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die Geschmacksrichtungen von ZFS

  1. natives ZFS in Solaris 11
    Dies ist das Unix, für das ZFS entwickelt wurde. Das ressourceneffizienteste und stabilste ZFS und wahrscheinlich das schnellste. In 20 Jahren habe ich nicht so viele Fehlerberichte bis hin zum Datenverlust gesehen wie unter Linux in ein paar Wochen. Natives ZFS ist weder kostenlos noch mit Open-ZFS kompatibel. Für nichtkommerzielle Nutzung/Tests kann man Solaris 11 cbe kostenlos herunterladen (aktuelle Solaris Beta)

  2. Open-ZFS 2.x
    Dies ist das ZFS in BSD, Linux, OSX und Windows. Aufgrund des Marktanteils von Linux findet die meiste Open-ZFS-Entwicklung jetzt hier statt, es handelt sich also um das Mainstream-ZFS. Vor ein paar Jahren war Illumos Upstream von Open-ZFS, jetzt ist Open-ZFS Upstream von Illumos. Hauptproblem bei Open-ZFS ist die Anzahl der Linux-Distributionen mit jeweils unterschiedlichen Open-ZFS-Release- oder Update-Richtlinien. Es ist keine schlechte Idee, den Issue-Tracker häufig zu überprüfen. Für einen Backup-Pool ist es eine gute Idee, Features zu deaktivieren, um weniger von Fehlern betroffen zu sein.

  3. Illumos ZFS
    Illumos ist der OpenSource-Zweig von Solaris. Es übernimmt alle Solaris-Vorteile wie Stabilität, Ressourceneffizienz, einfache Handhabung, das Solaris iSCSI Comstar-Projekt oder den in ZFS integrierten, kernelbasierten SMB-Server mit einer perfekten Integration von Windows NTFS ACL. Illumos ist kompatibel zu Open-ZFS 2.x, aber unabhängig von Open-ZFS 2.x. Es verwendet jetzt Open-ZFS als Upstream, um nach zusätzlichen Stabilitätsprüfungen neuere ZFS-Funktionen zu integrieren, was es stabiler als Open-ZFS macht. Der Issue-Tracker von Illumos zeigt eine ähnlich geringe Anzahl kritischer Probleme wie Solaris.

    Die Distributionen weichen nicht von Illumos ab, bieten aber teils Extras (nicht so unterschiedlich wie die vielen Linux-Distributionen: NexentaStor (Sorage Appliance), OmniOS (Storagebetriebssystem mit stable /long term stable), OpenIndiana (Nachfolger von OpenSolaris) oder SmartOS (Virtualizer-Betriebssystem, Konkurrent von ESXi oder Proxmox)
 
Wie ist der aktuelle Stand der Lizenzdebatte bezüglich der ZFS-Integration in den Linux Kernel?

Linus war ja bisher ziemlich abgeneigt weil die ursprünglichen Lizenzen nicht kompatibel zu GPL sind/waren. Aber die Entwicklung von openzfs scheint ja doch immer mehr fahrt aufzunehmen. Hat sich da der Wind in der Entwickler community mittlerweile gedreht?

Man hört ja auch oftmals die Meinung, dass ZFS ohne Kernelimplentierung immer nur ein Wurmfortsatz bleiben wird, der keinen Durchbruch im Enterpriseumfeld schaffen wird. Die ganzen Tools die man rund um das Thema Dateisystem kennt können in der Regel ja auch nix mit ZFS anfangen.

Von den großen Distris hat es ja auch nur Ubuntu so richtig integriert.
 
Man hört ja auch oftmals die Meinung, dass ZFS ohne Kernelimplentierung immer nur ein Wurmfortsatz bleiben wird, der keinen Durchbruch im Enterpriseumfeld schaffen wird. Die ganzen Tools die man rund um das Thema Dateisystem kennt können in der Regel ja auch nix mit ZFS anfangen.
Es hängt halt an den Distributionen wie aktuell Open-ZFS ist und wie gut die Updatepolicy ist bzw wie schnell auf Bugs reagiert wird und da sind deutliche Unterschiede. Ist halt die gleiche Ebene wie die schnelle Integration von Fehlerbehebungen in Open-SSL oder Diensten wie SMB um die sich auch die Distributionen kümmern müssen. Da brauchts ja auch keine Kernelintegration und trotzdem werden die kommerziell genutzt.

Zu den Tools.
Von Bugs, fehlendem ECC, menscjlichen Fehlern oder fehlerhafter Hardware abgesehen, wurde ZFS so konzipiert dass Datenfehler oder Verlust "per Design" vermieden werden (Copy on Write), sofort entdeckt (Prüfsummen) und umgehend repariert werden (selbstheilendes Dateisystem, benötigt Redundanz). Menschliche Fehler oder Virenattacken kann man mit readonly Snaps begrenzen.

Die üblichen Tools wie fschk oder chkdsk sehen dagegen alt aus. Die können allenfalls begrenzt Strukturfehler finden und beheben. Es gibt allenfalls Unterschiede wenn man mangels Backup Daten einer defekten Festplatte wiederherstellen will. Da ist das Angebot an Firmen die ZFS geringer die das anbieten. Da ZFS aber fast immer im Raid läuft ist eine Wiederherstellung immer aufwendiger da man dann nicht nur die defekte Platte braucht sondern auch alle anderen oder lediglich versuchen kann die Platte zu reparieren und zu hoffen dass das Raid dann noch sauber tut.

Sollte aber nie passieren denn wir machen ja alle Backup, entweder regelmäßig auf einen Backuppool idealerweise an einem anderen Standort oder Disasterbackup auf einen externen Datenträger (kann auch eine USB Platte sein) den man nur zum Backup ansteckt.
 
Nutzt jemand einen Ultra mini Server für ZFS?
Raspberry oder ähnliches mit 2-4GB RAM (Arm oder Intel) mit Linux, ZFS und Perl installiert, Platten auch gern per USB.

Würde mich interessieren ob man bei denen ZFS mit napp-it cs remote per web-ui administrieren kann.
Zum Testen müsste man lediglich cs_server da drauf kopieren und starten.
 
Release Notes for OmniOS v11 r151048
r151048w (2024-04-11)

Weekly release for w/c 8th of April 2024.

This update requires a reboot

Security Fixes

Other Changes
  • A panic in ZFS in conjunction with SMB2 has been fixed.
  • A bug in readline that could cause crashes with unknown locales has beenresolved.
  • The system PCI and USB hardware databases have been updated.
  • For Intel CPUs which are not vulnerable to Post-barrier Return Stack Buffer (PBRSB) the kernel no longer spends time mitigating thi
 
Nutzt jemand einen Ultra mini Server für ZFS?
Raspberry oder ähnliches mit 2-4GB RAM (Arm oder Intel) mit Linux, ZFS und Perl installiert, Platten auch gern per USB.

Verschlüsselte USB-Platte an einem Pi4 2GB ausprobiert, via WLAN und LAN und lokal, das kalte Kotzen bekommen, Projekt abgeblasen und beim großen 19"-Filer auch für den Alltagsgebrauch geblieben.
Dafür dem gerade einen 2,5Gbit-Adapter spendiert, damit der Laptop, dem ich schlecht einfach ne 10G-Karte nachrüsten kann, auch ein wenig schneller mit ihm kann. Für 2x 9€ ein absoluter No-Brainer.
 
Bei hohen Anforderungen wirds schnell teuer, laut und nicht sonderlich energieeffizient.
Bei ultra low power, low cost und low RAM wirds dagen schnell ultra langsam. ZFS mit Verschlüssellung oder ähnliches mit 2 GB RAM sollte man nicht mal andenken.

Man sollte sich eher in der Mitte bewegen, nicht in den extremen. Etwas schneller als ein Pi ist ein Atom N100 und auch noch sparsam und bezahlbar. Auf der anderen Seite des Spektrums ist vielleicht ein Vierkerner mit 32GB RAM und SAS/Sata und einem special vdev aus einem Optane 1600 Mirror ausreichend statt eine 32 Kern Lösung mit 128GB RAM und NVMe only.

Bei kritischen Daten würde ich als unteres Ende der Fahnenstange ein kleines AMD oder Intel System mit ECC RAM (richtiges ECC und nicht nur DDR 5) sehen.
 
Hehe ja auf ARM mit 2 GB läuft ZFS zwar aber naja :d das ist halt mehr was man so mal aus Spass macht um zu schauen ob es überhaupt geht

ZFS Crypt braucht sowieso AVX - ich meine sogar AVX2 - AES-NI etc allein reicht da nicht für die HW Beschleunigung - in Software geht es natürlich trotzdem.
 
Gibt es bei ZFS Nachteile bei bestimmten Anzahl(en) von HDDs in einem Pool? Z.B. 7 HDDs?

Ich komme darauf, weil bei diesem RAIDZ Calculator ein Punkt "Speed gain - Up to X read speed, no write speed gain"
Was hat es damit auf sich?
 
Wenn man compress deaktiviert, sollte man idealerweise 2^n Datenplatten haben.
Da man aber heutzutage Compress nahezu immer aktiviert, ist das obsolete.
Ob der Raid Calculator das meint, kann ich aber mangels Info dazu nicht sagen.


ps
Platten im Pool ist egal, es geht um Platten pro Raid-Z vdev.
 
Zuletzt bearbeitet:
Hi gea,

die Ova template with OmniOS 151046 LTS/ up from ESXi 6.7 Datei wirft beim vcenter content lib import folgenden Fehler:
Der Import des Bibliothekselements f7ed82a9-8b57-4f7d-b7e3-d3c231f16e5a ist fehlgeschlagen. Grund: Error transferring local file omnios46.ovf. Reason: Checksum mismatch for endpoint null in item omnios46.ovf: [actual checksum = e46a00fe4f6132d7c3aac640b1cda2cdefe0ff358841d7726656743f65195225; expected checksum = c17e9ebe1d8f19caa0bcb84b3d4339235dfc0ca444d8772e8186a1639d38db36].

(habe schon 2x runtergeladen - es bleibt dabei)

Könntest Du bitte 'mal nachschauen ? Würde gerne dieses Wochenende meinen Backup-Server neu aufsetzen...
Danke !
 
Hi gea,

die Ova template with OmniOS 151046 LTS/ up from ESXi 6.7 Datei wirft beim vcenter content lib import folgenden Fehler:
Der Import des Bibliothekselements f7ed82a9-8b57-4f7d-b7e3-d3c231f16e5a ist fehlgeschlagen. Grund: Error transferring local file omnios46.ovf. Reason: Checksum mismatch for endpoint null in item omnios46.ovf: [actual checksum = e46a00fe4f6132d7c3aac640b1cda2cdefe0ff358841d7726656743f65195225; expected checksum = c17e9ebe1d8f19caa0bcb84b3d4339235dfc0ca444d8772e8186a1639d38db36].

(habe schon 2x runtergeladen - es bleibt dabei)

Könntest Du bitte 'mal nachschauen ? Würde gerne dieses Wochenende meinen Backup-Server neu aufsetzen...
Danke !
Ich habe es gerade unter ESXi 8.0.0 probiert (lokal, ohne Vsphere). Ich konnte die ova da bereitstellen.

Warum das hier nicht klappt, hmm

Workarounds
- lokal bereitstellen
- ova mit 7Zip öffnen und omnios46.mf löschen (da stehen die Checksums drin) oder editieren und Soll Checksum eintragen

- OmniOS ganz normal via iso installieren. Die Open-VM Tools sind in OmniOS vorinstalliert.
Dauert auch nur ein paar Minuten, um das aufzusetzen und napp-it per wget Installer hinzuzufügen.
Beitrag automatisch zusammengeführt:

BTW
Wer nutzt SmartOS?

Für den der SmartOS nicht kennt.
Das ist die minimalistischste Illumos Distribution (OpenSource Solaris). Sie läuft ähnlich wie ESXi früher mal als die Welt noch in Ordnung war, nach dem Start komplett im Ram. ZFS Systemordner werden dabei wiederhergestellt oder zeigen wie /opt oder /var/ auf den Datenpool. Ein Reboot und man hat ein sauberes System. Ein Update gibts nicht, man bootet ein anderes/neueres OS.

Schwerpunkt von SmartOS ist Virtualisierung. Da ist es Konkurrent zu ESXi und Proxmox und kann KVM, Bhyve, Linux LX Container, und Solaris Zonen.

Ich beschäftige mich gerade mit SmartOS und teste inwieweit man das nutzen kann, auch als Storageserver "on a stick", Die nötigen Vorbereitungen um SmartOS mit napp-it cs zu managen und als FS Server zu managen sind trivial

install os
pkgin update
pkgin install perl
pkgin install mc
pkgin install smartmontools
ssh as root (Putty, WinSCP)

Mehr Probleme macht SMB. SmartOS möchte das in einer Zone machen, ich aber nicht. Workaround/Discuss:
 
Zuletzt bearbeitet:
Ich hatte per zfs send pool/dataset@snap | ssh IP zfs recv pool/dataset die Daten gesendet (TrueNAS 13.x). Leder ist der Datenstrom abgebrochen (bei über 70% 😭). Es wurde nur noch der Pool und eine Belegung im Pool angezeigt, aber das Dataset war weg. Ich hatte ein Resume versucht, leider war der Tocken korrupt. Wie kann ich pool senden mit Resume-Funktion?
Mit der -s bei recv wurde das Dataset immerhin nicht gelöscht, nur Resume habe ich bisher nicht geschafft. :cry:
 
Auch wenn Dir das jetzt bei Zfs send etc nicht hilft xD ich nutze rsync auch bei zfs <> zfs - was eben den Vorteil hat Quell und Zielfilesystem sind egal, weill ich ein anderes läuft alles wie bisher - und resume funktioniert auch recht gut
 
Auch wenn Dir das jetzt bei Zfs send etc nicht hilft xD ich nutze rsync auch bei zfs <> zfs - was eben den Vorteil hat Quell und Zielfilesystem sind egal, weill ich ein anderes läuft alles wie bisher - und resume funktioniert auch recht gut
Wenn es nochmal abbricht werde ich wohl auf rsync wechseln. Allerdings müsste ich mich erst einlesen :LOL:
 
Ich komme darauf, weil bei diesem RAIDZ Calculator ein Punkt "Speed gain - Up to X read speed, no write speed gain"
Vergiss den Calc, der ist imho crap.
Hatte die Diskussion erst mit einem IT-Kumpel.

Mit LZ4 kann ich zumindest mit ~500 mb/s auf mein 4x HC560 Z1 schreiben (welche allein so 250 mb/s machen), mehr gibt das Quelllaufwerk (SATA SSD 870 Evo 4tb) nicht her.
 
zumindest meine einfache rsync daemon conf datei kann ich geben - die tut xD als daemon dann ohne ssh lokal - das maxt auch problemlos 10 Gbit aus.

rsync auf dem client nutze ich glaub nur mit "--progress -avx --size-only" (+ bei mir chown auf nobody:nogroup)

glaube rsync wird oft genutzt zum Server spiegeln an z.b. unis etc das glaub echt extrem gut erprobt.
 
Openindiana 2024.04 ist verfügbar
OpenIndiana ist ein Solaris Fork und quasi Illumos pur mit Mate Gui für Server oder Desktop use.
 

Beim Drüberlesen ist mir ashift validation aufgefallen.
Ashift ist ein vdev und kein pool propery. Wenn man allerdings unterschiedliche ashift im pool hat ist ein vdev remove nicht möglich. Bisher war der work around z.B. grundsätzlich ashift=12 einzustellen.
 
Unlike Oracle Solaris with native ZFS, OmniOS stable is compatible with Open-ZFS but with its own dedicated software repositories per stable/lts release. This means that a simple 'pkg update' gives the newest state of the installed OmniOS release and not a newer release.

To update to a newer release, you must switch the publisher setting to the newer release.
A 'pkg update' initiates then a release update.

An update to 151050 stable is possible from 151046 LTS.
To update an earlier release, you must update in steps over the LTS versions.

Note that r151038 is now end-of-life. You should upgrade to r151046 then r151050 to stay on a supported track. r151046 is an LTS release with support until May 2026, and r151050 is a stable release with support until May 2025.

For anyone who tracks LTS releases, the previous LTS - r151038 - is nowend-of-life. You should upgrade to r151046 for continued LTS support.
 
Seit dem Update auf omnios r50 spamt mich das System mit folgender Fehlermeldung zu:

Betreff: Cron <root@omniosce>
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 45. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 50. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 51. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 53. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 56. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 57. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 58. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 105. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 416. Old package separator "'" deprecated at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 426.
Das dürfte ein Thema von napp-it 22.03c sein. Wie könnte man das abstellen? (Bin nicht sehr Perl bewandert)

Zudem: manche emails an root will mir das System (dma als MTA) immer an root@... zustellen, egal was ich in /etc/aliases und /etc/dma/aliases einstelle (dort habe ich natürlich "root: email@adresse.de" eingestellt).

Die Email wird ganz normal an Gmail als smarthost weitergeleitet, dann aber natürlich von der Zieladresse xyz@gmx.de abgelehnt, da der envelope eben leider an root@ adressiert ist. Tipps?
 
Seit dem Update auf omnios r50 spamt mich das System mit folgender Fehlermeldung zu:



Das dürfte ein Thema von napp-it 22.03c sein. Wie könnte man das abstellen? (Bin nicht sehr Perl bewandert)

Zudem: manche emails an root will mir das System (dma als MTA) immer an root@... zustellen, egal was ich in /etc/aliases und /etc/dma/aliases einstelle (dort habe ich natürlich "root: email@adresse.de" eingestellt).

Die Email wird ganz normal an Gmail als smarthost weitergeleitet, dann aber natürlich von der Zieladresse xyz@gmx.de abgelehnt, da der envelope eben leider an root@ adressiert ist. Tipps?

Eine Nebenwirkung des neuen Perl Releases in 151050.
Behoben in allen aktuellen Versionen: About > Update mit Download sollte das Problem beheben

Zum Mailprolem kann ich nichts sagen
Beitrag automatisch zusammengeführt:

Mit welchen Mitteln lässt sich am einfachsten ein Backup automatisieren ?
Was soll denn wohin gesichert werden?
 
Von meinem kleinen Homeserver (auf Gigabyte mc12 le0 Basis) auf eine externe Festplatte (muss noch angeschafft werden). Einmal die Woche würde locker ausreichen. Einmal die Systemplatte und einmal die Datenablage.
Die Software die auf dem Homeserver laufen wird ist noch offen. Ich tendiere zu truenas. Und überlege ob das reicht oder für so Spielereien wie automatische Backups proxmox mit einer truenas vm mehr Sinn macht?
 
Im Prinzip, einfach eine externe Platte mit einem ZFS Pool auf einer einzelnen Platte anstecken (SAS,Sata,USB),
dann Pool importieren und ein Replikationsjob manuell starten.

Ob man dazu ein eigenständiges Script oder die Replikationsfunktion von napp-it oder TrueNAS nimmt, ist egal
Anschließend (ganz wichtig) den Pool exportieren und die Platte dann erst abstecken.

Bei mehreren Backuplatten, den Pool darauf unterschiedlich benennen und ein Replikationsjob pro Backupplatte erstellen.

Bei einem kleinen Server beachten
Proxmox hätte gerne 4-8GB RAM plus RAM für die sonstigen VMs, dazu die TrueNAS VM mit 8-16GB und dazu den RAM den man gerne hätte damit ZFS schnell ist. Macht erst ab 32GB RAM Sinn und da hat ZFS noch nicht üppig viel davon.

Man kann auch SAMBA direkt auf Proxmox installieren und sich die Storage VM sparen. Der SAMBA SMB Server bei TrueNAS ist exakt das gleiche SAMBA wie unter Proxmox.

Ein Solaris basiertes System wie OmniOS ist etwas speichereffizienter, der da in ZFS eingebaute SMB Server dazu erheblich einfacher zu konfigurieren als SAMBA (keine smb.conf, alles in ZFS oder in ACL hinterlegt.
 
Zuletzt bearbeitet:
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