Dann schaffen deine Platen also kein 4GB/s
Gut zu wissen 
Vielleicht wiederholst du mal den Test ohne ARC.
Was schaffst du beim Kopieren großer Dateien über Netzwerk? Bevorzugt SMB
Mit allem aus sind die Werte jetzt schon etwas schlechter 
Write
Read
Hehe ich baue halt realtiv viel am zfs rum und habe das auch ab und an mit debug compiliert.
Bei rsync habe ich im mit der 2.2.2 auf beiden Systemen (FreeBSD 14 und Arch Linux) > 720 Mbyte im Schnitt gehabt bei 25 TByte (hauptsächlich sehr grosse Dateien) - aktuell habe ich 2.2.3 das ein bisschen langsamer.
SMB habe ich nur per 2.5 Gbit im Moment - die 10 Gbit sind linux/BSD etc.
Die Performance der ZFS Versionen finde ich schwankt doch relativ stark - evtl auch je nach Kernel ZFS Kombination usw. Mit älteren 1.x oder vor OpenZFS war ich auch schon bei knapp 10 Gbit permanent augelastet.
Das "Problem" ist halt es gibt aktuell immer noch so viele Fixes- die sicher extrem unwahrscheinlich auftreten - aber ich compilier mir auf 2 Systemen trotzdem dann immer neue ZFS-Versionen .... lediglich der Hauptserver ist "stock".
Write
Code:
fio --name=seqwrite --rw=write --ioengine=posixaio --bs=1M --numjobs=1 --size=10G --runtime=60 --end_fsync=1 --filename=/tank/notcrypted/write.abc --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
.....
Run status group 0 (all jobs):
WRITE: bw=606MiB/s (635MB/s), 606MiB/s-606MiB/s (635MB/s-635MB/s), io=10.0GiB (10.7GB), run=16910-16910msecRead
Code:
fio --name=seqread --rw=read --ioengine=posixaio --bs=1M --numjobs=1 --size=10G --runtime=60 --end_fsync=1 --filename=/tank/notcrypted/read.abc --group_reporting
seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=1071MiB/s][r=1071 IOPS][eta 00m:00s]
.....
Run status group 0 (all jobs):
READ: bw=1035MiB/s (1085MB/s), 1035MiB/s-1035MiB/s (1085MB/s-1085MB/s), io=10.0GiB (10.7GB), run=9897-9897msecHehe ich baue halt realtiv viel am zfs rum und habe das auch ab und an mit debug compiliert.
Bei rsync habe ich im mit der 2.2.2 auf beiden Systemen (FreeBSD 14 und Arch Linux) > 720 Mbyte im Schnitt gehabt bei 25 TByte (hauptsächlich sehr grosse Dateien) - aktuell habe ich 2.2.3 das ein bisschen langsamer.
SMB habe ich nur per 2.5 Gbit im Moment - die 10 Gbit sind linux/BSD etc.
Die Performance der ZFS Versionen finde ich schwankt doch relativ stark - evtl auch je nach Kernel ZFS Kombination usw. Mit älteren 1.x oder vor OpenZFS war ich auch schon bei knapp 10 Gbit permanent augelastet.
Das "Problem" ist halt es gibt aktuell immer noch so viele Fixes- die sicher extrem unwahrscheinlich auftreten - aber ich compilier mir auf 2 Systemen trotzdem dann immer neue ZFS-Versionen .... lediglich der Hauptserver ist "stock".
Zuletzt bearbeitet:
Danke. Das sind schon mal realistische Werte. Write scheint mit Platten und RAID-Z2 nicht mehr zu gehen. Aber die Read Performance ist bei mir doch wesentlich geringer 😡
Bin halt auf der letzten TrueNAS Scale stable 🤷♂️
Ich war schon froh fio endlich halbwegs korrekt ausführen zu können. Die ursprünglich kopierte Commandline aus einem Forum hat lediglich meine Boot-SSD vollgeschrieben und Fantasiewerte geliefert.
Bis ich das gecheckt habe, warum und wie ich überhaupt die angelegten Files wieder lösche 🤦♂️
Es ist frustrierend von dem ganzen Linux Kram keine Ahnung zu haben. Mit Google habe ich mich Befehl für Befehl vorgetastet und auch eine ausführlichere Erklärung zu fio gefunden.
Unter Windows hätte ich im Explorer sofort gesehen was Sache ist...
Bin halt auf der letzten TrueNAS Scale stable 🤷♂️
Haha
Ich war schon froh fio endlich halbwegs korrekt ausführen zu können. Die ursprünglich kopierte Commandline aus einem Forum hat lediglich meine Boot-SSD vollgeschrieben und Fantasiewerte geliefert.Bis ich das gecheckt habe, warum und wie ich überhaupt die angelegten Files wieder lösche 🤦♂️
Es ist frustrierend von dem ganzen Linux Kram keine Ahnung zu haben. Mit Google habe ich mich Befehl für Befehl vorgetastet und auch eine ausführlichere Erklärung zu fio gefunden.
Unter Windows hätte ich im Explorer sofort gesehen was Sache ist...
wddn
Enthusiast
Hallo zusammen, ich nutze seit einigen Monaten TrueNAS Scale mit ZFS, aber eine Ueberarbeitung steht an. Was wuerdet ihr mir empfehlen?
Das ganze ist auch im TrueNAS forum gepostet auf englisch.
Irgend etwas scheine ic hfalsch zu machen mit dem special vDev fuer die Pool Metadaten:
Ich ueberlege gerade ob ich 2x Optane P1600X 58GB reinwerfen soll, aber habe die Vermutung dass ic hbei der Anlage (TNS default) irgend etwas mit der "ZFS record size" und "zfs set special_small_blocks" falsch eingestellt habe.
On top: Mit 128GB RAM denke ich nicht, dass ich L2ARC benoetige. Im Moment habe ich auc hkein SLOG drive:
Habe ich es richtig verstanden dass SLOG nicht redundant sein muss, da selbst bei einem Defekt nur die Daten der letzten Sekunden verloren waeren? Drittes Optane 58GB SSD?
Was meinen die Experten?
sudo zpool list -v
find . -type f -print0 | xargs -0 ls -l | awk '{ n=int(log($5)/log(2)); if (n<10) { n=10; } size[n]++ } END { for (i in size) printf("%d %d\n", 2^i, size) }' | sort -n | awk 'function human(x) { x[1]/=1024; if (x[1]>=1024) { x[2]++; human(x) } } { a[1]=$1; a[2]=0; human(a); printf("%3d%s: %6d\n", a[1],substr("kMGTEPYZ",a[2]+1,1),$2) }'
sudo zdb -Lbbbs -U /data/zfs/zpool.cache storage
Das ganze ist auch im TrueNAS forum gepostet auf englisch.
Irgend etwas scheine ic hfalsch zu machen mit dem special vDev fuer die Pool Metadaten:
Ich ueberlege gerade ob ich 2x Optane P1600X 58GB reinwerfen soll, aber habe die Vermutung dass ic hbei der Anlage (TNS default) irgend etwas mit der "ZFS record size" und "zfs set special_small_blocks" falsch eingestellt habe.
On top: Mit 128GB RAM denke ich nicht, dass ich L2ARC benoetige. Im Moment habe ich auc hkein SLOG drive:
Habe ich es richtig verstanden dass SLOG nicht redundant sein muss, da selbst bei einem Defekt nur die Daten der letzten Sekunden verloren waeren? Drittes Optane 58GB SSD?
Was meinen die Experten?
sudo zpool list -v
find . -type f -print0 | xargs -0 ls -l | awk '{ n=int(log($5)/log(2)); if (n<10) { n=10; } size[n]++ } END { for (i in size) printf("%d %d\n", 2^i, size) }' | sort -n | awk 'function human(x) { x[1]/=1024; if (x[1]>=1024) { x[2]++; human(x) } } { a[1]=$1; a[2]=0; human(a); printf("%3d%s: %6d\n", a[1],substr("kMGTEPYZ",a[2]+1,1),$2) }'
sudo zdb -Lbbbs -U /data/zfs/zpool.cache storage
Da es keine Blocks > 128K gibt, steht recsize wolhl auf 128K.
Da von dem Special vdev nur 20G genutzt werden, so werden das wohl allenfalls Metadaten sein, keine small io Daten.
Wie sind denn die Einstellungen und was soll erreicht werden?
Zum Slog.
Korrekt, darf ausfallen, letzte paar Sekunden write können verloren sein. Ist das aber VM Storage so kann das tödlich für ein VM Dateisystem sein.
Da von dem Special vdev nur 20G genutzt werden, so werden das wohl allenfalls Metadaten sein, keine small io Daten.
Wie sind denn die Einstellungen und was soll erreicht werden?
Zum Slog.
Korrekt, darf ausfallen, letzte paar Sekunden write können verloren sein. Ist das aber VM Storage so kann das tödlich für ein VM Dateisystem sein.
wddn
Enthusiast
128K ZFS record size ist TrueNAS Scale default... korrekt
Da ich die Virtualisierung zukuenftig zu 99% auf meinem Proxmox Hypervisor machen will, waere das ok. Einzig wichtige VM: Proxmox Backup Server (PBS)
Ich habe die default size fuer zfs set special_small_blocks verwendet -> wahrscheinlich sollte ic hmal ein bisschen erhoehen -> 32k
Da ich die Virtualisierung zukuenftig zu 99% auf meinem Proxmox Hypervisor machen will, waere das ok. Einzig wichtige VM: Proxmox Backup Server (PBS)
Ich habe die default size fuer zfs set special_small_blocks verwendet -> wahrscheinlich sollte ic hmal ein bisschen erhoehen -> 32k
Release Notes for OmniOS v11 r151048
r151048t (2024-03-22)
Release Notes
illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support
omnios.org
Security Fixes
- AMD CPU microcode has been updated to 20240116.
- Intel CPU microcode has been updated to 20240312.
- Introduced a workaround for the recently published Intel Register File Data Sampling [RFDS] vulnerability in some Intel Atom CPUs - INTEL-SA-00898
- Fix for a kernel panic in the SMB server caused by a race between cancel and completion functions - illumos 15985.
- SHA-2 calculations that use libmd and a very large block size couldproduce incorrect hashes.
- A POSIX normal lock would not properly deadlock on re-entry in a single-threaded application - illumos 16200.
- Clock calibration in KVM environments now retrieves the clock frequencydirectly via an MSR. This fixes the calculation in environments such as AWS.This calibration method was previously only tried in VMWare guests.
- Added support for e1000g I219 V17 and LM+V24-27,29 network cards.
- The ena network driver has received a number of fixes that make it morestable on multi-processor instance types, and support for device reset hasbeen added.
Was ich oft gelesen habe, ist dass das special vdev nicht weniger sicher als die Daten vdevs sein soll, weil ohne die Metadaten alles weg ist. Wie sieht das umgekehrt aus? Wenn der Pool hops geht weil ein vdev ausfällt, hab ich dann weiter Zugriff auf die Daten die über small blocks vollständig auf dem special metadata vdev gelandet sind, oder ist dann ebenfalls alles weg?
Habs nicht wirklich anders erwartet, aber da ja sowohl Daten als auch Metadaten noch vorhanden sind, hatte ich eine geringe Hoffnung. Aber danke das du mir das ausprobieren erspart hast.
Gibt es Erfahrungswerte zu QLC SATA SSD Pools mit TLC/SLC oder gar Optane NVMe special vdev? Abseits von datasets die über small blocks vollständig auf der NVMe landen, ergibt das irgendeinen Vorteil, oder pure Verschwendung? Ich hab ein wenig gegoogled, aber nichts gefunden. Meine Überlegungen warum das helfen könnte:
- SSDs sind bei mixed workloads grundsätzlich langsamer. Wenn ich den QLC SSDs den Metadaten und evtl small blocks Zugriff abnehmen kann, verschiebt sich die Last vielleicht ausreichend von komplett gemischt zu schreibend oder lesend das die Performance steigt.
- Basierend auf der großen Page- und Blocksize von QLC SSDs gehe ich davon aus, das die write amplification hier deutlich schlimmer ist als mit TLC und es ein ingesamt guter Deal ist, die Gesundheit der TLC NAND Zellen für die QLC SSDs zu opfern.
- Da die Latenz von QLC SSDs höher ist (ich meine 7x höher als TLC gelesen zu haben), könnte bei metadaten intensiven Operationen ein geringer Geschwindigkeitsvorteil drin sein.
Ergibt das Sinn, oder phantasier ich mir Luftschlösser zusammen?
Gibt es Erfahrungswerte zu QLC SATA SSD Pools mit TLC/SLC oder gar Optane NVMe special vdev? Abseits von datasets die über small blocks vollständig auf der NVMe landen, ergibt das irgendeinen Vorteil, oder pure Verschwendung? Ich hab ein wenig gegoogled, aber nichts gefunden. Meine Überlegungen warum das helfen könnte:
- SSDs sind bei mixed workloads grundsätzlich langsamer. Wenn ich den QLC SSDs den Metadaten und evtl small blocks Zugriff abnehmen kann, verschiebt sich die Last vielleicht ausreichend von komplett gemischt zu schreibend oder lesend das die Performance steigt.
- Basierend auf der großen Page- und Blocksize von QLC SSDs gehe ich davon aus, das die write amplification hier deutlich schlimmer ist als mit TLC und es ein ingesamt guter Deal ist, die Gesundheit der TLC NAND Zellen für die QLC SSDs zu opfern.
- Da die Latenz von QLC SSDs höher ist (ich meine 7x höher als TLC gelesen zu haben), könnte bei metadaten intensiven Operationen ein geringer Geschwindigkeitsvorteil drin sein.
Ergibt das Sinn, oder phantasier ich mir Luftschlösser zusammen?
pwnbert
Enthusiast
- Mitglied seit
- 30.10.2014
- Beiträge
- 3.633
So billig sind QLCs zum jetzigen Zeitpunkt nicht, dass man sich über sowas gedanken machen sollte.
... so denke ich.
8 TB U.2 gibts ab und zu in vernünftigen Preisregionen, das ist dann auch Datacenter Ware und kein Sandisk QLC. Z1 und gut.
... so denke ich.
8 TB U.2 gibts ab und zu in vernünftigen Preisregionen, das ist dann auch Datacenter Ware und kein Sandisk QLC. Z1 und gut.
wddn
Enthusiast
Aktuell nutze ich Micron 7300 Pro als Special vDev… Wie gut dies funktioniert kann ich dir nicht sagen, da ich erst vor kurzem und nach vielen Monaten gemerkt habe dass small block size = 0 war. Hat zwar 20GB an Daten aber wird nicht richtig genutzt…
2x Optane P1600X 118GB sind auf dem Weg zu mir und ich werde meinen Pool in ein paar Wochen neu aufbauen.
Der Trick ist die “richtige” small block size zu definieren: so groß wie möglich und ca. 50-75% Füllstand deiner special vDev devices…
Sobald man eine größere small block size setzt, landen nicht nur die Metadaten sondern ein Teil der Daten auf dem special vdev. Dann hängt es von der Nutzung ab. Bei einer sbs von 64K oder 128K landen bei einem Office Filer fast alle Daten auf dem special vdev und das ist dann sehr schnell voll. Bei einem Mediafiler landen gar keine Dateien auf dem special vdev sofern recsize > sbs.
Da man recsize und sbs per Dateisystem definieren kann, ist man allerdings flexibel. Auch kann man mehr als einen special vdev mirror haben und man kann per disk replace kleinere NVMe gegen größere tauschen. Man sollte aber das special vdev bei sbs >32K nicht zu klein wählen. Zwei Optane 1600 -118G sind das schnellste was man überhaupt haben kann, für größere sbs aber oft zu klein Hängt sehr von der Art der Daten ab.
Zuletzt bearbeitet:
wddn
Enthusiast
Ich habe ein paar Reports (Block size diagram) auf dem jetzigen Fileserver laufen lassen (siehe oben).
Record size wird allgemein auf 128k gesetzt (TNS default) und für Videos, Musik, Books setzte ich diese auf 1M.
Small block size: 16k geplant was ca 90GB füllen sollte.
Im Endeffekt ein tiered storage…
Record size wird allgemein auf 128k gesetzt (TNS default) und für Videos, Musik, Books setzte ich diese auf 1M.
Small block size: 16k geplant was ca 90GB füllen sollte.
Im Endeffekt ein tiered storage…
Klassisches Tiering arbeitet mit hot (neueste oder per use case) und cold (alle anderen) Daten
ZFS "Tiering" unterscheidet per Datenstruktur zwischen small io und alle anderen.
Im Endeffekt halte ich ZFS "Tiering" für den intelligenteren Ansatz da dabei das Umkopieren wegfällt.
Ich betreibe seit bald 3 Jahren ein Z1 bestehend aus 4 Micron ION 5210 7,68TB SATA SSDs (QLC).
Keine speziellen Geraete wie Optane oder sonstiger Kram in Place. Einfach nur das Array.
Was magst denn wissen?
@p4n0 Die Micron ION 5210 sind interessant, mir war bis eben nicht bewusst, das es QLC SSDs ohne SLC Cache gibt. Allerdings zumindest aktuell etwas teuer.
Im Grunde interessiert mich ob das ganze einfach wie langsamere TLC SSDs ist, oder ob QLC sich wirklich anders verhält. Außerdem die zu erwartende Performance, bzw wie viele davon ich in ein Z1 packen müsste um 10Gbit/s oder 25GBit/s auszureizen. Wenn du zB große Dateien kopierst (mixed read write, groß genug das der ARC beim Lesen nicht zu viel unterstützt), wie schnell ist das? Lokal und/oder über SMB.
Während ZFS dank COW schreibend grundsätzlich langsamer als NTFS ist, leiden SSDs scheinbar besonders. Zumindest meine Consumer Samsung SATA und NVMe SSDs. Daher wollte ich nicht einfach irgendwelche CrystalDiskMark Benches der SSDs als Basis nehmen. Außerdem hab ich online wenig konkrete Zahlen gefunden, und wenn, dann von Leuten die Probleme hatten.
Wie brauchbar ist so ein QLC Z1 für mixed random read write? Kann ich da ein paar VMs und NFS oder MINIO für Kubernetes PVCs drauf laufen lassen, oder sollte ich mir dafür ein extra TLC SDD mirror anlegen?
Im Grunde interessiert mich ob das ganze einfach wie langsamere TLC SSDs ist, oder ob QLC sich wirklich anders verhält. Außerdem die zu erwartende Performance, bzw wie viele davon ich in ein Z1 packen müsste um 10Gbit/s oder 25GBit/s auszureizen. Wenn du zB große Dateien kopierst (mixed read write, groß genug das der ARC beim Lesen nicht zu viel unterstützt), wie schnell ist das? Lokal und/oder über SMB.
Während ZFS dank COW schreibend grundsätzlich langsamer als NTFS ist, leiden SSDs scheinbar besonders. Zumindest meine Consumer Samsung SATA und NVMe SSDs. Daher wollte ich nicht einfach irgendwelche CrystalDiskMark Benches der SSDs als Basis nehmen. Außerdem hab ich online wenig konkrete Zahlen gefunden, und wenn, dann von Leuten die Probleme hatten.
Wie brauchbar ist so ein QLC Z1 für mixed random read write? Kann ich da ein paar VMs und NFS oder MINIO für Kubernetes PVCs drauf laufen lassen, oder sollte ich mir dafür ein extra TLC SDD mirror anlegen?
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 515
Ich fürchte du kommst gut ein Jahr zu spät, die 5210 gibts nicht mehr und ich sehe auch sonst keine interessanten QLC in der Enterprise Klasse mehr.
OmniOS AiO setup von ESXi nach Proxmox umziehen:
https://forums.servethehome.com/index.php?threads/napp-it-for-proxmox.32368/#post-419886
https://forums.servethehome.com/index.php?threads/napp-it-for-proxmox.32368/#post-419886
Bei mir laeuft eine TrueNas Core VM auf einem ESXi7, Hardware siehe Sig.
Die Appliance hat 4 Kerne und 64GB RAM zugewiesen.
Das ganze Storage-Gelump haengt an einem dediziertem VSWITCH auf dem ESX, damit die VMs zuegig auf das NAS zugreifen koennen.
Eine Windows VM kann mit > 16gbps mit großen Daten auf dem Storage hantieren (lesend)
(Copy von SMB Share auf lokale OS Disk - ist eine NVMe auf dem Host).
Die andere Richtung habe ich nicht genau im Kopf, geht jedenfalls stark in Richtung maximum was die SSDs hergeben.
Generell laeuft das Ding sehr 'flutschig', also in allen Belangen genug Performance fuer mich.
Ob ich das Array als VMStorage nutzen wuerde? Eher nicht. Denke mit einigen roedelnden VMs faehrt man die QLCs relativ schnell an die Wand.
Nach sehr langer Zeit (mind. 2 Jahre) habe ich heute mal wieder versucht ein aktuelles r151048 stable Release von OmniOSce (USB: omnios-r151048m.usb-dd) zu installieren und danach napp-it. Bei der napp-it Installation fliegt die ganze Zeit folgender Fehler:
Framework error: code: E_SSL_CACERT (60) reason: SSL certificate problem: certificate is not yet valid
URL: 'https://pkg.omnios.org/r151048/core'
Bei einer frischen Installation sollte doch das certificate und repository etc. alles korrekt sein? Ein 'pkg update' liefert natürlich das Gleiche.
Was mache ich falsch?
Die Installation von r151048 ist fehlerfrei durchgelaufen und das System läuft auch im Netzwerk und ich konnte meinen alten Pool wieder importieren.
Framework error: code: E_SSL_CACERT (60) reason: SSL certificate problem: certificate is not yet valid
URL: 'https://pkg.omnios.org/r151048/core'
Bei einer frischen Installation sollte doch das certificate und repository etc. alles korrekt sein? Ein 'pkg update' liefert natürlich das Gleiche.
Was mache ich falsch?
Die Installation von r151048 ist fehlerfrei durchgelaufen und das System läuft auch im Netzwerk und ich konnte meinen alten Pool wieder importieren.
Das war's. Vielen Dank gea!
Ja da hast Du natürlich völlig recht. Kaum machts man richtig, gehts.
Zuletzt bearbeitet:
Ich nutze aktuell Napp-IT auf OmniOS in einer VM basierend auf ESXi. Ich hab Napp-IT pro/home inkl. der Backup-Lizenz gekauft. Bisher hab ich die Backup-Lizenz nicht genutzt. Wollt ich jetzt machen, geht aber aus folgendem Grund nicht:
Bin gerade dabei, mir ein Ugreen NASync DXP 8800 Plus zu schießen (das große mit 8 bays): https://www.kickstarter.com/project...level-storage-limitless-possibilities?lang=de
Die 6 und 8 bay Version haben 2x 10G-NICs. Wenns dumm läuft und da nicht zufällig ein Dual-Port Intel-NIC verbaut ist, hab ich so die Befürchtung, dass da 2x 10G Marvell-NICs verbaut sind. Für diese NICs gibts keine Treiber für ESXi, FreeBSD und Illumos-basierte Betriebssysteme. Lediglich Windows und Linux werden dann laufen. Warum ich das vemute? Es wurden bereits Samples der kleineren Versionen mit bis zu 4 bays rausgeschickt, die teilweise 1x 2,5G und/oder 1x 10G-NICs haben. Die 2,5G waren immer Intel i226-v, die 10G immer Marvell AQC 119.
Nun stellt sich mir die Frage: Kann Napp-IT auf OmniOS auch auf TrueNAS SCALE (Linux-basiert mit OpenZFS) backupen? Weil, das wäre dann mein favorisiertes OS für diese Hardware.
Bin gerade dabei, mir ein Ugreen NASync DXP 8800 Plus zu schießen (das große mit 8 bays): https://www.kickstarter.com/project...level-storage-limitless-possibilities?lang=de
Die 6 und 8 bay Version haben 2x 10G-NICs. Wenns dumm läuft und da nicht zufällig ein Dual-Port Intel-NIC verbaut ist, hab ich so die Befürchtung, dass da 2x 10G Marvell-NICs verbaut sind. Für diese NICs gibts keine Treiber für ESXi, FreeBSD und Illumos-basierte Betriebssysteme. Lediglich Windows und Linux werden dann laufen. Warum ich das vemute? Es wurden bereits Samples der kleineren Versionen mit bis zu 4 bays rausgeschickt, die teilweise 1x 2,5G und/oder 1x 10G-NICs haben. Die 2,5G waren immer Intel i226-v, die 10G immer Marvell AQC 119.
Nun stellt sich mir die Frage: Kann Napp-IT auf OmniOS auch auf TrueNAS SCALE (Linux-basiert mit OpenZFS) backupen? Weil, das wäre dann mein favorisiertes OS für diese Hardware.
Napp-it kann nicht zu TrueNAS replizieren (nur manuell nicht über die GUI)
Das normale napp-it läuft zwar auf Linux und kann mit der Solaris Version replizieren, kann aber nicht neben TrueNAS installiert werden.
Bleiben folgende Optionen:
1. AiO mit Proxmox (Debian) als Basis OS anstatt ESXi
Darauf eine beliebige Storage VM entweder was mit Linux und SAMBA oder Illumos mit dem Solaris SMB Server.
Mit OmniOS unter Proxmox kann man natürlich Daten replizieren.
www.hardwareluxx.de
2. Napp-it cs
Damit kann man ZFS unter Linux (Proxmox, Truenas) und OmniOS managen und Daten zwischen den dreien replizieren.
Napp-it cs kann man unter Windows herunterladen und ohne Installation starten. Auch auf OmniOS, Proxmox oder Truenas muss man die App ( cs_server ) lediglich irgendwohin kopieren und starten.
Das normale napp-it läuft zwar auf Linux und kann mit der Solaris Version replizieren, kann aber nicht neben TrueNAS installiert werden.
Bleiben folgende Optionen:
1. AiO mit Proxmox (Debian) als Basis OS anstatt ESXi
Darauf eine beliebige Storage VM entweder was mit Linux und SAMBA oder Illumos mit dem Solaris SMB Server.
Mit OmniOS unter Proxmox kann man natürlich Daten replizieren.
[Sammelthread] - Proxmox Stammtisch
https://www.tuxis.nl/de/wir-gehen-nach-deutschland/ Dürfte wohl für uns Home-User keinen nennenswerten Unterschied machen.
www.hardwareluxx.de
2. Napp-it cs
Damit kann man ZFS unter Linux (Proxmox, Truenas) und OmniOS managen und Daten zwischen den dreien replizieren.
Napp-it cs kann man unter Windows herunterladen und ohne Installation starten. Auch auf OmniOS, Proxmox oder Truenas muss man die App ( cs_server ) lediglich irgendwohin kopieren und starten.
Schade, dass Napp-IT nicht über die GUI auf TrueNAS replizieren kann.
Bisher haben die meisten Leute meinem Empfinden nach Napp-IT auf ESXi virtualisiert. Gibts denn mittlerweile breitere Erfahrung auf Proxmox? Hab VMUG Advantage Lizenzen und müsste nicht zwingend wechseln, solang es diese Möglichkeit noch gibt.
Napp-IT cs: Da musste ich erstmal nachschauen was das ist. Scheint ja noch recht neu zu sein. Klingt interessant, aber da muss ich mich erstmal noch bisschen aufschlauen.
Bisher haben die meisten Leute meinem Empfinden nach Napp-IT auf ESXi virtualisiert. Gibts denn mittlerweile breitere Erfahrung auf Proxmox? Hab VMUG Advantage Lizenzen und müsste nicht zwingend wechseln, solang es diese Möglichkeit noch gibt.
Napp-IT cs: Da musste ich erstmal nachschauen was das ist. Scheint ja noch recht neu zu sein. Klingt interessant, aber da muss ich mich erstmal noch bisschen aufschlauen.
