[Sammelthread] ZFS Stammtisch

[ludwinator]

Kann doch gar nicht sein, das das nur bei mir funktioniert?
zfs get all zones/opt
NAME PROPERTY VALUE SOURCE
...
zones/opt encryption off default
zones/opt keylocation none default
zones/opt keyformat none default
zones/opt pbkdf2iters 0 default

zfs send -v zones/opt@2020-01-03_16.03.01--3d |zfs receive -o encryption=on -o keyformat=passphrase -o keylocation=file:///zones/trash/key zones/test
full send of zones/opt@2020-01-03_16.03.01--3d estimated size is 415M
total estimated size is 415M

zfs get all zones/test
NAME PROPERTY VALUE SOURCE
...
zones/test encryption aes-256-ccm -
zones/test keylocation file:///zones/trash/key local
zones/test keyformat passphrase -
zones/test pbkdf2iters 342K -
zones/test encryptionroot zones/test -
zones/test keystatus available -

zfs send -v -I zones/opt@2020-01-03_16.03.01--3d zones/opt@2020-01-04_14.03.01--3d |zfs receive -F zones/test
total estimated size is 1.37M
...

 

[gea]

Kann doch gar nicht sein, das das nur bei mir funktioniert?
zfs get all zones/opt
NAME PROPERTY VALUE SOURCE
...
zones/opt encryption off default
zones/opt keylocation none default
zones/opt keyformat none default
zones/opt pbkdf2iters 0 default

zfs send -v zones/opt@2020-01-03_16.03.01--3d |zfs receive -o encryption=on -o keyformat=passphrase -o keylocation=file:///zones/trash/key zones/test
full send of zones/opt@2020-01-03_16.03.01--3d estimated size is 415M
total estimated size is 415M

zfs get all zones/test
NAME PROPERTY VALUE SOURCE
...
zones/test encryption aes-256-ccm -
zones/test keylocation file:///zones/trash/key local
zones/test keyformat passphrase -
zones/test pbkdf2iters 342K -
zones/test encryptionroot zones/test -
zones/test keystatus available -

zfs send -v -I zones/opt@2020-01-03_16.03.01--3d zones/opt@2020-01-04_14.03.01--3d |zfs receive -F zones/test
total estimated size is 1.37M
...

Ich habs nochmal probiert. Bei mir hat jetzt das Anlegen eines neuen verschlüsselten Dateisystems per receive -o encryption=on jetzt auch geklappt (ohne send -R). Ich muss da wohl irgendeinen Typofehler drin gehabt haben.

Beitrag automatisch zusammengeführt: 04.01.2020

Jaja gea, aber die Frage ist doch, warum das für SMR-Platten schlecht sein soll? Die sollte man doch nur nicht random befüllen, weil sie sonst noch übler einbrechen als konventioneller Drehrost. Wenn ein Datenblock rekonstruiert ist, dann geht der doch in Gänze (idealerweise mit vielen anderen zusammen) auf die neue Platte und nicht in 4k-Häppchen, die dann SMR-intern wegen der des Layouts dann u.U. mehrfach neu geschrieben werden müssen?

Selbst wenn mam den Cache Inhalt (mehrere GB) schreibt, wird daraus kein richtig sequentieller Datenstrom. Der wird zunächst in variablen ZFS recsize Blöcken über den Pool mit Redundanz verteilt. Jeder ZFS Block muss nicht notwendigerweise am Stück bleiben da die Platte mit der Zeit fragmentiert., er kann auch deutlich kleiner als recsize.

Für einen Single User Media oder Backupserver wird das sicher gut genug funktionieren, nicht jedoch für Multiuser Lastbetrieb und dafür ist ZFS ja ausgelegt. Da bleibt dann nur noch die Erkenntnis dass der einzige Vorteil vom MSR der geringere Preis war. Performancetechnisch taugt das nicht.

 

[kandamir]

Okay, scheint ja doch eine Lösung zu geben, das ist erst einmal gut. Ich bin inzwischen vom Ort des Backup-Servers wieder unverrichteter Dinge los (Backup Platten im Gepäck) und wieder zuhause angelangt. Dort steht jetzt gerade das Update auf OmniOS R151028 an (Napp-It ist bereits auf 19.10 homeuse aktualisiert). Aktuell ist der Server noch auf R151024l. Dabei stoße ich auf folgendes Problem:

