The Windows HPC Team Blog : HPC AD DNS

Headnode reports itself as Unreachable

FrankChism — Mon, 05 Oct 2009 19:32:00 GMT

I find a lot of people are starting to build demonstration clusters on a small scale with some sort of minimal ‘enterprise’ network. In my case the enterprise network is my home router and the private network is a little 5 port GigE switch.

To make it a bit more realistic and to be able to test configurations where the head node is _not_ the Active Directory Domain controller, I created a Domain Controller for my test network. I then added the cluster head node to this domain and installed the HPC 2008 Pack. The setup worked like a champ.

Then about one month later I was trying to run some tests when I noticed that the head node reported that it was ‘Unreachable’. How can this be I thought? All its networks were active, it could ping itself and the router and other private network nodes. Finally I stumbled onto trying to ping the Domain Controller. Surprise! No response from the DC. It seems that my 5 year old NIC on the Domain Controller had crossed the digital divide to the land of failed hardware.

Replacing the NIC, and installing a valid 64-bit driver for it brought the DC back into the network and in next to no time the head node self-reported as reachable.

When a domain joined system boots, it tries to contact its domain controller. If it can’t, it will come up and allow console logins on cached credentials, but periodically look for a domain controller connection to see if it can trust itself.

In my case the broken NIC prevented DC access, but the cached credentials allowed console logins.

I have seen similar Unreachable situations when a compute node cannot reach its domain controller. If you log on to a node immediately after it has rebooted and use the Event Viewer to look at the Windows Logs-> Security events you will see numerous Logon and Special Logon events. This is how the node establishes itself as being a member of the cluster, and if these fail, the node will appear as Unreachable.

Frankie

DNS Suffix vs. Active Directory Domain for HPC cluster (Part 2)

Steve Roach — Wed, 22 Apr 2009 17:59:00 GMT

In an earlier post, I described an approach for resolving names when the connection specific DNS suffix did not match the Active Directory domain name. Recently, I realized that there is a much simpler solution. The Default ComputeNode Template which is created when you run through the Node Template Creation Wizard contains a step for joining the AD domain, but unless you edit the template, the field for specifying the AD domain name is blank. If that field is blank, the compute nodes will use the primary DNS suffix of the head node as the name of the AD domain they attempt to join, and if there is no such domain, that step will fail. So, the solution is simply to edit the Node Template and add the AD Domain name to that field.

DNS Suffix vs. Active Directory Domain for HPC cluster

Steve Roach — Tue, 31 Mar 2009 21:52:00 GMT

A few months ago, I was asked a question about how to assign a connection specific DNS Suffix to a NIC which was different from the Active Directory Domain. For example, the AD Domain was contoso.com, but they wanted to be able to assign a DNS suffix of cluster.contoso.com. If the Fully Qualified Domain Name (FQDN) of cluster.contoso.com was specified as a DHCP scope option (015 DNS Domain Name), then the installation would fail when the nodes attempted to join an Active Directory Domain that did not exist.

This scenario would only arise for clusters which are configured with network topology 2 or 4, where all the compute nodes have a connection to the enterprise LAN as well as to the private one. Otherwise, this would not be an issue, because the compute nodes would only be connected to the private network and would not be accessable from the rest of the enterprise and therefore would not have DNS entries.

After some searching, I determined that a good work around would be to add a new domain to the contoso.com DNS Forward Lookup Zone. The steps to implement this solution are as follows:

Specify cluster.contoso.com as the 015 DNS Domain Name scope option for the DHCP server which manages the scope that includes the NIC's on the cluster nodes which are attached to the enterprise network.
Install the head node. Before joining the AD Domain, verify the Connection-specific DNS suffix for the enterprice NIC by running the ipconfig command.
Join the head node to the contoso.com AD Domain. Install the HPC Pack and follow the standard proceedure for installing the compute nodes from bare metal. When this process completes, the nodes will all belong to the contoso.com AD Domain, and the DNS Host(A) records for all the nodes will indicate the FQDN to be <hostname>.contoso.com. However, the ipconfig command will show that the Connection-specific DNS suffix for the enterprise NIC's is cluster.contoso.com.
Add a New Domain to the contoso.com DNS Forward Lookup zone.
Name the New Domain "cluster". Then add New Alias (CNAME) records to this domain for each of the nodes in the cluster which equate the <hostname>.cluster.contoso.com FQDN to the target <hostname>.contoso.com FQDN.

Please let me know if this information was helpful to you.