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.
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 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 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.
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.
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 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 (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.
The Managed Server must be shut down before moving to a new machine.
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:
On the Welcome screen, log in.
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.
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.
The message All changes have been activated. No restarts are necessary. opens to indicate that you have 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 Machines table, click the machine machine_2.
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.
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.
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_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 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 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
pack command. For example:
See pack and unpack Command Reference in Creating WebLogic Domains and Domain Templates for more information about creating a template.
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.
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
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.
You start Managed Servers in the Administration Console.
To start Managed Servers:
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 Administration Console to start it).
You configure clusters to use messaging so that they can communicate whether or not services are available and other information.
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.
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 126.96.36.199 and 188.8.131.52. (Weblogic uses default value of 184.108.40.206).
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.
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:
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.
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.
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.