[Sammelthread] ZFS Stammtisch

[gea]

Nein, keine weiteren Logs,
auto.pl macht ja auch nichts ausser alle Jobs einzulesen um zu schauen ob die im Hintergrund gestartet werden sollen. Ich habe Installationen wo das auch mit über 50 gleichzeitig gestarteten Jobs keine Probleme macht.

Der Job lief ja am Samstag davor. Gab es zwischenzeitlich etwas auffälliges, Umstellung der Sprache etc? Ansonsten mal schauen ob es heute läuft.

 

[rigel]

Die Mail ist heute wieder nicht angekommen. Ich habe daraufhin in napp-it den Punkt "TLS-test" ausgeführt und erhalte:

Connect failed :IO::Socket::INET: connect: timeout at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 80.

Meine Zugangsdaten sind korrekt, auch die SMTP-Serveradresse hat sich nicht verändert. Das einzige ist, dass mein Mail-Anbieter Port 465 empfiehlt, napp-it aber offenbar 587 verwendet. Evtl. hat mein Anbieter Port 587 inzwischen blockiert. Kann ich den Port irgendwo konfigurieren?

 

[gea]

Das ist wohl die Ursache. In napp-it kann man das aber nicht einstellen. Die zugrunde liegenden TLS Module von Perl stellen den für TLS vorgesehenen Port 587 fest ein. Ein Ändern des Ports in napp-it bringt nichts, habe ich getestet.

Choosing an SMTP Port: Ports 25, 465, or 587 | Mailgun

Port 25 is for SMTP relays, 587 for mail submission, and 465 for implicit TLS. Discover the use cases for each SMTP port in this guide.

www.mailgun.com

Als Alternative kann man allenfalls das Google Gateway mit Port 25 unverschlüsselt mit Weiterleitung auf einen Google Account nutzen.

Oder beim Provider nachfragen ob er den eigentlich "richtigen" TLS Port 587 blockiert.

 

[rigel]

Ok, ich schaue mich schon mal nach einem anderen Mailanbieter um.

Da ich von Perl fast nichts verstehe, aber beim Herumsuchen diese Informationen gefunden habe: Könnte das eine Alternative zu Net::SMTP::TLS sein? Zumindest scheinen dort verschiedene Ports zu funktionieren.

 

[gea]

Ich werde das mal im Auge behalten. Email ist aber etwas sehr kritisches. Ich bin froh dass das smtp::TLS Modul so gut funktioniert und gepflegt wird. Auch sehe ich das Problem eher bei einem Mailprovider der den für TLS vorgesehenen Port nicht benutzt, nicht alternativ zuläßt oder im Zweifel gar blockiert.

Was du versuchen kannst:
In "/var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl" den Port in Zeile 82 umstellen (auch smtp::TLS erlaubt das). Ich habe das früher mal getestet, lief bei mir aber nicht.

Alternative smtp::TLS durch smtp::SSL ersetzen. Der Aufruf ist fast identisch.

 

[martingo]

Port 465 ist für impliziten TLS (landläufig auch SMTPS genannt) und Port 587 ist für STARTTLS (optionales TLS). Theoretisch ist STARTTLS auch über Port 25 möglich, allerdings gehen die meisten Provider mittlerweile den Weg, dass 25 nur noch für den unauthentifizierten Zugriff erlaubt ist (aka eingehende Mails fremder Mailserver).
Das ist vom Protokoll einfach unterschiedlich, daher würde es auch sicher nicht klappen, den Port auf 465 umzubiegen, solange Net::SMTP::TLS genutzt wird.

Ich persönlich nutze ausschließlich STARTTLS und bin verwundert, dass es Provider gibt, die das nicht (mehr) anbieten. Bei welchem Anbieter bist du denn?

Beitrag automatisch zusammengeführt: 13.04.2020

@gea: eben mal Deinen Artikel gelesen, der ist nicht mehr aktuell. 2018 wurde in RFC 8314 der Port 465 wieder für implizites TLS empfohlen:

RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.

tools.ietf.org

 

[rigel]

Für die Statusmail nutze ich Yandex. Evtl. ist das Problem ja tatsächlich nur vorübergehender Natur, immerhin habe ich über ein Jahr lang keine Schwierigkeiten gehabt. Ich beobachte das einfach.

 

[martingo]

Auf der Supportseite von Yandex ist zwar nur von 465 (smtps) die Rede, aber ein telnet auf smtp.yandex.com Port 587 ergibt, dass der Port offen ist und auch ein Mailserver dort horcht. Was den Timeout in Deinem Log nicht erklärt.
Sicher, dass der Port nicht durch Deine eigene Firewall geblockt wird?

 

