This chapter describes the steps for scaling out a topology (machine scale-out) for all Fusion Middleware products that are a part of a Fusion Middleware 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 the consumers of your deployed applications if one computer goes down.
This chapter includes the following topics:
Section 7.7, "Configuring WLS JMS After Machine Scale Up or Scale Out"
Section 7.14, "Configuring Multicast Messaging for WebLogic Server Clusters"
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. For more information on scaling up your environment, see "Scaling Up Your Environment" in the guide Oracle Fusion Middleware Administering Oracle Fusion Middleware.
The following table describes the typical steps you must take to scale out a topology.
Table 7-1 Roadmap for Scaling Out Your Topology
| Task | Description | More Information |
|---|---|---|
|
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 |
Section 7.7, "Configuring WLS JMS After Machine Scale Up or Scale Out" |
|
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) |
Section 7.14, "Configuring Multicast Messaging for WebLogic Server Clusters" |
Note:
In this section, APPHOST refers to a physical host computer, and machine refers to the WebLogic Server machine definition describing that host. See "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" in the guide Installing and Configuring the Oracle Fusion Middleware Infrastructure.
Following the standard installation topology results in 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 it can meet a variety of 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, as additional computing resources are required. An additional benefit of this approach is that it facilitates troubleshooting; you can validate the basic domain then perform and troubleshoot scale up and scale out steps 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 simply perform the pack and unpack steps.
If you have already assigned Managed Servers to their target machines, either in the initial installation process or through an online administrative operation, simply skip Section 7.6, "Creating a New Machine" as you progress through the roadmap (Table 7-1, "Roadmap for Scaling Out Your Topology").
See the product installation guides, such as Installing and Configuring the Oracle Fusion Middleware Infrastructure, for more information 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 serves as 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 the topic "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" describes in the guide Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
See Also:
For more information on the standard installation topology, see your product's installation guide or "About the Standard Installation Topology" in the guide Planning an Installation of Oracle Fusion Middleware.
Before you scale out the topology, verify that your environment meets these requirements:
At least one machine running 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 WebLogic Server instances that they host.
Follow these steps to create a new machine:
The server must be in a shutdown state before moving to a new machine. If the server 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 create a new machine using WLST commands see "Creating a New Machine for Certain Components" in the guide 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 using the Administration Console, perform the following steps:
If the domain Administration Server is not running, you must start it. Go to the DOMAIN_HOME/bin directory and run:
./startWeblogic.sh
After the Administration Server is up and running, access the WebLogic Server Administration Console. Open a web browser and enter the URL:
http://hostname:port/console
On the Welcome screen, log in.
In the Change Center of the Administration Console, 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.
Click Finish.
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 the newly-created machine, use the Administration Console to perform the following steps:
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 on the right shows all servers in the domain and their machine assignments.
This section describes the steps to configure JMS after machine scale up or scale out.
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 one of the existing Managed Servers 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. Oracle recommends that you follow the same naming pattern for manageability and usability.
To configure JMS resources on a new Managed Server server_n:
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, server_1.
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, UMSJMSServer_auto_1 and UMSJMSFileStore_auto_1.
Click New to create a new JMS server.
Name the JMS server for server_n using the same format as server_1. For example, UMSJMSServer_auto_n.
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 persistent store for server_1. For example, UMSJMSFileStore_auto_n.
In the Target field, select the migratable target for migratable target server_n (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 will have a common root. For example for the 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.
Navigate 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.
When you complete these steps, a new Managed Server that includes configured JMS resources is available in the cluster.
Note:
See Section 10.1.1, "Configuring Oracle BAM Managed Server JMS System Resources After Scale Up" to configure WLS JMS for Oracle BAM components. Section 10.1.1 describes additional steps that you must complete for Oracle BAM components after you configure JMS system resources.
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.
Run the pack command on APPHOST1 to create a template pack. You will unpack the template file on APPHOST2 later in the scale out process; Section 7.10, "Running Unpack to Transfer the Template" describes the unpack procedure.
For example:
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 are creating with the pack command. For example: mydomain.jar.
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:
DOMAIN_HOME/bin/startNodeManager.sh &
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 the guide Oracle Fusion Middleware Administering Oracle Fusion Middleware.
To determine if the machine scale out succeeded, verify that the server status has changed to RUNNING after you start it using the Administration Console.
This section describes the steps to configure Multicast messaging for WebLogic Server cluster communication.
Clusters use messaging to broadcast the availability of services and heartbeats that indicate continued availability. You can configure clusters to use either Unicast or Multicast messaging.
Multicast is a simple broadcast technology that enables multiple applications to subscribe to a given IP address and port number and listen for messages. Multicast is more complex to set up; it requires hardware configuration and support.
Unicast provides TCP-based, reliable, one-to-many communication for cluster messaging and is easier to set up in comparison to multicast.
When you create clusters in the Configuration Wizard, Unicast is the default cluster messaging mode. When the number of servers increases in a domain, Multicast messaging is preferable.
This section includes the following topics:
Requirements for configuring Multicast messaging include the following:
A configured domain with at least one cluster.
A hardware configuration that is 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 224.0.0.0 and 239.255.255.255. (Weblogic uses default value of 239.192.0.0).
You have run the MulticastTest utility to verify that your environment can support multicast. The MulticastTest utility helps you debug multicast problems when you configure a cluster. The utility sends out multicast packets and returns information about how effectively multicast is working on your network.
See Also:
See "Communications In a Cluster" in the guide Administering Clusters for Oracle WebLogic Server for more information on Multicast messaging and cluster configuration.
To configure Multicast Messaging:
Log in to the Administration Console.
Shut down all servers for which you want to use Multicast messaging.
In the Domain Structure pane on the left, expand Environment and click Clusters.
Select the cluster name for which you want to enable Multicast.
Click on Configuration tab then the Messaging tab.
For Messaging Mode, select Multicast. Enter the Multicast Address then enter the Multicast Port.
The Multicast Address must be unique for each cluster. See "Cluster Multicast Address and Port" in the guide Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server for guidelines on Multicast addresses.
Click Advanced to configure the following parameters:
Table 7-2 Multicast Advanced Parameters
| Parameter | Description |
|---|---|
|
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. |
|
Multicast TTL |
Number of network hops (between 1 and 255) that a cluster multicast message is allowed to travel. If your cluster spans multiple subnets in a WAN, the value of this parameter must be high enough to ensure that routers do not discard multicast packets before they reach their final destination. This parameter sets the number of network hops a multicast message makes before the packet can be discarded. |
|
Multicast Buffer Size |
The multicast socket send/receive buffer size (at least 64 kilobytes). |
|
Idle Periods Until Timeout |
Maximum number of periods that a cluster member will wait before timing out a member of a cluster. |
|
Enable Data Encryption |
Enables multicast data encryption. Only multicast data is encrypted; Multicast header information is not encrypted. |
Click Save.
Restart all servers in the cluster.
The cluster is ready to use Multicast messaging. When you select Clusters in the Domain Structure pane in the Administration Console, Multicast appears for the Cluster Messaging Mode.