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:
This setting indicates that a request to an EJB should be routed to an EJB on the local node if available. This is the default setting and generally will result in better performance.
Configure HTTP session memory-to-memory replication (create a replication domain):
WebSphere Application Server supports session replication to another WebSphere Application Server instance. In this mode, sessions can replicate to one or more WebSphere Application Server instances to address HTTP Session single point of failure.
When you create a cluster, you can elect whether to create a replication domain for the cluster. The replication domain is given the same name as the cluster and is configured with the default settings for a replication domain. When the default settings are in effect, a single replica is created for each piece of data and encryption is disabled. Also, the Web container for each cluster member is configured for memory-to-memory replication.
When you create a new cluster member, you have the following options to consider:
Basis for first cluster member:
You can add application servers to the cluster when you create the cluster or later.
The first cluster member can be a new application server or you can convert an existing application server so that it becomes the first cluster member.
Subsequent application servers in the cluster must be created new. The first application server in the cluster acts as a template for the subsequent servers.
The options you have depend on the how you create the cluster.
When you use the job manager, you have the option to convert an existing server to use as the first cluster member, or create an empty cluster and run additional jobs to add cluster members.
When you use the deployment manager, you can convert an existing server, create one or more new servers, or create an empty cluster.
Note: The option to use an existing application server does not appear in the deployment manager administrative console if you create an empty cluster, then add a member later. If you want to convert an existing application server as the first server, specify that option when you create the cluster or use the job manager to create the cluster member.
Tip: To remove a server from a cluster, you must delete the server. Take this into consideration when you are determining whether to convert an existing server to a cluster.
Server weight for each cluster member:
The weight value controls the amount of work that is directed to the application server. If the weight value for this server is greater than the weight values that are assigned to other servers in the cluster, then this server receives a larger share of the workload. The weight value represents a relative proportion of the workload that is assigned to a particular application server. The value can range from 0 to 20.
Member weight: Specify the relative weight of this server in the cluster. Values are from 0 to 20. 0 indicates that work is to be routed to this server only in the event that no other servers are available.
Using the deployment manager administrative console
To create a new cluster:
Select "Servers > Clusters > WebSphere application server clusters".
Enter the information for the new cluster (see the figure below):
Enter a cluster name of your choice.
Create first cluster member: The first cluster member determines the server settings for the cluster members:
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
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
3/14 of the requests, member
C gets 4/14 of the requests, and
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.
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.
When all the servers have been entered, click Next.
A summary page shows you what will be created.
Click Finish to create the cluster and new servers.
Save the configuration.
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.
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.