| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.3) Part Number E14496-04 |
|
|
View PDF |
| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.3) Part Number E14496-04 |
|
|
View PDF |
This chapter describes how to configure Oracle Fusion Applications for high availability and how to scale out an Oracle Fusion Applications environment.
This chapter contains the following topics:
Introduction to Oracle Fusion Applications High Availability Architecture
Oracle WebLogic Cluster Configuration for Oracle Fusion Applications
Oracle RAC Database Configuration for Oracle Fusion Applications Repositories
The following appendixes describe additional high availability topics:
Appendix A, "High Availability for Oracle Fusion Middleware Extensions for Applications"
Appendix B, "High Availability for Oracle Enterprise Scheduler"
For information about configuring high availability for Oracle Fusion Middleware products such as Oracle WebLogic Server, Oracle SOA Suite, Oracle Identity Management, and Oracle Business Intelligence, see the Oracle Fusion Middleware High Availability Guide.
Providing high availability for Oracle Fusion Applications involves configuring an Oracle WebLogic cluster for high availability of the middle tiers and configuring Oracle Real Applications Clusters (Oracle RAC) for high availability of the Oracle Database. It also involves scaling out Oracle Fusion Applications and Oracle RAC database instances.
Oracle Fusion Applications is built on standards-based Oracle Fusion Middleware. Therefore, it benefits from the high availability solutions for Oracle Fusion Middleware.
Characteristics of an Oracle Fusion Applications high availability configuration are:
Oracle Fusion Applications are Oracle Application Development Framework (Oracle ADF) applications running on Oracle WebLogic Server Clusters.
Oracle Fusion Applications connect to Oracle RAC databases using multi data sources.
Oracle Fusion Applications use Enterprise JavaBeans (EJBs) for inter-cluster communication within the same domain.
Oracle Fusion Applications use Web services for inter-domain communication.
Oracle Fusion Applications use the Java Message Service (JMS) operational interface (shared interfaces) to Oracle Streams Advanced Queueing (AQ), known as AQ JMS, for inter-domain communication.
This chapter assumes that you have a basic understanding of high availability concepts such as active-active deployments, active-passive deployments, and disaster recovery deployments. For information about these concepts, see the "Oracle Fusion Middleware High Availability Framework" chapter in the Oracle Fusion Middleware High Availability Guide.
See the following documentation resources to learn more about high availability for Oracle Fusion Middleware and Oracle Database:
Oracle Fusion Applications runs on Oracle WebLogic Server. During an Oracle Fusion Applications installation, each individual product family installs into its own WebLogic Server domain. At the time of provisioning, a WebLogic cluster (with one Oracle WebLogic Server) is created for each Java EE application that is part of the product family. If you want to scale out any of the Java EE applications, new Managed Servers can be added to the application's WebLogic cluster.
For more information about Oracle WebLogic Server clustering, see the "High Availability for WebLogic Server" chapter in the Oracle Fusion Middleware High Availability Guide.
This section provides a description of the single instance architecture of Oracle Fusion Applications, and then provides information that helps you deploy Oracle Fusion Applications in a high availability configuration.
If you have not already done so, read Chapter 1 for an introduction to:
Oracle Fusion Applications
Oracle Fusion Applications product families and components
Key Oracle Fusion Applications concepts
Figure 1-1 shows an Oracle Fusion Applications single instance architecture. These are stateful applications that maintain session state.
Oracle Fusion applications are built using the following technologies:
ADF, Oracle Middleware Extensions for Applications (Applications Core), and Oracle WebCenter framework, which run as JavaEE applications on WebLogic Server
Clustered EJBs. Inter-cluster communication within one domain is done using EJBs. Inter-cluster communication across different domains is done using web services (SOAP).
Event Delivery Network (EDN) queues are used for event propagation. EDN uses Advanced Queueing (AQ) database queues.
This section contains the following topics that describe high availability details:
The following lists shows some of the external entities that Oracle Fusion Applications depends on that are relevant from a high availability perspective:
Oracle Fusion Applications repository database
Oracle Metadata Service (MDS) repository database
Oracle Enterprise Scheduler Service (ESS) repository database and queues
EDN data source (AQ queues)
Identity Management infrastructure (for authentication/authorization)
LDAP store for users, roles, and policies.
Oracle Business Intelligence Foundation, which includes Essbase
Web Services invocation (mostly asynchronous)
Java Message Service (JMS), for Asynchronous Web Services invocation
Oracle Data Integrator (for replication framework)
Oracle Universal Content Management system
Note:
When you configure Oracle Identity Manager for Fusion Applications in a high availability environment, Oracle recommends that you use Multimaster Replication. See Setting up Multimaster Replication.
All Oracle Fusion Applications components run as JavaEE applications in WebLogic Server and do not start a process of their own. Standard WebLogic tools such as the Administration Console, Oracle WebLogic Scripting Tool (WLST), and Oracle Enterprise Manager Fusion Middleware Control start, stop, and manage the applications.
Oracle Fusion Applications also has C components such as Oracle Global Order Promising (GOP) and the Bounce Handling Daemon. Oracle Process Manager and Notification Server (OPMN) manage these.
The typical client HTTP request goes from the web browser or Web Services client to Oracle HTTP Server to JDBC/RMI/WS (HTTP). Table 16-1 shows the Oracle Fusion Applications clients, the protocols they use to connect, and their high availability configuration.
Table 16-1 Oracle Fusion Applications Client Connection Protocols for High Availability
| Client | Connection Protocol | High Availability Configuration |
|---|---|---|
|
Web browser |
HTTP |
Load balancer |
|
ESS |
HTTP (WS SOAPFoot 1 over HTTP) |
Load balancer |
|
Web Services invocation |
HTTP (WS SOAP over HTTP) |
Load balancer |
|
Inter-cluster communication |
EJB (RMIFoot 2 over T3) |
Clustered provider URL |
|
Oracle Data Integrator |
JDBCFoot 3 |
Oracle RAC/multi data source |
Footnote 1 Web Services Simple Object Access Protocol
Footnote 2 Remote Method Invocation
Footnote 3 Java Database Connectivity
All configuration for Oracle Fusion Applications is stored in the Oracle Fusion Applications repository database or MDS repository.
Configuration for Oracle WebLogic is stored in the domain configuration.
The Oracle Fusion applications are deployed using the nostaged deployment model. This allows you to install a single copy of the Oracle Fusion Applications binaries on a NAS or SAN shared storage and then run Fusion Applications from multiple computers using that single copy on the shared storage. Typically, application extensions get deployed on a different Managed Server than the application itself.
For detailed information about Oracle Fusion Applications log file locations, see Section 13.6.4.
Figure 16-1 shows the high availability architecture of an Oracle Fusion Applications cluster deployment.
Figure 16-1 Oracle Fusion Applications High Availability Cluster Deployment
Some of the key characteristics of this architecture are:
It is an active-active clustered architecture.
It stores product binaries on shared storage.
Each computer in the cluster has its own copy of the domain configuration on local storage.
The application tier includes hosts SALESHOST1 and SALESHOST2, which comprise a WebLogic cluster with two Managed Servers running the Sales application.
The WebLogic cluster is front-ended in the web tier by hosts WEBHOST1 and WEBHOST2 running Oracle HTTP Server. Oracle HTTP Server provides sticky routing by default.
It has a hardware load balancer in front of the two Oracle HTTP Servers configured with sticky routing.
The Oracle RAC repository in the data tier has multi data source configuration.
ADF session state replication is enabled by default. The following high availability session state replication settings are enabled out of the box:
In weblogic.xml, the replicate_if_clustered option is specified:
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
In adf-config.xml, the adf-scope-ha parameter is set to true:
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config"> <adf-scope-ha-support>true</adf-scope-ha-support> </adf-controller-config>
In adf-config.xml, the adf-scope-ha-support parameter is set to true:
<adfc:adf-controller-config> <adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support> </adfc:adf-controller-config>
The jbo.dofailover parameter is set to true, either in the startup environment as -D or in the ADF Business Component configuration file (bc4j.xcfg):
<AppModuleConfig ... <AM-Pooling jbo.dofailover="true"/> </AppModuleConfig>
In the setDomainEnv.sh file, change JAVA_PROPERTIES to the following value and then export JAVA_PROPERTIES:
JAVA_PROPERTIES="-Dplatform.home=${WL_HOME} -Dwls.home=${WLS_HOME}
-Dweblogic.home=${WLS_HOME} -Djbo.ampool.doampooling=true"
EJBs used for inter-cluster communication within the same domain deploy uniformly to the WebLogic cluster and leverage WebLogic Server clustering capabilities.
Web services inter-domain communication is routed through the load balancer.
It uses the external dependency high availability configuration that Table 16-1 describes.
This section contains the following topics about Oracle Fusion Applications changes and failover considerations:
Starting and Stopping the Oracle Fusion Applications Cluster
Oracle Fusion Applications Cluster-Wide Configuration Changes
See Section 2.5 for descriptions of the various scenarios for starting and stopping the Oracle Fusion Applications environment.
All Oracle Fusion Applications configuration changes can be done at the cluster level. You do not need to make configuration changes to individual instances in a cluster.
This section describes the different types of failures that can occur in an Oracle Fusion Applications high availability deployment, and the expected behaviors when these failures occur. This section contains the following topics:
Node Manager detects Managed Server failures and restarts the Managed Server automatically. If repeated restart attempts fail, then in case of a simple active-active deployment, surviving cluster members continue to service the request. The ORACLE_INSTANCE/config/OHS/ohsName/mod_wl_ohs.conf file for Oracle HTTP Server redirects user requests to a server which has the replica of the session state. The Node Manager RestartInterval parameter specifies the amount of time Node Manager attempts to start a failed server. The RestartMax parameter specifies the number of times Node Manager attempts to start a failed server. See the Node Manager Properties table in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server for more information about these parameters.
The server promotes the state to primary, creates a replica elsewhere in the cluster, and services the user request.
WebLogic Server clustering provides EJB failover for inter-cluster communication within the domain.
Web services inter-domain communication is routed through the load balancer, which also provides failover.
If a cluster member fails, messages continue to be available to surviving cluster members because AQ JMS is used for inter-domain communication.
When system components fail, OPMN attempts to restart the process in place.
When a computer fails, the expected behavior is the same as for process failure that Section 16.3.2.3.1 describes except that Node Manager and OPMN do not attempt restarts.
This section describes external dependency failures.
Oracle RAC Instance Failure. When an Oracle RAC instance fails, multi data sources and built-in application retry logic provide failover. Under certain circumstances, an Oracle RAC database outage generates the following message on your Web browser:
Encountered database recoverable exception. Please retry your request.
If this message appears, retry the ongoing session after logging in again (if required).
Web Services Provider Failure. If the failure occurs before the Web Services stack is invoked, the application receives an error and can retry. If failure occurs after the acknowledgement is received, then the Asynchronous Web Services infrastructure guarantees a successful response.
If you experience issues with your Oracle Fusion Applications high availability deployment, check the WebLogic Server log. See Section 16.3.1.6 for details.
Oracle Real Application Clusters (Oracle RAC) enables you to cluster servers to provide resilient and scalable access to a database. A cluster comprises multiple interconnected computers or servers that appear as if they are one server to end users and applications. Oracle RAC simultaneously provides a highly available and scalable database for Oracle Fusion Applications.
This section provides an overview of Oracle RAC and information about setting up a highly available deployment for Oracle Fusion Applications configured with an Oracle RAC database as the persistent store for data.
Note:
This chapter discusses configuring Oracle RAC databases only. Other persistent repositories that connect with Oracle Fusion Applications, such as Oracle Hyperion, are configured implicitly and transparently.
For complete information about Oracle RAC, see the Oracle Real Application Clusters Administration and Deployment Guide.
This section contains the following topics:
Providing High Availability for Oracle Fusion Applications Repositories
Best Practices for Deploying JDBC Multi Data Sources on Servers and Clusters
Oracle RAC and Oracle ClusterwareFoot 1 allow the Oracle Database to run any packaged or custom application across a set of clustered servers. This capability provides the highest levels of availability and the most flexible scalability. If a clustered server fails, Oracle Database continues running on the surviving servers. When more processing power is needed, you can add another server without interrupting access to data.
Oracle RAC enables multiple database instances that are linked by an interconnect to share access to an Oracle database. In an Oracle RAC environment, the Oracle Database runs on two or more systems (nodes) in a cluster while concurrently accessing a single shared database. The result is a single database system that spans multiple hardware systems and enables Oracle RAC to provide high availability and redundancy during failures in the cluster. Oracle RAC accommodates all system types, from read-only data warehouse (DSS) systems to update-intensive online transaction processing (OLTP) systems.
The clusters that are typical of Oracle RAC environments can provide continuous service for both planned and unplanned outages. Oracle RAC builds higher levels of availability on top of the standard Oracle features. All single-instance high availability features, such as the Oracle Flashback technologies and online reorganization, also apply to Oracle RAC. Applications scale in an Oracle RAC environment to meet increasing data processing demands without changing the application code. In addition, allowing maintenance operations to occur on a subset of components in the cluster while the application continues to run on the rest of the cluster can reduce planned downtime.
For information about Oracle RAC design and deployment techniques, see the "Design and Deployment Techniques" chapter of the Oracle Real Application Clusters Administration and Deployment Guide.
For information about online application maintenance and upgrades, see the "Online Application and Maintenance and Upgrades" section of Oracle Database High Availability Overview.
Providing high availability requires detailed planning to ensure there are no single points of failure throughout the infrastructure. Even though Oracle RAC makes your database highly available, if a critical application becomes unavailable, then your business can be negatively affected.
For example, because Oracle Fusion Applications uses the Lightweight Directory Access Protocol (LDAP) for authentication, the best practice is to make the LDAP server highly available. If the database is up but the LDAP server is down, users cannot connect to the applications and the entire system appears to be down.
The following sections describe deploying Oracle RAC for high availability in an Oracle Fusion Applications environment:
Use Oracle Fusion Applications provisioning to orchestrate the integration process, including the specification of your Oracle RAC database.
For more information about the provisioning and installation process and installing Oracle Database, see Section 1.2.1.2.
Oracle Fusion Applications support only multi data source configurations for Oracle RAC. Multi data sources encapsulate individual data sources that pool connections to specific instances of Oracle RAC.
A data source is a Java object that application components use to obtain connections to a relational database. Specific connection information, such as the URL or user name and password, are set on a data source object as properties and do not need to be explicitly defined in an application's code. This abstraction allows applications to be built in a portable manner, because the application is not tied to a specific back-end database. The database can change without affecting the application code.
A multi data source is like a pool of data sources that provides failover processing and recovery. It also provides load balancing between nodes of a highly available database system, such as an Oracle RAC database. When an Oracle RAC instance fails, a multi data source determines which data source to use to satisfy application requests. If you are using an Oracle RAC database, you must configure multi data sources.
The data source member list for a multi data source supports dynamic updates. This allows Oracle RAC environments to add and remove database nodes and corresponding data sources without redeployment, and it provides the ability to:
Grow (scale) and shrink Oracle RAC clusters in response to throughput
Shut down Oracle RAC nodes temporarily to perform planned maintenance
See Section 16.4.3 for best practices when configuring multi data sources for Oracle RAC and Oracle Fusion Applications. For more information about using multi data sources with Oracle RAC, see the "Using Multi Data Sources with Oracle RAC" section in the Oracle Fusion Middleware High Availability Guide.
WebLogic Server periodically checks the status of data sources in a multi data source. If an Oracle RAC node or instance fails, application connection requests are managed as follows:
Existing connections
There is no failover of existing connections. In-flight transactions are typically rolled back when the database is the transaction manager. When the WebLogic Server is the Transaction Manager, in-flight transactions are failed over; they are driven to completion or rolled back based on the transaction state at the time of failure.
New connection requests
New session requests are redirected to a working Oracle RAC instance in the cluster, either by Oracle WebLogic Server or by the Oracle Thin driver.
For information about multi data source failover limitations and requirements, see the "Configuring JDBC Multi Data Sources" chapter in Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.
Load balancing involves distributing requests among two or more processes. Oracle WebLogic Server provides a load balancing algorithm for multi data sources. If an application requires load balancing across Oracle RAC nodes, then WebLogic Server supports this capability through the use of JDBC multi data sources that have been configured for load balancing.
WebLogic accesses the data sources that form a multi data source using a round-robin scheme. When switching connections, WebLogic Server selects a connection from the next data source in the order listed.
See Section 16.4.3 for recommendations when configuring load balancing with WebLogic Server.
Under certain circumstances, an Oracle RAC database outage generates the following message:
Encountered database recoverable exception. Please retry your request.
If this message appears, retry the ongoing session after logging in again (if required).
See Section 16.4.3 to configure retry properties with WebLogic Server.
When you create an Oracle Fusion Applications environment using an Oracle RAC database, the provisioning tool configures automatically a multi data source to use each Oracle RAC database instance.
The default configuration uses these best practices that provide optimal availability:
Deploys a multi data source to a cluster or server by selecting the server or cluster as a deployment target in the WebLogic Server Administration Console.
When a multi data source is deployed on a server, WebLogic Server creates an instance of the multi data source on the server. When you deploy a multi data source to a cluster, WebLogic Server creates an instance of the multi data source on each server in the cluster.
Deploys all data sources that are used by a multi data source to satisfy connection requests on the same servers and clusters as the multi data source.
Multi data sources do not route connection requests to other servers in a cluster or in a domain.
Sets the load-balancing properties as shown in Table 16-2.
If the data sources require support for non-XA drivers, then the properties for the individual data sources are set as shown in Table 16-3.
Table 16-3 Recommended Data Source Property Settings for Non-XA Drivers
| Property Name | Recommended Value |
|---|---|
|
Driver |
|
|
Property command |
< < < < |
|
connection-creation-retry-frequency-seconds |
|
|
test-frequency-seconds |
|
|
test-connections-on-reserve |
|
|
test-table-name |
|
|
seconds-to-trust-an-idle-pool-connection |
|
|
global-transactions-protocol |
|
For more information about configuring JDBC multi data sources, see "Configuring JDBC Multi Data Sources" in Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.
Scale-out enables organizations to improve application performance, scalability, and availability on an incremental, as-needed basis by adding multiple replicated servers.
Oracle Fusion Applications is always deployed in a cluster. Even in a single instance deployment, the Oracle Fusion Applications instance is part of a cluster with one member.
You can use a scale out operation to move from a non-high availability deployment to a high availability deployment. You can scale up or scale out the Oracle Fusion Applications topology. When you scale up the topology, you add a new Managed Server to computers that are already running one or more Managed Servers. When you scale out the topology, you add a new Managed Server to new computers.
Before you run scale up or scale out steps, check that you meet these requirements:
There must be at least one existing computer running at least one Managed Server configured with Oracle Fusion Applications within the topology. The computer contains an APPLICATIONS_BASE home directory (/oracle in Figure 1-6) and an Oracle Fusion Applications Middleware home directory (/oracle/fusionapps in Figure 1-6) in shared storage.
The computer on which the new Managed Server is deployed can access the existing home directories for Oracle Fusion Applications. Use the existing installations in shared storage for creating a new Managed Server.
For scale up, you do not need to install Oracle Fusion Applications binaries in a new location, and you do not need to run pack and unpack to bootstrap the domain configuration.
For scale out, you must run pack and unpack to bootstrap the domain configuration in the new computer.
Note:
The steps below assume that Oracle Fusion Applications clusters such as the Sales cluster do not use WebLogic JMS or XA.
The scale up steps for Oracle Fusion Middleware components such as Oracle SOA Suite and Oracle WebCenter are in the scale up section of the component's chapter in the Oracle Fusion Middleware High Availability Guide. Scale out steps for Oracle Fusion Middleware components such as Oracle SOA and Oracle WebCenter are in the scale out section of the component's chapter in the Oracle Fusion Middleware High Availability Guide. To make Oracle HTTP Server highly available, see the Oracle HTTP Server chapter in the Oracle Fusion Middleware High Availability Guide.
This section includes the following topics:
In this case, you have a computer that runs a Managed Server configured with Oracle Fusion Applications components and you want to add another Managed Server to that computer. Use the steps in this section to add a second Managed Server to a computer and to add subsequent Managed Servers on that computer.
Follow these steps to scale up the topology. This example uses the Oracle Fusion Customer Relationship Management application; you can also use these steps to scale up other Oracle Fusion Applications clusters:
Using the Administration Console, clone the source Managed Server (for example, SalesServer1) into a new Managed Server. The source Managed Server to clone should be one that already exists on the computer where you want to run the new Managed Server.
To clone a Managed Server:
Select Environment -> Servers from the Oracle WebLogic Server Administration Console.
Select the Managed Server that you want to clone (for example, SalesServer1).
Select Clone.
Name the new Managed Server server_nameN (for example, SalesServer2), where N is a number to identify the new Managed Server.
For the listen address, assign the host name to use for this new Managed Server.
Ensure that the port number (9001, in this example, so as not to conflict with the current port 8001 that the existing Managed Server, SalesServer1, uses) for the new Managed Server is not used on this computer.
Update the cluster address to include the new server:
Select Environment -> Cluster from the Administration Console.
Click on the Sales_Cluster server.
In the Change Center, click Lock & Edit.
Add the new server's address and port to the Cluster Address field. For example:
SALESHOST1:8001,SALESHOST1:9001
Disable host name verification for the new Managed Server. Before starting and verifying the SalesServern Managed Server, you must disable host name verification. You can re-enable it after you configure server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SALESHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required; the hostname verification setting propagates to the cloned server.
To disable host name verification:
Start the Oracle WebLogic Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers.
Select SalesServern in the Names column of the table in the Summary of Servers page.
Click the SSL tab in the Settings page for the server.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Change JDBC LLR Table Name:
In the Oracle EM, expand the Environment node in the Domain Structure window
Click Servers.
Select the scaled out server.
In the General tab, click Advanced.
Change the JDBC LLR Table Name to the next higher number so that it doesn't conflict with the number of the original server.
Click Save.
Ensure that the Node Manager is running on the computer. To start the Node Manager, use the installation in shared storage from the existing computer and start Node Manager by passing the host name of the computer as a parameter as follows:
SALESHOST1> WL_HOME/server/bin/startNodeManager computer_ip
Start and test the new Managed Server from the Oracle WebLogic Server Administration Console:
Ensure that the newly created Managed Server (SalesServer2 in this example) is running.
Access the application on the newly created Managed Server (http://SALESHOST1:9001/sales/faces/index). The application should be functional.
Configure Oracle HTTP Server to route to the Administration Server that contains the new Managed Server; set the WebLogicCluster parameter to the list of computers in the cluster. Follow these steps for all Oracle HTTP Server hosts in your deployment:
cd to the following directory in the Web Tier configuration home:
(UNIX) APPLICATIONS_BASE/instance/SetupDomain_webtier/config/OHS/ohs1/ moduleconf (Windows) APPLICATIONS_BASE\instance\CommonDomain_webtier\config\OHS\ohs1\ moduleconf
Create a backup of the FusionVirtualHost_crm.conf file and then make these edits to the file (the example is for the Sales server):
<Location /sales>
SetHandler weblogic-handler
WebLogicCluster SALESHOST1:8001,SALESHOST1:9001
</Location>
Where portn is a different port number than the port used for the first Managed Server.
Restart the Oracle HTTP Server by following these steps:
(UNIX) cd APPLICATIONS_BASE/instance/SetupDomain_webtier/bin
opmnctl stopall
opmnctl startall
(Windows) cd APPLICATIONS_BASE\instance\SetupDomain_webtier\bin
opmnctl stopall
opmnctl startall
Check that both the SALESHOST1:8001/sales/faces/index and SALESHOST1:9001/sales/faces/index are accessible.
Check the Sales servers from Oracle HTTP Server:
WEBHOST1:7777/sales/faces/index
This example assumes 7777 is being used for the Oracle HTTP Server port.
Login to the WebLogic Server Administration Console and navigate to CRMDomain > Environments > Servers.
To test the routing from Oracle HTTP Server to the new Managed Server.
If desired, shut down the existing Managed Server (in this case, SalesServer1).
Access the application using WEBHOST1:7777/sales/faces/index through the web server, which should access the application on the new Managed Server (in this case, SalesServer2).
This step should show that Oracle HTTP Server routed the request to the new Managed Server (SalesServer2) while SalesServer1 was down, and that SalesServern serviced the request.
If you have not already done so, restart the Managed Server that you shut down.
When you scale out the topology, you add new Managed Servers configured with Oracle Fusion Applications to new computers where no Oracle Fusion Applications Managed Servers are configured.
You scale out the topology using Enterprise Manager Cloud Control. Benefits of Cloud Control include:
Ease of use. Cloud Control automatically completes the provisioning and deployment processes. It gives you all the information you need about a Fusion Instance, Fusion Product Family, Fusion Product, and Fusion Application instances.
Increased reliability. The Cloud Control process uses a job system to automatically and regularly rediscover WebLogic domains.
Enhanced interface. Home pages enable you to monitor instances and product families at a glance. The interface makes transparent the relationship between the server and application deployment details. Cloud Control shows cluster applications from a product perspective.
Enterprise Manager Cloud Control enables you scale out a Fusion Product or a specific Fusion Application by:
Provisioning a new WebLogic Server instance within the cluster
Deploying an instance of the Fusion Application on the new WebLogic Server instance
There are two ways to scale out Fusion Applications:
To scale out a Fusion Product Family, Product, or Fusion Cluster Application target, see "Scaling Out a Fusion Product Family, Product, or Fusion Cluster Application Target".
To scale out a Fusion Instance target, seethe topic "Fusion Application Instance Scale Out - Scale Out Selections" in the Cloud Control online help.
Scaling Out a Fusion Product Family, Product, or Fusion Cluster Application Target
After you provide the information required to provision the new WebLogic Server instance, Enterprise Manager invokes a deployment procedure to automatically complete the provisioning and deployment processes.
To scale out a Fusion Product Family, Product, or Fusion Cluster Application target:
From the Targets menu, choose Fusion Applications to open the Fusion Applications target home page.
Select one of the following: Fusion Product Family, Product, or Fusion Cluster Application.
Choose Provisioning > Scale Out from the Product Family, Product, or Fusion Cluster Application menu for the selected target.
Click on the Fusion Product or Fusion Application you want to scale out in the topology view in the region on the left.
Note that some Fusion Products may be associated with up to two Fusion Applications in the topology view.
The WebLogic Server cluster(s) that the selected Fusion Product or Fusion Application is currently deployed appears in the region on the right.
Click Scale Out in the row for a cluster you want to add an instance to.
Enter the credentials for the Administration Server user in the WebLogic Domain Administrator Username and Password fields.
The Administration Server is a WebLogic Server instance that manages the WebLogic Server domain the cluster belongs to.
Specify a directory to store temporary data files during the scale out operation in the Administration Host Server Working Directory field; for example, /tmp.
Enter the credentials required to access the Administration Server host.
Specify the following for the new WebLogic Server instance:
The hostname for the host that the instance will be provisioned to.
A unique identifier for the new instance.
The port that the instance will use.
Click Configure More Details.
Enter any additional information required to access the host machine that the new WebLogic Server instance will be created on. Required information includes:
The credentials required to access the host.
The directory to store temporary data files during the scale out operation; for example, /tmp
The port that the WebLogic Server instance will use.
Click OK.
Click Scale Out.
Enterprise Manager creates a Deployment Procedure job to provision the new WebLogic Service instance, add it to the cluster, and deploy the Fusion Application instance to it.
Note:
Follow the preceding steps to scale out infrastructure applications (SOA, ESS).
This section provides guidance on how to add nodes to existing Oracle RAC environments by using Oracle cloning, and then configuring the multi data source to route database requests to the new Oracle RAC instance.
This section contains the following topics:
Cloning Oracle RAC Nodes to Scale Out Oracle Fusion Applications
Configuring the Multi Data Source to Include New Oracle RAC Nodes
The Oracle RAC cloning procedures assume that you successfully installed and configured an Oracle RAC environment that you want to add nodes and instances to. To add nodes to an Oracle RAC environment using cloning, you must first extend the Oracle Clusterware configuration, then extend the Oracle Database software with Oracle RAC, and then add the listeners and instances by running the Oracle assistants.
For more information about cloning nodes within the same cluster, see the chapter about "Using Cloning to Extend Oracle RAC to Nodes in the Same Cluster" in Oracle Real Application Clusters Administration and Deployment Guide.
For Oracle cloning that is specific to UNIX system environments, see the chapter about "Adding and Deleting Oracle RAC from Nodes on Linux and UNIX Systems" in Oracle Real Application Clusters Administration and Deployment Guide.
For Oracle cloning that is specific to Windows system environments, see the chapter about "Adding and Deleting Oracle RAC from Nodes on Windows Systems" in Oracle Real Application Clusters Administration and Deployment Guide.
After adding an Oracle RAC node to the database cluster as a part of scaling out the database, you must configure the multi data source to route database requests to the new Oracle RAC instance. You do this by adding a data source to each of the multi data sources that will route database requests to the newly added instance of the database.
Note:
Verify that the property values of the data source that you add match the property values in the other peer data source of the multi data source. See Table 16-3, "Recommended Data Source Property Settings for Non-XA Drivers" for a list of property values.
The example configures a multi data source with the properties shown in Table 16-4 but you can substitute the names and properties to scale any Oracle Fusion Applications cluster.
Table 16-4 Multi Data Source Example to Scale Out Oracle RAC with Oracle Fusion Applications
| Property Name | Property Value |
|---|---|
|
name |
ApplicationDB |
|
Jndi-name |
jdbc/ApplicationDBDS |
|
Data Sources |
ApplicationDB01, ApplicationDB02 |
|
Target |
Sales_Cluster |
To configure the new Oracle RAC instance in a multi data source:
Log in to the Oracle WebLogic Administration Console.
Create a new data source, as follows:
Navigate to domain_name > Services > Data Sources
For example, navigate to CRM_Domain > Services > Data Sources.
In the Change Center, click Lock & Edit (if needed).
On the Summary of JDBC Data Sources page, click New to create a new data source. (Choose Generic Data Source.)
In the Name field, enter the name of the computer (ApplicationDB03) and enter the JNDI Name. The Database Type is Oracle.
Click Next.
For the Database Driver, choose the driver of type Thin and RAC Server-Instance Connection.
On the next screen, add details for this data source by providing Oracle RAC instance details for the new Oracle RAC instance, plus other properties matching its peer datasource in the Multi Data Source.
Click Finish.
In the Change Center, click Activate Changes.
In the Change Center, click Lock & Edit.
Navigate to domain_name > Services > Data Sources.
On the Summary of JDBC Data Sources page, choose the multi data source ApplicationDB.
On the right-hand pane for Settings for ApplicationDB, click the Data Sources tab.
In the Available list, find the newly created data source (ApplicationDB03) and click it to add it to the multi data source.
In the Change Center, click Save and Activate Changes.
Footnote Legend
Footnote 1: Oracle Clusterware is software that enables the servers to be bound together to operate as if they are one server and manages the availability of user applications and Oracle databases.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|