同期レプリケートされたディスクの障害を管理する

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

このドキュメントでは、同期レプリケートされたディスクの動作を妨げる可能性のあるさまざまなシナリオと、これらのシナリオを管理する方法について説明します。

始める前に

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

    Select the tab for how you plan to use the samples on this page:

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

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

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

必要なロール

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

  • レプリカ復元チェックポイントを使用して、レプリケートされたディスクのデータを同期的に移行する: プロジェクトに対する Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）
  • レプリケートされたディスクの指標を表示する（次のいずれか）:

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

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

必要な権限

レプリカ復元チェックポイントを使用して、レプリケートされたディスクデータを同期的に移行するには、次の権限が必要です。

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

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

障害シナリオ

同期的にレプリケートされたディスクでは、デバイスが完全にレプリケートされると、データはリージョン内の 2 つのゾーンに自動的にレプリケートされます。両方のレプリカで書き込み内容が永続化された時点で、書き込みの確認応答がコンピューティング インスタンスに返されます。

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

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

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

ゾーン障害

レプリケートされたディスク（またはリージョン ディスク）は、プライマリ ゾーンとセカンダリ ゾーンのディスク レプリカに同期的にレプリケートされます。ゾーン障害は、ゾーンレプリカが使用できなくなった場合に発生します。ゾーン障害は、次のいずれかの理由で、プライマリ ゾーンまたはセカンダリ ゾーンのいずれかで発生する可能性があります。

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

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

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

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

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

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

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

 プライマリ ゾーン

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

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

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

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

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

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

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

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

 セカンダリ ゾーン

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

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

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

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

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

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

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

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

 プライマリ ゾーン

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

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

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

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

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

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

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

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

 プライマリ ゾーン

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

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

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

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

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

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

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

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

 プライマリ ゾーン

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

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

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

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

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

VM の構成ミス、OS のアップグレードの失敗、その他のアプリケーション エラーで停止した場合、force-attach を実行して、レプリケートされたディスクをレプリカと同じゾーン内のコンピューティング インスタンスに強制的にアタッチできます。

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

force-attach を使用して、レプリケートされたディスクをフェイルオーバーする

プライマリ ゾーンで障害が発生した場合、force-attach オペレーションを使用して、リージョン Persistent Disk または Hyperdisk Balanced High Availability ボリューム（プレビュー）を別のゾーンの Compute Engine インスタンスにフェイルオーバーできます。

プライマリ ゾーンで障害が発生すると、インスタンスにアクセスして切断オペレーションを実行できないため、インスタンスからディスクを切断できない場合があります。force-attach を使用すると、そのボリュームが別のインスタンスにアタッチされている場合でも、リージョン Persistent Disk または Hyperdisk Balanced High Availability ボリュームをコンピューティング インスタンスにアタッチできます。

force-attach オペレーションの完了後、Compute Engine は、元のインスタンスがレプリケートされたディスクに書き込めないようにします。force-attach オペレーションを使用すると、データへのアクセスを安全に回復し、サービスを復旧できます。force-attach オペレーションを実行した後に、VM インスタンスを手動でシャットダウンすることもできます。

既存のディスクをコンピューティング インスタンスに強制的にアタッチするには、次のいずれかのタスクを選択します。

コンソール

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

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

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

  3. 変更するインスタンスの名前をクリックします。

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

  5. [追加ディスク] セクションで、[追加のディスクをアタッチする] をクリックします。

  6. プルダウン リストからリージョン永続ディスクを選択します。

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

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

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

gcloud

レプリカ ディスクをコンピューティング インスタンスにアタッチするには、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: リージョン内の新しいコンピューティング インスタンスの名前
  • DISK_NAME: レプリケートされたディスクの名前

force-attach でディスクを強制的にアタッチしたら、必要に応じてファイル システムをディスクにマウントします。コンピューティング インスタンスは、強制的にアタッチされたディスクを使用して、ディスクに対する読み取り / 書き込みオペレーションを続行できます。

REST

compute.instances.attachDisk メソッドに対する POST リクエストを作成し、作成したレプリケート ディスクへの URL を含めます。ディスクを新しいコンピューティング インスタンスにアタッチするときに、プライマリ コンピューティング インスタンスにディスクがまだアタッチされている場合は、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_NAME: レプリケートされたディスクを追加するコンピューティング インスタンスの名前
  • REGION: レプリケートされたディスクが配置されているリージョン
  • DISK_NAME: レプリケートされたディスクの名前

レプリケートされたディスクをアタッチしたら、必要に応じてファイル システムをディスクにマウントします。コンピューティング インスタンスは、レプリカ ディスクを使用して、ディスクへの読み取り / 書き込みオペレーションを続行できます。

ブートディスクをセカンダリ インスタンスにフェイルオーバーする

コンピューティング インスタンスにアタッチできるブートディスクは 1 つだけです。レプリケートされたブートディスクにフェイルオーバーする場合は、セカンダリ コンピューティング インスタンスがすでに存在するかどうかに応じて、次のいずれかの方法を使用します。

レプリカ復元チェックポイントを使用して、レプリケートされたディスクを復元する

レプリカ復元チェックポイントは、完全にレプリケートされたリージョン Persistent Disk または Hyperdisk Balanced High Availability（プレビュー）ボリュームの最新のクラッシュ整合性ポイントを表します。Compute Engine では、デグレード状態のリージョン ディスクのレプリカ復元チェックポイントから標準スナップショットを作成できます。

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

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

レプリカ復元チェックポイントを使用して、レプリケートされたディスクのデータを復元して移行するには、次の操作を行います。

  1. レプリカ復元チェックポイントから、影響を受けるリージョン Persistent Disk または Hyperdisk Balanced High Availability（プレビュー）ボリュームの標準スナップショットを作成します。

    レプリカ復元チェックポイントからディスクの標準スナップショットを作成するには、gcloud 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 または Hyperdisk Balanced High Availability ディスクを新規に作成します。新しいディスクを作成するときに、スナップショットから新しいディスクにデータを復元して、最新のレプリカ復元チェックポイントからすべてのデータを復元します。詳しい手順については、レプリケートされたブートディスクを使用して新しい VM を作成するをご覧ください。

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

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

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

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

ゾーンレプリカが完全に同期されている

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

ゾーンレプリカが同期されていない

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

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

次のステップ