[Sammelthread] ZFS Stammtisch

[dogma2k]

@Digi-Quick und Gea danke für die Antworten.
Aber wie Digi-Quick schon geschrieben hat wird zu 99% Murphys Law auftreten und 2 Platten im einen vdev zerlegen ^^

Ich werde zuerst ein raidz2 aus 8 HDD's machen. Wenn mir die Performance nicht reichen sollte werde ich einfach ein zweites raidz2 stripen.
Das Backup wird denke ich ein raidz3 muss noch mal gucken wie ich es an besten angehe?

P.S. Hat jemand eine gute Internet Seite wo man "Snapshot für dummies" erklärt bekommt?

 

[Morpheus2200]

Hat hier jemand Erfahrung mit ZFS und vielen kleinen files?

Wenn ich mehrere VDEVS stripe und kleine Dateien, sagen wir mal nur wenige Byte groß auf dem Volume anlege auf wie vielen VDEVs liegt die kleine Datei dann? Und wie sieht das mit der Prüfsumme/Metadaten aus?

Ich habe mal irgendwo aufgeschnappt das ZFS dynamisch innerhalb eines stripes Dateien ablegen kann, dementsprechend nicht wie ein klassisched (r)aid 0 auf alle Platten schreibt. Ist das schon per default so?

Wird beim anlegen einer Datei immer einen synchronen Schreibvorgang auslöst?

Ich überlege im moment an einer Stelle ZFS einzusetzen wo ich auf eine gewisse performance angewiesen bin.
Geht um ca. 10-20mio. files und ca. 30TB, gemischtes Zugriffsverhalten und Dateigrößen.

Sorgen bereiten mir im moment Situationen wo ~1mio. files durchsucht oder hundertausende angelegt werden und zeitgleich von anderen clients mit anderen Zugriffsmustern Arbeit auf den Filer zukommt.
Ich kann das im Moment auch schlecht testen, habe hier nur Systeme mit zu wenig VDEVs die knicken bei random IO natürlich irgendwann mal ein wenn die caching effekte nicht mehr greifen.

Diese mixed workloads machen mir etwas Sorgen.
Natürlich kann man IOPs Monster mit SSDs bauen, die bei 30TB Kapazität wenn man rein auf SAS setzt aber leider zu teuer werden.

Die andere Möglichkeit auf gute I/O performance zu kommen wären ja viele VDEVs.
Nimmt man z.B. einen Stripe über 30 Mirrored VDEVs aus 1TB 7.2k HDDs (die bekommt man mit SAS schon für ~100Euro) käme man bei 60 Platten auf 30TB netto und ca. 6000 IOPs wenn jeder mirror ca. 200 iops liefert. Ohne caching Effekte wären das schon brauchbare Werte.

Aber so kann man ja nur rechnen, wenn für jede operation nur 1 VDEV arbeiten muss.
Daher die Frage zu Beginn, wie geht ZFS im Stripe mit extrem kleinen Dateien um?

 

[gea]

Bei Raid-Z ist der "Verschnitt" und damit die Nutzkapazität am Größten, wenn die Anzahl der Datenplatten eine Zweierpotenz ist. Mit Raid-Z2 sind das 6 oder 10 Platten.

Snapshot bei ZFS ist gabz einfach erklärt:
Als CopyOnWrite Filesystem werden bei ZFS keine Datenblöcke geändert sondern immer neu geschrieben. Der alte Datenblock wird dann zum Überschreiben freigegeben.

Ein Snapshot verhindert das Überschreiben, so dass der alte Datenblock erhalten bleibt. ZFS Snapshots können dadurch ohne Zeitverzug auch in großer Anzahl (Tausende) angelegt werden. Sie verbrauchen auch zunächst keinen Platz. Die freie Kapazität eines Pools sinkt allerdings mit der Menge der gesperrten Datenblocks. (Platz-Zaubern kann auch ZFS nicht)

- - - Updated - - -

Hat hier jemand Erfahrung mit ZFS und vielen kleinen files?

Wenn ich mehrere VDEVS stripe und kleine Dateien, sagen wir mal nur wenige Byte groß auf dem Volume anlege auf wie vielen VDEVs liegt die kleine Datei dann? Und wie sieht das mit der Prüfsumme/Metadaten aus?

Ich habe mal irgendwo aufgeschnappt das ZFS dynamisch innerhalb eines stripes Dateien ablegen kann, dementsprechend nicht wie ein klassisched (r)aid 0 auf alle Platten schreibt. Ist das schon per default so?

Wird beim anlegen einer Datei immer einen synchronen Schreibvorgang auslöst?

Ich überlege im moment an einer Stelle ZFS einzusetzen wo ich auf eine gewisse performance angewiesen bin.
Geht um ca. 10-20mio. files und ca. 30TB, gemischtes Zugriffsverhalten und Dateigrößen.

Sorgen bereiten mir im moment Situationen wo ~1mio. files durchsucht oder hundertausende angelegt werden und zeitgleich von anderen clients mit anderen Zugriffsmustern Arbeit auf den Filer zukommt.
Ich kann das im Moment auch schlecht testen, habe hier nur Systeme mit zu wenig VDEVs die knicken bei random IO natürlich irgendwann mal ein wenn die caching effekte nicht mehr greifen.

