Loading...

Blog

Latest blog posts

Deduplizierender Storage mit dem ZFS-Filesystem

Hallo Kollegen,
wir sind auf der Suche nach einem bezahlbaren Storage-System, das Deduplizieren und Komprimieren kann, und gleichzeitig für hoch produktive Umgebungen geeignet ist. Von einigen Kunden kennen wir die Datadomain von (mittlerweile) EMC, die zwar verblüffend hohe Performance bei optimalen Deduplizier-Raten leistet, jedoch auch erst für entsprechend verblüffende Preise zu haben ist. Wir fragen uns, was zum Beispiel Opensource hier beitragen kann? Bekannte Projekte sind ZFS und Opendedup. Nachdem ZFS auch als Kernelmodul vorliegt und eine weitaus größeres Featureset aufweist, werden wir uns einige Zeit (es wurden mehrere Monate) mit ZFS beschäftigen. Dabei geht es in dieser Reihenfolge um ZFS-Verstehen, Best-Practise, Versuchsaufbau, Benchmarking/Tests, Setup und Hardware für produktive Maschinen und Deployment.
Ich nehme hier vorweg, dass unser Versuch mit ZFS gescheitert ist. Und zwar am letzten Punkt „Deployment“. Mehrmals haben wir nach erfolgreichen Tests Probleme im Live-betrieb feststellen müssen, die wir letztlich nicht lösen konnten. Aber dennoch ist ZFS grundsätzlich ein interessantes Filesystem, außerdem haben wir bei diesem Versuchsprojekt viele spannende Dinge gelernt.

Warum Deduplizierung und Kompression?

In Zeiten der fortschreitenden Virtualisierung von IT-Technik, ist es üblich viele kleine (lokale) Storage-Systeme durch wenige große zu ersetzen. Das erhöht zum einen die Anforderungen an solche Systeme enorm. Auf der anderen Seite lassen sich dadurch auch Synergie-Effekte erzielen. Große zentrale Systeme bieten in der Regel auch einen höheren Funktionsumfang und rechtfertigen höhere Komplexität und Kosten. Eine gute Voraussetzung für die Einführung eines „schlauen“ Storage-System, mit dem Deduplizierung und Blocklevel-Kompression bei WorNet Einzug erhält. Mit dieser modernen Technik sollte sich der Bedarf an Speicherkapazität in Form von Festplatten reduzieren lassen. Die neuen Systeme sollen wesentlich sparsamer mit ihrem Plattenplatz umgehen und dadurch langfristig Kosten einsparen.
Den neue  ZFS-Storage würden wir als Storage-Server auf entsprechend leistungsfähiger Hardware im Münchener Rechenzentrum aufsetzen. Per ISCSI (oder NFS) an unsere ESX-Hosts angebunden, würden hauptsächlich Platten von virtuellen Maschinen (vmdk-Disks) abgelegt werden, die etwas weniger I/O-Leistung voraussetzen, sondern mehr auf Kapazität im Sinne einer Archivierungs- oder Backup-Lösungen.
Was kann ZFS?
ZFS, das Zettabyte File System ist von Sun entwickelt und zum ersten mal 106 Released worden. Es kann theoretische extrem große Datenmengen verwalten, nämlich bis zu 16 Exabyte ( 1018 Byte = 1.000.000.000.000. GByte). Das Copy-On-Write Dateisystem hat viele, sehr moderne Funktionen implementiert, und unterscheidet sich damit völlig von den üblichen Dateisystemen wie ext4 oder NTFS. Eine dieser interessanten Eigenschaften ist die Möglichkeit das Storage-System schneller zu machen indem SSD-Platten als Lese-Cache bzw. Schreiblog verwendet werden. Weitere spezielle Funktionen sind:

  • bis zu 16 Exabyte Datenmenge
  • Volume-Manager (vergleichbar mit LVM)
  • Snapshots
  • RAID-Levels (0, 1, 5,6, 10, 50, 60)    (Lesen Sie hierzu: RAID 10 vs RAID 50)
  • online Vergrößerung vorhandener RAID-Sets
  • Copy-On-Write
  • Blocklevel Deduplizierung
  • Blocklevel Komprimierung
  • Tiered-Storage per SSD-Chaches und -Logs
  • Finden und Korrigieren von schleichenden Bit-Fehlern

Angenehm ist bei ZFS auch die sehr gründliche Dokumentation von Sun (mittlerweile Oracle)  und das komfortable Handling der zur Verfügung gestellten Tools namens zpool, zfs und zdb:

  • # Zum Erstellen eines Storage-Pools  (wie LVM-Volumegroup):
    zpool  create -f mainpool mirror sdj sdf mirror sdh sdd mirror sdi sde
  • # Zum Erstellen eines Volumes mit aktivierter Deduplizierung und Kompression:
    zfs create mainpool/volumname
    zfs set compression=on mainpool/volumname
    zfs set dedup=sha256 mainpool/volumname
  • # NFS-Shares können direkt über zfs eingerichtet werden:
    zfs unshare -a
    zfs set sharenfs='rw=@10.97.155.0/24' mainpool/volumname
  • # SSD-caches und Schreiblog hinzufügen:
    zpool add mainpool log mirror sda1 sdb1
    zpool add mainpool cache sda2 sdb2

Softwarepakete

Spätestens bei der ersten Installation fällt auf, dass ZFS nicht ganz so glücklich mit Linux ist. Das liegt zunächst weniger an der Technik, sondern viel mehr an der Lizenz unter der ZFS verbreitet wird, die nicht kompatibel zur GPL des Linux-Kernels ist. Daher kann es keine fertigen Kernel-Implementierungen geben. Die meisten Distributionen machen sich jedoch die Mühe ein ZFS-Paket bereit zu stellen, das kurzerhand während der Installation erst kompiliert, um die Lizenz-Problematik zu umgehen. Das funktioniert erstaunlich gut, kann allerdings auch nicht als Ursache für die später festgestellten, versteckten Stabilitätsprobleme ausgeschlossen werden.
Unter Ubuntu kann ZFS wie folgt installiert werden:

apt-add-repository ppa:zfs-native/stable
apt-get install python-software-properties
apt-get update
apt-get install ubuntu-zfs

ZFS gibt es übrigens nativ auch unter Freebsd. Dazu lohnt es sich das Opensource-Projekt Nas4Free anzusehen, wenn man beispielsweise aus alter Hardware ein ZFS-basierten Storage-Server betrieben möchte. Nas4Free scheint sehr comfortabel und ausgereift zu sein. Für unser Rechenzentrum ist es dann widerum zu eingeschränkt (Freebsd Treiber etc) und zu wenig performant.

Unser Hardware-Setup

Getestet wird gleich auf der Hardware, die auch später zum Einsatz kommen wird. Nachdem vor allem die Deduplizierung viele Ressourcen verschlingt, insbesondere RAM, verbauen wir:

  • Quadcore-Xeon 3,2GHZ
  • 24GB RAM
  • aktuelles Supermicro-Board und Gehäuse
  • 2x Adaptec 8Port-Controller
  • 9x3TB SATA-Platten,
  • 2 x 256GB SLC-SSD für den Cache.

Wir setzten das System  auf, lassen alle 8 Festplatten vom Adaptec Controller als Einzelplatten (JBODs) an das Betriebssystem durchreichen und konfigurieren einen ZFS-Pool mit folgenden Eigenschaften:

  • 4 x Mirror aus je 2 x 3TB Platten. (Diese Verbünde werden vdevs genannt. Es gibt auch raidz und raidz2, das einem RAID5 bzw RAID6 Level entspricht.)
  • Nachdem ZFS über alle vdevs ein dynamisches Striping macht, ergibt unser Setup eigentlich ein klassisches RAID10 aus 8 Platten.
  • Wie sorgen dafür, dass die beiden Mirror-Platten jeweils an unterschiedlichen Controllern angeschlossen sind, damit das System den Ausfall eines Controllers verkraften kann.
  • 1 x Spare-Platte  (scheint bisher noch nicht implementiert zu sein, wie sich später heraus stellt)
  • 2 x 256 GB SSD Platten als Cache-Device.

