How to leverage global address resolution using Cloud DNS in Google Cloud VMware Engine

Following up our previous deep dive about multi-VPC networking in Google Cloud VMware Engine and in keeping with the objective of integrating more and more native Google Cloud services, we now support across-the-board global name resolution for the Google Cloud VMware Engine management components, namely vCenter, NSX Manager and HCX Manager. Customers desire the ability to resolve a fully qualified domain name (FQDN) of a Google Cloud VMware Engine managed endpoint in any private cloud in any region for any project from a central on-premises domain name system (DNS) server, and today’s new feature leverages an automatic integration with Cloud DNS, providing such functionality.

Cloud DNS is a high-performance, resilient, global DNS service that manages your domain names and provides a 100% availability service-level agreement (SLA).

With this new capability, a VMware administrator can now access the various core VMware components via FQDN from anywhere (on-premises, your VMware Private Cloud (VPC), or even Google Cloud VMware Engine itself), and if a customer has deployed multiple private clouds, these components can be reached as well without issues. We are providing a single entry point for management of DNS for multiple private clouds running across various regions to be able to span deployments across the globe, making it easier for customers to manage their distributed environments.

Global DNS relies on DNS peering zones that are automatically created and configured as new Google Cloud VMware Engine private clouds are brought online, which means there is no user intervention required.

Use cases:
The main use case is if a customer has one or multiple private clouds and wants to resolve VMware management components from their VPC(s) or their on-premises data center. A prime example of this is cross-site Hybrid Cloud Extension (HCX) connectivity, which would enable VM instance mobility between the on-premises data center and a private cloud in Google Cloud. Additional use cases will be unlocked by this capability in the future.

Benefits and differentiators:

• Each private cloud has its own DNS. It is difficult to configure DNS resolution if those are deployed in multiple regions and global DNS addresses this challenge.

• Cloud DNS provides a 100% availability SLA, meaning that name resolution for these critical management components will always be available.

• Customer’s ability to identify and troubleshoot issues with name resolution is enhanced by integrating with the native Cloud DNS service.

• Customers can use this new capability to resolve names for management components from both their VPC(s) and also on-premises.

How to configure:
There is nothing to configure! As mentioned earlier, this feature is activated every time a Google Cloud VMware Engine private cloud is provisioned and we do that for you automatically. Just make sure you set up the Private Service Access connection and the Cloud DNS API is enabled in your project.

Digging deeper into the implementation and what’s happening under the hood in the following customer project, a DNS peering zone is automatically created and mapped to a private zone managed by Google inside of a Google managed project. In this private zone, A records and pointer records (PTR) exist for each one of the VMware products deployed in Google Cloud VMware Engine. This means that VM instances (or services) in the customer VPC(s) can directly resolve the FQDNs for these components via the metadata server, just like they would other apps running in the cloud. Below we can see a screenshot of Cloud DNS and the configuration that resulted after setting up the private service access connection:

And if we dive deeper into the servicenetworking.googleapis.com peering zone:

For on-premises applications to reach the VMware components in Google Cloud, you will need to create a conditional forward on your DNS server for Google Cloud VMware Engine as documented in this guide for Configuring DNS for management appliance access. Additionally, when you delete a private cloud, the DNS configuration will automatically be removed from your project.

What about DNS resolution for workloads in Google Cloud VMware Engine?
There are multiple strategies for providing domain name resolution for the applications hosted in Google Cloud VMware Engine, and they will depend on where you want or need to place the DNS servers.

1. DNS servers inside of Google Cloud VMware Engine
   This is the most straightforward option for name resolution of VMware applications. You can place your DNS servers inside of Google Cloud VMware Engine as just another workload, and point your applications to them either statically or via dynamic allocation (Dynamic Host Configuration Protocol). These DNS servers will be authoritative for the VMware environment and can be configured according to your hierarchy, availability and performance needs. As a best practice, these infrastructure components should be placed in a dedicated network and secured accordingly, by using the embedded perimeter (gateway firewall in the Tier-1 and/or Tier-0) and distributed firewalling capabilities (in-hypervisor firewall) of Google Cloud VMware Engine, which are . This option is very common when customers move, or instantiate, 100% of their applications in Google Cloud Platform.
2. DNS servers located on-premises or in other public clouds
   This is a very common model when customers do not fully migrate their VMware environments to Google Cloud and still maintain infrastructure in their own on-premises data centers, or in other clouds. As mentioned earlier in this article, these authoritative on-premises/cloud servers can be configured to forward queries to Cloud DNS to resolve VMware management components, and could also host the zones associated with the VMware applications. In addition, VMware NSX can be configured to provide conditional forwarding to these servers for specific domains or subdomains, in case this level of granularity is required. For more information about configuring a DNS forwarder in VMware NSX, please refer to the documentation on adding a DNS forwarder service.

3. Leveraging Cloud DNS for VMware workloads
   In this model, Cloud DNS provides centralized name resolution for both VMware management components and Google Cloud VMware Engine-hosted applications. This model is desirable due to the high resiliency of Cloud DNS (100% SLA). There is some configuration required in order to steer DNS traffic over the various hops between Google Cloud VMware Engine and Cloud DNS, which are documented separately.

4. DNS server in the customer VPC
   As another option for customers wanting to deploy these DNS servers in their VPC, Compute Engine instances can be configured as DNS servers (for example, BIND) to provide name resolution. As a best practice and for high availability and redundancy, it is recommended to front end a managed instance group or an unmanaged instance group using an internal load balancer (ILB), and use the ILB virtual IP (VIP) as the DNS server.

These tips should help you effectively leverage Cloud DNS and other DNS options to gain better control over your Google Cloud VMware Engine deployment across one or multiple private clouds for both your management infrastructure and also your workloads.

For more information about the end-to-end networking capabilities and services available in Google Cloud VMware Engine, please refer to the Private Cloud Networking for Google Cloud VMware Engine whitepaper, which includes details about network flows, configuration options, and the differentiated benefits of running your VMware workloads in Google Cloud.