Die getrennten Grid-Nodes werden deaktiviert
Möglicherweise müssen Sie einen Knoten außer Betrieb setzen, der derzeit nicht mit dem Grid verbunden ist (einen Node, dessen Status unbekannt oder administrativ ausgefallen ist).
-
Sie kennen die Überlegungen für die Stilllegung "Admin-, Gateway- und Archive-Nodes" Und die Überlegungen zur Stilllegung "Storage-Nodes".
-
Sie haben alle erforderlichen Elemente erhalten.
-
Sie haben sichergestellt, dass keine Datenreparaturjobs aktiv sind. Siehe "Prüfen Sie die Reparatur von Daten".
-
Sie haben bestätigt, dass die Wiederherstellung von Storage-Nodes an keiner Stelle im Grid ausgeführt wird. In diesem Fall müssen Sie warten, bis alle Cassandra-Rebuilds im Rahmen der Recovery abgeschlossen sind. Anschließend können Sie mit der Stilllegung fortfahren.
-
Sie haben sichergestellt, dass andere Wartungsvorgänge während der Deaktivierung des Nodes nicht ausgeführt werden, es sei denn, der Vorgang zur Deaktivierung des Nodes wurde angehalten.
-
Die Spalte Decommission möglich für den Knoten oder Knoten, die Sie außer Betrieb nehmen möchten, enthält ein grünes Häkchen.
-
Sie haben die Provisionierungs-Passphrase.
Sie können nicht verbundene Knoten identifizieren, indem Sie in der Spalte Health nach Unbekannt (blau) oder Administrativ Down (grau)-Symbolen suchen. Im Beispiel ist der Archivknoten DC1-ARC1 getrennt.
Beachten Sie vor dem Stilllegen getrennter Nodes Folgendes:
-
Dieses Verfahren dient in erster Linie zum Entfernen eines einzelnen nicht verbundenen Knotens. Wenn Ihr Grid mehrere getrennte Knoten enthält, muss die Software gleichzeitig ausmustern, wodurch das Potenzial für unerwartete Ergebnisse erhöht wird.
Es kann zu Datenverlusten kommen, wenn Sie mehr als einen getrennten Storage Node gleichzeitig stilllegen. Siehe "Überlegungen zu getrennten Storage-Nodes". Gehen Sie mit Vorsicht vor, wenn Sie Storage-Nodes in einem Grid stilllegen, das rein softwarebasierte Metadaten-Nodes enthält. Wenn Sie alle Knoten außer Betrieb nehmen, die für den Speicher sowohl Objekte als auch Metadaten konfiguriert sind, wird die Fähigkeit zum Speichern von Objekten aus dem Raster entfernt. Siehe "Typen von Storage-Nodes" Weitere Informationen zu nur Metadaten-Storage-Nodes. -
Wenn ein getrennter Knoten nicht entfernt werden kann (z. B. ein Speicher-Knoten, der für das ADC-Quorum erforderlich ist), kann kein anderer getrennter Knoten entfernt werden.
-
Versuchen Sie, alle nicht verbundenen Grid-Nodes wieder online zu schalten oder wiederherzustellen, sofern Sie einen Archive Node nicht stilllegen (der getrennt werden muss).
Siehe "Verfahren zur Recovery von Grid-Nodes" Weitere Anweisungen.
-
Wenn Sie einen nicht verbundenen Grid-Node nicht wiederherstellen können und ihn während der Trennung außer Betrieb nehmen möchten, aktivieren Sie das Kontrollkästchen für diesen Node.
Wenn Ihr Grid mehrere getrennte Knoten enthält, muss die Software gleichzeitig ausmustern, wodurch das Potenzial für unerwartete Ergebnisse erhöht wird. Seien Sie vorsichtig, wenn Sie mehrere getrennte Grid-Nodes gleichzeitig stilllegen möchten, insbesondere wenn Sie mehrere getrennte Storage-Nodes auswählen. Wenn Sie mehr als einen getrennten Storage Node haben, den Sie nicht wiederherstellen können, wenden Sie sich an den technischen Support, um die beste Vorgehensweise zu ermitteln. -
Geben Sie die Provisionierungs-Passphrase ein.
Die Schaltfläche Start Decommission ist aktiviert.
-
Klicken Sie Auf Start Decommission.
Es wird eine Warnung angezeigt, die angibt, dass Sie einen nicht verbundenen Knoten ausgewählt haben und dass Objektdaten verloren gehen, wenn der Knoten die einzige Kopie eines Objekts hat.
-
Überprüfen Sie die Liste der Knoten, und klicken Sie auf OK.
Der Vorgang zur Deaktivierung wird gestartet und für jeden Node wird der Fortschritt angezeigt. Während des Verfahrens wird ein neues Wiederherstellungspaket mit der Änderung der Grid-Konfiguration generiert.
-
Sobald das neue Wiederherstellungspaket verfügbar ist, klicken Sie auf den Link oder wählen Sie WARTUNG > System > Wiederherstellungspaket, um die Seite Wiederherstellungspaket aufzurufen. Laden Sie anschließend die herunter
.zip
Datei:Siehe Anweisungen für "Herunterladen des Wiederherstellungspakets".
Laden Sie das Wiederherstellungspaket so schnell wie möglich herunter, um sicherzustellen, dass Sie Ihr Grid wiederherstellen können, wenn während des Stillfalls etwas schief geht. Die Recovery Package-Datei muss gesichert sein, weil sie Verschlüsselungsschlüssel und Passwörter enthält, die zum Abrufen von Daten vom StorageGRID-System verwendet werden können. -
Überwachen Sie die Seite Dekommission regelmäßig, um sicherzustellen, dass alle ausgewählten Knoten erfolgreich außer Betrieb gesetzt werden.
Storage-Nodes können Tage oder Wochen ausmustern. Wenn alle Aufgaben abgeschlossen sind, wird die Liste der Knotenauswahl mit einer Erfolgsmeldung erneut angezeigt. Wenn Sie einen getrennten Speicherknoten außer Betrieb genommen haben, zeigt eine Informationsmeldung an, dass die Reparaturaufträge gestartet wurden.
-
Nachdem die Nodes im Rahmen der Stilllegung automatisch heruntergefahren wurden, entfernen Sie alle verbleibenden Virtual Machines oder anderen Ressourcen, die dem ausgemusterten Node zugeordnet sind.
Führen Sie diesen Schritt erst aus, wenn die Nodes automatisch heruntergefahren wurden. -
Wenn Sie einen Storage Node außer Betrieb nehmen, überwachen Sie den Status der Reparatur-Jobs mit replizierten Daten und Erasure-codierten (EC) Daten, die während des Stilllegungsprozesses automatisch gestartet werden.
-
Um einen geschätzten Fertigstellungsgrad für die replizierte Reparatur zu erhalten, fügen Sie die hinzu
show-replicated-repair-status
Option zum Befehl Repair-Data.repair-data show-replicated-repair-status
-
So stellen Sie fest, ob Reparaturen abgeschlossen sind:
-
Wählen Sie NODES > Storage Node wird repariert > ILM.
-
Prüfen Sie die Attribute im Abschnitt Bewertung. Wenn die Reparaturen abgeschlossen sind, weist das Attribut wartet - Alle 0 Objekte an.
-
-
So überwachen Sie die Reparatur genauer:
-
Wählen Sie SUPPORT > Tools > Grid-Topologie aus.
-
Wählen Sie Grid > Storage Node wird repariert > LDR > Data Store.
-
Verwenden Sie eine Kombination der folgenden Attribute, um festzustellen, ob replizierte Reparaturen abgeschlossen sind.
Cassandra-Inkonsistenzen sind möglicherweise 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.
-
-
So überwachen Sie die Reparatur von Daten mit Verfahren zur Einhaltung von Datenkonsistenz und versuchen Sie es erneut, eventuell fehlgeschlagene Anfragen zu senden:
-
Status von Datenreparaturen mit Löschungscode ermitteln:
-
Wählen Sie SUPPORT > Tools > Metrics, um die geschätzte Zeit bis zum Abschluss und den Fertigstellungsgrad für den aktuellen Job anzuzeigen. Wählen Sie dann im Abschnitt Grafana die Option EC Übersicht aus. Sehen Sie sich die Dashboards Grid EC Job Estimated Time to Completion und Grid EC Job prozentual Completed an.
-
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. -
-
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 6949309319275667690 erneut versucht:
repair-data start-ec-node-repair --repair-id 6949309319275667690
Mit diesem Befehl wird eine fehlerhafte Volume-Reparatur mithilfe der Reparatur-ID 6949309319275667690 wiederholt:
repair-data start-ec-volume-repair --repair-id 6949309319275667690
Sobald die getrennten Nodes außer Betrieb genommen und alle Reparatur-Jobs abgeschlossen sind, können Sie alle verbundenen Grid-Nodes je nach Bedarf ausmustern.
Führen Sie anschließend die folgenden Schritte aus, nachdem Sie den Vorgang zur Deaktivierung abgeschlossen haben:
-
Stellen Sie sicher, dass die Laufwerke des ausgemusterten Grid-Node sauber gelöscht werden. Verwenden Sie ein handelsübliches Datenwischwerkzeug oder einen Dienst, um die Daten dauerhaft und sicher von den Laufwerken zu entfernen.
-
Wenn Sie einen Appliance-Node deaktiviert haben und die Daten auf der Appliance mithilfe der Node-Verschlüsselung geschützt wurden, löschen Sie die Konfiguration des Verschlüsselungsmanagement-Servers (Clear KMS) mithilfe des StorageGRID Appliance Installer. Wenn Sie die Appliance einem anderen Grid hinzufügen möchten, müssen Sie die KMS-Konfiguration löschen. Anweisungen hierzu finden Sie unter "Überwachung der Node-Verschlüsselung im Wartungsmodus".