Actifio、VMware Engine、Zerto を使用した Google Cloud の障害復旧
Google Cloud Japan Team
※この投稿は米国時間 2021 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウドに移行することが特に望ましいアプリケーションとしては、VMware のようなエンタープライズのストレージ アレイに接続している専用プラットフォームで動作するアプリケーションがあります。しかし、このようなアプリケーションは多くの場合ミッション クリティカルで、移行には大きな困難が伴います。特に障害の目標復旧時間（RTO）と目標復旧時点（RPO）が厳しい場合や、隔離された「バブル」ネットワークを使用して構成されている場合には難易度が高くなります。
Google は、お客様のクラウド プロジェクトに適した DR ソリューションをすばやく見つけられるようサポートしたいと考えています。このブログ投稿では、クラウドでの DR の基本コンセプトについて説明します。その後、例として、架空のお客様である Acme 社のユースケースを示します。Acme 社はバブル ネットワークを使用していて、RPO が 2 時間、RTO が 4 時間と非常に短時間です。ユースケースを提示した後で、この要件を満たすいくつかの一般的な DR ソリューションを評価し、それらのソリューションを Google Cloud にデプロイする方法を紹介します。
Acme 社について
Acme 社は従来型のエンタープライズです。すべてのアプリケーションを 2 つのオンプレミス データセンターで、VMware とメインフレーム インフラストラクチャを使用して実行しています。データセンターは、一方がプライマリで、もう一方がリモート DR 用です。Acme 社は、Google Cloud に移行してインフラストラクチャをモダナイズし、コストを削減しようと考えています。そのために、厳しい RPO/RTO 要件を満たす Google Cloud 環境用の強固な障害復旧ソリューションを必要としています。
この要件とは別に、設計をさらに難しくしている問題があります。Acme 社は、DR を実現するためにバブルを使用しているのです。これは、プライマリ サイトの VM と DR サイトの VM が同じプライベート IP のセットを持つ、一種の隔離ネットワークです。このバブル ネットワークの要件があるために、クラウドでの障害復旧アーキテクチャの構築がいっそう困難になっています。
次の図は、Acme 社にあるさまざまなシステム、アプリケーション、データのスタックと、現在のオンプレミス データセンター環境でバックアップと障害復旧を行っている方法を示しています。
この図から、Acme 社の設定の詳細がわかります。
現在の DR 戦略では、Acme 社はオンプレミス データセンターのすべてのデータとリソースをブロックレベルで複製しています。全体の RPO は 2 時間、RTO は 4 時間です。
Acme 社には、合計で 500 台の Windows VM と 3,000 台のサーバーがあります。
Avamar で VM、OS、永続ディスク、データベースのバックアップを毎日行っています。データは DR データセンターに複製されます。これらのバックアップは、DR には使用しません。
IBM Global Mirror が、IBM メインフレーム スタックの DR 用にブロックレベルのデータ複製を行います。対象には、メインフレームの中間ティア、DB2 データベース（構成テーブル）、z/VM DB2 データベース（コアサーバー）が含まれます。
Isilon（PowerScale）SyncIQ が、Acme 社の Isilon ファイルデータの DR 用にデータ複製を行います。
EMC RecoverPoint が、VMware スタックの DR 用にデータ複製を行います。対象には、VMware VM ベースのアプリケーション、SQL Server、MySQL データベースが含まれます。
Google Cloud に移行することで、Acme 社のシステムとアプリケーションに次の変化が生じます。
IBM DB2 と z/VM DB2 の両方が Compute Engine ベースの LUW（Linux/Unix/Windows）DB2 に移行されます
IBM Global Mirror は、Google Cloud 環境では適用できません
EMC RecoverPoint は、GCP 環境では使用できません
Isilon（現在の呼び名は PowerScale）は、Google Cloud 環境では SaaS ソリューションとして使用できます
また、Acme 社は Google Cloud に移行するときに、ウェブサービスのオーケストレーションのために Apigee を採用しました。この環境も保護する必要があります。
まとめると、Google Cloud で稼働する Acme 社のシステム用にどのような DR ソリューションを設計するか決定するうえで、大きな要件が 3 つあります。
本番環境システムの RPO 要件は 2 時間
現在のバブル ネットワークの設計と実装をサポートしており、主要なシステムとアプリケーションの作り直しを避けられる
1 台につき最大 24 台のディスクがマウントされている膨大な数の VM に対して行うディスクの再マウントをオーケストレーションできること
Apigee スタック用のソリューション
Google チームはこのような DR アーキテクチャを実際にお客様のために実装したことがあるため、その経験に基づいて、Acme 社の DR ソリューションとして以下の例を作成しました。GCP 上にある Acme 社のシステムとアプリケーションを次のスタックに分割します。
Apigee。Google が提供するマネージド サービス。
PowerScale（Isilon）。サードパーティのマネージド サービスとして GCP で実行。
最大 RPO が 2 時間の、VM で実行されるデータベースとアプリケーション。
2 時間の RPO を満たす必要がないデータを含む VM で実行される本番環境アプリケーション。
利用可能なソリューションの検討
これらの要件を念頭に置いて、次のアプローチを検討しました。
ネイティブのリージョン DR とスナップショット
アーキテクチャ設計による GCP ネイティブのリージョン DR は、HA と DR の要件に従って設計されたクラウドネイティブなシステムに適しています。しかし、Acme 社でこのソリューションを使用するには、アプリケーションのアーキテクチャを大きく変更する必要があります。また、このソリューションは、バブル ネットワークの制約下では動作しません。プライマリ リージョンと DR リージョンの間で発生する VM レベルのリアルタイム トラフィックが、IP の競合により妨げられるからです。
さらに、このアーキテクチャを利用するには、各ディスクで増分スナップショットを取得する必要があります。Acme 社にとって、この方法は現実的ではありません。3,000 台のサーバーがあるため、すべてのディスクをスナップショットから復元し、復元した VM に正しい順序でマウントするには大きな手間がかかります。障害復旧の状況下でこのプロセスを自動化するマルチスレッド オーケストレーション ツールがなければ、管理はほぼ不可能です。そのため、この方法は採用しないこととしました。
Actifio
もう一つの見込みのあるソリューションが、Google Cloud で利用できるバックアップと DR サービスのプラットフォーム、Actifio GO です。バックアップ、障害復旧、Google Cloud への移行、テストデータ管理（TDM）用のデータベースと VM のクローン作成、ランサムウェアからの復旧のほか、BigQuery による分析も可能です。Actifio GO のサービス アーキテクチャは複数のコンポーネントで構成されていて、これらが協調して動作し、サービスを提供します。また、バブル ネットワークの要件もサポートします。
次の図は、Acme 社向けの Actifio DR ソリューションの設計を示しています。
Acme 社のバブル ネットワークをサポートし、DR リージョンで同じ IP アドレスを維持するには、Acme 社の VPC およびネットワーク設定と同じセットを Acme 社の Google Cloud DR リージョンに作成する必要があります。そのため、DR リージョンの「acme-transit-DR-vpc」に、Google Cloud プライマリ リージョンの「acme-transit-vpc」をミラーリングさせます。これは、Actifio が Google Cloud Storage を使用しているために実現できました。詳しくは後ほど説明します。
Actifio Global Manager（AGM）は、Google のネットワークでホストされています。AGM は、Actifio Sky を Acme 社のネットワークにデプロイしてバックアップと復元のエージェントとして動作できるように、Acme 社の VPC と VPC ピアリングを確立する必要があります。AGM は 2 つの VPC と IP 範囲でピアリングするため、このバブル ネットワークで Actifio Sky を「acme-transit-vpc」と「acme-transit-DR-vpc」の両方にデプロイすることはできません。そのため、リージョンごとに別の VPC、「sky-vpc-east」と「sky-vpc-central」を作成し、Actifio Sky を実行します。
この構成では、VPC ピアリングは非推移的（順次接続される VPC が 2 つまで）なので、AGM VPC は DR およびプライマリ VPC CIDR 範囲を持つ個々の SKY VPC のピアリング詳細を参照しません。そのため、「sky-vpc-east」と「sky-vpc-central」の CIDR 範囲は慎重に選択しなければなりません。これらは AGM VPC、「acme-transit-vpc」、「acme-transit-DR-vpc」とそれぞれピアリングする必要があるからです。
Actifio GO は、Cloud Storage を使用してバックアップ ファイルを保存します。ローカル リージョンのバックアップのみを行う場合は、同じリージョンで単一リージョンの Cloud Storage を使用できます。障害復旧の場合は、Cloud Storage バケットを DR リージョンで使用すると、パフォーマンスが向上します。Actifio では、マルチリージョン Cloud Storage バケットを使用して可用性を高めることもできます。ここでは、Cloud Storage を主に障害復旧に使用するため、Nearline または Coldline のストレージ クラスを使用することをおすすめします。
要求される RPO / RTO を Actifio で満たせない汎用 VM については、Acme 社のオンプレミス VM を Google Cloud VMware Engine に移行できます。詳しくは次のセクションで説明します。
Google Cloud VMware Engine と Zerto
Google Cloud VMware Engine は、Google Cloud のロケーションで VMware プラットフォームを Google Cloud ベアメタル インフラストラクチャ上でネイティブに実行するフルマネージド サービスです。Google Cloud のその他の機能と完全に統合します。Acme 社の、最も要求が厳しいアプリケーションに課される厳格な RTO / RPO 要件を満たすために、Zerto を組み合わせることを考えました。これは、データ損失とダウンタイムを実質的に排除して継続的な可用性を確保するスケーラブルなレプリケーション プラットフォームです。
Google Cloud VMware Engine は、メインフレーム アプリケーションにも使用できます。必要に応じて、これらのアプリケーション用に、移行した OpenFrame インスタンスを Google Cloud VMware Engine の VMware VM で実行することもできます。次に、Zerto による複製と復元で VM をミラーリングする 2 つの Google VMware プライベート クラウドを使用して、クロスリージョン DR を実現します。正しく設計すれば、このソリューションの RPO / RTO は非常に小さくなり（RPO < 30 分）、Acme 社の RPO / RTO（2 時間 / 4 時間）要件を簡単に満たすことができます。
次の 2 つの図（複製と復元）は、Acme 社の Google Cloud VMware Engine と Zerto を組み合わせた障害復旧ソリューションを示しています。
図 4: 同一 IP を持つネットワークでの Google Cloud VMware Engine + Zerto のデータ復元
ネットワーク構成は、主に Google Cloud VMware Engine のレベルで行います。Google Cloud VMware Engine は、プライベート サービス アクセス接続を使用して Acme 社の VPC とピアリングし、この VPC を Acme 社のネットワークで使用します。
Acme 社では、DR リージョンに同一 IP を持つバブル ネットワークを使用しているため、プライマリ リージョンで「acme-transit-vpc」を構成し、DR リージョンで「acme-transit-DR-vpc」を構成します。また、両方の Google Cloud VMware Engine VPC に、同じ CIDR を持つ「ワークロード サブネット」を作成します。
通常は、両方の Google Cloud VMware Engine VPC が「acme-transit-vpc」VPC とピアリングされます。また、GCVE-central（DR リージョン）の「ワークロード サブネット」へのルートはオフになっているため、IP の競合は発生しません。ピアリングされたネットワーク接続を通じて「acme-transit-vpc」経由で GCVE-primary のデータを GCVE-dr に複製するように、Zerto を構成します。
Google Cloud プライマリ リージョンで災害が発生した場合、GCVE-dr と「acme-transit-vpc」の間のピアリング接続を手動で解除します。次に、GCVE-dr が「acme-transit-DR-vpc」とピアリングされます。また、GCVE-dr リージョンの「ワークロード サブネット」へのルートがオンになります。さらに、複製されている VM、データ、アプリケーションを Zerto が「ワークロード サブネット」に復元します。
Google Cloud VMware Engine VPC をセットアップする方法と、既存の Google Cloud VPC とのネットワーク接続を構成する方法については、プライベート サービス アクセスの設定をご覧ください。
PowerScale（Isilon）
Acme 社の PowerScale（Isilon）アレイを保護するために、Dell EMC Powerscale SyncIQ を使用して、マルチ NIC VM を通じて PowerScale ノード間でデータを複製します。マルチ NIC VM はプライマリ リージョン内にあり、DR リージョンのバブル ネットワークへのセカンダリ ネットワーク インターフェース（NIC）を持ちます。これにより、リージョンをまたぐデータの複製ができます。
Apigee
最後になりますが、重要なこととして、Acme 社が Google Cloud にデプロイしたマイクロサービスに使用している Apigee 環境を保護する必要があります。Apigee は、データセンターをグローバル レベルで冗長化します。トラフィックは複数のリージョンまたは国で処理されるため、リージョン全体がオフラインになっても、データの流れは止まりません。下の図に示すように、マルチリージョン Apigee ライセンスがあれば、ネットワーク トラフィックは自動的に障害復旧リージョンにルーティングされます。
まとめ
複雑なセットアップでしたが、要件の厳しいさまざまなアプリケーションをクラウドに移行しようとするエンタープライズにとっては、珍しい事例ではありません。次の図に、最終的な Acme 社の障害復旧アーキテクチャを示します。現在のオンプレミス DR アーキテクチャが左側で、Google Cloud DR アーキテクチャが右側です。
Google Cloud 用に DR 環境を構成する方法について詳しくは、Actifio GO ドキュメント ライブラリと Zerto を使用した障害復旧の構成をご覧ください。または、Google までお問い合わせください。お客様独自のユースケースの確立をサポートさせていただきます。
このブログ投稿の執筆にあたり、元同僚の Jianhe Liao の協力に感謝します。
-パートナー デリバリー マネージャー Rajesh Nanda
-戦略的クラウド エンジニア Waheed Brown
