システムのリカバリー実行後に検査する内容

システムを使用する前に、いくつかのタスクを実行する必要があります。

リカバリー手順では、古いシステムをクォーラム・データから再作成します。ただし、キャッシュ・データやシステム・データなど、インフライトの入出力を管理する一部のものについては復元できません。後者のデータの状態が失われると、内部ストレージを管理する RAID アレイに影響を及ぼします。同期していないデータの場所を示す詳細マップが失われるということは、すべてのパリティー情報を復元しなければならないことを意味し、ミラーリング済みのペアを同期化するために再び戻す必要があります。通常、このアクションの結果として、古いデータまたは失効したデータのいずれかが使用されることになるため、実行中の書き込みのみが影響を受けます。 ただし、システム・リカバリーが必要なエラーの前にアレイが冗長性を失っていた場合 (同期中、機能低下、または RAID 状況がクリティカルなど)、状態はさらに深刻です。このような状況下では、以下のようにして内部ストレージを検査する必要があります。
  • パリティー・アレイはおそらく回復パリティーとの同期化を行います。この操作が続行された時点で冗長性はありません。
  • この処理には冗長性がないため、データにアクセスできない不良ブロックが作成された可能性があります。
  • パリティー・アレイに「破損」のマークが付けられている場合があります。これは、データ損失のエクステントがインフライトの入出力より広範囲に及ぶことを意味しており、アレイをオンラインにするためには、データ損失を確認する必要があります。
  • システム・リカバリー以前に機能が低下していた RAID6 アレイは、バックアップからの完全復元が必要になる可能性があります。したがって、少なくとも、容量の一致するスペアを使用可能にすることが重要です。
リカバリーされた構成に関して、以下の相違点に注意してください。
  • FlashCopy® マッピングは、0% 進行中の「idle_or_copied」として復元されます。両方のボリュームを元の入出力グループに復元する必要があります。
  • 管理 ID が異なります。システムのシステム管理 ID を参照するスクリプトまたは関連プログラムには変更が必要です。
  • 災害発生時点に 100% 進行中の「idle_or_copied」状態でなかったすべての FlashCopy マッピングでは、ターゲット・ディスク上のデータが不整合です。 これらのマッピングを再開する必要があります。
  • システム間の協力関係と関係は復元されないため、手動での再作成が必要です。
  • 整合性グループは復元されないため、手動での再作成が必要です。
  • システム内のメトロ・ミラー関係は、すべての依存関係が元の入出力グループに正常に復元された場合は復元されます。
  • 復元前にボリュームのクラウド・スナップショットが有効にされていた場合、それらのクラウド・スナップショットを手動で再度有効にする必要があります。
  • リカバリーの前にハードウェアが交換された場合、SSL 証明書が復元されない可能性があります。復元されない場合は、30 日の有効期間で新しい自己署名証明書が生成されます。永続的な解決に関連する指定保守手順 (DMP) に従ってください。
  • システムの時間帯は復元されない場合があります。
  • 災害発生時に 1 次ボリュームからの複製入出力が 2 次システム上のキャッシュに入っていた場合、リカバリーされたシステム上のグローバル・ミラー 2 次ボリュームに不整合データがある可能性があります。これらの関係を再作成および再始動する際に、完全同期が必要です。
  • T3 リカバリー・プロセスの実行直後には、圧縮ディスクはその使用済み容量の正しい値を認識していません。 ディスクは、初期には容量を実容量全体として設定します。入出力が再開されると、容量は正しい値まで縮小されます。

    ボリュームに対して -autoexpand オプションを使用した場合も、同様な動作が発生します。ディスクの実容量は、圧縮ボリュームに影響する同種の動作により、わずかに増える場合もあります。ディスクへの入出力が再開されると、再び容量が縮小します。

  • ホストが装置を再スキャンするようトリガーするには、ホストでの手動操作が必要になる可能性があります。ファイバー・チャネル・ケーブルを各ホスト・バス・アダプター (HBA) ポートから切り離してから再接続することで、このタスクを実行することができます。
  • すべてのマップ済みボリュームにホストからアクセスできることを確認します。
  • アプリケーションの整合性検査を実行します。
仮想ボリューム (VVOL) では、以下のタスクを実行します。
  • T3 が正常に完了したことを確認した後、Spectrum Control Base (SCB) サービスを再開します。Spectrum Control Base コマンド service ibm_spectrum_control start を使用します。
  • SCB GUI でストレージ・システム情報を最新表示して、リカバリーの後でシステムが同期されていることを確認します。
    • このタスクを実行するには、SCB GUI にログインします。
    • 影響を受けたストレージ・システムの上にポインターを移動させて、メニュー・ランチャーを選択し、「最新表示」を選択します。このステップにより、システムに情報が再び取り込まれます。
    • すべての Spectrum Control Base インスタンスに対してこのステップを繰り返します。
  • vSphere Web クライアントの中からストレージ・プロバイダーを再スキャンします。
    • 「vCSA」>「管理」>「ストレージ・プロバイダー (Storage Providers)」>「アクティブな VP の選択 (select Active VP)」>「再スキャン (Re-scan)」アイコンを選択します。

仮想ボリューム (VVOL) では、以下の情報にも留意してください。

VVOL の FlashCopy マッピングは復元されません。 その意味は次のとおりです。
  • VM のスナップショット関係を記述するマッピングは失われています。ただし、これらのスナップショットに関連付けられている仮想ボリュームは引き続き存在しているため、スナップショットが vSphere Web クライアントにまだ表示される可能性があります。この結果により、VMware バックアップ・ソリューションが影響を受ける可能性があります。
    • スナップショットの復帰は試行しないでください。
    • vSphere Web クライアントを使用して、VVOL データ・ストア上の VM のスナップショットをすべて削除し、不必要に使用されているディスク・スペースを解放します。
  • 未処理の「クローン」 FlashCopy 関係のターゲットが予期したように機能しない可能性があります (vSphere Web クライアントが最近、クローン操作が完了したことを報告している場合でも)。最近のクローン操作のターゲットとなったすべての VM について、以下のタスクを実行します。
    • 従来型のボリュームについて推奨されている方法でデータ保全性検査を実行します。
    • クローンが予期したように機能していないか、データ破損の兆候を示している場合は、ソース VM の新規クローンを作成して、データ保全性が維持されるようにします。