(dist)(iseries)Configure SIP quorum support using the default core group
We can configure quorum to avoid inconsistency among Session Initiation Protocol (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 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.
Avoid trouble: 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, you should configure your system to minimize evenly split partitions. Create a set of three groupings: three data centers, three blade centers, and three groupings of cluster members.gotcha
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 the 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 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.
- In the console, click...
Servers > Core Groups > Core group settings > core_group_name
- Click Policies > New.
- Select All active policy, and then click Next
- Specify a unique name for the policy in the Name field, and then enter a description in the Description field.
- Select Quorum, and then click 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 the policy in the navigation breadcrumb on this 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 you 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 the policy in the navigation breadcrumb on this 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 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, you 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, you must restart all of the members of that cluster.
- Repeat these steps if you 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 to enable SIP quorum, but you 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.
Results
The majority of the members that are 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 concepts
High availability group policies High availability group policy selection process High availability group policy modification guidelines Implications of high availability group policy settings
Related tasks
Browse all SIP topics
SIP proxy server custom properties