オブジェクトデータをストレージボリュームにリストアする(システムドライブの障害)
非アプライアンスストレージノードのストレージボリュームをリカバリしたら、ストレージノードの障害で失われたレプリケートオブジェクトデータまたはイレイジャーコーディングオブジェクトデータをリストアできます。
どの手順 を使用すればよいですか。
可能なかぎり、Grid Managerの*[ボリュームのリストア]*ページを使用してオブジェクトデータをリストアします。
-
ボリュームが* maintenance > Volume restore > Nodes to restore *に表示された場合は、を使用してオブジェクトデータをリストアします"Grid Managerのボリュームリストアページ"。
-
ボリュームが* maintenance > Volume restore > Nodes to restore *に表示されない場合は、スクリプトを使用してオブジェクトデータをリストアするため、以下の手順に従ってください。
repair-data
リカバリされたストレージノードのボリューム数が交換対象のノードよりも少ない場合は、スクリプトを使用する必要があり `repair-data`ます。
repair-dataスクリプトは廃止され、今後のリリースで削除される予定です。可能な場合は、を使用し"GridManagerテノホリユウムノリストア手順"ます。 |
スクリプトを使用し `repair-data`てオブジェクトデータをリストアする
-
Grid Managerの* nodes > Overview タブで、リカバリされたストレージノードの接続状態が Connected *になっていることを確認しておきます。
グリッドのILMルールがオブジェクトコピーを作成するように設定されている場合は、他のストレージノードまたはクラウドストレージプールからオブジェクトデータをリストアできます。
次の点に注意してください。
-
レプリケートされたコピーを 1 つだけ保存するように ILM ルールが設定されていて、そのコピーがストレージボリュームに障害が発生した場合、オブジェクトをリカバリすることはできません。
-
オブジェクトのコピーがクラウドストレージプールにしか残っていない場合、 StorageGRID は、オブジェクトデータをリストアするために複数の要求をクラウドストレージプールエンドポイントに問題 する必要があります。この手順 を実行する前に、テクニカルサポートに問い合わせて、リカバリ期間と関連コストの見積もりを依頼してください。
スクリプトについて repair-data
オブジェクトデータをリストアするには、スクリプトを実行し `repair-data`ます。このスクリプトは、オブジェクトデータのリストアプロセスを開始し、 ILM スキャンと連動して ILM ルールを適用します。
以下の* Replicated data または Erasure-Coded(EC)data *を選択すると、レプリケートデータとイレイジャーコーディングデータのどちらをリストアするかに基づいて、スクリプトの各種オプションを確認でき `repair-data`ます。両方のタイプのデータをリストアする必要がある場合は、両方のコマンドセットを実行する必要があります。
スクリプトの詳細を表示するには repair-data 、プライマリ管理ノードのコマンドラインからと入力します repair-data --help 。
|
repair-dataスクリプトは廃止され、今後のリリースで削除される予定です。可能な場合は、を使用し"GridManagerテノホリユウムノリストア手順"ます。 |
レプリケートデータをリストアするコマンドは、ノード全体を修復するのか、ノード上の一部のボリュームのみを修復するのかに応じて 2 つあります。
repair-data start-replicated-node-repair
repair-data start-replicated-volume-repair
レプリケートデータの修復は、次のコマンドで追跡できます。
repair-data show-replicated-repair-status
イレイジャーコーディングデータをリストアするコマンドは、ノード全体を修復するのか、ノード上の一部のボリュームのみを修復するのかに応じて 2 つあります。
repair-data start-ec-node-repair
repair-data start-ec-volume-repair
イレイジャーコーディングデータの修復は、次のコマンドで追跡できます。
repair-data show-ec-repair-status
イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。ただし、すべてのイレイジャーコーディングデータを把握できない場合は、修復を完了できません。修復はすべてのノードが使用可能になったあとに完了します。 |
EC 修復ジョブによって、大量のストレージが一時的にリザーブされます。ストレージアラートがトリガーされることもありますが、修復が完了すると解決します。予約に必要なストレージが不足していると、 EC の修復ジョブが失敗します。ストレージリザベーションは、ジョブが失敗したか成功したかに関係なく、 EC 修復ジョブが完了すると解放されます。 |
ストレージノードのホスト名を探します
-
プライマリ管理ノードにログインします。
-
次のコマンドを入力します。
ssh admin@primary_Admin_Node_IP
-
ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
-
次のコマンドを入力してrootに切り替えます。
su -
-
ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
rootとしてログインすると、プロンプトがからに
#`変わります `$
。
-
-
ファイルを使用して
/etc/hosts
、リストアしたストレージボリュームのストレージノードのホスト名を確認します。グリッド内のすべてのノードのリストを表示するには、次のコマンドを入力します。cat /etc/hosts
すべてのボリュームで障害が発生した場合はデータを修復します
すべてのストレージボリュームで障害が発生した場合は、ノード全体を修復します。レプリケートデータ、イレイジャーコーディング( EC )データ、またはその両方を使用するかどうかに応じて、 * レプリケートデータ * 、 * イレイジャーコーディング( EC )データ * 、またはその両方の手順を実行します。
一部のボリュームだけで障害が発生した場合は、に進みます一部のボリュームのみで障害が発生した場合はデータを修復します。
複数のノードに対して同時に処理を実行することはできません repair-data 。複数のノードをリカバリする場合は、テクニカルサポートにお問い合わせください。
|
グリッドにレプリケートデータが含まれている場合は、コマンドにオプションを指定して --nodes`使用し `repair-data start-replicated-node-repair
、ストレージノード全体を修復します。 `--nodes`はホスト名(システム名)です。
次のコマンドは、 SG-DC-SN3 というストレージノードにあるレプリケートデータを修復します。
repair-data start-replicated-node-repair --nodes SG-DC-SN3
オブジェクトデータのリストア時に、StorageGRID システムがレプリケートされたオブジェクトデータを見つけられない場合は、* Objects lost *アラートがトリガーされます。システム全体のストレージノードでアラートがトリガーされることがあります。損失の原因 と、リカバリが可能かどうかを確認する必要があります。を参照して "損失オブジェクトを調査する" |
グリッドにイレイジャーコーディングデータがある場合は、コマンドでオプションを指定して --nodes`使用し `repair-data start-ec-node-repair
、ストレージノード全体を修復します。 `--nodes`はホスト名(システム名)です。
次のコマンドは、 SG-DC-SN3 というストレージノードにあるイレイジャーコーディングデータを修復します。
repair-data start-ec-node-repair --nodes SG-DC-SN3
この処理を識別する `repair_data`一意のが返され `repair ID`ます。処理の進捗状況と結果を追跡する場合に `repair_data`使用し `repair ID`ます。リカバリプロセスが完了しても、それ以外のフィードバックは返されません。
イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。
一部のボリュームのみで障害が発生した場合はデータを修復します
一部のボリュームだけで障害が発生した場合は、影響を受けたボリュームを修復します。レプリケートデータ、イレイジャーコーディング( EC )データ、またはその両方を使用するかどうかに応じて、 * レプリケートデータ * 、 * イレイジャーコーディング( EC )データ * 、またはその両方の手順を実行します。
すべてのボリュームで障害が発生した場合は、に進みますすべてのボリュームで障害が発生した場合はデータを修復します。
ボリューム ID を 16 進数で入力します。たとえば、 `0000`は最初のボリューム、 `000F`は16番目のボリュームです。1つのボリューム、一連のボリューム、または連続していない複数のボリュームを指定できます。
すべてのボリュームが同じストレージノードにある必要があります。複数のストレージノードのボリュームをリストアする必要がある場合は、テクニカルサポートにお問い合わせください。
グリッドにレプリケートデータがある場合は、 `start-replicated-volume-repair`コマンドでオプションを指定し `--nodes`てノードを特定します( `--nodes`はノードのホスト名)。次に、次の例に示すように、または `--volume-range`オプションを追加し `--volumes`ます。
単一ボリューム:このコマンドは、SG-DC-SN3というストレージノード上のボリュームにレプリケートデータをリストアし `0002`ます。
repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0002
ボリュームの範囲:このコマンドは、SG-DC-SN3というストレージノードのに `0009`含まれるすべてのボリュームにレプリケートデータをリストアし `0003`ます。
repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volume-range 0003,0009
複数のボリュームが連続していません:このコマンドは、レプリケートされたデータをボリューム、および 0005
`0008`SG-DC-SN3というストレージノードにリストアし `0001`ます。
repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0001,0005,0008
オブジェクトデータのリストア時に、StorageGRID システムがレプリケートされたオブジェクトデータを見つけられない場合は、* Objects lost *アラートがトリガーされます。システム全体のストレージノードでアラートがトリガーされることがあります。アラートの概要 と推奨される対処方法をメモして、損失の原因 を特定し、リカバリが可能かどうかを判断します。 |
グリッドにイレイジャーコーディングデータがある場合は、コマンドにオプションを指定し `--nodes`て実行し `start-ec-volume-repair`ます( `--nodes`はノードのホスト名)。次に、次の例に示すように、または `--volume-range`オプションを追加し `--volumes`ます。
単一ボリューム:このコマンドは、SG-DC-SN3というストレージノードのボリュームにイレイジャーコーディングデータをリストアし `0007`ます。
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 0007
ボリュームの範囲:このコマンドは、 0006`SG-DC-SN3というストレージノードの範囲内のすべてのボリュームにイレイジャーコーディングデータをリストアします `0004
。
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volume-range 0004,0006
複数のボリュームが連続していません:このコマンドは、イレイジャーコーディングデータをボリューム、および 000C
`000E`SG-DC-SN3というストレージノードにリストアし `000A`ます。
repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 000A,000C,000E
`repair-data`この処理を識別する `repair_data`一意のが返され `repair ID`ます。処理の進捗状況と結果を追跡する場合に `repair_data`使用し `repair ID`ます。リカバリプロセスが完了しても、それ以外のフィードバックは返されません。
イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。 |
修理を監視する
-
レプリケートデータ * 、 * イレイジャーコーディング( EC )データ * 、またはその両方を使用しているかどうかに基づいて、修復ジョブのステータスを監視します。
実行中のボリュームリストアジョブのステータスを監視し、で完了したリストアジョブの履歴を表示することもできます"Grid Manager"。
-
レプリケートされた修復の完了率を推定するには、repair-dataコマンドにオプションを追加し `show-replicated-repair-status`ます。
repair-data show-replicated-repair-status
-
修理が完了しているかどうかを確認するには、次
-
ノードを選択 * > * _ 修復中のストレージノード _ * > * ILM * を選択します。
-
「評価」セクションの属性を確認します。修理が完了すると、 *Awaiting - All * 属性は 0 個のオブジェクトを示します。
-
-
修理を詳細に監視するには、次の手順を実行します。
-
サポート * > * ツール * > * グリッドトポロジ * を選択します。
-
「 * grid* > * _ Storage Node being repaired _ * > * LDR * > * Data Store * 」を選択します。
-
次の属性を組み合わせて、レプリケートデータの修復が完了したかどうかを可能なかぎり判別します。
Cassandraに不整合がある可能性があり、失敗した修復は追跡されません。 -
* Repairs Attempted ( XRPA ) * :レプリケートデータの修復の進行状況を追跡します。この属性は、ストレージノードがハイリスクオブジェクトの修復を試みるたびに値が増分します。この属性の値が現在のスキャン期間( * Scan Period - - Estimated * 属性で指定)よりも長い期間にわたって上昇しない場合、 ILM スキャンはすべてのノードで修復が必要なハイリスクオブジェクトを検出していません。
ハイリスクオブジェクトとは、完全に失われる危険があるオブジェクトです。ILM設定を満たさないオブジェクトは含まれません。 -
* スキャン期間 - 推定( XSCM ) * :この属性を使用して、以前に取り込まれたオブジェクトにポリシー変更が適用されるタイミングを見積もります。「 * Repairs Attempted * 」属性が現在のスキャン期間よりも長くなっていない場合は、複製修復が実行されている可能性があります。スキャン期間は変わる可能性があるので注意してください。* Scan Period - - Estimated ( XSCM ) * 属性は、グリッド全体の環境 を示します。これは、すべてのノードのスキャン期間の最大値です。グリッドの * Scan Period - - Estimated * 属性履歴を照会して、適切な期間を判断できます。
-
-
イレイジャーコーディングデータの修復を監視し、失敗した可能性のある要求を再試行するには、次の手順を実行します。
-
イレイジャーコーディングデータの修復ステータスを確認します。
-
サポート * > * 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`ます。
-
-
失敗した修復処理が出力された場合は、オプションを使用し `--repair-id`て修復を再試行します。
次のコマンドは、修復ID 6949309319275667690を使用して、障害が発生したノードの修復を再試行します。
repair-data start-ec-node-repair --repair-id 6949309319275667690
次のコマンドは、修復ID 6949309319275667690を使用して、障害が発生したボリュームの修復を再試行します。
repair-data start-ec-volume-repair --repair-id 6949309319275667690