[Sammelthread] ZFS Stammtisch

Hallo, ist es dem ZFS irgendwie möglich, dateien, die oft benötigt werden und allgemeines schreib cache auf die ssd's zu verlagern?
Ungefähr so, wie es bei Microsoft Storage realisiert ist?
Ich halte das für nicht so gut. Windows benutzt Tiers. Sprich wenn die Datei oft benötigt wird wandert sie auf die SSD, wird aber von der HDD gelöscht.
Das heißt du musst auch die SSDs Redundant ausführen. Machst du Doube Parity, also 2 Platten können ausfallen, dann benötigst du schon 3 SSD, hast aber grade mal die Kapazität von einer. Microsoft begründet dass man eben die gleiche Sicherheit (2 Geräte können ausfallen) eben auch bei den SSDs dann haben muss.

Ich weiß nicht. Da finde ich den ZFS Ansatz einfach besser wenn auf der SSD nur Kopien liegen. Da ist man auch viel flexibler, weil man nicht auch die SSDs noch redundant ausführen muss.

Beispiel für Single Parity:

Microsoft SS: Mindestens 3 Festplatten und mindestens 2 SSDs (nur 50% effektiv nutzbar)
ZFS: Mindestens 3 Festplatten mindestens eine SSD (komplett nutzbar)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
So, hdd erfolgreich ersetzt. Hab jetzt 2x1tb als mirror laufen.
Vorher waren es 1x1tb und 1x 750gb.
Der pool is jetzt nur 750gb groß. Krieg ich den irgendwie auf die vollen 1tb ohne alles neu zu machen?

Hast Du die pool-property "autoexpand" auf "on" stehen?

zpool get autoexpand <poolname>

auf on setzen:

zpool set autoexpand=on <poolname>
 
Ich halte das für nicht so gut. Windows benutzt Tiers. Sprich wenn die Datei oft benötigt wird wandert sie auf die SSD, wird aber von der HDD gelöscht.
Das heißt du musst auch die SSDs Redundant ausführen. Machst du Doube Parity, also 2 Platten können ausfallen, dann benötigst du schon 3 SSD, hast aber grade mal die Kapazität von einer. Microsoft begründet dass man eben die gleiche Sicherheit (2 Geräte können ausfallen) eben auch bei den SSDs dann haben muss.

Ich weiß nicht. Da finde ich den ZFS Ansatz einfach besser wenn auf der SSD nur Kopien liegen. Da ist man auch viel flexibler, weil man nicht auch die SSDs noch redundant ausführen muss.

Beispiel für Single Parity:

Microsoft SS: Mindestens 3 Festplatten und mindestens 2 SSDs (nur 50% effektiv nutzbar)
ZFS: Mindestens 3 Festplatten mindestens eine SSD (komplett nutzbar)

Diese über Redundanz für einfache Daten zuhause finde ich überflüssig.
Es wurden seit Anbeginn der Zeit PC's mit nur eine Festplatte verkauft, und niemand beschwerte sich über irgendwas. Ich habe noch rechner in der Firma, die eine Festplatte aus dem Jahr 1995 haben und alles funktioniert.

Ich finde, es währe recht sinnvoll Daten/Blöcke die oft/schnell benötigt werden, auf die SSDs auszulagern.
Ein beispiel,
bei mir starten Rechner über iscsi, es währe recht sinnvoll diese Start Daten die Windows Booten auf einem schnellem speicher anstelle von HDDs zu spiechern. Vll auch noch nur bei diesem Speicher die Deduplizierung zu nutzen.

Es macht finde ich keine recht viele 40gb zvol's auf der ssd zu nutzen. Obwohl vll. nur 5% davon benutzt wird.
 
Sorry, ich meine nicht "recht", sondern "sinn". Autovervollständigung hat wieder mal versagt.
Was ich damit meine.

