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 Package *を選択して、Recovery Packageページにアクセスします。次に、をダウンロードします .zip ファイル。

    リカバリパッケージのダウンロード手順を参照してください。

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

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

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

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

    1. Support > Tools > Grid Topology *を選択します。

    2. グリッドトポロジツリーの上部にある「* StorageGRID deployment」を選択します。

    3. 概要タブで、ILMアクティビティセクションを探します。

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

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

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

    5. 修復を追跡または再開するには、次のコマンドを使用します。

      • を使用します repair-data show-ec-repair-status イレイジャーコーディングデータの修復を追跡するコマンド。

      • を使用します repair-data start-ec-node-repair コマンドにを指定します --repair-id 失敗した修復を再開するオプションです。データ修復ジョブの確認手順を参照してください。

  10. 修復ジョブがすべて正常に完了するまで、引き続きECデータの修復のステータスを追跡します。

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

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