リージョン Persistent Disk の障害を管理する

リージョン Persistent Disk は、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うストレージ オプションです。Compute Engine に高可用性（HA）サービスを実装するときに、リージョン Persistent Disk を構成要素として使用できます。

このドキュメントでは、リージョン Persistent Disk ボリュームの動作を妨げる可能性のあるさまざまなシナリオと、これらのシナリオを管理する方法について説明します。

準備

  • リージョン Persistent Disk のゾーン レプリケーションとフェイルオーバーの基本を確認します。詳細については、 リージョン Persistent Disk についてをご覧ください。
  • まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。

    このページのサンプルをどのように使うかに応じて、タブを選択してください。

    gcloud

    1. Google Cloud CLI をインストールし、次のコマンドを実行して初期化します。

      gcloud init
    2. デフォルトのリージョンとゾーンを設定します。

    REST

    このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

      Google Cloud CLI をインストールし、次のコマンドを実行して初期化します。

      gcloud init

障害シナリオ

リージョン永続ディスクでは、デバイスが完全に複製されると、データはリージョン内の 2 つのゾーンに自動的に複製されます。 両方のレプリカで書き込み内容が永続化された時点で、書き込みの確認応答が仮想マシン（VM）に返されます。

1 つのゾーンへのレプリケーションが失敗した場合、またはレプリケーションが非常に低速な状態がしばらく続くと、ディスクのレプリケーションのステータスは「デグレード」に切り替わります。このモードでは、一方のレプリカで書き込み内容が永続化された時点で、書き込みの確認応答が返されます。

Compute Engine がレプリケーションを再開できることを検出した場合、デバイスがデグレード状態になった後に書き込まれた以前に書き込まれたデータが両方のゾーンに同期され、ディスクが完全に複製された状態に戻ります。この移行は完全に自動化されています。

デバイスがデグレード状態の間は、RPO と RTO は定義されません。デグレード状態で動作しているディスクに障害が発生した場合のデータや可用性の損失を最小限に抑えるため、標準スナップショットを使用してリージョン永続ディスクを定期的にバックアップすることをおすすめします。スナップショットを復元することで、ディスクを回復できます。

ゾーン障害

リージョン Persistent Disk のボリュームは、プライマリ ゾーンとセカンダリ ゾーンのディスク レプリカに同期的に複製されます。ゾーン障害は、ゾーンレプリカが停止して使用不能になった場合に発生します。ゾーン障害は、次のいずれかの理由で、いずれかのゾーンで発生する可能性があります。

  • ゾーンが停止している場合。
  • レプリカで書き込みオペレーションが過度に遅くなっている場合。

次の表に、リージョン Persistent Disk で発生する可能性のあるゾーン障害のシナリオと、各シナリオで推奨される対応を示します。これらの各シナリオでは、初期状態でプライマリ ゾーンレプリカが正常であり、同期されていることを前提としています。

ディスクの初期状態 失敗 ディスクの新しい状態 失敗の影響 必要な対応

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: 同期済み

ディスクのステータス: 完全に複製済み

ディスクのアタッチ先: プライマリ ゾーン

 プライマリ ゾーン

プライマリ レプリカ: 非同期または使用不可

セカンダリ レプリカ: 同期済み

ディスクのステータス: デグレード

ディスクのアタッチ先: プライマリ ゾーン
  • セカンダリ ゾーンのレプリカは正常な状態に保たれ、ディスクデータは最新です。
  • プライマリ ゾーンのレプリカは正常ではなく、すべてのディスクデータが存在する保証はありません。
 正常なセカンダリ ゾーンの VM に強制的にアタッチしてディスクをフェイルオーバーします。

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: 同期済み

ディスクのステータス: 完全に複製済み

ディスクのアタッチ先: プライマリ ゾーン

 セカンダリ ゾーン

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: 非同期または使用不可

ディスクのステータス: デグレード

ディスクのアタッチ先: プライマリ ゾーン
  • プライマリ ゾーンのレプリカは正常な状態に保たれ、ディスクデータは最新です。
  • セカンダリ ゾーンのレプリカは正常ではなく、すべてのディスクデータが存在する保証はありません。
 アクションは不要です。Compute Engine は、セカンダリ ゾーンの異常なレプリカが再び使用可能になったときに同期状態に戻します。

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: 非同期および使用不可

