Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

切断されているグリッドノードの運用を停止

共同作成者

グリッドに現在接続されていないノード(「 Health 」が「 Unknown 」または「 Administratively Down 」のノード)の運用を停止することが必要になる場合があります。

作業を開始する前に
  • 要件とを理解しておきます "グリッドノードの運用停止に関する考慮事項"

  • 前提条件となる項目をすべて用意しておきます。

  • アクティブなデータ修復ジョブがないことを確認しておきます。を参照してください "データ修復ジョブを確認します"

  • グリッド内でストレージノードのリカバリが実行中でないことを確認します。実行中の場合は、リカバリの一環として実行される Cassandra の再構築が完了するまで待機する必要があります。そのあとで運用停止を続行できます。

  • ノード運用停止手順 が一時停止されていないかぎり、ノード手順 の運用停止中に他のメンテナンス手順が実行されないようにしておきます。

  • 運用停止するノードの * 運用停止可能な * 列には、緑のチェックマークが表示されます。

  • プロビジョニングパスフレーズを用意します。

このタスクについて

切断されているノードは、「 * Health * 」列で「 Unknown 」(青)または「 Administratively Down 」(グレー)のアイコンで特定できます。この例では、 DC1-S4 という名前のストレージノードが接続解除されており、他のすべてのノードが接続されています。

1 つのノードが切断されているノードの運用停止ページ

切断されているノードの運用を停止する前に、次の点に注意して

  • この手順 は、主に切断されている 1 つのノードを削除することを目的としています。グリッド内に切断されているノードが複数ある場合は、それらのノードをすべて同時に運用停止する必要があるため、予期しない結果になる可能性があります。

    重要 切断されている複数のグリッドノードの運用を一度に停止する場合、特に切断されている複数のストレージノードを選択する場合は注意が必要です。
  • 切断されているノードを削除できない場合(ADCクォーラムに必要なストレージノードなど)は、切断されている他のノードを削除できません。

切断されている * ストレージノード * の運用を停止する前に、次の点に注意してください

  • 切断されているストレージノードの運用停止は、オンラインにしたりリカバリしたりできないことが確実である場合を除き、絶対に実行しないでください。

    重要 ノードからオブジェクトデータをリカバリできる可能性がある場合は、この手順 を実行しないでください。代わりに、テクニカルサポートに問い合わせて、ノードのリカバリが可能かどうかを確認してください。
  • 切断されている複数のストレージノードの運用を停止すると、データが失われる可能性があります。十分な数のオブジェクトコピー、イレイジャーコーディングフラグメント、またはオブジェクトメタデータが残っていると、システムがデータを再構築できない場合があります。

    重要 切断されていてリカバリできないストレージノードが複数ある場合は、テクニカルサポートに連絡して、最適な対処方法を確認してください。
  • 切断されているストレージノードの運用を停止すると、 StorageGRID は運用停止手順の終了時にデータ修復ジョブを開始します。これらのジョブは、切断されているノードに格納されていたオブジェクトデータとメタデータの再構築を試みます。

  • 切断されているストレージノードの運用を停止する場合、手順 の運用停止は比較的短時間で完了します。ただし、データ修復ジョブは実行に数日から数週間かかることがあり、運用停止手順 によって監視されません。これらのジョブは手動で監視し、必要に応じて再開してください。を参照してください "データ修復ジョブを確認します"

  • オブジェクトの唯一のコピーを含む切断されているストレージノードの運用を停止すると、そのオブジェクトは失われます。データ修復ジョブは、現在接続されているストレージノードに、 1 つ以上のレプリケートコピーまたは十分なイレイジャーコーディングフラグメントが含まれている場合のみ、オブジェクトを再構築してリカバリできます。

切断されている * 管理ノード * または * ゲートウェイノード * の運用を停止する前に、次の点に注意してください。

  • 切断されている管理ノードの運用を停止すると、そのノードの監査ログが失われますが、これらのログはプライマリ管理ノードにも存在している必要があります。

  • 切断されているゲートウェイノードは安全に運用停止できます。

手順
  1. 切断されているグリッドノードのオンラインへの復帰またはリカバリを試行します。

    手順については、リカバリ手順を参照してください。

  2. 切断されているグリッドノードをリカバリできず、切断されている間に運用を停止する場合は、そのノードのチェックボックスを選択します。

    メモ グリッド内に切断されているノードが複数ある場合は、それらのノードをすべて同時に運用停止する必要があるため、予期しない結果になる可能性があります。
    重要 切断されている複数のグリッドノードの運用を一度に停止する場合、特に複数のストレージノードを選択する場合は注意が必要です。切断されていてリカバリできないストレージノードが複数ある場合は、テクニカルサポートに連絡して、最適な対処方法を確認してください。
  3. プロビジョニングパスフレーズを入力します。

    [ * 分解を開始 * ( Start Decommission * ) ] ボタンが有効になります。

  4. * 分解を開始 * をクリックします。

    切断されているノードが選択されていることと、そのノードにオブジェクトの唯一のコピーが含まれている場合はオブジェクトデータが失われることを示す警告が表示されます。

    運用停止の警告メッセージのスクリーンショット
  5. ノードのリストを確認し、 * OK * をクリックします。

    運用停止手順 が開始され、ノードごとの進行状況が表示されます。手順 の実行中に、グリッド設定の変更を含む新しいリカバリパッケージが生成されます。

    実行中のノードの運用停止のスクリーンショット
  6. 新しいリカバリパッケージが利用可能になったら、リンクをクリックするか、 * maintenance * > * System * > * Recovery パッケージ * を選択して、リカバリパッケージのページにアクセスします。次に、をダウンロードします .zip ファイル。

    メモ 手順 の運用停止中に問題が発生した場合にグリッドをリカバリできるよう、できるだけ早くリカバリパッケージをダウンロードしてください。
    重要 リカバリパッケージファイルには StorageGRID システムからデータを取得するための暗号キーとパスワードが含まれているため、安全に保管する必要があります。
  7. 運用停止ページを定期的に監視して、選択したすべてのノードの運用が正常に停止されることを確認してください。

    ストレージノードの運用停止には、数日から数週間かかることがあります。すべてのタスクが完了すると、成功メッセージとともにノード選択リストが再表示されます。切断されているストレージノードの運用を停止した場合は、修復ジョブが開始されたことを示す情報メッセージが表示されます。

    修復ジョブが開始されたことを示すスクリーンショット
  8. 運用停止手順 の一環としてノードが自動的にシャットダウンされたら、運用停止したノードに関連付けられている残りの仮想マシンやその他のリソースをすべて削除します。

    重要 ノードが自動的にシャットダウンされるまで、この手順を実行しないでください。
  9. ストレージノードの運用を停止する場合は、運用停止プロセス中に自動的に開始される * Replicated data * および * erasoded ( EC ) data * repair ジョブのステータスを監視します。

