| Sun Java System Application Server Enterprise Edition 8.1 Administration Guide 2005Q1 |
Chapter 2
Configuring ClustersThis chapter describes how to use the Admin Console to configure clusters. It contains the following sections:
About ClustersWhat is a Cluster?
A cluster is a collection of zero or more server instances that work together as one logical entity. A cluster provides a runtime environment for one or more J2EE applications.
The use of clusters in the Sun Java System Application Server Enterprise Edition 8.1 environment provides the following:
- High availability, by allowing for failover protection for the server instances in a cluster. If one server instance goes down, other server instances take over the requests that the unavailable server instance was serving.
- Scalability, by allowing for the addition of server instances to a cluster, thus increasing the capacity of the system. The load balancer of the Application Server distributes requests to the available server instances within the cluster. No disruption in service is required as an administrator adds more server instances to a cluster.
A cluster has the following properties:
- All instances in the cluster reference the same configuration.
- All instances in the cluster have the same set of deployed applications (for example, a J2EE application EAR file, a web module WAR file, or an EJB JAR file).
- All instances in the cluster have the same set of resources, resulting in the same JNDI namespace.
Every cluster in the domain has a unique name; furthermore, this name must be unique across all node agent names, server instance names, cluster names, and configuration names. The name must not be
domain. Administrators perform the same operations on a cluster (for example, deploying applications and creating resources) that they perform on an unclustered server instance.For an overview of the use of clusters, node agents, and server instances, see the Deployment Planning Guide. For details about the load balancer, see Configuring Load Balancing and Failover.
Cluster Types
There are two types of clusters: stand-alone clusters and shared clusters.
- A stand-alone cluster has its own configuration shared by no other server instances or clusters. By default, the name of this configuration is cluster_name
-config, where cluster_name represents the name of the cluster.- A shared cluster shares its configuration with one or more other clusters or unclustered instances.
Clusters, Instances, Load Balancers, and Sessions
Clusters, server instances, load balancers, and sessions are related as follows in the Application Server:
- It is not mandatory that a server instance be part of a cluster. However, an instance that is not part of a cluster cannot take advantage of high availability through transfer of session state from one instance to other instances.
- The server instances within a cluster can be hosted on different machines or on the same machine. That is, you can group server instances across different machines into a cluster.
- A particular load balancer can forward requests to server instances on multiple clusters. You can use this ability of the load balancer to perform an online upgrade without loss of service. For more information, see "Using Multiple Clusters for Online Upgrades Without Loss of Service".
- A single cluster can receive requests from multiple load balancers. If a cluster is served by more than one load balancer, you must configure the cluster in exactly the same way on each load balancer.
- Each session is tied to a particular cluster. What this implies is that although an application can be deployed on multiple clusters, sessions will only be failed over to server instances within the same cluster.
- The Application Server supports failover for HTTP sessions and stateful session bean (SFSB) sessions. Failover of certain J2EE object references that are stored within HTTP sessions is also supported.
For more information on failover of HTTP sessions, see "Configuring Availability and Session Persistence"
The cluster thus acts as a safe boundary for session failover for the server instances within the cluster. You can use the load balancer and upgrade components within the Application Server without loss of service. For more information, see "Using Multiple Clusters for Online Upgrades Without Loss of Service".
Admin Console Tasks for ClustersCreating a Cluster
To create a cluster, perform these steps:
- In the tree component, select the Clusters node.
- On the Clusters page, click New. The Create Cluster page appears.
- In the Name field, type a name for the cluster. The name
- In the Configuration field, choose a configuration from the drop-down list.
To create a stand-alone cluster, choose
default-config, and leave the radio button labeled “Make a copy of the selected Configuration” selected. The copy of the default configuration will have the name cluster_name-config.To reference another configuration, choose the configuration from the drop-down list and select the radio button labeled “Reference the selected Configuration.” This action creates a shared cluster if the configuration is used by another cluster.
- You can add server instances now, or you can wait until after the cluster is created. Before you create server instances for the cluster, first create one or more node agents or node agent placeholders. See "Creating a Node Agent Placeholder" for details.
To create server instances, perform the following steps:
- Click OK.
- Click OK on the Cluster Created Successfully page that appears.
For more details on how to administer clusters, server instances, and node agents, see "Deploying Node Agents".
Equivalent
asadmincommand:create-clusterConfiguring a Cluster
To configure a cluster, perform these steps:
Equivalent
asadmincommands:start-cluster,stop-cluster,migrate-timersMigrating EJB Timers
If a server instance stops running abnormally or unexpectedly, it can be necessary to move the EJB timers installed on that server instance to a running server instance in the cluster. To do so, perform these steps:
- From the Source drop-down list, choose the stopped server instance from which to migrate the timers.
- Optionally, from the Destination drop-down list, choose the running server instance to which to migrate the timers. If this field is left blank, a running server instance will be randomly chosen.
- Click OK.
- Stop and restart the Destination server instance.
An error message appears if the Source server instance is running or if the Destination server instance is not running.
Equivalent
asadmincommand:migrate-timersCreating Server Instances for a Cluster
Before you can create server instances for a cluster, you must first create a node agent or node agent placeholder. See "Creating a Node Agent Placeholder" for details.
To create a server instance for a cluster, perform these steps:
- In the tree component, expand the Clusters node.
- Select the node for the cluster.
- Click the Instances tab to bring up the Clustered Server Instances page.
- Click New to bring up the Create Clustered Server Instance page.
- In the Name field, type a name for the server instance.
- Choose a node agent from the Node Agents drop-down list.
- Click OK.
Equivalent
asadmincommand:create-instanceConfiguring Clustered Server Instances
To make changes to a clustered server instance after creating it, perform these steps:
- In the tree component, expand the Clusters node.
- Expand the node for the cluster that contains the server instance, then select the server instance node to be edited.
- On the General Information page, you can perform these tasks:
- Click Start Instance to start the instance.
- Click Stop Instance to stop a running instance.
- Click JNDI Browsing to browse the JNDI tree for a running instance.
- Click View Log Files to open the server log viewer.
- Click Rotate Log File to rotate the log file for the instance. This action schedules the log file for rotation. The actual rotation takes place the next time an entry is written to the log file.
- Click Recover Transactions to recover incomplete transactions.
- Click the Properties tab to modify the port numbers for the instance.
- Click the Monitor tab to change monitoring properties.
You can also perform operations on a server instance as follows:
To delete a clustered server instance from a cluster, select the checkbox next to the instance name and click Delete.
Configuring Applications for a Cluster
To configure applications for a cluster, perform these steps:
- In the tree component, expand the Clusters node.
- Select the node for the cluster.
- Click the Applications tab to bring up the Applications page. On this page, you can perform these tasks:
- Select the checkbox next to an application and choose Enable or Disable to enable or disable the application for the cluster.
- From the Deploy drop-down list, select a type of application to deploy. On the Deployment page that appears, specify the application.
- From the Filter drop-down list, select a type of application to display in the list.
To edit an application, click the application name.
Configuring Resources for a Cluster
To configure resources for a cluster, perform these steps:
- In the tree component, expand the Clusters node.
- Select the node for the cluster.
- Click the Resources tab to bring up the Resources page. On this page, you can perform these tasks:
- Select the checkbox next to a resource and click Enable or Disable to enable or disable the resource globally. This action does not remove the resource.
- From the New drop-down list, select a type of resource to create. Make sure to specify the cluster as a target when you create the resource.
- From the Filter drop-down list, select a type of resource to display in the list.
To edit a resource, click the resource name.
Deleting a Cluster
To delete a cluster, perform these steps:
Equivalent
asadmincommand:delete-clusterUsing Multiple Clusters for Online Upgrades Without Loss of Service
You can use the load balancer and multiple clusters to upgrade components within the Application Server without any loss of service. A component can, for example, be a JVM, the Application Server, or a web application.
To perform this task, do the following:
Because sessions within one cluster will never fail over to sessions within another cluster, there is no risk of version mismatch caused by a session’s failing over from a server instance that is running one version of the component to another server instance (in a different cluster) that is running a different version of the component. A cluster in this way acts as a safe boundary for session failover for the server instances within it.