Diese mixed workloads machen mir etwas Sorgen.
Natürlich kann man IOPs Monster mit SSDs bauen, die bei 30TB Kapazität wenn man rein auf SAS setzt aber leider zu teuer werden.

Die andere Möglichkeit auf gute I/O performance zu kommen wären ja viele VDEVs.
Nimmt man z.B. einen Stripe über 30 Mirrored VDEVs aus 1TB 7.2k HDDs (die bekommt man mit SAS schon für ~100Euro) käme man bei 60 Platten auf 30TB netto und ca. 6000 IOPs wenn jeder mirror ca. 200 iops liefert. Ohne caching Effekte wären das schon brauchbare Werte.

Aber so kann man ja nur rechnen, wenn für jede operation nur 1 VDEV arbeiten muss.
Daher die Frage zu Beginn, wie geht ZFS im Stripe mit extrem kleinen Dateien um?

Je nach den Gegebenheiten ist selbst eine Datei mit 1 Byte Inhalt deutlich Größer z.B. 1k oder 4k.
Die Datei wird bei ZFS nach Möglichkeit über alle vdevs gestript (balanced pool).
Lediglich bei unbalanced pools (wenn man bei einem vollen Pool ein weiteres vdev hinzufügt), erfolgen die Schreibvorgänge gezwungenermassen auf das neue vdev.

Die Prüfsummen arbeiten auf Datenblockebene.

Die Performance beim Lesen lässt sich durch sehr viel RAM verbessern.
Falls nicht mehr RAM geht, dann eine SSD als L2ARC. Dadurch reduzieren sich die Lesevorgänge vom Pool.


Beim Schreiben arbeitet ZFS je nach Einstellung
- sync=default: Client bestimmt, z.B: ESXi + NFS = syncron, SMB asyncron
- sync=always : immer
- sync=disabled: nie

Sync schreibt ein Log auf das ZIL (Onpool oder separates Logdevice).
Die normalen Schreibvorgänge werden im RAM gesammelt und nach wenigen Sekunden als als schnelles sequentielles Write geschrieben. Kleine Random Write sind daher vor allem mit Sync ein Problem das sich mit einem schnellen separaten Logdevice lösen läßt.

Plan B sind sehr viele mirrors.
Lese-iops skaliert mit der Anzahl der Platten, Schreib-iops mit der Anzahl der Mirrors.

Die Alternative wären Sata SSD (günstiger als SAS). Die gehen bis 1.6 TB pro SSD.
Man sollte dann aber nach Möglichkeit auf Expander verzichten und z,B, ein Case mit 24x 2,5" von Supermicro und mehrere HBA nehmen (z.B. http://www.supermicro.nl/products/chassis/2U/216/SC216BA-R1K28LP.cfm) und dann mehrere Raid-Z2

Denkbar wären auch zwei Pools, ein schneller und ein großer.

 

[Fischje]

Ich habe ja schon lange den Wunsch von XPEnology wegzukommen zu ZFS und möchte in meinem ESXi gea's napp-it nutzen. Der ESXi ist in Version 6.0 und da möchte erstmal ein "go" von gea haben, das ich seine fertige Appliance nutzen kann.
Das ZFS soll dann für meine VMs den Datenspeicher bereitstellen.

Dann wollte ich folgendes nutzen:
6 Festplatten unterschiedlicher Größe und Hersteller zwischen 3 und 4 TB groß, möchte ich in einem ZFS Raid unterbringen. Welches Raid-Level bietet sich denn da an? Die Möglichkeit die 3 TB Platten nach und nach durch 4 TB Platten auszutauschen hätte ich auch gerne irgendwie vorher bedacht

Es sollte später easy mit ner externen 5TB HDD zu backupen sein. Ein Bakcup-Server mit 3x 750TB, 2x 2TB und einmal 500GB steht auch noch zur Verfügung, momentan Win7 drauf mit Snapraid und rsync-Möglichkeit.

 

[Bzzz]

Ich überlege im moment an einer Stelle ZFS einzusetzen wo ich auf eine gewisse performance angewiesen bin.
Geht um ca. 10-20mio. files und ca. 30TB, gemischtes Zugriffsverhalten und Dateigrößen.

Sorgen bereiten mir im moment Situationen wo ~1mio. files durchsucht oder hundertausende angelegt werden und zeitgleich von anderen clients mit anderen Zugriffsmustern Arbeit auf den Filer zukommt.
Ich kann das im Moment auch schlecht testen, habe hier nur Systeme mit zu wenig VDEVs die knicken bei random IO natürlich irgendwann mal ein wenn die caching effekte nicht mehr greifen.

Diese mixed workloads machen mir etwas Sorgen.
Natürlich kann man IOPs Monster mit SSDs bauen, die bei 30TB Kapazität wenn man rein auf SAS setzt aber leider zu teuer werden.

