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

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

共同作成者 netapp-lhalbert
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. 新しいリカバリ パッケージが利用可能になったらすぐに、リンクをクリックするか、[メンテナンス] > [システム] > [リカバリ パッケージ] を選択して、リカバリ パッケージ ページにアクセスします。次に、 `.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 name>*ilm * を選択します。

    3. ILM キュー グラフの上にカーソルを置くと、スキャン レート (オブジェクト/秒) 属性の値が表示されます。これは、グリッド内のオブジェクトがスキャンされ、ILM のキューに入れられるレートです。

    4. ILM キュー セクションで、次の属性を確認します。

      • * Scan Period - Estimated *：ILMによるすべてのオブジェクトのフルスキャンが完了するまでの推定時間。

        完全スキャンでは、すべてのオブジェクトに ILM が適用されていることが保証されません。

      • 試行された修復: 高リスクと見なされる複製されたデータに対して試行されたオブジェクト修復操作の合計数。高リスク オブジェクトとは、ILM ポリシーによって指定されているか、コピーの損失の結果として、コピーが 1 つ残っているオブジェクトのことです。このカウントは、ストレージ ノードが高リスクのオブジェクトの修復を試みるたびに増加します。グリッドが混雑している場合は、リスクの高い ILM 修復が優先されます。

        修復後にレプリケーションが失敗した場合、同じオブジェクトの修復が再度増加する可能性があります。 + これらの属性は、ストレージ ノード ボリュームのリカバリの進行状況を監視するときに役立ちます。修復の試行回数の増加が止まり、完全スキャンが完了した場合、修復は完了したと考えられます。

    5. あるいは、Prometheusクエリを送信して storagegrid_ilm_scan_period_estimated_minutes`そして `storagegrid_ilm_repairs_attempted。

イレイジャーコーディング（EC）データ

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

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

    • 現在のジョブの完了までの推定時間と完了率を表示するには、[サポート] > [ツール] > [メトリック] を選択します。次に、Grafana セクションで EC 概要 を選択します。 *グリッド 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 の設定をクリアする必要があります。手順については、を参照してください "メンテナンスモードでノード暗号化を監視します"。