[Sammelthread] ZFS Stammtisch

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.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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?
 
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.
 
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)
 
Zuletzt bearbeitet:
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?
 
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
 
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.
 
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.
 
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.
 
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).
 
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.
 
@gea

Gibt es unter einem aktuellen OmniOS (r151052f) Probleme beim Einrichten von TLS fürs Mailing unter napp-it oder übersehe ich eventuell
einfach etwas in der beschriebenen TLS-Anleitung auf der napp-it Homepage?

Beim Schritt für Net::SMTP::TLS scheitert er mit untenstehender Fehlermeldung von HTTP::Tiny.
Gibt's da irgendeinen eleganteren Kniff um das zu umgehen?

Code:
cpan[1]> notest install Net::SMTP::TLS
Reading '/root/.cpan/Metadata'
  Database was generated on Sun, 29 Dec 2024 09:17:02 GMT
Running install for module 'Net::SMTP::TLS'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/A/AW/AWESTHOLM/Net-SMTP-TLS-0.12.tar.gz
HTTP::Tiny failed with an internal error: Couldn't find a CA bundle with which to verify the SSL certificate.
Try installing Mozilla::CA from CPAN

Giving up on '/root/.cpan/sources/authors/id/A/AW/AWESTHOLM/Net-SMTP-TLS-0.12.tar.gz'
Note: Current database in memory was generated on Sun, 29 Dec 2024 09:17:02 GMT

cpan[2]> install Mozilla::CA
Running install for module 'Mozilla::CA'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/L/LW/LWP/Mozilla-CA-20240924.tar.gz
HTTP::Tiny failed with an internal error: Couldn't find a CA bundle with which to verify the SSL certificate.
Try installing Mozilla::CA from CPAN

Giving up on '/root/.cpan/sources/authors/id/L/LW/LWP/Mozilla-CA-20240924.tar.gz'
Note: Current database in memory was generated on Sun, 29 Dec 2024 09:17:02 GMT

cpan[3]>

Umschiffen kann man das Problem durch einen manuellen Download Mozilla::CA Datei,
welche sich ja auch nicht installieren lässt, siehe oben.

Code:
wget https://www.cpan.org/modules/by-module/Mozilla/LWP/Mozilla-CA-20240924.tar.gz in /root/.cpan/sources/authors/id/L/LW/LWP/

Danach lässt das Mozilla::CA und anschliessend auch Net:SMTP::TLS dann installieren.

Dann ist mir noch aufgefallen, dass die Netzwerkstatistik keinerlei Daten anzeigt? Sieht so aus,
als würde in nicstat selbst schon nichts hereinlaufen. Eventuell 'ne Idee dazu, was das verursachen
könnte?

nappit_nicstats.PNG
 
Zuletzt bearbeitet:
Zertifikatsfehler liegen häufig am falschen Systemdatum (Datum in der Vergangenheit).
151052 benötigt außerdem ein ganz aktuelles napp-it (About > Update, neu herunterladen).
 
Hi gea,

