Reliable Transaction Router
System Manager's Manual
Previous Contents Index

2.4 Changing a Facility

RTR facilities can be altered either by deleting and re-creating them using the delete facility create facility commands. Alternatively, you can use the extend facility and trim facility commands.

With sufficient redundancy in a system, facility modification can be carried out with minimal interruption to the application.

Note
The RTR facility defines the nodes used by an application, and the roles (frontend, router, backend) they may assume. You do not need to change facility definitions in the event of node or link failures.

In the example in Figure 2-1, assume that the FE3 node is being removed from the FUNDS_TRANSFER facility. Since FE3 is a frontend for this facility, only the routers (TR1 and TR2) need be reconfigured. The routers can be reconfigured one after another, so that the service provided to the remaining frontends (FE1 and FE2) is not interrupted.

Example 2-3 shows the delete facility and create facility commands that are issued from node BE1 (for example), in order to achieve this reconfiguration.


Example 2-3 Reconfiguration Using Delete and Create Facility 

 % rtr
 RTR> stop rtr/node=FE3 (1)
 RTR> delete facility funds_transfer/node=TR2 (2)
 RTR> create facility funds_transfer/node=TR2 - (3)
 _RTR>                           /frontend=(FE1,FE2) -
 _RTR>                           /router=TR2 ) 
 RTR> delete facility funds_transfer/node=TR1  (4)
 RTR> create facility funds_transfer/node=TR1 - (5)
 _RTR>                           /frontend=(FE1,FE2) -
 _RTR>                           /router=TR1 )

  1. RTR is stopped on node FE3, the node being excluded from the network. In order to prevent transactions being interrupted or aborted, application processes should be stopped in an orderly manner before issuing the 'stop rtr' command. Alternatively, a stop rtr/abort command will force application processes using RTR to exit, aborting or interrupting any outstanding transactions.
  2. The facility is deleted on node TR2. Any frontends that were connected to TR2 will connect to the remaining router, node TR1.
  3. The facility is created on node TR2, excluding node FE3 from the frontend list. This facility has started when the start message appears in the RTR log.
  4. The facility is deleted from node TR1. Frontends FE1 and FE2 now connect to router TR2.
  5. The new facility is created on node TR1, again excluding node FE3 from the frontend list. The frontends now distribute their connections to the router nodes TR1 and TR2 according to the load sharing algorithm. The system is again fully operational.

In the example in Figure 2-1, assume that a new router node TR3 and new frontend FE4 are being added to the facility funds_transfer. The extended configuration is shown in Figure 2-2. This diagram shows all possible connections. The frontend connects to only one router at a time.

Figure 2-2 Extend Configuration Example

All backend nodes must be informed when router configurations are changed. Because TR3 will be a router for the FE3 and FE4 frontends, these nodes must also be informed of its presence. Likewise, TR3 must be informed about FE3 and FE4.

Example 2-4 shows the extend facility command used for this reconfiguration.


Example 2-4 Reconfiguration Using Extend Facility 

 % RTR
 RTR> start rtr /node=(TR3,FE4)  
 RTR> set environment/node= -  (1)
 _RTR> (FE1,FE2,FE3,TR1,TR2,BE1,BE2,BE3,TR3,FE4)
 
 RTR> extend facility funds_transfer -    (2)
 _RTR> /router=TR3/frontend=(FE3,FE4) -
 _RTR> /backend=(BE1,BE2,BE3) 
 
 RTR> extend facility funds_transfer -    (3)
 _RTR> /router=TR1/frontend=FE4

  1. The set environment is used to send the following command to all nodes in the facility, including the new nodes.
  2. The extend facility defines the new router TR3 and the new frontend FE4. Because the new router is also connected to the existing frontend FE3, this node must also be specified as a frontend. The new router TR3 is told about all backends with the /backend qualifier. Note that the extend facility command has been used to create new definitions on TR3 and FE4, and extend the definitions on BE1, BE2 and BE3.
  3. The extend facility command is used to extend the definitions on TR1 and FE4 in order to give FE4 a second router link.

2.5 Setting up Callout Servers

Callout servers are applications that receive a copy of every transaction passing through the node where the callout server is running.

Like any other server, callout servers have the ability to abort any transaction that they participate in. Callout servers are typically used to provide an additional security service in the network; transactions can be inspected by the callout server and aborted if they fail to meet any user-defined criteria. Callout servers can run on router or backend nodes, or both.

Assume that callout servers are to run on the router nodes (TR1 and TR2) in the example configuration shown in Figure 2-1. Example 2-5 shows the commands needed to set up callout servers on the routers.

Example 2-5 Configuration of Callout Servers 

 % rtr
 RTR> set environment/node= - 
 _RTR>    (FE1,FE2,FE3,TR1,TR2,BE1,BE2,BE3)
 
 RTR> start rtr
 
 RTR> create facility funds_transfer/frontend=(FE1,FE2,FE3) -
 _RTR>                           /router=(TR1,TR2) -
 _RTR>                           /backend=(BE1,BE2,BE3) -
 _RTR>                           /call_out=router

2.6 Router Load Balancing

Router load balancing, or intelligent re-connection of frontends to a router is possible, allowing a frontend to select the router that has least loading. The create facility and set facility commands have the /balance qualifier to control this. RTR now allows frontends to determine their router connection. The RTR version 2 implementation of load balancing treated all routers as equal and this could cause reconnection timeouts in geographically distant routers.

When used with create facility, /balance specifies that load balancing is enabled for frontend/router connections across the facility.

Use the set facility/[no]balance to switch load-balancing off and on.

The default behavior (/nobalance) is for a frontend to connect to the preferred router. Preferred routers are selected in the order specified in the create facility/router=tr1,tr2,tr3.. qualifier. Automatic failback ensures that the frontend will reconnect to the first router in the order when it becomes available. Manual balancing can be attained by specifying different router orders across the frontends.

Non load-balanced frontend connections will fail back to the preferred router when it becomes available.

Automatic load balancing institutes a router list with a random value for the frontend assigned at the time the create facility with the /balance command is issued. The frontend will sort the list of routers based on its own random order. Randomness ensures that there will be a balance of load in a configuration with a large number of frontends. Automatic failback will maintain the load distribution on the routers and failback is controlled at a limited rate so as not to overload configurations with a small number of routers.

The following points should be born in mind when using load-balancing:

2.7 RTR Privileges

RTR supports two levels of rights or privileges, rtroper and rtrinfo (on UNIX® platforms), RTR$OPERATOR and RTR$INFO (on OpenVMS) and RtrOperator and RtrInfo on Windows NT. In general, rtroper or RTR$OPERATOR is required to issue any command that affect the running of the system, and rtrinfo or RTR$INFO is required for using monitor and display commands.

Setting RTR Privileges on UNIX Systems

On UNIX machines RTR privileges are determined by the user id and group membership. For RTR users and operators, create the group rtroper and add RTR operators and users as appropriate.

The root user has all privileges need to run RTR. Users in the group rtroper also have all privileges with respect to RTR, but may not have sufficient privilege to access resources used by RTR, such as shared memory or access to RTR files.

The rtrinfo group is currently only used to allow applications to call rtr_request_info() .

Depending on your UNIX system, see the addgroup , groupadd or mkgroup commands or the System Administration documentation for details on how to add new groups to your system.

The rtrinfo group is currently only used to allow applications to call rtr_request_info() For other users, create the groups rtroper and rtrinfo Users who do not fall into the above categories, but are members of the rtrinfo group can only use RTR commands that display information (SHOW, MONITOR, call rtr_request_info, etc.).

If the groups rtroper and rtrinfo are not defined, then all users automatically belongs to them. This means that there is no system management required for systems that do not need privilege checking.

Setting RTR Privileges on OpenVMS Systems

Create the Rights Identifiers RTR$OPERATOR and RTR$INFO if they do not already exist on your system, and assign them to users as appropriate. The RTR System Manager must have the RTR$OPERATOR identifier or the OPER privilege.

Setting RTR Privileges on Windows NT Systems

Administrator privileges are needed for RtrOperator rights by the RTR System Manager.

2.8 RTR ACP Virtual Memory Sizing

In addition to basic memory requirements of an unconfigured RTR ACP of approximately 5.8 Mbytes, additional memory requirements may be required according to the operating system environment that the RTR ACP process is using.

Compaq strongly recommends that you allocate as much virtual memory as possible. While there is no penalty for allocating more virtual memory than is used, the result of allocating too little can be catastrophic.

2.8.1 OpenVMS Virtual Memory Sizing

On OpenVMS the following allowances for additional virtual memory should be made:

It is also necessary to prepare for the number of active transactions in the system. Unless the client applications are programmed to initiate multiple concurrent transactions this number will not exceed the total number of client channels in the system. This should be verified with the application provider.

In addition it is necessary to determine the size of the transaction messages in use:

  1. For each front end:
  2. For each transaction router:
  3. For each back end:

The total of all the contributions listed will yield an estimate of the likely virtual memory requirements of the RTR ACP. A generous additional safety factor should be applied as a final element to the total of virtual memory sizing. It is better to grant the RTR ACP resource limits exceeding its real requirements than to risk loss of service in a production environment as a result of insufficient resource allocation. The total result should be divided by the virtual memory size in pages to obtain the final virtual memory requirement. Process memory and page file quotas should be set to accommodate as least this much memory.

Process quotas are controlled by qualifiers to the START RTR command. START RTR accepts both links and application processes as qualifiers which can be used to specify the expected number of links and application processes in the configuration. The values supplied are used to calculate reasonable and safe minimum values for the following RTR ACP process quotas:

Both /LINKS and /PROCESSES have high default values:

Use of /LINK and /PROCESSES do not take into account memory requirements for transactions. If an application passes a large amount of data from client to server or vice-versa this should be included in the sizing calculations. For further information on the START RTR qualifiers see the START RTR command in the Command Reference section.

