Create a new core group

 

+

Search Tips   |   Advanced Search

 

Before you begin

Before creating a new core group, determine which application server processes to add to the core group. For example, if you are creating a new core group because a firewall is used to separate your proxy environment from your application server environment, you might leave the deployment manager, the node agent, and some of the other Application Server processes in the default core group, and move the server processes that exist on the other side of a firewall to the new core group after you create it.

 

Overview

You might want to perform this task if:

  • A firewall is used to separate your proxy environment from your application server environment. (Additional core groups are required to provide proper failover support in this topology.)

  • The number of open TCP/IP sockets becomes unacceptable. (This could occur if you are using a multicast protocol.)

Every WebSphere process is initially a member of the default core group provided with the WAS product. Using the default core group is sufficient in most configurations.

To create a new core group:

 

Procedure

  1. In the administrative console, click...

    Servers | Core groups | Core group settings | New

  2. In the Name field, specify a unique name for the new core group. This field can only be edited when you create the new core group. Verify the name is meaningful and consistent with the names of the other core groups in the cell. It is helpful if the name conveys why the application servers are being moved to this core group. For example, if your company's human resources applications are installed on the application servers that are moved to this core group, you might include HR as part of the core group name.

  3. Add a description of this core group that helps other administrators understand the purpose of this core group.

  4. In the Number of coordinators field, specify the number of active application servers you want serving as coordinators for this core group. Each core group coordinator can manage up to 10,000 core group components. Specify a value for this field based on the anticipated number of core group components.

  5. Select the type of transport that the application servers contained in this core group are using.

    1. If you select CHANNEL_FRAMEWORK, specify the name of an already defined transport chain in the Channel chain name field. Any value specified for the Multicast port, Multicast group IP start or Multicast group IP end fields are ignored.

    2. If you select MULTICAST, enter a port number in the Multicast port field, enter the first IP address in the range of IP addresses that can be used in the Multicast group IP start field, and enter the last IP address in the range of IP addresses that can be used in the field.

    3. If you select UNICAST, any value specified for the Channel chain name, Multicast port, Multicast group IP start or Multicast group IP end fields are ignored.

  6. Click Apply.

  7. On the administrative console panel click Core groups > core_group_name > Policies > New , and then select the policy that you want to associate with a high availability group in this core group. The high availability groups that are part of the new core group determine the policies that are required for this core group. New policies do not have to be defined if:

    • The processes contained in the new core group do not contain any high availability groups.

    • The new core group only contains processes, such as the service integration bus, for which default policies are provided as part of the high availability manager function.

    If we need to define a new policy, the policy options are:

    • All active policy: Under this policy, all of the group members are activated.

    • M of N policy: Under this policy, M group members are activated. The number represented by M is defined as part of the policy details.

    • No operation policy: Under this policy, no group members are activated.

    • One of N policy: Under this policy, only one group member is activated.

    • Static policy: Under this policy, the active members of a group are statically assigned.

    Multiple policies can be defined if different high availability groups require different policies. However, only one policy can be associated with a given high availability group.

    Note: If you are setting up a policy for a transaction manager, select One of N as your policy type because a transaction manager requires that only one server can have access to a failed server's recovery log at any point in time.

  8. Click Next.

  9. Specify a name for the policy that is unique within the scope of the core group.

  10. Change the value specified in the Is alive timer field if the default value is too long or too short a time period. This value, specified in seconds, determines how frequently the high availability manager checks the health of the core group members. Valid values are any integer between -1 and 600, inclusive. If -1 is specified, the timer is disabled. If 0 (zero) is specified, the default value of 120 seconds is used.

  11. Select Quorum if you want to enable quorum checking for the core group. Quorum is a mechanism that can be used to protect resources shared across members of the group in the event of a failure. CAUTION: Quorum is an advanced hardware function and should not be enabled unless you thoroughly understand how to properly use this function. If not used properly, this function can cause data corruption.

    The Quorum setting in the policy will only have an effect if the following items are true:

    • The group members are also cluster members.

    • GroupName.WAS_CLUSTER=clustername must be specified as a property in the group name of any high availability group matching this policy.

    When enabled, any group that is using this policy does not achieve quorum until a majority of the members are running. For example, if there are n members in the group, (n/2) + 1 servers must be online in order to achieve quorum. No group members are activated until quorum has been achieved.

    The quorum mechanism is designed to work in conjunction with a hardware control facility that allows application servers to be shut down if a failure causes the group to be partitioned.

  12. Click Apply, and then select Match criteria .

  13. On the next panel, click New and then specify the match criterion for this policy. A match criterion is a set of one or more name=value pairs of data that can be matched to attributes contained in the name of a high availability group.

    1. In the Name field, enter the name of one of the properties contained in a high availability group's name that you want to use to associate this policy with that high availability group.

    2. In the Value field, enter the value of this property that, along with the property name, forms the name=value pair.

    3. Optional: Add a description of this match criteria in the Description field.

    4. Click Ok.

    5. If we need to specify additional name=value pairs for your match criterion, repeat this step. Each name=value pair must be entered separately. Repeat this step until you have specified all of the name=value pairs required for this match criterion.

  14. Click Save, select Synchronize changes with nodes and then click Save again to save your changes.

 

What to do next

You are now ready to add members to this new core group.

 

See also


High availability groups
Core group collection
Core group settings

 

Related Tasks


Adding members to a core group