20 Mio kleine Files sind auf SSD gut aufgehoben, 30 TB große Einzeldateien gut auf Platte. Aber 20 Mio MB-große Files, die im Multiuserbetrieb durchkämmt werden sollen? Da biste ja schon zur richtigen Einsicht gekommen, wenn das performant werden muss, dann wirds nicht billig. ZFS kann auch nur cachen, wenn dafür Speicher verfügbar ist, und das ist bei lauter gleichgroßen Sachen, die zusammen TB-schwer sind, denkbar schwierig. Sowohl im ARC, als auch im L2ARC...

 

[gea]

Ich habe ja schon lange den Wunsch von XPEnology wegzukommen zu ZFS und möchte in meinem ESXi gea's napp-it nutzen. Der ESXi ist in Version 6.0 und da möchte erstmal ein "go" von gea haben, das ich seine fertige Appliance nutzen kann.
Das ZFS soll dann für meine VMs den Datenspeicher bereitstellen.

Dann wollte ich folgendes nutzen:
6 Festplatten unterschiedlicher Größe und Hersteller zwischen 3 und 4 TB groß, möchte ich in einem ZFS Raid unterbringen. Welches Raid-Level bietet sich denn da an? Die Möglichkeit die 3 TB Platten nach und nach durch 4 TB Platten auszutauschen hätte ich auch gerne irgendwie vorher bedacht

Es sollte später easy mit ner externen 5TB HDD zu backupen sein. Ein Bakcup-Server mit 3x 750TB, 2x 2TB und einmal 500GB steht auch noch zur Verfügung, momentan Win7 drauf mit Snapraid und rsync-Möglichkeit.

Die momentane Appliance basiert auf OmniOS 151012 und vmware-Tools 5.5.
Für ESXi 6 müsste man die Tools updaten.

Beim neuen OmniOS 151014 würde ich noch etwas zuwarten.
Da wurden mit ESXI Probleme mit NFS gemeldet. Ist aber noch nicht klar woran das liegt.

Beim Pool würde ich entweder ein Z2 aus den 6 Platten machen (je Platte 3 TB, 12 TB nutzbar).
Wenn alle 3 TB Platten durch 4 TB Modelle ersetzt werden steigt die Kapazität entsprechend.

Alternative (bessere iops Leistung für VMs): 3 gestripte Mirrors


zum Backup
Unter Windows kann man robocopy als sync tool nutzen (kann auch ACL im Gegensatz zu rsync).

Die Option:
Ein Backupserver mit ZFS.
Damit könnte man dann zfs Snaps replizieren (besonders schnell). Auch kann man in ZFS snaps ESXi Hot-Snaps integrieren. Damit hat man sauber wiederherstellbare ESXi snaps. (Normale ZFS Snaps sind wie plötzliches Power-Off. ESXi VMs sind da gern mal korrupt)

 

[dogma2k]

Mehrere GB/s Datenraten mit Raid-Z sind somit prinzipiell und sequentiell kein Problem.
Sync Write, bei dem es auf iops ankommt, ist aber mit Raid-Z deutlich langsamer
sofern man kein separates schnelles Logdevice (z.B. Intel 3700-100 oder Winkom SLX 8-32) hat

Ich hab mir eben mal die Daten der Intel und einer Samsung Pro angeguckt. Von den Random 4k read/write ist die Samsung doch besser oder interpretiere ich da was falsch

Bei Raid-Z ist der "Verschnitt" und damit die Nutzkapazität am Größten, wenn die Anzahl der Datenplatten eine Zweierpotenz ist. Mit Raid-Z2 sind das 6 oder 10 Platten.

Snapshot bei ZFS ist gabz einfach erklärt:
Als CopyOnWrite Filesystem werden bei ZFS keine Datenblöcke geändert sondern immer neu geschrieben. Der alte Datenblock wird dann zum Überschreiben freigegeben.

Ein Snapshot verhindert das Überschreiben, so dass der alte Datenblock erhalten bleibt. ZFS Snapshots können dadurch ohne Zeitverzug auch in großer Anzahl (Tausende) angelegt werden. Sie verbrauchen auch zunächst keinen Platz. Die freie Kapazität eines Pools sinkt allerdings mit der Menge der gesperrten Datenblocks. (Platz-Zaubern kann auch ZFS nicht)

Danke für die einfach Erklärung. Also kann ich einen beliebigen Snapshot aussuchen und den Ursprünglichen Zustand schnell und sicher wiederherstellen (z.B. Datei aus versehen gelöscht oder ein Virus befall?!)

 

[gea]

Ein Logdevice hat ganz spezielle Anforderungen
- extrem geringe Latenzen
- "konstant" hohe iops (kein Einbruch nach einiger Zeit)
- Powerloss protection

Da helfen die Datenblattangaben oft nicht weiter.
siehe z.B. Consistent Performance: A Reality? - The Intel SSD DC S3700 (200GB) Review


ZFS Snapshots sind perfekt geeignet um Vorversionen sicher vorzuhalten.
Da sie readonly sind, können sie nachträglich auch nicht geändert werden.
(Ausnahme: einen Clone daraus erstellen, der ist schreibbar).

Zugriff auf Snaps: Am einfachsten mit "Windows - vorherige Version"

 

[Crash Override]

Hi,

Anscheinend liegt das Problem mit NFS bei ESXi6 noch an VMWare, mir wurde von einem VMWare Mitarbeiter nahegelegt noch nicht auf ESXi6 zu migrieren wenn man NFS nutzt...

 

[CommanderBond]

Woran kann es liegen das Snapshots nicht gelöscht werden? Habe einen Job erstellt über NappIT dass die Dinger 10 Tage und die 10 letzten aufbewahrt werden (erstelle täglich einen). Erstellen tut er sie auch nur löschen nicht...

 

[dogma2k]

Gibt es eigentlich die Möglichkeit dem ZFS ein Ramdrive als Logdrive zuzuweisen?

 

[gea]

zu den Snaps
Bei den Einstellungen sollten nur die letzten 10 Snaps je Filesystem erhalten bleiben.
Welches napp-it Release ist es denn?

- - - Updated - - -

Gibt es eigentlich die Möglichkeit dem ZFS ein Ramdrive als Logdrive zuzuweisen?

Ja, ist aber unsinnig.
Dann ist es nämlich so unsicher wie sync=disabled, lediglich umständlicher und langsamer

Mit dem ZeusRAM gibt es aber ein Dram-Logdevice
Das wäre die professionelle Option.

 

[dogma2k]

Oha die Preise sind aber noch mal heftiger!

 

[Fimbultyr]

Moin moin in die Runde,

vielleicht kann mir ja jemand von euch weiterhelfen? Problem ist hier geschildert.

Hardware: HP Microserver G8, 1610T, 2GB RAM, 4x3TB WD Green

 

[Digi-Quick]

@gea

Moin gea,
du hast doch sicherlich ein "Ohr" am Entwicklungsstand von ZFS dran.
Gibt es da eigentlich schon irgendwelche Neuigkeiten in Bezug auf eine SMR-HA (Schingled Magnetic Recording - Host Aware) Implementation?
Für das EXT 4 Filesystem gibt es da offenbar schon was Fertiges - direkt von Seagate wie es scheint:
https://github.com/Seagate/SMR_FS-EXT4
Laut dieser Seite ist die aktuell ausgelieferte Seagate 8TB Archive V2 bereits Host aware ("Seagate's new 8TB Archive HDD v2 drive is SMR-HA."), es fehlt eigentlich nur noch die ZFS implementierung von SMR-HA

 

[gea]

Ich weiss nur, dass es (auch bei ZFS-Entwicklern ) bekannt ist, dass die Schreib/ Scrubperformance dieser Platten eher schlecht ist. Zum Stand eventueller ZFS Anpassungen ist mir aber nichts bekannt.

 

[Digi-Quick]

Das Scrubben fand ich jetzt gar nichtmal so schlecht:

Raidz3 aus 7 (4+3) Platten ist gut 80 % gefüllt (ca. 24,5 TiB von 30,5 TiB).
i3-4150 CPU / 16 GB ECC Ram

state: ONLINE
scan: scrub repaired 0 in 16h41m with 0 errors on Mon Apr 20 11:14:21 2015

ABEEERRR:
Beim Resilvern kann man zuschauen....

  pool: Testpool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Apr 20 13:55:16 2015
        3.66T scanned out of 39.9T at 111M/s, 94h44m to go
        535G resilvered, 9.18% done

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
Testpool                   39.9T  10.6T    517     21  63.6M   112K
  raidz3                   39.9T  10.6T    517     21  63.6M   112K
    da3                        -      -    302      3  16.1M  42.5K
    replacing                  -      -      0    527     16  16.0M
      3376418568582324464      -      -      0      0      0      0
      da7                      -      -      0    291     58  15.9M
    da4                        -      -    301      3  16.1M  42.3K
    da0                        -      -    303      3  16.1M  42.3K
    da1                        -      -    298      3  16.1M  42.4K
    da5                        -      -    294      3  16.1M  42.5K
    da6                        -      -    301      3  16.1M  42.6K
-------------------------  -----  -----  -----  -----  -----  -----

Man könnte natürlich dagegen halten, daß das Resilvern nicht dem normalen Nutzungsprofil entspricht und nicht allzu häufig auftritt (am besten Nie!). Wie war das noch gleich mit den Pferden und der Apotheke .... Oder auch Murphy.

 

[Bzzz]

Was genau erwartest du an zusätzlicher Performance beim Resilver? Da wird eine Platte sequentiell vollgetröpfelt. Mehr als die Schreibrate dieser einzelnen Platte ist nicht zu erwarten, wo solls denn auch hin?
Und das ausschließliche Wiederherstellen der Daten (vs. kompletter Plattengröße) macht sich bei 3/4 Pool-Befüllung auch nur noch begrenzt bemerkbar. Bei mir ist grade so Halbzeit, da "lohnt" sich das Feature noch...

 

[Digi-Quick]

Naja, die Schreibrate einer einzelnen Platte liegt idR eher bei 150 MB/s und nicht bei 15 MB/s.

Der Rebuild einer 2TB Platte für ein Raid5 an einem Dell Perc 5i dauert etwa 17h, und da wurden die Vollen 2TB rebuildet - also nicht nur die Daten.
4x17h wären 70h, hier müssen aber nur ca. 6,4 TB (80%) Resilvered werden. also etwa 3,2*17h = etwa 55h. Der Resilver dauert aber pauschal gut doppelt so lange (es sei denn da komt noch ein Plötzlicher Performanceschub).

Bei Seagate Archive HDD Review (8TB) | StorageReview.com - Storage Reviews ist das Verhalten der Seagate Archive recht gut dokumentiert.
Verglichen wurde die 8TB Seagate mit SMR und die HGST he8 ohne SMR

"Below is a screenshot showing disk activity during the SMR RAID rebuild on top, where we see sustained write performance all over the map, including single digit throughput for long periods. This is compared to the PMR rebuild shown on the bottom half of the image which is able to stay over 100MB/s for most of the duration."
Die gemittelte Transferate der Seagate lag unter 10 MB/s, die der HGST über 150 MB/s.

- - - Updated - - -

Ich weiss nur, dass es (auch bei ZFS-Entwicklern ) bekannt ist, dass die Schreib/ Scrubperformance dieser Platten eher schlecht ist. Zum Stand eventueller ZFS Anpassungen ist mir aber nichts bekannt.

Es heisst also weiterhin abwarten und Tee trinken.
Es ist natürlich auch die Frage, in wie weit Seagte selbst da Interesse daran hat mitzuwirken, schliesslich könnte das Ihrem Geschäftsinteressen entgegenwirken.
Bemerkenswert ist halt, daß für Linux respektive EXT4 hier die notwendigen Erweiterungen direkt von Seagate kommen - so scheint es

 

[ludwinator]

Solange SMR nicht im Enterprise Segment ankommt, besteht seitens Nexenta, Omnti etc. auch wenig Interesse, deswegen grundsätzliche Änderungen an ZFS vorzunehmen. Seagate selbst empfiehlt ja explizit keinen RAID Usage mit diesen Platten.

cu

 

[Bzzz]

Naja, die Schreibrate einer einzelnen Platte liegt idR eher bei 150 MB/s und nicht bei 15 MB/s.

Da ich selber schon zwei Replacements durchgeführt hab, um (aus Platznot) temporär eingefügte 1,5TB-Platten gegen die eigentlichen 2,0TBs zu tauschen, kann ich solche überlangen Rebuilds nicht bestätigen. Aber nach ein bisschen Rechnerei seh ich dein Problem. Ich hatte vermutet, dass die angezeigten 111 MB/s der Schreibrate entsprechen und die einzelnen Werte der Platten die effektiven Beiträge dazu sind. Tatsächlich sind das aber die gesamte Schreib- und Leserate, was ja weit unter den Möglichkeiten des Arrays liegt - eben weil eine Einzelplatte 100-150 MB/s durchbolzen könnte. Gut, damit ist das nachvollziehbar...

Also Augen auf beim Plattenkauf? Mir war SMR ja vorher schon ein Begriff, aber dass das so arbeitet - ziemliches No-Go, finde ich. Man merkt, dass aus rotierendem Rost kaum noch was rauszuholen ist und man die Platten für spezielle Anwendungsprofile überzüchtet. Zeit für SSDs

 

[Digi-Quick]

Solange SMR nicht im Enterprise Segment ankommt, besteht seitens Nexenta, Omnti etc. auch wenig Interesse, deswegen grundsätzliche Änderungen an ZFS vorzunehmen. Seagate selbst empfiehlt ja explizit keinen RAID Usage mit diesen Platten.

cu

Ein wenig dagegen spricht der Vortrag von Kim Novak im letzten Jahr, der ist bei Nexenta.
Ich habe gerade mal eine Mail an Nexenta geschickt unter Bezugnahme auf genau diesen Vortrag, bin mal gespannt, ob die antworten....
Bei Linux und FreeBSD ist da auf jeden Fall schon Erkennbar, daß sich was tut.
Nur zu ZFS & SMR habe ich nicht wirklich was aktuelles gefunden. die Seite von OpenZFS erscheint mir völlig unaktuell / schlecht gewartet.

Achja, Seagate sieht die Archive Platten genau im Enterprise Segment bzw. Nearline.
"Kostengünstige Festplatte für effektive Archivierung und Cloud-Speicherung
Mit dem besten Kosten-pro-TB-Verhältnis ermöglicht diese Online-Datenarchivierungslösung für wachsende Archivspeicher in Petabyte-Größe eine erschwingliche langfristige Datenverwaltung.

Die SMR-kompatible Technologie ermöglicht selbst in den anspruchsvollsten Rechenzentrumsumgebungen eine effiziente und wirtschaftliche Speicherung selten benötigter Daten."

Genau betrachtet eiigentlich ein ideales Einsatzgebiet für ZFS.

