HP OpenVMS Systems Documentation

BIND Version 9 does not allow you to disable round-robin scheduling.

7.3 Load Broker Concepts

TCP/IP Services provides a configurable, calculated, load-balancing mechanism called the load broker for distributing the load across systems in a DNS cluster.

Unlike round-robin scheduling (the default method used by most DNS name servers), the load broker takes into account the load on all DNS cluster participants. The load broker polls DNS cluster members and updates the DNS namespace accordingly.

7.3.1 How the Load Broker Works

When the load broker starts, it reads its configuration file and starts polling DNS cluster members. The load broker exchanges messages with DNS cluster members that run the metric server. The metric server ( Section 7.3.3) calculates the current rating and reports it when polled by the load broker. Periodically, the load broker sorts the list of addresses based on metric rating reports, drops the systems that are not responding after being polled three times, and takes a subset of the list and compares it to the name server information. To do the comparison, the load broker sends a host lookup request to the specified name server. If the lists are the same, the load broker does not make any change. If the lists are different, the load broker updates the name server data by sending a dynamic update request to the specified name server.

The name server uses round-robin scheduling to further balance the load across the members of a DNS cluster. So every consecutive request for translating the DNS cluster name results in a list being returned, rotated by one.

The dns-ttl value stored in the load broker configuration file governs how long the record is to be cached by other name servers. If some intermediate name server caches the "A" resource records for a given DNS cluster name, it caches it for the period of time defined by the dns-ttl value. The default dns-ttl value is 45 seconds. If less time is required, you can set dns-ttl to a smaller value. To suppress any caching, you can set the dns-ttl to 0.

The dns-refresh time specifies how often the DNS information for a given DNS cluster is refreshed. The default is 30 seconds. If you want to quickly pick up changes in the system load (reported by metric servers), set dns-refresh to a smaller number.

If the load broker has not received a response from a metric server after three polling intervals, the load broker marks the address for removal from the DNS alias. This removal will occur at the next dns-refresh interval.

For earliest possible detection of this failure, the polling-interval should be set to a value that is less than one-third of the value specified as the dns-refresh period.

       polling-interval  < (dns-refresh) / 3

The masters list specifies the authoritative name servers to which queries will be sent. Only one name server at a time is sent a query. A query is sent to the first name server specified. If that name server does not respond to the query, then the query is sent to the next name server specified. This process continues until either a name server responds or the list is exhausted. Note that the name servers specified in the masters statement are not necessarily the servers that will be sent dynamic updates.

Queries are sent for the following reasons:

• A query for A resource records is sent to the name server to obtain the list of addresses associated with the load broker cluster name that is to be updated. The load broker can then perform its comparison to determine whether any updates need to be made.
• A query for the SOA resource record is sent to the name server so that the load broker can determine the primary master name server for the zone. The primary master name server is then sorted to the top of the name server list that will be sent dynamic update requests.
• A query for NS resource records is sent to the name server to retrieve the list of name servers that will receive dynamic updates. Dynamic updates are sent to only one server at a time. A dynamic update is sent to the first server on the list. If that name server does not respond, or rejects the dynamic update, then the dynamic update is sent to the next server on the list. This process continues until either the dynamic update is accepted by the name server or the name server list is exhausted.

The name server must be set up to allow dynamic updates from the system that runs the load broker. For information about configuring dynamic updates, see Section 6.5.7.

TCP/IP Services supports dynamic updating of only one master server in a DNS cluster environment.

7.3.2 Managing the Load Broker in an OpenVMS Cluster

By default, you can run the load broker on multiple systems in an OpenVMS Cluster. This is accomplished through a locking mechanism. The first load broker process to start in the cluster obtains the lock. Any load broker processes started afterward go into a standby state and wait for the lock to be released. If the system running the first load broker process goes down, the load broker process releases the lock, allowing the next available standby load broker process to obtain the lock. This system then runs the active load broker process; additional servers remain on standby.

To disable the clusterwide load broker locking mechanism, enter the following command:

$ DEFINE /SYSTEM TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS 1

The metric server calculates the current load on a DNS cluster host by using the following equation:

         rating = availablity + workload - penalty

In the equation, the variables are calculated by:

• Availability
  Availability is calculated using the IJOBLIM system parameters and the SDA global reference variable IJOBCNT in the following equation:

  availablity = (20*(IJOBLIM-IJOBCNT))/IJOBLIM