Ich hab zB 20x40gb zvol volumes die über iscsi freigegeben sind.
Hier werden ca 30 fast gleiche windows8 installation von PCs gebootet und 10 Linux/bds systemen. Später wird es mehr sein.
Alle diese zvols auf die ssd zu schieben, finde ist eine Platzverschwendung.
Windows benötigt vll. nur ein paar hundert MB bis es vollständing hochgefahren ist.
Währe es nicht sinnvoller diese daten, so zusagen ins Cache auszulagern?
Oder anderes Beispiel.
Ich schneide grad ein film, jedes Frame liegt als TIFF auf dem storage mit der Auflösung von 5120×2700 pixel. Es sind mehrere stunden Bildmaterial vorhanden.
Allerdings sind die metadaten in eine art sqlite Tabelle gespeichert zusammen mit Previews und Schnittmarken. Diese Datei ist kleiner als 1TB
Auf diese wird sehr oft zugegriffen und previews neu geschrieben, falls irgendwelche Effekte dazukommen.

Währe es nicht klasse, wenn ZFS von sich selbst erkennt, das auf diese Blöcke sehr oft zugegriffen wird und diese auf ein schnelleres speicher verschiebt?


(der letzte film den ich so bearbeitet habe, war knapp 40TB groß).
 
Macht es doch. Es verschiebt aber nicht sondern kopiert. Windows SS verschieben. Fürs Lesen macht das kein Unterschied, für die Redundanz aber schon da man dadurch die SSDs ebenfalls redundant ausführen muss, wie ich bereits schrieb. Genau das finde ich bei ZFS eben besser gelöst, dass man eben mit Kopien auf den SSDs nur arbeitet und daher auch keine Redundanz braucht.

Fallen die SSDs bei den Storage Spaces aus, ist der Pool im Eimer. Bei ZFS verlierst du nur etwas Performance.
 
Zuletzt bearbeitet:
@VivianMeally
Ich möchte wetten das ZFS das sehr gut in deinem Sinne regeln würde, häng doch einfach mal ne SSD als Cache dazu und beobachte, was passiert.
also: zpool add poolname cache devicename

Noch ne Frage: Bootest du die Clients auch per iSCSI ?
 
Zuletzt bearbeitet:
Ja, ich boote diese auch über ISCSI.
Manche booten mit Intel ISCSI manch mit iPXE. Mit ipxe gefällt es mir besser, da ich hier ein menü erstellen kann und snapshots oder Rollbacks direkt in diesem menü machen kann.
 
Wie sind die zvols organisiert, gibt es ein master-zvol ( mit der Windows Basisinstallation) und davon hast du Clone angelegt? Oder benutzt du dedup?

cu
 
Ich habe so das gefühl das zvol nicht besonders gut mit dedup funktioniert. Die schreib und leseraten sinken rapide, wenn ich ein zvol mit dedup anlege.

Ja, es gibt ein Mater Zvol mit allen benötigen Einstellungen und Updates. Wenn du win installierst, ist es sinnvoll vor dem schalten die ip oder dhcp lease freizugeben bevor du die snapshots davon machst.

Leider muss dieses vorgang bei jedem windows update wiederholt werden, damit nicht alle 30 snpashots die gleichen updates ziehen und installieren. Software kann mittelst AD Gruppenrichtlinien dann in die einzelne zvols installiert werden.
 
Also benutzt du jetzt zfs clone von diesem master oder nicht? Dedup würd ich nicht machen, aber mit clone erreichst du ähnliche Einsparungen bei unveränderter Performance.

cu
 
Hast Du die pool-property "autoexpand" auf "on" stehen?

zpool get autoexpand <poolname>

auf on setzen:

zpool set autoexpand=on <poolname>

Jep, hab ich.

root@epoxy:~# zpool get autoexpand tank NAME PROPERTY VALUE SOURCE tank autoexpand on local
root@epoxy:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 7,66G 677G 31K /tank
tank/lxc 7,65G 677G 31K /tank/lxc
tank/lxc/containers 48K 677G 30K /tank/lxc/containers
tank/lxc/gallium 6,95G 93,0G 3,60G /usr/local/var/lib/lxc/gallium/rootfs
tank/lxc/wolfram 713M 99,3G 523M /usr/local/var/lib/lxc/wolfram/rootfs
 
ja, ich benutze zfs clone. Werde später paar ssds kaufen und ausprobieren.

Dann wiederhol ichs lieber nochmal:

Alleine die Header zur Verwaltung des L2Arc kosten ca. 3% Speicher, ergo 100GB auf ner SSD im L2Arc verbrauchen 3GB ARC. Also nicht übertreiben mit dem L2Arc und lieber 16GB Ram nachschieben als ne weitere SSD.
 
Gibt es eigentlich irgendwelche Nachteile wenn man mehr als einen pool hat?
 
Ja, dedup, Clone, SLOG und L2ARC arbeiten nur Poolbezogen.
Das soll natürlich nicht heißen, das mal alle Platten grundsätzlich in einem Pool zusammenfassen soll.

cu
 

OK, dann hilft ggf ein zpool online -e <pool> <device>, siehe hierzu auch entsprechende Beschreibung in der Oracle Doku

Ja, dedup, Clone, SLOG und L2ARC arbeiten nur Poolbezogen.
Das soll natürlich nicht heißen, das mal alle Platten grundsätzlich in einem Pool zusammenfassen soll.
cu

Bist Du sicher dass dedup und Clone Pool-bezogen arbeiten und nicht vielmehr ZFS-Filesystem-bezogen?
 
Wunderbar, das wars. Vielen Dank! :)
 
OK, dann hilft ggf ein zpool online -e <pool> <device>, siehe hierzu auch entsprechende Beschreibung in der Oracle Doku



Bist Du sicher dass dedup und Clone Pool-bezogen arbeiten und nicht vielmehr ZFS-Filesystem-bezogen?


Ja. Du kannst ein und das selbe SLOG device nicht mehreren Pools zuordnen, gleiches gilt für L2ARC.
Zum Clone: https://www.illumos.org/issues/5610 geht natürlich prinzipiell nicht, schmeisst momentan sogar nen Core.
Die DDT (dedup) ist an den Pool gebunden. Du kannst aber trotzdem dedup auf Filesystemebene ein- und ausschalten.

cu
 
Bist Du sicher dass dedup und Clone Pool-bezogen arbeiten und nicht vielmehr ZFS-Filesystem-bezogen?

Ein Clone wird aus einem Snapshot erzeugt und ist damit Dateisystem-bezogen.
Dedup arbeitet leider poolweise obwohl man es Dateisystembezogen aktivieren kann (Damit wird man es nur mit einem Pool-Destroy wieder los)
 
Ok dann hab ich also keine Nachteile aus meiner Konfig.

Aber mal eine andere Frage, ich habe zfs auf einem ubuntu server mit napp-it laufen.
Jetzt hab ich das Szenario das manchmal nach dem reboot der Pool verfügbar ist, und machmal muss er importiert werden.
Meinen Recherchen zu Folge macht Linux beim runterfahren wohl nur ein unmount und je nach Erfolg oder Misserfolg hab ich dann den entsprechenden Status beim hochfahren.

Hat jemand eine idee was man dagegen tun kann um die Situation automatisiert zu normalisieren?

Edit: Es wird beim booten ein zpool-import.conf via upstart ausgeführt, daraus werde ich, als nicht programmierer, aber nicht schlau. ein gefundener verweis auf /etc/default/zfs brachte mich auch nicht weiter.
 
Zuletzt bearbeitet:
Hallo zusammen,

ich habe ein kleines Problem mit meinem Backup-Server.
Dies ist ein ausrangierter Virtualisierungsserver mit 4 QC, 128 GB RAM und 21x WD green 2TB in einem Pool zu 3x raidz3 unter OpenIndiana.
Im Pool ist dedup und compression gesetzt, primary- und secondarycache auf metadata, in der /etc/system sind set zfs:zfs_arc_max = 133143986200 sowie set zfs:zfs_arc_min = 130000000000 eingetragen und z.Zt. sind ca. 30 TB brutto belegt.
Ich kann bis zu einer RAM-Belegung von ca. 50 GB (geschriebene Daten bis dahin ca. 400 GB) Schreibraten von ca. 35-50 MB/s erzielen, dann bricht die Schreibrate ein und die RAM-Belegung stagniert (also mehr als 60 GB frei).
Was kann ich tun damit auch der restliche RAM, der ja eigentlich ARC sein müsste, für die Metadaten (also DDT) genutzt wird, denn ich schätze, dass die prozentuale Einschränkung der ARC-Nutzung für Metadaten, trotz Einstellung primary- und secondarycache auf nur metadata, noch existiert.
Ich gebe zu, die Platten sind nicht der Renner, hätte mir aber Schreibraten von mehr als 8 MB/s versprochen, und ich sehe den Grund eigentlich in der schlechten Cache-Nutzung.
 
