HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

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 

7.3.3 How the Metric Server Calculates Load

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


 
         rating = availability + workload - penalty 
 

In the equation, the variables are calculated by:

7.4 Load Broker Startup and Shutdown

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:

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

7.5 Configuring the Load Broker

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}; 
 [ keys { string; [ string; [...]] }; ] 
 
}; 
 

Table 7-1 describes the valid cluster statements.

Table 7-1 Valid Cluster Statements
Statement Description
members Specifies the IP address for each DNS cluster member.
failover Specifies the address of the host to use if all other members are down.
masters Specifies the IP addresses of authoritative name servers.
dns-ttl Specifies the time to live for a given record. The value you provide governs how long the record is to be cached by other name servers. If some intermediate name servers cache A resource records for a given DNS cluster name, they cache it for the period specified by dns-ttl for the resource record. The default value is 45 seconds.
dns-refresh Specifies how often the DNS information for a given DNS cluster name is refreshed. The default is 30 seconds. The minimum is 10 seconds. The value of this field should be set relative to to the value of polling-interval . The dns-refresh value should be smaller than the polling-interval value. It is unproductive to refresh more often then you poll.
polling-interval Specifies the length of time between polls to cluster members. The default is 30 seconds. The minimum is 5 seconds.
keys Specifies a key_id defined by the key ("key" in different font) statement, to be used for transaction security (TSIG) when talking to a remote DNS server. The key statement must come before the cluster statement that references it. When a request is sent to the remote server, a request signature is generated using the key specified here and appended to the message.
max-members Specifies the maximum number of IP addresses to be returned to the name server in each dynamic update. For effective load balancing, this number should be between one-third and one-half the number of participating DNS cluster members.

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.

7.5.1 Configuring the Load Broker with TSIG

This section describes how to set up Transaction Signatures (TSIG) security in the Load Broker. TSIG provides authentication and data integrity between the Load Broker and the DNS server. To use TSIG, configuration must occur on the Load Broker and on the DNS server. For more information on configuring the BIND/DNS server ee Section 6.2.3.

TSIG requires the definition of a key in the Load Broker configuration file TCPIP$LBROKER.CONF. The following example shows the format of the key statement:


key key_id { 
    algorithm algorithm-id; 
    secret secret-string; 
}; 
Table 6-4 describes the elements of the key statement.

Table 7-2 Key Statement Elements
Element Description
key_id Specifies a domain name that uniquely identifies the key (also known as the key name). It can be used in a cluster statement to cause requests sent to the DNS server to be signed with this key.
algorithm-id Specifies an authentication algorithm. The only algorithm currently supported with TSIG authentication is HMAC-MD5.
secret-string Specifies the secret to be used by the algorithm; treated as a Base-64 encoded string.

7.5.1.1 Configuring the Load Broker to Use TSIG

To configure the Load Broker to use TSIG, perform the following steps:
  1. Generate the secret-string that will be used in the key statement on the Load Broker and the DNS server. The key name must be the same on both.
    Longer keys are better, but shorter keys are easier to read. The maximum key length is 512 bits. Use the dnssec-keygen utility to genereate keys automatically.
    The following command generates a 128-bit (16-byte) HMAC-MD5 key:


    $ dnssec_keygen -a hmac-md5 -b 128 -n HOST host1-host2 
    

    In this example, the key is in the files KHOST1-HOST2.157-00000_PRIVATE and KHOST1-HOST2.157-00000_KEY. Nothing uses these files directly, but the base-64 encoded string following Key: (in different font) can be extracted from either file and can be used as a shared secret. For example:


    Key: La/E5CjG9O+osljq0a2jdA== 
    

    The string La/E5CjG9O+osljq0a2jdA== can be used as the shared secret.
    Keys can also be specified manually. The shared secret is a random sequence of bits, encoded in base-64. Most ASCII strings are valid base-64 strings (assuming the length is a multiple of 4 and that only valid characters are used).

  2. Inform the Load Broker of the key's existence. Add the following to TCPIP$LBROKER.CONF:


    key host1-host2 { 
        algorithm hmac-md5; 
        secret "La/E5CjG9O+osljq0a2jdA=="; 
    }; 
    

  3. Instruct the Load Broker to use the key. Add a keys statement to the cluster (in different font) statement in TCPIP$LBROKER.CONF:


    cluster "cluster1.sample.hp.com." { 
            masters { 
                    1.2.3.4; 
            }; 
            dns-refresh        60; 
            polling-interval   30; 
            max-members     2; 
            keys { host1-host2; }; 
            members { 
                    1.2.3.5; 
                    1.2.3.6; 
                    1.2.3.7; 
            }; 
    }; 
    

    Multiple keys may be specified and used.

  4. On the DNS server that is authoritative for the zone, add a matching key statement to the configuration file. For TCP/IP Services BIND, the key will be added to TCPIP$BIND.CONF.
    Add an allow-update sub-statement to the zone statement in the BIND configuration file for the zone that the Load Broker will be updating, specifying the key name. The zone should be a "master" zone.
    See Chapter 6 for more information.
  5. Restart the Load Broker.
    The DNS server will now authenticate Dynamic Update requests from the Load Broker based on the shared key.

