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


Chapter 1 Concepts : Placing TIBCO Applications into a Cluster Scenarios

Placing TIBCO Applications into a Cluster Scenarios
This section presents scenarios that show how to place TIBCO applications into a cluster. You should first decide how to organize an administration domain into cluster groups. You can place your entire domain within a same cluster group, or divide your domain into multiple cluster groups. You can also keep some of the domain software outside the cluster and place only certain applications under cluster software control.
The trade-off is often manageability verses finer failover control and better computer resource usage. You should also consider how to provide high availability of external products that TIBCO products rely on, such as databases.
Note that each cluster group:
When you configure TIBCO applications to work with a cluster solution, the applications (TIBCO Runtime Agent, TIBCO Administrator, TIBCO BusinessWorks, and so on) are typically installed on each cluster group node’s local drive. The TIBCO home location must be the same on each node in the cluster group.
When you use TIBCO Domain Utility to create an administration domain for the cluster group, the TIBCO Runtime Agent domain home and the TIBCO Administrator domain home is set to the cluster group’s shared drive. The cluster group’s virtual network name or IP address is also specified.
When you deploy applications from a node in a cluster group, deployment files are written to the cluster group’s shared drive. If the domain was created with the Local Application Data option enabled, all files required for runtime are written to the shared drive.
Entire Domain in a Single Cluster Group
You can group TIBCO applications along with their related resources such as IP address, network name and shared disk into just one cluster group. One cluster group corresponds to one logical machine as defined in the administration domain.
Figure 3 shows all applications in a domain configured in a cluster group. The domain includes the TIBCO Hawk Agent, TIBCO Administrator administration server, and all managed applications in the domain. The Hawk Agent and administration server must be controlled by the cluster software. Other TIBCO applications such as the TIBCO Enterprise Message Service server could also be configured into the cluster group.
Figure 3 Applications in a Domain Configured in a Cluster Group
Scenario Benefits
A domain in one cluster group is easier to manage. Placing the entire domain in one cluster group results in just one virtual machine in the TIBCO Administrator domain. The name of the virtual machine is the network name resource of the cluster group, while the IP address of the machine is the IP address resource of the cluster group. If a network name is not configured, the virtual IP address is used as the machine name.
Scenario Risks
An entire domain in a single cluster group is easier to manage but, because a cluster group is an atomic unit for failover control, the entire domain will failover all together if one resource in the group fails.
Also, because a single cluster group is not optimized to use computer resources, all applications in a cluster group must be running from one cluster node at any given time. This means the entire TIBCO domain runs on the active cluster node, while the other cluster nodes are idle, waiting for failover.
Entire Domain Split Into Multiple Cluster Groups
A cluster group failover occurs as a single atomic group. If you do not want TIBCO Administrator and its managed applications to failover as an atomic group, you can divide the application’s service instances into different cluster groups as shown in the next diagram. You can also divide the managed applications in the domain into multiple cluster groups to get a more granular control over failover.
In this scenario, two cluster groups are possible, one with Node 1, Node 2 and shared drive 1, and another with Node 1, Node 2 and shared drive 2.
Figure 4 Dividing the Application’s Service Instances into Different Cluster Groups
If you decide to divide a domain into multiple cluster groups, make sure each cluster group owns its own shared disk, network name (optional) and IP address. In a TIBCO Administrator domain, you will see multiple virtual machines. Each machine represents a cluster group. The name of each machine is the network name resource of a cluster group, while the IP address of the machine is the IP address resource of the cluster group.
The cluster software ensures that at any one point of time the shared disk can only be accessed by the owing node of the cluster group. Other cluster nodes cannot access the shared disk even though all nodes in the cluster groups are physically connected to the shared disk.
 
Scenario Benefits
A domain divided into multiple cluster groups provides more granular control of failover and more optimized use of computer resources in a cluster environment.
For example, if you have two services A and B running in a cluster with one cluster group, both A and B must run in the same cluster group and the group must run either on machine 1 or machine 2. One machine hosts both services A and B while the other machine is idle.
If you form two cluster groups, service A can be placed in the cluster group that runs on machine 1. Service B can be placed in the cluster group 2 that runs on machine B. This allows each machine to run a service, and be a backup for the other machine. No machine is idle.
Scenario Risks
A domain divided into multiple cluster groups can be more difficult to manage. For example, not only do the resources within each cluster group have order dependencies, the cluster groups also have order dependencies. The cluster group that hosts TIBCO Administrator must be online before applications in other cluster groups that depend on TIBCO Administrator can be brought online.
Domain Not in Cluster and Services in Cluster
Figure 5 shows a scenario where the TIBCO Administrator administration server is installed on a machine that is not under cluster control. Other TIBCO applications such as the TIBCO Hawk Agent, TIBCO Enterprise Message Service server and applications managed in the domain are configured in a cluster group.
Figure 5 Domain Not in Cluster and Services in Cluster
Scenario Benefits
Only the applications that need to be managed by the cluster are under cluster control. This allows for better use of cluster resources in the event of a failover.
Scenario Risks
Applications not managed by the cluster do not have failover control. However, primary and secondary administration servers can be configured for fault tolerance.

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