Distributed Name Service (DNS) Management Operations Manual

Distribution Strategy of Network Control Nodes
How DNS Exports the Name Database
5–8 31258 Tandem Computers Incorporated
Important Considerations
About Database
Distribution
The fact that only one node can export or update the definition of a name has one
important implication: if the definition node becomes unavailable, other nodes can no
longer receive new definitions or updates from the definition node.
If you need to update the name’s definition immediately, you can ask DNS to provide
an alterable copy of that definition with the COPY command on your own node.
However, your changes to the copied name definition affect only your local node’s
view of the name. When the definition node again becomes available, you can
resynchronize the name as defined throughout the network by asking DNS to restore
the name with the RESTORE command. For more information about the COPY and
RESTORE commands, see “Updating Definitions on Unavailable Nodes” in Section 3
and the command descriptions in Section 7.
Since the information in a DNS database is always node-specific, you should not
attempt to replicate the database using the Remote Duplicate Database Facility (RDF)
or similar products.
Another factor to consider in planning distribution is that only the definitions of
aliases, groups, and composites can be replicated.
DNS need not be available when your system is cold loaded. Therefore, you can
deploy the DNS name manager process pair (default name of $ZDNS) on any two
processors you want. Furthermore, you can place the DNS database on volumes other
than $SYSTEM.
Distribution Strategy
of Network Control
Nodes
The most fault-tolerant distribution of the DNS database is to define names on the
nodes where the corresponding objects reside and to replicate them on two network
control nodes (NCNs). Operators on an NCN can still control the objects and their
names by logging on to the definition nodes remotely. If the link between an NCN
and a definition node is severed, the definition nodes can be controlled locally or from
the other NCN. Since all objects on a definition node have their names defined on that
system, all names of objects on that system are available so long as the system itself is
available. Similarly, if a remote node can communicate with a definition node, then it
has access to the names of objects defined on that definition node.
The most recommended distribution method is illustrated in Figure 5-3. In this
example, names are defined on the nodes where the objects exist and are replicated (or
partly replicated) on two NCNs. The assumption here is that the two network control
nodes (\C and \F) exert control over separate parts of the network, with some overlap
concerning node \D. If either NCN should become unavailable, the other NCN could
assume control responsibility for the disabled NCN by having names from the affected
remote nodes replicate their names to the functioning NCN. In effect, each NCN acts
as a backup for the other. Furthermore, if the link between an NCN and a definition
node is severed, the definition node could be controlled locally.