All of the settings that are specified for a policy affect
how the high availability manager governs a high availability group
associated with that policy. Some of the policy settings are policy
type specific, while others apply to all policy types. It is important
to understand the implications for all of the associated high availability
groups before you change the settings of an existing policy.
Implications of the Policy type setting
The
policy type determines which members of a high availability group
are automatically made active when the servers containing these members
start. You can not directly change the policy type of an existing
high availability group policy. If you need to change the policy type,
you must create a new policy with a different policy type and give
it a match criteria that makes the high availability manager select
a new policy instead of the original one to associate with the high
availability group.
Before creating a new policy with a different
policy type, you must determine which components are using the high
availability groups that are governed by the original policy and make
sure that those components support the new policy type. For example,
the service integration bus (SIB) component might require a One of
N policy for its high availability group, because it only wants one
group member active at a given time. If you change the policy that
is associated with the service integration bus high availability group
to be an All Active policy, the service integration bus high availability
support might not function properly and data corruption can occur.
You can select one of the following policy types when you
create a new policy:
- All active policy
- When this policy is selected, all of the members of the high availability
group are made active.
- M of N policy
- When this policy is selected for a high availability group with
N members, M of them are made active. The number that M represents
is configurable in the policy settings. You can use the Preferred
servers setting to designate the preference order in which members
of the high availability group are made active.
- No operation policy
- When this policy is selected, none of the high availability group
members are made active. You can use the administrative console to
manually activate specific group members.
- One of N policy
- When this policy is selected for a high availability group with
N members, only one member of the group is made active. You can use
the Preferred servers setting to designate the preference order in
which members of the high availability group are made active.
- Static policy
- When this policy is selected, only the members specified in the
Static group servers setting are made active.
Avoid trouble: Only the Static,
One of N, and No operation policies apply for service integration
and messaging engines. See the information about policies for service
integration.
gotcha
Implications of the Preferred servers setting
With
the One of N and M of N policy types, you can set up a list of preferred
servers as part of the policy settings. The preferred server list
enables an administrator to indicate a preference as to which high
availability group member is made active. If no preferred server list
is specified, any of the available high availability group members
can be selected as the member to activate. If a preferred server
list is specified, then the member to activate is selected from this
list, in order of preference. The most preferred server is the first
one on the list. The following example demonstrates how a policy uses
of the preferred server list.
Example:
A high
availability group has three members that are located on application
servers named ServerA, ServerB, and ServerC. This group is governed
by a One of N policy, under which only one of the three members can
be active at a given time. When all three members are running and
available at the time that the policy is enforced:
- If no preferred servers are specified, the high availability manager
randomly selects one of the three members and makes it active.
- If ServerB is the only server on the preferred servers list, the
high availability manager makes the member located on this server
active before either of the other two members, provided the member
located on this server is available when the policy is enforced.
- If all three of the application servers are listed on the preferred
servers list in the following order, and if all other things are equal,
the high availability manager makes the member that is located on
ServerC active:
The two other policy settings that directly affect how
the preferred server list is used are the Failback and Preferred servers
only settings.
Implications of the Failback setting
The
Failback setting is used to specify what happens to the high availability
group member on the most preferred server when it is restarted following
a failure. The affect of the Failback setting on a member is best
demonstrated with two examples.
During startup example:
A
high availability group has three members that are located on application
servers named ServerA, ServerB, and ServerC. This group is governed
by a One of N policy, under which only one of the three members can
be active at a given time. The server named ServerB is the only server
on the preferred server list. In this example, none of the servers
are started.
When ServerA starts, the One of N policy dictates
that the high availability manager makes a member active. Because
this application server is the only server running, the member on
ServerA is activated. When we start ServerB, which is the only server
on the preferred server list, one of two things happens:
- If Failback is enabled when ServerB starts, the high availability
manager deactivates the currently active member and activates the
member on ServerB, because ServerB is on the preferred server list.
- If Failback is disabled when ServerB starts, the currently active
member remains the active member.
Following a failure example:
A high availability
group has three members that are located on application servers named
ServerA, ServerB, and ServerC. This group is governed by a One of
N policy, under which only one of the three members can be active
at a given time. ServerB is the only server on the preferred server
list and is the only member that is currently active. If ServerB fails,
the high availability manager activates one of the remaining members
to replace that member. The Failback setting determines what happens
after ServerB is repaired and restarted.
- If Failback is enabled when ServerB restarts, the currently active
member is deactivated, and the member on ServerB is activated, because
ServerB is still the most preferred server
- If Failback disabled when ServerB restarts, the currently active
member remains the active member.
Implications of the Preferred servers only setting
The
Preferred Servers Only setting is used to instruct the policy to activate
members on preferred servers only. With this setting enabled, only
members running on the servers that are specified in the preferred
servers list are activated. If no preferred servers are specified,
or no preferred servers are currently available, then no members are
activated.
During startup example:
A high availability
group has three members that are located on application servers named
ServerA, ServerB, and ServerC. This group is governed by a One of
N policy, under which only one of the three members can be active
at a given time. ServerB the only server on the preferred server list.
In this example, none of the servers are started.
When ServerA
starts, the One of N policy dictates that the high availability manager
activates a member. Because ServerA is the only server running, the
member on ServerA is activated. Because it is the only server on the
preferred server list, when ServerB starts, one of two things happens:
- If Preferred servers only is enabled when ServerA or ServerC starts,
no member is activated because the high availability manager can only
activate a member that is located on a server that is on the preferred
servers list. When ServerB starts, the high availability manager activates
the member on ServerB because ServerB is on the preferred servers
list.
- If Preferred servers only is disabled when ServerA starts, the
member on ServerA is activated because any member of the group can
be the active member. When ServerB or ServerC starts, no activation
occurs because the member on ServerA is already active.
Following a failure example:
A high availability
group has three members that are located on application servers named
ServerA, ServerB, and ServerC. This group is governed by a One of
N policy, under which only one of the three members can be active
at a given time. ServerB the only server on the preferred server list.
The member located on ServerB is the active member. If ServerB fails,
one of two things happens:
- If Preferred servers only is enabled when ServerB fails, the high
availability manager can only activate another members that is located
on a server that is included on the preferred servers list. Because
ServerB is the only server on the preferred servers list, no other
member is activated.
- If Preferred servers only is disabled when ServerB fails, the
high availability manager activates one of the remaining members to
replace the member on ServerB.
Implications of the Static group servers setting
You
can specify a list of static group servers as part of the configuration
settings for a static policy type. When a high availability group
is governed by a static policy type, the static group server list
defines which group members are activated if it is possible to do
so.
Implications of the Is alive timer setting
The
Is alive timer setting controls how frequently the high availability
manager checks the health of the active group members that are governed
by a given policy. The high availability manager can detect two fundamentally
different kinds of failures:
- It can detect when an entire process stops functioning or terminates.
This type of failure detection does not depend on the value that is
specified for the Is alive timer setting.
- It can detect when a program fails. This type of failure detection
does depend on the value that is specified for the Is alive timer
setting. The value that is specified for the Is alive time setting
determines the amount of time that might pass before a processing
problem that does not cause the entire process to stop functioning
or terminate is detected.
The administrator has the ability to specify the Is alive
timer at the policy level, where it applies to all the members that
are governed by this policy, at the process level where it applies
to all members running in a particular process. The administrator
can also disable this type of failure detection at either of these
levels.
Implications of the Quorum setting
Quorum
is a mechanism that you can use to protect resources that, in the
event of a failure, are shared across members of a high availability
group. When enabled, the policy does not activate any group members
until quorum is achieved. A high availability group does not achieve
quorum until a majority of the members are running. For example,
if there are n members in a group, (n/2) + 1 servers must be online
to achieve quorum.
Quorum is an advanced function that is designed
to work with clusters, specialized component code, and a hardware
control facility. Currently, none of the high availability groups
supporting product components use the quorum mechanism. Therefore,
do not enabled the Quorum setting.