Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 Fault Tolerance and Load Balancing in a Rendezvous Administration Domain : Overview

Overview
TIBCO Administrator provides fault tolerance and load balancing capabilities for client applications. To allow client applications to access the same data from multiple administration servers, a primary server and one or more secondary servers can be installed. Each server should be installed on a separate machine and each machine must be part of the same administration domain.
Fault tolerance and load balancing is implemented using the TIBCO Rendezvous distributed queue protocol (RVDQ). Each logical server has a distributed queue based on the server name. The servers in a distributed queue group share the same server name. The TIBCO Administrator client just sees one logical server.
Primary and secondary administration servers can be configured in one of these ways:
When a client application writes to the application or domain repository (for file-based domains), the primary administration server propagates the changes to the secondary administration servers. If the primary server goes down, clients continue to receive data from the secondary server.
While all update requests are handled by the primary administration server, read requests are shared among the primary and secondary servers by use of RVDQ. Updates will automatically propagate from the primary to the secondary servers. You can have any number of secondary servers.
Note that this is not full fault tolerance.
However, if you are using file storage, there is a small time gap between when the primary receives an update and when it is propagated to the secondary servers, so converting a secondary to a primary for short downtimes is not recommended, and definitely not to deal with network partitions. The most reliable configuration is to have your data stored in a fault tolerant, distributed database that is shared by all servers.
Multiple Secondary Administration Servers
If you install one or more secondary administration servers to run in a fault-tolerant mode, each client request for project information in the administration domain is load-balanced across all administration servers, even if the primary administration server is down.
If multiple secondary administration servers are used:
If you make updates to the configuration using either the TIBCO Domain Utility (recommended) or by editing the tibcoadmin_domain-name.tra files, you must restart the administration server on each machine so the changes take effect.
For example, if a TIBCO BusinessWorks process uses Rendezvous to make a request to a primary administration server and that server fails, the process request will automatically go to the secondary administration server.
For example, if a TIBCO BusinessWorks process uses HTTP or HTTPS to communicate with TIBCO Administrator, when the primary administration server is unavailable, the process will be unable to communicate with the secondary server as it has different IP or hostname. In this case, the tibco.repourl property in the BusinessWorks process .tra file must be changed to point to the secondary server machine’s IP address or hostname.
Alternatively an external IP redirector can be used to redirect the primary machine’s IP address or hostname to the secondary machine. See your IP Redirector or HTTP server documentation for information on how to do this.
Secondary Administration Server Startup Fails
When setting up a primary and a secondary administration server, if startup of the secondary server fails because it cannot get its initial data, a stack trace message starting with the following appears in the secondary server's console and log file:
 
java.lang.Exception: Load security program error:null
To resolve this, verify that the time zone settings on the machines that host the primary and secondary servers are in sync.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved