Ich bin gerade ein wenig überrascht. Mit meinem Macbook Pro 2021, Monterey 12.1 kann ich kabelgebunden mit etwa 100+ MB/s auf meine SMB Shares schreiben. Sowas kannte ich bisher nur von Windows. Beim Mac war ich immer froh, wenn es mehr als 40 MB/s hatte.
Hat jemand mit macos ähnliche Erfahrungen gemacht? Wäre natürlich schön, wenn sich dass ENDLICH und nachhaltig bewahrheitet
Hat jemand mit macos ähnliche Erfahrungen gemacht? Wäre natürlich schön, wenn sich dass ENDLICH und nachhaltig bewahrheitet
Ich bin derzeit dabei mein Datensicherungskonzept zu erweitern.
Ich mache schon Auto Replication meiner ZFS Daten Filesystems von meiner Haupt-Napp-It Instanz auf meinen Backup-Napp-It Server (mit Replication Extension)
Das funktioniert soweit sehr gut. Nun möchte ich auch die VM Datastores auf dem Haupt-Napp-it Server per ESXI-Hotsnap sichern.
Grundsätzlich funktionieren die ESXi Hotsnaps auch sehr gut und auch der zugehörige ZFS Snap wird danach angelegt.
Meine Frage ist: Wie kann ich die ZFS Snapshots mit den ESXi Hotsnaps vom Haupt-Napp-it Server in die Auto-Replication zum Backup-Napp-it Server integrieren?
Wenn ich einfach einen weiteren Auto-Replication Job auf dem Backup Server erstellen, dann erstellt dieser ja selbst einen neuen Snaptshot auf dem Haupt-Napp-it Server und das dann ohne die ESXi Hotsnaps. So zumindest meine Interpretation. Gibt es eine Möglichkeit meine Absichten elegant umzusetzen? Muss ich das ggf. über einen Other-Job selbst realisieren?
BTW: Da scheint noch ein kleiner Bug beim Anlegen eines autosnap-jobs aufzutreten. Wenn man im Namen (Name of Snapjob) Leerzeichen verwendet, dann wird der eigentlich ZFS Snapshot nicht erstellt, aber es erscheint auch keine Fehlermeldung. Das hat mich gestern mal ne halbe Stunde gekostet, bis ich dahintergekommen bin. Die initialen ESXi Hotsnaps wurden erstellt, aber danach hat sich der autosnap Job mit "ok" beendet. Ggf. ist es aber auch ein Verständnisproblem auf meiner Seite. Nach Löschen der Leerzeichen im Namen hat es dann aber funktioniert.
Danke im Voraus für euer Feedback.
Ich mache schon Auto Replication meiner ZFS Daten Filesystems von meiner Haupt-Napp-It Instanz auf meinen Backup-Napp-It Server (mit Replication Extension)
Das funktioniert soweit sehr gut. Nun möchte ich auch die VM Datastores auf dem Haupt-Napp-it Server per ESXI-Hotsnap sichern.
Grundsätzlich funktionieren die ESXi Hotsnaps auch sehr gut und auch der zugehörige ZFS Snap wird danach angelegt.
Meine Frage ist: Wie kann ich die ZFS Snapshots mit den ESXi Hotsnaps vom Haupt-Napp-it Server in die Auto-Replication zum Backup-Napp-it Server integrieren?
Wenn ich einfach einen weiteren Auto-Replication Job auf dem Backup Server erstellen, dann erstellt dieser ja selbst einen neuen Snaptshot auf dem Haupt-Napp-it Server und das dann ohne die ESXi Hotsnaps. So zumindest meine Interpretation. Gibt es eine Möglichkeit meine Absichten elegant umzusetzen? Muss ich das ggf. über einen Other-Job selbst realisieren?
BTW: Da scheint noch ein kleiner Bug beim Anlegen eines autosnap-jobs aufzutreten. Wenn man im Namen (Name of Snapjob) Leerzeichen verwendet, dann wird der eigentlich ZFS Snapshot nicht erstellt, aber es erscheint auch keine Fehlermeldung. Das hat mich gestern mal ne halbe Stunde gekostet, bis ich dahintergekommen bin. Die initialen ESXi Hotsnaps wurden erstellt, aber danach hat sich der autosnap Job mit "ok" beendet. Ggf. ist es aber auch ein Verständnisproblem auf meiner Seite. Nach Löschen der Leerzeichen im Namen hat es dann aber funktioniert.
Danke im Voraus für euer Feedback.
Luckysh0t
Enthusiast
Die Hotsnaps sind doch in dem Fall die VM Snapshots von ESXi - die siehst du nur in der VM im ESXi. Im Dateisystem selbst siehst du die im Rahmen von ZFS nicht.
Oder verstehe ich dich hier falsch ?
Naja, ESXi Hotsnaps von napp-it funktionieren ja so, dass napp-it per SSH und VMWare API in ESXi Snapshots der zusichernden VMs generiert. Diese sind dann nur in ESXI sichtbar. Wenn das abgeschlossen ist, macht napp-it vom ZFS Filesystem, welcher den ESXI Datastore repräsentiert und auf dem die VMs und somit die ESXI Snapshots gespeichert sind einen ZFS Snapshot. Dann löscht napp-it wieder die ESXi Snapshots und man hat schließlich einen ZFS Snaptshot, der konsistente ESXi Snapshots enthält. Und genau diesen ZFS Snaptshot möchte ich nun automatisiert auf den Backup-Server replizieren.
ESXi Hotsnaps sind also eigentlich ZFS Snapshots von NFS Datastores, welche wiederum konsistente ESXI Snapshots enthalten. Denn nur so kann man später aus dem ZFS Snapshot wieder ein konsistentes VM Image recovern.
Luckysh0t
Enthusiast
Wir meinen also das selbe ^^.
Ich hatte dieses Konstrukt selbst bei mir - nur halt nicht mit rep. auf weiteren napp-it sondern mittels zfs send auf einen anderen Datastore im gleichen Server.
Und da hat alles geklappt wie es soll.
Aber ich habe genau so wie du einen dedizierten Snapshot angelegt, der dann per zfs send weg kommt - aber in diesem snapshot sind ja dennoch die esxi snaps drinn. Es ist halt nur nicht der Snapshot aus dem Hotsnap Job, sondern aus einem nachgelagerten snapjob.
Zuminidest war das bei mir so.
Ich musste einen eigenen Snap nehmen, weil ich einen gleichen Namen brauchte für das Skript, da sich bei dem anderen ja immer das Datum/Zeit mit eingetragen hat.
Dadurch hatte jeder folgende ZFS snap einen konsistenten VM Zustand inkludiert.
Ich hatte dieses Konstrukt selbst bei mir - nur halt nicht mit rep. auf weiteren napp-it sondern mittels zfs send auf einen anderen Datastore im gleichen Server.
Und da hat alles geklappt wie es soll.
Aber ich habe genau so wie du einen dedizierten Snapshot angelegt, der dann per zfs send weg kommt - aber in diesem snapshot sind ja dennoch die esxi snaps drinn. Es ist halt nur nicht der Snapshot aus dem Hotsnap Job, sondern aus einem nachgelagerten snapjob.
Zuminidest war das bei mir so.
Ich musste einen eigenen Snap nehmen, weil ich einen gleichen Namen brauchte für das Skript, da sich bei dem anderen ja immer das Datum/Zeit mit eingetragen hat.
Beitrag automatisch zusammengeführt:
Das hat er bei mir erst beim nächsten Hotsnap job gemacht und nicht gleich nochmal danach - ich hatte quasi dauerhaft einen esxi snap in jeder VM. Hatte das nur als prejob aktiv.
Dadurch hatte jeder folgende ZFS snap einen konsistenten VM Zustand inkludiert.
Zuletzt bearbeitet:
Das ist ne gute Idee. Das sollte funktionieren. Muss mal schaun wie viel Storage das auf dem ESXI kostet, da ich da etwas knapp bin. (50G frei von 380G).
Alternativ fällt mir gerade ein, dass ich ja auch vom Backup-Server die ESXi Snapshots erzeugen könnte, bevor die Replikation startet. Und nach der Replikation dann vom Backup-Server aus dann wieder die ESXi Snapshots löschen.
So ist es eigentlich gedacht.
Der Backupserver kontrolliert die Replikationen von einem oder mehreren Quell-Servern.
Das macht Sinn. Aber wie kann ich die ESXI Snaps auf dem Haupt ESXI/NAPP-IT Server erstellen und löschen und zwar vom Replication Job, der auf meinem Backup ESXI/NAPP-IT Server läuft.
Bei "Jobs => ESXI Hotsnaps" kann ich ja nur lokale auto-snap-jobs auswählen und keine Replication Jobs.
Ein auto-snap-job bezieht sich aber ja nur auf lokale Filesysteme. Mein Datastore liegt aber auf dem Haupt napp-it Server und nicht lokal.
Einzig was mir einfällt:
1. Zuerst läuft ein autosnap job auf dem Backup-Server (für ein beliebiges lokales Filesystem), welcher aber den ESXI Pre job auf dem Haupt ESXI Server ausführt. Dieser Job läuft vor der Replikation ab und erzeugt damit die ESXI Snapshots
2. Dann läuft die Replikation, welche den entsprechenden Datastore mit den ESXI Snaps auf den Backup Server sichert
3. Dann wird ein weiterer autosnap job auf dem Backup Server gestartet welcher den ESXI Post Job enthält, welcher auf dem Haupt-ESXI Server wieder die ESXI Snapshots löscht
Geht das noch irgendwie einfacher?
Genial wäre, wenn ein Replikationsjob auch ESXI Pre/Post Scripts starten könnte, quasi automatische Replikation von ESXI Datastore ZFS Filesystems. Vielleicht geht das ja schon irgendwie und ich habs nur nicht verstanden. Eine kurze Erklärung dazu wäre super!
Napp-it / @gea :
Servus, seit einiger Zeit funktioniert der SMTP-over-SSL email-Versand via GMail nicht mehr bei mir.
Ich bin nicht ganz sicher, ob es an der Umstellung auf ein app-Passwort bei gmail liegt (sollte eigentlich gehen) oder an der Aktualisierung auf OmniOS r40 und neuere napp-it Version.
Mir scheint es eher ein Problem mit einer Aktualisierung, die mein Perl zerschossen hat, denn ich habe versuchsweise die Perl-Module neu installieren wollen (entsprechend https://napp-it.org/downloads/tls_en.html) und erhalte folgende blöde Fehlermeldung:
Blöd, wenn ich IO::Socket::SSL benötige, um IO::Socket::SSL zu installieren ...
Any tips / help?
Servus, seit einiger Zeit funktioniert der SMTP-over-SSL email-Versand via GMail nicht mehr bei mir.
Ich bin nicht ganz sicher, ob es an der Umstellung auf ein app-Passwort bei gmail liegt (sollte eigentlich gehen) oder an der Aktualisierung auf OmniOS r40 und neuere napp-it Version.
Mir scheint es eher ein Problem mit einer Aktualisierung, die mein Perl zerschossen hat, denn ich habe versuchsweise die Perl-Module neu installieren wollen (entsprechend https://napp-it.org/downloads/tls_en.html) und erhalte folgende blöde Fehlermeldung:
Code:
cpan[2]> notest install IO::Socket::SSL
Running install for module 'IO::Socket::SSL'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/S/SU/SULLR/IO-Socket-SSL-2.073.tar.gz
HTTP::Tiny failed with an internal error: IO::Socket::SSL 1.42 must be installed for https support
Giving up on '/home/[xxxxxx]/.cpan/sources/authors/id/S/SU/SULLR/IO-Socket-SSL-2.073.tar.gz'
Note: Current database in memory was generated on Wed, 22 Dec 2021 19:55:40 GMTBlöd, wenn ich IO::Socket::SSL benötige, um IO::Socket::SSL zu installieren ...
Any tips / help?
Ich habe gerade die Module (neues OmniOS 040g + napp-it wget) durchlaufen lassen
perl -MCPAN -e shell
notest install Net::SSLeay
notest install IO::Socket::SSL
notest install Net::SMTP::TLS
exit;
Ging ohne Probleme.
Bei Rückfragen habe ich nur Enter gedrückt
zu Gmail
Login to Gmail settings. On the bottom of the settings, you find the option: allow less security apps; set to on
https://www.google.com/settings/security/lesssecureapps
Alternativ:
Push Alerts z.B. mit Telegram API
perl -MCPAN -e shell
notest install Net::SSLeay
notest install IO::Socket::SSL
notest install Net::SMTP::TLS
exit;
Ging ohne Probleme.
Bei Rückfragen habe ich nur Enter gedrückt
zu Gmail
Login to Gmail settings. On the bottom of the settings, you find the option: allow less security apps; set to on
https://www.google.com/settings/security/lesssecureapps
Alternativ:
Push Alerts z.B. mit Telegram API
Ich start den ESXi oder die Napp-IT VM zwar nicht regelmäßig neu, aber es ist etwas nervig, wenn man verschlüsselte Dateisysteme hat und darauf VMs liegen, die man dann manuell starten muss.
Wäre es möglich, dass Napp-IT eine Funktion erhält, VMs (auf einem ESXi) automatisch zu starten, sobald ein verschlüsseltes ZFS-Dateisystem entsperrt wird?
Oder kennt jemand eine Möglichkeit, VMs automatisiert zu starten, sobald ein (NFS- oder iSCSI-) Datastore wieder verfügbar ist?
Wäre es möglich, dass Napp-IT eine Funktion erhält, VMs (auf einem ESXi) automatisch zu starten, sobald ein verschlüsseltes ZFS-Dateisystem entsperrt wird?
Oder kennt jemand eine Möglichkeit, VMs automatisiert zu starten, sobald ein (NFS- oder iSCSI-) Datastore wieder verfügbar ist?
Sind eigentlich mehrere Fragen:
Wenn man eine VM nach manuellem Unlock starten möchte, wäre in der Tat ein Script das man z.B. über "other job" startet eine Option. Entschlüsseln + VM Start per SSH/esxcli könnte man da integrieren.
Man kann aber auch verschlüsselte Dateisysteme in napp-it automatisch beim Booten entschlüsseln (auto-unlock). Wenn man die napp-it VM auch in ESXi auf autoboot stellt, hat man NFS nach dem Einschalten zur Verfügung.
Ich boote ESXi zwar nie, bisher war es für ESXi kein Problem, wenn NFS3 mit Verzögerung zur Verfügung steht. Autoboot von VMs auf NFS müssen dann halt mit entsprechender Verzögerung gestartet werden.
Lediglich bei iSCSI ist ein manueller Mount nötig, NFS ist aber eh praktisch gleich schnell und viel einfacher im Handling.
Wenn man eine VM nach manuellem Unlock starten möchte, wäre in der Tat ein Script das man z.B. über "other job" startet eine Option. Entschlüsseln + VM Start per SSH/esxcli könnte man da integrieren.
Man kann aber auch verschlüsselte Dateisysteme in napp-it automatisch beim Booten entschlüsseln (auto-unlock). Wenn man die napp-it VM auch in ESXi auf autoboot stellt, hat man NFS nach dem Einschalten zur Verfügung.
Ich boote ESXi zwar nie, bisher war es für ESXi kein Problem, wenn NFS3 mit Verzögerung zur Verfügung steht. Autoboot von VMs auf NFS müssen dann halt mit entsprechender Verzögerung gestartet werden.
Lediglich bei iSCSI ist ein manueller Mount nötig, NFS ist aber eh praktisch gleich schnell und viel einfacher im Handling.
Das bedeutet ja, der Schlüssel muss irgendwo in Napp-IT hinterlegt sein, damit das Dateisystem automatisch beim boot entschlüsselt werden kann. Macht das nicht die Verschlüsselung obsolet, wenn der Schlüssel direkt bei den zu entschlüsselnden Daten aufbewaht wird und zudem auch noch automatisch angewendet wird? .
Kannst du bitte das Sicherheitskonzept dahinter erläutern?
Kannst du bitte das Sicherheitskonzept dahinter erläutern?
Ich habe mehrere Möglichkeiten in napp-it eingebaut um den Schlüssel beim Booten bereitzustellen. Beim Anlegen eines verschlüsselten Dateisytems kann man das aus den konfigurierten Optionen auswählen.
1. Schlüssel liegt auf einem lokalen Dateisystem (L1:L1).
Das ist die einfachste Option für Heimnutzer. Hier könnte man einen Dateisystem auf einem USB Stick oder Wechselplatte benutzen den man abziehen kann.
2. Schlüssel liegt auf zwei Dateisystemen (Keysplit, L1:L2).
Hier wird pro Dateisystem nur eine Hälfte des Keys gespeichert. eine weitere Option für Heimnutzer. Hier könnte man zwei Dateisysteme auf zwei USB Sticks oder Wechselplatten benutzen
3. Schlüssel liegt auf einem oder zwei iSCSI Targets (L1:L1, L1:L2).
Das ist eher eine Pro Option. Hier kann man ein oder zwei Dateisysteme auf iSCSI Targets benutzen. Mit Target Portal Groups hat man eine Einschränkung auf die Client IP. Auch kann man das Target per Passwort absichern.
4. Schlüssel liegt auf einem oder zwei Key/Webservern (W1:W1, W1:W2).
Das ist eher eine Pro Option. Hier kann man ein oder zwei Webserver benutzen. Auf dem Webserver hat man eine Einschränkung auf die Client IP. Auch ist ein Key nötig.Webserver können redundant sein (2 oder 4 Webserver)
5. obige Optionen kann man kombinieren. Beim Entschlüsseln mit lokalem oder Webkey kann man immer direkt den Key alternativ per Prompt eingeben (falls man den Key hat aber nicht die Dateien). Webserver kann man auch redundant auslegen und per Key oder ip absichern.
6. Als weitere Option kann man "on demand" ein Dateisystem mit obigen Keys per SMB und überwachtem Unlock/Lock Ordner remote über eine SMB Freigabe verschlüsseln/entschlüsseln.
1. Schlüssel liegt auf einem lokalen Dateisystem (L1:L1).
Das ist die einfachste Option für Heimnutzer. Hier könnte man einen Dateisystem auf einem USB Stick oder Wechselplatte benutzen den man abziehen kann.
2. Schlüssel liegt auf zwei Dateisystemen (Keysplit, L1:L2).
Hier wird pro Dateisystem nur eine Hälfte des Keys gespeichert. eine weitere Option für Heimnutzer. Hier könnte man zwei Dateisysteme auf zwei USB Sticks oder Wechselplatten benutzen
3. Schlüssel liegt auf einem oder zwei iSCSI Targets (L1:L1, L1:L2).
Das ist eher eine Pro Option. Hier kann man ein oder zwei Dateisysteme auf iSCSI Targets benutzen. Mit Target Portal Groups hat man eine Einschränkung auf die Client IP. Auch kann man das Target per Passwort absichern.
4. Schlüssel liegt auf einem oder zwei Key/Webservern (W1:W1, W1:W2).
Das ist eher eine Pro Option. Hier kann man ein oder zwei Webserver benutzen. Auf dem Webserver hat man eine Einschränkung auf die Client IP. Auch ist ein Key nötig.Webserver können redundant sein (2 oder 4 Webserver)
5. obige Optionen kann man kombinieren. Beim Entschlüsseln mit lokalem oder Webkey kann man immer direkt den Key alternativ per Prompt eingeben (falls man den Key hat aber nicht die Dateien). Webserver kann man auch redundant auslegen und per Key oder ip absichern.
6. Als weitere Option kann man "on demand" ein Dateisystem mit obigen Keys per SMB und überwachtem Unlock/Lock Ordner remote über eine SMB Freigabe verschlüsseln/entschlüsseln.
Zuletzt bearbeitet:
Ja geht. Eine Scripdatei /var/web-gui/_log/jobs/$id.pre bzw /var/web-gui/_log/jobs/$id.post anlegen ($id=jobid). Das Script wird vor/nach der Replikation ausgeführt.
So, gelöst:
1. (Re-)Installation von IO::Socket::SSL war über HTTP (statt HTTPS) möglich, nachdem ich mit folgendem CPAN-Befehl auf HTTP umgeschaltet hatte:
Code:
conf init pushy_https2. Versand mit emails in napp-it über smtp.gmail.com funktioniert auch mit "App-Passwörtern", man kann also 2FA bei google einschalten.
3. Man muss die email-Einstellungen allerdings im job selbst ändern. Die Änderung unter "System -> Settings" genügt nicht. Auch der SMTP-Test unter "Jobs -> Email -> smtp-test" funktionierte bei mir mit App-Passwörtern nicht, der Status-email-Job aber schon.
Knogle
Enthusiast
Hey Freunde.
Wieder Verbesserungsbedarf vorhanden bei meinem Setup
Ich habe aktuell 2 Pools, einen großen aus 12x 4TB Platten als Datengrab + iSCSI Share für eine Zoneminder VM.
Dann einen zweiten, aus 3x 1TB TLC SSDs im RAID-Z, die Performance ist irgendwie jedoch echt bescheiden, ich komme auf 300MB/s etwa. Deduplizierung brauche ich hier jedoch.
Könnte man das tunen, oder ein striped + mirrored ala RAID 10 stattdessen eher machen, mit einer vierten SSD?
Leider habe ich für sowas kein Platz mehr im Case, alle 16 HDD Slots sind belegt. Würdet ihr daher den großen Pool verkleinern, z.B. auf 4x 14TB SSDs als striped + mirrored oder ähnlich?
Ich habe eine Maschine für virtuelle Maschinen, und eine dedizierte Maschine für Storage, mit Ryzen 2700X, 128GB ECC RAM.
Beide sind Maschinen sind mit 2x 40Gbps verbunden als LAG, und die Performance vom SSD Pool ist leider deutlich schlechter als die vom HDD Pool.
Jedoch konnte ich durch Dedup extrem viel Platz einsparen, fast 1,6TB, da ein Großteil der Daten identisch ist unter den ganzen VMs.
Was würdet ihr mir vorschlagen um das ganze Setup mal zu überholen? Vielleicht andere SSDs, andere HDDs oder sonst irgendwas?
Ich bin für alles offen!
Wieder Verbesserungsbedarf vorhanden bei meinem Setup
Ich habe aktuell 2 Pools, einen großen aus 12x 4TB Platten als Datengrab + iSCSI Share für eine Zoneminder VM.
Dann einen zweiten, aus 3x 1TB TLC SSDs im RAID-Z, die Performance ist irgendwie jedoch echt bescheiden, ich komme auf 300MB/s etwa. Deduplizierung brauche ich hier jedoch.
Könnte man das tunen, oder ein striped + mirrored ala RAID 10 stattdessen eher machen, mit einer vierten SSD?
Leider habe ich für sowas kein Platz mehr im Case, alle 16 HDD Slots sind belegt. Würdet ihr daher den großen Pool verkleinern, z.B. auf 4x 14TB SSDs als striped + mirrored oder ähnlich?
Ich habe eine Maschine für virtuelle Maschinen, und eine dedizierte Maschine für Storage, mit Ryzen 2700X, 128GB ECC RAM.
Beide sind Maschinen sind mit 2x 40Gbps verbunden als LAG, und die Performance vom SSD Pool ist leider deutlich schlechter als die vom HDD Pool.
Jedoch konnte ich durch Dedup extrem viel Platz einsparen, fast 1,6TB, da ein Großteil der Daten identisch ist unter den ganzen VMs.
Was würdet ihr mir vorschlagen um das ganze Setup mal zu überholen? Vielleicht andere SSDs, andere HDDs oder sonst irgendwas?
Ich bin für alles offen!
300MB/s für ein SATA SSD RAIDZ vdev scheinen ein üblicher Wert zu sein. Du darfst da nicht zuviel erwarten.
Stripe+mirror pool hilft sowohl bei IOPS als auch writes. Lesen geht vermutlich nur unwesentlich schneller. Genaues müsste jmd anderes (be-)raten.
Trambahner
Urgestein
Für meinen SSD-Pool nutze ich 6x960GB SSD (SM863/SM883), als Stripe über 3 Mirror-Pärchen. Sequentiell schreibt das mit bis zu 1.3GB/s und liest mit bis zu knapp 2GB/s. Bei den SSDs ist etwa je 850 GB für die vdevs genutzt, der Rest dient dem Overprovisioning. Hängen an einem 9400-16i.
Dedup ist aus (da hab ich mal gelernt: vermeiden soweit es irgendwie geht), LZ4 ist an.
Aktuell hab ich die Vorstellung, diesen Pool durch ein U.2 PM9A3-Pärchen (2x7.68TB) zu ersetzen; da ist aber PCIe 4.0 Cableing noch ein Thema und auch die Sata-SSDs haben noch genug Platz, so dass es derzeit mehr ein "würde gerne machen+haben" statt "brauche" Modus ist. 2500 Euro ist mir das derzeit nicht wert.
Dedup ist aus (da hab ich mal gelernt: vermeiden soweit es irgendwie geht), LZ4 ist an.
Aktuell hab ich die Vorstellung, diesen Pool durch ein U.2 PM9A3-Pärchen (2x7.68TB) zu ersetzen; da ist aber PCIe 4.0 Cableing noch ein Thema und auch die Sata-SSDs haben noch genug Platz, so dass es derzeit mehr ein "würde gerne machen+haben" statt "brauche" Modus ist. 2500 Euro ist mir das derzeit nicht wert.
Zuletzt bearbeitet:
Prinzipiell hat ein Mirror schreibend die Performance einer Einzelplatte (sequentiell und iops). Lesend bei parallelen Zugriffen hat man die doppelte Performance da ZFS dann von beiden Platten gleichzeitig lesen kann. In napp-it Pool > Benchmark (Filebench) und 5streamread/write sieht man das sehr gut. Um die Performance zu beurteilen braucht man auf jeden Fall eine Testreihe die sequentiell und random lesend und dann das schreibend mit und ohne sync testet.
Ein Raid-Z vdev hat übrigens sequentiell n * Datenplatten (ohne Redundanz Platten) und iops einer einzelnen Platte. Skaliert mit Anzahl vdevs.
Bei Stripes aus zwei oder mehr Mirrors (Raid 10) multiplizieren sich die sequentielles Schreib- und iops Werte eines Mirrors mit der Anzahl der Mirrors. Der Zuwachs ist aber nicht ganz linear. Wenn eine Platte 500 MB/s kann, dann ist man beim Raid-10 oft nur bei 750 MB/s (Faktor 1,5).
Vor allem beim Schreiben kommt es aber auf die Qualität der SSD an. Billige Desktop SSD brechen da nach kurzer Zeit Schreiben teils heftig ein. Auch ist die Datensicherheit nicht die Beste da diese SSD keine Powerloss Protection haben die dafür sorgen dass ein Absturz bei Schreiben keinen Datenverlust oder korruptes Dateisystem hinterläßt.
Performance insgesamt hängt von vielen Parametern ab. 300 MB/s bei SSD Raid-10 ist auf jeden Fall (bis auf sync write) ziemlich wenig. Bei sehr guten SSD würde ich eher 700 MB/s Schreiben und 900 MB/s Lesen erwarten. Neben RAM und Plattenperformance zählt aber durchaus auch CPU, vgl https://napp-it.org/doc/downloads/epyc_performance.pdf wobei Core Performance (Takt) wichtiger ist als Anzahl Cores (bis auf AiO mit Virtualisierung)
Dedup ist normalerweise zu vermeiden weil man den RAM eher als Lesecache möchte als für Dedup Tabellen oder man nutzt ein special vdev Mirror für die Dedup Tabellen. Mit 128 GB RAM und einem 2TB Pool ist das aber Egal. Selbst wenn man im worst case 5GB RAM per TB Dedup Daten veranschlagt, kostet Dedup nicht mehr als 10 GB RAM.
Zuletzt bearbeitet:
Wünsche allen ein gutes Jahr 2022 und würde gerne nochmal auf das Thema Entschlüsselung zurück kommen (siehe auch geas Beitrag #11.981 weiter oben).
Die zur Verfügung stehenden Methoden zur Entschlüsselung haben ja fast alle gemein, dass man die Keys irgendwo hinterlegen muss und diese dann "online" zur Verfügung stehen müssen. Das heißt ich muss mir an anderer Stelle Gedanken darüber machen, dass die Keys auch tatsächlich zu jeder Zeit gegen Zugriff gesichert UND verfügbar UND die Verbindung auch sicher ist. Das ist für eine All in One Lösung irgendwie nicht praktikabel, weil ja dann Keyserver und Napp-IT komplett auf einem Blech liegen würde.
Ich würde weiter gerne dabei bleiben und die Entschlüsselung manuell triggern. Da bin ich mir dann auch sicher, dass der Schlüssel nur zum Zeitpunkt der Entschlüsselung verfügbar ist. Über SSH oder direkt die Konsole geht das ja ganz einfach und funktioniert so weit auch:
Ich wollte das jetzt automatisieren indem ich das ganze als Skript oder Kommandozeilenbefehl in meinem meinem Passwortmanager hinterlege und von dort aus dann anstoße. Ich scheitere aber daran, dass der erste Befehl (Schlüssel laden) noch eine Eingabe ("Enter passphrase for...") haben will. Soweit ich das verstehe, ist es nicht möglich, den Key direkt als Schalter an den load-key-Befehl zu hängen, oder? In etwa so:
Das würde nur gehen, wenn der Schlüssel als Datei irgendwo abgelegt ist (was ich ja nicht unbedingt will)?
Das Problem ist, dass die Methoden die ich kenne bzw. genutzt hätte, alle daran scheitern, dass sie das Passwort nicht abschicken, wenn "Enter Passphrase for..." kommt. Hat jemand ne Idee, wie man das über ne SSH-Verbindung automatisiert bekommt?
Was ich probiert habe ist mit Putty/plink:
Wobei command.txt einfach nur folgenden Inhalt hat:
Mit dem Windows-SSH-Client hat es auch nicht funktioniert:
Die zur Verfügung stehenden Methoden zur Entschlüsselung haben ja fast alle gemein, dass man die Keys irgendwo hinterlegen muss und diese dann "online" zur Verfügung stehen müssen. Das heißt ich muss mir an anderer Stelle Gedanken darüber machen, dass die Keys auch tatsächlich zu jeder Zeit gegen Zugriff gesichert UND verfügbar UND die Verbindung auch sicher ist. Das ist für eine All in One Lösung irgendwie nicht praktikabel, weil ja dann Keyserver und Napp-IT komplett auf einem Blech liegen würde.
Ich würde weiter gerne dabei bleiben und die Entschlüsselung manuell triggern. Da bin ich mir dann auch sicher, dass der Schlüssel nur zum Zeitpunkt der Entschlüsselung verfügbar ist. Über SSH oder direkt die Konsole geht das ja ganz einfach und funktioniert so weit auch:
Bash:
Verschlüsseltes Dataset mit passphrase über Konsole mounten:
1. Schlüssel laden:
# zfs load-key -r pool/crypteddataset
Enter passphrase for 'pool/dataset': key
2. Verschlüsseltes Dataset mounten:
# zfs mount pool/crypteddataset
Verschlüsseltes Dataset Unmounten und Schlüssel entfernen:
1. Unmounten:
# zfs unmount pool/crypteddataset
2. Schlüssel entfernen:
# zfs unload-key -r pool/crypteddataset
Ganz gut beschrieben mit weiteren Optionen ist es hier:
https://docs.oracle.com/cd/E36784_01/html/E36835/gkkih.html#scrolltoc
http://manpages.ubuntu.com/manpages/impish/man8/zfs-load-key.8.htmlIch wollte das jetzt automatisieren indem ich das ganze als Skript oder Kommandozeilenbefehl in meinem meinem Passwortmanager hinterlege und von dort aus dann anstoße. Ich scheitere aber daran, dass der erste Befehl (Schlüssel laden) noch eine Eingabe ("Enter passphrase for...") haben will. Soweit ich das verstehe, ist es nicht möglich, den Key direkt als Schalter an den load-key-Befehl zu hängen, oder? In etwa so:
Code:
zfs load-key -r pool/crypteddataset -pw *datasetkey*Das würde nur gehen, wenn der Schlüssel als Datei irgendwo abgelegt ist (was ich ja nicht unbedingt will)?
Das Problem ist, dass die Methoden die ich kenne bzw. genutzt hätte, alle daran scheitern, dass sie das Passwort nicht abschicken, wenn "Enter Passphrase for..." kommt. Hat jemand ne Idee, wie man das über ne SSH-Verbindung automatisiert bekommt?
Was ich probiert habe ist mit Putty/plink:
Code:
plink.exe -ssh root@host -pw password -m c:\path\to\command.txtWobei command.txt einfach nur folgenden Inhalt hat:
Code:
zfs load-key -r pool/cryptotest
cryptotestpasswort
zfs mount pool/cryptotestMit dem Windows-SSH-Client hat es auch nicht funktioniert:
Code:
ssh root@host-IP "zfs load-key -r pool/cryptotest && cryptotestpasswort && zfs mount pool/cryptotest"
Zuletzt bearbeitet:
Habs jetzt mit TeraTerm automatisiert bekommen. Wer das auch machen möchte kann nachfolgendes Makro dafür nutzen.
Ich hinterlege das Makro in meinem Passwortmanager und muss dann nur noch kurz das Makro starten.
Anleitung für Windows in Verbindung mit TeraTerm:
Vorbereitung:
- SSH auf Napp-IT aktivieren ( Services -> SSH auf online stellen und Services -> SSH -> allow root aktivieren)
- TeraTerm runterladen und entpacken oder installieren
- TeraTerm starten und manuell auf Napp-IT verbinden und den SSH-Key akzeptieren / speichern
- Im TeraTerm-Ordner liegen .ttl-Dateien. Davon eine öffnen und falls Windows nicht automatiisch TeraTerm startet die Dateiendung .ttl zu ttpmacro.exe im TeraTerm-Verzeichnis zuordnen.
Makro erstellen:
- Datei ZFS-Autounlock.ttl erstellen
- Diese Datei mit dem Editor öffnen
- Nachfolgendes Makro in die Datei kopieren und alle Values die in *** stehen ändern, die *** dabei entfernen
- Datei speichern
- Datei starten. Es sollte sich dann TeraTerm öffnen und das Makro automatisch abarbeiten.
OK... Das Makro scheint zwar zu gehen. Wenns durchgelaufen ist, wird auch in der Web-Oberfläche von Napp-IT angezeigt, dass die Datasets unlocked sind und auch die Berechtigungen, SMB und co. werden richtig aktualisiert.
Nur: Weder das NFS-Laufwerk kann vom ESXi erreicht werden, noch die SMB-shares von einem anderen Host.
@gea Was fehlt hier noch ?
Ich hinterlege das Makro in meinem Passwortmanager und muss dann nur noch kurz das Makro starten.
Anleitung für Windows in Verbindung mit TeraTerm:
Vorbereitung:
- SSH auf Napp-IT aktivieren ( Services -> SSH auf online stellen und Services -> SSH -> allow root aktivieren)
- TeraTerm runterladen und entpacken oder installieren
- TeraTerm starten und manuell auf Napp-IT verbinden und den SSH-Key akzeptieren / speichern
- Im TeraTerm-Ordner liegen .ttl-Dateien. Davon eine öffnen und falls Windows nicht automatiisch TeraTerm startet die Dateiendung .ttl zu ttpmacro.exe im TeraTerm-Verzeichnis zuordnen.
Makro erstellen:
- Datei ZFS-Autounlock.ttl erstellen
- Diese Datei mit dem Editor öffnen
- Nachfolgendes Makro in die Datei kopieren und alle Values die in *** stehen ändern, die *** dabei entfernen
- Datei speichern
- Datei starten. Es sollte sich dann TeraTerm öffnen und das Makro automatisch abarbeiten.
Code:
Siehe Beitrag #11.998 weiter unten
Beitrag automatisch zusammengeführt:
OK... Das Makro scheint zwar zu gehen. Wenns durchgelaufen ist, wird auch in der Web-Oberfläche von Napp-IT angezeigt, dass die Datasets unlocked sind und auch die Berechtigungen, SMB und co. werden richtig aktualisiert.
Nur: Weder das NFS-Laufwerk kann vom ESXi erreicht werden, noch die SMB-shares von einem anderen Host.
@gea Was fehlt hier noch ?
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
Genau dieses Phänomen hatte ich auch als ich meine Datasets manuell per ssh (pw abfrage) entsperrt habe.
Manchmal hat es geklappt aber eher selten.Ich musste dann in nappit smb etc de/aktivieren damit es wieder geklappt hat.
Da mich dass dann nervte habe ich es jetz einfach dauerhaft an. Nutzt du Omnios oder Solaris ? Ich hatte das Verhalten bei Solaris.
Den NFS und SMB Service muss man dann neu starten. Bei geschachtelten Dateisystemen sogar rekursiv.
ps
-Solaris und OmniOS arbeiten unterschiedlich wenn es um Verschlüssellung geht. OmniOS baut auf Open-ZFS Verschlüssellung auf. Das basiert zwar wie Solaris auch auf der (fast fertigen) Verschlüssellung im letzten freien OpenSolaris, Befehle und Optionen sind aber anders.
-Wenn man ein Perl Script nimmt, kann man auch das installierte Expect nutzen. Ich mache damit interaktive Befehle wie passwd, join ad, unlock etc. Gestartet wird ein Perlscript am einfachsten z.B. mit "perl scriptdatei".
siehe /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl
Unlock eines Dateisystems, Zeile 2172
ps
-Solaris und OmniOS arbeiten unterschiedlich wenn es um Verschlüssellung geht. OmniOS baut auf Open-ZFS Verschlüssellung auf. Das basiert zwar wie Solaris auch auf der (fast fertigen) Verschlüssellung im letzten freien OpenSolaris, Befehle und Optionen sind aber anders.
-Wenn man ein Perl Script nimmt, kann man auch das installierte Expect nutzen. Ich mache damit interaktive Befehle wie passwd, join ad, unlock etc. Gestartet wird ein Perlscript am einfachsten z.B. mit "perl scriptdatei".
siehe /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl
Unlock eines Dateisystems, Zeile 2172
Zuletzt bearbeitet:
@Luckysh0t Ich hab Napp-IT auf OmniOS installiert.
@gea Ich kann leider kein Perl und verstehe auch dein Script nicht im Detail.
Kann man dein Script auch über Komandozeile mit entsprechenden Parametern triggern? Also quasi das, was die Weboberfläche macht, auch über SSH anstoßen? Das wäre ja dann eine erprobte und zuverlässige Methode, wie man über SSH unlocken und sicherstellen kann, dass SMB/NFS sofort wieder funktioniert.
Falls das nicht so ohne weiteres geht:
Reicht es aus, wenn man in das Makro einfach noch die share-Befehler hinzufügt? https://docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html#gayno
Wenn ich das aus deinem Perl-Script richtig raus lese, setzt dein Perl-Skript "nur" die legacy-Befehle zfs set sharenfs=on tank/fs1 ab und nicht die new share syntax. Ist das richtigt oder müsste man sonst noch was beachten?
Oder gibts sowas wie ein "systemctl restart smb/nfs" ?
@gea Ich kann leider kein Perl und verstehe auch dein Script nicht im Detail.
Kann man dein Script auch über Komandozeile mit entsprechenden Parametern triggern? Also quasi das, was die Weboberfläche macht, auch über SSH anstoßen? Das wäre ja dann eine erprobte und zuverlässige Methode, wie man über SSH unlocken und sicherstellen kann, dass SMB/NFS sofort wieder funktioniert.
Falls das nicht so ohne weiteres geht:
Reicht es aus, wenn man in das Makro einfach noch die share-Befehler hinzufügt? https://docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html#gayno
Wenn ich das aus deinem Perl-Script richtig raus lese, setzt dein Perl-Skript "nur" die legacy-Befehle zfs set sharenfs=on tank/fs1 ab und nicht die new share syntax. Ist das richtigt oder müsste man sonst noch was beachten?
Oder gibts sowas wie ein "systemctl restart smb/nfs" ?
