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

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

始める前に

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

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

  gcloud

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

     gcloud init

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

  REST

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

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

  gcloud init

必要なロール

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

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

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

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

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

障害シナリオ

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

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

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

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

ゾーン障害

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

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

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

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

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

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 インスタンスを手動でシャットダウンすることもできます。

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

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

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"
}

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

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

• アクティブなスタンバイ VM がない場合は、セカンダリ ゾーンに新しいインスタンスを作成します。2 つ目のインスタンスを作成するときに、レプリケートされたブートディスクを使用して新しい VM を作成するで説明されているように、レプリケートされたディスクをブートディスクとして使用します。

• セカンダリ ゾーンにスタンバイ VM がある場合は、レプリケートされたブートディスクを VM にアタッチするの説明に沿って、レプリケートされたブートディスクでスタンバイ VM のブートディスクを置き換えます。

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

レプリカ復元チェックポイントは、完全にレプリケートされたリージョン 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))

次のステップ

• 同期レプリケートされたディスクのレプリカの状態とレプリケーション ステータスをモニタリングする方法を確認する。
• 正確なディスク レプリケーション ステータスを確認する方法を確認する。
• ディスクのスナップショットを作成する方法を学習する。
• 同期レプリケートされたディスクを使用して高可用性サービスを構築する方法を確認する。
• Google Cloud でスケーラブルで復元力のあるウェブ アプリケーションを構築する方法を確認する。
• 障害復旧計画ガイドを確認する。