クラウド マイグレーション

Google Cloud VMware Engine で Cloud DNS を使用したグローバル アドレス解決を活用する方法

cloud_migration

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

Google Cloud VMware Engine のマルチ VPC ネットワークについて掘り下げた前回に続き、ネイティブの Google Cloud サービスをより多く統合させるという目標に向けて、Google Cloud VMware Engine の管理コンポーネント(vCenter、NSX Manager、HCX Manager)に対応するグローバルな名前解決を全面的にサポートするようになりました。お客様は、どのプロジェクトについても、任意のリージョンの任意のプライベート クラウド内にある Google Cloud VMware Engine が管理するエンドポイントの完全修飾ドメイン名(FQDN)を中心となるオンプレミスのドメイン ネーム システム(DNS)サーバーから解決できる性能を求めています。本日取り上げる新機能は、Cloud DNS と自動で統合することで、それを可能にします。

Cloud DNS は、高パフォーマンスで復元力を備えたグローバル DNS サービスで、ドメイン名を管理し、可用性が 100% のサービスレベル契約(SLA)を提供します。

この新機能により、VMware 管理者が FQDN を介してどこからでも(オンプレミス、VMware Private Cloud(VPC)、または Google Cloud VMware Engine 自体からでも)、さまざまなコア VMware コンポーネントにアクセスできるようになります。複数のプライベート クラウドを所有している場合でも、問題なくこれらのコンポーネントに到達できます。さまざまなリージョンで運用されている複数のプライベート クラウドの DNS を管理する単一のエントリ ポイントを提供することで、世界中でのデプロイが可能になり、お客様が分散環境をより簡単に管理できるようになります。

グローバル DNS は、新しい Google Cloud VMware Engine のプライベート クラウドがオンラインなると自動で作成および構成される DNS ピアリング ゾーンに依存するため、ユーザーの介入は必要ありません。

1 cloud dns.jpg

ユースケース:

主要なユースケースとして、お客様が 1 つまたは複数のプライベート クラウドを所有していて、自社の VPC やオンプレミスのデータセンターから VMware の管理コンポーネントを解決する場合があります。この典型的な例が、クロスサイトの Hybrid Cloud Extension(HCX)の接続性です。これにより、オンプレミスのデータセンターと Google Cloud のプライベート クラウド間の VM インスタンスのモビリティが可能になります。その他のユースケースは、将来、この機能によって明らかになるでしょう。

メリットと差別化要因:

  • 各プライベート クラウドには独自の DNS があります。複数のリージョンでデプロイされ、グローバル DNS がこの課題に対応する場合、DNS の解決を構成することは困難です。

  • Cloud DNS は可用性が 100% の SLA を提供します。つまり、これらの重要な管理コンポーネントの名前解決は常に利用可能になります。

  • ネイティブの Cloud DNS サービスと統合することで、お客様の名前解決に関する問題の特定とトラブルシューティングの能力が向上します。

  • お客様がこの新機能を使用して、自社の VPC とオンプレミスの両方から管理コンポーネントの名前解決を行えるようになります。

構成方法:

構成する必要はありません。前述のとおり、この機能は、Google Cloud VMware Engine のプライベート クラウドがプロビジョニングされるたびに有効になります。お客様の代わりに、自動で行われます。プライベート サービス アクセスの接続を設定済みで、Cloud DNS API がプロジェクトで有効になっていることだけ確認してください。

次の顧客プロジェクトにおいて、実装時に内部で何が起こっているかをさらに深く掘り下げてみると、DNS ピアリング ゾーンが自動的に作成され、Google のマネージド プロジェクト内にある Google が管理するプライベート ゾーンにマッピングされていることがわかります。このプライベート ゾーンには、Google Cloud VMware Engine でデプロイされた各 VMware プロダクトのレコードとポインタ レコード(PTR)が存在します。つまり、顧客 VPC の VM インスタンス(またはサービス)により、クラウドで実行されている他のアプリと同じように、メタデータ サーバーを介してこのようなコンポーネントの FQDN を直接解決できます。以下は、Cloud DNS のスクリーンショットと、プライベート サービス アクセスの接続設定後の構成を示しています。

2 cloud dns.jpg

