So, mal noch eine kurze Rückmeldung. Ich habe am Wochenende den Server noch einmal komplett herunter, um die SATA-Anschlüsse zu prüfen. Mit der Folge, dass danach keine einzige VM mehr starten wollte (es konnte keine Verbindung zur VM aufgebaut werden). Ich habe Stunden damit verbracht, das zu analysieren. Ich war schon kurz davor, ESXi neu zu installieren. Letzter Versuch nach zweimaligem Ausschalten + Server stromlos machen - und die VMs starteten wieder einwandfrei. Und was soll ich sagen: seither ist der Zugriff auf die Pool-Übersicht oder die Filesysteme wieder in ordentlicher Zeit da. Keine Ahnung, was der Kiste quer im Magen lag. Sowas mag ich ja gar nicht, Probleme, die kommen und gehen, ohne dass man erkennen könnte, warum… Napp-It war jedenfalls nicht schuld, sondern offenbar das Blech... 😉
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 543
Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?
Also Mainboard, Controller etc?
Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also
Manueller-Snap1
Replikations-Snap (veraltetet) -> wird gelöscht
Manueller-Snap2
Sorry für die vielen Fragen…
Beitrag automatisch zusammengeführt:
Will ich nicht ausschließen. Hardware siehe System in meinem Profil - sollte gepflegt sein. 😉
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 543
OK, also bei der Hardware musst du schon mal damit rechnen, das es so komische Effekte gibt.
Elektronik altert einfach.
Elektronik altert einfach.
Das einzige Fehlverhalten, was ich ggf. auf Hardware schieben würde, wäre das im März berichtete nicht herunterfahren wollen der Napp-It VM. Ich denke inzwischen, dass der damalige Datenverlust des Paperless Docker Containers eher ein Docker Problem war (was ich zugegebenermaßen aber noch nicht verstanden habe…).
Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…
Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…
Recursive Replikation überträgt alle datasets (auch tieferliegende Dateisysteme, Zvols, Snaps). Das kann manchmal Probleme bereiten wenn man nach der Erstreplikation erwas ändert. Replikations Snaps werden nach der Übertragung umbenannt (mit Hinweis auf die Regel um den Snap zu behalten)
Einfach ausprobieren.
ZFS Anyraid
Status: Projektidee
Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.
Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)
Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR
hexos.com
Status: Projektidee
Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.
Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)
Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR
Introducing ZFS AnyRaid, Sponsored by Eshtek — HexOS
At the beginning of this year, we made the decision to invest a substantial chunk of capital to support an open source project for which we have great personal interest. ZFS AnyRaid will give users the ability to mix different sized drives in a pool, a highly-requested feature since our la
hexos.com
Hoffentlich wird das *irgendwann* gefixt: https://www.illumos.org/issues/4896
Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.
Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.
Luckysh0t
Enthusiast
Das habe ich vor ein paar Jahren auch festgestellt, mit einem Freund, als wir OmniOS als Alternative zu Solaris getestet hatten als VM Filer....aber das war wirklich ein graus...
Mittlerweile nutze ich OmniOS als FIler, aber wie schon mein Solaris direkt auf Blech. Allerdings nur mit einem HDD Mirror und Gbit Lan..mit Verschlüsselung. Solaris ist ca. +-20 MB/s schneller.
Für mich ist OmniOS damit solange raus. Hab aber keine Lust wieder zurück zu Solaris zu gehen. Ich werde solange Truenas Scale nochmal eine Chance geben, auch wenn ich die UI für zu fancy und aufgeblasen finde.
@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?
@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?
Zuletzt bearbeitet:
ja, napp-it cs.
Ich habe allerdings noch kein howto dabei, um Apache zu installieren und zu starten. Man müsste sich an der Proxmox oder OSX Anleitung orientieren oder das Web Frontend auf Windows oder Linux/Proxmox laufen lassen und nur den backend server starten um Free-BSD remote zu managen.
OpenZFS 2.3.0 für OSX ist jetzt eine Release Edition, kein release candidate mehr
github.com
OpenZFS 2.3.1 rc8 für Windows hat die meisten Kinderkrankheiten hinter sich
github.com
Release zfs-macOS-2.3.0 · openzfsonosx/openzfs-fork
Upstream changelog RAIDZ Expansion (openzfs#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime. Fast Dedup (openzfs#15896): A major performance upgrade...
github.com
OpenZFS 2.3.1 rc8 für Windows hat die meisten Kinderkrankheiten hinter sich
Releases · openzfsonwindows/openzfs
OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com
Guten Morgen,
ein Medien-ZFS-Raid wo vielleicht max 4 Streams gleichzeitig drüber laufen sollen mit 14 TB SATA Platten. Macht man da ein Striped Mirror oder was in Richtung RAIDZ2 ? Und reicht das so oder muss man da mit SSDs und ARC und L2ARC was machen? Ist eher ein Datengrab, als das darauf Videoschnitt oder sowas betrieben werden soll...
ein Medien-ZFS-Raid wo vielleicht max 4 Streams gleichzeitig drüber laufen sollen mit 14 TB SATA Platten. Macht man da ein Striped Mirror oder was in Richtung RAIDZ2 ? Und reicht das so oder muss man da mit SSDs und ARC und L2ARC was machen? Ist eher ein Datengrab, als das darauf Videoschnitt oder sowas betrieben werden soll...
Einfach ein Z2 machen und für ausreichend RAM sorgen (min 16GB). Vom RAM nutzt OpenZFS dann 50% als Lesecache (Arc), sollte für 4 Streams reichen wenn es nicht gerade 8k streams sind. L2Arc wird kaum was bringen, eher ein special vdev mirror um metadaten zu beschleunigen oder ein recsize von 1M für geringere Fragmentierung und einen read ahead alike Effekt. Den Pool eventuell nicht zu voll machen, das kostet Performance.
Es folgt gefährliches Halbwissen:
Also ich habe sogar nur 2 MG10ACA20T 20TB Sata stumpf als ZFS-Mirror derzeit, laut Datenblatt schaffen die 268 MiB/s. Das Mirror bringt da bereits ja theoretisch eine Verdoppelung beim Lesen, dann noch der ARC des ZFS. Meine 4K Medien sind encodiert (MakeMKV + Handbrake) und keine reinen UHD-Disk-Backups, heißt deren Bitrate ist auch bereits niedriger, aber sehr deutlich über dem was Netflix und co als 4K-Stream ausliefern.
@gea Wie könnte ich denn lokal einmal unter Proxmox 8.4 die tatsächliche Leseleistung meines ZFS-Mirros benchen?
Also ich habe sogar nur 2 MG10ACA20T 20TB Sata stumpf als ZFS-Mirror derzeit, laut Datenblatt schaffen die 268 MiB/s. Das Mirror bringt da bereits ja theoretisch eine Verdoppelung beim Lesen, dann noch der ARC des ZFS. Meine 4K Medien sind encodiert (MakeMKV + Handbrake) und keine reinen UHD-Disk-Backups, heißt deren Bitrate ist auch bereits niedriger, aber sehr deutlich über dem was Netflix und co als 4K-Stream ausliefern.
@gea Wie könnte ich denn lokal einmal unter Proxmox 8.4 die tatsächliche Leseleistung meines ZFS-Mirros benchen?
nach reboot (arc cache leer):
entweder mit dd ein file nach /dev/null kopieren
dd bs=1M count=256 if=your_file of=/dev/null
oder mit pv
apt install pv
pv file > /dev/null
oder ein benchmarktool installieren
Code:
root@prox1:/tank0/media_root# dd if=/dev/zero of=groesse_4gb.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1.4117 s, 3.0 GB/s
root@prox1:/tank0/media_root# pv groesse_4gb.img > /dev/null
4.00GiB 0:00:01 [3.00GiB/s] [======================================>] 100%
Beitrag automatisch zusammengeführt:
Hm, da dürfte schon der RAM arbeiten, auch wenn das kurz nach dem Reboot war, oder?
