Document revision date: 15 October 2001

You can designate an Advanced Server as the network time server in a domain by having it run the TimeSource service. Client computers on the network can synchronize their time with the time server, which makes it possible to synchronize network events. For Compaq OpenVMS servers, the operating system maintains the clock, which cannot be set with Advanced Server commands. (For information about changing the time or time zone for a system, see Section 2.3.5, Changing Time Zones or Daylight Saving Time Settings.

To run the TimeSource service automatically, do one of the following:

• Edit the LANMAN.INI file to include TIMESOURCE in the SERVER section as a value for the SRVSERVICES keyword. For example, the LANMAN.INI file could contain an entry of the following form:

  [SERVER] . . . SRVSERVICES=ALERTER,NETLOGON,TIMESOURCE

  
  With this entry in place, the TimeSource service starts automatically whenever you start the server. To activate the TimeSource service after the server is running, you can use the START SERVICE TIMESOURCE command.

• Run the configuration procedure PWRK$CONFIG.COM, and answer YES to the option "Enable Timesource service."

Then the TimeSource service will start automatically whenever you start the server.

To activate the TimeSource service after the server is running, use the START SERVICE TIMESOURCE command.

2.3.5 Changing Time Zones or Daylight Saving Time Settings

To properly represent the time in your local environment, you must set up the OpenVMS time zone information before the server is started, as explained in the Compaq PATHWORKS for OpenVMS (Advanced Server) Server Installation and Configuration Guide. If your server is moved to a location in a different time zone, you must set the new time zone information accordingly. If your server system resides in an area that observes daylight saving time, the time zone information must be modified appropriately when daylight saving starts and ends.

2.3.6 Setting Up the Time Zone Information on OpenVMS Version 6.2

For OpenVMS Version 6.2, you can set up the time zone as an optional feature using SYS$MANAGER:UTC$CONFIGURE_TDF.COM, as explained in the OpenVMS System Manager's Manual. However, PATHWORKS Advanced Servers running on OpenVMS Version 6.2 do not use the values defined by UTC$CONFIGURE_TDF.COM. Instead, you must define the logicals PWRK$$TDF and PWRK$$DST before starting the server.

PWRK$$TDF defines the time differential factor (TDF). The default is -5, which works for Eastern Standard Time. The value for PWRK$$TDF must be a whole number in the range -13 to 13 hours. Seconds are not significant.

PWRK$$DST sets daylight saving time status. The default is 1, signifying that daylight saving time currently applies. Set a value of 0 when daylight saving time does not currently apply. In regions where daylight saving time is not observed, this setting can be set permanently to 0. If daylight saving time is observed in your system's time zone, you must change this logical twice a year, accordingly, and restart the server. For systems located in time zones that observe daylight saving time, the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM file can be used to adjust the system time and TDF automatically twice a year.

You define these logicals in either SYS$MANAGER:SYSTARTUP_VMS.COM or SYS$MANAGER:SYLOGICALS.COM, using the DEFINE/SYSTEM command. The following example shows the definitions for the PWRK$$TDF and PWRK$$DST logicals on a system located in San Diego, California. The TDF for this part of the United States is -8. The PWRK$$DST definition indicates that daylight saving time is currently in effect.

$ DEFINE/SYSTEM PWRK$$TDF -8 $ DEFINE/SYSTEM PWRK$$DST 1

In those states of the United States that observe daylight saving time, daylight saving time applies from the first Sunday in April to the last Sunday in October. Thus, on the last Sunday in October, the PWRK$$DST logical for the PATHWORKS Advanced Server system in San Diego must be changed to 0 (and the server restarted).

2.3.7 Setting Up the Time Zone Information on OpenVMS Version 7.x Systems

Advanced Servers running on OpenVMS Version 7.x systems implement default date/time support using the UTC standard.

You can use the OpenVMS SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM procedure to adjust the system time and TDF automatically twice a year. You check and set the time zone and time differential factor (TDF) settings on your system by running the OpenVMS command procedure UTC$TIME_SETUP.COM. (This command procedure defines the logicals needed by the Advanced Server. You do not define logicals manually for time services support, as you must on PATHWORKS Advanced Servers running on OpenVMS Version 6.2.) From the SYSTEM account, enter the following command to begin the procedure:

$ @SYS$MANAGER:UTC$TIME_SETUP.COM

When you elect to change the time zone or TDF setting, or both, the changes are also made clusterwide if your server participates in an OpenVMS Cluster.

If you change any time zone information, you must restart the server for the time to be properly represented.

For more information about running the command procedure and resetting the time zone and TDF, refer to the OpenVMS System Manager's Manual.

2.4 Advanced Server in OpenVMS Clusters

Some servers in your network may be configured in an OpenVMS Cluster environment. Advanced Servers running in an OpenVMS Cluster share the same copy of the user accounts and shares databases and assume a single role, either a primary domain controller, a backup domain controller, or a member server. They operate as a single entity identified by the Advanced Server cluster alias name.

When you change the server role on one member of an OpenVMS Cluster, the role on all cluster members running the Advanced Server is also changed accordingly.

Use the SHOW COMPUTERS command to display a list of all the nodes in the cluster with the server role. Because of the way a Windows NT Server detects the cluster, the information displayed by the Windows NT Server Manager may not reflect the cluster role information accurately when the cluster is a primary domain controller.

The following sections discuss the Advanced Server cluster alias and cluster load balancing in LANs and WANs:

• Section 2.4.1, About the Advanced Server Cluster Alias, describes the Advanced Server cluster alias.
• Section 2.4.2, Defining the Advanced Server Cluster Alias, explains how to define the Advanced Server cluster alias.
• Section 2.4.3, Cluster Load Balancing in LANs, describes how the Advanced Server cluster alias provides cluster load balancing for clients that are on the same LAN as the server.
• Section 2.4.4, Dynamic Cluster Load Balancing in WANs, describes how the Advanced Server cluster alias provides cluster load balancing for clients that are not on the same LAN as the server.

In an OpenVMS Cluster, an Advanced Server cluster alias name allows all the members of the OpenVMS Cluster that are running the Advanced Server to be addressable as a single entity.

Unlike the DECnet and TCP/IP cluster aliases, the Advanced Server cluster alias is transport independent. (The TCP/IP cluster alias is also referred to as the TCP/IP cluster impersonator name.)

Clients can access resources on the OpenVMS Cluster by connecting to the cluster using the Advanced Server cluster alias or the name of a specific Advanced Server cluster member. Make sure a static entry for the Advanced Server cluster alias is defined in each client's LMHOSTS file, or a static multihomed entry is defined in the WINS (Windows Internet Name Service) database; however, if load balancing and failover are desired for LAN or WAN environments, remove any static entries for the cluster alias from the LMHOSTS file, the local hosts file, and the WINS database to ensure that the cluster alias is resolved appropriately. Failover occurs when the node to which the client is connected becomes unavailable; the client is reconnected (using the Advanced Server alias) to the cluster member that is least loaded. For more information about load balancing, see Section 2.4.3, Cluster Load Balancing in LANs, and Section 2.4.4, Dynamic Cluster Load Balancing in WANs.

You define the Advanced Server cluster alias name when you run the PWRK$CONFIG configuration procedure. The Advanced Server cluster alias name is a NetBIOS name that is unique among domain names and server names. OpenVMS Clusters running DECnet may have a DECnet cluster alias name defined as well. The DECnet cluster alias name is used by the DECnet transport only. OpenVMS Clusters running TCP/IP may have a cluster alias defined for the purpose of providing failover for Network File System (NFS) clients. The Advanced Server cluster alias can be the same as the TCP/IP cluster alias and/or the DECnet cluster alias; however, Compaq strongly recommends that the Advanced Server cluster alias not be the same as the TCP/IP cluster alias.

During the initial configuration process (when you run PWRK$CONFIG.COM), you can accept the default Advanced Server cluster alias name (nodename_ALIAS), or you can specify a different name. For more information about the PWRK$CONFIG.COM command procedure and configuring the Advanced Server alias, refer to the Compaq PATHWORKS for OpenVMS (Advanced Server) Server Installation and Configuration Guide.

When an Advanced Server running on an OpenVMS Cluster joins a domain, a computer account by the name of the cluster alias is created in the domain security database; a separate account is not created for each cluster member running the Advanced Server.

Clients using the Advanced Server cluster alias to obtain Advanced Server services can gain the benefit of load balancing, in which the alias is resolved to the Advanced Server cluster member that has the least load. For more information about cluster load balancing, see Section 2.4.3, Cluster Load Balancing in LANs, and Section 2.4.4, Dynamic Cluster Load Balancing in WANs.

Note that when a client connects to a server using the Advanced Server cluster alias, the connection is associated with the network address of the cluster member to which the client is actually connected. Additional connections made from the same client to the Advanced Server alias are made directly to the same cluster member. Once a client is connected, no further load balancing for that client is done. When the node to which the client is connected becomes unavailable, failover is possible: the client is reconnected (using the Advanced Server alias) to the cluster member that is least loaded.

The Advanced Server cluster alias is stored in the LANMAN.INI file as keyword pwrkalias in the VMSSERVER section. For more information, see Section 7.3, Using the LANMAN.INI File.

2.4.3 Cluster Load Balancing in LANs

The Advanced Server cluster alias makes load balancing possible for clients that are on the same LAN as the server. To gain the benefits of load balancing and failover, clients must connect to the Advanced Server on the OpenVMS Cluster by using the Advanced Server cluster alias. The clients use the NetBIOS broadcast facility to request resolution of the Advanced Server cluster alias. Only one Advanced Server node in the cluster is designated to respond to the request: the Advanced Server node that is the least loaded of the servers in the cluster. The relative loads of the servers in the cluster are checked periodically, and so the node designated to respond will change from time to time.

Cluster load balancing is not available if clients using Windows Internet Name Service (WINS) to resolve the Advanced Server cluster alias have a static entry for this alias in the WINS database.

2.4.4 Dynamic Cluster Load Balancing in WANs

Dynamic cluster load balancing is available for service requests from WAN clients that are outside the server cluster's LAN. Dynamic cluster load balancing for WAN environments is provided by Compaq TCP/IP Services for OpenVMS Version 5.0A or later, and uses a Domain Name System (DNS) server to resolve the Advanced Server cluster alias name, instead of WINS or LMHOSTS.

The Advanced Server cluster alias name should be registered as a cluster name (that is, as having multiple A resource records for a single host name) at the authoritative DNS server for the TCP/IP domain to which the cluster belongs. This DNS name server must support dynamic updates (Berkeley Internet Name Domain (BIND) server, Version 8.1.1 or later).

The DNS server associates the Advanced Server cluster alias name with an ordered list of the IP addresses of all, or more typically, a subset of, associated cluster nodes that are running the Advanced Server. The order of the list is based on the relative loads of the servers in the cluster. The DNS name server returns this ordered list to any client querying for the server cluster alias name. Periodically, the cluster load balancing software dynamically updates this cluster alias entry at the DNS server, providing a new ordered list of associated IP addresses, based on the latest relative loads on the servers running in the cluster.

The Advanced Server encompasses many of the features of the OpenVMS operating system, including OpenVMS Clusters and symmetric multiprocessing. Advanced Servers in your network that are configured in an OpenVMS Cluster environment share the same copy of the domain security accounts and shares databases and assume a single role, either a PDC, BDC, or member server.

For Advanced Servers in an OpenVMS Cluster, you must define a server cluster alias so that client workstations and network nodes can address the Advanced Servers in the OpenVMS Cluster as a single entity.

Clients should connect to the Advanced Server using the Advanced Server cluster alias; the client is connected to the least-loaded server in the OpenVMS Cluster. To gain the benefits of load balancing and failover using DNS, remove any entries for the cluster alias from the LMHOSTS file and local hosts file on clients, and you might need to remove any static entries for the cluster alias from the WINS database on WINS servers that are used by clients. (If Windows 95, Windows 98, or Windows NT clients are configured to use both WINS and DNS for NetBIOS name resolution, they first query the WINS server to resolve the name.)

2.4.4.2 The Software for Dynamic Cluster Load Balancing in WANs

The Advanced Server in conjunction with TCP/IP Services for OpenVMS provides dynamic load balancing through use of the load broker. The load broker is a configurable software component that calculates the relative loads of Advanced Server cluster members so that client requests for services can be distributed appropriately among these members. For information about configuring the load broker, refer to the latest TCP/IP Services for OpenVMS documentation of cluster load balancing with BIND servers.

The load broker periodically polls the Metric Server running on the cluster members to determine the current load on each member and then compiles a list of all cluster members associated with the Advanced Server cluster alias, dropping any systems that are not responding, and ordering the list based on the relative loads. The load broker provides this list when it sends a dynamic update request to a specified DNS server. The DNS server then updates the Advanced Server cluster alias name entry in the DNS name server database.

The DNS name server uses this ordered list to answer client requests for the Advanced Server cluster alias name. In addition, to further balance the load among the server members of the cluster, the name server uses round-robin scheduling. For every consecutive request for resolving the Advanced Server cluster alias, the name server returns a new list, rotated by one (the second server in the preceding list now being the first server in the new list, and so on).

2.4.4.3 Enabling Dynamic Load Balancing Using TCP/IP Services for OpenVMS

To enable dynamic cluster load balancing for service requests from WAN clients, complete the following tasks:

• If you are using WINS to resolve NetBIOS names, you might need to remove all static entries for the cluster alias from the WINS database of all WINS servers that might be used by clients. (If Windows 95, Windows 98, or Windows NT clients are configured to use both WINS and DNS for NetBIOS name resolution, they first query the WINS server to resolve the name). WINS should still be the primary resource for resolving names.)
• If you are using LMHOSTS to resolve NetBIOS names, remove all entries for the cluster alias from the LMHOSTS file and local hosts file of all clients and servers.
• On all clients and servers, to correctly resolve the Advanced Server cluster alias and gain the benefits of cluster load balancing, enable NetBIOS name resolution using DNS.
• Ensure that all hosts in the cluster are running Compaq TCP/IP Services for OpenVMS (Compaq recommends Version 5.0A or later). On each member of the cluster that is running the Advanced Server, enable the Metric Server. The Metric Server calculates the load on the cluster member that it is running on.
• Configure the TCP/IP Services for OpenVMS load broker. When configuring the load broker, the following load broker parameters are important regarding load balancing:
  • max-members
    The max-members parameter specifies the maximum number of IP addresses to be returned to the DNS name server in each dynamic update. Be sure to set this parameter to a value that is anywhere from one-third to one-half of the number of cluster members running the Advanced Server. The load broker will then send the DNS server a list of that number of servers on the cluster that have the least loads of all the server cluster members. The DNS server uses the list to answer clients' queries in round-robin fashion. Do NOT set the parameter to the actual number of cluster members running the Advanced Server; otherwise, the load broker will send the DNS server a list of all the server cluster members --- even the most heavily loaded members --- and load balancing will not be accomplished.
  • polling-interval
    The polling-interval parameter specifies the time interval between polls to the cluster members. The default is 30 seconds.
  • dns-refresh
    The dns-refresh parameter specifies how often the DNS information for a given DNS cluster name 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. This parameter should be set in conjunction with the polling-interval parameter --- when you change one, you should most likely change the other. Though both parameters default to the same value, the value of the dns-refresh parameter should be greater than or equal to that of the polling-interval parameter. It is unproductive to refresh more often than you poll.
  
  For more information about configuring the load broker, refer to the TCP/IP Services for OpenVMS Management guide.
• Ensure TCP/IP connectivity between the cluster members and the load broker.
• At the authoritative DNS (BIND) name server for the cluster, ensure that the Advanced Server cluster alias name is NOT already registered as a cluster alias name (that is, as having multiple A resource records for a single host name). The cluster name is associated with the IP addresses of all cluster members that are running the Advanced Server. If the addresses of the cluster members are added to the DNS database, round-robin load balancing will be in effect instead of dynamic load balancing.
• Configure the authoritative DNS name server to allow dynamic updates from the host on which the load broker is running, as explained in the TCP/IP Services for OpenVMS Management guide.
• Optionally, as appropriate, configure the parameters and logical names described in the latest TCP/IP Services for OpenVMS Management guide.

Review the following guidelines:

• The server cluster alias and the TCP/IP cluster alias should be different (in many environments, this will facilitate troubleshooting problems that involve name resolution).
• Cluster hosts and clients are not required to be on the same bridged LAN.
• The number of cluster member hosts is limited to 32.
• The load broker can also be a cluster member.
• A DNS (BIND) name server can also be a cluster member host.
• The authoritative name server can be any name server that supports BIND Version 8.1.1 or later, or that supports dynamic updates.

Note the following regarding an Advanced Server BDC that needs to resolve a PDC cluster alias for dynamic DNS load balancing:

• If the BDC and the PDC are in the same DNS domain (for example, BUDGET.ACME.COM and SALES.ACME.COM), then WAN DNS dynamic load balancing will work.
• If the BDC and the PDC are not in the same DNS domain (for example, STANS_WS.BUILDING1 and SYSMGR_WS.BUILDING2), in order for WAN DNS load balancing to work, you must add entries for the domain names in the TCP/IP BIND resolver's domain search list. This assumes TCP/IP Services for OpenVMS V5.0A or later is running. If an earlier version of TCP/IP Services for OpenVMS is running, you must insert an entry for the cluster alias in the LMHOSTS file or a static entry for the cluster alias in the WINS database.

	privacy and legal statement
6556PRO_005.HTML