[rigel]

Ein Firewall-Problem kann ich ausschließen, da ich per telnet aus meiner OmniOS-VM am Samstag ebenfalls durchkam. Danach habe ich per Thunderbird von meinem Arbeitsrechner versucht, das Konto einzurichten, was mit Port 587 nicht gelungen ist. Dass der Provider hier also irgendwas blockt, schien mir plausibel.

Gerade habe ich dann noch mal die Test-Mail aus napp-it heraus versendet (ohne irgendwelche Modifikationen) und es hat wieder funktioniert. Möglicherweise war es also tatsächlich nur ein kurzzeitiges Problem bei Yandex.

 

[v3nom]

Mit viel RAM sollte der ARC ja optimal genutzt werden. Wie schnell würde auf diesen geschrieben? Wäre dies die maximal mögliche Geschw. per Ethernet oder limitiert ZFS da auf die Geschw. des Pools?

 

[gea]

Mit viel RAM sollte der ARC ja optimal genutzt werden. Wie schnell würde auf diesen geschrieben? Wäre dies die maximal mögliche Geschw. per Ethernet oder limitiert ZFS da auf die Geschw. des Pools?

Arc ist der rambasierte Lesechache (blockbasiert, read last/read most - nicht filebasiert).
Ram wird aber auch als Schreibcache benutzt. Bei Original Oracle Solaris ZFS nimmt der 5s der letzten Schreibaktivitäten, bei Open-ZFS ist die normale Größe 10% RAM, max 4GB. Ist der Schreibcache halb voll. wird er als schnelles sequentielles Write geschrieben und die andere Hälfte macht Caching. Der Schreibcache dient ausschließlich dazu kleine langsame random Write zu vermeiden. Ist der Pool bei mixed/sequential Load so schnell wie das LAN so kann man mit Netzperformance schreiben, auch bei kleinen Datenblöcken bei denen die Performance ansonst massiv einbrechen würde.

Nur am Rande: Ein Slog ist kein Schreibcache. Es ist die Absicherung des rambasierten Schreibcaches. Von der Funktion eher wie Cache+Batterie bei gutem Hardwareraid.

 

[v3nom]

Danke für die Erklärung.

 

[danielmayer]

@gea: Nur als Nachfrage/Zusammenfassung wie ich es verstanden habe:
- Der Cache sammelt also kleine Dateien, um sie als sequential write effizient auf die [HDD/SSD/Raid/etc] schreiben zu können.
- Die Schreibleistung mixed/sequential des Zieldateisystems ist das "Nadelöhr" ab 50% Cachegröße
Frage: Mixed? Weil Zieldateisystem auch als Slog verwendet wird; sequential, falls externes Slog verwendet wird
- Falls Slog verwendet wird ist Slog das Nadelöhr, wenn Slog-Schreibleistung mixed-IO (? oder random?) langsamer als [HDD/SSD/Raid/etc]
Daher gerne die Empfehlung auf schnellen Optane als Slog, mit erheblichen Abstrichen ggf. M2/SSD-powerlossprotected, richtig?

 

[gea]

@gea: Nur als Nachfrage/Zusammenfassung wie ich es verstanden habe:
- Der Cache sammelt also kleine Dateien, um sie als sequential write effizient auf die [HDD/SSD/Raid/etc] schreiben zu können.

Der RAM-Schreibcache sammelt alle zu schreibenden ZFS Datenblöcke aller User und unterscheidet nicht was kommt. Beim Schreiben hat man aber immer große "sequentielle" Writes, wobei es in einem ZFS Raid keine "echten" sequentiellen Writes im Sinne von "fülle die Platte Spur um Spur" gibt sondern ZFS immer bestrebt ist alle vdevs gleichmäßig zu füllen.

- Die Schreibleistung mixed/sequential des Zieldateisystems ist das "Nadelöhr" ab 50% Cachegröße

Die 50% besiehen sich auf den Füllgrad. Ist der Cache zu 50% gefüllt, wird der Inhalt geschrieben. Der restliche Cache übernimmt solang weiteres Cachen damit die Schreibperformance konstant bleibt und nicht zuBeginn großartig ist und dann nach kurzer Zeit (Cache voll) einbricht

Frage: Mixed? Weil Zieldateisystem auch als Slog verwendet wird; sequential, falls externes Slog verwendet wird

