Source-target group relationships
It is sometimes convenient to associate several groups with a single application, and to allow a process to be a member of multiple groups.
Such relationships are not normally tracked by Group Services, except when the source-target facility is used. To understand this facility, consider the following scenario.
If a node crashes, all of the groups with providers on that node receive a membership change proposal notification simultaneously. The notification causes each group to begin reacting independently to the membership change. However, it may be better for some applications to wait until another group has completed processing this change. Such a relationship might exist, for example, between a disk recovery subsystem and a distributed database application. If the database is on a disk on the failed node, the database application must wait for the disk recovery subsystem to recover from the node failure before it can begin its recovery.
Although it is possible to deal with such relationships using subscriptions, they are loosely synchronized and may not provide the degree of timing control that is required. Instead, the source-target facility can be used. The source-target facility allows a target group to tie itself to a source group as follows. If a failure leads to the failure of a provider in both the source and the target groups, the source group completes its membership change protocol before the target group begins its membership change protocol. Thus, the providers in the target group can run with the knowledge that the providers in the source group have already handled the failure. This knowledge is particularly useful when the recovery of the target group depends on the completion of recovery by the source group.
In the recovery scenario just described, the disk recovery subsystem is defined as the source group, and the database application is defined as the target group.
- A group defines itself as a target-group by listing a source-group name in the set of group attributes specified on the ha_gs_join subroutine by each target-group provider. A source-group is not notified that it has been sourced by any groups.
- For every node on which a target-group provider wants to run, there must
exist a source-group provider.
If there is no source-group provider on a node, a potential target-group provider is not allowed to join the target group, and no membership change is proposed. The GS client attempting to join the target-group receives an asynchronous return code that indicates that there is no source-group provider active on this node.
If there is a source-group provider on a node, a potential target-group provider is allowed to join the target-group in the normal manner, that is, by a membership change proposal to the target-group.
- There may be multiple source-group or target-group providers on a node. A source-group may have any number of target-groups. A target-group may have only one source group.
- If the last remaining source-group provider on a node leaves the source-group,
voluntarily or involuntarily, all of the target-group providers on that node
must leave the target-group. The source-group processes the leaves as a normal
membership change proposal.
Once the source-group has approved the leave protocol, a membership change is proposed to the target-group as a cast-out of the affected providers from the target-group. As a failure leave protocol, the cast-out protocol cannot be rejected. As part of the notification initiating this target-group membership change, the target-group receives the source-group's state value. If there is no target-group provider on that node, no notification is sent to the target-group providers.
The providers that are being cast out receive a notification that they have been cast out of the group. They do not otherwise participate in the cast-out protocol.
- If a target-group is running a protocol, and a source-group provider process
fails on a node that also contains a target-group provider, the source-group
runs a failure leave protocol.
In this case, only the process of the source-group provider has failed, not the node on which it is running. Because the target-group provider process still exists, the target-group protocol could continue. However, once the source-group completes its leave protocol, the target-group provider may no longer validly belong to the target-group.
As a result, the Group Services subsystem considers the target-group providers that will be cast-out as having failed during the protocol, and treats them as follows:- If the target-group's default vote is REJECT, the protocol is rejected, and the Group Services subsystem initiates a cast-out protocol.
- If the default vote is APPROVE, the protocol is approved or, if a provider votes CONTINUE, the protocol continues.
- If the protocol continues, the failed target-group providers are no longer allowed to participate. Instead, the default vote (APPROVE in this case) is registered for them for each voting phase.
Whatever the outcome of the target-group's running protocol, once it ends, the Group Services subsystem immediately initiates a cast-out protocol for the target-group.
- When a source-group leave protocol prevents the last target-group providers from invoking protocols, those providers are given a cast-out final notification and the target-group is, in effect, dissolved.
- If a node fails, rather than the last source-group provider on the node, it is handled in the same way as if the source-group provider itself had failed. The source-group completes its protocol before the target-group is notified. In this case, the target-group receives a cast-out protocol, rather than a failure leave protocol.
- If a source-group changes its state
value during protocols that do not result in a target-group cast-out , its
associated target-groups receive the committed state value. An example of
this is a state value change protocol or a voting response during any other
n-phase protocol.
The notification appears to the target-group as a source-state reflection protocol. Values specified in the group attributes of the target-group control the number of phases and a voting time limit. The target-group treats this as a normal protocol and takes whatever actions are required.
If the target-group is running a protocol when a source-group state value change is ready to be reflected, the running protocol continues normally, and the source-state reflection protocol is queued, to be initiated later when the running protocol completes.
If a subsequent source-group state value change appears, only the most recent one is reflected to the target-group, and the earlier change is simply dropped. In addition, if a cast-out is necessary, and a source-state reflection protocol is queued, the queued protocol is dropped, because the cast-out protocol reflects the most recent source-group state value.
Because a source-state reflection protocol is initiated by Group Services, it is always initiated before any pending provider-initiated protocols for the group. In addition, there is no interface for a provider to request this protocol. It is automatically initiated as a consequence of a source-group's state value change.
- As part of any cast-out protocol in a target group, it will receive in the notification the source-group's current state value.