リージョン Persistent Disk は、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うストレージ オプションです。Compute Engine に高可用性(HA)サービスを実装するときに、リージョン Persistent Disk を構成要素として使用できます。
このドキュメントでは、リージョン Persistent Disk ボリュームの動作を妨げる可能性のあるさまざまなシナリオと、これらのシナリオを管理する方法について説明します。
準備
- リージョン Persistent Disk のゾーン レプリケーションとフェイルオーバーの基本を確認します。詳細については、 リージョン Persistent Disk についてをご覧ください。
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。
このページのサンプルをどのように使うかに応じて、タブを選択してください。
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- デフォルトのリージョンとゾーンを設定します。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Install the Google Cloud CLI, then initialize it by running the following command:
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 インスタンスに強制的に接続できます。
障害のカテゴリ(および確率) | 障害の種類 | アクション |
---|---|---|
アプリケーション障害(高) |
|
アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。 |
VM 障害(中) |
|
VM は通常、自動修復されます。アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。 |
アプリケーションの破損(低~中) |
アプリケーション データの破損 (アプリケーションのバグや OS のアップグレードの失敗などが原因) |
アプリケーションの復旧:
|
force-attach
を使用してリージョン Persistent Disk をフェイルオーバーする
プライマリ ゾーンで障害が発生した場合、強制アタッチ オペレーションを使用して、リージョン Persistent Disk ボリュームを別のゾーンの VM にフェイルオーバーできます。プライマリ ゾーンで障害が発生すると、VM にアクセスして切断オペレーションを実行できないため、VM からディスクを切断できない場合があります。強制接続オペレーションを使用すると、リージョン Persistent Disk ボリュームが別の VM にアタッチされている場合でも、そのボリュームを VM にアタッチできます。強制アタッチ オペレーションの完了後、Compute Engine は、元の VM がリージョン Persistent Disk ボリュームに書き込めないようにします。強制アタッチ オペレーションを使用すると、データへのアクセスを安全に回復し、サービスを復旧できます。強制アタッチ オペレーションを実行した後に、VM インスタンスを手動でシャットダウンすることもできます。
既存のディスクを VM に強制的にアタッチするには、次の手順を行います。
Console
[VM インスタンス] ページに移動します。
プロジェクトを選択します。
変更する VM の名前をクリックします。
詳細ページで [編集] をクリックします。
[追加ディスク] セクションで、[Attach additional disk] をクリックします。
リージョン Persistent Disk をプルダウン リストから選択します。
ディスクを強制的にアタッチするには、[ディスクを強制接続する] チェックボックスをオンにします。
[完了] をクリックし、[保存] をクリックします。
障害が解決した後は、同じ手順で 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
: プロジェクト IDZONE
: 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
- VM インスタンスに対する
カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。
ディスクデータを移行して復元する手順
レプリカ復元チェックポイントを使用してリージョン Persistent Disk ボリュームのデータを復元して移行するには、次の操作を行います。
レプリカ復元チェックポイントから、影響を受けるリージョン 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.
このスナップショットを使用して、新しいリージョン Persistent Disk ボリュームを作成します。新しいディスクを作成するときに、データを新しいディスクに移動して、最新のレプリカ復元チェックポイントからすべてのデータを復元します。詳しい手順については、リージョン Persistent Disk ブートディスクを使用して新しい VM を作成するをご覧ください。
すべての 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))
次のステップ
- リージョン Persistent Disk ボリュームのレプリカ状態をモニタリングする方法を確認する。
- リージョン Persistent Disk のレプリケーション状態を判断する方法を確認する。
- リージョン Persistent Disk ボリュームのスナップショットを作成する方法を確認する。
- リージョン Persistent Disk を使用して高可用性サービスを構築する方法を確認する。
- Google Cloud でスケーラブルで復元力のあるウェブ アプリケーションを構築する方法を確認する。
- 障害復旧計画ガイドを確認する。