インフラモダナイゼーション

VMware Site Recovery Manager を使用して Google Cloud VMware Engine のリージョンの障害復旧を設定する方法

2024年3月19日

Google Cloud Japan Team

※この投稿は米国時間 2024 年 3 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

VMware 管理者であれば、ビジネスの継続性を確保し、ダウンタイムを最小化することの重要性を理解しておられるでしょう。Google Cloud VMware Engine（GCVE）のお客様は、RTO と RPO のニーズに基づいて、GCVE Protected、Zerto、Veeam replication、VMware Site Recovery Manager（SRM）、その他のサードパーティツールなどさまざまなツールオプションを選択できます。中でも VMware SRM は、GCVE マルチリージョンデプロイで障害復旧（DR）を可能にするための一般的な方法です。このブログ投稿では、GCVE 内に SRM を設定し、DR を目的として Google Cloud リージョン間で VM のフェイルオーバーとフェイルバックを可能にするためのガイドをご紹介します。

アーキテクチャ

実装に入る前に、GCVE と SRM のアーキテクチャを確認しておきましょう。次の図は、SRM をデプロイして構成された GCVE プライベートクラウドの概要を示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_Design.max-1100x1100.png

このアーキテクチャでは、あるリージョンにプライマリプライベートクラウド（PC）をデプロイし、別のリージョンに DR PC をデプロイして、2 つの PC 間を標準の VMware Engine ネットワークで接続しています。SRM と vSphere Replication のアプライアンスを、NSX-T Tier-1 ルーターのネットワークセグメント内ではなく、PC 内のサービスサブネットにデプロイすることで、ネットワーク速度を向上させています。Cloud DNS は、PC 内にデプロイされている SRM と vSphere Replication のアプライアンスの解決に使用されます。

前提条件

ソリューションをデプロイする前に、いくつか前提条件となる手順が完了していることを確認する必要があります。

Google Cloud 上のプロジェクトで GCVE API が有効になっている
2 つの GCVE PC が異なるリージョンにデプロイされている
VMware Engine ネットワークがデプロイされ、PC に接続されている
SRM と vSphere Replication アプライアンスの OVA をダウンロード済みである
SRM のライセンスがある

SRM の障害復旧を設定する

それでは早速、SRM をデプロイして GCVE のリージョン間サイト復旧を設定してみましょう。

1. サブネット Service-1（または使用するサービスサブネット）のアドレス範囲を割り当てます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_Subnets.max-1700x1700.png

2. vCenter でこのサブネットのポートグループを作成します。これには、ソリューションユーザーアカウントが必要です（ポートグループの作成には、サブネット Service-1 の VLAN ID が必要です）。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_Port_Group.max-1100x1100.png

3. 上述の手順に沿って、DR PC のサービスサブネットを作成します。

4. SRM と vSphere Replication のアプライアンスのレコード参照用に、Cloud DNS 内にプライベート DNS ゾーンを作成します。この DNS ゾーンは、ユーザーが制御する VPC に接続する必要があります（SRM では、両方のサイトの vCenter、SRM、vSphere Replication のアプライアンス間で正引き参照と逆引き参照の両方が必要です）。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_-_PrivateZone.max-1400x1400.png

5. 各ゾーン内のアプライアンスの DNS レコードを作成します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_Fwd_Lookup.max-1300x1300.png

逆引き参照レコード:

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_-_Rvrse_Lookup.max-1300x1300.png

6. プライベートゾーンのバインディングを VMware Engine ネットワークのイントラネット VPC に更新します。これにより、PC 内のアプライアンスの DNS 解決が容易になります。バインディングが作成されたら、各プライベートクラウド内の DNS サーバーアドレスを、SRM と vSphere Replication のアプライアンス内の構成用 DNS アドレスとして利用できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/7_-_PC.max-1800x1800.png

7.CloudOwner ロールと同様の権限を持つユーザーで vCenter にログインし、vSphere Replication アプライアンス OVA をデプロイします。Service-1 サブネットを使用して作成した分散ポートグループをネットワークとして利用してください。DR サイトでこの手順を繰り返します。

8.vSphere Replication アプライアンスのデプロイが成功したら、ログインして構成を行います。デプロイ時にアプライアンスのホスト名に略称を使用した場合は、構成のネットワーク設定をアプライアンスの FQDN で更新してください。また、構成時に vCenter に接続するには、ソリューションユーザーアカウントを使用する必要があります。両サイトでこの構成を行います。

9.構成後、vCenter にログインしてメニューから [Site Recovery Manager] に移動します。両サイトで vSphere Replication のステータスが OK になっていることを確認します。

10.CloudOwner ロールと同様の権限を持つユーザーで vCenter にログインし、SRM アプライアンス OVA をデプロイします。Service-1 サブネットを使用して作成した分散ポートグループをネットワークとして利用してください。DR サイトでこの手順を繰り返します。

11.SRM アプライアンスのデプロイが成功したら、ログインして構成を行います。デプロイ時にアプライアンスのホスト名に略称を使用した場合は、構成のネットワーク設定をアプライアンスの FQDN で更新してください。また、構成時に vCenter に接続するには、ソリューションユーザーアカウントを使用する必要があります。両サイトでこの構成を行います。

12.構成後、vCenter にログインしてメニューから [Site Recovery Manager] に移動します。両サイトで Site Recovery Manager のステータスが OK になっていることを確認します。

ということで、vSphere Replication と SRM のアプライアンスをデプロイし、両方のサイトでそのステータスを確認しました。これで、SRM に移動して 2 つのリージョン間のサイトペアリングを実行し、VM のレプリケーションを構成できるようになりました。

このガイドに沿って進めれば、VMware SRM と Google Cloud VMware Engine の力を組み合わせて、Google Cloud vSphere 環境向けに堅牢で信頼性の高い障害復旧ソリューションを構築できるようになります。障害が発生してからでは手遅れです。今すぐ SRM を使用して Google Cloud VMware Engine に障害復旧を実装することで、リスクを軽減し、重要なワークロードを保護しましょう。

ークラウド コンサルタント Jake Wells

ーソリューション エンジニア Raj Jethnani

投稿先