Note

You must enter the Key’s description before the cluster statement, as shown in the following example:


... 
# DESCRIPTION: 
# 
#   This file contains configuration information for the LBROKER  server. 
#   Before starting the LBROKER server, you must edit this file and  copy 
#   it to SYS$SYSDEVICE:[TCPIP$LD_BKR]TCPIP$LBROKER.CONF. 
# 
#   Refer  to  the  HP TCP/IP Services for OpenVMS Management  guide  for 
#   instructions on editing and using this file. 
 
key oak { 
        algorithm "hmac-md5"; 
        secret "Bj1xjGUTkzclXQ6aT/UGoA=="; 
}; 
 
cluster "timber.sqa.tcpip.zko.hp.com." 
{ 
  masters { 
        16.116.93.66; 
  }; 
  dns-ttl               43200; 
  dns-refresh           30; 
  polling-interval       5; 
  max-members  4; 
  keys { oak; }; 
  members { 
        16.116.93.67; 
        16.116.93.68; 
        16.116.93.69; 
        16.116.93.70; 
  }; 
  failover 16.116.93.68; 
}; 

7.5.2 Enabling the Load Broker

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-22.
  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:

7.5.3 Load Broker Logical Names

Table 7-3 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.

Table 7-3 Load Broker Logical Names
Logical Name Description
TCPIP$LBROKER_LOG_LEVEL value Turns on diagnostics and writes them to the TCPIP$LBROKER_RUN.LOG located in SYS$SYSDEVICE:[TCPIP$LD_BKR]. Valid values are 1 and 2 (2 provides more detailed diagnostics).
TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS
  Turns off the clusterwide load-broker locking mechanism, allowing separate load broker processes to run on each node in the OpenVMS Cluster.

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

$ DEFINE /SYSTEM TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS 1

  When you define this logical and then start the load broker, multiple load brokers in an OpenVMS Cluster will be active. For more information, refer to Section 7.3.2.

7.5.4 Metric Server Logical Names

Table 7-4 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.

Table 7-4 Metric Server Logical Names
Logical Name Description
TCPIP$METRIC_CPU_RATING value Sets a bias value that represents your estimate of the relative CPU power. Valid values range from 1 (lowest CPU power) to 100 (highest CPU power). Use a value of 0 (zero) to specify the default (The value of the system parameter IJOBLIM is used).
TCPIP$METRIC_COMPUTE_INTERVAL value Specifies how often the metric server computes the rating. Valid value (in seconds) is a number from 1 to 300. The default is 10 seconds.
TCPIP$METRIC_LOG_LEVEL value Turns on diagnostics logged to the file TCPIP$METRIC_RUN.LOG located in SYS$SPECIFIC:[TCPIP$METRIC]. Valid values are 1 or 2 (2 provides more detailed diagnostics).

7.6 Metric Server Startup and Shutdown

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:

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

7.7 Solving Load Broker Problems

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

7.7.1 Metricview Utility

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 

Optionally, you can direct the metricview query to a specific host by including the /HOST qualifier on the command. For example:


/HOST=hostname

Only the specified host will be queried. If the host is multihomed, it will send replies out over each interface, resulting in a separate metricview display line for each interface. Note that the metric rating is calculated on a per-host basis, so the ratings will be the same for each interface of a multihomed host.

7.7.2 Viewing Diagnostic Messages

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.4 for a description of the logical name.


Previous Next Contents Index