• Managing static clusters
• Managing dynamic clusters

Managing static clusters

There are two approaches for managing static WebSphere Application Server clusters when using the WebSphere Application Server - Configure plug-in.

• Multiplicity approach

  In the multiplicity approach, you can create an arbitrary number of cluster members on an arbitrary number of nodes. The cluster members are based on a single server template. There are no configuration differences among cluster members. Use this approach instead of the standard approach to quickly change the number of cluster members that are deployed. For example, use the multiplicity approach to deploy four cluster members in a test environment, and then to deploy eight cluster members in a production environment.

• Standard approach

  In the standard approach, each cluster member is managed individually. Each cluster member is represented in the resource tree and has an associated component. There can be configuration differences among cluster members.

The WebSphere - Templatize Cluster Configuration Data step

Both approaches use the WebSphere - Templatize Cluster Configuration Data step. This step creates the server template that is used to create clusters. The Use Multiplicity check box controls the option to use the multiplicity approach. By default, Use Multiplicity is selected.

Using the multiplicity approach

When you create a component to manage the cluster configuration, use the WebSphere - Cluster Config component template that is provided with the plug-in. The WebSphere - Cluster Config component template includes resource property definitions that are required for the multiplicity approach.

For an example process that discovers and templatizes WebSphere Application Server configuration data for the multiplicity approach, see the WebSphere - Example 1 - Discover & Templatize Configuration Data (WAS ND with Cluster) generic process, which is provided with the plug-in. If you make changes to the example process, save and rename the example process before you begin editing. When you install a newer version of the IBM WebSphere Application Server - Configure plug-in, the example process is overwritten. If you do not save the example process with a different name, any changes that you make are overwritten if you install a newer version of the plug-in.

In the resource tree, add the cluster component under the cluster resource role, as shown in the following screen capture:

When you add the cluster component to the resource tree, enter values for the role properties. For more information on role properties, see the steps regarding adding server clusters in Managing WebSphere Application Server configurations.

Apply configuration changes by using a process similar to the WebSphere - Example 1 - Configuration - Example Application’s Deploy (WAS ND - Cluster) process, which is provided with the plug-in.

Using the standard approach

When you create a component to manage the cluster configuration, use the WebSphere - Cluster Config - No Multiplicity component template that is provided with the plug-in.

Create a component for each cluster member with the WebSphere - Server Config component template.

For an example process that discovers and templatizes WebSphere Application Server configuration data for the standard approach, see the WebSphere - Example 4 - Discover & Templatize Configuration Data (WAS ND with Cluster - No Multiplicity) generic process, which is provided with the plug-in. This example process assumes that there are two cluster members on the same node. You might need to modify the example process for your environment. If you make changes to the example process, save and rename the example process before you begin editing. When you install a newer version of the IBM WebSphere Application Server - Configure plug-in, the example process is overwritten. If you do not save the example process with a different name, any changes that you make are overwritten if you install a newer version of the plug-in.

In the resource tree, add the cluster component under the cluster resource role, as shown in the following screen capture. Add the server components, which represent cluster members, under the respective server resource roles. Specify the Cluster Name role property on the server components, as shown in the following screen capture.

In the following example, there are two cluster members, both located on the same node.

Apply configuration changes by using a process such as the WebSphere Configuration - Example Application’s Deploy (WAS ND - Cluster no Multiplicity) process, which is provided with the plug-in. The sample process assumes that there are two cluster members. You must update the sample process to use your server component names and to match the number of cluster members in your environment. If you make changes to the example process, save and rename the example process before you begin editing. When you install a newer version of the IBM WebSphere Application Server - Configure plug-in, the example process is overwritten. If you do not save the example process with a different name, any changes that you make are overwritten if you install a newer version of the plug-in.

In the standard approach, all cluster members must exist before you apply the cluster configuration.

Cluster members are listed in the configuration data for the cluster. To add or remove cluster members, you must edit the cluster configuration data. Cluster members are listed under the Cluster Members path.

Note: By default, server and node names are hardcoded in the configuration data. If you plan to deploy across environments where the server or node names are different, you must update the configuration data accordingly.

The following code is an example of how two cluster members are represented in cluster configuration data:

    {
        "description": "Discovered Cluster Members",
        "inheritTeam": "true",
        "name": "Cluster Members",
        "path": "/@websphere.cell@/ServerClusters/@websphere.cluster@/Cluster Members",
        "teamMappings": []
    },
    {
        "description": "Discovered WebSphereClusterMember",
        "inheritTeam": "true",
        "name": "JWC-CustomNode01Node01-amatthewMember1",
        "path": "/@websphere.cell@/ServerClusters/@websphere.cluster@/Cluster Members/JWC-CustomNode01Node01-amatthewMember1",
        "roleName": "WebSphereClusterMember",
        "roleProperties": {
            "websphere.clustermember.membername": "amatthewMember1",
            "websphere.clustermember.nodename": "JWC-CustomNode01Node01",
            "websphere.clustermember.weight": "2"
        },
        "teamMappings": []
    },
    {
        "description": "Discovered WebSphereClusterMember",
        "inheritTeam": "true",
        "name": "JWC-CustomNode01Node01-amatthewMember2",
        "path": "/@websphere.cell@/ServerClusters/@websphere.cluster@/Cluster Members/JWC-CustomNode01Node01-amatthewMember2",
        "roleName": "WebSphereClusterMember",
        "roleProperties": {
            "websphere.clustermember.membername": "amatthewMember2",
            "websphere.clustermember.nodename": "JWC-CustomNode01Node01",
            "websphere.clustermember.weight": "2"
        },
        "teamMappings": []
    }

Managing dynamic clusters

Dynamic clusters use server templates to manage cluster members. The server template contains configuration settings for the cluster members.

When you run a discovery process on a dynamic cluster and convert the cluster configuration data into templates, the server template is included as a component version artifact. For an example, see the WebSphere - Example 11 - Discover & Templatize Cluster Configuration Data example process. The following screen capture shows the server template stored with the cluster artifact.

You do not need to collect configuration information for dynamic cluster members. The dynamic cluster itself manages the cluster members by using the server template.