This chapter covers specific features that are new to IBM PowerHA SystemMirror for IBM AIX for Version 7.2 and Version 7.2.1.

This chapter covers the following topic:

Starting with of PowerHA V7.2, there is an additional management option to start the cluster. The new argument for the option manage is named delayed.

Here is the syntax of the new option:

Starting with PowerHA V7.1.0, the Start After and the Stop After dependencies are added. The Start After is used often. The Resource Group (RG) dependencies support up to three levels. Figure 11-1 shows a proposed setup that cannot be configured. If you encounter such a case, you must find another solution. In this example, RG1 is at level 1, RG2 is at level 2, RG3 and RG4 are at level 3, and RG5 and RG6 are at level 4.

A supported setup example is shown in Figure 11-2. It has the same number of RGs, but it is using three dependency levels. The challenges that you can get with such request are described in 11.1.2, “Use case for using manage=delayed” on page 405.

When you have multiple RGs with a similar dependency as the one that is shown in Figure 11-2, there is a challenge when the cluster is started. This section describes this behavior in more details.

When starting the cluster in one go, for example, by using clmgr on cluster, then one of the two nodes always is the first one. In fact, it does not matter if you use clmgr or smitty. The sequence can be different, but that is the only difference.

The following section illustrates an example and does not describe the exact internal behavior. It is a description of what you can experience. Assume that Node A is the first one. Then, you get the startup situation that is shown illustrated in Figure 11-3:

The startup takes longer than expected. Depending on your timeout settings, the start can have a significant time delay.

This behavior happens due to the fact that the first cluster manager does not see the partner at its initialization. This situation always happens even if there is a small time delay. Therefore, the second cluster manager must wait until all RGs are processed by the first cluster manager.

A solution might be to change all the RGs to start on the first available node. The Start After settings are still the same as shown in Figure 11-2 on page 405. The assumption is that you still use the command clmgr on cluster command.

As shown in Figure 11-4, the start sequence is as defined in the Start After dependencies. But, now all RGs are running on Node A, which is not the outcome that you want.

In the past, the only way to correct this situation was to use the manual option. For the example here, start with the original settings that are described in “Starting the entire cluster with the default settings” on page 405. Run the clmgr on cluster manage=manual. This command starts both cluster managers but not the RG.

Now, the cluster managers are running in a stable state, as shown in Figure 11-5. You can start all your RGs by using the clmgr command.