Once the requirements have been determined for the START RTR qualifiers of /PGFLQUOTA or /LINK and /PROCESSES then RTR should be started with these qualifiers set to ensure the appropriate virtual memory quotas are set.

Note
The AUTHORIZE utility of OpenVMS does not play a role in the determination of RTR ACP quotas. RTR uses AUTHORIZE quotas for the command line interface and communication server, COMSERV. Virtual memory sizing for the RTR ACP are determined through the qualifiers of the START RTR command.

2.8.2 UNIX Virtual Memory Sizing

The RTR ACP process requires the operator to size the process limits for the ACP before starting RTR on all platforms. No direct control of the process quotas of the RTR ACP is offered for UNIX based platforms but log file entries will result if hard limits are found to be less than the preferred values for the RTR ACP.

The following are the minimum limits for the ACP on the following UNIX platforms:

The START RTR qualifiers /LINK and /PROCESSES apply only to the OpenVMS platform and the determination of process quotas on UNIX platforms must be done through operating system handling of virtual memory sizing.

2.9 Network Transports

RTR supports multiple network transports with a default behaviour as follows:

If an attempt to create a network connection to a remote node fails, RTR retries the connection attempt using an alternate transport protocol if one is available. The order in which the supported transport protocols are used depends on the host operating system:

If a connection attempt fails on all available protocols, the connect fails and is retried at a later time starting again with the first transport protocol.

If an established link fails, RTR automatically initiates a reconnection of the link, starting with the first transport protocol for the platform, regardless of the transport employed when the link failed.

2.9.1 Specifying the Link Transport Protocol

It is possible to override the protocol failover mechanism by specifying the transport protocol to be employed for a link by naming links to include a transport selecting prefix. Prefixing links names with "tcp." and "dna." specifies TCP/IP or DECnet as the required transports respectively. Use of these prefixes causes the local node to employ only the specified transport protocol when attempting a connection on the link to which the prefix has been applied. Note that use of a protocol prefix on one node does not prevent a remote node from connecting using some other transport.

For example, to specify the facility "FAX1" that only uses the DECnet transport, two routers ("DNET1" and "DNET2"), two backends ("SRV1" and "SRV2") and many frontends, use the following command:- 


RTR> create facility FAX1 /frontend=(dna.FE1,dna.FE2,dna.FE3 ....) 
    /router=(dna.DNET1,dna.DNET2) 
    /backend=(dna.SRV1,dna.SRV2)

Creating a facility that uses only TCP/IP would use a command like this:- 


RTR> create facility FINANCE /frontend=(tcp.client1,tcp.client2,tcp.client7 ....) 
    /router=(tcp.routr1,tcp.routr2) 
    /backend=(tcp.srv1,tcp.srv2)

2.9.2 Using RTR with DHCP and Internet Tunnels

When using RTR with DHCP or an Internet tunnel, a nodename may not be fully known; special naming techniques are provided for these conditions.

Anonymous Clients

RTR allows the use of wild cards when specifying the frontends that a router is permitted to accept connections from (that is, in the facility definition on the router). Valid wild card characters are "*", "%" and "?". The result of using a wild card character at facility configuration time is the creation of a template link.

When operating RTR in conjunction with the Compaq Internet Personal Tunnel, a client system outside of the corporate firewall uses tunnel software to obtain a secure channel from the Internet to inside the corporate domain. The tunnel client is assigned an address by the tunnel server from a pool when the tunnel software starts up.

When an RTR router receives a connection request from RTR running on this client, the source of the address is the address assigned by the tunnel server. There is no longer a fixed relationship between the client and its address. The method of configuring the router to accept such a connection is to define the frontends nodes with all the possible addresses that the tunnel server can assign to tunnel clients; you can do this with wildcards. For example, 


       RTR> create facility . . ./frontend=*.pool.places.dec.com

This command enables all nodes connecting through the tunnel to connect as frontends. The anonymous client feature may also be used with frontends that are using DHCP for TCP/IP address assignment.

Using the Tunnel Prefix

By using the node name prefix "tunnel.", it is possible to configure RTR to accept a network connection from a particular remote node even if it is connecting via a Internet tunnel using an unknown pseudoadapter address. This method allows stricter access control than the anonymous client feature where wild cards may be used when specifying a remote node name. For example, on the router node behind a firewall, the facility definition could include: 


RTR> create facility . . ./router=router.rtr.dec.com - 
    /frontend=tunnel.client.rtr.dec.com

The definition on the frontend could be 


RTR> create facility /router=router.rtr.dec.com - 
    /frontend=client.rtr.dec.com

Troubleshooting Tunnel and Wildcard Connections

To assist in diagnosing connect acceptance problems, use the monitor picture ACCFAIL. This picture displays the recent history of those links from which the local node has refused to accept connections. It displays the failed link name as provided by the network transport, and can assist in rapidly identifying any problems.

TCP Services File

Previous Next Contents Index