Slog hat die Funktion "Absichern des rambasierten Schreibcaches gegen Datenverlust" und ist unabhängig vom Pool. Bei einem normalen Filer arbeitet man eh async, da wird ein mögliches Slog gar nicht benutzt. Sync brauchts unabdingbar bei Transaktionen/Datenbanken und VM Storage. Bei einem SMB Filer ist es wünschenswert aber nicht notwendig, ZFS selber braucht es garnicht wegen CopyOnWrite (Dateisystem nie korrupt, immer valide)

- Falls Slog verwendet wird ist Slog das Nadelöhr, wenn Slog-Schreibleistung mixed-IO (? oder random?) langsamer als [HDD/SSD/Raid/etc]

Ein Slog protokolliert jedes bestätigte Write damit das nach einem Crash nachgeholt werden kann. Wenn man also sync aktiviert so wird jeder Schreibvorgang zweimal geschrieben, einmal sofort und einmal über den Cache. Ein Slog kann sehr klein sein, muss ja nur ein paar GB RAM absichern, muss aber extrem schnell sein (niedrige Latenz und hohe write iops bei qd1) und plp haben.

Daher gerne die Empfehlung auf schnellen Optane als Slog, mit erheblichen Abstrichen ggf. M2/SSD-powerlossprotected, richtig?

Ohne PLP macht ein Slog keinen Sinn. Das soll ja gegen Datenverlust bei Powerloss sichern. Ist irgendwie sinnbefreit wenn das Slog dann selber kein plp kann.

 

[MisterY]

Wie CPU lästig ist zfs? Sind Threads oder Takt wichtiger?

 

[v3nom]

Denke die CPU wird dabei nicht sonderlich gefordert, außer man aktivier Verschlüsselung und Komprimierung. Wobei lz4 Komprimierung nicht so "schwer" sein sollte

 

[CommanderBond]

WD Red: Manche Festplatten nutzen SMR ohne Kennzeichnung

Einige Festplatten der für NAS bestimmten Serie WD Red nutzen die Aufzeichnungstechnik SMR, ohne dass Western Digital dies angibt.

www.computerbase.de

 

[VirtuGuy]

Phil Bullinger hat bei den letzten Storage Field Day´s ausführlich über den Einsatz von SMR gesprochen. Von daher kann ich die ganze Aufregung nicht wirklich verstehen.

 

[jonofe]

Phil Bullinger hat bei den letzten Storage Field Day´s ausführlich über den Einsatz von SMR gesprochen. Von daher kann ich die ganze Aufregung nicht wirklich verstehen.

Was genau hat er denn gesagt, das die Aufregung relativiert?

 

[CommanderBond]

Bei Seagate dasselbe vorgehen.

Festplatten: Auch bei Seagate gibt es SMR als Überraschung

Nachdem bekannt wurde, dass Western Digital HDDs mit SMR-Technik ohne Hinweis anbietet, wird jetzt klar: Auch Seagate geht so vor.

www.computerbase.de

 

[JohnnyBGoode]

Sollte man eigentlich beim aktuellen stable OmmniOS als VMware-Gast nach wie vor Solaris 10 als Umgebung angeben oder auf 11 gehen? Oder ist das völlig egal?

 

[VirtuGuy]

Was genau hat er denn gesagt, das die Aufregung relativiert?

Die Nutzung von SMR für Budgetlösungen. Unschön ist aus meiner Sicht eher das man den Preisvorteil NICHT an den Endkunden weitergibt.

 

[gea]

Sollte man eigentlich beim aktuellen stable OmmniOS als VMware-Gast nach wie vor Solaris 10 als Umgebung angeben oder auf 11 gehen? Oder ist das völlig egal?

Ich nehme immer das neuere Solaris 11 als Typ. Sollte aber egal sein. Die Default Plattengräße und RAM sollte man in beiden Fällen höher setzen. VMware Tools von Solaris nimmt man eh nicht sondern die in OmniOS enthaltenen Open-VMware Tools. Auch wird meines Wissens in VMware nichts von Solaris 11 unterstützt was nicht auch in OmniOS ist.

Illumos/OmniOS an sich ist ein Fork vom letzten OpenSolaris Build. Das war vom Stand Solaris 11 Express jedoch noch ohne die ZFS Verschlüssellung. Die war zwar bereits zu 80% fesrtig, kam aber erst kurz danach im Closed Source Oracle Solaris (und wurde erst letztes Jahr auf dieser Basis in Open-ZFS fertigentwickelt)

 

[ces]

Mir ist nicht bekannt ob minIO periodisch auf die Platte zugreift.

