|
|
The following sections describe how Oracle WebLogic Integration (WLI) is configured and deployed in a clustered environment. It contains the following topics:
For more information about deploying applications, see Deploying Applications To Oracle WebLogic Server.
Clustering allows WLI 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. WLI provides load balancing so that resource requests are distributed proportionately across all machines. A WLI 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 WLI cluster domain consists of only one administration server, and one or more managed servers. The managed servers in a WLI domain can be grouped in a cluster. When you configure WLI clusterable resources, you normally target the resources to a named cluster. The advantage of specifying a cluster as the target for resource deployment is that it makes it possible to increase capacity dynamically by adding managed servers to your cluster.
| Note: | WLI domains can support multiple clusters. However, you must still target WLI system resources and applications on a single WLI cluster in a multiple cluster domain. |
The topics in this section provide the information you need to configure WLI in a clustered environment. Although some background information about how WLI supports clustering is provided, the focus is on procedures that are specific to configuring WLI for a clustered environment.
Before proceeding, we recommend that you review the following sections of the Oracle 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 Oracle WebLogic Server clusters operate.
Domain and cluster creation are simplified by a Domain Configuration Wizard that lets you generate domains from basic and extension domain templates. Based on responses to user queries, the Domain Configuration Wizard generates a domain, server, and enterprise application with the appropriate components preconfigured and assets included. For information about the templates available for different domains, see the Template References.
The domain you create with the Configuration Wizard must have one and only one target which will contain WLI system components and applications. You can specify this target by setting the value of weblogic.wli.WliClusterName in wli-config.properties. If you do not specify a value for weblogic.wli.WliClusterName, the WLI target defaults to the first WLI cluster. For more information about the wli-config.properties file, see wli-config.properties Configuration File.
A server can be either a managed server or an administration server. A Oracle WebLogic Server running the administration service is called an administration server and hosts the Oracle WebLogic Server Administration Console. In a domain with multiple Oracle 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.
For more information about Oracle WebLogic clusters, see Using Oracle WebLogic Server Clusters in the Oracle 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 Oracle WebLogic clusters, see “Security Options for Cluster Architectures” in Cluster Architectures in Using Oracle WebLogic Server Clusters.
All the managed servers in a Oracle WebLogic Integration domain must be a part of the Oracle WebLogic Integration cluster, you cannot have a stand alone managed servers.
Although it is possible for a Oracle WebLogic Server management domain and cluster domain to be different (that is, it is possible for Oracle WebLogic Server clusters to have nodes that belong to different management domains), you must design your WLI deployment such that the cluster domain equals the management and security domain.
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 a WLI domain using the Configuration Wizard. You can also configure these attributes manually using the Servers node in the Oracle WebLogic Server Administration Console.
| Note: | The WLI applications must be deployed to the entire cluster; they cannot be deployed to just a few managed servers in the cluster. |
For a list of configurable WLI deployment resources, see Oracle WebLogic Integration Deployment Resources. It describes the default targeting of each resource in a clustered WLI domain and provides instructions on how to navigate to each resource in the Oracle WebLogic Server Administration Console.
This section contains the following topics regarding additional WLI deployment configuration requirements:
It is essential to have all WLI application components deployed before your system attempts to process messages. To guarantee this, specify the TwoPhase attribute when you deploy WLI. The following excerpt from a sample config.xml file illustrates an Application element that specifies the two-phase deployment of WLI.
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WL_HOME/lib"
TwoPhase="true">
...
Trading Partner Integration components must be deployed homogeneously to a cluster. You must configure Trading Partner Integration resources identically on every managed server so that there is no single point of failure.
When configuring Trading Partner Integration in a cluster, keep in mind the following considerations:
You can only change configuration for a cluster (for example, add new nodes to the cluster or modify Trading Partner Integration configuration) while 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.
Managed servers that start without an administrative server operate in Managed Server Independence (MSI) mode. For complete information about MSI mode, see “Managed Server Independence Mode” in Managing Server Startup And ShutDown.
One of the goals of clustering your WLI application is to achieve scalability. In order for a cluster to be scalable, each server must be fully utilized. Load balancing distributes the workload proportionally among all the servers in a cluster so that each server can run at full capacity. The following sections describe load balancing for various functional areas in a WLI cluster:
For more information, see Load Balancing in a Cluster in Using Oracle WebLogic Server Clusters.
Both Web services (SOAP or XML over HTTP) and Oracle WebLogic Trading Partner Integration protocols can use HTTP load balancing. External load balancing can be accomplished through the WebLogic HttpClusterServlet, a WebServer plugin, or a hardware router.
Oracle WebLogic Server supports load balancing for HTTP session states and clustered objects. For more information, see Communications in a Cluster in Using Oracle WebLogic Server Clusters.
Most JMS queues used by WLI or WLI applications are configured as distributed destinations. The exceptional cases are JMS queues that are targeted to single managed servers.
For detailed information on JMS load balancing, see “Tuning Distributed Destinations” in Tuning WebLogic JMS.
If your WLI solution includes communication between a synchronous client and an asynchronous business process, the weblogic.jws.jms.QueueConnectionFactory must have server affinity enabled. This is the default setting.
| WARNING: | Attempting to tune JMS load balancing by disabling server affinity for a solution that includes communication between a synchronous client and an asynchronous business process will result in unpredictable behavior. |
The RDBMS Event Generator has a dedicated JMS connection factory (wli.internal.egrdbms.XAQueueConnectionFactory). Load balancing is enabled for this connection factory by default. To disable load balancing for RDBMS events, you must disable load balancing and enable server affinity for wli.internal.egrdbms.XAQueueConnectionFactory.
Applications are deployed in production after creating EAR files from a Oracle Workshop for WebLogic application. Deploying a process application uses the same steps as deploying a web service application.
When deploying a WLI application to a cluster, keep in mind the following considerations:
wlw-manifest.xml be configured as JMS Distributed Queues, with a member of the distributed queue configured on each managed server. wlw-manifest.xml.For a full overview of application deployment, see Deploying Applications To Oracle WebLogic Server.
WLI event generators (Email, File, HTTP, JMS, MQSeries, RDBMS, and Timer) can be deployed through the Oracle WebLogic Integration Administration Console. For information about how to deploy event generators using the Oracle WebLogic Integration Administration Console, see “Creating and Deploying Event Generators” in Event Generators in Using The WebLogic Integration Administration Console.
Event generators can also be deployed using the WebLogic Scripting Tool (WLST). The following three pieces of WLST script show how to create, deploy, and configure an event generator.
The following excerpt from a WLST script shows how to create a JMS event generator:
import com.bea.wli.mbconnector.jms as eggen
…
eggen.JmsConnGenerator.main([
"-inName", “myEgName”,
"-outfile", “mydomain/myEgName.jar",
"-destJNDIName", “myQueueName”,])
Once you have created the event generator, you can deploy it to the appropriate target using script similar to the following example:
wlst.deploy( "WLIJmsEG_myEgName”, “mydomain/myEgName.jar", myServer )
To configure the properties of the deployed event generator, use a script similar to the following example:
import com.bea.wli.management.configuration as wlicfg
…
# Must have wli.jar in classpath
egCfgMBean = wlst.getTarget("JMSEventGenerators/JMSEventGenerators")
egMBean = egCfgMBean.newJMSEventGenConfigurationMBean( “myEgName”)
cData = jarray.zeros( 1, wlicfg.JMSEventGenChannelConfiguration )
cData[0] = wlicfg.JMSEventGenChannelConfiguration()
cData[0].setChannel( “myChannel” )
cData[0].setComment("Default channel")
egMBean.setChannels(cData);
| Note: | Code samples and utilities are available on WebLogic Integration Sample Code. |
The following sections provide additional guidelines for event generators.
The email, file, and timer event generators should be targeted to the cluster. They will be active on the managed server containing the migratable server with the queues associated with the specific event generator (for example, wli.internal.egmail.queue for an email event generator).
The sections below describe targeting and error handling issues to take into consideration when you deploy the JMS event generator.
The JMS event generator should be targeted depending on the destination JNDI name of the JMS event generator as indicated in the following table:
|
|||
The JMS event generator has no explicit error handling mechanism. Error handling is provided by associating the JMS event generator queue with an error queue.
| Note: | It is important to set the Redelivery Limit for a JMS error queue to a number of messages that is practical for your environment. By default, a JMS queue will redeliver error messages and warnings an infinite number of times. |
| Note: | For information about how to set the Redelivery Limit for messages, see JMS Templates: Configuration: Redelivery in the Oracle WebLogic Server Administration Console Online Help. |
The MQSeries event generator polls for messages on a WebSphere MQ queue and publishes the messages (MQMD headers as metadata along with the message payload) to Message Broker channels. Content filtering, as well as other handling criteria, are specified in the channel rules for the event generator.
The HTTP event generator is a servlet, which takes HTTP requests, checks for the content type, and then publishes the messages to Message Broker channels.
The RDBMS event generator polls the database table to check for added, deleted, or updated rows and publishes the results to Message Broker channels. You can also use this event generator to run custom queries on the database table and publish the results to Message Broker channels.
When deploying the RDBMS event generator in a cluster, you need to manually set the Redelivery Delay Override value to 20000 (20 seconds) and the Redelivery Limit to -1 (indicating no limit) for each of the RDBMS event generator JMS queues. You must configure these redelivery settings before generating any events on the cluster.
| WARNING: | Leaving the Redelivery Delay Override and Redelivery Limit set to their default values causes two immediate redelivery attempts for a JMS message when an error condition is encountered. If the second redelivery attempt fails, the message is discarded. |
To configure the redelivery settings for the RDBMS event generator JMS queues in a cluster, complete the following procedure:
For the procedure to start the Oracle WebLogic Server Administration Console (and the administration server, if necessary), see Start the Console.
dist_wli.internal.egrdbms.queue_auto_1 through n), select the Redelivery tab, and then enter the following values:
You must also set the Redelivery Delay Override value to 20000 (20 seconds) for single-server deployments. To configure the Redelivery Delay Override value for single-server deployments, complete the following procedure:
For the procedure to start the Oracle WebLogic Server Administration Console (and the administration server, if necessary), see Start the Console.
20000 in the Redelivery Delay Override field.It is not necessary to manually configure the Redelivery Limit setting for single-server deployments. The Redelivery Limit setting defaults to the correct values in single-server deployments.
|