Configure SIP quorum support using the default core group
We can configure quorum to avoid inconsistency among SIP containers, or repeated errors from a proxy server. If quorum is enabled before a network partition occurs, the correct routing decisions can be made. A network partition can occur when a set of SIP containers are disconnected from the network and then reconnected.
Determine whether we want to configure the quorum feature for an entire core group, or for specific clusters within a core group. The topic Implications of high availability group policy settings provides additional information about quorum functionality.
All SIP containers publish a set of unique identifiers (IDs) to the SIP proxy server. Each ID represents a set of SIP sessions. The SIP proxy server is able to make the correct routing decisions based on the one-to-one mapping of these IDs to the SIP containers.
A network partition occurs whenever a network device within the topology of the cell fails. As a result, some portion, or partition, of the cell disconnects from the other portion, or partition.
If a network partition evenly splits the cluster members, half of the cluster members are arbitrarily selected to be in the quorum. This split might cause a restart of the partition while it is still connected to clients. Therefore, we should configure the system to minimize evenly split partitions. We should create a set of three groupings: three data centers, three blade centers, and three groupings of cluster members.
Whenever network connectivity is interrupted, a backup SIP container takes ownership of all IDs that were managed by the disconnected SIP container. The backup container then publishes ownership of these IDs to the SIP proxy server so that the proxy server can make the correct routing decisions.
When the network connection for the primary container is restored, the primary container begins publishing ID ownership to the SIP proxy server to indicate that it owns the same IDs as the backup container. If the SIP proxy server has two destinations for each ID, it is impossible for the SIP proxy server to consistently make the correct routing decisions. To avoid this problem, configure the SIP quorum feature for our proxy servers before a network partition occurs.
The SIP quorum feature can be enabled for an entire core group, such as DefaultCoreGroup, or for specific clusters within a core group. When the quorum feature is enabled on the Default SIP Quorum core group policy for a core group, the feature is enabled for all clusters in the core group. If the SIP quorum feature is only enabled for some of the clusters in a core group, then we must modify the default policy, and create a duplicate core group policy setting to enable quorum support for those clusters.
We must enable the Default SIP Quorum core group policy, or configure a duplicate core group policy with quorum enabled for each core group that requires quorum support. The purpose of the high availability group that uses the core group policy is to track quorum between the SIP containers, or SIP proxy servers, in a cluster.
Complete these steps to configure the quorum feature using an additional SIP quorum core group policy.
Only one cluster name can be applied to a policy. Repeat this procedure for each cluster that requires the SIP quorum feature to create a new policy with the appropriate match criteria. Each SIP quorum policy should have at the most three match criteria.
Tasks
- In the administrative console, click...
- Servers > Core Groups > Core group settings > core_group_name
- Click Policies > New.
- Select All active policy> Next
- Specify a unique name for the policy in the Name field, and then enter a description in the Description field.
- Select Quorum> OK. You will receive a warning message that indicates that define at least one match criteria for this policy.
- In the Additional Properties section, click Match criteria > New.
- Specify policy in the Name field, and AllActiveQuorumPolicy in the Value field. Both of these fields are case sensitive, and both values must be entered as shown in this step.
- Click Apply.
- Click the name of our policy in the navigation breadcrumb on this administrative console page, and then, in the Additional Properties section, click Match criteria > New again.
- This time, specify type in the Name field, and SIP_QUORUM in the Value field. As previously mentioned, both of these fields are case sensitive, and both values must be entered as shown in this step.
- Click Apply.
- Perform the following actions if we only want this new
policy to apply to a specific cluster within the core group. Skip
this step if we want this new policy to apply for the entire core
group.
- Click the name of our policy in the navigation breadcrumb on this administrative console page, and then, in the Additional Properties section, click Match criteria > New again.
- This time, specify IBM_hc in the Name field, and the name of a cluster, to which we want to apply this policy, in the Value field. Both of these fields are case sensitive. Therefore, make sure that you enter the cluster name exactly as it is defined in the core group.
- Click Apply.
- Click Save to save the configuration changes.
- Restart the affected servers.
If the new SIP quorum core group policy applies to the entire core group, we must restart every server that is part of that core group.
If the new SIP quorum core group policy only applies to a specific cluster within the core group, we must restart all of the members of that cluster.
- Repeat these steps if we are
only enabling SIP quorum
for specific clusters in the core group.
Only one cluster name can be associated with a policy. If we have multiple clusters in this core group, for which we want to enable SIP quorum, but we are not enabling SIP quorum for the entire core group, create an entirely new policy for each cluster for which we are enabling SIP quorum. For each new policy, specify the three match criterias type=SIP_QUORUM, policy=AllActiveQuorumPolicy, and IBM_hc=cluster_name.
The majority of the members included in a SIP container or a proxy server cluster must be started before quorum is achieved. The members of a proxy server cluster do not start to listen for SIP requests until quorum is achieved.
When a SIP proxy server is disconnected from the network, a SIP proxy server in the minority partition of the cell continues to handle SIP requests. The minority partition of a cell is the partition that has connectivity to the fewest cluster members.
When a SIP container is disconnected from the network, the SIP container in the minority partition is automatically restarted to clear all information about the logical partitions that were previously managed. The SIP containers in the majority partition take ownership of the logical partitions from the disconnected SIP container and publish these IDs to the SIP proxy servers.
Related: