Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Appliance-Storage-Volumes neu einbinden und formatieren (manuelle Schritte)

Beitragende
PDFs

Führen Sie manuell zwei Skripte aus, um noch intaerte Storage-Volumes neu mounten und ausgefallene Storage Volumes neu formatieren zu können. Das erste Skript bindet Volumes wieder ein, die ordnungsgemäß als StorageGRID-Storage-Volumes formatiert sind. Das zweite Skript formatiert alle nicht abgehängt Volumes neu, stellt die Cassandra-Datenbank bei Bedarf wieder her und startet Services.

Bevor Sie beginnen

  • Sie haben bereits die Hardware für alle ausgefallenen Storage Volumes ausgetauscht, die ausgetauscht werden müssen.

    Ausführen des sn-remount-volumes Skript kann Ihnen helfen, zusätzliche ausgefallene Storage-Volumes zu identifizieren.

  • Sie haben überprüft, dass keine Ausmusterung von Storage-Nodes ausgeführt wird oder Sie den Vorgang zur Deaktivierung eines Node angehalten haben. (Wählen Sie im Grid Manager MAINTENANCE > Tasks > Decommission.)

  • Sie haben überprüft, dass keine Erweiterung ausgeführt wird. (Wählen Sie im Grid Manager MAINTENANCE > Tasks > Expansion.)

Achtung Wenden Sie sich an den technischen Support, wenn mehr als ein Speicherknoten offline ist oder wenn ein Speicherknoten in diesem Grid in den letzten 15 Tagen neu aufgebaut wurde. Führen Sie das nicht aus sn-recovery-postinstall.sh Skript: Die Neuerstellung von Cassandra auf zwei oder mehr Storage-Nodes innerhalb von 15 Tagen voneinander kann zu Datenverlust führen.
Über diese Aufgabe

Zum Abschluss dieses Vorgangs führen Sie die folgenden grundlegenden Aufgaben aus:

  • Melden Sie sich beim wiederhergestellten Speicherknoten an.

  • Führen Sie die aus sn-remount-volumes Skript zum Neumounten ordnungsgemäß formatierter Speicher-Volumes. Wenn dieses Skript ausgeführt wird, führt es Folgendes aus:

    • Hängt jedes Storage-Volume an und ab, um das XFS-Journal wiederzugeben.

    • Führt eine Konsistenzprüfung der XFS-Datei durch.

    • Wenn das Dateisystem konsistent ist, bestimmt, ob das Storage Volume ein ordnungsgemäß formatiertes StorageGRID Storage Volume ist.

    • Wenn das Storage Volume ordnungsgemäß formatiert ist, wird das Storage-Volume wieder gemountet. Alle bestehenden Daten auf dem Volume bleiben erhalten.

  • Prüfen Sie die Skriptausgabe und beheben Sie etwaige Probleme.

  • Führen Sie die aus sn-recovery-postinstall.sh Skript: Wenn dieses Skript ausgeführt wird, führt es Folgendes aus.

    Wichtig Starten Sie einen Storage-Node vor der Ausführung nicht während der Wiederherstellung neu sn-recovery-postinstall.sh (Schritt 4) zum Neuformatieren der ausgefallenen Storage Volumes und zum Wiederherstellen von Objekt-Metadaten. Vor dem Neubooten des Speicherknoten sn-recovery-postinstall.sh Durch das Abschließen werden Fehler bei Diensten verursacht, die zu starten versuchen, und die Knoten der StorageGRID-Appliance den Wartungsmodus beenden.

    • Umformatiert alle Storage-Volumes, die von der sn-remount-volumes Das Skript konnte nicht gemountet werden oder es wurde festgestellt, dass es nicht ordnungsgemäß formatiert wurde.

      Hinweis Wenn ein Speicher-Volume neu formatiert wird, gehen alle Daten auf diesem Volume verloren. Sie müssen ein zusätzliches Verfahren durchführen, um Objektdaten von anderen Standorten im Grid wiederherzustellen, vorausgesetzt, dass ILM-Regeln für die Speicherung von mehr als einer Objektkopie konfiguriert wurden.

    • Stellt die Cassandra-Datenbank bei Bedarf auf dem Node wieder her.

    • Startet die Dienste auf dem Speicherknoten.

Schritte

  1. Melden Sie sich beim wiederhergestellten Speicherknoten an:

    1. Geben Sie den folgenden Befehl ein: ssh admin@grid_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 #.

  2. Führen Sie das erste Skript aus, um alle ordnungsgemäß formatierten Speicher-Volumes neu zu mounten.

    Hinweis Wenn alle Speicher-Volumes neu sind und formatiert werden müssen, oder wenn alle Speicher-Volumes ausgefallen sind, können Sie diesen Schritt überspringen und das zweite Skript ausführen, um alle nicht abgehängt Speicher-Volumes neu zu formatieren.

    1. Führen Sie das Skript aus: sn-remount-volumes

      Dieses Skript kann Stunden dauern, bis es auf Storage-Volumes ausgeführt wird, die Daten enthalten.

    2. Überprüfen Sie die Ausgabe, während das Skript ausgeführt wird, und beantworten Sie alle Eingabeaufforderungen.

      Hinweis Nach Bedarf können Sie die verwenden tail -f Befehl zum Überwachen des Inhalts der Protokolldatei des Skripts (/var/local/log/sn-remount-volumes.log) . Die Protokolldatei enthält ausführlichere Informationen als die Befehlsausgabe der Befehlszeile. 
      root@SG:~ # sn-remount-volumes
The configured LDR noid is 12632740

====== Device /dev/sdb ======
Mount and unmount device /dev/sdb and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sdb:
Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12632740, volume number 0 in the volID file
Attempting to remount /dev/sdb
Device /dev/sdb remounted successfully

====== Device /dev/sdc ======
Mount and unmount device /dev/sdc and checking file system consistency:
Error: File system consistency check retry failed on device /dev/sdc.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID Webscale will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policy.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sdd ======
Mount and unmount device /dev/sdd and checking file system consistency:
Failed to mount device /dev/sdd
This device could be an uninitialized disk or has corrupted superblock.
File system check might take a long time. Do you want to continue? (y or n) [y/N]? y

Error: File system consistency check retry failed on device /dev/sdd.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID Webscale will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policy.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sde ======
Mount and unmount device /dev/sde and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sde:
Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12000078, volume number 9 in the volID file
Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      In der Beispielausgabe wurde ein Storage-Volume erfolgreich neu eingebunden und drei Storage-Volumes wiesen Fehler auf.

      • /dev/sdb Die Konsistenzprüfung des XFS-Dateisystems wurde bestanden und hatte eine gültige Volume-Struktur, so dass es erfolgreich neu eingebunden wurde. Daten auf Geräten, die vom Skript neu eingebunden werden, bleiben erhalten.

      • /dev/sdc Die Konsistenzprüfung des XFS-Dateisystems ist fehlgeschlagen, da das Speichervolume neu oder beschädigt war.

      • /dev/sdd Konnte nicht gemountet werden, da die Festplatte nicht initialisiert wurde oder der Superblock der Festplatte beschädigt war. Wenn das Skript ein Speichervolume nicht mounten kann, werden Sie gefragt, ob Sie die Konsistenzprüfung des Dateisystems ausführen möchten.

        • Wenn das Speichervolumen an eine neue Festplatte angeschlossen ist, beantworten Sie N mit der Eingabeaufforderung. Sie müssen das Dateisystem auf einer neuen Festplatte nicht überprüfen.

        • Wenn das Speichervolumen an eine vorhandene Festplatte angeschlossen ist, beantworten Sie Y mit der Eingabeaufforderung. Sie können die Ergebnisse der Dateisystemüberprüfung verwenden, um die Quelle der Beschädigung zu bestimmen. Die Ergebnisse werden im gespeichert /var/local/log/sn-remount-volumes.log Protokolldatei.

      • /dev/sde Die Konsistenzprüfung des XFS-Dateisystems wurde bestanden und eine gültige Volume-Struktur hatte; die LDR-Knoten-ID befindet sich jedoch im volID Die Datei stimmt nicht mit der ID für diesen Speicherknoten überein (der configured LDR noid Oben angezeigt). Diese Meldung gibt an, dass dieses Volume zu einem anderen Speicherknoten gehört.

  3. Prüfen Sie die Skriptausgabe und beheben Sie etwaige Probleme.

    Wichtig Wenn ein Speichervolume die Konsistenzprüfung des XFS-Dateisystems fehlgeschlagen ist oder nicht gemountet werden konnte, überprüfen Sie sorgfältig die Fehlermeldungen in der Ausgabe. Sie müssen die Auswirkungen der Ausführung des verstehen sn-recovery-postinstall.sh Skript auf diesen Volumen.

    1. Überprüfen Sie, ob die Ergebnisse einen Eintrag für alle Volumes enthalten, die Sie erwartet haben. Wenn keine Volumes aufgeführt sind, führen Sie das Skript erneut aus.

    2. Überprüfen Sie die Meldungen für alle angeschlossenen Geräte. Stellen Sie sicher, dass keine Fehler vorliegen, die darauf hinweisen, dass ein Speichervolume nicht zu diesem Speicherknoten gehört.

      Im Beispiel enthält die Ausgabe für /dev/sde die folgende Fehlermeldung:

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      Achtung Wenn ein Storage-Volume gemeldet wird, das zu einem anderen Storage Node gehört, wenden Sie sich an den technischen Support. Wenn Sie den ausführen sn-recovery-postinstall.sh Skript: Das Speichervolumen wird neu formatiert, was zu Datenverlust führen kann.

    3. Wenn keine Speichergeräte montiert werden konnten, notieren Sie sich den Gerätenamen und reparieren oder ersetzen Sie das Gerät.

      Hinweis Sie müssen Speichergeräte reparieren oder ersetzen, die nicht montiert werden können.

      Sie verwenden den Gerätenamen, um die Volume-ID zu suchen. Dies ist erforderlich, wenn Sie den ausführen repair-data Skript zum Wiederherstellen von Objektdaten auf dem Volume (beim nächsten Verfahren).

    4. Führen Sie nach der Reparatur oder dem Austausch aller nicht montierbaren Geräte den aus sn-remount-volumes Skript erneut, um zu bestätigen, dass alle Speicher-Volumes, die neu gemountet werden können, neu eingebunden wurden.

      Wichtig Wenn ein Storage-Volume nicht gemountet oder nicht ordnungsgemäß formatiert werden kann und Sie mit dem nächsten Schritt fortfahren, werden das Volume und sämtliche Daten auf dem Volume gelöscht. Falls Sie zwei Kopien von Objektdaten hatten, ist nur eine einzige Kopie verfügbar, bis Sie das nächste Verfahren (Wiederherstellen von Objektdaten) abgeschlossen haben.
    Achtung Führen Sie das nicht aus sn-recovery-postinstall.sh Skript, wenn Sie glauben, dass die auf einem ausgefallenen Storage-Volume verbleibenden Daten nicht von einer anderen Stelle im Raster neu erstellt werden können (Beispiel: Wenn Ihre ILM-Richtlinie eine Regel verwendet, die nur eine Kopie erstellt, oder wenn Volumes auf mehreren Nodes ausgefallen sind). Wenden Sie sich stattdessen an den technischen Support, um zu ermitteln, wie Sie Ihre Daten wiederherstellen können.

  4. Führen Sie die aus sn-recovery-postinstall.sh Skript: sn-recovery-postinstall.sh

    Dieses Skript formatiert alle Storage-Volumes, die nicht gemountet werden konnten oder die sich als falsch formatiert herausfanden. Darüber hinaus wird die Cassandra-Datenbank bei Bedarf auf dem Node wiederhergestellt und die Services auf dem Storage-Node gestartet.

    Beachten Sie Folgendes:

    • Das Skript kann Stunden in Anspruch nehmen.

    • Im Allgemeinen sollten Sie die SSH-Sitzung allein lassen, während das Skript ausgeführt wird.

    • Drücken Sie nicht Strg+C, während die SSH-Sitzung aktiv ist.

    • Das Skript wird im Hintergrund ausgeführt, wenn eine Netzwerkunterbrechung auftritt und die SSH-Sitzung beendet wird. Sie können jedoch den Fortschritt auf der Seite Wiederherstellung anzeigen.

    • Wenn der Storage-Node den RSM-Service verwendet, wird das Skript möglicherweise 5 Minuten lang blockiert, während die Node-Services neu gestartet werden. Diese 5-minütige Verzögerung wird erwartet, wenn der RSM-Dienst zum ersten Mal startet.

      Hinweis Der RSM-Dienst ist auf Speicherknoten vorhanden, die den ADC-Service enthalten.
    Hinweis Einige StorageGRID-Wiederherstellungsverfahren verwenden Reaper für die Bearbeitung von Cassandra-Reparaturen. Reparaturen werden automatisch ausgeführt, sobald die entsprechenden oder erforderlichen Services gestartet wurden. Sie können die Skriptausgabe bemerken, die “reaper” oder “Cassandra Reparatur erwähnt.” Wenn eine Fehlermeldung angezeigt wird, dass die Reparatur fehlgeschlagen ist, führen Sie den in der Fehlermeldung angegebenen Befehl aus.

  5. Als der sn-recovery-postinstall.sh Skript wird ausgeführt, überwachen Sie die Wiederherstellungsseite im Grid Manager.

    Die Fortschrittsanzeige und die Spalte Phase auf der Seite Wiederherstellung geben einen allgemeinen Status des an sn-recovery-postinstall.sh Skript:

    Screenshot zeigt den Wiederherstellungsfortschritt in der Grid-Verwaltungsschnittstelle

  6. Nach dem sn-recovery-postinstall.sh Das Skript hat Dienste auf dem Knoten gestartet. Sie können Objektdaten auf allen Speichervolumes wiederherstellen, die mit dem Skript formatiert wurden.

    Das Skript fragt Sie, ob Sie Objektdaten manuell wiederherstellen möchten.

    • In den meisten Fällen sollten Sie "Stellen Sie Objektdaten mithilfe von Grid Manager wieder her". Antwort n Um den Grid-Manager zu verwenden.

    • In seltenen Fällen, z. B. wenn Sie vom technischen Support angewiesen werden oder wenn Sie wissen, dass für den Ersatz-Node weniger verfügbare Volumes für Objekt-Storage als der ursprüngliche Node verfügbar sind, müssen Sie dies tun "Manuelles Wiederherstellen von Objektdaten" Verwenden der repair-data Skript: Wenn einer dieser Fälle zutrifft, antworten Sie y.

      Hinweis

      Wenn Sie antworten y So stellen Sie Objektdaten manuell wieder her:

      • Objektdaten können mit Grid Manager nicht wiederhergestellt werden.

      • Sie können den Fortschritt manueller Wiederherstellungsaufträge mit Grid Manager überwachen.