ist sogar die aktuellste 24dev, aber sollte ja eigentlich nicht zwigend entscheidend sein, weil die vorbereitenden Schritte
auf dem System ja bereits scheitern. Vorgegangen wie hier beschrieben (https://www.napp-it.org/downloads/tls.html).

Habe testweise noch mal ein System in einer VM auf die aktuellste r151052 zurückgesetzt, napp-it erstmalig via wget
Aufruf installiert. Danach napp-it GUI über die Update Funktionalität auf den neusten möglichen Stand gebracht (24.dev se nov 10.2024).

Systemdatum ist ebenfalls i.O.

Dann erstmalig nach der TLS-Anleitung vorgegangen um CPAN und die nötige Module zu installieren. Bleibt an der gleichen Stelle
wieder "stecken". Er scheitert ja, weil er keine CA findet um den das ssl Zertifikat beim Download für das Modul Net::SMTP::TLS zu
prüfen. Zumindestens auf einem neuen clean install System unter r151052f führt es dann zu den oben aufgeführten Problemen.

Code:
...
Running install for module 'Net::SMTP::TLS'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/A/AW/AWESTHOLM/Net-SMTP-TLS-0.12.tar.gz
HTTP::Tiny failed with an internal error: Couldn't find a CA bundle with which to verify the SSL certificate.
Try installing Mozilla::CA from CPAN
...

/EDIT
Die ersten beiden der drei Module werden noch per wget geladen, deswegen gibt es dort offenbar keine Probleme,
beim Net::SMTP::TLS versucht er es aber stattdessen mittels HTTP:Tiny

notest install Net::SSLeay
Code:
Running install for module 'Net::SSLeay'
Trying with
    /usr/bin/wget -O "/root/.cpan/sources/authors/id/C/CH/CHRISN/Net-SSLeay-1.94.tar.gz.tmp1914"
to get
    https://cpan.org/authors/id/C/CH/CHRISN/Net-SSLeay-1.94.tar.gz
...

notest install IO::Socket::SSL
Code:
Running install for module 'IO::Socket::SSL'

Trying with
    /usr/bin/wget -O "/root/.cpan/sources/authors/id/S/SU/SULLR/IO-Socket-SSL-2.089.tar.gz.tmp1914"
to get
    https://cpan.org/authors/id/S/SU/SULLR/IO-Socket-SSL-2.089.tar.gz
...

notest install Net::SMTP::TLS
Code:
Running install for module 'Net::SMTP::TLS'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/A/AW/AWESTHOLM/Net-SMTP-TLS-0.12.tar.gz
HTTP::Tiny failed with an internal error: Couldn't find a CA bundle with which to verify the SSL certificate.
Try installing Mozilla::CA from CPAN
...
 
Zuletzt bearbeitet:
Schön, dass man es nachvollziehen - Danke fürs Nachstellen und ergänzen der Dokumentation. (y)

Hast du eventuell noch eine Idee zu der leeren Netzwerkstatistik in der Systemübersicht (s.o.)? Kann mir da
noch keinen Reim drauf machen.
 
Schön, dass man es nachvollziehen - Danke fürs Nachstellen und ergänzen der Dokumentation. (y)

Hast du eventuell noch eine Idee zu der leeren Netzwerkstatistik in der Systemübersicht (s.o.)? Kann mir da
noch keinen Reim drauf machen.

Ist "Monitoring" denn aktiv (Topmenü mon)?
Bei einem Update werden alle Hintergrunddienste deaktiviert
 
Ja, das Monitoring ist aktiv, die restliche Werte werden ja angezeigt.


nappit_nicstats.PNG


Während eines laufenden iperf3 tests sieht das schon komisch aus, daher vermutlich auch die leere
Grafik.

root@NAS01:~# nicstat -i oce0 -M 1
Time Int rMbps wMbps rPk/s wPk/s rAvs wAvs %Util Sat
20:50:40 oce0 0.00 0.00 0.08 0.05 6425.3 7523.7 0.00 0.00
20:50:41 oce0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
20:50:42 oce0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
20:50:43 oce0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
20:50:44 oce0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
20:50:45 oce0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
 
Habe jetzt noch etliches rumprobiert, werde aber einfach nicht schlau aus dem Verhalten von nicstat.

Sobald man den zusätzlichen Parameter -t verwendet, bekomme ich hier auch auch traffic zu sehen, ohne dümpelt
alles mehr oder weniger bei 0 rum bezüglich in/out Traffic des Interfaces.

Mit welchen Optionen greift der Background Agent den die Werte ab, damit sie in der napp-it gui dann aufbereitet
werden können?
nappit_nicstats.PNG



Gegebenenfalls muss ich noch mal eine andere Netzwerkkarte testen, obwohl ich mir da jetzt nicht wirklich einen Zusammenhang vorstellen kann,
da sie ja ohne Probleme läuft - wenngleich auch die Performance noch Luft nach oben hätte.
 
nicstat -Mn 2
/var/web-gui/data/napp-it/zfsos/_lib/illumos/agents/agent_stat.pl line 895
 
Aktuell kämpfe ich noch mit dem 9600-24i: An dieser Stelle DANKE FÜR NICHTS Broadcom, dass ich manuell per udev regel TRIM aktivieren muss (SSD Micron 5300 PRO SATA, hängt direkt per direct attach backplane am Controller. Data Set Management TRIM supported (limit 8 blocks) + Deterministic read ZEROs after TRIM. Glaube dem Controller passt nicht dass Write Same nicht supported ist :fire:
An dieser Stelle nochmal: Danke für nichts, Broadcom.

Nachdem da ewig ein Tech Support Case lief, hab ich folgende Antwort bekommen:

Hello Robin,

Engineering just got back to me and said that "Unmap/Trim is supported only for SAS/NVMe "

It looks like you are using SATA SSD's:
"Controller is used with 24 disks Micron 5300 PRO (Firmware D3MU001) on a direct attach backplane (Supermicro BPN-SAS3-216A-N4)"

Thank you and let me know if you have any questions,
Storage and Ethernet NIC Technical Support
Broadcom Inc.
Joseph

Also meine Erwartungen waren wirklich niedrig, aber trotzdem hat Broadcom es mal wieder geschafft zu enttäuschen.

TRIM nur auf SAS / NVMe? Bitte was?
 
1. Trim kann man auf Ebene der Einzelplatten unter Kontrolle eines Controllers oder von ZFS haben.
2. Trim im Raid geht nur auf OS/ZFS Ebene.

Der BroadCom Kommentar kann sich also nur auf 1. beziehen. Hat man ein ZFS Raid, geht eh nur Fall 2.
ZFS Trim geht aber auch nicht mit jeder Hardware. Der Befehl zpool status -t sollte anzeigen ob trim unter ZFS geht.

Code:
PS C:\Users\me> zpool status -t
  pool: tank
 state: ONLINE
config:

        NAME              STATE     READ WRITE CKSUM
        tank              ONLINE       0     0     0
          physicaldrive3  ONLINE       0     0     0  (trim unsupported)

errors: No known data errors
 
ZFS Trim geht aber auch nicht mit jeder Hardware. Der Befehl zpool status -t sollte anzeigen ob trim unter ZFS geht.
Und genau das ist der Punkt: NUR mit DIESEM Controller / "HBA" (das Konzept gibt es ab der 9500er Serie nicht mehr) (Broadcom 9600-24i) behauptet ZFS, dass TRIM nicht möglich wäre.

Das ist allerdings nicht zutreffend, denn die SSDs (Micron 5300 PRO) können definitiv TRIM. Das Problem liegt also 100% beim Controller und seiner Firmware / Treiber. Mit anderen HBAs (bspw. 9500er Serie, 9300er Serie) kein Problem und TRIM wird ohne Workarounds als supported angezeigt.
 
blöd sowas.
Den 9600 sollte man dann wohl besser vermeiden wenn man kein SAS nehmen kann.

(Wobei ich 12G SAS generell den Vorzug vor 6G Sata bei SSD geben würde)
 
(Wobei ich 12G SAS generell den Vorzug vor 6G Sata bei SSD geben würde)
Absolut, es ist aber wie immer ein Dilemma.

SATA SSDs: Enterprise Modelle günstig für gutes Geld verfügbar.
SAS SSDs: Eher weniger gebraucht verfügbar und teuer.
NVMe SSDs: Enterprise Modelle günstig für gutes Geld verfügbar, ABER Problematisch bzgl. Backplanes und zu wenig Lanes, dank Broadcom sind PCIe 4.0 Switch-Karten auch unbezahlbar verglichen mit PCIe 3.0.
 
Gegebenenfalls muss ich noch mal eine andere Netzwerkkarte testen, obwohl ich mir da jetzt nicht wirklich einen Zusammenhang vorstellen kann,
da sie ja ohne Probleme läuft - wenngleich auch die Performance noch Luft nach oben hätte.

Mit 'ner Intel X520 läuft es ohne Probleme. Verstehen muss man es nicht.
 
Ip Päckchen ein/auspacken und Traffic Statistik bereitstellen sind unabhängig voneinander.
 
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