root@san:~# pkg unset-publisher omnios
Updating package cache                           1/1
root@san:~# pkg set-publisher -g https://pkg.omniosce.org/r151026/core omnios
root@san:~# pkg update
Creating Plan (Running solver): -
pkg update: No solution was found to satisfy constraints
No solution found to update to latest available versions.
This may indicate an overly constrained set of packages are installed.
 
latest incorporations:
 
  pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151026:20180420T093054Z
  pkg://omnios/entire@11,5.11-0.151026:20190411T175052Z
  pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151026:20180420T093326Z
  pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151026:20190411T175114Z
 
The following indicates why the system cannot update to the latest version:
 
    Reject:  pkg://omnios/incorporation/jeos/omnios-userland@11-0.151026
    Reason:  No version matching 'incorporate' dependency network/dns/bind@9.11-0.151026 can be installed
      ----------------------------------------
      Reject:  pkg://omnios/network/dns/bind@9.11.3-0.151026
      Reason:  No version matching 'require' dependency library/libedit@3.1-0.151026 can be installed
        ----------------------------------------
        Reject:  pkg://omnios/library/libedit@3.1-0.151026
        Reason:  Higher ranked publisher localhostomnios was selected
        ----------------------------------------
      Reject:  pkg://omnios/network/dns/bind@9.11.4-0.151026
      Reason:  No version matching 'require' dependency library/libedit@3.1-0.151026 can be installed
      ----------------------------------------
    Reject:  pkg://omnios/entire@11-0.151026
    Reason:  No version matching 'incorporate' dependency incorporation/jeos/omnios-userland@11-0.151026 can be installed
      ----------------------------------------
      Reject:  pkg://omnios/incorporation/jeos/omnios-userland@11-0.151026
               pkg://omnios/incorporation/jeos/omnios-userland@11-0.151026
      Reason:  No version matching 'incorporate' dependency network/dns/bind@9.11-0.151026 can be installed
      ----------------------------------------
    Reason:  No version matching 'require' dependency network/dns/bind@9.11-0.151026 can be installed
root@san:~#

Was geht hier schief?

 

[frittes]

Also ich habe ein stranges Problem. Immer wenn ich mit einem virtualisierten Windows 10 von einer externen Platte in das ZFS-Filesystem synce, ist erst das SMB im Windows und danach das NFS in der ESXI weg. Auch wenn ich von der externen Platte 1GB ins Windows kopieren will, passiert selbiges. NFS (mirror) und SMB (raid-z2) sind zwei verschiedene Pools. Vom iPhone kann ich komischerweise die SMB-Shares aufrufen. napp-it ist auf einer M2 und meldet keine Fehler.

Woran kann das liegen?

Edit: Beim Erstellen von Snapshots auf der ESXI passiert es auch.

 

[00riddler]

