5.2.  Create clusters and cluster members.


Creating application server clusters

When you create a cluster, you have the option to create an empty cluster (no servers) or to create the cluster with one or more servers. The first application server added to the cluster acts as a template for subsequent servers. You can create the first server during the cluster creation process or you can convert an existing application server. The rest of the servers must be new and can be created when you create the cluster or added later.

Tip: When creating a cluster, it is possible to select the template of an existing application server for the cluster without adding that application server into the new cluster. If you need to change the attributes of the servers in your cluster after the cluster has been created, you must change each server individually. For this reason, consider creating an application server with the server properties that you want as a standard in the cluster first, then use that server as a template or as the first server in the cluster.

Cluster and cluster member options

When you create a new cluster, you have the following options to consider:

When you create a new cluster member, you have the following options to consider:

Using the deployment manager administrative console

To create a new cluster:

  1. Select "Servers > Clusters > WebSphere application server clusters".

  2. Click New.

  3. Enter the information for the new cluster (see the figure below):

    • Enter a cluster name of your choice.

    Figure 5.2. Creating a new cluster

    Creating a new cluster

  4. Create first cluster member: The first cluster member determines the server settings for the cluster members:

    Figure 5.3. First cluster member

    First cluster member

    • Member name: Type a name of the new server to be added to the cluster.

    • Select node: Specifies the node on which this new cluster member is created.

    • Weight: Assign the weight for this server.

      Work is distributed across the servers in the cluster based on weights assigned to each application server. If all cluster members have identical weights, work is distributed among the cluster members equally. Servers with higher weight values are given more work. An example formula for determining routing preference is as follows:

      % routed to Server1 = weight_1 /(weight_1 + weight_2 +...+ weight_n)

      In the formula, n represents the number of cluster members in the cluster. Consider the capacity of the system that hosts the application server.

      For example, if you have a cluster that consists of members A, B, and C with weights 2, 3, and 4, respectively, then 2/9 of the requests are assigned to member A, 3/9 are assigned to member B, and 4/9 are assigned to member C. If a new member, member D, is added to the cluster and member D has a weight of 5, then member A now gets 2/14 of the requests, member B gets 3/14 of the requests, member C gets 4/14 of the requests, and member D gets 5/14 of the requests.

    • Generate unique HTTP ports: Generates unique port numbers for every transport that is defined in the source server, so that the resulting server that is created will not have transports that conflict with the original server or any other servers defined on the same node.

    • Select basis for first cluster member:

      • If you select "Create the member using an application server template", the settings for the new application server are identical to the settings of the application server template you select from the list of available templates.

      • If you select "Create the member using an existing application server as a template", the settings for the new application server are identical to the settings of the application server you select from the list of existing application servers. However, applications that are installed on the template server are not installed on the new servers.

      • If you select "Create the member by converting an existing application server", the application server you select from the list of available application servers becomes a member of this cluster.

        Applications that are installed on the existing server are automatically installed on new members of the cluster.

        Note that the only way to remove a server from a cluster is to delete it, and when you delete the cluster, all servers in the cluster are deleted. Consider this before selecting this option.

      • If you select "None. Create an empty cluster", a new cluster is created, but it does not contain any cluster members.

      Click Next.

  5. Create additional cluster members: Use this page to create additional members for a cluster. You can add a member to a cluster when you create the cluster or after you create the cluster. A copy of the first cluster member that you create is stored as part of the cluster data and becomes the template for all additional cluster members that you create.

    To add a member, enter a new server name, select the node, and click "Add Member". The new member will be added to the list.

    Figure 5.4. Additional cluster members

    Additional cluster members

  6. When all the servers have been entered, click Next.

  7. A summary page shows you what will be created.

  8. Click Finish to create the cluster and new servers.

  9. Save the configuration.

Node groups

A node group is a collection of managed nodes. Managed nodes are WebSphere Application Server nodes. A node group defines a boundary for server cluster formation.

In a distributed environment, you can have nodes in a cell with different capabilities. However, there are restrictions on how the nodes can coexist.

Node groups are created to group nodes of similar capability together to allow validation during system administration processes. Effectively, this means that a node group establishes a boundary from which servers can be selected for a cluster. Nodes on distributed platforms and nodes on the IBM i platform can be members of the same node group, however, they cannot be members of a node group that contains a node on a z/OS platform.

A node group validates that the node is capable of performing certain functions before allowing them. For example, a cluster cannot contain both z/OS nodes and nodes that are not z/OS-based. In this case, you can define multiple node groups, one for the z/OS nodes and one for nodes other than z/OS. A DefaultNodeGroup is automatically created. This node group contains the deployment manager and any new nodes with the same platform type. A node can be a member of more than one node group.

Figure 5.5. Cell, deployment manager, node, and node group concepts

Cell, deployment manager, node, and node group concepts

To delete a node group, the node group must be empty. The default node group cannot be deleted.

A default node group called DefaultNodeGroup is automatically created for you when the deployment manager is created, based on the deployment manager platform. New nodes on similar platforms are automatically added to the default group. A node must belong to at least one node group, but can belong to more than one.

As long as you have nodes in a cell with similar platforms, you do not need to do anything with node groups. New nodes are automatically added to the node group. However, before adding a node on a platform that does not have the same capabilities as the deployment manager platform, you will need to create the new node group.

Note: Do not confuse node groups with "groups of nodes" in the job manager. These are two different concepts.

Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide