Abo
  1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Erasure Coding: Das Ende von Raid…

Der Artikel ignoriert ZFS

  1. Thema

Neues Thema Ansicht wechseln


  1. Der Artikel ignoriert ZFS

    Autor: schily 09.07.19 - 16:30

    und damit moderne Raid Technologie.

    Ein separates RAID war schon in den 1980ern ein Problem weil es bei Ausfall der Konsistenz eines Blockes ohne daß dieser Block vom Laufwerk als defekt gemeldet wird schon nicht mehr konsistent war und damit zu nicht reparablen Fehlern führte. RAID-Resync war auch damals schon ein ernstes Problem....

    ZFS aber verwendet RAID ohne diese Probleme zu haben:

    - RAID ist Teil von ZFS und damit wird eine Zeitverzögerungsstufe vermieden

    - Jeder Block hat eine eigene Checksumme, daher kann ein verfälschter Block immer erkannt werden.

    - RAID-Z2 verwendet typischerweise eine 6/4 Konstellation, die erst dann Probleme macht, wenn 3 von 6 Platten einer 6er Zelle gleichzeitig ausfallen. Die Wahrscheinlichkeit dafür ist extrem gering

    - Im laufenden Betrieb lassen sich regelmäßig ohne die Leistung zu mindern Konsistenzprüfungen und Korrekturen durchführen.

    - ZFS kann die Low Level RAID Blöcke auch auf weniger Platten verteilen und damit die Datensicherheit erhöhen.

    Damit liefert ZFS alle die Eigenschaften die der Artikel RAID absprechen will.



    1 mal bearbeitet, zuletzt am 09.07.19 16:34 durch schily.

  2. und auch weitere Dateisysteme

    Autor: 486dx4-160 09.07.19 - 17:49

    schily schrieb:
    --------------------------------------------------------------------------------
    > und damit moderne Raid Technologie.
    >
    > Ein separates RAID war schon in den 1980ern ein Problem weil es bei Ausfall
    > der Konsistenz eines Blockes ohne daß dieser Block vom Laufwerk als defekt
    > gemeldet wird schon nicht mehr konsistent war und damit zu nicht reparablen
    > Fehlern führte. RAID-Resync war auch damals schon ein ernstes Problem....
    >
    > ZFS aber verwendet RAID ohne diese Probleme zu haben:
    >
    > - RAID ist Teil von ZFS und damit wird eine Zeitverzögerungsstufe
    > vermieden
    >
    > - Jeder Block hat eine eigene Checksumme, daher kann ein verfälschter Block
    > immer erkannt werden.
    >
    > - RAID-Z2 verwendet typischerweise eine 6/4 Konstellation, die erst dann
    > Probleme macht, wenn 3 von 6 Platten einer 6er Zelle gleichzeitig
    > ausfallen. Die Wahrscheinlichkeit dafür ist extrem gering
    >
    > - Im laufenden Betrieb lassen sich regelmäßig ohne die Leistung zu mindern
    > Konsistenzprüfungen und Korrekturen durchführen.
    >
    > - ZFS kann die Low Level RAID Blöcke auch auf weniger Platten verteilen und
    > damit die Datensicherheit erhöhen.
    >
    > Damit liefert ZFS alle die Eigenschaften die der Artikel RAID absprechen
    > will.

    Es gibt mittlerweile noch mehr Dateisysteme die vergleichbares leisten: BTRFS, Ceph, BeeGFS,...

  3. Re: und auch weitere Dateisysteme

    Autor: schily 09.07.19 - 18:39

    BTRFS ist doch tot und war nie so weit fertig entwickelt, daß man es ernsthaft verwenden konnte.

    Die Anderen kenne ich nicht.

  4. Re: Der Artikel ignoriert ZFS

    Autor: Katsuragi 09.07.19 - 21:46

    schily schrieb:
    --------------------------------------------------------------------------------
    > - RAID-Z2 verwendet typischerweise eine 6/4 Konstellation, die erst dann
    > Probleme macht, wenn 3 von 6 Platten einer 6er Zelle gleichzeitig
    > ausfallen. Die Wahrscheinlichkeit dafür ist extrem gering

    aber es hat damit auch einen Redundanz-Overhead, der mit RAID1 (Mirroring) vergleichbar ist.
    Für einen einzelnen Host ist es aber trotzdem vor allem wegen der Fehlerkorrektur interessant. Bei RAID-Arrays in aktuellen Größen (mehrere dutzend TB) sind unbemerkt defekte Blöcke nämlich fast an der Tagesordnung. Je nach den gespeicherten Daten kann das vernachlässigbar oder katastrophal sein.

    Wenn man sich aber auch gegen den Ausfall eines ganzen Hosts wappnen will oder die Speichermenge zu groß für einen einzelnen Host wird, dann ist ZFS nichts mehr. Snapshots auf andere Rechner zu spiegeln ist bei hoher I/O-Load wenig praktikabel und außerdem ist ein nahtloser Wechsel bei Ausfall eines Hosts nicht wirklich einfach.

    An dieser Stelle kommen dann verteile Storage-Systeme ins Spiel, z.B. das schon erwähnte Ceph. Das ist ein über (drei bis tausende) Rechner verteilter Object-Store OHNE zentrale Steuerung, daher ohne Single Point of Failure. Jeder beliebige Host kann ausfallen ohne dass die Clients etwas davon merken, und die parallele Performance skaliert (fast) linear mit der Anzahl der beteiligten Hosts. Außerdem kann man im laufenden Betrieb einzelne Festplatten oder ganze Hosts zum Cluster hinzufügen oder entfernen. Das ist auch bei Wartungsarbeiten sehr entspannend, wenn man z.B. in Ruhe einen Host für Updates herunter fahren kann. Das Rebalancing danach updated NUR die zwischenzeitlich geänderten Datenblöcke, so dass es sehr schnell geht, wenn der Host wieder verfügbar ist.

    Darauf bauen bei Ceph eine Reihe von Diensten über den Object Store hinaus auf. Beispielsweise kann man mittels RBD (Rados Block Device) ein Objekt aus dem Store als Device-File unter Linux einbinden und damit z.B. als virtuelle Festplatte für VMs verwenden. Der Hypervisor "Proxmox" implementiert das sehr elegant und einfach. Dann gibt es noch CephFS, das auf dem Object Store ein POSIX-Filesystem "simuliert". Damit hat man dann ein ausfallsicheres, verteiltes Filesystem mit fast beliebigem Durchsatz und Erweiterbarkeit.

  5. Re: und auch weitere Dateisysteme

    Autor: robinx999 09.07.19 - 21:54

    BTRFS ist nicht so wirklich tod eigentlich funktioniert es sogar sehr gut.
    Für ein Totes Projekt gibt es noch zu viele Änderungen https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature

    Einige Linux Distributionen haben BTRFS zu früh gepushed, aber insgesammt würde ich sagen funktioniert das meiste schon recht gut
    Raid 5 / 6 sind allerdings immer noch unstable und Verschlüsselung im Dateisystem fehlt auch noch. Aber sofern man auf diese Raid Levels verzichten kann und die Verschlüsselung anderweitig löst ist es bestens einsetzbar und benötigt wesentlich weniger RAM wie ZFS
    https://btrfs.wiki.kernel.org/index.php/Status

  6. Re: Der Artikel ignoriert ZFS

    Autor: gdh 09.07.19 - 22:28

    schily schrieb:
    --------------------------------------------------------------------------------

    > - Jeder Block hat eine eigene Checksumme, daher kann ein verfälschter Block
    > immer erkannt werden.


    wenn ich mich recht erinnere ist das auch nicht immer so.
    gibt buffered und unbuffered, bei dem einen wird aus dem ram die prüfsumme erstellt, auf die HDD geschrieben und erneut die checksum gebildet. gibt es eine differenz, wird ein fehler erkannt.

    hat man jetzt keinen RAM mit fehlerkorrektur, kann es sein, dass z.b. ein bit sich gedreht hat. der fehlerhafte wert wird auf die HDD geschrieben und die checksum ist gleich, dennoch ist die information falsch.

    bei unbuffered wird direkt auf die HDD geschrieben, was es langsam macht.

  7. Re: und auch weitere Dateisysteme

    Autor: picaschaf 10.07.19 - 05:29

    schily schrieb:
    --------------------------------------------------------------------------------
    > BTRFS ist doch tot und war nie so weit fertig entwickelt, daß man es
    > ernsthaft verwenden konnte.
    >
    > Die Anderen kenne ich nicht.


    btrfs ist nicht tot, sondern aktiv im Einsatz.

  8. Re: und auch weitere Dateisysteme

    Autor: Zoj 10.07.19 - 08:17

    486dx4-160 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt mittlerweile noch mehr Dateisysteme die vergleichbares leisten:
    > BTRFS, Ceph, BeeGFS,...
    Ich setze privat nur Btrfs ein, doch wirklich so gut wie ZFS ist es nicht. Schade, dass ZFSOnLinux so instabil auf Kernelupdates reagiert, sonst wäre ZFS die bessere Alternative.

  9. Re: Der Artikel ignoriert ZFS

    Autor: elcaron 10.07.19 - 09:52

    Wer machte denn großen Storage auf Hardware ohne ECC?

    Wobei die ZFS-Entwickler selbst sagen, RAM-Fehler seien bei ZFS kein größeres Problem als bei anderen Dateisystemen.

  10. Re: und auch weitere Dateisysteme

    Autor: zonk 10.07.19 - 10:38

    picaschaf schrieb:
    --------------------------------------------------------------------------------
    > schily schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > BTRFS ist doch tot und war nie so weit fertig entwickelt, daß man es
    > > ernsthaft verwenden konnte.

    BTRFS ist das einzige Dateisystem, mit dem ich bei komplett intakter Hardware schon mal Daten verloren habe. Doch es ist tot.

  11. Re: Der Artikel ignoriert ZFS

    Autor: schily 10.07.19 - 10:54

    Keine ernstzunehmende Installation hat RAM ohne Fehlerkorrektur.

  12. Re: und auch weitere Dateisysteme

    Autor: robinx999 10.07.19 - 12:45

    zonk schrieb:
    --------------------------------------------------------------------------------
    > picaschaf schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > schily schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > BTRFS ist doch tot und war nie so weit fertig entwickelt, daß man es
    > > > ernsthaft verwenden konnte.
    >
    > BTRFS ist das einzige Dateisystem, mit dem ich bei komplett intakter
    > Hardware schon mal Daten verloren habe. Doch es ist tot.

    Hier wäre die Frage nach dem genauen Zeitpunkt interessant und ob Features genutzt wurden die zu dem Zeitpunkt noch als Unstable gekennzeichnet waren, wie es aktuell bei Raid 5/6 noch der Fall ist.

  13. Re: Der Artikel ignoriert ZFS

    Autor: recluce 10.07.19 - 22:07

    Außerdem:

    Ein Resilver bei ZFS ist im Normalfall um Kategorien schneller als die Rekonstrution eines Platteninhaltes im klassischen Raid 5/6:

    - Nur belegte Blöcke müssen rekonstruiert werden, bei 50% Füllstand des Pools halbiert sich gegenüber Raid 5/6 die zu rekonstruierende Datenmenge
    - Bei halbwegs gescheiter Hardware erfolgt der Resilver mit der maximalen Schreibgeschwindigkeit der Zielplatte (ich sehe regelmäßig ca. 150 bis 200 MByte/s bei Spindelplatten)
    - Auch bei einem laufenden Resilver (oder einem RAIDZ im "degraded" Zustand) ist die Funktion des zpools üblicherweise nicht spürbar verlangsamt

    Zur Sicherheit: zfs erlaubt RAIDZ3 und damit drei Platten Sicherheitsreserve, gibt es nach meinem Wissen bei klassischem RAID nicht. Dazu kommen die vdevs, die ein sinnvolles Bündeln einzelner RAIDZs erlauben. Niemand würde 100 Platten als ein RAIDZ betreiben. Typisch ist das Bündeln von acht bis zehn Platten zu einem RAIDZ2 oder RAIDZ3 vdev. Ein Pool von 100 Platten könnte also z.B. aus 10 vdevs bestehen, bei dem jedes vdev aus 10 Platten in RAIDZ2 / RAIDZ3 bestünde.

    Sun hat zfs ja gerade für große Storage Server / SANs entwickelt...

    Flexibilität: mittlerweile ist es möglich, ein vdev zu vergrößern, in dem man weitere Platten hinzufügt. Außerdem kann man einen Pool durch Hinzufügen von vdevs vergrößern. Letztendlich kann man nach und nach alle Platten eines vdevs durch größere Platten ersetzen - sind alle Platten getauscht, kann das vdev auf die neue Kapazität vergrößert werden.

    RAM-Bedarf: zfs braucht nur dann zwingend viel RAM, wenn Deduplikation eingeschaltet ist, dann gilt 1 GB RAM für 1 TB dedupliziertem Filesystem (was auch ein Bruchteil des Pools sein kann). Ohne Deduplikation funktioniert zfs ab 4 GB RAM zufriedenstellend. ZFS läßt allerdings keinen Speicher ungenutzt, der zfs ARC paßt sich im Betrieb einfach an den Speicherbedarf des Gesamtsystems an.

    Ich sehe z.B. bei einem Storageserver mit 32 GB RAM im Moment "nur" 1.3 GB freien Speicher bei einem ARC von 22 GB. Das SWAP ist aber komplett leer, also haben alle laufenden Anwendungen auch genug Speicher. Starte ich eine speicherhungrige Anwendung, schrumpft der ARC.

    Ach ja: betreibe niemals zfs an einem RAID-Controller....

  14. Re: Der Artikel ignoriert ZFS

    Autor: ultra79 11.07.19 - 12:46

    recluce schrieb:
    --------------------------------------------------------------------------------
    > Außerdem:
    >
    > Ein Resilver bei ZFS ist im Normalfall um Kategorien schneller als die
    > Rekonstrution eines Platteninhaltes im klassischen Raid 5/6:
    >
    > - Nur belegte Blöcke müssen rekonstruiert werden, bei 50% Füllstand des
    > Pools halbiert sich gegenüber Raid 5/6 die zu rekonstruierende Datenmenge

    Das ist ein nettes theoretisches Argument - ABER: bis zum letzten Release hat ZFS keinen sequential resilver gemacht. Sondern der Resilver war quasi ein replay der IO-Operationen auf dem Filesystem. Dann hängt deine Resilver-Geschwindigkeit davon ab wie dein FS genutzt wurde und wie alt es ist... und dann war es oft eben ziemlich Random auf den Spindeln.


    > - Bei halbwegs gescheiter Hardware erfolgt der Resilver mit der maximalen
    > Schreibgeschwindigkeit der Zielplatte (ich sehe regelmäßig ca. 150 bis 200
    > MByte/s bei Spindelplatten)

    Nett - aber in der Praxis deutlich anders wenn du viele kleine Dateien und viele kleine Schreibzugriffe hattest.

    Das neue Release soll sequential resilver machen - also erst die Arbeit planen, sortieren und dann sequentiell ausführen. Schauen wir mal wie das aussieht.

    Allerdings: RAID5 und RAID6 klasssisch macht man im professionellen Umfeld kaum noch. Spätestens mit 10 und 12TB Spindeln haben alle relevanten Hersteller auf DeClustered Arrays gesetzt. Und dann kannst du auch mit einem 8+2p Schema nach einem Plattenfehler innerhalb weniger Stunden wieder herstellen - und nach einem Doppelplattenfehler kannst du alle stripes mit zwei Fehlern in der Regel unter einer Stunde wieder absichern da nur ein Bruchteil betroffen ist aber der Rebuild von/auf alle verbleibenden HDDs gemacht wird

    DeClustered Pools können mehrere hundert HDDs haben (wenn nötig).

    > - Auch bei einem laufenden Resilver (oder einem RAIDZ im "degraded"
    > Zustand) ist die Funktion des zpools üblicherweise nicht spürbar
    > verlangsamt

    Das kommt ganz drauf an was du machst. Wenn dein Workload 100% Performance braucht, und die HW 100% liefert dann kann auch ZFS nicht zaubern. Die Performance für den Rebuild muss irgendwo herkommen... aber ja - in der Praxis laufen Systeme oft nicht auf 100% und dann ist Platz da.

    >
    > Zur Sicherheit: zfs erlaubt RAIDZ3 und damit drei Platten
    > Sicherheitsreserve, gibt es nach meinem Wissen bei klassischem RAID nicht.

    Es gibt Hersteller die das machen - interessanterweise wollen Kunden das dann oft nicht weil "das kostet ja Geld".

    > Dazu kommen die vdevs, die ein sinnvolles Bündeln einzelner RAIDZs
    > erlauben. Niemand würde 100 Platten als ein RAIDZ betreiben. Typisch ist
    > das Bündeln von acht bis zehn Platten zu einem RAIDZ2 oder RAIDZ3 vdev. Ein
    > Pool von 100 Platten könnte also z.B. aus 10 vdevs bestehen, bei dem jedes
    > vdev aus 10 Platten in RAIDZ2 / RAIDZ3 bestünde.

    Problem mit ZFS ist das es "single Host" ist. Es ist ein Dateisystem für EINEN Server

    D.h. du brauchst einen Softwarelayer oben drüber wenn du mehr Performance brauchst als ein Server einzeln liefern kann.

    >
    > Sun hat zfs ja gerade für große Storage Server / SANs entwickelt...

    SAN? Ich sehe nicht wo ZFS in ein SAN passt...

    >
    > Flexibilität: mittlerweile ist es möglich, ein vdev zu vergrößern, in dem
    > man weitere Platten hinzufügt. Außerdem kann man einen Pool durch
    > Hinzufügen von vdevs vergrößern. Letztendlich kann man nach und nach alle
    > Platten eines vdevs durch größere Platten ersetzen - sind alle Platten
    > getauscht, kann das vdev auf die neue Kapazität vergrößert werden.

    Jo - wenn man 2 Jahre mit der Migration zubringen will :-D

    >
    > RAM-Bedarf: zfs braucht nur dann zwingend viel RAM, wenn Deduplikation
    > eingeschaltet ist, dann gilt 1 GB RAM für 1 TB dedupliziertem Filesystem
    > (was auch ein Bruchteil des Pools sein kann). Ohne Deduplikation
    > funktioniert zfs ab 4 GB RAM zufriedenstellend. ZFS läßt allerdings keinen
    > Speicher ungenutzt, der zfs ARC paßt sich im Betrieb einfach an den
    > Speicherbedarf des Gesamtsystems an.
    >
    > Ich sehe z.B. bei einem Storageserver mit 32 GB RAM im Moment "nur" 1.3 GB
    > freien Speicher bei einem ARC von 22 GB. Das SWAP ist aber komplett leer,
    > also haben alle laufenden Anwendungen auch genug Speicher. Starte ich eine
    > speicherhungrige Anwendung, schrumpft der ARC.
    >
    > Ach ja: betreibe niemals zfs an einem RAID-Controller....

    Das kommt immer drauf an was man von ZFS möchte - für Snapshots, VolumeManagement und Compression kann es schon sinnvolle Einsatzzwecke on top of RAID geben...

  15. Re: und auch weitere Dateisysteme

    Autor: ultra79 11.07.19 - 12:48

    486dx4-160 schrieb:

    > Es gibt mittlerweile noch mehr Dateisysteme die vergleichbares leisten:
    > BTRFS, Ceph, BeeGFS,...

    BeeGFS ist ein paralleles Dateisystem - es setzt auf Systeme mit lokalen Dateisystemen wie BTRFS auf. Und es übernimmt keine Funktion von RAID (außer evtl. die Replizieren von Daten zwischen zwei Servern)... es passt einfach nicht in diese Reihe.

    Und Ceph (FS): steht da immer noch auf der Website "don't use it if you want to have your data back"? ;-)

  16. Re: Der Artikel ignoriert ZFS

    Autor: ultra79 11.07.19 - 12:58

    Katsuragi schrieb:

    > An dieser Stelle kommen dann verteile Storage-Systeme ins Spiel, z.B. das
    > schon erwähnte Ceph. Das ist ein über (drei bis tausende) Rechner
    > verteilter Object-Store OHNE zentrale Steuerung, daher ohne Single Point of
    > Failure. Jeder beliebige Host kann ausfallen ohne dass die Clients etwas
    > davon merken, und die parallele Performance skaliert (fast) linear mit der
    > Anzahl der beteiligten Hosts. Außerdem kann man im laufenden Betrieb
    > einzelne Festplatten oder ganze Hosts zum Cluster hinzufügen oder
    > entfernen. Das ist auch bei Wartungsarbeiten sehr entspannend, wenn man
    > z.B. in Ruhe einen Host für Updates herunter fahren kann. Das Rebalancing
    > danach updated NUR die zwischenzeitlich geänderten Datenblöcke, so dass es
    > sehr schnell geht, wenn der Host wieder verfügbar ist.

    Wieviele CEPH Systeme im Feld hast du gesehen die so funktionieren wie du das beschreibst - und das in signifikantem Maßstab?

    10, 12 oder 14 Server - sicher.

    Aber hunderte? Das wird spannend.

    Der Hardwarebedarf von CEPH ist "mind blowing" - da wird immer noch von 1 GB RAM pro 1TB verwaltetem Speicher gesprochen. Und NVMe zum abfangen von Schreibzugriffen in jedem Server.

    Dazu kommt das NetworkErasureCoding immer noch wahnsinnig langsam ist - vor allem für kleine Zugriffe. Wer Performance will arbeitet mit 3 Replicas

    Das mag alles mit 200, 300 oder 500 TB funktionieren - aber richtig "at scale" wird es dann auch spannend!

    Und das tolle "ohne zentrale Steuerung" und "rolling upgrades" - ich will das mal sehen wie das jemand macht mit 500 Servern. Der Teufel steckt im Detail und auch Auf- und Abwärtskompatibilität muss stimmen sonst wird das nichts.

    > Darauf bauen bei Ceph eine Reihe von Diensten über den Object Store hinaus
    > auf. Beispielsweise kann man mittels RBD (Rados Block Device) ein Objekt
    > aus dem Store als Device-File unter Linux einbinden und damit z.B. als
    > virtuelle Festplatte für VMs verwenden. Der Hypervisor "Proxmox"
    > implementiert das sehr elegant und einfach. Dann gibt es noch CephFS, das
    > auf dem Object Store ein POSIX-Filesystem "simuliert". Damit hat man dann
    > ein ausfallsicheres, verteiltes Filesystem mit fast beliebigem Durchsatz
    > und Erweiterbarkeit.

    Naja - fast beliebigem Durchsatz... alles was ich an Performance gesehen habe von CephFS war grausam (im Vergleich zur eingesetzten Hardware). Wenn man aus 100 Spindeln 1 GB/s mit 20 Clients zieht, dann ist das einfach nicht großartig...

    und es war lange Zeit als "unstable" markiert - mag jetzt anders sein, aber jetzt muss es sich erstmal im Feld beweisen

    Ich halte es auch immer noch für eine merkwürdige Idee erst ein ObjectStore zu bauen und dann obendrauf ein POSIX Dateisystem...

  17. Re: Der Artikel ignoriert ZFS

    Autor: recluce 11.07.19 - 21:31

    ultra79 schrieb:
    --------------------------------------------------------------------------------
    > recluce schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Außerdem:
    > >
    > > Ein Resilver bei ZFS ist im Normalfall um Kategorien schneller als die
    > > Rekonstrution eines Platteninhaltes im klassischen Raid 5/6:
    > >
    > > - Nur belegte Blöcke müssen rekonstruiert werden, bei 50% Füllstand des
    > > Pools halbiert sich gegenüber Raid 5/6 die zu rekonstruierende
    > Datenmenge
    >
    > Das ist ein nettes theoretisches Argument - ABER: bis zum letzten Release
    > hat ZFS keinen sequential resilver gemacht. Sondern der Resilver war quasi
    > ein replay der IO-Operationen auf dem Filesystem. Dann hängt deine
    > Resilver-Geschwindigkeit davon ab wie dein FS genutzt wurde und wie alt es
    > ist... und dann war es oft eben ziemlich Random auf den Spindeln.
    >
    > > - Bei halbwegs gescheiter Hardware erfolgt der Resilver mit der
    > maximalen
    > > Schreibgeschwindigkeit der Zielplatte (ich sehe regelmäßig ca. 150 bis
    > 200
    > > MByte/s bei Spindelplatten)
    >
    > Nett - aber in der Praxis deutlich anders wenn du viele kleine Dateien und
    > viele kleine Schreibzugriffe hattest.
    >

    Die 150 bis 200 MB/s sehe ich in der PRAXIS.

    > > - Auch bei einem laufenden Resilver (oder einem RAIDZ im "degraded"
    > > Zustand) ist die Funktion des zpools üblicherweise nicht spürbar
    > > verlangsamt
    >
    > Das kommt ganz drauf an was du machst. Wenn dein Workload 100% Performance
    > braucht, und die HW 100% liefert dann kann auch ZFS nicht zaubern. Die
    > Performance für den Rebuild muss irgendwo herkommen... aber ja - in der
    > Praxis laufen Systeme oft nicht auf 100% und dann ist Platz da.
    >

    Klar, es gibt immer Workloads bei denen das I/O am Anschlag ist, dann geht die Leistung beim Resilver runter. Dann ist aber der Pool bzw. das Gesamtsystem falsch ausgelegt.


    > Problem mit ZFS ist das es "single Host" ist. Es ist ein Dateisystem für
    > EINEN Server
    >
    > D.h. du brauchst einen Softwarelayer oben drüber wenn du mehr Performance
    > brauchst als ein Server einzeln liefern kann.
    >

    Klar, aber da sind wir bei anderen Größenordnungen, CEPH ist hier interessant. Nur vergleichen wir hier dann Äpfel und Birnen.

    > >
    > > Flexibilität: mittlerweile ist es möglich, ein vdev zu vergrößern, in
    > dem
    > > man weitere Platten hinzufügt. Außerdem kann man einen Pool durch
    > > Hinzufügen von vdevs vergrößern. Letztendlich kann man nach und nach
    > alle
    > > Platten eines vdevs durch größere Platten ersetzen - sind alle Platten
    > > getauscht, kann das vdev auf die neue Kapazität vergrößert werden.
    >
    > Jo - wenn man 2 Jahre mit der Migration zubringen will :-D
    >
    Dauert nicht annähernd so lange, wie Du denkst. Zudem hatte ich auch noch zwei weitere Methoden zur Pool-Vergrößerung genannt, die klassisches RAID soweit nicht unterstützt.

    > >
    > > Ach ja: betreibe niemals zfs an einem RAID-Controller....
    >
    > Das kommt immer drauf an was man von ZFS möchte - für Snapshots,
    > VolumeManagement und Compression kann es schon sinnvolle Einsatzzwecke on
    > top of RAID geben...

    Nein, es gibt keinen einzigen Anwendungsfall, bei dem zfs von einem Hardware RAID darunter profitieren würde, aber Probleme gibt es gerne. zfs immer nur an einem HBA, das gehört zu den zfs Best Practices. Ich habe mich anfangs nicht daran gehalten und damit ernsthafte Probleme gehabt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ATP Auto-Teile-Pollath Handels GmbH, Pressath bei Bayreuth
  2. Deichmann SE, Essen
  3. assona GmbH, Berlin
  4. Amprion GmbH, Pulheim-Brauweiler

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 3,74€
  2. (-75%) 3,75€
  3. 1,72€


