Monday, March 10, 2014

GNS Overview

In a static configuration, all addresses are assigned by administrative action and given names that resolve with whatever name service is provided for the environment. This is universal historic practice because there has been no realistic alternative.

One result is significant turnaround time to obtain the address, and to make the name resolvable. This is undesirable for dynamic reassignment of nodes from cluster to cluster and function to function.

DHCP provides for dynamic configuration of the host IP address but does not provide a good way to produce good names that are useful to external clients. As a result, it is rarely used in server complexes because the point of a server is to provide service, and clients need to be able to find the server.

This is solved in the current release by providing a service (GNS) for resolving names in the cluster, and defining GNS to the DNS service used by the clients.

To properly configure GNS to work for clients, it is necessary to configure the higher level DNS to forward or delegate a subdomain to the cluster and the cluster must run GNS on an address known to the DNS, by number. This GNS address is maintained as a VIP in the cluster, which is run on a single node, and a GNSD process that follows that VIP around the cluster and service names in the subdomain. To fully implement GNS, you need four things:

  • DHCP service for the public network in question
  • A single assigned address in the public network for the cluster to use as the GNS VIP
  • A forward from the higher-level DNS for the cluster to the GNS VIP
  • A running cluster with properly configured GNS

No comments:

Post a Comment