Zuletzt bearbeitet:
Hallo, gibt es irgendwelche Möglichkeit absichtlich Fehler ins zfs zu produzieren?
Möchte gerne testen, wie weit zfs mit den eigenen mitteln und scrub damit umgeht
 
Hallo zusammen,

ich habe ein kleines Problem mit meinem Backup-Server.
Dies ist ein ausrangierter Virtualisierungsserver mit 4 QC, 128 GB RAM und 21x WD green 2TB in einem Pool zu 3x raidz3 unter OpenIndiana.
Im Pool ist dedup und compression gesetzt, primary- und secondarycache auf metadata, in der /etc/system sind set zfs:zfs_arc_max = 133143986200 sowie set zfs:zfs_arc_min = 130000000000 eingetragen und z.Zt. sind ca. 30 TB brutto belegt.
Ich kann bis zu einer RAM-Belegung von ca. 50 GB (geschriebene Daten bis dahin ca. 400 GB) Schreibraten von ca. 35-50 MB/s erzielen, dann bricht die Schreibrate ein und die RAM-Belegung stagniert (also mehr als 60 GB frei).
Was kann ich tun damit auch der restliche RAM, der ja eigentlich ARC sein müsste, für die Metadaten (also DDT) genutzt wird, denn ich schätze, dass die prozentuale Einschränkung der ARC-Nutzung für Metadaten, trotz Einstellung primary- und secondarycache auf nur metadata, noch existiert.
Ich gebe zu, die Platten sind nicht der Renner, hätte mir aber Schreibraten von mehr als 8 MB/s versprochen, und ich sehe den Grund eigentlich in der schlechten Cache-Nutzung.

Soweit ich weiss gibt es einige Systeme bei denen per default maximal 50% des zur verfügung stehenden Speichers als ZFS cache genutzt werden. Das hat seine Wurzel noch aus alten Tagen als der Speicher knapp war. An welcher stelle du da drehen müsstest weiss ich gerade nicht aber vielleicht kannst du ja gezielt danach suchen. 30-50MB/s kommt mir nicht gerade viel vor für die Hardware. Wie gut gepflegt und aktuell ist denn OpenIndiana? Es gibt einige Betriebssysteme die um ZFS gestrickt wurden, die per default recht brauchbare parameter verwenden. Da hat sich in den letzten Jahren einiges bei der ZFS performance getan.
 
Soweit ich weiss gibt es einige Systeme bei denen per default maximal 50% des zur verfügung stehenden Speichers als ZFS cache genutzt werden. Das hat seine Wurzel noch aus alten Tagen als der Speicher knapp war. An welcher stelle du da drehen müsstest weiss ich gerade nicht aber vielleicht kannst du ja gezielt danach suchen. 30-50MB/s kommt mir nicht gerade viel vor für die Hardware. Wie gut gepflegt und aktuell ist denn OpenIndiana? Es gibt einige Betriebssysteme die um ZFS gestrickt wurden, die per default recht brauchbare parameter verwenden. Da hat sich in den letzten Jahren einiges bei der ZFS performance getan.

ist das aktuellste OpenIndiana 151a8

Zitat von Crash Override

Zitat von ron2105
Hallo zusammen,

Im Pool ist dedup und compression gesetzt....

Warum Dedup und welch Kompression? sind warscheinlich die Performancekiller...

dedup ist logischerweise DER Performancekiller, aber bei einem dedupratio=5,83 (fast nur VMs) geht das nicht anders und sollte bei 128 GB RAM die DDTs im ARC halten können, Kompression ist die stärkste (gzip-9), aber bei 16 Cores langweilen sich die Prozessoren nur (10% Auslastung)
 
soweit ich mitbekommen habe wird OI doch seit 1,5 Jahren nicht mehr weiter entwickelt / gepflegt
gibt nichtmal Release Notes zur 151a8 (die letzten sind noch für 151a5)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh