[Sammelthread] ZFS Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich hab davon eine einzelne mit ZFS als Backup-Storage für selten veränderliche Daten: Write once, read (idealerweise) never. ;)

Ausnahmen: monatlicher Scrub (viel read) und eben die tägliche Replikation (kaum Write). Soweit unauffällig (insb. keine Scrub-errors) seit irgendwas um 1,5 Jahre oder so.
 
Hat einer von euch bereits Erfahrungen mit den Seagate Archive HDDs im Zusammenhang mit ZFS? Taugen die dafür was?

ebenfalls 4x im Microserver als Backupserver, wie bei besterino: tägliche replikation und 1x im monat scrub. waren vorher in einem N54L und laufen im September meine ich 2 Jahre so. Keine Probleme.
 
Habe die auch 1x im Einsatz, allerdings (noch) nicht mit ZFS. Derzeit unter NTFS für Veeam Backups - läuft auch seit rund zwei Jahren ohne Probleme. Einzige was mich stört ist, dass sie beim Zugriff relativ laut ist.
 
Hat einer von euch bereits Erfahrungen mit den Seagate Archive HDDs im Zusammenhang mit ZFS? Taugen die dafür was?

Bei Neukauf würde ich die niemals für ein Raid kaufen.
Es gab mal eine Diskussion darüber bei der ZFS developper conference in Paris bei der dringend davon abgeraten wurde einen ZFS pool daraus zu bauen. Unter hoher Schreiblast wurde nichtmal ein Datenverlust ausgeschlossen. Diskutiert wurde eine Anpassung von ZFS an Archive Platten, wurde aber nie umgesetzt da der Nutzen der Platten sich einzig auf ein paar gesparte Euros reduziert.
 
@gea: Ging es bei der Diskussion um Hot oder Cold Storages?

Ich will ja nach dem Ablegen der Multimediadateien diese nur noch lesen ...

Wenn nicht, ich habe ja bisher sowieso die Seagate SkyHawk 8TB genutzt, dann mache ich das halt weiter! :d
 
Es ging eher generell um den Einsatz von Archive Platten mit ZFS Raid.

Es macht aber auch keinen Sinn das zu unterscheiden. Oder soll man das so handhaben wie bei einem Oberklasse Automobill bei dem man auf das Lenkrad einen Aufkleber hat "max 100km/h" weil man billige Reifen aufgezogen hat die mehr nicht erlauben.


als Ergänzung
Wegen CopyOnWrite ist vor allem bei höheren Füllgraden die iops Leistung der Platten entscheident und nicht deren sequentielle Performance. Gerade da brechen die Archive extrem ein.

vgl How slow is ZFS with low RAM or readcache disabled and slow disks? | ServeTheHome and ServeThe.Biz Forums

Selbst eine non-Archive WD Green ist mir da ohne Cache auf 3MB/s eingebrochen !!
 
Zuletzt bearbeitet:
"Damals"
Waen die Archive die einzigen bezahlbaren 8 TB Platten

"Heute"
würde ich eher auf die Seagate Ironwolf oder HGST NAS setzen

Das Raidz3 aus 19 Stück läuft allerdings seit über 2 Jahren fehlerfrei - wobei mind. 95 % der Daten unveränderlich sind
 
@User von Proxmox mit nappit

Ich habe esxi 6.0 gehabt, lief wirklich ohne Probleme, da fehlte halt natürlich der Webgui.
Nun habe ich seit ca. 6 Monaten die Version 6.5 von ESXI, WebGui ist ja ganz nett aber ab und zu etwas träge und auch mit einigen BUG's z.B. Speicherverwaltung ,WebGui stürzt auch gerne mal ab.

Wer von euch hat denn Erfahrung mit Proxmox und OmniOS/Nappit ?
Läuft OmniOs stabil ? Kann man auch ohne probleme PCIe-Karten durchreichen ?
Wieviel Ressourcen mehr würde Proxmox "verschwenden" im Vergleich zu Esxi ?
 
PCIe-Karten durchreichen ist kein Problem, insofern deine Hardware das unterstützt:

Pci passthrough - Proxmox VE

Gruß Hoppel

also das hier macht mir etwas sorgen:
Note:

PCI passthrough is an experimental feature in Proxmox VE

Habe Intel VT-D etc.

gibt es von Nappit auch eine fertige tamplate für proxmox, @gea ? oder vielleicht wissen das die anderen auch ???


ZFSonLinux fällt bei mir eh weg, lasse meinen Storage und die vm's hauptsächlich nur über nappit laufen
 
Bei mir läuft das ohne Murren mit Intel VT-d, keine Ahnung warum das experimental sein soll...

Gruß Hoppel
 
gibt es von Nappit auch eine fertige tamplate für proxmox, @gea ?

Nein, gibt es nicht. Eine normale Installation von OmniOS/OpenIndiana/Solaris ist aber kein Problem und napp-it ist dann nur noch der Aufruf des Online Wget Installers.

Was man aber beachten sollte. Man solllte/muss den Storage (HBA+Datenpool) per pass-through durchreichen damit ZFS den mit maximaler Performance direkt nutzen kann. Eine Netzwerkkarte sollte man auch durchreichen sofern es keine virtuellen vnics für Solaris gibt die ähnlich wie die ESXi vmxnet3 Top Perfomance intern in Software bieten. Auch ist das Speichermanagement kritisch. ZFS nimmt sich dynamisch alles was es gibt. Wenn andere Prozesse das auch dynamisch machen wollen kann es Probleme geben. Bei ESXi kein Problem weil da die Speicherzuordnung an die Storage VM bei Pass-through fest ist.
 
Oracle beendet wohl die Sparc/ Hardware Sparte die sie von Sun übernommen haben. Wie es mit dem Solaris OS (Sparc/X86) weitergeht muss man sehen, immerhin hat Oracle Supportkontrakte bis 2034 zu erfüllen. Auch ist Solaris ZFS immer noch leistungsfähiger/ schneller als Open-ZFS. Für ZFS (OpenZFS) wie auch für Illumos, dem Opensource Solaris Fork hat das keine direkte Konsequenzen, die werden seit vielen Jahren unabhängig von Oracle weiterentwickelt. 2010 als Oracle Sun übernahm sind ja bereits viele ZFS und Solaris Entwickler zu den Firmen um Illumos (z.B. Delphix, Joyent/Samsung, Nexenta oder OmniTi) gewechselt.

https://www.heise.de/ix/meldung/Oracle-feuert-SPARC-und-Solaris-Entwickler-3820643.html
 
Wird Open ZFS eigentllich "zentral" weiterentwickelt. Oder ist das wie bei den Distris jeder mach für seine Implementierung spezifische Änderungen, sodass es wieder nicht gleich ist.
 
Es gibt keine zentrale Weiterentwicklung von Open-ZFS. Ein Großteil findet bei Illumos, dem freien Solaris Fork statt. Es gibt aber auch Weiterentwicklungen wie z.B. ZFS Verschlüssellung die bei Datto/ZoL entwickelt werden.

Die verschiedenen Entwicklerteams arbeiten aber eng zusammen und übernehmen neue ZFS Feautures meist recht schnell so dass aktuelle OpenZFS Pools v5000 eine gute Kompatibilität zwischen den OpenZFS Betriebssystemen haben. Ein aktiviertes ZFS Feature kann aber die Übernahme eines Pool verhindern wenn das Zielsystem dieses Feature noch nicht unterstützt.
 
Was kann man dagegen tun dass manche Dateien sich nur verzögert öffnen lassen?
Client Win10Pro und Server OmniOS akuelle Version.
Habe das bei unterschiedlichen Dateien, manchmal klickt man drauf und das Video startet sofort, und bei anderen dauert es erst ein paar Sekunden. An der Dateigröße liegt es nicht glaube ich, bei MP3 von ein paar MB tritt das genauso auf wie bei Videos. Freigabe liegt auf einem Mirror mit 2 3TB Platten.
 
Ich könnte mal ein wenig Entscheidungshilfe gebrauchen ...

Meine Wenigkeit grübelt mal wieder über den richtigen Aufbau des Storage Servers und steht nun vor folgender Frage:

12 Platten als RAID-Z oder 24 Platten als RAID-Z2 oder 36 Platten als RAID-Z3? Insgesamt gilt es, 144 Platten zu einem Pool zu verknüpfen! Ach ja, an meinen 12er Schritten werde ich nichts ändern. Damit bin ich bisher sehr gut gefahren ... ;)

Von daher: Große vdevs oder eher kleine?
 
Was kann man dagegen tun dass manche Dateien sich nur verzögert öffnen lassen?
Client Win10Pro und Server OmniOS akuelle Version.
Habe das bei unterschiedlichen Dateien, manchmal klickt man drauf und das Video startet sofort, und bei anderen dauert es erst ein paar Sekunden. An der Dateigröße liegt es nicht glaube ich, bei MP3 von ein paar MB tritt das genauso auf wie bei Videos. Freigabe liegt auf einem Mirror mit 2 3TB Platten.

Wenn iostat keine Errors oder unterschiedliche Performance der Platten zeigt hätte ich oplock in Verdacht
What is OpLock (opportunistic lock)? - Definition from WhatIs.com

Umschalten mittels
svccfg -s network/smb/server setprop smbd/oplock_enable=false

server message block - OmniOS/ZFS/Windows 7: from within applications lags 5 seconds for all file sizes over CIFS/SMB - Server Fault

- - - Updated - - -

Ich könnte mal ein wenig Entscheidungshilfe gebrauchen ...

Meine Wenigkeit grübelt mal wieder über den richtigen Aufbau des Storage Servers und steht nun vor folgender Frage:

12 Platten als RAID-Z oder 24 Platten als RAID-Z2 oder 36 Platten als RAID-Z3? Insgesamt gilt es, 144 Platten zu einem Pool zu verknüpfen! Ach ja, an meinen 12er Schritten werde ich nichts ändern. Damit bin ich bisher sehr gut gefahren ... ;)

Von daher: Große vdevs oder eher kleine?

Das Hauptproblem eines großen vdevs ist die geringe iops Leistung die der einer Platte entspricht. Da ZFS seine Daten über den Pool verteilt entsteht zusammen mit CopyOnWrite vor allem bei volleren Pools eine starke Fragmentierung. Bei aktuellen Daten ist das wegen dem Ramcache ein kleineres Problem. Beim Resilvern/Scrubben des Pool müssen aber alle Metadaten oder Daten gelesen werden. Die Dauer ist dann direkt abhängig von der Füllrate, der Fragmentierung und der iops Leistung. Ein disk-replace oder scrubbing kann dann Tage dauern - mit einem Z3 vielleicht nicht allzu kritisch für die Datensicherheit. Unangenehm ist die reduzierte Geschwindigkeit.

12 Platten per vdev erzeugt bei einer kleinen Recordsize mehrere Prozent der Kapazität Raid-Verschnitt. Ideal ist wenn die Platten per vdev ohne Redundanz eine Zweierpotenz sind, also 2,4,8,16 (bei Z2 zwei Platten dazurechnen). Man sollte die Recordsize von default=128k daher dann erhöhen z.B. auf 512k oder 1M

Insbesondere wenn Performance eine Rolle spielt daher immer kleine vdevs bevorzugen. 12 Platten als Raid-Z1 würde ich aber als fahrlässig ansehen, wenigstens Z2 nehmen. 24 oder mehr Platten je vdev ist jenseits jeder Empfehlung

