アプライアンスのストレージボリュームへのオブジェクトデータのリストア

アプライアンスストレージノードのストレージボリュームをリカバリしたら、ストレージノードの障害で失われたオブジェクトデータをリストアします。グリッドのILMルールがオブジェクトコピーを作成するように設定されていた場合、他のストレージノードおよびアーカイブノードからオブジェクトデータをリストアします。

開始する前に

repair-dataコマンドは、プライマリ管理ノードにログインしているときに実行する必要があります。
再フォーマットしたボリュームのボリュームIDを記録しておく必要があります。
リカバリされたストレージノードがグリッドトポロジツリーで緑で表示され、かつすべてのサービスが「Online」と表示されていることを確認しておく必要があります。

タスク概要

障害が発生してリストアされた各ストレージボリュームのボリュームIDが判明している場合は、そのボリュームIDを使用してオブジェクトデータをストレージボリュームにリストアできます。ストレージボリュームのデバイス名がわかっている場合は、デバイス名を使用してボリュームID（ボリュームの/var/local/rangedb番号に対応）を検索できます。

インストール時に、各ストレージデバイスにはファイルシステムのUniversal Unique Identifier（UUID）が割り当てられ、そのUUIDを使用してストレージノードのrangedbディレクトリにマウントされます。ファイルシステムUUIDとrangedbディレクトリは、/etc/fstabファイルに記録されます。デバイス名、rangedbディレクトリ、マウントされているボリュームのサイズは、Grid Managerに表示されます。

これらの値を確認するには、[Support] > [Grid Topology]を選択します。次に、[site] > [failed Storage Node] > [SSM] > [Resources] > [Overview] > [Main]を選択します。

次の例では、ボリュームサイズが4TBのデバイス/dev/sdcが/var/local/rangedb/0にマウントされており、/etc/fstabファイル内のデバイス名/dev/disk/by-uuid/822b0547-3b2b-472e-ad5e-e1cf1809fabaを使用しています。
ボリュームサイズの例

repair-dataスクリプトの使用

オブジェクトデータをリストアするには、repair-dataスクリプトを実行します。このスクリプトは、オブジェクトデータのリストアプロセスを開始し、ILMスキャンと連動してILMルールを適用します。repair-dataスクリプトの各オプションを使用して、オブジェクトレプリケーションで保護されたオブジェクトデータ、およびイレイジャーコーディングで保護されたデータをリストアします。

注:プライマリ管理ノードのコマンドラインで「repair-data --help」と入力すると、repair-dataスクリプトの使用方法の詳細を確認できます。

レプリケートデータ

レプリケートデータをリストアするコマンドは、ノード全体を修復するのか、ノード上の一部のボリュームのみを修復するのかに応じて2つあります。

repair-data start-replicated-node-repair

repair-data start-replicated-volume-repair

Cassandraに不整合が生じている可能性があり、かつ失敗した修復は追跡されませんが、レプリケートデータの修復のステータスはある程度監視できます。[Support] > [Grid Topology]を選択します。次に、[deployment] > [Overview] > [ILM Activity]を選択します。修復を監視し、レプリケートデータの修復が完了したかどうかを可能なかぎり判別するには、次の属性の組み合わせを使用できます。

Repairs Attempted (XRPA)：レプリケートデータの修復の進行状況を追跡します。この属性は、LDRがハイリスクオブジェクトの修復を試みるたびに値が増えます。この属性の値が現在のスキャン期間（[Scan Period – Estimated]属性で確認可能）よりも長い期間増えないときは、修復を必要とするハイリスクオブジェクトがILMスキャンでどのノードにも見つからなかったことを意味します。
注:ハイリスクオブジェクトとは、完全に失われる危険があるオブジェクトです。ILM設定を満たしていないオブジェクトは含まれません。
Scan Period – Estimated (XSCM)：以前に取り込まれたオブジェクトにポリシー変更が適用されるタイミングを推定します。[Repairs Attempted]属性の値が現在のスキャン期間よりも長い期間増えない場合は、レプリケートデータの修復が完了している可能性があります。スキャン期間は変わる可能性があるので注意してください。[Scan Period – Estimated (XSCM)]は、すべてのノードスキャン期間の最大値を示す環境レベルの属性です。[Scan Period – Estimated]属性の履歴を環境レベルで照会して、グリッドの適切な期間を特定することができます。

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

イレイジャーコーディングデータをリストアするコマンドは、ノード全体を修復するのか、ノード上の一部のボリュームのみを修復するのかに応じて2つあります。

repair-data start-ec-node-repair

repair-data start-ec-volume-repair

イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。イレイジャーコーディングデータの修復は、次のコマンドで追跡できます。

repair-data show-ec-repair-status

データリカバリに関する注意事項