servicenetworking.googleapis.com ピアリング ゾーンをさらに詳しく調べる場合:

3 cloud dns.jpg

オンプレミスのアプリケーションが Google Cloud の VMware コンポーネントに到達するには、管理アプライアンス アクセス用の DNS の構成に関するガイドに記載されているように、Google Cloud VMware エンジンの DNS サーバーで条件付き転送を作成する必要があります。また、プライベート クラウドを削除すると、DNS 構成はプロジェクトから自動的に削除されます。

Google Cloud VMware Engine のワークロードに対応する DNS の解決の場合は?

Google Cloud VMware Engine でホストされているアプリケーションのドメインの名前解決を提供する方法は複数あり、DNS の設置場所によって変わってきます。

  1. Google Cloud VMware Engine 内の DNS サーバー
    VMware アプリケーションの名前解決の最もわかりやすいオプションです。DNS サーバーを Google Cloud VMware Engine の内部に別のワークロードとして配置し、静的にまたはダイナミック アロケーション(Dynamic Host Configuration Protocol)を介して、アプリケーションを DNS サーバーに示すことができます。DNS サーバーは、VMware 環境に対して権限を持ち、階層、可用性、パフォーマンスのニーズに応じて構成が可能です。ベスト プラクティスとして、このようなインフラストラクチャのコンポーネントは、専用のネットワーク内に配置され、組み込みの境界(Tier-1 および / または Tier-0 のゲートウェイ ファイアウォール)と Google Cloud VMware Engine の分散型ファイアウォール機能(ハイパーバイザ ファイアウォール内)を使用して、適切に保護される必要があります。このオプションは、お客様が Google Cloud Platform の全アプリケーションを移動またはインスタンス化する場合によく利用されます。

  2. オンプレミスまたは他のパブリック クラウドに配置された DNS サーバー
    お客様が VMware 環境を Google Cloud に完全に移行せずに、自社のオンプレミス データセンターまたは他のクラウドでインフラストラクチャを維持する場合によく利用されるモデルです。この記事で前述したように、このような権限のあるオンプレミスまたはクラウド サーバーは、クエリを Cloud DNS に転送して VMware 管理コンポーネントを解決するように構成できます。また、VMware アプリケーションに関連付けられたゾーンもホストできます。さらに、このレベルの粒度が必要な場合、特定のドメインまたはサブドメイン用のサーバーに条件付き転送を行うように、VMware NSX を構成できます。VMware NSX での DNS フォワーダの構成についての詳細は、DNS フォワーダ サービスの追加に関するドキュメントをご覧ください。

  3. VMware ワークロードでの Cloud DNS の活用
    このモデルでは、Cloud DNS により、VMware 管理コンポーネントと Google Cloud VMware Engine ホステッド アプリケーションのどちらにも一元化した名前解決が可能になります。Cloud DNS の高い復元力(100% SLA)により望ましいモデルとなっています。Google Cloud VMware Engine と Cloud DNS 間の多様なホップ上の DNS トラフィックを操作するために必要となる構成があります。この構成に関しては、別途記載されています。

  4. 顧客 VPC 内の DNS サーバー
    自社の VPC の DNS サーバーにデプロイする場合のもう一つのオプションとして、Compute Engine インスタンスを DNS サーバー(BIND など)として構成して、名前解決を提供できます。ベスト プラクティスとして、可用性と冗長性を高めるには、内部ロードバランサ(ILB)を使用してマネージド インスタンス グループまたは非マネージド インスタンス グループをフロントエンドで処理し、DNS サーバーとして ILB 仮想 IP(VIP)を使用することをおすすめします。

前述の使い方により、Cloud DNS と他の DNS のオプションを効果的に活用し、管理インフラストラクチャとワークロードのどちらにも対応する 1 つまたは複数のプライベート クラウドにわたる Google Cloud VMware Engine のデプロイにおける制御を向上させることができます。

Google Cloud VMware Engine で利用できるエンドツーエンドのネットワーキング機能とサービスの詳細については、Google Cloud VMware Engine のプライベート クラウド ネットワーキングのホワイトペーパーを参照してください。このホワイトペーパーには、ネットワーク フロー、構成オプション、Google Cloud で VMware ワークロードを実行することの他とは異なるメリットも記載されています。