Wir erstellen also ein ZFS-RAID10 mit vier 3TB-Pärchen und statten es mit zwei SSDs für den Lese-Cache aus.

Performance Benchmarks

Jetzt interessiert uns brennend, wie Leistungsfähig unser System ist. Es wurde moderne und schnelle Hardware verbaut – immerhin acht spindeln und zwei SSD-Caches.
Wir testen auf dem System direkt, indem wir ein ZFS-Volume einfach mounten. Außerdem lassen wir ein anderes Volume von ZFS als Device bereitstellen, das wir mit LIO zu einem ISCSI-Device machen. In einem VMware ESX-Server mounten wir per ISCSI das Volume, so, dass wir auch die Netzwerkperformance testen können. Als Benchmarks dienen einfache Kopiervorgänge, sowie ein alter Bekannter namens FIO-Benchmark (Blog über FIO-Benchmarking).
Benchmark-Problem 1:
Wenn wir mit „Nullen“ testen, dann werden alle Daten ziemlich gut dedupliziert und wir benchmarken eigentlich nur, wie schnell die CPU Blocks zählen kann, weil ja nur der erste Block (mit Nullen) auf die Platten geschrieben wird. Das bringt uns also nicht viel, auch wenn die Werte sehr geschmeidig sind.
Benchmark-Problem 2:
Erzeugen wir zunächst Randomdaten für unsere Tests, dann verhindern wir damit sowohl die Deduplizierung, als auch die Komprimierung, weil das mit echten Zufalls-Daten nicht geht. Die Last wird natürlich trotzdem erzeugt.
Lösung:
Um dedup und comp zu testen braucht man also „echte“ Daten. Am besten solche, die später im produktiven Umfeld auch zu erwarten sind. Erst dann kann die Performance und effektivität des Systems halbwegs genau ermittelt werden.
Ergebnis:
Die Ergebnisse sind insgesamt für so ein System ziemlich mittelmäßig. Wir erhalten für das Lesen von großen sequenziellen Datenmengen, abhängig von der Mess-Methode, Werte zwischen 50 und 150MB pro Sekunde. Nach mehreren Benchmark-Läufen – damit ZFS die Lesecaches füllen kann – ermitteln wir beim Random-Read einen maximalen Wert von ca. 4000 Transaktionen pro Sekunde. Von einem „dummen“ Storage-System hätte man deutlich mehr erwarten können, in etwa das doppelte. Angesichts der zusätzlichen Features, mit denen ZFS daherkommt, ist die nicht richtig überzeugende Performance allerdings weder sonderlich überraschend, noch unplausibel. Für unser Backup-System  reicht der Wumms allemal aus. Beim Einsatz als Storage einer Datenbank oder Server-Virtualisierung wäre ich da deutlich skeptischer.

Produktiver Betrieb – Versuch

Das System steht und macht einen stabilen Eindruck, so, dass wir das Gerät in unserem Rechenzentrum in einer halb-Produktiven Umgebung mit der Realität konfrontieren. Dazu binden wir den ISCSI-Store in eines unser ESXi-Cluster ein, migrieren mehrere (Backup-)Server und Virtuelle-Festplatten drauf. Die ersten Maschinen laufen rund und gesund. Als nächstes zeihen wir einen unserer VMware-Datarecoverys auf den neuen Storage. Das sind ca 750GB in einem Rutsch und dauert viele Stunden. Dabei kommt es zum ersten mal zu einer Instabilität. Das ZFS-System scheint sich wegen andauernder Hochlast in eine sich selbst blockierende Situation zu manövrieren. Während das Betriebssystem normal reagiert, frieren alle Aktionen, die IO-Tätigkeit auf ZFS-Volumes ausführen, komplett ein oder dauern ewig. Der Kopiervorgang wird immer langsamer, bis er nur noch einige Kilobytes schafft, bringt aber nie völlig ab. Trotz funktionsfähigem Betriebssystem lässt sich die Maschine in diesem Zustand nicht einmal mehr rebooten, da das System ewig auf unmounts etc. wartet.
Dieses Problem ist definitiv reproduzierbar und tritt bei uns ausschließlich bei Storage-Migrationen großer Maschinen über einen ESX-Server auf. Beschleunigen können wir das Auftreten, wenn wir während der Migration zusätzlich ein paar GB Daten löschen, die gerade auf einem ZFS-Volume „herum liegen“.
Leider, leider, leider ist es uns nicht gelungen dieses Phänomen in den Griff zu bekommen. Wir  haben die Umgebung getauscht, ISCSI durch NFS getauscht, mirror-vdevs durch raidz-vdevs getauscht, Hardware tests durchgeführt, Internet-Recherche betrieben und so weiter …. Alles war leider zwecklos. Es bleibt dabei – große Datenmengen an sich sind scheinbar kein Problem, aber im Zusammenhang mit ESXi-Infrastruktur gibt es zuverlässig gravierende Probleme.
Das IST ein klassischer Showstopper! Der leider erst nach mehrmonatiger Arbeit zum Vorschein kommt.

