Name Resolution

IP addresses are used to communicate and transfer data between DataCore Servers (including Replication partners), as well as to communicate and transfer information between DataCore Servers and remote SQL Servers recording performance data and computers running the DataCore Management Console. In order to make a network connection using host names, all machines must be able to resolve the host names of DataCore Servers to their IP address.

DataCore strongly recommends using host names instead of IP addresses. Host names can be resolved to IP addresses regardless of changes to the IP addresses.

This topic addresses name resolution and how it pertains to connecting to a server group, and facilitating communications within a local server group, between local and remote server groups replicating virtual disks, using remote SQL Servers for performance recording, and when using a remote DataCore Management Console. Also see Connecting to a Server Group and Establishing Server Groups for more information.

Numerous name resolution mechanisms and implementations exist. The correct name resolution implementation should be based on your network configuration. Before making any changes based on the information in this topic, consult your IT department for guidance and to ensure compliance with the name resolution implementation for your network configuration.

Functioning Name Resolution

A name resolution mechanism must exist to resolve hostnames to IP addresses. For instance, some examples of name resolution mechanisms are Domain Name System (DNS) or Windows HOSTS file.

A fully qualified domain name (FQDN) specifies an exact network location of a network device. For example, given a computer with a local computer name "mycomputer and a parent domain name

A host name can be either a computer name or a FQDN.

  • If a host name (not an FQDN) is used to connect to a server group, and DNS or Windows HOSTS file is not used, then the Windows NetBIOS port 137 used to resolve host names must be open.SeeWindows Settings Disclosurefor more information about ports used insoftware.
  • A HOSTS file will override DNS and could give incorrect results if IP addresses are changed on the DNS.
  • The computer name in a HOSTS file is case sensitive.
  • The computer name used in a HOSTS file should be the computer name used to connect to a server group (typically the short name). To ensure correct name resolution using the HOSTS file, when a server is in a domain use the FQDN (not the short name). See Connecting to a Server Group for more information.
  • The computer name used in a HOSTS file, should be the computer name used to connect to a server group (typically short name). To ensure correct name resolution using the HOSTS file when the server is joined to a domain or the primary DNS suffix is set, use the FQDN, otherwise use the short name. See Connecting to a Server Group for more information.

Partnering Within a Server Group

Each server running DataCore SANsymphony software must be able to resolve the host names of each DataCore Server in the server group to which it belongs.

For instance, to partner DataCore Servers A1 and A2 into the same Server Group A:

  • DataCore Server A1 must be able to resolve the host name "A2" to an IP address that A1 can connect to.
  • DataCore Server A2 must be able to resolve the host name "A1" to an IP address that A2 can connect to.

Ensure that the DataCore Servers can reach each other. From a command line on the computer running the console, ping each server using the host name and ensure there is a successful reply. For instance, "ping A1" and "ping A2". If the ping times out without a reply, check firewall settings to ensure the reply is not being blocked.

Remote Management via the DataCore Management Console or from a Different Server Group

The computer running the console must be able to resolve the host names of each DataCore Server in the server group to which it is connecting.

For instance, to connect from a DataCore Management Console running on Machine X to Server Group A consisting of DataCore Servers A1 and A2:

  • The console on Machine X must be able to resolve the host name "A1" to an IP address that Machine X can connect to.
  • The console on Machine X must be able to resolve the host name "A2" to an IP address that Machine X can connect to.

If the computer running the DataCore Management Console is "outside" the network of the server group that it is connecting to, then public IP addresses may be required for the computer running the console and each DataCore Server in the server group. In this case, host names must be resolved to the public IP addresses using the appropriate name resolution mechanism. (Editing the HOSTS file might be a possible solution.)

Ensure that the console can reach each DataCore Server. From a command line on the computer running the console, ping each server using the host name and ensure there is a successful reply. For instance, "ping A1" and "ping A2". If the ping times out without a reply, check firewall settings to ensure the reply is not being blocked.

Replication

All servers running DataCore SANsymphony software in the local and remote server groups involved in virtual disk replication must be able to resolve the host names of all other DataCore Servers in those groups.

For instance, Server Group A consisting of DataCore Servers A1 and A2 which are replicating virtual disks to Server Group B consisting of DataCore Servers B1 and B2 must be able to resolve the following:

  • DataCore Server A1 must be able to resolve host names "B1" and "B2" to IP addresses that A1 can connect to.
  • DataCore Server A2 must be able to resolve host names "B1" and "B2" to IP addresses that A2 can connect to.
  • DataCore Server B1 must be able to resolve host names "A1" and "A2" to IP addresses that B1 can connect to.
  • DataCore Server B2 must be able to resolve host names "A1" and "A2" to IP addresses that B2 can connect to.

If Server Groups A and B are on different networks, then public IP addresses may be required for all DataCore Servers in both server groups. In this case, host names must be resolved to the public IP addresses using the appropriate name resolution mechanism. (Editing the HOSTS file might be a possible solution.)

Ensure that DataCore Servers in both server groups can reach each other. From a command line on each DataCore Server ping each server in the other server group and ensure there is a successful reply. For instance, from a command line on DataCore Server A1, "ping B1" and "ping B2". Repeat for each server. If the ping times out without a reply, check firewall settings to ensure the reply is not being blocked.

Remote Access between Server Groups and Servers Outside the Network

In some cases server groups may require access to remote servers, such as SQL Recording Servers or Support Bundle Relay servers.

Each DataCore Server in the local server group must be able to resolve the host name of the remote server to which it is connecting.

For instance, Server Group A consisting of DataCore Servers A1 and A2 must be able to resolve the following:

  • DataCore Server A1 must be able to resolve host name "Remote Server" to an IP address that A1 can connect to.
  • DataCore Server A2 must be able to resolve host name "Remote Server" to an IP address that A2 can connect to.

If the remote server is "outside" the network of the server group that it is connecting to, then public IP addresses may be required for the remote server and each DataCore Server in the server group. In this case, host names must be resolved to the public IP addresses using the appropriate name resolution mechanism. (Editing the HOSTS file might be a possible solution.)

Ensure that each DataCore Server in the server group can reach the remote server. From a command line on each DataCore Server ping the remote server and ensure there is a successful reply. For instance, from a command line on DataCore Server A1, "ping Remote Server". Repeat for each server in the server group. If the ping times out without a reply, check firewall settings to ensure the reply is not being blocked.