Differences Between the Solstice HA 1.3 and Sun Cluster 2.x API

In Solstice HA, the hareg(1M) man page defined an explicit reconfiguration sequence, for example, that stop methods are called before start methods are called, and that when a stop method is called a start method is also eventually called.

However, the Sun Cluster 2.x implementation deviates from the Solstice HA model. Most notably, you should not rely on the overall reconfiguration sequence too much. In Sun Cluster 2.x, it is possible for the following to occur:

• When moving a logical host off of a physical host, stop_net and stop methods will be called, however, the start and start_net methods will not necessarily be called. This deviates from hareg(1M) man page.

• When moving a logical host onto a physical host, start and start_net methods are called. However, the stop_net and stop methods are not necessarily called. Again, this deviates from the hareg(1M) man page.

• Solstice HA 1.3 has the behavior that there is a single call to each method for all the logical hosts that are moving during a particular reconfiguration. For example, let us say that a physical host is mastering two logical hosts and that physical host crashes. Both of the logical hosts will need to move to the surviving physical host (consider just a two node cluster for now). In Solstice HA 1.3, the methods of each registered data service are called just once, and are passed the complete list of all the logical hosts that this physical host now masters as arguments to the method call. In Sun Cluster 2.x, the implementation of reconfiguration tends to be that logical hosts are moved one at a time. Thus, each data service will have its methods called multiple times, once for each logical host that is moving.

Working With the Differences Between Solstice HA 1.3 and Sun Cluster 2.x

This section describes some ways in which you can adjust your applications to deal with the differences in the API.

The API definition, and both of its implementations, ultimately require that a method callback be "idempotent," that is, that it can be called multiple times and that has the same effect as a single call. Pragmatically, a called back method needs to be prepared to deal with the scenario that it has no real work to do, that the work was already accomplished during some previous call to the method. Concretely, this means that the method needs to contain logic that figures out whether there is any work to do for the logical host(s) that are moving. If not, the method should just return. An example of this in shown in Chapter 2 "Sample Data Service".

These differences in the API implementations should have minimal impact given that a data service's called-back methods must deal with the basic idempotence issue anyway.