[Sammelthread] ZFS Stammtisch

[Luckysh0t]

Ich habe das ganze erst hinter mir. Ich hatte die Freigaben auf dem anderen Server gemountet und dann über IPMI/ Monitor per copy die Daten rüber gezogen. Allerdings sollte man doppelt prüfen ob die Dateisysteme auch da sind, meine sind verschlüsselt, bei einem hatte ich das vergessen und die Daten waren halt dann erstmal woanders xD.

Snapshots, Versionierung hast du auch.
Ist halt nur etwas langsamer als Solaris bei Netzwerktraffic ( ca 10-20 MB/s bei einer Gbit Verbindung)- aber das ist wohl leider so.

 

[Wesumat]

Hätte jetzt nicht gedacht, dass einen Unterschied bei der Netzwerkperformance gibt, zumal unter Solaris gefühlt schon nicht immer volle 1Gbit Auslastung gegeben war, aber smb Multichannel unterstützt OmniOS auch?

 

[pwnbert]

In Solaris soll SMB besser "gemacht" sein, vom Mitlesen jetzt, selbst hab ichs nie verwendet.
Ich halte diese +/-10% eigentlich für unwichtig, solang man das OS, das man nutzt gut bedienen kann, und es tut, was es soll...

Obs jetzt 100mb/s oder 110mb/s sind, machts ja echt nicht fett.

 

[gea]

Guten Morgen zusammen,

ich hege mich mit dem Gedanken meinen filer von Solaris 11.4CBE auf OmniOS umzustellen. Hintergrund ist ein eh geplanter Hardwarewechsel. Das die ZFS Varianten nicht kompatibel sind ist mir bekannt, frage mich jetzt was im späteren Verlauf der einfachste und sinnvollste Weg der Datenmigration wäre. Läuf es auf einen schnöden bspws. rsync vom alten auf den neuen pool heraus oder gibt es noch irgendeinen Kniff den ich vielleicht nicht im Auge habe?

Am Besten unter OmniOS einen strukturell identischen Pool anlegen (Pool, ZFS Dateisysteme und ZFS Volumes). Dann die Daten umkopieren (z.B. via rsync oder besser robocopy via SMB weil damit ntfs ACL erhalten bleiben)

Zudem würde mich noch interessieren ob man mit dem Wechsel irgendwas wesentliches im Vergleich zu Solaris „verliert“. Im Hinblick auf smb und nfs Version und features? Bietet OmniOs da ähnliches und features wie vorherige Versionen beim Verwenden von Speicherplatz unter Microsoft Systemen?

Dir Features von native ZFS unter Solaris und OpenZFS mit OmniOS sind featuremäßig unterschiedlich und inkompatibel. ZFS Snaps als Windows "vorherige Version", ohne dass man etwas beachten oder konfigurieren muss können beide wie auch die Unterstützung von ntfs artigen ACL mit Windows SID statt uid/gid als security reference.

Nur Solaris SMB kann multichannel und ist auch ansonst immer etwas schneller als OmniOS SMB. SMB Direkt/RDMA können beide nicht (geht eh nur mit Windows Server sauber)

 

[Wesumat]

Am Besten unter OmniOS einen strukturell identischen Pool anlegen (Pool, ZFS Dateisysteme und ZFS Volumes). Dann die Daten umkopieren (z.B. via rsync oder besser robocopy via SMB weil damit ntfs ACL erhalten bleiben)

Ein guter Hinweis - Danke 👍

Wie macht man es nachher am geschicktesten die napp-it Lizenzen von Alt- zu Neu-System umzuziehen?

 

[gea]

Wie macht man es nachher am geschicktesten die napp-it Lizenzen von Alt- zu Neu-System umzuziehen?

Key neu eingeben oder /var/web-gui/_log/appliance.log umkopieren (WinSCP)
Man kann auch den kompletten /var/web-gui/* umkopieren, dann hat man auch eventuelle Jobs dabei

 

[sch4kal]

frage mich jetzt was im späteren Verlauf der einfachste und sinnvollste Weg der Datenmigration wäre. Läuf es auf einen schnöden bspws. rsync vom alten auf den neuen pool heraus oder gibt es noch irgendeinen Kniff den ich vielleicht nicht im Auge habe?

Habs bei mir gerade durch: ging via rsync super, musste vorher bei OmniOS aber zuerst die Berechtigungen auf dem Dataset das ich kopieren wollte, anpassen, vorallem das Recht den Owner zu wechseln. Wenn ichs mir recht überlege und geas Antwort sehe, wäre robocopy da wohl vielleicht einfacher gewesen. Hab nach dem Kopieren dann halt mit seinen tollen Pro Extensions wieder meine alten Berechtigungen drübergebügelt.


Wenn ich einen auf OmniOS erstellten OpenZFS Pool exportiere und zB im aktuellen TrueNAS Scale importiere, dann dürfte der mir ja nicht automatisch die Pool Version Updaten oder irgendwelche Featureflags automatisch hinzufügen, oder ? Wollte den Pool temporär wegen einigen Plugins via TrueNAS managen und später wieder auf OmniOS damit wechseln.

 

[gea]

Ein Pool upgrade geht nie automatisch sondern immer manuell on demand.
Wenn man allerdings ein besonderes Feature aktiviert das OmniOS nicht kann, z.B. Raid-Z Expansion, dann kann OmniOS (wie auch ein Linux das dieses Feature noch nicht kann) den Pool nicht mehr importieren.

 

[sch4kal]

Okay, dann notiere ich mir die Features, die OmniOS beim Erstellen des Pools gesetzt hat und vergleiche mal mit denen von TrueNAS. Mein Vorhaben sollte ja dann safe sein.

 

[gea]

Was soll denn in TN verändert werden?

Ein einfacher Pool Import/Export mit Lesen der Daten ohne Ändern einer ZFS Eigenschaft zwischen verschiedenen Betriebssystemen oder Distributionen ist unkritisch wenn die aktivierten Features jeweils unterstützt sind. Wenn man etwas auf dem Pool ändert, muss man prüfen ob das beiderseits so unterstützt wird (recsize, compress, vdev etc).

 

[sch4kal]

Ich hab keine Ahnung was deren Middleware da alles im Hintergrund rum fummelt, better safe than sorry. In der letzten Version davon die ich getestet hatte, wurde bei Installation der Apps funktionalität ein Kubernetes im Hintergrund hochgezogen, was deutlich im höheren „Idle“ Stromverbrauch bemerkbar war. Aber ich probier es einfach aus, hab ja Backups.