|
HP OpenVMS Systems Documentation |
|
Compaq TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
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:
availablity = (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};
};
|
Table 6-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 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. |
| 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 16.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 |
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 6-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.
| 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). |
Table 6-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.
| 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:
Two images in the TCP/IP Services software distribution kit perform the metric functions:
The Metric View utility, SYS$COMMON:[SYSEXE]TCPIP$METRICVIEW.EXE, displays the metric rating of the member hosts in the TCP/IP DNS cluster.
To run Metric View, enter the following command:
$ RUN SYS$SYSTEM: TCPIP$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 TCPIP$METRIC_LOG_LEVEL, the METRIC server writes diagnostic messages to the TCPIP$METRIC_RUN.LOG file. If you are experiencing 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 6.5.3 for a description of the logical.
Part 3 describes how to set up and manage the Dynamic Host Configuration Protocol (DHCP), the Bootstrap Protocol (BOOTP), the Trivial File Transport Protocol (TFTP), the Portmapper service, the Network Time Protocol (NTP), and the Simple Network Management Protocol (SNMP). The chapters in this part include the following:
Dynamic Host Configuration Protocol (DHCP), a superset of the Bootstrap Protocol (BOOTP), provides a centralized approach to the configuration and maintenance of IP address space. It allows the system manager to configure various clients on a network from a single location.
DHCP allocates temporary or permanent IP addresses from an address pool to client hosts on the network. DHCP can also configure client parameters such as default gateway parameters, domain name server parameters, and subnet masks for each host running a DHCP client.
This chapter reviews key DHCP and BOOTP concepts and also describes:
With DHCP, system managers can centralize TCP/IP network configurations and management tasks involved with network connections. DHCP makes network administration easier by allowing:
In addition, the TCP/IP Services implementation of DHCP includes support for DHCP server failover in a OpenVMS Cluster environment.
The DHCP protocol is a superset of BOOTP. In addition to the BOOTP functionality, DHCP offers robust configuration services, including IP addresses, subnet masks, and default gateways.
Based on the BOOTP functionality, DHCP is built on the client/server model:
DHCP consists of two components:
DHCP operates as follows:
During the lifetime of the lease, the client repeatedly asks the server to renew. If the client chooses not to renew, the lease expires.
Once the lease expires, the IP address can be recycled and given to another client. When the client reboots, it can be given the old address if available or assigned a new address.
For more information about how DHCP operates, see RFC 2131 and RFC 1534.
7.1.2 How DHCP Allocates IP Addresses
With TCP/IP Services, DHCP uses the dynamic and static IP address-mapping methods outlined in Table 7-1 to service DHCP and BOOTP-only client requests.
| Method | Applicable Client | Description |
|---|---|---|
| Dynamic |
DHCP and
BOOTP |
The DHCP server assigns an IP address from an address pool to a client
for a specified amount of time (or until the client explicitly
relinquishes the address). Addresses no longer needed by clients can be
reused.
Use dynamic allocation when:
For BOOTP clients, DHCP assigns dynamic IP addresses from the address pool and stores the addresses in the lease database by assigning each lease a time of infinity. |
| Static |
DHCP and
BOOTP |
The system manager manually assigns (in the DHCPCAP. file) an IP
address to a client and uses DHCP to pass the assigned address to the
client.
Use static allocation in an error-prone environment where it is desirable to manage IP address assignment outside of the DHCP functionality. |
| Finite | BOOTP-only | The DHCP server assigns an IP address from the pool to the BOOTP client and defines a lease time based on certain parameters you define in the SERVER.PCY file. When the lease expires, the DHCP server pings the IP address. If the server receives a reply, it extends the lease and does not offer the address to a new client. If not, the address is free and can be assigned to a new client. |
Section 7.5 explains how to configure the different types of addressing for clients on your network.
The typical network uses a combination of static and dynamic DHCP
addressing. As the local system manager or network administrator, you
can apply any of the IP addressing methods as appropriate for your
specific policies and environment.
7.1.3 Relationship Between DHCP and BOOTP
From the client's perspective, DHCP is an extension of the BOOTP functionality. DHCP allows existing BOOTP clients to operate with DHCP servers without having to change the client's initialization software.
Based on the format of BOOTP messages, the DHCP message format does the following:
However, DHCP improves the BOOTP-only functionality in the following ways:
| Previous | Next | Contents | Index |