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.
Important: Only the Static, One of N, and No operation
policies apply for service integration and messaging engines. See
Policies for service integration for more
information.
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 WebSphere
Application Server components use the quorum mechanism. Therefore, do not
enabled the Quorum setting.