コンテンツに移動
データベース

Google Cloud VMware Engine(GCVE)へのデータベースの移行

2022年6月2日
Google Cloud Japan Team

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

以下のブログ投稿では、オンプレミス(物理サーバーまたは VMware)から Google Cloud VMware Engine(GCVE)へのデータベースの移行に使用される一般的なプロセスとツールについて説明しています。お客様の多くは、データベースのアップグレードやモダナイゼーションに向けたワークストリームを開始する前に、データベースを Google Cloud に迅速に移行する最初のステップとして、このリフト&シフト移行のアプローチを選択しています。

Google Cloud VMware Engine

GCVE は、Google Cloud で VMware プラットフォームを運用できるフルマネージド サービスです。このソリューションには、vSphere、vCenter、vSAN、NSX-T と対応するツールが含まれます。GCVE VMware 環境は、Google Cloud のロケーションにある Google Cloud ベアメタル インフラストラクチャ上でネイティブに稼働し、GCVE サービスには、VMware プラットフォームを効率的かつ安全に利用するために必要なすべての機能が含まれます。各クラスタは最低 3 つのノードで構成され、vSphere High Availability による高可用性を備えています。vSphere HA の詳細については vSphere HA の動作をご確認ください。

重要: 

  • 1 つの GCVE プライベート クラウド = 1 つの vCenter + 1 つの NSX-T Manager + 1 つの HCX Manager

  • GCVE では、vSphere または HCX 管理ネットワークの CIDR 範囲は重複できません。

  • 1 つのクラスタには、少なくとも 3 つのノードが必要です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_GCVE.max-2000x2000.jpg

オンプレミス VMware の Google Cloud VMware Engine への接続

GCVE への接続の詳細については、Google Cloud VMware Engine のプライベート クラウド ネットワーキングのホワイトペーパーをご覧ください。

データベースの移行ツール

GCVE にサーバーを移行するためのツールは数多く存在しますが、一般的な選択肢として以下の 3 つが挙げられます。

VMware HCX

VMware HCX は、VM をオンプレミスの VMware 環境から Google Cloud VMware Engine に移行するために使用されます。GCVE では、オンプレミスとプライベート クラウドの両方で、HCX コネクタ OVA をダウンロード、インストール、デプロイ、構成する必要があります。オンプレミスの vCenter と HCX コネクタ アプライアンスには 1 対 1 の対応関係があります。たとえば、VMware がインストールされているデータセンターが 10 ある場合、それぞれの vCenter にコネクタをインストールする必要があります。

VMware HCX を使用して、VM をオンプレミス環境からプライベート クラウドに移行する方法については、VMware HCX を使用した VMware VM の移行をご覧ください。

PlateSpin Migrate

PlateSpin Migrate はデータセンターの移行ツールで、ワークロードのインフラストラクチャとソフトウェア(オペレーティング システム、アプリケーション、データ)を切り離し、物理サーバーを VMware ハイパーバイザなどのターゲット サーバーのプラットフォームに移行します。一般的なユースケースでは、GCVE に移行する場合は 2 段階の移行が行われます。まずオンプレミスの P2V から始め、次に HCX を使用して V2V から GCVE に移行します。サポートされるワークロードの詳細については、Platespin のドキュメントをご覧ください。

Windows クラスタの移行に関する注意点: SQL Server フェイルオーバー クラスタ(FCI)などの Windows クラスタの移行は、ネットワーク接続、必要な IP の変更、共有ストレージ コンポーネントが原因で複雑になる場合があります。 多くの場合、クラスタを移行するよりも、GCVE でターゲット VM を構築し、データを移行する方が合理的です。

データベース プラットフォームの再構築

物理サーバーや仮想サーバーは、複雑さや移行ツールの互換性要件のために、オンプレミスから GCVE へ移行できないケースがあります。このようなケースでは、OS、データベース、モニタリング ソフトウェア、Actifio データベース コネクタなどのオペレーション ソフトウェアなど、必要なソフトウェア構成やツールを含む VM テンプレートが GCVE 内に作成されます。その後 VM は、データベース ワークロードの移行ターゲットとして、作成されたテンプレートからプロビジョニングされます。このようなターゲットへの移行に使用される戦略は、プラットフォームと移行期間に大きく依存します。

