SOA cluster configuration steps

Configuring a SOA Suite cluster is the first step in allowing your application to scale out to support more users. This recipe explains how to create a new domain that contains a cluster.

Follow these steps to configure a SOA Suite cluster:

1. Start the Oracle Fusion Middleware Configuration wizard, select the Create a new WebLogic domain option, and click on Next.

2. Select the necessary components for a SOA Suite and BAM domain with Enterprise Manager, as shown in the following screenshot, and then click on Next.

3. Enter a name for the domain in the Domain Name box, and the location you want it to be installed to. This can be any path on a local system. Click on Next.

4. Enter a name for the administrative user and a domain password, then click on Next.

5. Select Production Mode for the domain and click on Next, leaving the default JVM choice if this is suitable.

6. Obtain the database username and password from the database administrator, enter the database connection details, and click on Next.

7. The wizard will now test the connections. If the database is not up, or the repositories have not been created, the tests will fail, but the domain can still be created. Click on Next.

8. Select that you wish to edit the managed servers, clusters, and machine configurations, and click on Next.

9. Add additional managed servers, up to the number in your cluster design, give them the listen addresses and ports that you wish them to run on, and click on Next.

10. Create two clusters—one for SOA servers and one for BAM servers. Select multicast as the cluster protocol (assuming your network supports it; if not then select unicast), and enter the cluster address as a comma-separated list of the hosts in the cluster. Click on Next.

11. Allocate the servers to the clusters, and then click on Next.

12. Create a machine for each host in your cluster, then click on Next.

13. Allocate the WebLogic server instances to the machines that you wish them to run on, as in the following example screenshot, and then click on Next.

14. Review the domain configuration, then click on Next.

15. Wait while the wizard creates the domain. Once it has finished, you can select the box if you wish to immediately start the admin server, then click on Close.

— A domain is a group of WebLogic servers that share the same configuration repository. The configuration repository is the config.xml file on the admin server. There can only be one admin server per domain.

— A server is an instance of the WebLogic server.

— An admin server is the WebLogic server instance that is used to administer the domain. It stores the master copy of the configuration files, and runs the WebLogic administration console application and Enterprise Manager SOA Suite component.

— A managed server is any WebLogic server instance that is not the admin server. Managed servers are used to run applications such as the SOA Suite components.

— A cluster is a group of WebLogic servers that all have the same configuration and application components on them. Clusters can share some state between the servers in the cluster, so some stateful operations can be performed on any cluster member. Resources can be targeted at a cluster, which will deploy them on each server in the cluster.

— A machine is the logical representation of a host, and is used by Oracle WebLogic to know which host a particular server should be started on.

When running the configuration wizard, we stepped through the normal process of creating a domain, then selected to customize the domain and add additional servers, clusters, and machines. These changes get written to the config.xml file that contains the domain’s configuration. When we create the clusters and assign soa_server1 and bam_server1. to them, the configuration wizard is smart enough to know that it should deploy the relevant resources to the cluster, rather than to the individual servers.

In this domain setup, we also selected multicast as the cluster communication mechanism over unicast. Multicast is more efficient as updates are sent to a single address rather than distributed at the network tier, reducing network communication. Unicast on the contrary will create a connection between each cluster node, which is more work for the servers when sending updated cluster information. Unicast can sometimes be more efficient in very small clusters (for example, two to three nodes), because the networking infrastructure will often drop multicast packets first in order to preserve its QOS; unicast traffic can avoid this pitfall.

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.