Technical Considerations for a Serviceguard Cluster that Spans Multiple IP Subnets, July 2009

17
resolution requests at the cost of using old records for a long time. Setting it to a low value (e.g. a few
seconds) reduces the time old records might be used at the cost of increased number of name
resolution requests at the client and a higher load on the DNS server. In a cross-subnet configuration
this parameter might be best set at value that is less than the time it takes for an application to fail
over to a cluster node in a different subnet.
The Dynamic DNS update request can also run in non-interactive mode and be triggered by the
application package script. In this case one could prepare two input files specifying the name
resolution information depending on whether the package starts on a node in subnet/site 1 or 2 and
run nsupdate with the appropriate input file at package startup.
Example nsupdate input file “at-site-1”when package starts in subnet 5.1.2.0:
update delete db-serv.hp.com
update add db-serv.hp.com 60 A 5.1.2.10
send
Example nsupdate input file “at-site-2”when package starts in subnet 5.2.2.0:
update delete db-serv.hp.com
update add db-serv.hp.com 60 A 5.2.2.10
send
The above examples show the commands to update the A-record for a relocatable IP address. This
record is used for resolving a given domain name to an IP address.
In environments in which reverse DNS lookup or reverse DNS resolution is used to determine the
domain name that is associated with a given IP address, the corresponding PTR-record needs to be
updated along with the A-record.
Example nsupdate command to update a PTR-record:
update delete 10.2.2.5.in-addr.arpa
update add 10.2.1.5.in-addr.arpa 60 PTR db-serv.hp.com
send
In this example, applications which honor the TTL value would use the old record for a maximum of 1
minute after the DNS records has been updated following a cross-subnet failure. The cluster nodes
need to be authorized to update DNS records on the DNS server.
Global Server Load Balancer (GSLB)
The usage of Dynamic DNS requires a mechanism to update the name to IP address mapping at a
specific event (failure to a node in a different subnet) as described above. This is not necessary when
using GSLB devices. GSLB devices are configured to work in combination with DNS servers and can
also act as DNS servers. Each time a system requests a name resolution from its DNS server, the DNS
server will forward that request to a GSLB if the TTL expired or returns the cached IP address to the
requesting system if the TTL hadn’t expired. If forwarded to a GSLB, the GSLB will check which of the
two IP addresses responds and provide the active IP address along with a TTL value in its reply to the
DNS server.
Some GSLB devices use an abstraction layer which leads to non-uniform reverse lookups. Given the
example below:
db-srv.hp.com  15.84.120.5  db-srv1.hp.com
db-srv.hp.com  15.84.136.5  db-srv2.hp.com
clients request a resolution for “db-srv.hp.com” and receive either “15.84.120.5 ” or
”15.84.136.5 ” depending on which IP address / site is active. However a reverse lookup of