- - - Updated - - -

Bryan Cantrill zu Solaris/ Oracle ( Bryan Cantrill - Wikipedia )
The Observation Deck The sudden death and eternal life of Solaris
 
Zuletzt bearbeitet:
Ich fange zwar gerade erst an mich mit ZFS und Co zu befassen, aber wäre aus Sicht der einfacheren "verwaltung" (Sei es Rechenleistung, einfacherer Scrub/Resilvering) etc ein ein Raid 10 nicht besser ? Also ein Pool über 72 oder vlt. sogar 48 (3 HDDs pro mirror) mirrors ?
 
Zuletzt bearbeitet:
Solaris wird wohl bald nicht mehr gepflegt, das wird die Forks ebenso betreffen. Sind diese Auswirkungen auch auf ZFS zu übertragen, dass dieses keine Versionssprünge mehr erleben darf?

PS: Ich nutze FreeNAS daher betrifft es mich nicht direkt aber es wäre echt bitter, wenn die Entwicklung und Wartung nun Enden würde.


Source: Oracle: Mitarbeiter mssen gehen - Solaris steht wohl vor dem Aus - Golem.de
 
Zuletzt bearbeitet:
@gea: Vielen Dank für die Informationen!

Der Storage wird fast nur Multimediadateien beinhalten, die zum Abspielen bereitstehen. Dazu noch ein paar Bilddateien und NFOs ...
Wenn ich dich richtig verstehe, dann sollte ein RAID5 (oder seine ZFS-Entsprechung) maximal aus 8 Platten plus Paritätsplatte bestehen. Habe ich das richtig gelesen?
Wenn ja, dann würde ich das auch so machen und von den 12er Schritten Abstand nehmen, damit könnte ich noch leben ... ;)
 
Nein, man kann schon mehr Platten nehmen, wird halt langsamer und ein Rebuild beim Plattenausfall dauert entsprechend länger. Ich würde aber in jedem Fall bei vielen Platten Z2 oder Z3 vdevs nehmen (also z.B. je 12 Platten als Z2) und die Rekordsize z.B. auf 512k setzen. das passt dann schon soweit.
 
Alles klar, wieder mal ein Fall von "verlesen" ...

Ich werde bei 8+1 bleiben, darunter ist mir das einfach zu viel Verlust an Speicherplatz. Und ich muß ja auch keine kritischen Datenbanken oder so vorhalten, ne verlorene MKV habe ich in 30 Minuten von der Blu Ray ersetzt ...

Auf jeden Fall habe ich durch dich einen viel größeren Blick über den Tellerrand gewagt (und toll gefunden!) als ich je dachte. Echt Klasse!
 
144 Platten? Holly shit! Wo kommen die denn alle rein?
Und ich dachte schon, meine Sammlung ist groß. Ich komme aber seeeehr gut mit 10 Platten (Raidz2) aus.
Hinweis: Wenn bei dir mehr als eine Platte in einem der Verbünde (vdev) ausfällt sind aber alle MKV's hinüber. ZFS verteilt meines Wissens Daten auch über mehrere vdevs. Aber da fragst du am besten noch mal gea...
 
Zuletzt bearbeitet:
@the_pi_man: Die Platten sind dann alle schön brav in meinem 42HE Rack mit den 12 HP MSA60!

Wenn mir der ganze Pool flöten geht, weil eines der vdevs ausfällt, wäre das extrem suboptimal. Mir geht es am Ende nur darum, dass alle einzelnen RAIDs als ein einziger Storage verbunden sind. Dies aber ohne die Gefahr des Gesamtverlustes ...
 
Der Pool striped, sobald es mehrere vdevs gibt.
Geht ein vdev flöten, ist alles weg.Also je nach Raidz sind es 1-3 HDDs die über deine Daten entscheiden.
 
Zuletzt bearbeitet:
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