Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Wiederherstellen von Objektdaten in einem Storage Volume, falls erforderlich

01/04/2023 Beitragende

PDFs

Wenn der sn-recovery-postinstall.sh Skript ist erforderlich, um ein oder mehrere fehlgeschlagene Speicher-Volumes neu zu formatieren, müssen Sie Objektdaten auf dem neu formatierten Speicher-Volume von anderen Speicherknoten und Archiv-Nodes wiederherstellen. Diese Schritte sind erst dann erforderlich, wenn ein oder mehrere Storage Volumes neu formatiert wurden.

Was Sie benötigen

Sie müssen bestätigt haben, dass der wiederhergestellte Speicherknoten einen Verbindungsstatus von verbunden hat Auf der Registerkarte Nodes Übersicht im Grid Manager.

Über diese Aufgabe

Objektdaten können von anderen Storage-Nodes, einem Archiv-Node oder einem Cloud Storage-Pool wiederhergestellt werden, wenn die ILM-Regeln des Grid so konfiguriert wurden, dass Objektkopien verfügbar sind.

Wenn eine ILM-Regel so konfiguriert wurde, dass nur eine replizierte Kopie gespeichert wird und sich diese Kopie auf einem ausgefallenen Storage Volume befand, können Sie das Objekt nicht wiederherstellen.

Wenn sich die einzige verbleibende Kopie eines Objekts in einem Cloud Storage Pool befindet, muss StorageGRID mehrere Anfragen an den Cloud Storage Pool Endpunkt stellen, um Objektdaten wiederherzustellen. Bevor Sie dieses Verfahren durchführen, wenden Sie sich an den technischen Support, um Hilfe bei der Schätzung des Recovery-Zeitrahmens und der damit verbundenen Kosten zu erhalten.

Wenn sich die einzige verbleibende Kopie eines Objekts auf einem Archiv-Node befindet, werden Objektdaten vom Archiv-Node abgerufen. Aufgrund der Latenz beim Abrufen von Daten aus externen Archiv-Storage-Systemen dauert die Wiederherstellung von Objektdaten in einen Storage Node aus einem Archiv-Node länger als die Wiederherstellung von Kopien aus anderen Storage-Nodes.

Zum Wiederherstellen von Objektdaten führen Sie den aus repair-data Skript: Dieses Skript startet den Prozess der Wiederherstellung von Objektdaten und arbeitet mit ILM-Scans zusammen, um sicherzustellen, dass ILM-Regeln eingehalten werden. Sie verwenden verschiedene Optionen mit dem repair-data Skript, unabhängig davon, ob Sie replizierte Daten oder Erasure Coding Daten wiederherstellen:

Replizierte Daten: Für die Wiederherstellung replizierter Daten stehen zwei Befehle zur Verfügung, je nachdem, ob Sie den gesamten Knoten oder nur bestimmte Volumes auf dem Knoten reparieren müssen:
```
repair-data start-replicated-node-repair
```
```
repair-data start-replicated-volume-repair
```
Erasure Coded (EC) Data: Zwei Befehle stehen zur Wiederherstellung von Erasure-codierten Daten zur Verfügung. Dabei wird darauf basierend, ob Sie den gesamten Knoten oder nur bestimmte Volumes auf dem Knoten reparieren müssen:
```
repair-data start-ec-node-repair
```
```
repair-data start-ec-volume-repair
```
Reparaturen an Erasure-codierten Daten können beginnen, während einige Storage-Nodes offline sind. Die Reparatur ist abgeschlossen, wenn alle Nodes verfügbar sind. Sie können Reparaturen von Daten, die mit Erasure-Coding-Verfahren codiert wurden, mit diesem Befehl verfolgen:
```
repair-data show-ec-repair-status
```

Der EC-Reparaturauftrag reserviert vorübergehend eine große Menge an Lagerung. Storage-Warnmeldungen können zwar ausgelöst werden, werden aber nach Abschluss der Reparatur behoben. Wenn nicht genügend Speicherplatz für die Reservierung vorhanden ist, schlägt der EC-Reparaturauftrag fehl. Speicherreservierungen werden freigegeben, wenn der EC-Reparaturauftrag abgeschlossen wurde, unabhängig davon, ob der Job fehlgeschlagen oder erfolgreich war.

Weitere Informationen zur Verwendung des repair-data Skript, geben Sie ein repair-data --help Über die Befehlszeile des primären Admin-Knotens.

Schritte

Melden Sie sich beim primären Admin-Node an:
1. Geben Sie den folgenden Befehl ein: ssh admin@primary_Admin_Node_IP
2. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
3. Geben Sie den folgenden Befehl ein, um zum Root zu wechseln: su -
4. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
  
  Wenn Sie als root angemeldet sind, ändert sich die Eingabeaufforderung von $ Bis #.
Verwenden Sie die /etc/hosts Datei, um den Hostnamen des Speicher-Knotens für die wiederhergestellten Speicher-Volumes zu finden. Um eine Liste aller Nodes im Raster anzuzeigen, geben Sie Folgendes ein: cat /etc/hosts

Wenn alle Storage-Volumes ausgefallen sind, reparieren Sie den gesamten Node. (Wenn nur einige Volumes ausgefallen sind, fahren Sie mit dem nächsten Schritt fort.)

Sie können nicht ausgeführt werden repair-data Betrieb für mehr als einen Node gleichzeitig. Wenden Sie sich an den technischen Support, um mehrere Nodes wiederherzustellen.

Wenn in Ihrem Grid replizierte Daten enthalten sind, verwenden Sie das repair-data start-replicated-node-repair Befehl mit dem --nodes Option zum Reparieren des gesamten Speicherknoten.

Mit diesem Befehl werden die replizierten Daten auf einem Storage-Node mit dem Namen SG-DC-SN3 repariert:

repair-data start-replicated-node-repair --nodes SG-DC-SN3

Während Objektdaten wiederhergestellt werden, wird die Warnmeldung Objekte verloren ausgelöst, wenn das StorageGRID System replizierte Objektdaten nicht finden kann. Auf Storage-Nodes im gesamten System können Warnmeldungen ausgelöst werden. Sie sollten die Ursache des Schadens bestimmen und feststellen, ob eine Wiederherstellung möglich ist. Anweisungen zum Monitoring und zur Fehlerbehebung von StorageGRID finden Sie in der Anleitung.

Wenn in Ihrem Grid Daten zur Einhaltung von Datenkonsistenz (Erasure Coding) enthalten sind, verwenden Sie den repair-data start-ec-node-repair Befehl mit dem --nodes Option zum Reparieren des gesamten Speicherknoten.

Mit diesem Befehl werden die Erasure Coding-Daten auf einem Storage-Node mit dem Namen SG-DC-SN3 repariert:
```
repair-data start-ec-node-repair --nodes SG-DC-SN3
```
Der Vorgang gibt einen eindeutigen zurück repair ID Das identifiziert dies repair_data Betrieb. Verwenden Sie diese Option repair ID Den Fortschritt und das Ergebnis des verfolgen repair_data Betrieb. Beim Abschluss des Wiederherstellungsprozesses wird kein weiteres Feedback zurückgegeben.

Reparaturen an Erasure-codierten Daten können beginnen, während einige Storage-Nodes offline sind. Die Reparatur ist abgeschlossen, wenn alle Nodes verfügbar sind.

Wenn im Grid Daten repliziert und mit Erasure-Coding-Verfahren codiert sind, führen Sie beide Befehle aus.

Wenn nur einige Volumes ausgefallen sind, die betroffenen Volumes reparieren.

Geben Sie die Volume-IDs in hexadezimal ein. Beispiel: 0000 Ist der erste Band und 000F Ist der sechzehnte Band. Sie können ein Volume, einen Bereich von Volumes oder mehrere Volumes angeben, die sich nicht in einer Sequenz befinden.

Alle Volumes müssen sich auf demselben Speicherknoten befinden. Wenn Sie Volumes für mehr als einen Speicherknoten wiederherstellen müssen, wenden Sie sich an den technischen Support.

Wenn Ihr Grid replizierte Daten enthält, verwenden Sie das start-replicated-volume-repair Befehl mit dem --nodes Option zum Identifizieren des Knotens. Fügen Sie dann entweder die hinzu --volumes Oder --volume-range Option, wie in den folgenden Beispielen dargestellt.

Einzelnes Volume: Dieser Befehl stellt replizierte Daten auf das Volume wieder her 0002 Auf einem Storage-Node mit dem Namen SG-DC-SN3:

repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0002

Bereich von Volumes: Dieser Befehl stellt replizierte Daten auf alle Volumes im Bereich wieder her 0003 Bis 0009 Auf einem Storage-Node mit dem Namen SG-DC-SN3:

repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volume-range 0003-0009

Mehrere Volumes nicht in einer Sequenz: Dieser Befehl stellt replizierte Daten in Volumes wieder her 0001, 0005, und 0008 Auf einem Storage-Node mit dem Namen SG-DC-SN3:

repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0001,0005,0008

Wenn in Ihrem Grid Daten zur Einhaltung von Datenkonsistenz (Erasure Coding) enthalten sind, verwenden Sie den start-ec-volume-repair Befehl mit dem --nodes Option zum Identifizieren des Knotens. Fügen Sie dann entweder die hinzu --volumes Oder --volume-range Option, wie in den folgenden Beispielen dargestellt.

Einzelnes Volume: Dieser Befehl stellt gelöscht codierte Daten auf das Volumen wieder her 0007 Auf einem Storage-Node mit dem Namen SG-DC-SN3:
```
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 0007
```
Bereich von Volumes: Dieser Befehl stellt gelöscht codierte Daten auf alle Volumes im Bereich 0004 Bis 0006 Auf einem Storage-Node mit dem Namen SG-DC-SN3:
```
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volume-range 0004-0006
```
Mehrere Volumes nicht in einer Sequenz: Dieser Befehl stellt gelöscht codierten Daten auf Volumes wieder 000A, 000C, und 000E Auf einem Storage-Node mit dem Namen SG-DC-SN3:
```
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 000A,000C,000E
```
Der repair-data Der Vorgang gibt einen eindeutigen zurück repair ID Das identifiziert dies repair_data Betrieb. Verwenden Sie diese Option repair ID Den Fortschritt und das Ergebnis des verfolgen repair_data Betrieb. Beim Abschluss des Wiederherstellungsprozesses wird kein weiteres Feedback zurückgegeben.

Reparaturen an Erasure-codierten Daten können beginnen, während einige Storage-Nodes offline sind. Die Reparatur ist abgeschlossen, wenn alle Nodes verfügbar sind.

Wenn im Grid Daten repliziert und mit Erasure-Coding-Verfahren codiert sind, führen Sie beide Befehle aus.

Monitoring der Reparatur replizierter Daten
1. Wählen Sie Nodes Storage Node wird repariert ILM.
2. Verwenden Sie die Attribute im Abschnitt Bewertung, um festzustellen, ob Reparaturen abgeschlossen sind.
  
  Wenn die Reparaturen abgeschlossen sind, zeigt das Attribut „wartet – Alle“ 0 Objekte an.
3. Um die Reparatur genauer zu überwachen, wählen Sie Support Tools Grid Topology.
4. Wählen Sie Grid Storage Node wird repariert LDR Data Store.
5. Verwenden Sie eine Kombination der folgenden Attribute, um festzustellen, ob replizierte Reparaturen abgeschlossen sind.
  
  Cassandra ist möglicherweise Inkonsistenzen vorhanden und fehlgeschlagene Reparaturen werden nicht nachverfolgt.
  - Reparted (XRPA): Verwenden Sie dieses Attribut, um den Fortschritt der replizierten Reparaturen zu verfolgen. Dieses Attribut erhöht sich jedes Mal, wenn ein Storage-Node versucht, ein risikoreicheres Objekt zu reparieren. Wenn dieses Attribut für einen Zeitraum nicht länger als die aktuelle Scan-Periode (vorgesehen durch das Attribut Scan Period — Estimated) steigt, bedeutet dies, dass ILM-Scans keine hoch riskant Objekte gefunden haben, die auf allen Knoten repariert werden müssen.
    
    Objekte mit hohem Risiko sind Objekte, die Gefahr laufen, völlig verloren zu sein. Dies umfasst keine Objekte, die ihre ILM-Konfiguration nicht erfüllen.
  - Scan Period — Estimated (XSCM): Verwenden Sie dieses Attribut, um zu schätzen, wann eine Richtlinienänderung auf zuvor aufgenommene Objekte angewendet wird. Wenn sich das Attribut Repears versuchte über einen Zeitraum nicht länger als der aktuelle Scanzeitraum erhöht, ist es wahrscheinlich, dass replizierte Reparaturen durchgeführt werden. Beachten Sie, dass sich der Scanzeitraum ändern kann. Das Attribut Scan Period — Estimated (XSCM) gilt für das gesamte Raster und ist die maximale Anzahl aller Knoten Scan Perioden. Sie können den Attributverlauf des Attributs Scanperiode — Estimated für das Raster abfragen, um einen geeigneten Zeitrahmen zu ermitteln.
Überwachen Sie die Reparatur von Daten, die mit Erasure Coding codiert wurden, und versuchen Sie alle fehlgeschlagenen Anfragen erneut.
1. Status von Datenreparaturen mit Löschungscode ermitteln:
  - Verwenden Sie diesen Befehl, um den Status eines bestimmten anzuzeigen repair-data Betriebliche Gründe:
    
    repair-data show-ec-repair-status --repair-id repair ID
  - Verwenden Sie diesen Befehl, um alle Reparaturen aufzulisten:
    
    repair-data show-ec-repair-status
    
    Die Ausgabe enthält Informationen, einschließlich repair ID, Für alle zuvor und derzeit laufenden Reparaturen.
  root@DC1-ADM1:~ # repair-data show-ec-repair-status Repair ID Scope Start Time End Time State Est Bytes Affected/Repaired Retry Repair ================================================================================== 949283 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:27:06.9 Success 17359 17359 No 949292 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:37:06.9 Failure 17359 0 Yes 949294 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:47:06.9 Failure 17359 0 Yes 949299 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:57:06.9 Failure 17359 0 Yes
2. Wenn in der Ausgabe angezeigt wird, dass der Reparaturvorgang fehlgeschlagen ist, verwenden Sie den --repair-id Option, um die Reparatur erneut zu versuchen.
  
  Mit diesem Befehl wird eine fehlerhafte Node-Reparatur mithilfe der Reparatur-ID 83930030303133434 erneut versucht:
  repair-data start-ec-node-repair --repair-id 83930030303133434
  Mit diesem Befehl wird eine fehlerhafte Volume-Reparatur mithilfe der Reparatur-ID 83930030303133434 wiederholt:
```
repair-data start-ec-volume-repair --repair-id 83930030303133434
```

Verwandte Informationen

"StorageGRID verwalten"

"Monitor Fehlerbehebung"

Wiederherstellen von Objektdaten in einem Storage Volume, falls erforderlich

Creating your file...