|
|
The following sections describe how ALSB is configured and deployed in a clustered environment. It contains the following topics:
Clustering allows ALSB to run on a group of servers that can be managed as a single unit. In a clustered environment, multiple machines share the processing load. ALSB provides load balancing so that resource requests are distributed proportionately across all machines. An ALSB deployment can use clustering and load balancing to improve scalability by distributing the workload across nodes. Clustering provides a deployment platform that is more scalable than a single server.
A WebLogic Server cluster domain consists of only one administration server, and one or more managed servers. The managed servers in an ALSB domain can be grouped in a cluster. When you configure ALSB clusterable resources, you normally target the resources to the named cluster. The advantage of specifying a cluster as the target for resource deployment is that it makes it possible to dynamically increase capacity by adding managed servers to your cluster.
| Note: | ALSB domains can support a single cluster, and all managed servers in the domain must belong to that cluster. |
The topics in this section provide the information you need to configure ALSB in a clustered environment. Although some background information about how WebLogic Server supports clustering is provided, the focus is on procedures that are specific to configuring ALSB for a clustered environment.
Before proceeding, we recommend that you review the following sections of the WebLogic Server documentation to obtain a more in-depth understanding of clustering:
The following sections provide the information you need to design a clustered deployment:
Before you begin designing the architecture for your clustered domain, you need to learn how WebLogic Server clusters operate.
Domain and cluster creation are simplified by a Configuration Wizard that lets you generate domains from basic and extension domain templates. Based on responses to user queries, the Configuration Wizard generates a domain, server, and enterprise application with the appropriate components preconfigured and assets included. For information about creating ALSB domains using the Configuration Wizard, see Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.
A server can be either a managed server or an administration server. A WebLogic Server running the administration service is called an administration server and hosts the WebLogic Server Administration Console. In a domain with multiple WebLogic Servers, only one server is the administration server; the other servers are called managed servers. Each managed server obtains its configuration at startup from the administration server.
| Note: | Managed servers that start without an administration server operate in Managed Server Independence (MSI) mode. For information about MSI mode, see “Managed Server Independence Mode” in “ Avoiding and Recovering From Server Failure” in Managing Server Startup and Shutdown. |
You can enable an SSL port, an HTTP cleartext port, or both ports for the administration server. In secure installations, the HTTP cleartext port can be disabled. However, when AquaLogic Service Bus is used in combination with a UDDI registry (for example, AquaLogic Service Registry), you must ensure that the server’s HTTP cleartext port is enabled.
For general information about WebLogic clusters, see Using WebLogic Server Clusters in the WebLogic Server documentation set. This document includes details regarding recommended basic, multi-tiered, and proxy architectures. For information about security considerations in the design of WebLogic clusters, see “Security Options for Cluster Architectures” under Cluster Architectures in Using WebLogic Server Clusters.
For each server in a clustered domain, you can configure a variety of attributes that define the functionality of the server in the domain. These attributes are configured automatically when you create an ALSB domain using the Configuration Wizard. Advanced users can also configure these attributes manually using the Servers node in the WebLogic Server Administration Console.
For a list of configurable ALSB deployment resources, see AquaLogic Service Bus Deployment Resources. It describes the default targeting of each resource in a clustered ALSB domain and provides instructions on how to navigate to each resource in the WebLogic Server Administration Console.
While most resources used by ALSB are deployed homogeneously across the cluster, there are a number of resources that must be pinned to a single managed server in order to operate correctly. The following table lists these components, describes how they are targeted, and provides a link for more information.
“Viewing and Changing Proxy Services” in Proxy Services in Using the AquaLogic Service Bus Console.
|
||
The ALSB Data Aggregator runs as a singleton service on one of the managed servers in the cluster. Data collection is performed on each of the managed servers in the domain. The aggregator is responsible for the collection and aggregation of data from all managed servers in the domain. The aggregated data are processed and classified by each ALSB configuration.
ALSB configurations can include rules defining Service Level Agreements (SLAs) for system performance. The Alert Manager is responsible for storing rules, and evaluates these rules against the data aggregated for the cluster. When a rule evaluates to true, the Alert Manager sends an e-mail message, posts a message on a JMS queue, or logs a message according to the action associated with the rule.
For more information about these features, see Monitoring in Using the AquaLogic Service Bus Console.
When a managed server is down during session activation, configuration changes from the activation are not reflected on that server. In addition, the task status of the session activation is listed as Partially Activated to indicate that the activation was not completed on all managed servers. After the managed server is restarted, it synchronizes with the information available with the administration server, and any unactivated changes are activated on the managed server. For more information about session activations, see Using the Change Center in Using the AquaLogic Service Bus Console.
You can only re-configure a cluster (for example, add new nodes to the cluster or modify business service configuration) when its administration server is active.
If the administration server for a cluster is down, deployment or undeployment requests are interrupted, but managed servers continue serving requests. You can boot or reboot managed servers using an existing configuration, as long as the required configuration files (msi-config.xml, SerializedSystemIni.dat, and optionally boot.properties) exist in each managed server’s root directory.
One of the goals of clustering your ALSB application is to achieve scalability. For a cluster to be scalable, each server must be fully utilized. Load balancing distributes the workload proportionately across all the servers in a cluster so that each server can run at full capacity. The following sections describe inbound message processing load balancing for ALSB clusters:
For more information about inbound message load balancing, see Load Balancing in a Cluster in Using WebLogic Server Clusters. For information about configuring load balancing for business services, see “To Add a Business Service - Transport Configuration” in “Adding a Business Service” under Business Services, in Using the AquaLogic Service Bus Console.
Web services (SOAP or XML over HTTP) can use HTTP load balancing. External load balancing can be accomplished through the WebLogic HttpClusterServlet, a WebServer plugin, or a hardware router. For an overview of a cluster topology that includes load balancing, see Figure 5-1. WebLogic Server supports load balancing for HTTP session states and clustered objects. For more information, see Communications in a Cluster in Using WebLogic Server Clusters.
Most JMS queues used by ALSB are configured as distributed destinations. Exceptions are JMS queues that are targeted to single managed servers.
For detailed information on JMS load balancing, see “Controlling the Flow of Messages on JMS Servers and Destinations” in Tuning WebLogic JMS in WebLogic Server Performance and Tuning.
Message-driven beans consume messages from JMS destinations. A number of message-driven beans are deployed on each ALSB destination.
The ability to configure multiple physical destinations as members of a single distributed destination set provides a highly available implementation of WebLogic JMS. Specifically, for each node in a cluster, an administrator should configure one physical destination for a distributed destination. If one node in the cluster fails, making the physical destination for that node unavailable, then other physical destinations configured as members of the distributed destination can provide services to JMS producers and consumers. (This is how the Configuration Wizard generates domains for a cluster.)
Message-driven beans consume messages from distributed destinations. Distributed destinations contain one physical destination for each instance of WebLogic Server. A single message producer on a distributed queue is bound to a single physical destination. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity).
For more information, see Understanding ALSB High Availability.
Configurations are deployed by importing the contents of one or more JAR files exported from the ALSB Console. You deploy an ALSB configuration in a clustered environment following the same procedure as for a single-server deployment. For a description of the deployment procedure, see Step 4. Deploy an ALSB Configuration.
Preparations for deployment of an ALSB configuration in a production cluster environment involve more system administration tasks than for a single-server testing or staging environment. For a full description of the steps involved in a production cluster deployment, see Configuring a Clustered Deployment.
|