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

Warum verbessert das die Rekonstruktionszeit?

  1. Thema

Neues Thema Ansicht wechseln


  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...

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Karlsruher Institut für Technologie (KIT) Campus Nord, Eggenstein-Leopoldshafen
  2. VALEO GmbH, Bietigheim-Bissingen
  3. Schaltbau GmbH, Velden (Landkreis Landshut)
  4. assona GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. For Honor für 11,50€, Anno 1404 Königsedition für 3,74€, Anno 2070 Königsedition...
  2. (u. a. Total war - Three Kingdoms für 35,99€, Command & Conquer - The Ultimate Collection für 4...
  3. 116,09€ (10% Rabatt mit dem Code PREISOPT10)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Radeon RX 5700 (XT) im Test: AMDs günstige Navi-Karten sind auch super
Radeon RX 5700 (XT) im Test
AMDs günstige Navi-Karten sind auch super

Die Radeon RX 5700 (XT) liefern nach einer Preissenkung vor dem Launch eine gute Leistung ab: Wer auf Hardware-Raytracing verzichten kann, erhält zwei empfehlenswerte Navi-Grafikkarten. Bei der Energie-Effizienz hapert es aber trotz moderner 7-nm-Technik immer noch etwas.
Ein Test von Marc Sauter

  1. Navi 14 Radeon RX 5600 (XT) könnte 1.536 Shader haben
  2. Radeon RX 5700 (XT) AMD senkt Navi-Preise noch vor Launch
  3. AMD Freier Navi-Treiber in Mesa eingepflegt

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

Erasure Coding: Das Ende von Raid kommt durch Mathematik
Erasure Coding
Das Ende von Raid kommt durch Mathematik

In vielen Anwendungsszenarien sind Raid-Systeme mittlerweile nicht mehr die optimale Lösung. Zu langsam und starr sind sie. Abhilfe schaffen können mathematische Verfahren wie Erasure Coding. Noch existieren für beide Techniken Anwendungsgebiete. Am Ende wird Raid aber wohl verschwinden.
Eine Analyse von Oliver Nickel

  1. Agentur für Cybersicherheit Cyberwaffen-Entwicklung zieht in den Osten Deutschlands
  2. Yahoo Richterin lässt Vergleich zu Datenleck platzen

  1. 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.

  2. Nach Kartellamtskritik: Amazon ändert Umgang mit Marketplace-Händlern
    Nach Kartellamtskritik
    Amazon ändert Umgang mit Marketplace-Händlern

    Das Onlinekaufhaus Amazon ändert auf Druck des Bundeskartellamts seinen Umgang mit Händlern, die über Marketplace ihre Produkte verkaufen. Im Gegenzug wird ein sogenanntes Missbrauchsverfahren eingestellt.

  3. Vollformat-Kamera: Sony Alpha 7R IV mit 61 Megapixeln
    Vollformat-Kamera
    Sony Alpha 7R IV mit 61 Megapixeln

    Sony hat mit der Alpha 7R IV eine neue Systemkamera mit Kleinbildsensor vorgestellt. Sie erreicht eine Auflösung von 61 Megapixeln und kommt damit in den Bereich, der bisher Mittelformatkameras vorbehalten gewesen ist.


  1. 08:32

  2. 07:53

  3. 07:36

  4. 07:15

  5. 20:10

  6. 18:33

  7. 17:23

  8. 16:37