Lediglich aktuelles ZFS (Solaris mit sequentiellem Resilver oder neues Open-ZFS (z.B. neuestes OmniOS, ZoL, noch nicht verfügbar bei FreeNAS oder XigmaNAS) bei dem das sorted resilver heißt ist da um Größenordnung schneller weil hier die Daten soweit wie möglich sequentiell gelesen werden (Metadaten lesen, sortieren, Daten lesen)

Ist so nicht korrekt. FreeNAS macht sequentielles Resilvering bereit seit Februar/März 2018. (Ab Version 11.1)

 

[gea]

. Aktuell ist der Server noch auf R151024l. Dabei stoße ich auf folgendes Problem: ..

Was geht hier schief?

Wenn man das OS updated und in der Folgeversion Packete nicht (mehr) enthalten sind, so muss man diese vor dem Update deinstallieren

vgl Beiträge Dez 20

Element

gitter.im

Alternative
Sichern von /var/web-gui/_log/* (napp-it settings), Neunstallation von 151032 mit napp-it, Wiedeherstellen der napp-it Settings, dann Pool wieder importieren und updaten.

Beitrag automatisch zusammengeführt: 04.01.2020

Also ich habe ein stranges Problem. Immer wenn ich mit einem virtualisierten Windows 10 von einer externen Platte in das ZFS-Filesystem synce, ist erst das SMB im Windows und danach das NFS in der ESXI weg. Auch wenn ich von der externen Platte 1GB ins Windows kopieren will, passiert selbiges. NFS (mirror) und SMB (raid-z2) sind zwei verschiedene Pools. Vom iPhone kann ich komischerweise die SMB-Shares aufrufen. napp-it ist auf einer M2 und meldet keine Fehler.

Woran kann das liegen?

Edit: Beim Erstellen von Snapshots auf der ESXI passiert es auch.

Gibt es Infos in napp-it System > Log oder System > Fault oder dem ESXi Log?.

Beitrag automatisch zusammengeführt: 04.01.2020

Ist so nicht korrekt. FreeNAS macht sequentielles Resilvering bereit seit Februar/März 2018. (Ab Version 11.1)

Danke für die Info, habe ich übersehen. Reduziert zumindest auch in einem aktuellen FreeNAS/ Free-BSD das Resilverproblem mit MSR.

 

[frittes]

Das Einzige, was ich finden kann ist ein ESXI-Ereignis:

Verbindung zum Server 172.22.70.115 unterbrochen, Mount-Punkt /POOL_1/VM_IMAGES als 0de14a19-56af7258-0000-000000000000 (ZFS_VM_IMAGES) gemountet.

Gerade provoziert durch Kopieren von Daten innerhalb der Windows 10 VM.

 

[gea]

Dein ESXi Log beschreibt nur das Resultat - den Verbindungsabbruch.

Wie ist denn das Setup
- ESXi Bootlaufwerk, Controller
- OmniOS VM Speicherort, Controller
- Platten für Datenpool, Controller, pass-trough?
- sync Einstellung des NFS Dateisystems
- irgendwelche Auffälligkeiten z.B. System Log Einträge
- wie ist die Poolperformance mit/ohne sync (Menü Pools > Benchmark)

- Netzwerkkonfiguration OmniOS->ESXi, Jumoframes?
- ESXi und OmniOS Version

 

[Digi-Quick]

Das glaube ich sofort, denn genau dafür wurden die Platten ja entwickelt.
Allerdings ist SMR ja nur beim schreiben schwach (insbesondere random) und bei deinen 2% ist das locker drin.
Interessant wird's allerdings, wenn du mal einen Ausfall haben solltest und eine ersetzen musst. Der Resilver wird vermutlich ewig dauern, wenn du noch nicht auf aktuellem ZFS Stand bist.

cu

vermutlich ca. 2,5 Wochen
(Hochgerechnet aus meinem damaligen Test mit 10 HDDs)

Ich habe nochmal nachgeschaut, es sind doch schon fast 5 Jahre (gekauft im März & April 2015).
Damit sind die von Holt so oft kolportierten 5 Jahre "MHD" fast erreicht.
Daraus folgt >> statt einem Resilver würde ich vermutlich gleich ein neues NAS aufbauen, ich bin da eh schon vorsichtig am Planen....

Prinzipiell ist es ZFS egal, um was für Platten es sich handelt. MSR Platten können vor allem im Raid bei höherer Schreiblast mit kleinen Blöcken aber übel einbrechen. Seagate hat die MSR Platten auf der Open-ZFS Developper Konferenz 2014 vorgestellt. Ich erinnere mich an die Diskussion ob ZFS an diese Platten angepasst werden sollte, da der Performanceeinbruch bis zu einem Timeout mit Disk offline führen kann. Am Ende war niemand da, der Anpassungen vornehmen wollte oder das als sinnvoll erachtete. Es wurde von der Verwendung von MSR Platten im (ZFS) Raid generell abgeraten.

Ja, ich hatte das mit verfolgt, anfänglich war ja eine gewisse "Begeisterung" vorhanden, da man der Meinung war, daß ein angepaßtes ZFS für dies Platten ideal wäre.....
Daß der Performanceienbruch zu einem TIMEOUT und "DISK OFFLINE" führen kann, hatte ich nicht mitbekommen - aber nu ist's eh "zu spät". Das nächste NAS wird CMR HDDs haben

 

[gea]

Die MSR werden als Archivplatten vermarktet, also typische Anwendung ist einmal single User/Prozess vollschreiben und sonst im wesentlichen Lesen. Bei diesem Szenario ist auch Raid und ZFS kein Problem.

Für Multiuser Betrieb unter Last, Raid und höheren Füllgraden/ Fragmentierung müsste man Anpassungen vornehmen damit dass schneller funktioniert. Bei SSDs gibt es eine vergleichbare Situation. Bei denen muss man ja vor dem Schreiben/Ändern eines Bytes erstmal eine Page mit mehreren MB lesen, dann die Page löschen und geändert neu schreiben. Bei SSDs macht das die SSD Firmware im Zweifel selber - eventuell mit OS Trim Unterstützung. Bei MSR müsste das OS eine derartige Optimierung komplett liefern.

 

[frittes]

Dein ESXi Log beschreibt nur das Resultat - den Verbindungsabbruch.

Wie ist denn das Setup
- ESXi Bootlaufwerk, Controller
- OmniOS VM Speicherort, Controller
- Platten für Datenpool, Controller, pass-trough?
- sync Einstellung des NFS Dateisystems
- irgendwelche Auffälligkeiten z.B. System Log Einträge
- wie ist die Poolperformance mit/ohne sync (Menü Pools > Benchmark)

- Netzwerkkonfiguration OmniOS->ESXi, Jumoframes?
- ESXi und OmniOS Version

Ich habe die Wurzel des Übels gefunden, Einstellungen hatte ich nach HowTo von Anfang an so gemacht.

Der Dell Perc 200 Controller war es. Ich habe gestern einen Fujitsu eingebaut und siehe da, es läuft stabil. Performance ist ok, ich denke das liegt an den "langsamen" WD Red Platten.

Stresstest mit gleichzeitig Snapshots auf ESXI, Daten kopieren innerhalb VMs und Ubuntu Massenupdates liefen ohne Ausfälle.

Sync habe ich auf VM- und Datenpool deaktiviert. Blocksize auf dem VM-Pool auf 64K eingestellt. Disk-Indikator ist hauptsächlich gelb und manchmal orange bis rot.

Ich habe der napp-it aktuell 8GB RAM zugewiesen, würde mehr evtl. noch etwas Schub geben?

 

[gea]

Was für eine Firmware ist auf dem Dell?
Wenn es eine IT Firmware 20.00.00 bis 20.00.04 ist, so kann das die Ursache sein. Die ist buggy unter Last. Ok ist Firmware 20.00.07

 

[frittes]

Ich habe noch eine Frage zur Performance:

Auf dem Mirror habe ich nur 200MB/s Durchsatz, auf dem Raidz2 aber 500MB/s. Kann es sein, dass wenn ich die Mirrorplatten auf einem Controller-Strang laufen lasse, dass die langsamer sind?

Sollten die besser jeweils eine auf Strang A und eine auf B angeschlossen sein?

Falls ja, kann ich die einfach umstecken?

 

[Burnz84]

Guten Morgen,

mal eine Frage zu einem Problem, wo ich wahrscheinlich nur auf den Schlauch stehe.
Ich habe OMV auf eine SSD installiert und 3x10TB SAS per DELL Perc H310(IT Mode) als Pool für meine Daten im RAIDZ1 laufen.
Nun zur eigentlichen Frage:
Was passiert wenn meine Systemfestplatte kaputt geht bzw. ich mir das OMV-System zerschieße. Wie kann ich den Pool dann in ein neues System integrieren bzw. anbinden? Wird der automatisch gefunden, wenn ich mir das ZFS Addon installiere?
Ist bestimmt eine DAU-Frage aber ich hab gerade einen Knoten im Kopf

MfG

Burnz

 

[martingo]

Ich kenne die OMV GUI nicht, aber der Pool lässt sich über "zpool import" in jedem Fall einfach wieder einbinden. Gibt sicher auch einen Menüpunkt dazu.
Alle notwendigen Poolinformationen liegen auf dem Pool selbst.

 

[gea]

Ich habe noch eine Frage zur Performance:

Auf dem Mirror habe ich nur 200MB/s Durchsatz, auf dem Raidz2 aber 500MB/s. Kann es sein, dass wenn ich die Mirrorplatten auf einem Controller-Strang laufen lasse, dass die langsamer sind?

Sollten die besser jeweils eine auf Strang A und eine auf B angeschlossen sein?

Falls ja, kann ich die einfach umstecken?

Eine einzelne Platte hat je nach Füllgrad und Dateigrößen eine Performance zwischen sagen wir mal 50MB/s und 200 MB/s. Beim Schreiben auf einen Mirror hat man diese Performance, beim Lesen bis zum Doppelten.

Bei 6G SAS/Sata hat jeder Port die volle Performance von von 6G (ca 500MB/s). Es ist also egal wo man eine Platte einsteckt.

 

[Elektromat]

Servus,

bin grad dabei auf OmniOS (omnios-r151032-702376803e) inkl. Nappit v19dev umzustellen und könnte ein wenig Hilfestellung gebrauchen.
Die VM ist wie folgt angelegt mit 32GB RAM als feste Zuweisung:

Ich habe der OmniOS VM per Passthrough den HBA bekannt gemacht wie auch als Eintrag in der *.vmx wie folgt hinterlegt:

pciPassthru0.virtualDev = "pci"

Erst mit diesem Eintrag hab ich meine HDDs und SSDs des HBA angezeigt bekommen.

Dann wäre noch die Frage wie kann ich per SSH meine ZFS Pools Mounten? Im Solaris hatte ich das immer wie folgt gemacht, und wurde nach den Passworten der jeweiligen Shares gefragt:

zfs mount -a
zfs set sharesmb=off hddtank/Freigabe
zfs set sharesmb=on hddtank/Freigabe
....

So seint es im OmniOS nicht zu funktionieren. Wie macht man es im OmniOS?

Merkwürdiger weise bekomme ich die OmniOS VM nicht aufgelöst / angesprochen mit \\omnios\ (hostname ist angepasst). Per IP komme ich von meinem Win10 PC problemlos auf die SMB Shares drauf.
Der OmniOS host wird auch in meiner Netzwerkumgebung nicht angezeigt.

Auch ist mir aufgefallen, das wenn ich von meinem Win10 PC etwas in einen SMB Share kopiere, das die Auslastung der VM bis Max CPU Last hoch geht. Vom Solaris kannte ich es bisher so das es so um die Max 6Ghz war jetzt ca. 14Ghz, wenn man etwas per SMB drauf schreibt. Ist dies für OmniOS ein normales verhalten?

Ebenfalls wirkt die übertragung per SMB "einschlafend langsam". Bei großen Dateien um die 125MB/s , bei kleinen bricht es total ein, obwohl 10G. Gut irgendwann limitieren die Platten aber das find ich merkwürdig langsam, mit 10G Kupfer sollte doch mehr drin sein.
Das SYNC Write ist für die betroffenen Pools / ZFS Dateisyteme deaktiviert. Ebanfalls ist keine TrafficShaping Regel aktiv

Was mir noch einfällt ist die begrenzung der User tatsächlich 8 Zeichen? Kann man längere funktionierend für SMB anlegen?

Für Tips bin ich wie immer dankbar.
Gruß
Elektromat

 

[gea]

Pass-through:
Im Normalfall muss man einfach in der ESXi GUI den HBA auf Pass-through stellen und neu booten, dann den PCI Adapter der VM hinzufügen. Anpassungen z.B. in der passthrough.map benötigt man nur in "Problemfällen" z.B. bei manchen NVMe. Die BroadCom HBA sollten einfach tun.

SSH Pool Mount

zfs mount -a
zfs set sharesmb=off hddtank/Freigabe
zfs set sharesmb=on hddtank/Freigabe

ist das normale Verfahren (Groß/Kleinschreibung beachten)

SMB Connect
\\omnios sollte funktionieren wenn der Hostname aufgelöst werden kann (DNS Server oder Eintrag in /etc/hosts)

Bekannmachen von Servern
Dafür wird bei Solarish ein aktiver Windows Server oder ein Dienst wir Bonjour benötigt.
Teilweise muss man "netbios_enable=true" setzen (SMB > Service > Properties)

Performance
Eine Festplatte kann sequentiell bis zu 200MB/s, bei kleinen Daten kann das auch auf 50 MB/s einbrechen. Bei Schreiben nutzt ZFS seinen ram-cache um kleine Schreibaktionen zu vermeiden. Beim Lesen gibt es den Arc Lesecache. Der arbeitet aber nicht bei sequentiellen Daten. Um die Performance aber zu beurteilen, bräuchte ich die Ausgabe von Pool > Benchmark mit Angabe des Pool-Layouts und der Platten.

Username Länge
Da gibt es verschiedene Schwellen. Solarish ist ein Posix-Unix. Posix begrenzt die maximale Namenslänge auf 8. Jenseits davon gibt es eine Warnmeldung, der User wird aber angelegt. Wenn man in napp-it einen User anlegt, so wird der User angelegt und die Meldung gezeigt. Dadurch wird aber das Passwort nicht gesetzt. Man muss das in einem zweiten Schritt erledigen (Im nächsten napp-it wird zwar die Meldung too long kurz gezeigt, dann aber auch das Passwort gesetzt)

Windows hat eine maximale Länge von 20 Zeichen wenn man Kompatibilität mit älteren Windows Versionen will. Ohne Probleme kommt man ansonst bis 32 Zeichen, je nach Umgebung mehr.

 

[vdrschlucke]

nabend,

Ich möchte für private Daten, ohne die Notwendigkeit der Hochverfügbarkeit, ZFS auf proxmox benutzen. Nun stehe ich vor der Entscheidung:
Option1: 2 x Single Disk Pool mit set copies=2 (also insgesamt 2 HDDs) oder
Option 2: die 2 HDDs in einen Mirror pool packen und eine weitere HDD als Single Disk Pool dazustecken (also insgesamt 3 HDDs).
In jedem Fall wird dann regelmäßig vom einem auf den anderen pool gesichert und sogar eine weitere Offsite Sicherung ist angedacht. OS ist auf einer extra SSD. Momentan habe ich gerade mal 1TB Daten angesammelt.

Wie gesagt Hochverfügbarkeit ist kein Beweggrund für mich aber defekte Sektoren durch Redundanz automatisch reparieren zu können hört sich interessant an. Beide Optionen liefern das, während eine Single Disk mit set copies=1 das nicht kann. Option 1 spart die Kosten für eine zusätzliche Platte und ich rede mir ein, dass die Platte des Backup-pools auch weniger beansprucht wird, da sie ja nur während des täglichen Backups verwendet wird. Option 2 hat natürlich den großen Vorteil, dass man ein zusätzliches Backup hat und somit während des Mirror-Rebuilds zusammen mit dem Offsite Backup 2 Sicherungen hat. Andererseits habe ich oft gelesen, dass beim Rebuild gerne weitere (alte) HDDs kaputt gehen.

Was haltet ihr davon? Hab ich was übersehen? Fehlen wichtige Infos? Wie würdet ihr das machen?

Bonusfrage: Kann man Platten in einem ZFS Pool eigentlich auch mit z.B. hdparm in den Standby(Spindown) schicken? Habe das bisher mit den Platten (kein ZFS) in meinen Server so praktiziert.

Danke und VG

 

[Trambahner]

Ich schicke meinen HDD-Zpool (Raidz2 aus 6 Disks) regelmässig mit #camcontrol standby <device> (FreeBSD) in den Spindown, solange ich keine Daten davon brauche (ich hab einen zweiten Pool im Server aus SSDs). Sobald auf den HDD-Pool zugegriffen wird, dauerts halt bis die HDDs wieder da sind und I/O möglich ist.
Bis dato kein Problem, aber je HBA/OS/wasauchimmer könnte es Dir natürlich durchaus passieren, dass ZFS den Pool wg. Timeout offline nimmt. Musst Du bei Dir individuell prüfen.

 

[martingo]

Hmm, ein seltsames Konstrukt hast Du vor.

Gretchenfrage ist zunächst mal: Sollen das reine Datenpools sein oder läuft auch Proxmox auf diesen Disks?

Im ersten Fall: sollen die Platten an eine Storage VM durchgereicht werden, die dann ihrerseits selbst zfs machen müsste oder per Mountpoint an einen LXC Container durchgereicht werden auf Kosten eingeschränkter Berechtigungsmöglichkeiten? Oder soll Proxmox via Samba selbst Fileserver spielen?

Im zweiten Fall: wenn die eine Proxmoxplatte aussteigt, steht alles und booten ist von der zweiten Platte erstmal nicht möglich weil das drumherum fehlt (MBR etc).

Ich würde in beiden Fällen zur Option 3 raten: Daten auf Mirror legen, Snapshots nach dem Großvater-Prinzip anfertigen und den Pool inklusive Snapshots inkremetell auf zwei wechselnde Externplatten und/oder vollständig extern stehenden Speicher (anderer Brandabschnitt, andere Stromversorgung) übertragen.

Zur Bonusfrage: das kommt darauf an. Schlafen legen kann man Platten immer.
Sobald die Platten aber als Proxmox Storage (GUI) angelegt sind, werden sie unmittelbar wieder aufgeweckt.
Wenn sie ausschließlich über z.B. Samba verwendet werden und nicht in PVE eingebunden sind, sollten sie schlafend bleiben.
Wenn die gesamte Platte an eine VM übergeben wird, liegt das in deren Hoheit.

 

[vdrschlucke]

Proxmox liegt auf einer eigenen SSD ohne Redundanz. Da liegen auch die vdisks der VMs drauf. Die vdisks werden auf die HDDs gesichert. Raucht die SSD ab, darf ich neuinstallieren. Aber wie gesagt Hochverfügbarkeit ist mir nicht so wichtig

Auf dem Hauptpool wollte ich Datasets für z.b. NAS, plex, nextcloud einrichten. Nas ist nur ein sambashare und läuft direkt auf dem proxmox host, plex und nc sind eigene vms wo das jeweilige dataset durchgereicht werden soll. So bis jetzt der Plan.

Statt der wechselnden Externplatten möchte ich eigentlich, nach einem initialen lokalen kopieren, Sicherungen über SSH offsite verschicken. Am liebsten inkrementell dank zfs send mit snapshots. Was ich im FreeBSD Handbuch lese, geht das auch. Klar hier gibt es dann natürlich den tradeoff Sicherheit-Bequemlichkeit.

Gute Infos zum Standby, Danke.

 

[martingo]

Wir haben wohl unterschiedliche Definitionen von Hochverfügbarkeit. HV bedeutet, dass ein kompletter Standort (oder zumindest anderer Brandabschnitt, andere Stromversorgung etc) abrauchen darf ohne dass ein Nutzer außer geringfügiger Performanceeinbußen irgendwas bemerkt. Du hast in Deinem Konstrukt nichtmal minimale Redundanz. Wenn Deine SSD abraucht, bist Du nach Bekanntwerden und Arbeitsbeginn mindestens zwei bis drei Stunden beschäftigt, ehe der Host wieder rudimentär funktioniert. Ohne dass Backups zurückgespielt und Fehler durch halbgare Snapshots laufender VMs beseitigt sind.

 

[Elektromat]

Pass-through:
Im Normalfall muss man einfach in der ESXi GUI den HBA auf Pass-through stellen und neu booten, dann den PCI Adapter der VM hinzufügen. Anpassungen z.B. in der passthrough.map benötigt man nur in "Problemfällen" z.B. bei manchen NVMe. Die BroadCom HBA sollten einfach tun.

SSH Pool Mount

zfs mount -a
zfs set sharesmb=off hddtank/Freigabe
zfs set sharesmb=on hddtank/Freigabe

ist das normale Verfahren (Groß/Kleinschreibung beachten)

SMB Connect
\\omnios sollte funktionieren wenn der Hostname aufgelöst werden kann (DNS Server oder Eintrag in /etc/hosts)

Bekannmachen von Servern
Dafür wird bei Solarish ein aktiver Windows Server oder ein Dienst wir Bonjour benötigt.
Teilweise muss man "netbios_enable=true" setzen (SMB > Service > Properties)

Performance
Eine Festplatte kann sequentiell bis zu 200MB/s, bei kleinen Daten kann das auch auf 50 MB/s einbrechen. Bei Schreiben nutzt ZFS seinen ram-cache um kleine Schreibaktionen zu vermeiden. Beim Lesen gibt es den Arc Lesecache. Der arbeitet aber nicht bei sequentiellen Daten. Um die Performance aber zu beurteilen, bräuchte ich die Ausgabe von Pool > Benchmark mit Angabe des Pool-Layouts und der Platten.

Username Länge
Da gibt es verschiedene Schwellen. Solarish ist ein Posix-Unix. Posix begrenzt die maximale Namenslänge auf 8. Jenseits davon gibt es eine Warnmeldung, der User wird aber angelegt. Wenn man in napp-it einen User anlegt, so wird der User angelegt und die Meldung gezeigt. Dadurch wird aber das Passwort nicht gesetzt. Man muss das in einem zweiten Schritt erledigen (Im nächsten napp-it wird zwar die Meldung too long kurz gezeigt, dann aber auch das Passwort gesetzt)

Windows hat eine maximale Länge von 20 Zeichen wenn man Kompatibilität mit älteren Windows Versionen will. Ohne Probleme kommt man ansonst bis 32 Zeichen, je nach Umgebung mehr.

Danke für deine Rückmeldung.
Hab leider grad nen Kopierprozess laufen, so kann ich grade schlecht testen.

Wenn ich als root per SSH zfs mount -a absetze, passiert leider nichts.
Und das obwohl einzelne ZFS Dateisysteme auf Status locked stehen. In solaris ging das ohne probleme.

Im ESXi steht der HBA bereits wegen dem zuvor verwendeten Solaris auf Pass-Through.
Der HBA ist auch der OmniOS VM als PCI Device konfiguriert.
Folgend das Pool Layout. Die Platten sind 4x Ironwolf Pro 12TB:

was mir auffällt ist , das wenn ich im Nappit Pro monitor schaue das die Disk Auslastung wie folgt ist:

Ist das denn normal das die OmniOS VM die komplette CPU belegt sobald ich Daten auf ein ZFS Dateisystem via SMB schreibe? Wie gesagt das Solaris hatte egal wann nur um die max. 6Ghz, ohne das ich per Resourcen Pool im vCenter limitiert habe gezogen.

Den folgenden Screenshot habe ich erstellt beim zurückschreiben von Daten via SMB:

weitere Infos inkl. Benchmarks folgen sobald ich etwas mehr Zeit habe.

 

[martingo]

Locked deutet auf verschlüsselte Datasets hin. Dann musst Du "zfs mount -a -l" machen. -l für loadkey.

Ebenfalls bei der CPU falls Annahme bzgl. Verschlüsselung korrekt: nutzt die VM AES-NI der Host CPU?

 

[Elektromat]

Locked deutet auf verschlüsselte Datasets hin. Dann musst Du "zfs mount -a -l" machen. -l für loadkey.

Ebenfalls bei der CPU falls Annahme bzgl. Verschlüsselung korrekt: nutzt die VM AES-NI der Host CPU?

Dateisysteme sind verschlüsselt. Wie auch zuvor im solaris.
Bedeutet das das die ver- und entschlüsselung via CPU läuft im OmniOS, er ggf nicht korrekt auf den AES-NI Befehlssatz des Hosts zurückgreift?

Definiere nutzt die VM AES-NI der Host CPU? ... da stehe ich etwas aufm Schlauch.
Kann man hier was machen, das die Last runter geht? Bzw. was für Optionen hätte man, wie sollte man vorgehen wenn möglich?

Ist das ne Bios Einstellung von meinem Host?
Im Handbuch meines Boards steht folgendes:

Folgend die BIOS - CPU Configuration:

Es ist eingestellt auf Enable.

 

[Elektromat]

Wie kann ich denn herausfinden ob meine OmniOS VM korrekt auf den AES-NI Befehlssatz der Host CPU zugreift?

Folgend der Filebench zu meinem HDD Pool hddtank

zfs mount -l hddtank/Freigabe funktioniert soweit.
Wie muss ich das zfs set sharesmb=on hddtank/Freigabe anpassen das auch der korrekte Share Name gesetzt wird?

Wenn ich es so ausführe, werden die shares hddtank_Freigabe benannt.

 

[zos]

Wie muss ich das zfs set sharesmb=on hddtank/Freigabe anpassen das auch der korrekte Share Name gesetzt wird?

Wenn ich es so ausführe, werden die shares hddtank_Freigabe benannt.

zfs set sharesmb=name=myshare hddtank/Freigabe wird den share „myshare“ benennen. Setzt Du ihn auf auf myshare$ wird er ebenfalls “myshare“ benannt, ist aber nicht sichtbar, d. h. Du musst den smb-share-Namen wissen, um Dich damit zu verbinden.

 

[martingo]

Er wird dann myshare$ benannt und ist auch so einzugeben.
Sonst korrekt, aber das ist nur eine sehr sehr rudimentäre Unsichtbarkeit und nur für administrative Freigaben wie netlogon etc gedacht. Fast alles außer dem Windows Explorer zeigt die Freigabe trotzdem an.

Wobei das ja auch nicht die Frage war.

 

[gea]

Folgend der Filebench zu meinem HDD Pool hddtank

900MB/s ist nicht schlecht. Allerdings zeigt das eher die Qualität des Caches an.
Bitte direkt das Menü Pool > Benchmarks aufrufen.

Damit kann man eine Reihe von Benchmarks starten, sequentiell und io basiert, mit und ohne sync

Den Sharenamen kann man beim Aktivieren des Shares in napp-it eingeben (Name statt on)