Ok, hab nun noch mal meine vorherige docker-basierte Variante angeworfen, da ist's leider auch so. Kein spin-down mehr. Hat also offensichtlich nix mit der Art der Implementierung unter omnios und/oder napp-it zu tun!

Grüße
ces

 

[reap]

Hallo zusammen,

ich habe ein altes NAS, mit einer Boot-SSD und einer 2TB HDD mit ZFS drauf. Kann ich die Platte ausbauen und in den Schrank legen, und falls mir irgendwann mal in 2 Jahren einfällt, ich bräuchte die Daten, einfach wieder einbauen und problemlos davon lesen?

Oder anders: Hängen die Einstellungen des zpools irgendwie an der OS Installation (FreeBSD in dem Fall), so dass ich die Platte bei einem PC-Wechsel nicht mehr lesen könnte?

 

[asche77]

... 2TB HDD mit ZFS drauf. Kann ich die Platte ausbauen und in den Schrank legen, und falls mir irgendwann mal in 2 Jahren einfällt, ich bräuchte die Daten, einfach wieder einbauen und problemlos davon lesen?

1. Das NAS nochmal anwerfen und den Pool sauber exportieren (zpool export -f poolname).
2. Dann solltest Du den pool auf der 2TB HDD auch in jedem anderen Betriebssystem, das OpenZFS und alle features Deines pools (vgl. die feature flags) unterstützt, lesen können.

 

[besterino]

Genau. Die spannende Frage ist vor allem, in welcher „ZFS-Welt“ du aktuell unterwegs bist. Echt Solaris-Pools lassen sich (aufwärts von v28 nur) unter einem echten Solaris wieder importieren. Und ich schätze, das gilt für OpenZFS bzw. dessen Derivaten ähnlich, wobei mir da bei der Kompatibilität der Überblick fehlt.

 

[gea]

Beim Pool Austausch unter Open-ZFS kommt es darauf an, ob neuere Features im Pool aktiviert sind und die Ziel-Plattform diese unterstützt. Normalerweise sollten alle Open-ZFS Plattformen neue Features "zeitnah" unterstützen.

Im Moment unterstützen Illumos (Nexenta, OmniOS, OI, SmartOS) , OSX sowie Linux/ZOL neue ZFS Features wie Encryption, special vdevs oder System-Snaps bei denen man auf einen früheren Systemstand (vdevs, Dateisysteme) zurückgehen kann. Hier sollte ein Pool Austausch keine prinzipiellen Probleme machen.

Bei Free-BSD fehlen diese neuen Features noch die es seit einem Jahr gibt. Geplant hier 2020/21. Auch legt Free-NAS auf jede Platte ein swap file an. Auch das kann Probleme machen da ansonst ZFS die ganze Platte haben möchte. Ein Austausch eines aktuellen Pools -> Free-BSD kann scheitern. Manche Features erlauben ein readonly import.

Wenn man vorhat, den Pool austauschbar zu machen, so bleibt die Option beim Pool Create alle Features zu deaktivieren. Dann geht ein Austausch immer. Nachträglich deaktivieren kann man viele Features nicht. Nette Backup Feautures wie Verschlüssellung gibts dann halt nicht.

Beim kommerziellen Oracle Solaris mit Original ZFS stellt sich die Austauschfrage nicht. Oracle hat das nicht freigegeben. Da geht ein Austausch nur mit ZFS v28/5. Das war die letzte freie ZFS Version aus OpenSolaris/Illumos (2010) aus der alle Open-ZFS Varianten und Solaris ZFS getrennt weiterentwickelt wurden.

 

[reap]

Okay also ich nutze wie gesagt FreeBSD (nicht FreeNAS). Geht mir nur drum, dass ich die Platten in Rente schicken will, und in der Schublade als Notfall Backup vom Backup vom Backup habe. Ich hab den Pool per zpool export ausgehängt und dann die Platte ausgebaut.

Bei der Erstellung des Pools (das war irgendwann 2013) hatte ich keine besonderen Features aktiviert, Verschlüsselung habe ich auch nicht. Sollte der Fall eintreten, dass ich die Daten brauche, würde ich die Platte wieder an ein (aktuelles) FreeBSD hängen.

 

[Trambahner]

7 Jahre alte Platten, die Du dann stromlos ggf. auf Jahre rumliegen hast? Das ist nicht ohne Risiko, dass die Daten überhaupt noch vollständig intakt lesbar sind.
HDDs sind üblicherweise für 5 Jahre ausgelegt und auch die maximale stromlose Zeit ist üblicherweise sehr begrenzt. Wenn sie nicht laufen, können Schmiermittel z.B. verharzen.