Clusters are groups of servers that are managed together and participate in workload management. A cluster can contain nodes or individual appservers. A node is usually a physical computer system with a distinct host IP address that is running one or more appservers. Clusters can be grouped under the configuration of a cell, which logically associates many servers and clusters with different configurations and applications with one another depending on the discretion of the administrator and what makes sense in their organizational environments.
Clusters are responsible for balancing workload among servers. Servers that are a part of a cluster are called cluster members. When you install an application on a cluster, the application is automatically installed on each cluster member.
Because each cluster member contains the same applications, we can distribute client tasks in distributed platforms according to the capacities of the different machines by assigning weights to each server.
In distributed platforms, assigning weights to the servers in a cluster improves performance and failover. Tasks are assigned to servers that have the capacity to perform the task operations. If one server is unavailable to perform the task, it is assigned to another cluster member. This reassignment capability has obvious advantages over running a single appserver that can become overloaded if too many requests are made.
Cluster startup process options
New feature: Normal runtime processing automatically starts all server components during the server startup process. This processing applies to all servers, including servers that are part of a cluster.
However, we can configure servers, including servers that are cluster members, such that not all of the server components start during the server startup process. This capability enables the server to consume resources as needed, thereby providing a smaller and more manageable footprint, and normally results in a performance improvement
When you configure cluster members such that not all of the cluster member components start when the cluster or a specific cluster member is started, the cluster member components are dynamically started as they are needed. For example, if an application module starts that requires a specific server component, that component is dynamically started.
Clusters and node groups
Any application you install to a cluster must be able to execute on any appserver that is a member of that cluster. Because a node group forms the boundaries for a cluster, all of the members of a cluster must be members of the same node group. Therefore, for the application you deploy to run successfully, all of the members of a cluster must be located on nodes that meet the requirements for that application.
In a cell that has many different server configurations, it might be difficult to determine which nodes have the capabilities to host the application. A node group can be used to define groups of nodes that have enough in common to host members of a given cluster. All cluster members in a cluster must be in the same node group.
All nodes are members of at least one node group. When you create a cluster, the first appserver you add to the cluster defines the node group within which all of the other cluster members must reside. All other cluster members you add to the cluster can only be on nodes that are members of this same node group. By creating a new cluster member in the admin console, we are allowed to create the appserver on a node that is a member of the node group for that cluster only.
Nodes can be members of multiple node groups. If the first cluster member you add to a cluster has multiple node groups defined, the system automatically chooses the node group that bounds the cluster. We can change the node group by modifying the cluster settings. Use the Server cluster settings page to change the node group.
Clusters and core groups
In a high availability environment, a group of clusters can be defined as a core group. All of the appservers defined as a member of one of the clusters included in a core group are automatically members of that core group. Individual appservers that are not members of a cluster can also be defined as a member of a core group. The use of core groups enables WAS to provide high availability for applications that must always be available to end users.
We can also configure core groups to communicate with each other using the core group bridge. The core groups can communicate within the same cell or across cells.
New feature: We can improve system performance if we configure each cluster member, such that each of their components are dynamically started as they are needed instead of letting all of these components automatically start when the cluster member starts. Selecting this option can improve cluster startup time, and reduce the memory footprint of the cluster members. Starting components as they are needed is most effective if all of the applications that are deployed on the cluster are of the same type. For example, using this option works better if all of the applications are Web apps that use servlets, and JSPs. This option works less effectively if the applications use servlets, JSPs and EJB
Related conceptsClusters and workload management
Core group communications using the core group bridge service
Introduction: Application servers
Related tasksBalancing workloads
Set up a high availability environment
Manage node groups