一般的なデータベース プラットフォーム移行戦略を、データベース プラットフォーム別に以下に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_GCVE.max-800x800.jpg

Oracle 8i や Oracle 9i などの従来のデータベース プラットフォームの場合、Stromasys Charon エミュレータを使用することで、従来型データベースを GCVE で運用できる場合があります。


データベースの GCVE への移行が完了すると、Actifio を使用してバックアップを構成でき、vSphere Replication によってデータベースの DR 要件をサポートするように構成されます。サポートされるオペレーティング システムとデータベースについては、Actifio Go のサポートに関するマトリクスを参照してください。Actifio コネクタを使用してデータベースをバックアップするには、オペレーティングシステムとデータベースのバージョンの両方がサポートされている必要があります。データベースが Actifio でサポートされていない場合、データベース固有のバックアップ ツール(RMAN、mysqldump、pg_dump など)を使用して接続されたボリュームにバックアップを検討したうえで、必要なスケジュールでバックアップを含むディスク ボリュームのスナップショットを作成するよう Actifio を構成してください。

ホストでクロスリージョンの障害復旧が必要な場合、一般的な次のステップは、vSphere Replication を構成してプライマリ リージョンと DR リージョンの間で VM のレプリケーションを実施します。 VMware Site Recovery Manager では、VM のレプリケーションと復元の自動化をサポートしていますが、必須ではありません。Site Recovery Manager では、VMware PowerCLI を使用してスクリプトの作成と自動化が可能です。

最初のスナップショットの作成が完了した後、RPO と RTO の要件をサポートするために、必要な間隔で増分スナップショットがスケジュールされます。DR リージョンへのフェイルオーバーを実行する場合、サブネットの変更に伴い IP アドレスの変更と DNS の更新について計画を立てることが重要です。データベースによっては、tnsnames.ora や listener.ora などの特定のデータベースの構成ファイルを更新し、新しいホスト IP アドレスを反映する必要がある場合があります。 ユーザーが DNS CNAME を介してデータベースに接続する場合、CNAME レコードも更新する必要があります。

すべてのデータベースが vSphere Replication でサポートされているわけではありません。こちらの VMware サードパーティ ソリューションの相互運用性マトリックスをご覧になり、お使いのデータベースが vSphere Replication でサポートされているか確認してください。データベースが vSphere Replication でサポートされていない場合は、レプリケーション、ログの配布、Always On 可用性グループなどのデータベース固有の機能を実装することもできます。

データベース アーキテクチャの変更は、初期移行時に処理されるか、延期され後から行われる場合もあります。たとえば、オンプレミスの MSSQL 2016 フェイルオーバー クラスタ(FCI)では、GCVE の FCI に移行しない場合があります。GCVE では、vMotion を使用した HA をサポートし、vSphere Replication と Actifio によって DR 要件を満たす可能性があるためです。

今後の展開: GCE のモダナイゼーションとハイブリッド化- GCVE の活用

データベースとアプリケーションが GCVE に移行されると、アプリケーションとデータベースのモダナイゼーションに焦点を当てた新しいワークストリームを開始します。後続プロジェクトには、GCE や GKE で運用するためにアプリケーションを再設計するアプリケーションのモダナイゼーションに向けた取り組みが含まれる場合があります。このケースでは、GCE と GCVE のハイブリッド運用環境(アプリケーションを GCE に移行し、データベースを GCVE に残す)の出番となります。  

GCVE のネットワーキング、接続オプション、一般的なユースケースの詳細については、プライベート クラウドからオンプレミスプライベート クラウドから VPC限定公開の Google アクセスをご覧ください。

まとめ

GCVE へのリフト&シフト移行は、オンプレミスから GCVE へデータベースを移行する際によく使用される戦略です。初期移行が完了すると、組織はアプリケーションとデータベースのモダナイゼーション プロジェクトを開始し、クラウドネイティブ アプリケーションとデータベースのサービスにプラットフォームを再構築できます。

- Google Cloud プロフェッショナル サービス戦略クラウド エンジニア Matthew Smith
投稿先