Snapraid o.ä. würde sich zur Zeit vermutlich eher für die Platten eignen!

 

[layerbreak]

Achja, Seagate sieht die Archive Platten genau im Enterprise Segment bzw. Nearline.
"Kostengünstige Festplatte für effektive Archivierung und Cloud-Speicherung
Mit dem besten Kosten-pro-TB-Verhältnis ermöglicht diese Online-Datenarchivierungslösung für wachsende Archivspeicher in Petabyte-Größe eine erschwingliche langfristige Datenverwaltung.

Sorry, aber das halte ich definitiv für dummes Marketinggequatsche vom Hersteller und Seagate widerspricht sich doch selbst, denn im Enterprise Bereich ist Raid-Fähigkeit Pflicht.

 

[gea]

Nach meinem Reinfall mit 3 TB Disks von Seagate (selbst einen Z3 Backup-Pool kann ich damit nicht am Leben halten) bin ich eh vorsichtig mit Seagate.

Eine 8 TB HGST ist zwar dreimal so teuer, der glaube ich allerdings ihre Performance und ihre 3 x höhere MTBF.

ps
Ich hab die da: https://www.backblaze.com/blog/best-hard-drive/

 

[Digi-Quick]

Sorry, aber das halte ich definitiv für dummes Marketinggequatsche vom Hersteller und Seagate widerspricht sich doch selbst, denn im Enterprise Bereich ist Raid-Fähigkeit Pflicht.

Sagen wir es mal so:
Die Positionierung des Produktes erfordert eigentlich ZFS - von wegen Datenarchiv im Petabytebereich!
Archiv heisst per Definition "Langzeitspeicherung", und da möchte man keinen Datenrost haben! ZFS ist aber nur mit Parität (Mirror oder RaidzX) wirklich effektiv, Stichwort Selbstheilung. Ohne Parität gäbe es halt die Meldung, welche Dateien korrupt sind.
Dazu passt dann auch die Aussage von Kim Novak im letten Jahr: "ZFS may be the only file system that can use SMR drives with NO LOSS in performance!"
http://storageconference.us/2014/Presentations/Novak.pdf

 

[Morpheus2200]

Je nach den Gegebenheiten ist selbst eine Datei mit 1 Byte Inhalt deutlich Größer z.B. 1k oder 4k.
Die Datei wird bei ZFS nach Möglichkeit über alle vdevs gestript (balanced pool).
Lediglich bei unbalanced pools (wenn man bei einem vollen Pool ein weiteres vdev hinzufügt), erfolgen die Schreibvorgänge gezwungenermassen auf das neue vdev.

Die Prüfsummen arbeiten auf Datenblockebene.

Die Performance beim Lesen lässt sich durch sehr viel RAM verbessern.
Falls nicht mehr RAM geht, dann eine SSD als L2ARC. Dadurch reduzieren sich die Lesevorgänge vom Pool.


Beim Schreiben arbeitet ZFS je nach Einstellung
- sync=default: Client bestimmt, z.B: ESXi + NFS = syncron, SMB asyncron
- sync=always : immer
- sync=disabled: nie

Sync schreibt ein Log auf das ZIL (Onpool oder separates Logdevice).
Die normalen Schreibvorgänge werden im RAM gesammelt und nach wenigen Sekunden als als schnelles sequentielles Write geschrieben. Kleine Random Write sind daher vor allem mit Sync ein Problem das sich mit einem schnellen separaten Logdevice lösen läßt.

Plan B sind sehr viele mirrors.
Lese-iops skaliert mit der Anzahl der Platten, Schreib-iops mit der Anzahl der Mirrors.

Die Alternative wären Sata SSD (günstiger als SAS). Die gehen bis 1.6 TB pro SSD.
Man sollte dann aber nach Möglichkeit auf Expander verzichten und z,B, ein Case mit 24x 2,5" von Supermicro und mehrere HBA nehmen (z.B. Super Micro Computer, Inc. - Products | Chassis | 2U | SC216BA-R1K28LPB) und dann mehrere Raid-Z2

Denkbar wären auch zwei Pools, ein schneller und ein großer.

Danke für deine Antwort, hat leider etwas gedauert bis ich mal wieder Zeit gefunden habe mich mit dem Storage zu befassen.
Ich habe jetzt von mehreren Leuten die teilweise ihre Brötchen mit ZFS storage systemen verdienen gehört, dass die I/O performance schreibend mit anzahl der VDEVs skaliert.
Das funktioniert doch nur wenn an kleinen I/Os nicht alle VDEVs beteiligt sind oder habe ich da einen Denkfehler?

