Previous | Contents | Index |
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 = availability + workload - penalty |
In the equation, the variables are calculated by:
availability = (20*(IJOBLIM-IJOBCNT))/IJOBLIM |
workload = (min(235,IJOBLIM)*100)/(100+load_average) |
penalty = 40*((FREEGOAL+2048-FREECNT)/(FREEGOAL+2048)) |
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:
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.
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:
TCPIP> CONVERT/CONFIGURATION BIND - _TCPIP> /CLUSTER=SYS$SYSDEVICE:[TCPIP$LD_BKR]TCPIP$LBROKER.CONF |
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; }; |
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:
$ dnssec_keygen -a hmac-md5 -b 128 -n HOST host1-host2 |
Key: La/E5CjG9O+osljq0a2jdA== |
key host1-host2 { algorithm hmac-md5; secret "La/E5CjG9O+osljq0a2jdA=="; }; |
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; }; }; |
You must enter the Key’s description before the cluster statement, as shown in the following example:
|
To enable DNS cluster load balancing, complete the following tasks:
$ @SYS$MANAGER:TCPIP$CONFIG |
8 -- METRIC. |
2 -- Start service on this node. |
Review the following guidelines:
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.
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. |
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.
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). |
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:
TCP/IP Services provides the following tools to assist in solving load broker problems:
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 |