Configure DNS for an Oracle Cloud VMware Solution SDDC

This article shows you how to achieve DNS name resolution when deploying SRM and vSphere Replication in Oracle Cloud VMware Solution.

Oracle Cloud VMware Solution is a one-click VMware SDDC deployment from Oracle Cloud Infrastructure Console. The automation of Oracle Cloud VMware Solution deploys standard settings for VMware vSphere, NSX-T, and VSAN, such as default hostnames, VLANS, network security groups (NSGs), route tables, security lists, and so on. To deploy and configure VMware SRM for disaster recovery implementation, you must modify these default settings.

Name resolution within the virtual infrastructure is a key requirement for functional validation of VMware components. Failure to meet this requirement can lead to an unsuccessful SRM implementation for disaster recovery.

Oracle Cloud VMware Solution deploys vCenter Server with embedded mode with the default Single Sign-On/Platform Services Controller vsphere.local domain. The other VMware products and their extensions are always integrated with the vCenter Server lookup service. So, it’s important that VMware SRM and vSphere Replication appliance can communicate with vCenter Server by using the default fully qualified domain name (FQDN). At the same time, the on-premises SRM implementation must also be able to communicate with SRM implementation in Oracle Cloud VMware Solution for site pairing, replication, and other disaster recovery configuration.

The Oracle Cloud VMware Solution DNS is managed by Oracle and doesn’t allow you to add more DNS records in the same domain where vCenter and NSX records are created by default. It also means that SRM and vSphere Replication appliance can’t communicate with VMware's vCenter, Platform Service Controller, or NSX by using FQDN.

To overcome this challenge, we recommend that you create a DNS server to host the zone with the same name as that of default Oracle Cloud VMware Solution domain. This allows you to create additional DNS records that are necessary for disaster recovery implementation using SRM and vSphere Replication. This step is necessary to have DNS name resolution for all the deployed components within and across the sites.

Note:

The entire disaster recovery implementation could use IP addresses, but we recommend implementing SRM and vSphere Replication with FQDN.

Use Custom DNS in the Environment

Before you begin, ensure that both sites are connected over the network and can communicate with each other over IP addresses. For networking prerequisites and site connectivity details, see the section for each deployment model later in this playbook.

Note:

These steps are required for all Oracle Cloud VMware Solution clusters that you deploy. You might want to have both environments running on Oracle Cloud VMware Solution with SRM and vSphere Replication for disaster recovery implementation. This playbook describes all deployment models for disaster recovery using SRM and vSphere Replication. For deployment models 2 and 3, you must have a dedicated DNS server for each Oracle Cloud VMware Solution deployment.

Create a DNS Server Local to Oracle Cloud VMware Solution

Implement custom DNS for each Oracle Cloud VMware Solution deployment by following the steps below.

Note:

This procedure uses Deployment Model 1 for illustration. You must follow the same procedure for Deployment Models 2 and 3.

1. Deploy a Windows Server compute instance in Oracle Cloud Infrastructure in the same VCN where Oracle Cloud VMware Solution is deployed.
2. Perform standard DNS and Active Directory Domain Controller installation.
3. Create forward and reverse lookup zones that use the same name as the Oracle Cloud VMware Solution default domain name.
4. Create forward and reverse lookup entries for vCenter Server, NSX Manager, SRM, and vSphere Replication appliance under the sddc.xxx.oci.oraclecloud.com zone (where xxx is the region code; for example, lhr). Update the associated PTR records under the x.xx.xx.in-addr.arpa (where x.xx.xx represents the reverse 3 octave of the IP address) reverse lookup zone that pertain to Oracle Cloud VMware Solution deployment.
5. Create a zone that refers to the on-premises domain name. This is required for both sites to communicate using FQDN.
6. Create the necessary forward and reverse lookup entries from the on-premises implementation, such as vCenter, Platform Service Controller (if it’s external), SRM, vSphere Replication appliance, and NSX Manager (if it’s part of implementation) under the acme.local zone. Update the associated PTR records under x.xx.xx.in-addr.arpa (where x.xx.xx represents the reverse 3 octave of the IP address). This step ensures that communication can work from Oracle Cloud VMware Solution to on-premises components using FQDN.
7. Log in to your on-premises DNS server and create a forward and reverse lookup zone for Oracle Cloud VMware Solution deployment.
8. Create the necessary forward and reverse lookup entries from the Oracle Cloud VMware Solution deployment—such as vCenter, SRM, vSphere Replication appliance, and NSX Manager—under sddc.xxx.oci.oraclecloud.com for forward lookup zones and x.xx.xx.in-addr.arpa for reverse lookup zones.
9. Use the Oracle Cloud VMware Solution DNS server address when you deploy SRM and vSphere Replication appliance in Oracle Cloud VMware Solution. For deployment models 2 and 3, each site’s Oracle Cloud VMware Solution environment uses a dedicated DNS server.
10. Repeat the DNS deployment and configuration steps for deployment models 2 and 3. Replace the on-premises environment with Oracle Cloud VMware Solution where both primary and recovery sites are deployed in Oracle Cloud VMware Solution.

The preceding steps ensure that both sites can communicate with each other using FQDN. Validate by using a ping test to see if each site’s disaster recovery components can communicate with each other using FQDN for all deployment models.