• Workload
  One consideration in the work load calculation is the system manager's estimate of the host's relative CPU power specified by the system logical TCPIP$METRIC_CPU_RATING.
  To set a CPU power value, use the DCL command DEFINE to define the system logical name TCPIP$METRIC_CPU_RATING with a value. The CPU rating value can range from 1 (the lowest CPU power) to 100 (the highest CPU power). If a value is specified, the value is used instead of the term (min(235,IJOBLIM) in the following equation.

  workload = (min(235,IJOBLIM)*100)/(100+load_average)

  
  When you set the logical value to 0, or if you do not define TCPIP$METRIC_CPU_RATING, the metric server uses the value of the system parameter IJOBLIM to calculate work load.
  load_average is an average of the current CPU load taken every second. It is calculated by using 97.9% of the previous CPU load and 2.1% of the current CPU load value.
• Penalty
  The metric server uses the FREEGOAL system parameter and the SDA global reference variable FREECNT to calculate an available memory penalty.

  penalty = 40*((FREEGOAL+2048-FREECNT)/(FREEGOAL+2048))

  
  The value of penalty is subtracted from the rating only if the value is positive. If the value of FREECNT is high enough, the value of penalty is not applied.

The load broker can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$LBROKER_STARTUP.COM allows you to start up the load broker service.
• SYS$STARTUP:TCPIP$LBROKER_SHUTDOWN.COM allows you to shut down the load broker service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$LBROKER_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the load broker is started.
• SYS$STARTUP:TCPIP$LBROKER_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the load broker is shut down.

To configure the load broker, edit the file TCPIP$LBROKER_CONF.TEMPLATE located in SYS$SYSDEVICE:[TCPIP$LD_BKR], then rename the file to TCPIP$LBROKER.CONF.

After making changes to TCPIP$LBROKER.CONF, restart the load broker by running TCPIP$CONFIG, or by using the shutdown and startup procedures.

The load broker configuration file can contain one or more DNS cluster statements in the following format:

cluster "clustername.domain.com"
{

 [dns-ttl nn;]
 [dns-refresh nn;]
 masters {ip_address};
 [polling-interval nn;]
 [max-members nn;]
 members {ip_address};
 failover {ip_address};
};

Table 7-1 describes the valid cluster statements.

The following sample is a configuration of the load broker that load balances the DNS cluster named WWW.TCPIP.ERN.SEA.COM.

cluster "www.tcpip.ern.sea.com"
{
        dns-ttl                 45;
        dns-refresh             30;
        masters {
                 9.20.208.53;
        };
        polling-interval         9;
        max-members              3;
        members {
                9.20.208.100;
                9.20.208.53;
                9.20.208.54;
                9.20.208.80;
                9.20.208.129;
                9.20.208.130;
        };
        failover 9.20.208.200;
};

To retain your UCX Version 4.x DNS cluster load-balancing configuration:

1. Enter the CONVERT/CONFIGURATION BIND/CLUSTER command, as shown in the following example:

   TCPIP> CONVERT/CONFIGURATION BIND - _TCPIP> /CLUSTER=SYS$SYSDEVICE:[TCPIP$LD_BKR]TCPIP$LBROKER.CONF

   
   The output from this command is a TCPIP$LBROKER.CONF file containing your basic configuration.
2. Edit the TCPIP$LBROKER.CONF file to produce a complete configuration file.

To enable DNS cluster load balancing, complete the following tasks:

1. Ensure that all hosts in the DNS cluster are running TCP/IP Services.
2. Configure the load broker (see Section 7.5).
3. Configure the primary master name server that is authoritative for the zone containing the DNS cluster resource record to allow dynamic updates from the host on which the load broker is running. For information about configuring dynamic updates, see Section 6.5.7.
   You can also configure the master name server with the allow-update-forwarding option, so that slave servers that are sent dynamic updates will forward them to the master name server. For more information, see Table 6-20.
4. Ensure TCP/IP connectivity between the DNS cluster members and the load broker.
5. Enable the metric server on each member of the DNS cluster:
   1. Run the following command procedure:

      $ @SYS$MANAGER:TCPIP$CONFIG

   2. On the TCPIP$CONFIG Server Components Configuration menu, select option 8:

      8 -- METRIC.

   3. On the Metric configuration display, select option 2:

      2 -- Start service on this node.

Review the following guidelines:

• DNS cluster hosts and clients are not required to be on the same bridged LAN.
• The number of DNS cluster member hosts is limited to 32.
• A BIND name server can also be a DNS cluster member host.
• The authoritative name server can run any BIND name server that supports BIND 8.1.1 or later or that supports dynamic updates.

Table 7-2 describes the load broker's logical names. Define these logical names with the /SYSTEM qualifier, and restart the load broker server to make the changes take effect.

$ DEFINE /SYSTEM TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS 1

Table 7-3 describes the metric server's logical names. Define these logical names with the /SYSTEM qualifier. The metric server detects the change and dynamically updates the current enviroment.

The metric server starts up automatically at system startup time if the service was previously enabled and can be shut down and started independently.

The following files are provided:

• SYS$STARTUP:TCPIP$METRIC_STARTUP.COM allows you to start up the metric service.
• SYS$STARTUP:TCPIP$METRIC_SHUTDOWN.COM allows you to shut down the metric service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$METRIC_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the metric service is started.
• SYS$STARTUP:TCPIP$METRIC_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the metric service is shut down.

TCP/IP Services provides the following tools to assist in solving load broker problems:

• The metricview utility, to display metric information regarding DNS cluster members.
• Diagnostic log files.

The metricview utility is used to read the metric ratings. It displays the metric rating of the member hosts in the TCP/IP DNS cluster.

To run the metricview utility, enter the following commands:

$ @SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM
$ metricview
Host                                                    Rating
----                                                    ------
10.10.2.11      rufus.lkg.dec.com                         47
10.10.2.255     peach.lkg.dec.com                         51

If you define the logical name TCPIP$METRIC_LOG_LEVEL, the metric server writes diagnostic messages to the TCPIP$METRIC_RUN.LOG file. If you experience problems with the metric server, define TCPIP$METRIC_LOG_LEVEL and, after a period of operation, review the messages in the TCPIP$METRIC_RUN.LOG file for an indication of what the problem could be. See Section 7.5.3 for a description of the logical name.