ストレージ ボリュームへのオブジェクト データのリストア(必要な場合)

sn-recovery-postinstall.shスクリプトで障害が発生したストレージ ボリュームを再フォーマットした場合は、他のストレージ ノードとアーカイブ ノードから再フォーマットされたストレージ ボリュームにオブジェクト データをリストアする必要があります。この手順は、ストレージ ボリュームを再フォーマットしていなければ必要ありません。

開始する前に

タスク概要

グリッドのILMルールがオブジェクト コピーを作成するように設定されていた場合は、他のストレージ ノード、アーカイブ ノード、またはクラウド ストレージ プールからオブジェクト データをリストアできます。

注意: レプリケート コピーを1つだけ保存するようにILMルールを設定していた場合に、そのコピーがあるストレージ ボリュームで障害が発生すると、オブジェクトをリカバリできません。
注意: オブジェクトのコピーがクラウド ストレージ プールにしか残っていない場合、StorageGRIDクラウド ストレージ プールに対して複数の要求を実行してオブジェクト データを読み出す必要があります。この手順を実行する前に、テクニカル サポートにリカバリ期間と関連コストの見積もりを依頼してください。
注: オブジェクトのコピーがアーカイブ ノードにしか残っていない場合は、アーカイブ ノードからオブジェクト データが読み出されます。外部アーカイブ ストレージ システムからの読み出しには遅延が伴うため、アーカイブ ノードからストレージ ノードへのオブジェクト データのリストアには、別のストレージ ノードからコピーをリストアする場合に比べて時間がかかります。

オブジェクト データをリストアするには、repair-dataスクリプトを実行します。このスクリプトは、オブジェクト データのリストア プロセスを開始し、ILMスキャンと連動してILMルールを適用します。レプリケート データとイレイジャー コーディング データのどちらをリストアするかによって、repair-dataスクリプトで使用するオプションが異なります。

repair-dataスクリプトの使用方法の詳細を表示するには、プライマリ管理ノードのコマンドラインでrepair-data --helpと入力します。