Die 30TB sind schon der kleine Pool. Weiter aufteilen lässt sich das leider nicht.
SAS war angedacht um redundante Köpfe mit failover realisieren zu können. Ich habe noch eine andere Lösung mit parallelem Filesystem im Blick die keine Probleme mit dem Ausfall eines Rechners/Switches/Netzteils hat. Der ZFS Filer sollte eine preiswerte Alternative werden, aber nachdem ich jetzt erste Angebote gesehen habe wird sich da leider (bei gleicher Ausfallsicherheit und mit profesionellem support) nicht so viel einsparen lassen, dass sich das ZFS Experiment lohnen würde.
Wenn man auf den Redundaten Kopf verzichtet und mit SATA SSDs experimentiert sieht das mit den Kosten vielleicht anders aus. Aber auch SATA SSDs die bei hohen Änderungsraten 5 Jahre lang eine ordentliche Performance liefern sind nicht gerade billig. Und mit support wird es evtl. auch schwieriger als bei SAS. Inwiefern das berechnen der paritäten für RAID Z2 die performance beeinflusst kann ich auch nicht abschätzen. Es ist auf jeden Fall etwas mehr zu tun als bei striped Mirrors.

Für den Mixed Workload mit vielen kleinen und einigen großen Files gibt es bei anderen storage Lösungen interessante Ansätze. Z.B. Metadaten und die ersten 12k jeder Datei auf SSDs zu speichern. Total simpler und unflexibler Ansatz aber für meinen Fall hier vielleicht trozdem eine Effektive Lösung. Leider auch nicht ganz billig....

 

[oc_parts]

Moin Jungs,

bei mir steht demnächst ein HDD Upgrade an.
Gleichzeitig möchte ich den pool von derzeit 4 disk raidz1 auf 6 disk z2 wechseln wollen.
Aktuell habe ich 3TB Seagates.
Hat schon jemand Erfahrungen mit den 5TB WD Green bzw den Toshibas gemacht?
Die SMR Seagates scheinen ja nicht besonders gut zu laufen.

 

[gea]

Danke für deine Antwort, hat leider etwas gedauert bis ich mal wieder Zeit gefunden habe mich mit dem Storage zu befassen.
Ich habe jetzt von mehreren Leuten die teilweise ihre Brötchen mit ZFS storage systemen verdienen gehört, dass die I/O performance schreibend mit anzahl der VDEVs skaliert.
Das funktioniert doch nur wenn an kleinen I/Os nicht alle VDEVs beteiligt sind oder habe ich da einen Denkfehler?

Die 30TB sind schon der kleine Pool. Weiter aufteilen lässt sich das leider nicht.
SAS war angedacht um redundante Köpfe mit failover realisieren zu können. Ich habe noch eine andere Lösung mit parallelem Filesystem im Blick die keine Probleme mit dem Ausfall eines Rechners/Switches/Netzteils hat. Der ZFS Filer sollte eine preiswerte Alternative werden, aber nachdem ich jetzt erste Angebote gesehen habe wird sich da leider (bei gleicher Ausfallsicherheit und mit profesionellem support) nicht so viel einsparen lassen, dass sich das ZFS Experiment lohnen würde.
Wenn man auf den Redundaten Kopf verzichtet und mit SATA SSDs experimentiert sieht das mit den Kosten vielleicht anders aus. Aber auch SATA SSDs die bei hohen Änderungsraten 5 Jahre lang eine ordentliche Performance liefern sind nicht gerade billig. Und mit support wird es evtl. auch schwieriger als bei SAS. Inwiefern das berechnen der paritäten für RAID Z2 die performance beeinflusst kann ich auch nicht abschätzen. Es ist auf jeden Fall etwas mehr zu tun als bei striped Mirrors.

Für den Mixed Workload mit vielen kleinen und einigen großen Files gibt es bei anderen storage Lösungen interessante Ansätze. Z.B. Metadaten und die ersten 12k jeder Datei auf SSDs zu speichern. Total simpler und unflexibler Ansatz aber für meinen Fall hier vielleicht trozdem eine Effektive Lösung. Leider auch nicht ganz billig....

30 TB redundant und schnell ist immer sehr teuer und meist auch recht komplex.
Wenn man statt ZFS mit Standard Serverhardhardware mit einem freien OS aber kommerzielle zu ZFS vergleichbare Storageanbieter (NetApp etc) nimmt, kommen aber ganz andere Kosten zusammen. Dafür ist dann das Gesamtsystem unter Support. Mit OpenSource Systemen gibt es nur Hardwaresupport (Ausnahme OmniOS und Solaris mit OS Support, Nexenta mit Support auf zertifizierter Hardware).

Ob dabei Sata oder SAS Platten benutzt werden, ist zunächst mal egal (Bei manchen Konfigurationen z.B. mit Expandern werden aber oft nur SAS Konfigurationen supportet)

zu den IO
IO bei Multi-Raid Systemen (vdevs) skaliert mit der Anzahl der vdevs, sowohl lesend wie schreibend, egal welche Dateigröße. Je vdev liegen die iops bei mehreren Hundert bei Platten bis mehreren Zehntausend bei SSD. SAS Platten-Monster für 30 TB und schnelle Multi-Raid 10 um damit ordentliche iops Werte zu erreichen sind aber meiner Ansicht nach überholt zumal schnelle SAS Platten auch klein und teuer sind - große SAS/Sata Platten hingegen meist lahm. Die Alternative ist wohl: billige 7200 U/m Platten (egal ob SAS oder Sata) und teure aber drastisch schnellere Enterprise Sata SSDs wie z.B. die 1,6 TB Intel S3500.

