About Machine Scale Out
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 can handle increasing numbers of requests without adversely affecting response time and throughput.
Machine scale-out is 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 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.
Roadmap for Scaling Out Your Topology
When your product is installed, configured, and has a cluster of Managed Servers, use this roadmap to scale out your topology.
Table 6-1 describes typical steps you must take to scale out a topology.
If you already have a SIT (as Installing and Configuring the Oracle Fusion Middleware Infrastructure and product installation guides such as Installing and Configuring Oracle SOA Suite and Business Process Management describe), you do not need to repeat Resource Requirements, Creating a New Machine, and Configuring WLS JMS After Machine Scale Up or Scale Out steps.
Table 6-1 has start-to-finish steps if you did not complete SIT steps.
Table 6-1 Roadmap for Scaling Out Your Topology
Product is ready for scale out
Product is installed, configured, and a cluster of Managed Servers is available; your product is in a SIT
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)
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.
Optional Scale Out Procedure
If you follow a standard installation topology (SIT), you have multiple Managed Servers assigned to a single host computer.
This set up 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 Creating a New Machine when you go through the roadmap (Roadmap for Scaling Out Your Topology).
See Creating a New Machine in your product installation guide for more on machine mapping.
About Scale Out Prerequisites
Before you start the scale out process, you must have a standard installation topology (SIT) set up for your product. A SIT is the starting point for scale out.
If you followed the steps in your product installation guide, you should have a SIT. For an example, see the SIT that Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology describes in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
For more on the SIT, see your product's installation guide or About the Standard Installation Topology in Planning an Installation of Oracle Fusion Middleware.
Application tier products in this release don't 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 certain 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 Using Shared Storage.
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).
Creating a New Machine
A machine is the logical representation of the computer that hosts one or more WebLogic Server instances (Managed Servers). In a WebLogic domain, the machine definitions identify physical units of hardware and are associated with Managed Servers that they host.
Follow steps in this section to create a new machine.
Shutting Down the Managed Server
The Managed Server must be shut down before moving to a new machine.
Creating a New Machine (Using the Administration Console)
You create a new machine to host Managed Servers and identify physical units of hardware. Typically you use the Administration Console to create a new machine.
To use WLST to create a new machine, see Creating a New Machine for Certain Components in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
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 isn't 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.
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.
- Click Finish.
- In the Change Center, click Activate Changes.
The message All changes have been activated. No restarts are necessary. opens to indicate that you have a new machine.
Assigning Managed Servers to a New Machine
You assign Managed Servers to the new machine to specify which servers the machine hosts.
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.
Configuring WLS JMS After Machine Scale Up or Scale Out
You must manually recreate all JMS system resources on a new Managed Server when you add one to a cluster.
New JMS system resources are cloned from an existing Managed Server in the cluster. 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_1persistent 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 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.
Packing the Domain on APPHOST1
You create a Managed Server template by running the
pack command on a WebLogic domain.
The Administration Server should be running on APPHOST1 when you go through 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. (Running Unpack to Transfer the Template describes unpack steps.)
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
packcommand. For example:
See pack and unpack Command Reference in Creating WebLogic Domains and Domain Templates for more information about creating a Managed Server template.
Preparing the New Machine
To prepare the new machine, machine_2, verify that APPHOST2 can access 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.
If you use shared storage, you can reuse the same installation location.
If you are running a new installation or reusing binaries by means of shared storage, the path location of the new files must match the original machine's path location exactly.
Running Unpack to Transfer the Template
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
Starting the Node Manager
You use Node Manager to start Managed Servers (using the Administration Console or Fusion Middleware Control).
To start Node Manager, run:
If you use machine scoped Node Manager, see Using Node Manager in Administering Node Manager for Oracle WebLogic Server for more on Node Manager start options.
Starting Managed Servers
You start Managed Servers in the Administration Console.
To start 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).
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.
Verifying Machine Scale Out
To determine if the machine scale out succeeded, verify that the server status is RUNNING (after you use Administration Console to start it).
Configuring Multicast Messaging for Clusters
You configure clusters to use messaging so that they can communicate whether or not services are available and other information.
About Multicast and Unicast Messaging for Clusters
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. Multiple applications subscribe to an IP address and port number then '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. 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, Oracle recommends Multicast messaging.
Requirements to Configure Multicast Messaging
Before you configure Multicast messaging, verify that your system meets system and network requirements.
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 188.8.131.52 and 184.108.40.206. (Weblogic uses default value of 220.127.116.11).
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 Communications In a Cluster in Administering Clusters for Oracle WebLogic Server for details on Multicast messaging and cluster configuration.
Configuring Multicast Messaging
You configure Multicast messaging in the Administration Console by selecting the cluster you want to enable it for then selecting the Multcast Messaging mode.
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:
Table 6-2 Multicast Advanced 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 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 router can discard a packet.
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 isn't encrypted.
- Click Save.
- 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.