This section describes the steps to scale out a topology (machine scale-out) for all Fusion Middleware products that are a part of a WebLogic Server domain. To enable high availability, it is important to provide failover capabilities to another host computer. When you do so, your environment can continue to serve consumers of your deployed applications if one computer goes down.
This section includes the following topics:
Scalability is the ability of a piece of hardware or software or a network to "expand" or "shrink" to meet future needs and circumstances. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.
Machine scale-out is the process of moving a server, one of many on one machine, to another machine for high availability. Machine scale out is different from Managed Server scale up, which is the process of adding a new Managed Server to a machine that already has one or more Managed Servers running on it. See "Scaling Up Your Environment" in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
The following table describes the typical steps you must take to scale out a topology.
If you already have a standard installation topology (as Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure and product installation guides such as Oracle Fusion Middleware Installing and Configuring Oracle SOA Suite and Business Process Management describe), you do not need to repeat the Section 6.5, Section 6.6, and Section 6.7 steps. The following table provides start-to-finish steps if you did not complete standard installation topology steps.
Product is ready for scale out
Product is installed, configured, and a cluster of Managed Servers is available; your product is in a standard installation topology
Verify that you meet resource requirements
You must verify that your environment meets certain requirements
Create a new machine and assign servers to it
Use the Administration Console to create a new machine and add Managed Servers to it.
Create a new JMS server and target it
Create a new JMS server and target it to the new Managed Server
Run the pack command
Pack up the domain directory
Prepare the new machine
Install the same software that you installed on the first machine
Run the unpack command
Create a Managed Server template.
Start the server
Starts the Managed Server on the new machine
Verify the topology
Test the new setup
Set the cluster messaging mode to Multicast
Modifies messaging mode from Unicast to Multicast (preferred for multi-server domains)
Note:In this section, APPHOST refers to a physical host computer. Machine refers to the WebLogic Server machine definition describing that host. See "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" in Installing and Configuring the Oracle Fusion Middleware Infrastructure.
By following the standard installation topology, you have multiple Managed Servers assigned to a single host computer.
This approach is the most flexible way to create and scale out a domain topology so that it can meet changing requirements. It allows you to 1) create and validate a single-host domain, which is targeted to a single machine on a single host computer, and then 2) "retarget" the Managed Servers to additional machines, when additional computing resources are required. Also, it facilitates troubleshooting; you can validate the basic domain then scale up and scale out (and troubleshoot) at a later time.
However, if you know ahead of time what your target topology is, you can create additional machines during domain creation then just run pack and unpack steps.
If you assigned Managed Servers to target machines during installation or through an online administrative operation, skip Section 6.6, "Creating a New Machine" as you go through the roadmap (Section 6.2, "Roadmap for Scaling Out Your Topology").
See product installation guides, such as Installing and Configuring the Oracle Fusion Middleware Infrastructure, for more on machine mapping.
Before you start the scale out process, you must have a standard installation topology set up for your product. The standard installation topology is the starting point for scale out. If you followed the steps in your product installation guide, you should have a standard installation topology. For an example, see the standard installation topology that "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" describes in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
See Also:For more on the standard installation topology, see your product's installation guide or "About the Standard Installation Topology" in Planning an Installation of Oracle Fusion Middleware.
Note:Application tier products in this release do not support dynamic clusters. Dynamic clusters consist of server instances that can dynamically scale up to meet your application resource needs. A dynamic cluster uses a single server template to define configuration for a specified number of generated (dynamic) server instances.
Before you scale out the topology, verify that your environment meets these requirements:
At least one machine runs multiple Managed Servers configured with a product. This is the result of following your product installation guide or administration guide to add additional servers.
A host computer in addition to your starting host computer.
Each host computer can access the Oracle home that contains the product binaries by one of the following means:
Shared disk with binaries from the original installation
Dedicated disk with a new installation (matches the original installation)
Dedicated disk with a clone of the binaries from the original installation
See Chapter 4, "Using Shared Storage" for more information.
Sufficient storage available for the domain directory.
Access to the same Oracle or third-party database used for the original installation.
A shared disk for JMS and transaction log files (required when using a file persistence profile).
A machine is the logical representation of the computer that hosts one or more WebLogic Server instances (servers). In a WebLogic domain, the machine definitions identify physical units of hardware and are associated with the servers that they host.
Follow these steps to create a new machine:
The Managed Server must be shut down before moving to a new machine. If it is up and running, see the topic "Shut down a server instance" in the Administration Console Online Help to shut down the Managed Server that the new machine will host.
This topic describes how to create a new machine using the Administration Console. To use WLST to create a new machine, see "Creating a New Machine for Certain Components" in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
Note:The machine you create in this procedure must have a listen address on a specific network interface, not just a local host.
To create a new machine in the domain:
Start the domain Administration Server if it is not running. Go to the DOMAIN_HOME/bin directory and run:
When the Administration Server is running, access the Administration Console. Open a web browser and enter the URL:
On the Welcome screen, log in.
In the Administration Console Change Center, click Lock & Edit.
Note:For production domains, Oracle recommends creating the domain in Production mode, which enables Change Center. If Production mode is not enabled, Change Center steps are not required.
Under Domain Structure, expand Environment then click Machines.
Above the Machines table (above Summary), click New.
In the Create a New Machine screen, enter a name for the machine, such as machine_2. Select the Machine OS using the drop-down list then click Next.
On the next screen, for Type:, use the drop-down list to select Plain.
For the Node Manager Listen Address, enter the IP address or host name of the host computer that will represent this machine. Both machines appear in the Machines table.
In the Change Center, click Activate Changes.
The message "All changes have been activated. No restarts are necessary." appears. This message indicates that you have a new machine.
To add Managed Servers to a newly-created machine, use the Administration Console:
In the Change Center, click Lock & Edit.
In the Machines table, select the checkbox for machine_1.
Click the machine name (represented as a hyperlink).
Under the Settings for machine_1, click the Configuration tab then the Servers subtab.
Above the Servers table, click Add.
On the Add a Server to Machine screen, click Create a new server and associate it with this machine. Click Next then enter the Server Name and the Server Listen Port in the fields (required).
Under Domain Structure, click Machines.
In the Machines table, click the machine machine_2.
Under the Settings for machine_2, click the Configuration tab and then the Servers tab. Above the Servers tab, click Add.
On the Add a Server to Machine screen, select the button Select an existing server, and associate it with this machine.
Use the Select a server drop-down list to choose server_2 then select Finish.
The message Server created successfully appears.
Verify that all Managed Servers have the correct Server Listen Address. Under Domain Structure, click Servers. In the Servers table, click the name of the Managed Server. Select the Configuration tab. Verify/set the Listen Address to the IP address of the machine it is associated with. Click Save.
To complete the changes, go back to the Change Center. Click Activate Changes. The message All changes have been activated. No restarts are necessary. appears.
To see a summary of Managed Server assignments, under Domain Structure, under Environment, click Servers. The Servers table shows all servers in the domain and their machine assignments.
When you add a new Managed Server to a cluster, you must manually recreate all JMS system resources on the new Managed Server. The new JMS system resources are "cloned" from an existing Managed Server in the cluster. The new JMS system resources must have unique names in the domain. When you create a domain, the Configuration Wizard creates JMS system resource names that follow a pattern. For ease of use and manageability, Oracle recommends that you follow the same naming pattern.
To configure JMS resources on a new Managed Server
In the Domain Structure tree, select Services then select Messaging. Select JMS Servers to open the JMS Servers table.
In the Name column, identify all JMS servers that target one of the existing Managed Servers in the cluster, for example,
The JMS server name format is ResourceName_auto_number.
ResourceName is the resource's identifying name
number identifies the JMS server; servers with the suffix 1 or 2 were created when the domain was created.
Note the name of the JMS server and its persistent store. For example,
Click New to create a new JMS server.
Name the JMS server for
server_n using the same format as
server_1. For example,
For the Persistent Store, click Create a New Store.
For Type, select the same persistence profile used that the JMS Server uses on
server_1. Click Next.
Enter a persistent store in the Name field. Use the same format as the
server_1 persistent store. For example,
In the Target field, select the migratable target for migratable target
(migratable) from the drop down list.
In the Directory field, use the same name as the persistent store. Click OK to create the persistent store.
In the Create a New JMS Server screen, select the new persistent store and click Next.
For JMS Server Target, select the migratable target for
server_n (migratable) from the drop down list.
Click Finish to create the JMS server.
Update the Subdeployment targets for the corresponding JMS Modules to include the new JMS server:
In the Administration Console's Domain Structure tree, expand the Services node, expand the Messaging node, and select JMS Modules to open the JMS Modules table.
Identify the JMS system module that corresponds to the JMS server; its name has a common root. For example for JMS server
UMSJMSServer_auto_1, the JMS module name is
UMSJMSSystemResource. Click on the JMS module (a hyperlink) in the Name column to open the Module Settings page.
Open the Subdeployments tab and click on the subdeployment for the JMS module in the Name column.
Select the new JMS Server
server_n. Click Save.
Go back to the module Settings page. Select the Targets tab. Verify that All servers in the cluster is enabled.
Click Save if you changed anything.
You now have a new Managed Server that has configured JMS resources in the cluster.
You create a Managed Server template by running the
pack command on the WebLogic domain.
Note:The Administration Server should be running on APPHOST1 when you go through the pack and unpack steps.
pack command on APPHOST1 to create a template pack. You unpack the template file on APPHOST2 later in the scale out process; Section 6.10, "Running Unpack to Transfer the Template" describes the unpack procedure.
ORACLE_HOME/oracle_common/common/bin/pack.sh \ -domain=DOMAIN_HOME \ -template=dir/domain_name.jar \ -managed=true \ -template_name="DOMAIN"
In the preceding example:
Replace DOMAIN_HOME with the full path to the domain home directory.
Replace dir with the full path to a well-known directory where you will create the new template file.
Replace domain_name in the JAR file name with the domain name. This is the name of the template file that you create with the
pack command. For example:
See Also:See "pack and unpack Command Reference" in Creating WebLogic Domains and Domain Templates for more information about creating a Managed Server template.
To prepare the new machine, machine_2, verify that APPHOST2 has access to the shared disk where the Oracle home is installed or install the same software that you installed on machine_1.
For example, if you are scaling out an Oracle Fusion Middleware Infrastructure domain, verify that APPHOST2 can access the Infrastructure Oracle home.
Note:If you use shared storage, you can reuse the same installation location.
Note:If you are performing a new installation or reusing the binaries by means of shared storage, the path location of the new files must match the original machine's path location exactly.
To unpack the template and transfer the domain_name.jar file from APPHOST1 to APPHOST2, run the unpack command:
ORACLE_HOME/oracle_common/common/bin/unpack.sh \ -domain=user_projects/domains/base_domain2 \ -template=/tmp/domain_name.jar \ -app_dir=user_projects/applications/base_domain2
To start Node Manager, run the following:
When you use machine scoped Node Manager, see "Using Node Manager" in Administering Node Manager for Oracle WebLogic Server for more information on Node Manager start options.
To use the Administration Console to start the Managed Servers:
In the left pane of the Console, expand Environment and select Servers.
In the Servers table, click the name of the Managed Server that you moved to the new machine. Select the Control tab.
Select the check box next to the name of the server(s) you want to start and click Start to start the server(s).
See Also:To use WLST commands or Fusion Middleware Control to start Managed Servers, see "Starting and Stopping Managed Servers" in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
To determine if the machine scale out succeeded, verify that the server status is RUNNING after you use the Administration Console to start it.
This section includes the following topics:
Clusters use messaging to broadcast the availability of services and heartbeats that indicate continued availability. You configure clusters to use Unicast or Multicast messaging.
Multicast is a simple broadcast technology that enables multiple applications to subscribe to an IP address and port number, and listen for messages. Multicast set up is more complex than Unicast because it needs hardware configuration and support.
Unicast provides TCP-based, reliable, one-to-many communication for cluster messaging. It is easier to set up than multicast.
When you create clusters in the Configuration Wizard, Unicast is the default cluster messaging mode. When the number of Managed Servers in a domain increases, Multicast messaging is preferable.
Requirements to configuring Multicast messaging include:
A configured domain with at least one cluster.
A hardware configuration set up to support Multicast in your network.
The IP address and port numbers for Multicast communications in the cluster. A multicast address is an IP address between 22.214.171.124 and 126.96.36.199. (Weblogic uses default value of 188.8.131.52).
You have run the MulticastTest utility to verify that your environment can support multicast. The utility debugs multicast problems. It sends out multicast packets and returns data about how effectively multicast works in your network.
See Also:See "Communications In a Cluster" in Administering Clusters for Oracle WebLogic Server for details on Multicast messaging and cluster configuration.
To configure Multicast Messaging:
Log in to the Administration Console.
Shut down all servers that you want to use for Multicast messaging.
In the Domain Structure pane on the left, expand Environment and click Clusters.
Select the cluster name that you want to enable Multicast for.
Click the Configuration tab then the Messaging tab.
For Messaging Mode, select Multicast. Enter the Multicast Address then the Multicast Port.
The Multicast Address must be unique for each cluster. See "Cluster Multicast Address and Port" in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server for guidelines on Multicast addresses.
Click Advanced to configure these parameters:
Multicast Send Delay
Amount of time (between 0 and 250) in milliseconds to delay sending message fragments over multicast to avoid OS-level buffer overflow.
Number of network hops (between 1 and 255) that a cluster multicast message can travel. If your cluster spans multiple subnets in a WAN, this parameter value must be high enough to ensure that routers don't discard multicast packets before they reach their final destination. This parameter sets the number of network hops a multicast message makes before a packet can be discarded.
Multicast Buffer Size
Multicast socket send/receive buffer size (at least 64 kilobytes).
Idle Periods Until Timeout
Maximum number of periods a cluster member waits before timing out a cluster member.
Enable Data Encryption
Enables multicast data encryption. Only multicast data is encrypted; Multicast header information is not encrypted.
Restart all servers in the cluster.
The cluster can now use Multicast messaging. When you select Clusters in the Domain Structure pane in the Administration Console, Multicast appears for Cluster Messaging Mode.