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

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

共同作成者
PDF

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

開始する前に

  • 運用停止に関する考慮事項と運用停止に関する考慮事項について理解しておく"管理ノードとゲートウェイノード""ストレージノード"必要があります。

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

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

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

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

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

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

タスクの内容

切断されているノードを特定するには、* Health *列で青の[不明]アイコンまたはグレーの[ Administratively Down]アイコンをAdministratively Downのアイコン探し不明なアイコンます。

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

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

    注意 切断されている複数のストレージノードを一度に運用停止すると、データが失われる可能性があります。を参照して "切断されているストレージノードに関する考慮事項"
    注意 ソフトウェアベースのメタデータのみのノードを含むグリッド内のストレージノードの運用を停止する場合は注意が必要です。store_both_objectsとmetadataに設定されているすべてのノードの運用を停止すると、オブジェクトを格納する機能がグリッドから削除されます。メタデータ専用ストレージノードの詳細については、を参照してください"ストレージノードのタイプ"。

  • 切断されているノードを削除できない場合（ADCクォーラムに必要なストレージノードなど）は、切断されている他のノードを削除できません。

手順

  1. アーカイブノードの運用を停止する場合（切断する必要があります）を除き、切断されているグリッドノードをオンラインに戻すか、リカバリします。

    手順については'を参照して "グリッドノードのリカバリ手順" ください

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

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

  3. プロビジョニングパスフレーズを入力します。

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

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

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

  5. ノードのリストを確認し、 * OK * をクリックします。

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

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

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

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

  7. 運用停止ページを定期的に監視して、選択したすべてのノードの運用が正常に停止されることを確認してください。

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

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

    注意 ノードが自動的にシャットダウンされるまで、この手順を実行しないでください。

  9. ストレージノードの運用を停止する場合は、運用停止プロセス中に自動的に開始される * Replicated data * および * erasoded （ EC ） data * repair ジョブのステータスを監視します。

レプリケートデータ

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

    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 の設定をクリアする必要があります。手順については、を参照してください "メンテナンスモードでノード暗号化を監視します"。