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

Warum verbessert das die Rekonstruktionszeit?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Warum verbessert das die Rekonstruktionszeit?

    Autor: beuteltier 10.07.19 - 09:36

    Wenn in einem RAID-Verbund eine Platte ausfällt, tue ich sehr gut daran, diese zu ersetzen. Dazu muss ich eine komplette Platte neuschreiben und das dauert. So weit, so klar.
    Aber ist das bei Erasure Coding nicht genauso? Wenn da eine Platte ausfällt, sollte ich sie auch ersetzen, um wieder die gleiche Sicherheit wie zuvor zu haben. Und auch dazu muss ich die neue Platte neu befüllen. Ich sehe den Geschwindigkeitsvorteil noch nicht.

    Selbst wen ich argumentiere, dass das System im Ausfallzeitpunkt nur zu 10% gefüllt ist - Vielleicht muss Erasure Coding dann nur 10% der ersetzten Platte beschreiben. Aber auch ein hinreichend kluges RAID müsste doch eigentlich nur den tatsächlich belegten Bereich rekonstruieren.
    Oder ist der Punkt hier einfach, dass man sich hinstellt und sagt: Aber ich enthalte dem RAID die Information vor, welche Sektoren belegt sind, deswegen muss es immer 100% kopieren? Falls dsa der Punkt ist, ließe sich dieses Problem ja leicht lösen, ohne mehr Rechenleistung zu benötigen. (Wenngleich das die Skalierungsprobleme noch nicht angeht, schon klar, aber das ist ja eine davon unabhängige Sache.)

  2. Re: Warum verbessert das die Rekonstruktionszeit?

    Autor: elcaron 10.07.19 - 09:49

    Gibts ja. Dazu muss das RAID aber im Filesystem eingebaut sein, wie bei ZFS und btrfs. Ist aber IMHO eh das cleverste, weil die Parität dann zusammen mit der Filechecksum gegen Bitrot hilft, nicht nur gegen Plattenausfälle.

  3. Re: Warum verbessert das die Rekonstruktionszeit?

    Autor: ultra79 11.07.19 - 13:22

    beuteltier schrieb:
    --------------------------------------------------------------------------------
    > Wenn in einem RAID-Verbund eine Platte ausfällt, tue ich sehr gut daran,
    > diese zu ersetzen. Dazu muss ich eine komplette Platte neuschreiben und das
    > dauert. So weit, so klar.
    > Aber ist das bei Erasure Coding nicht genauso? Wenn da eine Platte
    > ausfällt, sollte ich sie auch ersetzen, um wieder die gleiche Sicherheit
    > wie zuvor zu haben. Und auch dazu muss ich die neue Platte neu befüllen.
    > Ich sehe den Geschwindigkeitsvorteil noch nicht.

    Ich versuch mich mal an einer Erklärung:

    - nimm 100 HDDs
    - du organisierst diese in 20 klassische RAID5 - jeweils 4+1p - nennen wir das 20 Pools
    - in jedem Pool kann eine Platte ausfallen - und du verlierst keine Daten
    - fällt jetzt eine HDD aus (Pool ist degraded) dann wirst du die HDD ersetzen (HotSpare = automatisch oder halt durch manuelles austauschen)
    - danach wird der Pool die Rekonstruktion ausführen - d.h. die 4 verbleibenden HDDs werden gelesen und die 5te Platte wird geschrieben
    - das geht maximal so schnell wie man eine komplette HDD lesen bzw. schreiben kann
    - nehmen wir eine 1TB HDD die mit 100 MB/s gelesen/geschrieben werden kann dann dauert das 10000 Sekunden

    -> das Problem ist klar das man nur von 4 HDDs liest und nur auf eine schreibt

    - nehmen wir jetzt 100 HDDs und fahren ein Erasure code Verfahren mit 4+1p darauf
    - üblicherweise werden die Daten dann "de-clustered" (das wurde im Artikel nicht erklärt - ist aber ein wesentlicher Punkt für den Geschwindigkeitsvorteil)
    - wenn ich jetzt 4+1p schreibe nehme ich mir 5 von den 100 HDDs und schreibe darauf
    - wenn ich die nächsten 4+1p schreibe nehme ich mir wieder 5 von 100 - üblicherweise andere kommt dann auf die Implementierung an
    - usw.

    - Damit sind die RAID stripes jetzt über alle 100 HDDs verteilt - aber die Absicherung ist immer noch nur 4+1p

    - fällt jetzt eine HDD aus muss ich schauen wieviele meiner Stripes einen Teil ihrer Information verloren haben - das sind (annähme das alles belegt ist) maximal 5% meiner stripes

    Und jetzt kommt der Clou:
    - der Rebuild erfolgt in noch freie Blöcke auf den 99 verbleibenden Festplatten (entweder vorher reserviert oder halt freier Platz der noch da ist) -> ich habe das Schreibproblem von oben gelöst denn ich kann jetzt theoretisch auf 99 HDDs schreiben

    - um die Information für das schreiben zu generieren muss ich für jeden der Blöcke noch 4 Blöcke lesen (wegen 4+1p!) - vorher lagen die alle auf den gleichen 4 HDDs aber jetzt liegen sie praktisch über 99 HDDs verteilt. Damit kann ich jetzt mit 99/4 lesen -> also etwa 25 mal schneller als vorher wo ich am Lesespeed einer HDD hing.

    Das ist natürlich eine Vereinfachung aber das ist generell die Idee. Ob das dann innerhalb eines RAID-Systems mit DeClustered Parity erfolgt - oder mittels Servern die NetworkErasureCoding machen ist dann zweitrangig (hat aber Einfluss darauf ob ich Blöcke, Objekte oder Dateien wiederherstelle - und auch welche Performance ich erreichen kann).


    Ich hoffe das macht es etwas klarer - gern nochmal nachfragen. Es ist ein wichtiges Thema für die IT heute und morgen...

  4. Re: Warum verbessert das die Rekonstruktionszeit?

    Autor: beuteltier 11.07.19 - 14:40

    Danke für die gute Erklärung, jetzt hab ichs begriffen. :-)
    Dass die neue HDD beim Restore garnicht beschrieben wird, sondern nur alle anderen, ist natürlich ein genialer Trickgriff.

    Laut gedacht:
    Weitergedacht hieße das dann ja, dass die neu eingestezte HDD zunächst leer bleibt, alle bestehenden aber etwas voller werden. Die unterschiedlichen Befüllungsstände können dann erst ausgeglichen werden, wenn neue Daten geschrieben werden (oder per Umlagerungsalgorithmus) und leerere HDDs dabei bevorzugt ausgewählt werden. Wenn man jetzt den Befüllungsstand aber ohnehin aktiv managen muss (und kann!), dann hieße das auch, dass es keine Hürde mehr wäre, total unterschiedliche Festplattengrößen einzusetzen. Interessant. So kann das System über die Jahre mit jedem Ausfall stetig wachsen. Cool.

  5. Re: Warum verbessert das die Rekonstruktionszeit?

    Autor: ultra79 11.07.19 - 15:19

    beuteltier schrieb:
    --------------------------------------------------------------------------------
    > Danke für die gute Erklärung, jetzt hab ichs begriffen. :-)
    > Dass die neue HDD beim Restore garnicht beschrieben wird, sondern nur alle
    > anderen, ist natürlich ein genialer Trickgriff.
    >
    > Laut gedacht:
    > Weitergedacht hieße das dann ja, dass die neu eingestezte HDD zunächst leer
    > bleibt, alle bestehenden aber etwas voller werden. Die unterschiedlichen
    > Befüllungsstände können dann erst ausgeglichen werden, wenn neue Daten
    > geschrieben werden (oder per Umlagerungsalgorithmus) und leerere HDDs dabei
    > bevorzugt ausgewählt werden. Wenn man jetzt den Befüllungsstand aber
    > ohnehin aktiv managen muss (und kann!), dann hieße das auch, dass es keine
    > Hürde mehr wäre, total unterschiedliche Festplattengrößen einzusetzen.
    > Interessant. So kann das System über die Jahre mit jedem Ausfall stetig
    > wachsen. Cool.

    Was mit der neuen HDD passiert ist natürlich von der Implementierung abhängig. Üblicherweise würde man ein "rebalance" durchführen wenn die defekte HDD ausgetauscht ist - einfach damit das System balanciert bleibt.

    Allerdings führt man diesen Schritt in einer Phase durch in der alle Daten voll geschützt sind - im Gegensatz zu einem Rebuild im klassischen RAID.

    D.h. das Zeitfenster in dem mich ein weiterer Festplattenfehler katastrophal trifft ist viel kleiner.

    Noch interessanter wird es wenn ich ein 4+2p schema einsetzt - weil wenn eine HDD ausfällt habe ich etwa 6% meiner Stripes die einen Einzelfehler haben aber eben immer noch einen Paritätschunk haben.

    Wenn jetzt aber eine zweite HDD ausfällt, dann sind eben nur 0,3% meiner Stripes von diesem Doppelfehler betroffen. Und die kann ich innerhalb von sehr kurzer Zeit zuerst wiederherstellen und bin schon wieder mit +1p geschützt.

    In einem klassischen RAID6 mit 4+2p würde ein Doppelplattenfehler einen kompletten Rebuild einer HDD benötigen bevor ich wieder minimal geschützt bin (+1p).

    -> das wird insbesondere mit sehr großen HDDs relevant weil die Rebuilds länger dauern.

    Ob man verschieden große HDDs einsetzen kann hängt dann auch wieder davon ab wie die Implementierung aussieht - bei block basierten Ansätzen üblicherweise nicht. Bei File-basierten Ansätzen evtl. schon. Die haben dann allerdings wieder andere Probleme...

  6. Re: Warum verbessert das die Rekonstruktionszeit?

    Autor: Wiki-Nger 22.07.19 - 07:55

    Wenn mein gesundes Halbwissen mich nicht trügt, braucht man auch weniger Hot Spares, weil der freie Platz auf den verbleibenden Platten ja die Daten aufnehmen kann.

    Die Rekonstruktionszeit würde das dann betreffen, wenn beim RAID die Hot Spares ausgehen, weil dann praktisch gesehen die Reaktionszeit der Admins draufgerechnet werden muss. Allerdings muss man sagen, dass es selbstverständlich sein sollte, bei 100 Platten sagen wir mal mindestens 5 Hot Spares zu provisionieren. Unser Admin würde auch mehr empfehlen, da er nach eigenem Bekunden nicht ständig zum RZ fahren will. :-)

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Senior Product Owner KI & Machine Learning (w/m/d)
    Dataport, verschiedene Standorte
  2. IT-Projektkoordinator / Entwickler (w/m/d) für Identity & Access Management (IDM/IAM)
    Universitätsklinikum Hamburg-Eppendorf, Hamburg-Eppendorf
  3. Automation Expert (d/m/w)
    OSRAM Opto Semiconductors Gesellschaft mit beschränkter Haftung, Regensburg
  4. Systemadministrator (m/w/d) Werks-IT
    Nordgetreide GmbH & Co. KG, Pritzwalk-Falkenhagen (Prignitz)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Horizon Zero Dawn - Complete Edition für 14,49€, The Walking Dead - The Telltale...
  2. (u. a. Resident Evil: Village für 32,99€, Orcs Must Die! 3 für 11€, Anno 1800 für 17,99€)
  3. 249€ statt 299€
  4. (u. a. 65 Zoll für 849€, 55 Zoll für 689€, 75 Zoll für 1.259€, 85 Zoll für 1.849€)


Haben wir etwas übersehen?

E-Mail an news@golem.de