Wenn Redundanz zwei unabhängige Systeme bedeutet, werden die Platten vor allem bei SSD zum finanzielle Problem.


zur CPU Last bei ZFS Software Raid/ Multi-Raid-Z
Da würde ich mir überhaupt keine Gedanken machen. Aktuelle Multicore CPUs sind tauglich für Echtzeit 3D. Das bisschen Raid-Berechnen ist dagegen lächerlich einfach.

 

[Morpheus2200]

SATA SSDs wären eine option, aber eben nur wenn man auf redundante Pfade zum Storage und damit auf failover verzichtet.
Und es bleibt die Frage der Hardware für die es support (von Nexenta z.B.) gibt und zuverlässig soll der Kram ja auch bleiben.

Die idee war halt preiswerte 1TB SAS HDDs zu nehmen, die gibt es ab ca. 100 Euro. Mit 2*32 Disks könnte man 30 Mirrors+2Spares bauen.
Die Empfehlung von Nexenta war dann noch 2x 8GB Zeus RAM, 512GB RAM und flotte CPUs um die Latenzen gering zu halten.
Dazu kommt das man bei Nexenta die bruto Kapazität lizensiert um support zu erhalten. mit den 30 Mirrors wären dann 60TB zu lizensieren um 30TB zu nutzen. Das alles treibt die Kosten etwas nach oben.
Die ZFS Alternative wären 2-3 striped RAID Z2 Sets mit SSDs. Etwas weniger Lizenzkosten, aber die Hardware ist deutlich teurer. Wenn man auf SATA zurückgreift belibt noch die Frage wie man so viele SATA devices wirklich zuverlässig anbinden soll.
Mit den 1.6TB Intel SSDs wären ja auch 2 Z2 sets mit je 10+2 SSDs denkbar. Wären also 24 SSDs +spare für 1500,- pro Stück.
Ich hatte das mal Intel SSD DC S3710 1.2TB durchgerechnet. Da braucht man dann eher 3 RaidZ2 Sets, damit wird es deutlich teurer als mit den S3500er SSDs.

Für überholt halte ich das Konzept ohne SSDs nicht. Solange man keine sync Zugriffe hat kann man über die caches schon einiges an performance herausholen. Solange ich async zugreife ist selbst bei random I/O bei meinem 2xRaidZ2 System das 10Gig Interface limitierend. Natürlich nur solange alles in den cache passt.
Wenn man mit den 30 Mirrors auf ca. 6k iops (200 iops*30VDEVs) ohne caching Effekte kommt. Sollte mit Zeus und großem ARC für mixed workloads eine ganz brauchbare performance herumkommen.

Es hängt wie immer ein bisschen am Einsatzzweck denke ich.
Aber bei beiden ZFS Lösungen bin ich preislich leider schon in einem Bereich von ~ 8-10 Storage Blades inkl. Netzwerkhardware für ein paralleles filesystem.
Und da packt man dann ein zweites director Blade und einen zweiten Switch dazu und hat die redundanz die bei ZFS viel aufwändiger zu realisieren ist.

 

[gea]

Wenn man auf SATA zurückgreift belibt noch die Frage wie man so viele SATA devices wirklich zuverlässig anbinden soll.

Mit den 1.6TB Intel SSDs wären ja auch 2 Z2 sets mit je 10+2 SSDs denkbar. Wären also 24 SSDs +spare für 1500,- pro Stück.
Ich hatte das mal Intel SSD DC S3710 1.2TB durchgerechnet. Da braucht man dann eher 3 RaidZ2 Sets, damit wird es deutlich teurer als mit den S3500er SSDs.

Ein ZFS System könnte so aussehen
Super Micro Computer, Inc. - Products | Chassis | 2U | SC216BA-R1K28LPB

Dazu ein SuperMicro Mainboard nach Wahl (Single 6Core wäre ausreichend, Dual Core eventuell wegen RAM Ausbau) mit 3 x LSI HBA 9207 + benötigte Nics, vorzugsweise Intel.

Dazu 20 Enterprise SSDs z.B. Intel 3500-1,6 TB oder S3610-1,6 TB oder S3710-1,2 TB für 2 x Raid-Z2
+ 1-2 SSD als Hotspare siehe Intel Launches SSD DC S3610 & S3710 Enterprise SSDs

Für async Betrieb braucht man kein Slog wie eine ZeusRAM,
falls man kleine sync Writes auf günstigeren SSDs reduzieren möchte (ZeusRAM hat 3,5", geht nicht),
wäre eine HGST s840Z (16GB) noch eine Option

Bei SAS wirds dann teurer, z.B. mit HGST s841-2TB o.ä.


Mit all inkl Support müsste man halt sehen, ob sowas von Nexenta zertifiziert ist,
ansonsten müsste man Hardware und Software Support (z.B. OmniOS, Oracle Solaris, High Availability.com) trennen. Bei der Nutzung von OpenSource ohne Komplett-Support sollte die eigene IT aber etwas Erfahrung haben.