Was sind Erasure Coding-Systeme?
Änderungen vorschlagen
PDFs
Erasure Coding steuert die Anzahl von Datenfragmenten und die Anzahl der Parity-Fragmente für jedes Objekt.
Wenn Sie eine ILM-Regel erstellen oder bearbeiten, wählen Sie ein verfügbares Schema für die Einhaltung von Datenkonsistenz aus. StorageGRID erstellt automatisch Schemata für die Einhaltung von Datenkonsistenz anhand der Anzahl der Storage-Nodes und Standorte des Storage-Pools, die Sie verwenden möchten.
Datensicherung
Das StorageGRID-System verwendet den Reed-Solomon-Erasure-Coding-Algorithmus. Der Algorithmus unterteilt ein Objekt in k Datenfragmente und berechnet m Paritätsfragmente.
Die k + m = n Fragmente werden über Storage-Nodes verteilt n, um folgende Datensicherungsmaßnahmen zu ermöglichen:
-
Um ein Objekt abzurufen oder zu reparieren,
kwerden Fragmente benötigt. -
Ein Objekt kann verlorene oder beschädigte Fragmente erhalten
m. Je höher der Wert vonm, desto höher die Ausfalltoleranz.
Die beste Datensicherung wird durch das Erasure Coding-Schema mit der höchsten Ausfalltoleranz für Nodes oder Volumes innerhalb eines Storage-Pools erreicht.
Storage Overhead
Der Speicher-Overhead eines Erasure-Coding-Schemas wird berechnet, indem die Anzahl der Paritäts-Fragmente (m`durch die Anzahl der Datenfragmente geteilt wird (`k). Der Storage Overhead lässt sich ermitteln, wie viel Festplattenspeicher jedes mit Erasure-Coding-Objekt benötigt:
disk space = object size + (object size * storage overhead)
Wenn Sie beispielsweise ein Objekt mit 10 MB unter Verwendung des Schemas von 4+2 speichern (mit einem Mehraufwand von 50 %), verbraucht das Objekt 15 MB Grid Storage. Wenn Sie dasselbe 10 MB große Objekt mit dem Schema 6+2 speichern (mit einem Mehraufwand von 33 %), verbraucht das Objekt etwa 13.3 MB.
Wählen Sie das Erasure Coding-Schema mit dem niedrigsten Gesamtwert k+m, der Ihren Anforderungen entspricht. Erasure Coding-Schemata mit einer geringeren Anzahl von Fragmenten sind aus folgenden Gründen recheneffizienter:
-
Pro Objekt werden weniger Fragmente erstellt und verteilt (oder abgerufen)
-
Sie zeigen eine bessere Performance, da die Fragmentgröße größer ist
-
Das Hinzufügen von weniger Nodes in einem ist möglich "Erweiterung, wenn mehr Storage benötigt wird"
Richtlinien für Speicherpools
Verwenden Sie bei der Auswahl des Speicherpools für eine Regel, die eine Kopie mit Verfahren zur Fehlerkorrektur erstellt, die folgenden Richtlinien für Speicherpools:
-
Der Speicherpool muss drei oder mehr Standorte oder exakt einen Standort umfassen.
Sie können kein Erasure Coding verwenden, wenn der Storage-Pool zwei Standorte umfasst. -
Verwenden Sie keinen Speicherpool, der den Standort „Alle Standorte“ umfasst.
-
Der Speicherpool sollte mindestens Storage Nodes enthalten
k+m +1, die Objektdaten speichern können.
Storage-Nodes können während der Installation so konfiguriert werden, dass sie nur Objektmetadaten und keine Objektdaten enthalten. Weitere Informationen finden Sie unter "Typen von Storage-Nodes". Die Mindestanzahl der erforderlichen Storage-Nodes ist
k+m. Durch mindestens einen zusätzlichen Storage-Node können jedoch Ingest- oder ILM-Backlogs verhindert werden, wenn ein erforderlicher Storage-Node vorübergehend nicht verfügbar ist.
Verfahren zur Einhaltung von Datenkonsistenz für Storage-Pools mit drei oder mehr Standorten
Die folgende Tabelle beschreibt die von StorageGRID derzeit unterstützten Erasure Coding-Schemata für Storage-Pools, die drei oder mehr Standorte umfassen. Alle diese Maßnahmen bieten einen Standortausfallschutz. Ein Standort kann verloren gehen, und das Objekt ist weiterhin verfügbar.
Für Erasure Coding-Schemata, die Schutz vor Standortausfällen bieten, übersteigt die empfohlene Anzahl von Storage-Nodes im Speicherpool k+m +1, da für jeden Standort mindestens drei Storage-Nodes erforderlich sind.
| Schema zur Einhaltung von Datenkonsistenz (Erasure Coding) (k+m) | Mindestanzahl der bereitgestellten Standorte | Empfohlene Anzahl von Storage-Nodes an jedem Standort | Insgesamt empfohlene Anzahl von Storage-Nodes | Schutz vor Standortausfällen? | Storage Overhead |
|---|---|---|---|---|---|
4+2 |
3 |
3 |
9 |
Ja. |
50 % erreicht |
6+2 |
4 |
3 |
12 |
Ja. |
33 % erreicht |
8+2 |
5 |
3 |
15 |
Ja. |
25 % erreicht |
6+3 |
3 |
4 |
12 |
Ja. |
50 % erreicht |
9+3 |
4 |
4 |
16 |
Ja. |
33 % erreicht |
2+1 |
3 |
3 |
9 |
Ja. |
50 % erreicht |
4+1 |
5 |
3 |
15 |
Ja. |
25 % erreicht |
6+1 |
7 |
3 |
21 |
Ja. |
17 % erreicht |
7+5 |
3 |
5 |
15 |
Ja. |
71 % erreicht |
|
|
StorageGRID erfordert mindestens drei Storage-Nodes pro Standort. Für die Verwendung des Schemas 7+5 benötigt jeder Standort mindestens vier Speicherknoten. Es wird empfohlen, fünf Storage-Nodes pro Standort zu verwenden. |
Bei der Auswahl eines Löschungsschemas, das Standortschutz bietet, sollte die relative Bedeutung der folgenden Faktoren in Einklang gestellt werden:
-
Anzahl der Fragmente: Leistung und Expansionsflexibilität sind im Allgemeinen besser, wenn die Gesamtzahl der Fragmente geringer ist.
-
Fehlertoleranz: Die Fehlertoleranz wird durch mehr Paritätssegmente erhöht (d.h. wenn
meinen höheren Wert hat). -
Netzwerkverkehr: Bei der Wiederherstellung nach Ausfällen erzeugt die Verwendung eines Schemas mit mehr Fragmenten (also einer höheren Summe für
k+m) mehr Netzwerkverkehr. -
Storage Overhead: Bei Systemen mit höherem Overhead wird mehr Speicherplatz pro Objekt benötigt.
Wenn Sie beispielsweise zwischen einem Schema 4+2 und dem Schema 6+3 (mit jeweils 50 % Storage Overhead) entscheiden, wählen Sie das Schema 6+3 aus, wenn eine zusätzliche Fehlertoleranz erforderlich ist. Wählen Sie das Schema 4+2 aus, wenn die Netzwerkressourcen begrenzt sind. Wenn alle anderen Faktoren gleich sind, wählen Sie 4+2 aus, da die Gesamtzahl der Fragmente geringer ist.
|
|
Wenn Sie sich nicht sicher sind, welches Schema Sie verwenden möchten, wählen Sie 4+2 oder 6+3 aus, oder wenden Sie sich an den technischen Support. |
Verfahren zur Einhaltung von Datenkonsistenz für Storage-Pools an einem Standort
Ein Storage-Pool an einem Standort unterstützt alle Erasure Coding-Schemata, die für drei oder mehr Standorte definiert sind, sofern der Standort über ausreichend Storage-Nodes verfügt.
Die Mindestanzahl der erforderlichen Storage-Nodes ist k+m, jedoch wird ein Speicherpool mit k+m +1 Storage-Nodes empfohlen. Zum Beispiel erfordert das Verfahren zur Einhaltung von Datenkonsistenz (Erasure Coding) 2+1 einen Speicherpool mit mindestens drei Storage-Nodes, es werden jedoch vier Storage-Nodes empfohlen.
| Schema zur Einhaltung von Datenkonsistenz (Erasure Coding) (k+m) | Mindestanzahl Storage-Nodes | Empfohlene Anzahl von Storage-Nodes | Storage Overhead |
|---|---|---|---|
4+2 |
6 |
7 |
50 % erreicht |
6+2 |
8 |
9 |
33 % erreicht |
8+2 |
10 |
11 |
25 % erreicht |
6+3 |
9 |
10 |
50 % erreicht |
9+3 |
12 |
13 |
33 % erreicht |
2+1 |
3 |
4 |
50 % erreicht |
4+1 |
5 |
6 |
25 % erreicht |
6+1 |
7 |
8 |
17 % erreicht |
7+5 |
12 |
13 |
71 % erreicht |