In some situations, it is desirable for one application to control another in a parent/child relationship. Consider a scenario in which a bank teller application depends on the local network (represented by a network resource object) and a database application. This can be represented by the graph in the following figure.
Figure 1.3 Parent application with two dependencies
Assume that if the network fails in some way, or if the database fails in some way, then the parent teller application cannot complete any transactions. The lines joining the objects in the figure indicate these dependencies. From the RMS perspective, then, we would like both the network resource and the database application to be configured in similar ways: they should both act as dependent resources that must be online if the teller application is to function properly.
However, RMS does not allow any application to be directly configured as the child of another application. Instead, RMS accommodates parent/child relationships between applications by providing an intermediate controller object, which is often simply called a controller. Unlike other resource objects, a controller has no scripts or detectors. Instead, it propagates online and offline requests from the parent to the child application, and it determines its status from that of the child application.
The following figure demonstrates how RMS would represent the banking scenario with the teller application, the controller, and the database application all running on node1. For the purposes of this example and the discussions that follow, only the applications and the controller are included in the illustration; the resource object representing the network interface is not shown.
Figure 1.4 RMS representation of controlled application
Note
In accordance with the manual of the PRIMECLUSTER Products that support the operation mode of the controller objects, use the control of the applications by the controller objects.
Each controlled application requires a separate controller as a child of the parent application. Also, controllers exist only for internal RMS management purposes. There is no equivalent in the context of the real-world operating system.
Failover of controlled applications
If a child application (controlled application) becomes Offline or Faulted state, RMS switches a parent, a child, or all the dependent resources to another cluster node. The exact action depends on the controller mode (Follow or Scalable mode).
The Follow and Scalable modes are described below.
If a parent application (to control) and a child application (to be controlled) must operate in the same cluster node, set the controller to Follow mode. If the parent is switched to another node, the application set in Follow mode and all its dependent resources will be switched there too. Likewise, if the child application fails in a way that requires it to be switched to another node, then the parent application must be switched as well. The node1 in Figure 1.4 RMS representation of controlled application shows the example when the teller application tree is Online at the beginning and the controller is configured to operate in Follow mode. If either the parent or child application needs to be switched to node2 for any reason, the rest of the tree follows. The following figure illustrates the result.
Figure 1.5 Result of follow-mode switchover
Note the state of the local controller in the figure above. Like the child application, it is brought online only on the same node as the parent. Follow Local controllers can guarantee that a group of applications and their resources remain closely coupled, so they always run together on the same machine.
Note
When RMS switches an application from node1 to node2, no objects are moved within the corresponding graph. Instead, the objects in the part of the graph corresponding to node1 are first taken offline, and then the objects in the part of the graph corresponding to node2 are brought online. The sequence used by RMS in an actual configuration is crucial to high availability operation. For a more detailed discussion, see "Appendix A Preparation."
Generally speaking, scalability is the ability of the overall system to adapt to changes in resources or workload. One of the main features of RMS scalable controllers is that they allow the parent and child applications to run on separate machines. This not only provides more flexibility but it may also prevent delays or outages when resources fail in certain combinations.
In our banking scenario, for example, the teller application depends on a network and a database application. Suppose the file system on node1 fails and the database goes offline. If the database controller is operating in follow mode, RMS will attempt to switch the teller and database to node2. However, if the network on node2 is offline or faulted, the teller can't be brought online there either. This is an extreme example, but it illustrates how high loads or resource outages could severely impact a configuration that relies only on a follow controller.
Using a scalable controller can help the configuration adjust dynamically in such situations. If the network is online on node1, while the file system is online on node2, then the database can be switched independently as shown in the following figure.
Figure 1.6 Scalable mode child (controlled) application switchover
Conversely, a network outage could cause RMS to switch the teller to node2 while leaving the database online on node1, as shown in the following figure.
Figure 1.7 Scalable mode parent (controlling) application switchover
If an application can run on more than one node, RMS allows only one instance of that application to be online in the cluster. That is, an application can run on only one node at a time. However, controller objects do not have the same restriction. Note the state of the controller objects in "Figure 1.6 Scalable mode child (controlled) application switchover" and "Figure 1.7 Scalable mode parent (controlling) application switchover." For each scalable child application, an instance of its controller is online on every node where that application can run.
The follow and scalable modes are mutually exclusive: a controller for a child application can operate in either follow mode or scalable mode, but not both. The Wizard Tools ensure that each controller's configuration is self-consistent.
A parent application can have more than one child application, but the Wizard Tools require the controller type to be the same for all children. If follow mode is used, then there will be one distinct follow controller for each child. If scalable mode is used, there will be one scalable controller with multiple children. For example, suppose the teller application in the banking scenario also has an automated teller machine (ATM) controlled application. The difference between the follow graph and the scalable graph is shown in the following figure.
Figure 1.8 Controller structure with multiple children
For a more detailed discussion, see the section "2.3 Scalable controllers".