Haben wir etwas übersehen?

E-Mail an news@golem.de


In eigener Sache: Golem.de bietet Seminar zu TLS an
In eigener Sache
Golem.de bietet Seminar zu TLS an

Der Verschlüsselungsexperte und Golem.de-Redakteur Hanno Böck gibt einen Workshop zum wichtigsten Verschlüsselungsprotokoll im Netz. Am 24. und 25. September klärt er Admins, Pentester und IT-Sicherheitsexperten in Berlin über Funktionsweisen und Gefahren von TLS auf.

  1. In eigener Sache Zweiter Termin für Kubernetes-Seminar
  2. Leserumfrage Wie können wir dich unterstützen?
  3. In eigener Sache Was du schon immer über Kubernetes wissen wolltest

Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
In eigener Sache
Neue Workshops zu agilem Arbeiten und Selbstmanagement

Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

  1. In eigener Sache ITler und Board kommen zusammen
  2. In eigener Sache Herbsttermin für den Kubernetes-Workshop steht
  3. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung

  1. Projektorkauf: Lumen, ANSI und mehr
    Projektorkauf
    Lumen, ANSI und mehr

    Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.

  2. Telefónica: Software-Fehler beschert O2-Kunden erhöhtes Datenvolumen
    Telefónica
    Software-Fehler beschert O2-Kunden erhöhtes Datenvolumen

    Telefónica gibt sich kulant. Der Mobilfunknetzbetreiber hatte einigen O2-Kunden aufgrund eines Software-Fehlers ein doppelt so hohes ungedrosseltes Datenvolumen angezeigt. Als Reaktion erhalten die betroffenen Kunden das erhöhte Datenvolumen.

  3. Elektroauto-Sounddesign: Und der Benz macht leise "wuuuuh"
    Elektroauto-Sounddesign
    Und der Benz macht leise "wuuuuh"

    Daimler hat die Töne präsentiert, die Elektroautos bei langsamer Fahrt künftig in den USA und in Europa künstlich produzieren, um andere Verkehrsteilnehmer über ihre Präsenz zu informieren. Das Rückwärtsfahren bietet Diskussionsstoff.


  1. 09:01

  2. 08:47

  3. 08:32

  4. 07:53

  5. 07:36

  6. 07:15

  7. 20:10

  8. 18:33