Fazit

ZFS- ist durchaus cool! Jedoch mussten wir eindeutig feststellen, dass zumindest  Ubuntu-ZFS derzeit trotz offiziell anderslautender Meldungen, noch nicht ganz auf dem Stabilitäts-Niveau ist, das wir für unsere Technik im Rechenzentrum benötigen und voraussetzen. ZFS ist an sich schon als stabil zu betrachten und hat zudem ein sehr verlockendes Set an Features. Jedoch unterscheiden sich die Anforderungen an ein Dateisystem, das als Basis eines hochverfügbaren Virtualisierungs-Clusters herhalten muss doch maßgeblich von denen, die es im KMU-Segment zu erfüllen gilt. Gegen den Einsatz in letzterem gibt es möglicherweise nichts einzuwenden.
Dieser ZFS-Versuch ist ein gutes Beispiel für Versuchsprojekte, deren hart erarbeitetes Ergebnis bedeutet: „ja, aber nicht für uns“.
Aber wer sich lange mit einer Sache beschäftigt, der lernt so einiges dabei. In diesem Fall konnten wir z.B. unsere Fähigkeit zur Einschätzung der Effizienz von Block-Deduplizierung und Datenkopmprimierung steigern. Beides ist nämlich kaum pauschal zu beziffern, weil extrem abhängig von der Beschaffenheit der verwendeten Daten. Letztlich hat sich dadurch gezeigt, dass sich der ganze Aufwand mit dieser komplizierten Technik nur dann lohnt, wenn die Daten *wirklich* optimal deduplizierbar bzw. komprimierbar sind, wie z.B. bei einer Dateibackup, die mit per se schon einmal viele Kopien der gleichen Daten im Zuge der regelmäßigen (Full-)Backup anlegen würde. In unserem Fall wären aber nicht explizit nur Backupdaten zu speichern gewesen, sondern alles Mögliche von Betriebssystemen virtueller Rechner über bereits deduplizierte VMWare-Backups, zu verschlüsselten Kunden-Daten der Trinity-Boxen. Dieser Datenmischmasch hatte auf ZFS im Test ein durchschnittliches Kompressions-Verhältnis (dedup + compression) von nicht mehr als ca. 1:1,4. Das bedeutet, dass lediglich 40% an Festplattenkapazität eingespart würden. In unserem Mengengerüst wären diese 40% durch eine Hand voll zusätzlicher 3TB SATA-Platten zu haben gewesen und damit auf bewährter, herkömmlicher Technik, sicher, wartungsarm und stabil betrieben.
Letztlich trauern wir ZFS also an dieser Stelle nur wenige Tränen nach … zumindest solange wir keine vielfach deduplizierbaren Daten produzieren. Bis dahin ist ZFS vielleicht stabiler oder bereits btrfs im Einsatz.
Wir setzen also bis auf weiteres auf unsere bewährten rock-solid, heavy-duty, ISCSI-Storages der Marke Eigenbau. Die sind zwar „dumm“, dafür aber ziemlich schnell und extrem robust dank einfacher Technik.
Quellen:

Comments (11)

  1. Hallo Christian – ist zwar nicht ZFS und auch nicht open source, aber schaut Euch mal http://www.purestorage.com an. Dedupe auf 512byte level, compression und Flash-Geschwindigkeit.
    Viele Grüße
    Christian

  2. Wieland sagt:

    Hi
    wir haben bei einem grossen TelekomProvider in Mch auch ZFS im Produktiveinsatz. Allerdings muss man wenn man professionell sein will hier auf Solaris gehen. Unter Linux wird man nie die gleiche Performance hinkriegen wie mit Solaris und wir spechen hier über eine ganze Menge an Daten die hier gemanaged werden.
    Mit dem Thema DeDup haben sich Leute schon 2009 beschäftigt und festgestellt das es einfach Performance kostet die ganze Platte nach gleichen Daten abzusuchen. Die Frage ist eher braucht man das mit heutigen Storagegrössen noch ? Oder ist es nicht einfacher compression einzuschalten ? Bei den aktuellen Prozessoren kann dies sogar schneller sein als unkomprimiert.
    https://blogs.oracle.com/observatory/entry/zfs_compression_a_win_win
    http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/
    Gruss
    Wieland / Geretsried

    1. Hallo Herr Wieland,
      da stimme ich Ihnen zu. Wie im Artikel beschrieben, sollte man sich zunächst Gedanken machen, was dedup und compression überhaupt bringen bei den Daten, um die es dabei geht. Ich würde behaupten, dass es sich nur lohnen kann, wenn klar ist, dass die Daten massiv redundant sind. Wie z.B. bei einer großen Backup, die sehr viele, kaum unterschiedliche „Versionen“ von Datensätzen speichert. Selbst bei einer Virtualisierung, die sehr viele gleiche virtuelle Gast-Maschionen betreibt, hätte man schon das Performanceproblem. Ansonsten ist es wohl insgesamt günstiger einfach ein paar mehr Festplatten zu kaufen.
      Grundsätzlich hatten wir allerdings kein Problem mit der Performance von ZFS, die schränkt lediglich den Einsatzzweck ein. Der Showstopper war letztlich die reproduzierbare Instabilität bei sehr hoher Belastung.
      Wofür setzen Sie denn Ihren ZFS-Storage ein, Herr Wieland?
      Viele Grüße
      Hannes Wilhelm

  3. Thomas Pönisch sagt:

    Warum wurde ZFS unter Linux eingesetzt? Das es hier noch nicht so stabil läuft wie unter Solaris und den darauf aufbauenden Distris (Openidiana, Omnios etc.) ist doch bekannt. Eventuell hätte ihr Test dann auch andere Ergebnisse erbracht.
    Gruß Thomas Pönisch

    1. Hallo Herr Pönisch,
      warum haben wir ZFS unter Linux getestet?
      Wir haben sehr viel Erfahrung mit Linux, der Großteil der anderen Storage-Server läuft unter Linux. Wir wollten uns einfach kein weiteres Betriebssystem zulegen. Da wir darauf angewiesen sind, zu verstehen, was unsere Maschinen unter der Haube so machen, wäre der Aufwand für uns zu groß gewesen, denn früher oder später kommt man erfahrungsgemäß an den Punkt, an dem man entweder anderen Experten viel Geld bezahlt, um ein tiefer sitzendes Problem zu lösen oder es selbst zerbeißt. Wir bevorzugen letzteres, was uns bei Linux aufgrund langjähriiger Erfahrung, sehr gut gelingt. Dazu kommt noch, dass wir auf Basis von Linux-Systemen derzeit sehr stabile und leistungsfähige Storage-Server herstellen können. Das hat viel Zeit und intensive „Versuche“ gekostet. Ob und mit welchem Aufwand das bei anderen Betriebssystemen zu erreichen ist, möchten wir derzeit nicht ausprobieren 🙂
      „Zum Spaß“ habe ich noch Nas4Free mit Opensolaris probiert, was unseren Anforderungen weder bei Stabilität, noch bei der Performance gerecht wurde.
      Openindiana und Omnios haben wir nicht ausprobiert. Haben Sie mit diesen Distris Erfahrungen gemacht? Wenn ja, dann würde ich mich über mehr Information freuen!
      Vielen Dank
      und Grüße
      H. Wilhelm

  4. Jörg Kwiatkowski sagt:

    Hallo,
    Ich vermisse erstmal auch Freebsd als Vergleichsystem und Test NFS, zudem
    wurde weder auf ein ZIL noch auf Partition Alignment eingegangen, Linux
    nutzt ja ZFS bisher nur über Fuse Usermode was natürlich Leistung und Funktionen einschränkt.
    Deduplizierung ist zugegeben eine sehr interessante Funktion gerade im Backup/Archivierungssumfeld aber sie benötigen einen exzessiven RAM Ausbau > 64 GB.
    Eine Leistungsmessung Anhand von MB ist schwer in der Interpretation,
    eine Ergänzung der Tests mit Record size KB 4/8/16/32/64 und ob Linear/Random und Testtool „iozone -Rb test4k.xls -i0 -i1 -i2 -+n -r 4k -s4g -t32“ und das auch als IO Ausgabe.
    Zudem sehen was kommt den zb. mit iometer bei einem Windows 2008 R2 Server in der Virtualisierten Umgebung an.
    Und zu guter Letzt:
    ZFS ZIL/ARC2 = IO um ca. read x10, write x3 schneller als HD,
    ZFS ZIL/ARC2 Comp= IO um ca. read x8, write x2 schneller als HD,
    ZFS ZIL/ARC2 Comp&Dedup= IO um ca. read x3, write x1 schneller als HD
    (jede HD hat ja eine Technisch Bedingte IO Leistung),
    Viele Grüße
    Jörg Kwiatkowski

    1. Hallo Herr Kwiatkowski ,
      Vielen Dank für Ihre Angaben.
      Wir hatten beim Versuchsaufbau natürlich das ZFS-Kernelmodul für Ubuntu-Linux verwendet. (muss halt bei der Installation kompiliert werden). Mit FUSE hätte es sicherlich nicht annähernd zufriedenstellend funktioniert.
      Viele Grüße
      H.Wilhelm

  5. Kurt Serberski sagt:

    Ich kann Herrn Kwiatkowski nur zustimmen und noch ein paar Gedanken hinzufügen! Die Pi x Daumen Aussage unter Storageadmins ist, dass ZFS on Linux ca. doppelt so viel ARC (vereinfacht gesagt RAM) braucht wie z.B. unter FreeBSD. Ganz ehrlich gesagt waren Ihre Versuche von Anfang an zum Scheitern verurteilt, und zwar nicht wegen NFS vs. iSCSI oder Jumboframes vs. standard oder Bonding oder sonstwas, sondern schlicht wegen Ihrer mageren RAM Ausstattung.
    Eine weitere Pi x Daumen Regel (die bei mathematischer Betrachtung und Verständnis des ARC garnicht so Pi x Daumen mehr ist), ist, dass man pro TB Storage zwischen 1 und 2GB ARC benötigt, also RAM. Auf L2ARC gehe ich um keine Verwirrung zu stiften später ein. Das wären bei Ihrer 24TB Ausstattung (und ich gehe aufgrund Ihrer „Mischmasch“ Workload davon aus, dass Sie an die 2GB ARC pro TB brauchen werden) schonmal bei 48GB. Jetzt kommt aber der Killer hinzu, und zwar Deduplication. Es wird an jeder Ecke in der ZFS Welt davor gewarnt, bei magerer RAM Auststattung insb. bei grossen vdev Konfigurationen (und 24TB sind für Marke Eigenbau zumind. mal nicht klein) die Deduplication anzuschalten! Wenn man fundamental versteht, dass ZFS einen grossen ARC (also RAM) braucht wie Menschen die Luft zum atmen, dass allein die Pointer für den L2ARC bei 8KB Blocksize 32MB pro Gigabyte Storage (ja 32MB pro GB, nicht TB) vom ARC auffressen und dass Deduplication pro TB bis zu 5GB ARC benötigen kann, so stellt sich mir nach diesem langen Schachtelsatz 😉 doch die simpele Frage: Auf welchen Seiten waren Sie bei der Internetrecherche unterwegs, dass Ihnen zu keiner Zeit dieser kapitale Fehler auffallen konnte?
    Das soll jetzt nicht als Vorwurf oder Angriff aufgefasst werden, sondern vielmehr als Hinweis für die Mitleser dienen, dass in meinen Augen hier zwei Architekturfehler begangen wurden.
    1. ZFS on Linux anstatt ZFS auf einer wesentlich erprobteren (und nativen) Basis im Produktivbetrieb einsetzen zu wollen
    2. viel viel viel zu wenig RAM für einen solchen Storage Server und eine derartige „Mischmasch“ Workload.
    Als dritten Punkt könnte man noch anführen, dass ein reines Datengrab (Backups, grosse infrequent genutzte Images) garkein ZIL und L2ARC benötigen, man sogar den ARC (und damit den RAM Verbrauch) für jeweilige Volumes begrenzen kann. Jedoch gerade für VMs ist ein ausreichend grosser ARC, darunter ein ausreichend grosser L2ARC bestehend aus einer consumer SSD (reicht aus), optimalerweise leicht grösser als das Working Set der VMs, essentiell. Hier hätte man antizipieren müssen, wie viel Platz die VMs einnehmen werden und ggf. schnellere Laufwerke den hier genutzten vorziehen können. Oder zumind. die VMs auf ein anderes Volume bspw. bestehend aus 3TB mirror + ARC assignment + L2ARC + ZIL legen können. Dann wäre auch nicht der reproduzierbare und absolut nachvollziehbare Fehler mit dem fast eingefrorenen System (wenige KB Durchsatz) entstanden.
    Trotzdem danke ich für diesen Blogeintrag und die mitgeteilten Erfahrungen. Nicht jede Firma wäre ohne weiteres bereit, monatelange Forschungsarbeit und ihre Ergebnisse kostenlos der breiten IT-Masse zur Verfügung zu stellen.
    Viele Grüsse
    Kurt

    1. Kurt Serberski sagt:

      Möchte noch korrigieren, dass „garkein ZIL“ natürlich Quatsch ist, denn der ZIL ist immer vorhanden und zwar striped across all devices. Was ich meinte ist ein dedizierter ZIL in Form einer SLC SSD.

    2. Hallo Kurt,
      Vielen Dank für Ihre ausführlichen Angaben.
      Punkt eins Ihres Fazits ist genauso unser Fazit ( siehe Fazit 🙂 des Blogartikels)
      Bei Ihrem Punkt zwei muss ich widersprechen. Wie beschrieben hatten unsere Testdaten ein Volumen von unter ein TB. Selbst bei extrem konservativer Berechnung MÜSSEN 24GB RAM für knapp ein TB Testdaten ausreichen!
      Der nicht genutzte Plattenplatz belegt sicher keine Ressourcen im RAM.
      Daher kann mangelnder RAM-Ausbau sicherlich nicht die Ursache für den „Stabilitäts-Bug“ gewesen sein.
      Mittlerweile wäre es allerdings wieder interessant den Versuch mit aktueller Software zu wiederholen. Vielleicht wurde der Bug inzwischen behoben.
      Vielen Dank und Grüße
      H. Wilhelm

  6. Sascha sagt:

    Da es aktuell auch ein Produkt von Open-E gibt was auf Linux aufsetzt, sollte der Test vielleicht wirklich wiederholt werden. Mangels Hardware wäre ich sogar dankbar wenn dies gemacht werden könnte. Wir haben bald Systeme (laufen aus dem Hardwaresupport) die wir dann damit nutzen könnten. Als Backupsystem und Datengrab. Testen und das jetzt, ist aber nicht drin. Wäre wirklich super wenn Sie den Test wiederholen könnten. So wie ich es verstanden habe, würde die Reine Wiederholung ja nicht so viel Zeit kosten 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*
*

Cookie Consent mit Real Cookie Banner