In all aspects of virtualization, there is one consistent supporting technology that enables everything to “just work” - DNS. For VMware vSphere and VI3 environments, DNS is critical for ESX(i) communication to vCenter. This criticality stems from VMware’s High Availability (HA) and Distributed Resource Scheduler (DRS) features being able to communicate to the management node of vCenter Server.
In terms of data protection with Veeam Backup and Replication, DNS also plays a critical part. This is especially important if multiple DNS zones, local Windows workgroups or multiple DNS servers are in use. The user interface of Veeam Backup and Replication is somewhat deceiving in that the connection is made directly to the vCenter Server in most situations. Individual hosts can be added, however most people aim for better scaling by pulling in the vCenter management node.
When a vCenter server is added to the Veeam Backup and Replication console, it confirms the DNS resolution to that endpoint. Further, the job definition that selects an individual host, virtual machine or other object in vCenter relies exclusively on the resolution to the vCenter Server and the objects in the vCenter database. This is the case when the vCenter Server is added into Veeam Backup and Replication exclusively.
DNS is used to connect the dots when the job is launched. At that point, Veeam Backup and Replication needs to determine where the virtual machine is located. This returns the VMware ESX(i) server where the virtual machine(s) for the job are located. This network resolution is directly from the Veeam Backup and Replication server to the ESX(i) host. This means that the Veeam Backup and Replication server needs to be able to resolve the host’s fully qualified domain name (FQDN) directly. Further, if advanced VMware features such as the vStorage APIs are to be used; port 902 needs to be open between the ESX(i) host and the Veeam Backup and Replication server to establish a network file copy (NFC) to perform the data mover operation when not using virtual appliance or direct SAN access modes.
DNS comes in to play when any of the components are not on the same zone or on the same Active Directory domain for the Windows systems or when multiple DNS servers are in use. It becomes an important end-to-end design element to ensure a full-circle DNS resolution consistency. This was a topic for me recently in a lab that has a separation between different domains and resolution realms, I was stuck on this very scenario!
As in any part of today's infrastructure, DNS clearly is an area that needs to be consistently accurate. Whether it be DNS configuration on the ESX(i) host itself to resolve names, Veeam Backup and Replication server's DNS configuration, or parts in between; DNS configured correctly is critical for all systems to work smoothly.