ディスクのステータス: デグレード

ディスクのアタッチ先: プライマリ ゾーン

 プライマリ ゾーン

プライマリ レプリカ: 同期済みだが使用不可

セカンダリ レプリカ: 非同期

ディスクのステータス: 使用不可

ディスクのアタッチ先: プライマリ ゾーン
  • どちらのゾーンレプリカも利用できず、トラフィックを処理できません。ディスクが使用できなくなります。
  • ゾーンの停止やレプリカの障害が一時的であれば、データが失われることはありません。
  • ゾーンの停止またはレプリカの障害が永続的な場合、ディスクのデグレード状態中に正常なレプリカに書き込まれたデータは完全に失われます。
 既存の標準スナップショットを使用して新しいディスクを作成 し、データを復元することをおすすめします。標準スナップショットを使用して、リージョン Persistent Disk のボリュームを定期的にバックアップすることをおすすめします。

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: キャッチアップ中だが使用可能

ディスクのステータス: 最新

ディスクのアタッチ先: プライマリ ゾーン

 プライマリ ゾーン

プライマリ レプリカ: 使用不可

セカンダリ レプリカ: キャッチアップ中だが使用可能

ディスクのステータス: 使用不可

ディスクのアタッチ先: プライマリ ゾーン
  • どちらのゾーンレプリカもトラフィックを処理できません。ディスクが使用できなくなります。
  • ゾーンの停止やレプリカの障害が一時的な場合は、プライマリ レプリカが再び使用可能になった後にディスクがオペレーションを再開します。
  • ゾーンの停止やレプリカの障害が永続的な場合、ディスクは使用できなくなります。

プライマリ レプリカ: 同期済み

セカンダリ レプリカ: 非同期だが使用可能

ディスクのステータス: デグレード

ディスクのアタッチ先: プライマリ ゾーン

 プライマリ ゾーン

プライマリ レプリカ: 使用不可

セカンダリ レプリカ: 非同期だが使用可能

ディスクのステータス: 使用不可

ディスクのアタッチ先: プライマリ ゾーン
  • どちらのゾーンレプリカもトラフィックを処理できません。ディスクが使用できなくなります。
  • ゾーンの停止またはレプリカの障害が一時的な場合は、プライマリ レプリカが再び使用可能になった後にディスクがオペレーションを再開します。
  • ゾーンの停止やレプリカの障害が永続的な場合、ディスクは使用できなくなります。

アプリケーションと VM の障害

VM の構成ミス、OS のアップグレードの失敗、その他のアプリケーション エラーで停止した場合、force-attach を実行して、リージョン Persistent Disk のボリュームを同じゾーン内の VM インスタンスに強制的に接続できます。

障害のカテゴリ（および確率） 障害の種類 アクション
アプリケーション障害（高）
  • 応答しないアプリケーション
  • アプリケーション管理アクション（アップグレードなど）による障害
  • ヒューマン エラー（SSL 証明書や ACL などのパラメータの構成ミスなど）
 アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。
VM 障害（中）
  • インフラストラクチャまたはハードウェアの障害
  • CPU の競合のため VM が応答しない、中間ネットワークの中断
 VM は通常、自動修復されます。アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。
アプリケーションの破損（低～中） アプリケーション データの破損
（アプリケーションのバグや OS のアップグレードの失敗などが原因）		 アプリケーションの復旧:

force-attach を使用してリージョン Persistent Disk をフェイルオーバーする

プライマリ ゾーンで障害が発生した場合、強制アタッチ オペレーションを使用して、リージョン Persistent Disk ボリュームを別のゾーンの VM にフェイルオーバーできます。プライマリ ゾーンで障害が発生すると、VM にアクセスして切断オペレーションを実行できないため、VM からディスクを切断できない場合があります。強制接続オペレーションを使用すると、リージョン Persistent Disk ボリュームが別の VM にアタッチされている場合でも、そのボリュームを VM にアタッチできます。強制アタッチ オペレーションの完了後、Compute Engine は、元の VM がリージョン Persistent Disk ボリュームに書き込めないようにします。強制アタッチ オペレーションを使用すると、データへのアクセスを安全に回復し、サービスを復旧できます。強制アタッチ オペレーションを実行した後に、VM インスタンスを手動でシャットダウンすることもできます。

既存のディスクを VM に強制的にアタッチするには、次の手順を行います。

Console

  1. [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. プロジェクトを選択します。

  3. 変更する VM の名前をクリックします。

  4. 詳細ページで [編集] をクリックします。

  5. [追加ディスク] セクションで、[Attach additional disk] をクリックします。

  6. リージョン Persistent Disk をプルダウン リストから選択します。

  7. ディスクを強制的にアタッチするには、[ディスクを強制接続する] チェックボックスをオンにします。

  8. [完了] をクリックし、[保存] をクリックします。

障害が解決した後は、同じ手順で force-attach を実行し、ディスクを元の VM に強制的にアタッチできます。

gcloud

レプリカ ディスクを VM インスタンスにアタッチするには、gcloud CLI で instances attach-disk コマンドを使用します。--disk-scope フラグを追加して、その値を regional に設定します。

gcloud compute instances attach-disk VM_NAME \
    --disk DISK_NAME --disk-scope regional \
    --force-attach

次のように置き換えます。

  • VM_NAME: リージョン内の新しい VM インスタンスの名前
  • DISK_NAME: ディスクの名前

force-attach でディスクを強制接続したら、必要に応じてファイル システムをディスクにマウントします。VM インスタンスは、強制接続されたディスクを使用して読み取りおよび書き込みオペレーションを続行できます。

REST

compute.instances.attachDisk メソッドに対する POST リクエストを作成し、作成した Persistent Disk ボリュームへの URL を指定します。ディスクを新しい VM インスタンスに接続するには、プライマリ VM インスタンスにディスクが接続している場合でも forceAttach=true クエリ パラメータが必要です。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/attachDisk?forceAttach=true

{
 "source": "projects/PROJECT_ID/regions/REGION/disks/DISK_NAME"
}

次のように置き換えます。

  • PROJECT_ID: プロジェクト ID
  • ZONE: VM インスタンスのロケーション
  • VM_NAME: 新しい Persistent Disk ボリュームを追加する VM インスタンスの名前
  • REGION: 新しいリージョン Persistent Disk ボリュームを配置するリージョン
  • DISK_NAME: 新しいディスクの名前

レプリカ ディスクを接続したら、必要に応じてファイル システムをディスクにマウントします。VM インスタンスは、レプリカ ディスクを使用して読み取りおよび書き込みオペレーションを続行できます。

レプリカ復元チェックポイントを使用して、劣化したリージョン Persistent Disk ボリュームを復元する

レプリカ復元チェックポイントは、完全に複製されたリージョン Persistent Disk ボリュームの、最新のクラッシュ整合性ポイントを表します。Compute Engine では、劣化したディスクのレプリカ復元チェックポイントから標準スナップショットを作成できます。

まれに、ディスクのパフォーマンスが低下し、最新のディスクデータと同期されたゾーンレプリカが、非同期レプリカにキャッチアップする前に障害が発生することがあります。その場合、どちらのゾーンの VM にもディスクを強制的にアタッチすることはできません。リージョン Persistent Disk ボリュームは使用できなくなり、データを新しいディスクに移行する必要があります。このようなシナリオでは、ディスクに使用できる既存の標準スナップショットがない場合でも、レプリカ復元チェックポイントから作成された標準スナップショットを使用して、不完全なレプリカからディスクデータを復元できる可能性があります。詳細な手順については、ディスクデータを移行して復元する手順をご覧ください。

必要なロール

レプリカ復元チェックポイントを使用してリージョン Persistent Disk データを移行するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

  • レプリカ復元チェックポイントを使用してリージョン Persistent Disk データを移行する: プロジェクトに対する Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）

ロールの付与の詳細については、アクセス権の管理をご覧ください。

これらの事前定義ロールには、レプリカ復元チェックポイントを使用してリージョン Persistent Disk データを移行するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

レプリカ復元チェックポイントを使用してリージョン Persistent Disk データを移行するには、次の権限が必要です。

  • レプリカ復元チェックポイントから標準スナップショットを作成する:
    • プロジェクトに対する compute.snapshots.create
    • ディスクに対する compute.disks.createSnapshot
  • 標準スナップショットから新しいリージョン Persistent Disk を作成する: 新しいディスクを作成するプロジェクトに対する compute.disks.create
  • VM を新しいディスクに移行する:
    • VM インスタンスに対する compute.instances.attachDisk
    • 新しく作成されたディスクに対する compute.disks.use permission

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

ディスクデータを移行して復元する手順

レプリカ復元チェックポイントを使用してリージョン Persistent Disk ボリュームのデータを復元して移行するには、次の操作を行います。

  1. レプリカ復元チェックポイントから、影響を受けるリージョン Persistent Disk ボリュームの標準スナップショットを作成します。レプリカ復元チェックポイントからディスクの標準スナップショットを作成するには、Google Cloud CLI または REST を使用する必要があります。

    gcloud

    レプリカ復元チェックポイントを使用してスナップショットを作成するには、gcloud compute snapshots create コマンドを使用します。レプリカ復元チェックポイントを使用してスナップショットを作成することを指定するには、--source-disk-for-recovery-checkpoint フラグを含めます。--source-disk パラメータと --source-disk-region パラメータを除外します。

    gcloud compute snapshots create SNAPSHOT_NAME \
    --source-disk-for-recovery-checkpoint=SOURCE_DISK \
    --source-disk-for-recovery-checkpoint-region=SOURCE_REGION \
    --storage-location=STORAGE_LOCATION \
    --snapshot-type=SNAPSHOT_TYPE

    以下を置き換えます。

    • DESTINATION_PROJECT_ID: スナップショットを作成するプロジェクトの ID。
    • SNAPSHOT_NAME: スナップショットの名前。
    • SOURCE_DISK: スナップショットの作成に使用するソースディスクの名前またはフルパス。ソースディスクのフルパスを指定するには、次の構文を使用します。: 
        projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME

      ソースディスクのフルパスを指定する場合は、--source-disk-for-recovery-checkpoint-region フラグを除外できます。ディスク名のみを指定する場合は、このフラグを含める必要があります。

      別のプロジェクトのソースディスクの復元 チェックポイントからスナップショットを作成するには、ソースディスクのフルパスを指定する必要があります。

    • SOURCE_PROJECT_ID: スナップショットの作成に使用するチェックポイントがあるソースディスクのプロジェクト ID。
    • SOURCE_REGION: スナップショットの作成に使用するチェックポイントがあるソースディスクのリージョン。
    • SOURCE_DISK_NAME: スナップショットの作成に使用するチェックポイントがあるソースディスクの名前。
    • STORAGE_LOCATION: スナップショットを保存する Cloud Storage マルチリージョンまたは Cloud Storage リージョン（オプション）。保存場所は 1 つだけ指定できます。
      --storage-location フラグは、スナップショット設定で構成した事前定義またはカスタマイズされたデフォルトの保存場所をオーバーライドする場合にのみ使用します。
    • SNAPSHOT_TYPE: スナップショットの種類（標準 または アーカイブ）。スナップショットの種類が指定されていない場合は、標準 スナップショットが作成されます。

    レプリカ復元チェックポイントを使用して、劣化したディスクにのみスナップショットを作成できます。デバイスが完全にレプリケートされているときにレプリカ復元チェックポイントからスナップショットを作成しようとすると、次のエラー メッセージが表示されます。

    The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
create regular snapshots instead.

    REST

    レプリカ復元チェックポイントを使用してスナップショットを作成するには、 snapshots.insert メソッドに POST リクエストを送信します。チェックポイントを使用してスナップショットを作成することを指定するには、sourceDisk パラメータを除外し、代わりに sourceDiskForRecoveryCheckpoint パラメータを含めます。

    POST https://compute.googleapis.com/compute/v1/projects/DESTINATION_PROJECT_ID/global/snapshots

{
  "name": "SNAPSHOT_NAME",
  "sourceDiskForRecoveryCheckpoint": "projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME",
  "storageLocations": "STORAGE_LOCATION",
  "snapshotType": "SNAPSHOT_TYPE"
}

    以下を置き換えます。

    • DESTINATION_PROJECT_ID: スナップショットを作成するプロジェクトの ID。
    • SNAPSHOT_NAME: スナップショットの名前。
    • SOURCE_DISK: スナップショットの作成に使用するソースディスクの名前またはフルパス。ソースディスクのフルパスを指定するには、次の構文を使用します。: 
        projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME

      ソースディスクのフルパスを指定する場合は、--source-disk-for-recovery-checkpoint-region フラグを除外できます。ディスク名のみを指定する場合は、このフラグを含める必要があります。

      別のプロジェクトのソースディスクの復元 チェックポイントからスナップショットを作成するには、ソースディスクのフルパスを指定する必要があります。

    • SOURCE_PROJECT_ID: スナップショットの作成に使用するチェックポイントがあるソースディスクのプロジェクト ID。
    • SOURCE_REGION: スナップショットの作成に使用するチェックポイントがあるソースディスクのリージョン。
    • SOURCE_DISK_NAME: スナップショットの作成に使用するチェックポイントがあるソースディスクの名前。
    • STORAGE_LOCATION: スナップショットを保存する Cloud Storage マルチリージョンまたは Cloud Storage リージョン（オプション）。保存場所は 1 つだけ指定できます。
      storageLocations パラメータは、スナップショット設定で構成した事前定義またはカスタマイズされたデフォルトの保存場所をオーバーライドする場合にのみ使用します。
    • SNAPSHOT_TYPE: スナップショットの種類（標準 または アーカイブ）。スナップショットの種類が指定されていない場合は、標準 スナップショットが作成されます。

    レプリカ復元チェックポイントを使用して、劣化したディスクにのみスナップショットを作成できます。デバイスが完全にレプリケートされているときにレプリカ復元チェックポイントからスナップショットを作成しようとすると、次のエラー メッセージが表示されます。

    The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
create regular snapshots instead.

  2. このスナップショットを使用して、新しいリージョン Persistent Disk ボリュームを作成します。新しいディスクを作成するときに、データを新しいディスクに移動して、最新のレプリカ復元チェックポイントからすべてのデータを復元します。詳しい手順については、リージョン Persistent Disk ブートディスクを使用して新しい VM を作成するをご覧ください。

  3. すべての VM ワークロードを新しく作成されたディスクに移行し、これらの VM ワークロードが正しく実行されていることを確認します。詳細については、ゾーンまたはリージョン間で VM を移動するをご覧ください。

ディスクデータと VM を復元して、新しく作成したリージョン Persistent Disk ボリュームに移行したら、オペレーションを再開できます。

レプリカ復元チェックポイントによって提供される RPO を確認する

このセクションでは、リージョン Persistent Disk ボリュームの最新のレプリカ復元チェックポイントによって提供される RPO を確認する方法について説明します。

ゾーンレプリカは完全に同期されています

Compute Engine は、リージョン Persistent Disk ボリュームのレプリカ復元チェックポイントを約 10 分ごとに更新します。したがって、ゾーンレプリカが完全に同期された場合、RPO は約 10 分です。

ゾーンレプリカは同期されていません

レプリカ復元チェックポイントの作成および更新の正確なタイムスタンプを確認することはできません。ただし、次のデータを使用して、最新のチェックポイントが提供するおおよその RPO を見積もることができます。

  • 完全に複製されたディスク状態の最新のタイムスタンプ: この情報を取得するには、replica_state 指標にリージョン Persistent Disk の Cloud Monitoring データを使用します。非同期レプリカの replica_state 指標データを確認して、レプリカが同期しなくなった時間を特定します。Compute Engine は 10 分ごとにディスクのチェックポイントを更新するため、最新のチェックポイント更新は、このタイムスタンプの約 10 分前であった可能性があります。
  • 最新の書き込みオペレーションのタイムスタンプ: この情報を取得するには、write_ops_count 指標に Persistent Disk の Cloud Monitoring データを使用します。write_ops_count 指標データを確認して、ディスクの最新の書き込みオペレーションを確認します。

これらのタイムスタンプの決定後、次の式を使用して、ディスクのレプリカ復元チェックポイントによって提供されるおおよその RPO を計算します。計算された値がゼロ未満の場合、RPO は実質的にゼロになります。

Approximate RPO provided by the latest checkpoint = (Most recent write operation timestamp - (Most recent timestamp of the fully replicated disk state - 10 minutes))

次のステップ