手順

  1. サービス ラップトップから、プライマリ管理ノードにログインします。
    1. 次のコマンドを入力します:ssh admin@primary_Admin_Node_IP
    2. Passwords.txtファイルに含まれているパスワードを入力します。
    3. 次のコマンドを入力してrootに切り替えます:su -
    4. Passwords.txtファイルに含まれているパスワードを入力します。
      rootとしてログインすると、プロンプトが$から#に変わります。
  2. /etc/hostsファイルを使用して、リストアされたストレージ ボリュームのストレージ ノードのホスト名を探します。グリッド内のすべてのノードのリストを表示するには、次のコマンドを入力します:cat /etc/hosts
  3. すべてのストレージ ボリュームで障害が発生した場合は、ノード全体を修復します (一部のボリュームだけで障害が発生した場合は、次の手順に進みます)。
    注意: 複数のノードに対して同時にrepair-data処理を実行することはできません。複数のノードをリカバリする場合は、テクニカル サポートにお問い合わせください。
    • グリッドにレプリケート データがある場合は、repair-data start-replicated-node-repairコマンドで--nodesオプションを指定して、ストレージ ノード全体を修復します。

      次のコマンドは、SG-DC-SN3という名前のストレージ ノードにあるレプリケート データを修復します。

      repair-data start-replicated-node-repair --nodes SG-DC-SN3
      注: オブジェクト データのリストア時、StorageGRIDシステムがレプリケートされたオブジェクト データを見つけられない場合は、Objects Lostアラートと従来のLOST(Lost Objects)アラームがトリガーされます。システム全体のストレージ ノードに対してアラートと従来のアラームがトリガーされることがあります。データが見つからない原因と、リカバリが必要かどうかを確認する必要があります。StorageGRIDの監視とトラブルシューティングの手順を参照してください。
    • グリッドにイレイジャー コーディング データがある場合は、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 IDを使用して、repair_data処理の進行状況と結果を追跡します。リカバリ プロセスが完了するまでにこの他に返される情報はありません。

      注: イレイジャー コーディング データの修復は、一部のストレージ ノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。
    • グリッドにレプリケート データとイレイジャー コーディング データの両方がある場合は、両方のコマンドを実行します。
  4. 一部のボリュームだけで障害が発生した場合は、影響を受けたボリュームを修復します。
    ボリュームIDを16進数で入力します。たとえば、0000は最初のボリューム、000Fは16番目のボリュームです。1つまたは一連のボリュームを指定できます。
    • グリッドにレプリケート データがある場合は、start-replicated-volume-repairコマンドで--nodesオプションと--volume-rangeオプションを指定します。

      次のコマンドは、SG-DC-SN3というストレージ ノードの0003~000Bのすべてのボリュームにレプリケート データをリストアします。

      repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volume-range 0003,000B

      レプリケート データの場合は、同じノードに対して複数のrepair-data処理を同時に実行できます。この方法は、連続しない2つのボリューム(0000と000Aなど)をリストアする必要がある場合に使用します。

      注: オブジェクト データのリストア時、StorageGRIDシステムがレプリケートされたオブジェクト データを見つけられない場合は、Objects Lostアラートと従来のLOST(Lost Objects)アラームがトリガーされます。システム全体のストレージ ノードに対してアラートと従来のアラームがトリガーされることがあります。データが見つからない原因と、リカバリが必要かどうかを確認する必要があります。StorageGRIDの監視とトラブルシューティングの手順を参照してください。
    • グリッドにイレイジャー コーディング データがある場合は、start-ec-volume-repairコマンドで--nodesオプションと--volume-rangeオプションを指定します。

      次のコマンドは、SG-DC-SN3というストレージ ノードの000Aという1つのボリュームにイレイジャー コーディング データをリストアします。

      repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volume-range 000A

      イレイジャー コーディング データの場合は、1つのrepair-data start ec-volume-repair処理が完了してから、同じノードに対して2回目のrepair-data処理を開始する必要があります。

      repair-data処理は、このrepair_data処理に対する一意のrepair IDを返します。このrepair IDを使用して、repair_data処理の進行状況と結果を追跡します。リカバリ プロセスが完了するまでにこの他に返される情報はありません。
      注: イレイジャー コーディング データの修復は、一部のストレージ ノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。
    • グリッドにレプリケート データとイレイジャー コーディング データの両方がある場合は、両方のコマンドを実行します。
  5. レプリケート データの修復を監視します。
    1. [Nodes] > [Storage Node being repaired] > [ILM]を選択します。
    2. [Evaluation]セクションの属性を使用して、修復が完了したかどうかを確認します。
      修復が完了すると、[Awaiting - All]属性のオブジェクト数は0になります。
    3. 修復を詳細に監視するには、[Support] > [Grid Topology]を選択します。
    4. [grid] > [Storage Node being repaired] > [LDR] > Data Store]を選択します。
    5. 次の属性を確認し、レプリケート データの修復が完了したかどうかを可能なかぎり判断します。
      注: Cassandraに不整合が生じている可能性があり、また、失敗した修復は追跡されません。
      • Repairs Attempted (XRPA):この属性を使用して、レプリケート データの修復の進行状況を追跡します。この属性は、ストレージ ノードがハイリスク オブジェクトの修復を試みるたびに値が増分します。この属性の値が現在のスキャン期間([Scan Period – Estimated]属性で確認可能)よりも長い期間増えないときは、ILMスキャンで修復を必要とするハイリスク オブジェクトがどのノードにも見つからなかったことを意味します。
        注: ハイリスク オブジェクトとは、完全に失われる危険があるオブジェクトです。ILM設定を満たしていないオブジェクトは含まれません。
      • Scan Period – Estimated (XSCM):この属性を使用して、以前に取り込まれたオブジェクトにいつポリシー変更が適用されるかを推定します。[Repairs Attempted]属性の値が現在のスキャン期間よりも長い期間増えない場合は、レプリケート データの修復が完了している可能性があります。スキャン期間は変わる可能性があるので注意してください。[Scan Period – Estimated (XSCM)]属性はすべてのノード スキャン期間の最大値で、グリッド全体に適用されます。グリッドの[Scan Period – Estimated]属性の履歴を照会して、適切な期間を特定することができます。
  6. イレイジャー コーディング データの修復を監視し、失敗した可能性のある要求を再試行します。
    1. イレイジャー コーディング データの修復ステータスを確認します。
      • 次のコマンドは、特定のrepair-data処理のステータスを確認します。
        repair-data show-ec-repair-status --repair-id repair ID
      • すべての修復処理を表示するには、次のコマンドを使用します。
        repair-data show-ec-repair-status
        出力には、以前に実行した修復と現在実行中の修復の情報(repair IDなど)が表示されます。
        root@DC1-ADM1:~ # repair-data show-ec-repair-status                      
        
         Repair ID   Scope                   Start Time  End Time  State  Est Bytes Affected Bytes Repaired  Retry Repair
        ==========================================================================================================
         949283   DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:27:06.9  Success   17359            17359           No
         949292   DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:37:06.9  Failure   17359            0               Yes
         949294   DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:47:06.9  Failure   17359            0               Yes
         949299   DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:57:06.9  Failure   17359            0               Yes
        
        
    2. 失敗した修復処理が出力された場合は、--repair-idオプションを指定して修復を再試行します。
      次のコマンドは、修復ID 83930030303133434を使用して、障害が発生したノードの修復を再試行します。
      repair-data start-ec-node-repair --repair-id 83930030303133434
      次のコマンドは、修復ID 83930030303133434を使用して、障害が発生したボリュームの修復を再試行します。
      repair-data start-ec-volume-repair --repair-id 83930030303133434