レプリケートデータ
  • レプリケートされた修復の完了率を推定するには、を追加します show-replicated-repair-status repair-dataコマンドのオプション。

    repair-data show-replicated-repair-status

  • 修理が完了しているかどうかを確認するには、次

    1. ノードを選択 * > * _ 修復中のストレージノード _ * > * ILM * を選択します。

    2. 「評価」セクションの属性を確認します。修理が完了すると、 *Awaiting - All * 属性は 0 個のオブジェクトを示します。

  • 修理を詳細に監視するには、次の手順を実行します。

    1. サポート * > * ツール * > * グリッドトポロジ * を選択します。

    2. 「 * grid* > * _ Storage Node being repaired _ * > * LDR * > * Data Store * 」を選択します。

    3. 次の属性を組み合わせて、レプリケートデータの修復が完了したかどうかを可能なかぎり判別します。

      メモ Cassandraに不整合がある可能性があり、失敗した修復は追跡されません。
      • * Repairs Attempted ( XRPA ) * :レプリケートデータの修復の進行状況を追跡します。この属性は、ストレージノードがハイリスクオブジェクトの修復を試みるたびに値が増分します。この属性の値が現在のスキャン期間( * Scan Period - - Estimated * 属性で指定)よりも長い期間にわたって上昇しない場合、 ILM スキャンはすべてのノードで修復が必要なハイリスクオブジェクトを検出していません。

        メモ ハイリスクオブジェクトとは、完全に失われる危険があるオブジェクトです。ILM設定を満たさないオブジェクトは含まれません。
      • * スキャン期間 - 推定( XSCM ) * :この属性を使用して、以前に取り込まれたオブジェクトにポリシー変更が適用されるタイミングを見積もります。「 * Repairs Attempted * 」属性が現在のスキャン期間よりも長くなっていない場合は、複製修復が実行されている可能性があります。スキャン期間は変わる可能性があるので注意してください。* Scan Period - - Estimated ( XSCM ) * 属性は、グリッド全体の環境 を示します。これは、すべてのノードのスキャン期間の最大値です。グリッドの * Scan Period - - Estimated * 属性履歴を照会して、適切な期間を判断できます。

イレイジャーコーディング( EC )データ

イレイジャーコーディングデータの修復を監視し、失敗した可能性のある要求を再試行するには、次の手順を実行します。

  1. イレイジャーコーディングデータの修復ステータスを確認します。

    • サポート * > * Tools * > * Metrics * を選択して、現在のジョブの完了までの推定時間と完了率を表示します。次に、 Grafana のセクションで * EC Overview * を選択します。グリッド EC ジョブの完了予想時間 * ダッシュボードと * グリッド EC ジョブの完了率 * ダッシュボードを確認します。

    • 特定のののステータスを表示するには、このコマンドを使用します repair-data 操作:

      repair-data show-ec-repair-status --repair-id repair ID

    • すべての修復処理を表示するには、次のコマンドを使用します

      repair-data show-ec-repair-status

    出力には、などの情報が表示されます `repair ID`以前に、現在実行中のすべての修復。

  2. 失敗した修復処理が出力された場合は、を使用します --repair-id 修復を再試行するオプションです。

    このコマンドは、修復 ID 6949309319275667690 を使用して、障害が発生したノードの修復を再試行します。

    repair-data start-ec-node-repair --repair-id 6949309319275667690

    このコマンドは、修復 ID 6949309319275667690 を使用して、障害が発生したボリュームの修復を再試行します。

    repair-data start-ec-volume-repair --repair-id 6949309319275667690

完了後

切断されているノードが運用停止され、すべてのデータ修復ジョブが完了したら、必要に応じて、接続されているグリッドノードの運用を停止できます。

その後、手順 の運用停止が完了したら、次の手順を実行します。

  • 運用停止したグリッドノードのドライブを確実に消去します。市販のデータ消去ツールまたはデータ消去サービスを使用して、ドライブからデータを完全かつ安全に削除します。

  • アプライアンスノードの運用を停止し、ノード暗号化を使用してアプライアンスのデータが保護されていた場合は、 StorageGRID アプライアンスインストーラを使用してキー管理サーバ設定( Clear KMS )をクリアします。アプライアンスを別のグリッドに追加する場合は、 KMS の設定をクリアする必要があります。手順については、を参照してください "メンテナンスモードでノード暗号化を監視します"