オブジェクトデータのコピーがアーカイブノードにしか残っていない場合は、アーカイブノードからオブジェクトデータが読み出されます。外部アーカイブストレージシステムからの読み出しには遅延が伴うため、アーカイブノードからストレージノードへのオブジェクトデータのリストアには、別のストレージノードからコピーをリストアする場合に比べて時間がかかります。

注意:レプリケートされたコピーを1つだけ保存するようにILMルールを設定している場合に、そのコピーがあるストレージノードで障害が発生すると、オブジェクトをリカバリできません。

手順

サービスラップトップから、プライマリ管理ノードにログインします。
1. 次のコマンドを入力します：ssh admin@primary_Admin_Node_IP
2. Passwords.txtファイルに含まれているパスワードを入力します。
3. 次のコマンドを入力してrootに切り替えます：su -
4. Passwords.txtファイルに含まれているパスワードを入力します。
  rootとしてログインすると、プロンプトが$から#に変わります。
/etc/hostsファイルを使用して、リストアされたストレージボリュームのストレージノードのホスト名を探します。グリッド内のすべてのノードのリストを表示するには、次のコマンドを入力します：cat /etc/hosts
すべてのストレージボリュームで障害が発生した場合は、ノード全体を修復する必要があります。一部のボリュームだけで障害が発生した場合は、手順4に進みます。
レプリケートデータとイレイジャーコーディングデータの両方がグリッドにある場合は、次の2つのコマンドを実行します。
注意:複数のノードに対して同時にrepair-data処理を実行することはできません。複数のノードをリカバリする場合は、テクニカルサポートにお問い合わせください。
1. レプリケートデータ：repair-data start-replicated-node-repairコマンドに--nodesオプションを指定して、ストレージノード全体を修復します。
  たとえば、次のコマンドはSG-DC-SN3という名前のストレージノードを修復しています。
```
repair-data start-replicated-node-repair --nodes SG-DC-SN3
```
2. イレイジャーコーディングデータ：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処理の進行状況と結果を追跡します。リカバリプロセスが完了するまでにこの他に返される情報はありません。
  
  注:イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。
オブジェクトデータのリストア時、StorageGRID Webscaleシステムがレプリケートされたオブジェクトデータを見つけられない場合は、LOST（Lost Objects）アラームがトリガーされます。システム全体のストレージノードに対してアラームがトリガーされることがあります。データが見つからない原因と、リカバリが必要かどうかを確認する必要があります。StorageGRID Webscaleのトラブルシューティングの手順を参照してください。
一部のボリュームにのみ障害が発生した場合は、1つまたは一連のボリュームを修復できます。
レプリケートデータとイレイジャーコーディングデータの両方がグリッドにある場合は、次の2つのコマンドを実行します。ボリュームIDを16進形式で入力します。0000は最初のボリューム、000Fは16番目のボリュームです。1つまたは一連のボリュームを指定できます。
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など）をリストアする必要がある場合に使用します。
2. イレイジャーコーディングデータ：start-ec-volume-repairコマンドに--nodesオプションと--volume-rangeオプションを指定します。
  たとえば、次のコマンドは、SG-DC-SN3というストレージノードの000Aという単一のボリュームにデータをリストアします。
```
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処理の進行状況と結果を追跡します。リカバリプロセスが完了するまでにこの他に返される情報はありません。
  注:イレイジャーコーディングデータの修復は、一部のストレージノードがオフライン状態で開始できます。修復はすべてのノードが使用可能になったあとに完了します。
オブジェクトデータのリストア時、StorageGRID Webscaleシステムがレプリケートされたオブジェクトデータを見つけられない場合は、LOST（Lost Objects）アラームがトリガーされます。システム全体のストレージノードに対してアラームがトリガーされることがあります。データが見つからない原因と、リカバリが必要かどうかを確認する必要があります。StorageGRID Webscaleのトラブルシューティングの手順を参照してください。

イレイジャーコーディングデータの修復のステータスを追跡して、修復が正常に完了したことを確認します。次のいずれかの処理を選択します。

次のコマンドは、特定の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

失敗した修復処理が出力された場合は、--repair-idオプションを指定して修復を再試行します。
次のコマンドは、修復ID 83930030303133434を使用して、障害が発生したノードの修復を再試行します。
```
repair-data start-ec-node-repair --repair-id 83930030303133434
```
次のコマンドは、修復ID 83930030303133434を使用して、障害が発生したボリュームの修復を再試行します。
```
repair-data start-ec-volume-repair --repair-id 83930030303133434
```

アプライアンスのストレージ ボリュームへのオブジェクト データのリストア

開始する前に

タスク概要

手順

アプライアンスのストレージボリュームへのオブジェクトデータのリストア