Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
So wie ich das verstanden habe, wird bei ZFS basierten Systemen nie zum Hardware Raid Controller geraten, weil dieser die benötigten Daten vorher abgreifft.
Etwas präziser weil der Hardware Raid keine Prüfsummen auf Daten und Metadaten kann (keine Möglichkeit Daten zu validieren) und kein Copy on Write beherscht (atomare Operationen wie Daten schreiben und Metadaten aktualisieren oder eine Raid Operation über mehrere Platten werden immer komplett geschrieben oder verworfen), http://www.raid-recovery-guide.com/raid5-write-hole.aspx
ZFS könnte diese Probleme vermeiden, sieht bei Hardware Raid aber nur eine Platte und kann daher nichts reparieren. Die Crashsicherheit von ZFS mit Copy on Write funktioniert bei Hardware Raid auch nicht mehr.
Ergo: Man verliert mit Hardwareraid zwei der wichigsten ZFS Features.
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hab ich auch nicht verstanden. Ein 1265Lv2 z.B. ist auch heute noch eine der besseren CPUs für ein ZFS-NAS (daheim jedenfalls). Wieviel weniger denn zieht ein X11 Board (SM) gegenüber einem X9?
Ihr solltet vielleicht nicht Dinge aus dem Zusammenhang reissen und den Ausgangspunkt lesen. Ein User wollte einen >Filer< bauen und dafür einen Ivy mit Sockel >2011< einsetzen
Und das hielt und halte ich für energie-ineffizient für daheim.
=> Es ging nicht um einen E3 Ivy und nicht um PVE.
Das kann man so lassen, sich aber ein Bild draus machen geht nur, wenn paar der angedachen Alternativen erwähnt würden (mit welchen man ebenfalls ZFS fahren kann).
Jetzt mal außer, daß mir an der Stelle die wohl notwendige Weiterbildung bezüglich der Begrifflichkeiten fehlt, da ich grad auf keine Ideen komme wie ein ZFS-System nicht als "Filer" eingesetzt werden kann. Ändert sich da was dran, wenn z.B. Proxmox mitmischt?
Jetzt mal außer, daß mir an der Stelle die wohl notwendige Weiterbildung bezüglich der Begrifflichkeiten fehlt, da ich grad auf keine Ideen komme wie ein ZFS-System nicht als "Filer" eingesetzt werden kann. Ändert sich da was dran, wenn z.B. Proxmox mitmischt?
Als VM Storage. Ist aber jetzt nicht an Proxmox gebunden.Aber ein Filer ist wohl für die meisten eher ein Ablageort von Dateien als denn ein Speicher für seine VM.Und ja mir ist klar das VMs auch nur Dateien sind xD.
1. Man hat meist konkurrierende parallele Zugriffe. Sollen die VMs schnell reagieren, muss man das Augenmerk vor allem auf hohe iops und geringe Latenz legen. Idealerweise also SSD/NVMe Speicher. Unter ZFS sollte man zudem die recsize z.B. auf 32k oder 64k verkleinern um zu vermeiden dass man unnötig Daten lesen/schreiben muss.
2. Wegen der deutlich besseren Performance nutzt man RAM als Lese/Schreibcache. Stürzt das System ab so ist normalerweise der Inhalt des Schreibcaches verloren. Bei VM Storage kann das ein korruptes Gast Dateisytem zu Folge haben. Darf also nicht passieren. Bei ZFS kann man sync aktivieren um korrupte Gast Dateisysteme zu vermeiden. Den massiven Performanceeinbruch von sync write kann man bei Verwendung von Festplatten unter ZFS mit einem Slog in Grenzen halten (z.B. Optane DC 4801X)
Ihr solltet vielleicht nicht Dinge aus dem Zusammenhang reissen und den Ausgangspunkt lesen. Ein User wollte einen >Filer< bauen und dafür einen Ivy mit Sockel >2011< einsetzen
Und das hielt und halte ich für energie-ineffizient für daheim.
=> Es ging nicht um einen E3 Ivy und nicht um PVE.
ich lerne mich gerade selbst ein und habe folgende Festplatten-Situation: Welche Einstellungen (best practice) und weshalb würdet ihr vornehmen? Ich werde ca. 4x VMs und 30-40 Container haben. Der Speicherplatz für alle zusammen ist ca. 750 Gb. Es ist ein Server für Forschungszwecke an der Uni. Mehr Speicherplatz ist ohne Probleme beschaffbar
Es gibt ja nur die Optionen Raid-0 (2 x basic vdev/single disk) oder Raid-1 (Mirror).
Da 750GB reichen ist die Empfehlung klar ein Mirror.
ps
-ZFS Pools erden ab ca 50% Füllrate langsamer, ab ca 80% deutlich langsamer
-Für VM Storage auf jeden Fall sync aktivieren auch wenn es Performance kostet. Die Samsung 883 haben ja Powerloss Protection
Das Problem ist bei Festplatten besonders ausgeprägt. Bei manchen NVMe wie Intel Optane ist es nicht vorhanden. Bei normalen SSD ist der Einbruch bei Desktop SSD stark und bei Enterprise SSD mit viel Overprovisioning geringer. Ursache ist dass mit höherem Füllgrad weniger freie Blocks z.B. 512 MB gibt. In dem Fall müssen teilweise freie Blocks gelesen, gelöscht und neu geschrieben werden. Mit Trim kann man das Problem verringern. Das kostet aber bei einem System unter Last auch Performance, vgl https://www.thomas-krenn.com/de/wiki/Solid-State_Drive
Die Vorschläge für einen ZFS... "Filer" , der nicht immer mal erlahmt und nicht so eine vermeindliche Stromschleuder ist wie ein 45W Xeon v2 (Ivy), sind welche nun? Da gabs doch starke Einwände (?)
Die jeweiligen Anschaffungspreise betrachtend...
Ich werde mich voraussichtlich gegen ende des Jahres mit Proxmox beschäftigen und möchte als Datengrab und VM Storage voraussichtlich ZFS einsetzen.
Bestehende alte Hardware kommt zum Einsatz.
I5 4440 (später I7 4790k)
32GB RAM (non ECC)
5x WD Green 3TB (noch 5 Stück von ehemalig 7)
2x WD Red 3TB
4x Samsung Evo 850 250GB
6x Samsung Evo 840 250GB
Es handelt sich um eine private Umgebung, aktuell werden 4,2TB Speicherplatz gebraucht, davon ist nur ca, 1TB wirklich wichtig. Ich würde nutzbare 8TB anstreben.
Ein Großteil der Daten sind Filme und Musik (sterbende optische Datenträger liegen im Keller und können wenn noch lesbar neu abgelegt werden).
Wichtige Daten werden alternierend auf zwei Platten wöchentlich als Backup gesichert.
Die Greens sind seit 2014 im Dienst im Raid 5 (eine ist 2015 im Raid 5 verstorben, eine von einer Woche - als Backup und Externe im Einsatz gewesen).
Die restlichen greens sehen von den SMART Werten super aus. Ich sehe kein Problem mit den Greens im Raid und sie haben sich eigentlich bewährt, reds fallen auch nicht seltener aus...
4disk-raidz1 nativ
5disk-raidz1 erweitert
5disk-raidz1 nativ
5disk-raidz2 nativ
5disk-raidz2 erweitert
5disk-raidz1 nativ
2*2disk-stripped mirrors nativ
3*2disk-stripped mirrors nativ
1. Disk
2,72
2,72
2,72
2,72
2,72
2,72
2,72
2,72
2. Disk
2,72
2,72
2,72
2,72
2,72
2,72
2,72
2,72
3. Disk
2,72
2,72
2,72
2,72
2,72
2,72
2,72
2,72
4. Disk
2,72
2,72
2,72
2,72
2,72
2,72
2,72
2,72
5. Disk
2,72
2,72
2,72
2,72
2,72
2,72
6. Disk
2,72
2,72
2,72
Rohkapazität
10,88
13,6
13,6
13,6
16,32
16,32
10,88
16,32
Nutzbar
8,16
10,88
10,336
8,16
9,973
10,88
5,44
8,16
Nutzbar %
75
80
76
60
61,11
66,67
50
50
Plattenausfälle
1
1
1
2
2
2
1
1
Wenn man sich etwas einliest stellen sich mit folgende Fragen:
Inzwischen ist scheinbar auch raidz1/2 erweiterbar, habt Ihr Erfahrungen? (mit Speicherplatznachteilen)
Warum werden keine 4 Platten raidz1 empfohlen/eingesetzt?
Würdet Ihr Green und Red im raidz1/2 oder im stripped Mirror mischen?
Wenn 2x2-auf 3x2-stripped Mirrors erweitert werden, wie verhält sich die Performance, da wird doch auch nichts umgeschichtet das müsste doch so "langsam" sein wie ein einzelner Mirror.
Greift bei stripped Mirror die gleiche Fehlererkennung wie bei raizz1/2 (gekippte bits)?
Der I5 4440 ist doch kein Flaschenhals für die Parity Berechnung, oder doch.
Was würdet Ihr empfehlen, und warum?
Grundsätzlich: jede Platte welche nicht gebraucht entspräche einer Energieeinsparung und es stehen mehr Ersatzplatten/Backupplatten zur Verfügung.
Variante 1: 4disk-raidz1 - 8TB nutzbar - 1 Plattenausfall ist ok - vollständiges Backup auf restlichen Platten und eine Ersatzplatte
Variante 2: 5disk-raidz2 - 8TB nutzbar - 2 Plattenausfälle sind ok - vollständiges Backup der wichtigen Daten, sollte ausreichen wegen doppelter Parität
Variante 3: 2x2disk-striped-Mirror - 5,4TB nutzbar - 1 Plattenausfall ist ok - vollständiges Backup auf restlichen Platten und eine Ersatzplatte, voraussichtlich Erweiterung in kürze und dann nur noch Backup auf einer Platte...
Danach muss ich mir mal überlegen was man mit den SSDs anstellen kann. Cache/VM-Storage...
1. Kommt erst und ist ein "kritisches" Feature. Würde ich nicht am Tag 1 einsetzen
2. Weil bei einem Lesefehler im degraded Status ein Datenverlust droht
3.ZFS ist das egal, die langsamere Platte definiert die Performance
4. Schreibperformance im Mirror ist immer wie eine Platte, Leseperfomance ist n * Plattenanzahl
5. Ja durch Prüfsummen auf ZFS Datenblöcke
6. Kommt darauf an. Wenn man > 1 GByte/s Durchsatz will oder schnelle Verschlüssellung braucht man Power, vgl https://napp-it.org/doc/downloads/epyc_performance.pdf
ansonst:
Raid schützt vor Plattenausfall
Backup vor Disaster (Feuer, Diebstahl)
Versionierung/Snaps vor Ransomware, Sabotage oder Hoppla, habe ich leider vor 2 Wochen gelöscht.
ad 2, RAID-Z1 wegen stripe size nur auf drei oder fünf Platten. Geht zwar, ist aber performancetechnisch ungünstig, weil 128k nicht durch drei (Datenplatten) teilbar.
Es gilt:
RAID-Z1 = 2^n + 1 Disks, also 3,5,9
RAID-Z2 = 2^n + 2 Disks, also 4,6,10
RAID-Z3 = 2^n + 3 Disks, also 5,7,11
ad 2, RAID-Z1 wegen stripe size nur auf drei oder fünf Platten. Geht zwar, ist aber performancetechnisch ungünstig, weil 128k nicht durch drei (Datenplatten) teilbar.
Es gilt:
RAID-Z1 = 2^n + 1 Disks, also 3,5,9
RAID-Z2 = 2^n + 2 Disks, also 4,6,10
RAID-Z3 = 2^n + 3 Disks, also 5,7,11
Gut. Ich wollt grad fragen, ob das noch aktuell ist.
Ist das dann aber so gemeint "spielt keine wirkliche Rolle mehr"?
Oder eher "die Vorteile dessen sind nahezu vernachlässigbar"?
Beides
Wenn man Compress aktiviert spielt es überhaupt keine Rolle mehr
andernfalls ist es vernachlässigbar, da
-man wesentlich flexibler beim Pool Layout ist
-allenfalls eine bis zu ca 10% geringere nutzbare Kapazität die Folge ist
-man eh meist irgendwann Kompress aktiviert (meist bessere Performance bis auf Ultra High Performance, mehr Kapazität, kaum Nachteile)
Ich bin aktuell bei 4TB und würde ein Array mit 8TB anstreben. Also am ersten Tag bräuchte ich es nicht. Nach aktuellem Datenzuwachs eher in 1-2 Jahren.
Wenn ich es "heute" oder direkt bräuchte würde ich direkt einen größeren Pool ansetzen...
ansonst:
Raid schützt vor Plattenausfall
Backup vor Disaster (Feuer, Diebstahl)
Versionierung/Snaps vor Ransomware, Sabotage oder Hoppla, habe ich leider vor 2 Wochen gelöscht.
Das ist klar, weiterhin sol gelten: Raid gegen Downtime, Backup gegen Datenverlust, dazu kommen dann wenn möglich Snapshots
Zusätzliche Info, das System hängt an einer USV.
Danke für den Hinweis, auch an ludwinator. Ich hatte hier gelesen und wollte sowieso LZ4 ausprobieren.
Dann wird es voraussichtlich ein 5-disk-raidz2 mit LZ4 aus den 5 greens. LZ4 werde ich direkt aktivieren, nach allem was man liest bringt es mehr Vorteile als Nachteile bei durchschnittlich starker CPU.
Aus den SSDs würde ich gerne einen raidz1 Pool anlegen und diesen als cache (L2ARC und ZIL) einsetzen.
Wenn L2ARC ausfällt wird's nur so langsam wie das Festplattenarray.
Wenn ZIL ausfällt steht Datenverlust bevor falls die Daten noch nicht auf das Festplattenarray geschrieben wurden.
Dabei stellen sich wieder mehrere Fragen:
Welche Größe darf der ZIL SLOG haben, ist er RAM abhängig?
L2ARC sollte nicht größer als 10*RAM sein, wenn ich 10GB verwenden möchte und der Rest für VMs gebraucht wird darf der L2ARC also nur 100GB betragen. Das würde mehr Daten fassen können als bei uns ungefähr Täglich in Benutzung sind (ohne Archivzugriffe).
Alles was im L2ARC Liegt sind doch Kopien und liegt auch noch auf dem Festplattenarray vor oder nicht?
Kann das SSD-Raid Array für ZIL SLOG + L2ARC * REST Partitioniert werden, sodass der Rest als SSD Pool für durchsatzintensive Anwendungen (VM) eingesetzt werden kann?
Gibt's ne Einstellung den ZIL zu deaktivieren sobald eine Platte des SSD-Pool ausfällt bis diese ersetzt und der rebuild durchgeführt ist?
ZIL wäre also in einem System mit 32GB Ram ca 3GB groß, mit 10Gbit also in ca 3s voll.
PS: Macht Spaß und man Lernt mehr wenn man sich unterhält
EDIT: Berichtigung auf Hinweis von asche77, Verwechslung ZIL <-> SLOG
1 - 10% des RAM, max. 4GB
1 - ZIL max 4GB, SLOG das doppelte, es genügen also 8GB SLOG. Gemeinhin nimmt man sicherheitshalber 10GB.
3 - korrekt
4 - bloss nicht - dabei stehen sich doch alle Prozesse im Weg!
5 - nein; warum auch? Du könntest zwar sync writes ausschalten das wäre aber nicht zu empfehlen (wenn beim Auto die Bremsen nicht gehen, schnallst Du ja auch nicht den Sicherheitsgurt ab). Dann lieber VMs ausschalten und resilver abwarten.
6 - ja in etwa
(Btw, ZIL ist immer aktiv (für sync writes), Du scheinst das mit dem SLOG zu verwechseln)
4 - bloss nicht - dabei stehen sich doch alle Prozesse im Weg!
5 - nein; warum auch? Du könntest zwar sync writes ausschalten das wäre aber nicht zu empfehlen (wenn beim Auto die Bremsen nicht gehen, schnallst Du ja auch nicht den Sicherheitsgurt ab). Dann lieber VMs ausschalten und resilver abwarten.
Zu 4. Schon klar das der SLOG nur etwas bringt wenn auch die Bandbreite bereitsteht, aber es handelt sich hier um eine private Umgebung und der Durchsatz ist zu 95% der Zeit nicht vorhanden beim rest werden Datenmengen hin und her geschoben. Daher dachte ich wenn es mal zusammenkommt leiden eben beide Anwendungen aber es müsste ein 9-SSD-raidz1 mit mehreren Zugriffen doch immer noch schneller als 2-SSD-Mirror für SLOG, 2-SSD-Stripe für L2ARC und 5-SSD-raidz1 für VMs sein. Wäre das wirklich so abstrus?
Zu 5. Wie du schon schriebst, hab ich das verwechselt, es ging um SLOG.
Bei so einem großen ssd Pool würde ich den L2ARC eh gleich weglassen...
Da alle drei (SLOG, L2ARC und VMs) um Schreibzugriffe konkurrieren, wären separate SSD(-mirror/-raidz) definitiv performanter. Denn 1 raidz = 1x SSD write iops. 3 separate mirrors/raidz = 3x soviele write iops. Gleiches für den schreib-Durchsatz.
Wenn der Performance unterschied für Deinen use case keine Rolle spielt, brauchst Du vermutlich auch kein L2ARC und vermutlich nicht Mal ein SLOG.
Beitrag automatisch zusammengeführt:
Was Du überlegen könntest:
1 schnelle SSD für hypervisor( proxmox) und SLOG. Der hypervisor sollte nicht viel schreiben und dann gibt es keine Konkurrenz um Schreibzugriffe mit VMs (wenn die auf einem separaten Pool liegen)
Guten Morgen,
alt bekanntes Sprichwort sagt - never chance a running system - damit fahre ich auch seit Jahren recht gut damit.
Inzwischen ist mir aber bei meinem AIO ein 3-fach Mirror zu 96% vollgelaufen. Der Pool ist nun fast nicht mehr nutzbar.
Der zweite Mirror Pool, worauf die VMs liegen läuft problemlos weiter.
zpool status
pool: pool_aio
state: ONLINE
scan: scrub repaired 0 in 11h47m with 0 errors on Sun Aug 1 17:47:19 2021
config:
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 0h5m with 0 errors on Sun Aug 1 06:05:05 2021
config:
NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess
rpool ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0 32.2 GB Virtual disk S:0 H:0 T:0
errors: No known data errors
Ich möchte jetzt mit gea's napp-it erstmalig ein Disk replace machen - von 4TB auf 8TB. Von den guten alten HGST's auf WD Red Plus WD80EFBX.
In zpool status ist zu sehen, dass der letzte Scrub fast 12 Std gedauert hat.
1. Kann ich davon ausgehen, dass auch das resilvern für jede einzelne HDD auch knappe 12 Std. dauern wird?
2. Geht mir vermutlich das ganze System in den 12 Std. in die Knie, so dass es besser sein wird, wenn ich über Nacht ein HDD Austausch mache? Oder rennt mein VM-Pool problemlos weiter?
3. Wann muss ich unter Pools Expand auf on stellen, damit der Pool auf 8TB erweitert wird? Vor der Replace-Aktion oder an Ende mit der 3 HDD?
Ich habe zwar noch keine Erfahrung, aber bei stripped Mirror müsstest du den Mirror welchen du erweiterten willst auch auf einen 3fach mit der neuen Platte erweitern können und dann die alten abtrennen lassen. Online ohne zeitweilig gefährdet zu sein, dass wenn die die 2. Platte währenddessen die grätsche macht den Pool geschrottet zu haben. Kann natürlich nur gehen wenn noch ein Anschluss für ne Platte frei ist. Replacing all disks in a ZFS mirror without taking it offline.
@BazzT ich möchte den Pool nicht erweitern, sondern jede einzelne der 3 alten HGST 4TB gegen eine neue WD 8TB austauschen.
Ja, ich habe noch freie Slots um eine Neue einzustecken, replace der Alten und dann die Alte aus dem Slot ziehen.
1 - ja, 12std könnte hinkommen. Sehr grob geschätzt.
2 - VM Pool läuft weiter, aber der resilver braucht auch CPU - besser also über Nacht.
3 - ich vermute, das ist egal.
Wenn Du noch einen Slot frei hast, kannst Du ja
- neue Platte rein und auf 4fach mirror erweitern, resilver abwarten
- zwei alte Platten raus (2fach mirror online, 2fach mirror offline!) und 2 neue dazu für resilver
- letzte alte Platte raus
Evtl vor der ganzen Aktion den Pool auf read only stellen, damit es konsistent bleibt und keine Schreiblast reingrätscht.
@asche77
1und 2 - genau das hab ich befürchtet - dann dauert die Austauschaktion locker mal 3 Tage, denn die VM's müssen ungebremst rennen.
Der Vorschlag von dir - erschließt sich mir nicht, welchen Vorteil mir diese Aktion bringen soll. Klar, die Redundanz bleibt so in jedem Falle erhalten.
Warum auf read only stellen? Die Daten müssten doch auch so konsistent bleiben, gut das mit der Schreiblast ist ein Argument, wenn ich aber vor jeder Tauschaktion die VM's runterfahre und alle Zweibeiner im Bettchen liegen, dürfte die Schreiblast gegen 0 tendieren.
Mein Vorschlag war gedacht, bei (nur) einem freien Slot mit 2x resilver auszukommen und trotzdem immer online Redundanz zu haben.
Wenn Du viele freie Slots hast, kannst Du natürlich direkt mit 1 resilver auf 6fach mirror erweitern und anschließend die alten HDD raus und wieder auf 3fach mirror reduzieren.
, der nicht immer mal erlahmt und nicht so eine vermeindliche Stromschleuder ist wie ein 45W Xeon v2 (Ivy), sind welche nun? Da gabs doch starke Einwände (?)
