Topics:
Scalability is the ability of a system to provide throughput in proportion to, and limited only by, available hardware resources. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.
The growth of computational power within one operating environment is called vertical scaling. Horizontal scaling is leveraging multiple systems to work together on a common problem in parallel.
Oracle Fusion Middleware scales both vertically and horizontally.
Oracle Fusion Middleware provides great vertical scalability, allowing you to add more Managed Servers or components to the same host. This is known as scale up.
Horizontally, Oracle Fusion Middleware can provide failover capabilities to another host computer. That way, if one computer goes down, your environment can continue to serve the consumers of your deployed applications. This is also known as scaling out or machine scale out. For information about see Scaling Out a Topology in the Oracle Fusion Middleware High Availability Guide.
Deploying a high availability system minimizes the time when the system is down (unavailable) and maximizes the time when it is running (available). Oracle Fusion Middleware is designed to provide a wide variety of high availability solutions, ranging from load balancing and basic clustering to providing maximum system availability during catastrophic hardware and software failures.
High availability solutions can be divided into two basic categories: local high availability and disaster recovery. For more information, see:
Introduction to High Availability in Oracle Fusion Middleware High Availability Guide
Overview of Oracle Fusion Middleware Disaster Recovery in Oracle Fusion Middleware Disaster Recovery Guide
When you extend a domain, the domain must be offline.
To extend a domain, you use the Oracle WebLogic Server Configuration Wizard from an Oracle home into which the desired component has been installed. Then, you select the domain that you want to extend and the component you want to add. For detailed information, see "Configuring Your WebLogic Domain" in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
For example, to extend a domain that initially was created to support Oracle Application Development Framework so that it can now also support Oracle HTTP Server:
You can add Managed Servers to a domain to increase the capacity of your system. The Managed Servers can be added to a cluster.
When a Managed Server is added to a cluster, it inherits the applications and services that are targeted to the cluster. When a Managed Server is not added as a part of a cluster, it does not automatically inherit the applications and services from the template.
To add a Managed Server to a domain, you can use Fusion Middleware Control, the Oracle WebLogic Server Administration Console, or WLST.
To add a Managed Server to a domain using the Fusion Middleware Control:
Oracle JRF (Java Required Files) consists of those components not included in the Oracle WebLogic Server installation and that provide common functionality for Oracle business applications and application frameworks.
Oracle JRF consists of several independently developed libraries and applications that are deployed into a common location. The components that are considered part of Java Required Files include Oracle Application Development Framework shared libraries and ODL logging handlers.
You must apply the JRF template to a Managed Server or cluster in certain circumstances. You can only apply JRF to Managed Servers that are in a domain in which JRF was configured. That is, you must have selected Oracle JRF in the Configuration Wizard when you created or extended the domain.
Note the following points about applying JRF:
When you add a Managed Server to an existing cluster that is already configured with JRF, you do not need to apply JRF to the Managed Server.
If you create a server using Fusion Middleware Control, the JRF template is automatically applied.
When you add a Managed Server to a domain and the Managed Server requires JRF services, but the Managed Server is not part of a cluster, you must apply JRF to the Managed Server.
When you create a new cluster and the cluster requires JRF, you must apply JRF to the cluster.
You do not need to apply JRF to Managed Servers that are added by product templates during the template extension process (though you must select JRF in the Configuration Wizard).
You must restart the server or cluster after you apply JRF.
Note that if you start the server or cluster using Node Manager (for example, through the Administration Console, which uses Node Manager), you must set the Node Manager property startScriptEnabled
to true
. For more information, see Configuring Node Manager to Start Managed Servers.
The format of the applyJRF command is:
applyJRF(target={server_name | cluster_name | *}, domainDir=domain_path, [shouldUpdateDomain= {true | false}])
You can use the applyJRF
command online or offline:
In online mode, the JRF changes are implicitly activated if you use the shouldUpdateDomain
option with the value true
(which is the default.) In online mode, this option calls the online WLST save() and activate() commands.
In offline mode, you must restart the Administration Server and the Managed Servers or cluster. (In offline mode, if you specify the shouldUpdateDomain
option with the value true
, this option calls the WLST updateDomain() command.)
For example, to configure the Managed Server server1 with JRF, use the following command:
applyJRF(target='server1', domainDir='DOMAIN_HOME')
To configure all Managed servers in the domain with JRF, specify an asterisk (*) as the value of the target
option.
To configure a cluster with JRF, use the following command:
applyJRF(target='cluster1', domainDir='DOMAIN_HOME')
For additional information, see:
Java Required Files Custom WLST Commands in the Oracle Fusion Middleware WLST Command Reference for Infrastructure Components
Using a Different Version of Spring to use a different version of Spring than that which is supplied with JRF
You can create a cluster of Managed Servers using WLST, the Oracle WebLogic Server Administration Console, or Fusion Middleware Control. This section describes how to create a cluster using Fusion Middleware Control.
To create a cluster of two Managed Servers, wls_server1 and wls_server2:
Now, you have a cluster with two members, wls_server1 and wls_server2.
See Understanding WebLogic Server Clustering in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server for more information about clusters.
You can configure elastic scaling for dynamic clusters. Elastic scaling adds or removes dynamic server instances on demand or based on certain conditions.
Elasticity allows you to configure elastic scaling for a dynamic cluster based on either of the following:
Manually adding or removing a running dynamic server instance from an active dynamic cluster. This is called on-demand scaling. You can perform on-demand scaling using the Fusion Middleware component of Enterprise Manager, the WebLogic Server Administration Console, or the WebLogic Scripting Tool (WLST).
Establishing policies that set the conditions under which a dynamic cluster should be scaled up or down and actions that define the scaling operations themselves. When the conditions defined in the scaling policy occur, the corresponding scaling action is triggered automatically.
Dynamic clusters consist of server instances that can be dynamically scaled up to meet the resource needs of your application. A dynamic cluster uses a single server template to define configuration for a specified number of generated (dynamic) server instances. When you create a dynamic cluster, the dynamic servers are preconfigured and automatically generated for you, enabling you to easily scale up the number of server instances in your dynamic cluster when you need additional server capacity.
For more information about elasticity and dynamic clusters, see What is Elasticity? in Oracle Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server.
You can create a standalone domain for system components, such as Oracle HTTP Server, using the Configuration Wizard as described in Configuring Oracle HTTP Server in a Standalone Domain in Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server.
Alternatively, you can use WLST to create a standalone domain, that contains a system component, for example, for Oracle HTTP Server:
You can create a system component instance, such as Oracle HTTP Server, in a WebLogic Server domain using the Configuration Wizard as described in Configuring Oracle HTTP Server in a WebLogic Server Domain in Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server.
Alternatively, you can create a system component instance, for example Oracle HTTP Server in the following ways:
Using Fusion Middleware Control. For example, to create an Oracle HTTP Server instance, see Creating an Instance by Using Fusion Middleware Control in Oracle Fusion Middleware Administering Oracle HTTP Server.
For Oracle HTTP Server using the WLST createOHSInstance command, as described in Creating an Instance by Using WLST in Oracle Fusion Middleware Administering Oracle HTTP Server.
Using WLST commands, as described in this section.
This section describes how to create a system component instance using WLST commands. It uses Oracle HTTP Server as an example and assumes that you have created a WebLogic Server domain that contains Oracle JRF.
You can copy an Oracle home and a domain to a different location while preserving its configuration. When you do so, many of the Oracle Fusion Middleware components are also copied. Some situations in which copying Oracle Fusion Middleware is useful are:
Creating an Oracle home that is a copy of a production, test, or development environment, enabling you to create a new Oracle home or component with all patches applied to it in a single step. This is in contrast to separately installing, configuring and applying any patches to separate components.
Preparing a "gold" image of a patched home and deploying it to many hosts.
For information about the procedures you use to copy an Oracle home and domain, see Moving from a Test to a Production Environment.