|
Oracle® Application Server High Availability Guide
10g Release 2 (10.1.2) B14003-03 |
|
 Previous |
 Next |
|
Oracle® Application Server High Availability Guide
10g Release 2 (10.1.2) B14003-03 |
|
|
Previous |
Next |
This chapter provides high availability information for the following middle-tier components:
Generally, most middle-tier components are supported on OracleAS Cold Failover Cluster, or active-passive, topologies. However, some components have some conditions that you need to be aware of when running them in OracleAS Cold Failover Cluster topologies. These components include:
See the section for the component for details.
You can run OracleAS Portal in active-active topologies, where you have at least two middle-tier instances running OracleAS Portal. These middle-tier instances are fronted by a load balancer, which distributes requests to the middle tiers.
There are two versions of this topology:
For an enterprise version of this topology, which includes a high availability OracleAS Infrastructure and covers security concerns, see the "myPortalCompany.com" example in the Oracle Application Server Enterprise Deployment Guide.
For a simplified topology that is suitable for internal deployments, see the following guide:
| Item | Name |
|---|---|
| Book | Oracle Application Server Portal Configuration Guide
This book is available in the Oracle Application Server documentation set. |
| Chapter | 5, "Performing Advanced Configuration" |
| Section | "Configuring Multiple Middle Tiers with a Load Balancing Router" |
Highlights of OracleAS Portal in Active-Active Topologies
The load balancer provides a single published URL (example: www.myportal.com) to the client tier. The Internet DNS maps the URL that clients use to the external IP of the load balancer.
The load balancer distributes requests to the instances. The Host: field of the HTTP requests still contain the original URL (www.myportal.com) used by the clients.
In the httpd.conf file in the middle tier homes, the ServerName directive is set to www.myportal.com (and not the physical names of the nodes running the middle tier instances).
Unless your load balancer does port mapping, you should configure the middle tier instances to use the same ports as the load balancer.
You can achieve better cache utilization if you mount a shared file system for the cached files. If you decide not to have the middle tiers share a cache directory, caching will still work, but with a lower hit ratio.
Session Binding for OracleAS Web Clipping Portlet
The session binding feature in OracleAS Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default OracleAS Portal middle-tier are stateless, session binding is required for two reasons:
Web Clipping Studio, used by both the OracleAS Web Clipping Portlet and the Web Page Data Source of OmniPortlet, uses HTTP session to maintain state, for which session binding must be enabled.
Enabling session binding forces all the user requests to go to a given OracleAS Portal middle-tier, resulting in a better cache hit ratio for the OracleAS Portal cache.
For details, see "Step 7: Enable Session Binding on OracleAS Web Cache" in the Oracle Application Server Portal Configuration Guide.
Configuring OracleAS Wireless for high availability is documented in chapter 14, "Load Balancing and Failover", of the Oracle Application Server Wireless Administrator's Guide.
Note that if you want to run OracleAS Wireless in an OracleAS Cold Failover Cluster (Middle-Tier) topology, you need to install the Oracle home for the middle tier on the local storage of each node. OracleAS Wireless is not supported on single Oracle home installations (that is, it is not supported if you install the Oracle home for the middle tier on the shared storage).
OracleAS Reports Services is the reports publishing component of Oracle Application Server. It is an enterprise reporting service for producing high quality production reports that dynamically retrieve, format, and distribute any data, in any format, anywhere. You can use OracleAS Reports Services to publish in both Web-based and non-Web-based environments.
For details on OracleAS Reports Services, see Oracle Application Server Reports Services Publishing Reports to the Web.
Contents of this section:
Section 5.4.2, "OracleAS Reports Services High Availability Features"
Section 5.4.3, "OracleAS Reports Services in Active-Active Configurations"
Section 5.4.4, "OracleAS Reports Services in Active-Passive Configurations"
OracleAS Reports Services runs as a set of processes in an Oracle Application Server middle-tier instance. These processes handle requests from clients, prepare reports, submit requests to a database, and deliver the result back to the client. The primary OracleAS Reports Services processes are:
Table 5-1 Primary Processes for OracleAS Reports Services
| Process | Description |
|---|---|
|
Reports client |
A Reports client connects to a Reports Server. The client can be a command-line client ( |
|
Reports servlet |
The Reports servlet directs requests to a specific Reports Server. The servlet runs under OC4J. |
|
Reports Server |
The Reports Server is responsible for interpreting the request and spawning one or more Reports Engine to fulfill the request. The Reports Server can run as a standalone process or within the OC4J process. If run within the OC4J process, it is called an "in-process Reports Server". If run as a standalone process, it does not need to run on the Oracle Application Server middle-tier node where you installed the OracleAS Reports Services component. |
|
Reports Engine |
The Reports Engine handles individual requests. It connects to the database as required. The Reports Engine fulfills the request and informs the Reports Server upon completion. |
Figure 5-1 shows the interaction between these processes.
Figure 5-1 Processes for OracleAS Reports Services
OracleAS Reports Services has the following high availability features:
The in-process Reports Server is managed by OPMN via "urlping-parameters". If for some reason the oc4j_bi_forms instance is restarted, the Reports Server will also be restarted and become available once the oc4j_bi_forms instance is up.
The standalone Reports Server is managed by OPMN as a component. If the Reports Server fails or is stopped unexpectedly, OPMN restarts it automatically. Upon installation, the default Reports Server will be automatically configured to be managed by OPMN. If you add new Reports Servers, you must configure them manually so that OPMN can manage them. These configuration instructions are in the documentation.
If you use the Reports Bridge, you should also configure it so that OPMN can manage it. Instructions for configuring the Reports Bridge with OPMN are provided in the documentation.
If components that OracleAS Reports Services is trying to connect to are unavailable, OracleAS Reports Services has the following features:
If the connection from the Reports Server to the OracleAS Portal database schema is dropped for some reason, then the Reports Server tries to reestablish the connection before generating an error. It retrieves the OracleAS Portal connection string from the OracleAS Metadata Repository and attempts to reconnect. If reconnection is successful, you do not need to restart the Reports Server.
If the Oracle Internet Directory connection becomes stale for some reason, the Reports servlet and the Reports Server try to reestablish the connection before generating errors. If reconnection is successful, you do not need to restart the Reports Server.
The outage of the OracleAS Metadata Repository (which stores security metadata) will not bring down the Reports Server. If the OracleAS Metadata Repository is unavailable, the Reports Server rejects new requests due to one of the component being unavailable. When the OracleAS Metadata Repository is brought back on-line, the Reports Server recovers itself and can begin to receive and process new requests.
If Oracle Identity Management components become unavailable for some reason, the Reports Server will also reject new requests. It has similar characteristics as outage of the OracleAS Metadata Repository.
The Reports Server has a configurable timeout for waiting for requests to be returned from the database. This has to be set to a high enough value to allow valid reports to run but not so high as to cause excessively long waits. You can configure this in the ORACLE_HOME/reports/conf/<server_name>.conf file, in the idleTimeOut attribute of the connection element.
You can run OracleAS Reports Services in an active-active configuration, as shown in Figure 5-2. In this case, you have two or more Oracle Application Server middle-tier instances, and each instance runs its own Reports servlet and Reports Server. A load balancer placed in front of Oracle HTTP Server distributes requests to the instances.
Each Reports servlet is bound to one default Reports Server. Although a specific Reports Server can be specified for an individual report request, there is no method of specifying an alternate Reports Server if the default Reports Server is not available.
If an instance fails, the load balancer detects the failure and routes all requests to the remaining active instances.
Persistent (or Sticky) Connections on the Load Balancer
Persistent (also called sticky) connections refer to the capability on the load balancer to direct requests from the same client to the same server. Persistent connections are not required for Reports Server, but you may want to use persistent connections to take advantage of Reports caching. This depends on the usage pattern of the Reports Server.
Examples where you should use persistent connections:
If the requests that you typically get consist of multiple HTTP requests (that is, output format is HTML or HTML/CSS, where the base document and images are individual requests), then you should configure persistent connection on your load balancer so that requests from the same client get routed to the same server. This enables the server to return the completed report.
If you have many requests that are asynchronous job submissions (followed by a separate request to the Reports Server for the output), then you should configure persistent connection on your load balancer so that requests from the same client get routed to the same server. This enables you to take advantage of caching.
Examples where persistent connections are optional:
If the requests that you typically get are for formats that represent a complete report that can be sent back to the client in a single file (for example, formats such as XML, PDF, or RTF), then you do not need persistent connections because it does not matter if consecutive report requests from the same client are routed to the same or different server.
If you are not caching reports for whatever reason (for example, because requests are different or because the underlying data changes too frequently), then you do not require persistent connections because there are no cached reports that you can take advantage of. The load balancer can route requests from the same client to any server.
Note that you should not confuse persistent connections on the load balancer with the Reports servlet being bound to a specific Reports Server. You should think of the Reports servlet-Reports Server as a single unit, and the load balancer directs requests to a Reports servlet-Reports Server unit.
Command-line Client, rwclient, Not Supported in Active-Active Configurations
Only Web clients are supported in active-active configurations. The command-line client, rwclient, is not supported. The reason is that rwclient connects to a specific Reports Server by name, and there can be only one named instance of a specific Reports Server. To run rwclient in a high availability environment, you can use the active-passive configuration. See Section 5.4.4, "OracleAS Reports Services in Active-Passive Configurations".
Storage Location for Source Files and Cache Directory
For Reports source files, you can store them in an NFS-mounted storage device that can be accessed by all nodes in the active-active configuration, or you can store the source files on local directories on each node.
For caching, you should use separate directories on each node. This means that if you execute a report on one node, and the next request for the same report goes to the other node, then the report will be executed again instead of being delivered from cache.
Multicast Subnet
For OracleAS Reports Services, all instances and components in an active-active configuration must run in the same subnet because the Reports servlet uses multicast to discover Reports Servers. If you need to run OracleAS Reports Services components across different subnets, then you need to use the Reports Bridge to provide access to Reports Servers on different subnets. In this case, the Reports Bridge becomes a vital component which you must secure using a high availability method such as OracleAS Cold Failover Cluster.
Figure 5-2 Running OracleAS Reports Services in an Active-Active Configuration
Steps for Creating an Active-Active Configuration
To create this active-active configuration, you perform these steps:
Install at least two middle-tier instances.
Configure your load balancer to distribute requests to the instances.
To verify that the Reports servlet is running, configure your load balancer to ping the following URL:
http://your_machine_name.domain_name:your_port_number/reports/rwservlet/help
The URL is case sensitive. If you run this URL in a browser, the Reports servlet displays a help page describing the rwservlet command line arguments.
To verify that the Reports Server is running, configure your load balancer to ping the following URL:
http://your_machine_name.domain_name:your_port_number/reports/rwservlet/getserverinfo?server=your_server_name
The server=your_server_name argument is not required if you are using the default Reports Server name (rep_machine_name) or the Reports Server specified in the servlet configuration file, rwservlet.properties (ORACLE_HOME\reports\conf\). If you run this URL in a browser, you should see a listing of the job queue for the specified Reports Server.
For more information, see section 2.5, "Verifying That the Reports Servlet and Server Are Running", in the Oracle Application Server Reports Services Publishing Reports to the Web guide.
Ensure that the Reports Servers have different names.
This is required because clients broadcast packets with the name of the Reports Server to which they want to connect. A Reports Server with the matching name responds if it exists in the network. If you have multiple Reports Servers with the same name, then clients will not be able to specify which server to connect to.
For more information, see section 1.4.1.1, "Server Discovery Within a Subnet", in the Oracle Application Server Reports Services Publishing Reports to the Web. guide
If you set up additional Reports Servers, make sure you configure OPMN to manage them. See the following guide for details.
| Item | Name |
|---|---|
| Book | Oracle Application Server Reports Services Publishing Reports to the Web
This book is available in the Oracle Application Server documentation set. |
| Chapter | 3, "Configuring OracleAS Reports Services" |
| Section | "Configuring Reports Server with the Oracle Process Manager and Notification Server and Oracle Enterprise Manager 10g" |
Ensure that configuration files are identical on all the middle-tier instances. If the files are different, requests may be interpreted differently on each instance. Configuration files include:
the key map file (by default, ORACLE_HOME/reports/conf/cgicmd.dat)
the Reports servlet properties file (ORACLE_HOME/reports/conf/rwservlet.properties)
Set up a backup plan to back up all configuration files regularly and frequently, especially the Reports Server batch file.
You can use a provided script for installing and deploying OracleAS Reports Services in an active-passive configuration. However, note the following restrictions:
All components (Reports Servlet, Reports Server, and Reports Engines) must run from the same Oracle Application Server middle-tier instance.
Reports Bridge is not part of the solution.
At runtime, OracleAS Forms Services consist of the components listed in Table 5-2.
Table 5-2 Runtime Forms Services components
| Component | Function |
|---|---|
|
The Forms Servlet handles the initial application request and dynamically generates the start HTML file for the Forms generic Java Applet. If using OracleAS Single Sign-On, the Forms Servlet is also used to verify users' authentication. |
|
|
The Forms Listener Servlet is a dispatcher servlet that handles the communication between the Forms Java client in the client browser and the Forms runtime process in the middle tier server. The Forms Listener Servlet starts a Forms runtime process for each application request and user. |
|
|
The Forms Runtime Engine interprets the Forms application modules (fmx files) and executes the contained business logic. The Forms Runtime Engine also makes the database connection using SQLNet. |
OracleAS Forms Services does not exist as a dedicated server process on the middle tier, and therefore, all that is required to request and run a Forms application on the Web is the availability of a servlet container (OC4J) that is configured to run Forms Services.
Because OracleAS Forms Services launches a dedicated Forms Runtime process for each user there is no transparent application failover. Once a user session is interrupted, the user has to restart the Forms Web application by issuing a new request to the Forms Servlet.
If a middle tier server crashes or a servlet session is interrupted, recover from either failure by restarting the application. To set up high availability for OracleAS Forms Services, the following components can be used:
mod_oc4j - Handling the failure of an OC4J instance, OracleAS Forms Services can be set up to load balance application requests between different OC4J instances. This ensures that an application request can be routed to the next available OC4J instance if the current OC4J instance fails.
OracleAS Web Cache - Using OracleAS Web Cache as a HTTP load balancer enables you to distribute Forms requests between many Oracle Application Server instances that may or may not share the same Infrastructure installation. If one instance fails, then the next Forms application request gets routed to the next available instance. Each instance can also use mod_oc4j to load balance Forms sessions between OC4J instances.
Hardware load balancers - A hardware load balancer can be deployed in front of OracleAS Web Cache, thereby adding one more layer of load balancing for Forms requests. Or, they can also replace OracleAS Web Cache and load balance requests directly to Oracle HTTP Servers.
For the OracleAS Infrastructure that is used by Forms Services installations, inclusive of Oracle Identity Management, use the OracleAS Cold Failover Cluster topology. This is described in Chapter 9, "OracleAS Infrastructure: High Availability Topologies".
For more information about Forms Services architecture and setup, refer to Oracle Application Server Forms Services Deployment Guide.
OracleAS Integration B2B uses several components from the Oracle Application Server stack during runtime. These include Oracle HTTP Server, OC4J, and OracleAS Metadata Repository. Figure 5-3 shows the OracleAS Integration B2B high availability configuration.
Figure 5-3 High Availability Configuration of OracleAS Integration B2B
For OracleAS Integration B2B services to be highly available, the following components must be highly available:
Oracle HTTP Server
OC4J transport servlet
OracleAS Integration B2B server JVM
OracleAS Infrastructure
For discussion purposes, the runtime architecture can be segmented into the following tiers:
If each of these tiers has active-active availability, then OracleAS Integration B2B has active-active availability. Otherwise, if one of the tiers is active-passive, then OracleAS Integration B2B service is active-passive. For example, if the OracleAS Infrastructure tier uses the OracleAS Cold Failover Cluster (Infrastructure) configuration, then OracleAS Integration B2B service has active-passive availability.
Web Server and OC4J Tier
This tier consists of Oracle HTTP Server and the OC4J transport servlet instances. The servlets are deployed in OC4J containers and can utilize the high availability properties of the containers. They can be grouped together into OracleAS Clusters (OC4J) and be synchronized by DCM for consistent configuration. The OC4J instances are load balanced by mod_oc4j.
For active-active availability, the web server and OC4J tier is front-ended by a load balancer router appliance and/or OracleAS Web Cache. If OracleAS Web Cache is used, it should be configured into an OracleAS Cluster (Web Cache). Monitoring and automatic restart of OracleAS Web Cache, Oracle HTTP Server, and OC4J processes are performed by OPMN.
The transport servlets perform the tasks of forwarding requests to and receiving responses from the OracleAS Integration B2B instances. The servlets do not maintain state for each request handled. They communicate with the OracleAS Integration B2B instances through Java RMI. Each instance of OracleAS Integration B2B is registered in the web.xml file of each of the OC4J containers hosting the transport servlets. The servlets forward requests to the OracleAS Integration B2B instances using the round-robin model. If any of the OracleAS Integration B2B instances fail, the servlets re-route requests to the next instance in the round-robin queue after a specified timeout period.
The OracleAS Integration B2B tier consists of the OracleAS Integration B2B server runtime. This is a Java application, but its instances do not run in OC4J containers. They run in their own standalone JVM processes.
The OracleAS Integration B2B server has the following characteristics:
Its runtime is stateless for each request it processes. If a runtime process fails and a request message is not completely processed, the client is expected to retry the request. If the failure occurs after the initial message has been completely processed, all subsequent incomplete processing results are stored in the database, and any other runtime instances can resume processing. Each processing step is atomic.
It uses JDBC to access the OracleAS Metadata Repository to make changes to the OracleAS Integration B2B metadata schemas. High availability for JDBC connections is achieved by Oracle Net.
Only one runtime instance exists for each Oracle Application Server instance.
To ensure that the server has active-active availability, multiple instances (on different nodes) of its runtime should be instantiated. Ideally, these instances should be deployed in more than one node to protect from node failure. For each instance, OPMN ensures that failure detection and automatic restart of each instance is managed.
Inbound communication to the OracleAS Integration B2B instances is received by the load balancer fronting the Oracle HTTP Servers. The load balancer distributes requests to the Oracle HTTP Server instances, which forwards the requests to the transport servlets via mod_oc4j load balancing. The transport servlets communicate the requests to the OracleAS Integration B2B instances using the RMI protocol.Outbound communication from the OracleAS Integration B2B instances occurs as follows. The instances send responses to the Oracle HTTP Servers, which are configured as proxy servers. This configuration can be accomplished by specifying the proxy host and port properties in the tip.properties file.
OracleAS Infrastructure Tier
High availability in the OracleAS Infrastructure tier can be enabled by any of the high availability configurations for the OracleAS Infrastructure explained in Chapter 9, "OracleAS Infrastructure: High Availability Topologies". These configurations ensure that the OracleAS Metadata Repository and Oracle Identity Management components are highly available for the web server and OC4J, and OracleAS Integration B2B tiers. For active-active availability, one of the configurations described in Section 6.2.1, "Active-Active High Availability Topologies", should be used. This allows the entire OracleAS Integration B2B service stack to have active-active availability.
OracleAS Integration InterConnect has a hub and spoke architecture. Figure 5-4 shows OracleAS Integration InterConnect components with two spoke applications as an example.
Figure 5-4 OracleAS Integration InterConnect runtime components with two spoke application as an example
The OracleAS Integration InterConnect components are:
OracleAS Integration InterConnect Adapters
OracleAS Integration InterConnect Repository Server
OracleAS Integration InterConnect Hub database
For OracleAS Integration InterConnect to be highly available, all its components must be highly available. One additional requirement is for the data or message sources that provide information to the adapters to be highly available. These are the spoke applications. Because these applications are customer-dependent and not part of the Oracle Application Server product, their high availability discussion is outside the scope of this book.
For the purpose of high availability discussion, the OracleAS Integration InterConnect components can be segmented into the following tiers:
The following sections provide details on how high availability can be achieved for each tier.
|
See Also: OracleAS Integration InterConnect documentation for detailed information about OracleAS Integration InterConnect components |
Except for the HTTP adapter, each adapter runs in a standalone JVM process (not OC4J) and is stateless. This JVM process can be configured as a custom OPMN application to achieve process failure detection and automatic restart. The custom application can be configured in the opmn.xml file. Refer to the Oracle Process Manager and Notification Server Administrator's Guide for instructions on how to do this. After the configuration, the adapter processes should be started using OPMN (opmnctl command).
OPMN only monitors and restarts individual processes. In order for the adapter tier to be fully redundant, multiple adapter processes are required. The adapters can be set up using an active-active or active-passive approach:
Active-Active
Multiple active adapter processes can be deployed either on the same machine or separate machines. The adapter processes process incoming messages from the spoke application and deliver messages to the hub database concurrently. In the event that one adapter process fails, messages are delivered to the surviving processes. The adapters coordinate with each other to balance their workload from the spoke application.
Active-Passive
Two adapter processes can be deployed in a cold failover cluster configuration to achieve active-passive availability.
In a cold failover cluster, two machines can be clustered together using clusterware such as Sun Cluster or HP MC/Service Guard. This type of clustering is a commonly used solution for making adapters highly available. One node of the cluster is "cold", passively waiting to take over in the event of a failure, while the other is "hot", or actively running the adapter software. When the "hot" or "active" node fails, the clusterware restarts the software on the cold node to bring the adapter back online. Figure 5-4 shows a cold failover cluster for the adapters.
If the hub database is a Real Application Clusters database, the adapters are enabled to work with the multiple database instances in the Real Application Clusters. Real Application Clusters technology provides consistent and uninterrupted service without having to restart the adapters if a database instance fails. The adapters connect to the first of the listed available nodes in the adapter.ini or hub.ini files. If one of the Real Application Clusters nodes fails, the database connection is established with the next available node in the adapter.ini or hub.ini file recursively until a successful connection. Failover is transparent to the spoke application. Refer to the "Hub Database Tier" section below for more information on how the adapter process can be made aware of Real Application Clusters hub database instances.
|
See Also: OracleAS Integration InterConnect adapters installation documentation for details onadapter.ini and hub.ini files associated with specific adapters
|
High availability specific to each adapter type can be achieved as follows:
You can deploy multiple database adapter instances serving the same application (Figure 5-5 shows an example). Because the adapters are stateless, they share tasks coming from their spoke application, the customer database. Connection failure handling to a database is done by rolling back unfinished transactions and retrying other data sources. The same connection failure handling mechanism is also used for JMS communication (JMS over JDBC) to the Advanced Queue in the hub database.
Figure 5-5 Example of multiple database adapter instances (showing only single spoke)
After an application is designed, it can be deployed to the database adapters when the adapters are first started. Upon initial startup, the adapters fetch metadata from the hub database through the OracleAS Integration InterConnect Repository Server, similar to the way OracleAS Integration InterConnect iStudio accesses the data at design time. Once these metadata are retrieved by the adapters, they are cached locally on a file-based cache. Thus, subsequent adapter startup does not need to access the Repository Server.
At run time, the database adapters access the customer database through JDBC. There can be multiple JDBC data sources, which the adapters iterate through should a connection fail. Tasks from the customer database are processed by all database adapter instances in coordination so that a task is only processed once. In order to have readily available data from the customer database, the database should be Real Application Clusters-enabled or be in a cold failover configuration (applies to the hub database as well). The adapters communicate with the Repository Server at run time to implement the Xref feature.
The HTTP adapter consists of a standalone Java application, an OC4J transport servlet, and Oracle HTTP Server. The Java application implements the HTTP adapter logic and communicates with a servlet in OC4J using the RMI protocol. Each Java application process communicates with only one OC4J process. The Oracle HTTP Server is required to communicate with spoke applications over HTTP.
For high availability, more than one set of Oracle HTTP Server, OC4J, and Java application process should be deployed on redundant nodes. mod_oc4j load balancing can be used to distribute requests between Oracle HTTP Server and OC4J instances across nodes. But communication between OC4J instances and the Java application processes is one-to-one. A load balancer router can be deployed in front of the Oracle HTTP Server instances to distribute requests to these instances.
The HTTP adapter Java application also communicates with the hub database and Repository Server. The Java application works with these components the same way as the database adapter as described above. The hub database should be made highly available through using a Real Application Clusters database or cold failover cluster configuration. The Repository Server can be made highly available using a cold failover cluster configuration.
In the event a HTTP adapter process fails, an inbound message to the adapter process (servlet to adapter) can be lost if the message is still in the transport or RMI layer. But once the message arrives at the adapter agent layer, the message is persisted and can be picked up later when the adapter is restarted. Also, the transport servlet will not be able to enqueue any other messages to the adapter process as the RMI server fails with the adapter process. These messages in the OC4J process will not be processed as the transport servlet's doPost() method will respond with an error message stating that the RMI server is unavailable.
To achieve high availability for the FTP/SMTP adapter, multiple adapter instances can be deployed on separate machines with a load balancer routing requests to them. Because adapters process messages atomically and are stateless, if any one of the adapter instances fail, the redundant deployment allows the failure to be transparent to senders and recipients of messages.
High availability specifics of this adapter are similar to those of the database adapter. This is because access to the MQ/AQ database is also through JDBC (JMS). Refer to the database adapter description above.
For the file adapter to achieve high availability, multiple adapter instances are required to access a network file system. If one adapter instance fails, another instance can process the requests for the failed instance.
The OEM adapter model is similar to that of the HTTP adapter, that is, it has an OC4J transport servlet, Oracle HTTP Server, and a standalone Java application. The Java application implements the adapter logic and communicates with a servlet in OC4J using the RMI protocol. Each Java application process communicates with only one OC4J process. The Oracle HTTP Server is required to communicate with spoke applications over HTTP.
This tier consists of the Repository Server instance. Only a single instance can be actively running at any one time. Hence, the Repository Server can be deployed in a two-node cold failover cluster configuration with the nodes using shared storage. This configuration provides for node-level failover.
For Repository Server process high availability, the process can be configured as a custom application for OPMN in the opmn.xml file. This allows OPMN to monitor and automatically restart the Repository Server process if it fails. After the modification, the Repository Server process should be started using OPMN (opmnctl command).
The repository server is only used at run time for the Xref feature. Otherwise, it is only needed during design time and deployment time, when adapters are first started and fetch application metadata from the hub database.
The hub database can be any database, including the OracleAS Metadata Repository database. It stores OracleAS Integration InterConnect metadata such as application view and common view formats. iStudio accesses the hub database at design time through RMI via the Repository Server, which is a JVM process. The Repository Server can communicate with multiple hub database instances as multiple JDBC data sources. Internally, the Repository Server iteratively retries each data source with timeouts.
The OracleAS Integration InterConnect hub database can be made highly available by using Real Application Clusters. The following are some guidelines:
Enable the Repository Server process to be aware of the Real Application Clusters hub database instances.
The Repository Server process can be made aware of the Real Application Clusters database instances by specifying the list of available nodes hosting the database instances. Specifically, enter the host, port, and instance information of all the nodes in the repository.ini or hub.ini file. If a Real Application Clusters node connected to the Repository Server process fails, then the next node entry in the repository.ini and hub.ini file is used.
Enable the adapter processes to be aware of the Real Application Clusters hub database instances.
The adapter processes can be made aware of the Real Application Clusters database instances by specifying the list of available nodes hosting the database instances. Specifically, enter the host, port, and instance information of all the nodes in the adapter.ini file. If a node connected to an adapter process fails, the next node entry in the adapter.ini file is used.
The hub connections of all the OracleAS Integration InterConnect adapters and the spoke connections of the database and AQ adapters support Real Application Clusters.
|
See Also: OracleAS Integration InterConnect adapters installation documentation for details onadapter.ini and hub.ini files associated with specific adapters.
|
BPEL (Business Process Execution Language) is an XML-based language that enables you to assemble discrete services into an end-to-end process flow. Oracle BPEL Process Manager provides a framework for designing, deploying, and managing BPEL business processes.
Oracle BPEL Process Manager is a J2EE application that you can run on different application servers. It is a stateless application, but it uses a database as its "dehydration store" to store process state information.
The Oracle BPEL Process Manager architecture is also stateless, which makes it simple to make highly available. Figure 5-6 shows Oracle BPEL Process Manager in an active-active configuration, with a Real Application Clusters database as the dehydration store.
Figure 5-6 Oracle BPEL Process Manager in an Active-Active Configuration
In an active-active configuration, all the components run at the same time. The load balancer distributes requests to the appropriate node. If the node is unavailable, it sends the request to the next available node.
To run Oracle BPEL Process Manager in an active-active configuration, you perform these steps:
Install Oracle BPEL Process Manager on multiple Oracle Application Server middle-tier instances (or on multiple standalone OC4J, WebLogic, JBoss, or WebSphere instances).
Place a load balancer in front of these Oracle Application Server instances. This can be a software load balancer such as OracleAS Web Cache, but for production purposes, a hardware load balancer such as f5 BIG-IP is recommended.
Configure all the BPEL servers to use the same database as their dehydration store.
Configure all the BPEL engines to use the load balancer as the server URL and callback address for the generated SOAP URLs. Specifically, use the Oracle BPEL Process Manager Administration Console to set the soapServerUrl and soapCallbackUrl properties to be the URL of the load balancer.
Change any JNDI lookups (for example, to retrieve services) to use a list of JNDI providers returned by OPMN. For example, instead of specifying JNDI providers like this:
jndiProviderURL = "ormi://localhost/CustomerService"
you should use this:
jndiProviderURL = "opmn:ormi://host1:port1:oc4j/app, opmn:ormi://host2:port2:oc4j/app"
This enables high availability at the JVM level. If you are running multiple JVM processes for a single OC4J instance, OPMN can route requests to independent JNDI objects based on the number of JVMs available.
To deploy BPEL processes on an active-active configuration:
In your design environment (for example, Oracle JDeveloper), compile and deploy your BPEL process on each node. You can also do this manually or through a script. See the Oracle BPEL Process Manager Developer's Guide for details.
Ensure that all the servers in the cluster have the same domains (as above, this can also be done manually or through a script).
Invoking BPEL Processes in an Active-Active Topology
This section describes the changes needed if you invoke BPEL processes through SOAP/WSDL or through the Oracle BPEL Process Manager Java API.
If you use SOAP/WSDL, then ensure that you use the load balancer virtual server name, instead of the hostnames of the nodes.
If you use the Oracle BPEL Process Manager Java API, then you list each hostname of the nodes in the active-active topology. See the jndiProviderURL example above.
Using a Real Application Clusters Database for the Dehydration Store
To complete the high availability picture, you should run the dehydration store on a highly available database, such as a Real Application Clusters database. With a Real Application Clusters database, then all the components are highly available.
If you are using a Real Application Clusters database for the dehydration store, you need to make the following changes to your configuration:
Modify the OC4J data-sources.xml file so that the connect information to the Real Application Clusters database has the following format:
jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=tcp)(HOST=hostname1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=hostname2)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=orcl))
)
hostname1 and hostname2 specify the names of the nodes running the Real Application Clusters database.
orcl specifies the service name of the database.
Note that both the address and the load balancer options are within the ADDRESS_LIST element.
Oracle BPEL Process Manager should work in an OracleAS Cold Failover Cluster, or active-passive, configuration. An active-passive configuration consists of two nodes in a hardware cluster, a shared storage, and a virtual hostname and IP. You install the files on the shared storage so that either node in the hardware cluster can access them. Clients use the virtual hostname to access the active in the hardware cluster. If the active node becomes unavailable, a failover event occurs, and the passive node takes over and runs the processes.
You can use Oracle BPEL Process Manager with Oracle Application Server adapters to integrate your Oracle BPEL Process Manager processes with external resources. These adapters are based on J2EE Connector Architecture (JCA).
This section describes how to run Oracle BPEL Process Manager with adapters in a highly available manner. This section contains the following subsections:
Oracle Application Server JCA-based adapters integrate Oracle Application Server with various external resources, as shown in Table 5-3:
Table 5-3 Types of Adapters
| Adapter Type | Examples |
|---|---|
|
Technology |
Technology adapters integrate Oracle Application Server with transport protocols, data stores, and messaging middleware. Examples of technology adapters include: FTP, Files, Database, JMS, and Advanced Queuing. |
|
Packaged application |
Packaged application adapters integrate Oracle Application Server with applications such as Siebel and SAP. |
|
Legacy and mainframe |
Legacy and mainframe adapters integrate Oracle Application Server with applications such as CICS and VSAM. |
For detailed information on adapters, see Oracle Application Server Adapter Concepts.
Concurrency support means that multiple adapter services can access the same resource at the same time without causing any data corruption. You can think of concurrency support as transactional support. For example, multiple adapter services for the database adapter can access the same table in the database at the same time.
Adapters can be divided into those that support concurrency and those that do not:
Adapters that do not support concurrency include the file and FTP adapters. This is because the external resource, which is the file system, does not support concurrent access.
All other adapters support concurrency.
The concurrency/no-concurrency support affects high availability options for the adapters, as shown in Table 5-4.
Table 5-4 High Availability Options for Adapters
| Adapter Type | High Availability Options |
|---|---|
|
Supports concurrency |
|
|
Does not support concurrency (file and FTP adapters) |
|
Note that for all high availability options, it is assumed that you have installed the adapters on all nodes. However, in some of the high availability options, you run Oracle BPEL Process Manager on only one node.
This topology can be used only for adapters that support concurrency.
Figure 5-6 shows this active-active topology. In this topology, you have one or more nodes fronted by a load balancer. On each node, you deploy and run Oracle BPEL Process Manager and business processes. This is the desired model from a high availability point of view, because you have all the components available on all nodes.
If you deploy an adapter that does not support concurrency on an active-active topology, then you risk corrupting the data on the external data source (for example, reading and writing the same file at the same time).
This modified version of an active-active topology is similar to the full active-active topology except for these differences:
You still deploy and run Oracle BPEL Process Manager and business processes on all nodes, but on all nodes except the first node, you disable the Activation Agent for partner links that use adapters that do not support concurrency.
Only the adapter service on the first node gets "receive" requests.
This topology can be used for these adapters:
adapters that do not support concurrency
adapters that support concurrency. Although you can run this type of adapter in a full active-active topology, you choose not to do so because you want to coordinate resources (such as managing and ensuring the proper sequence of messages), and the only way of doing this is to have only one adapter service running at any given time.
Figure 5-7 shows this modified active-active topology.
Figure 5-7 Modified Active-Active Topology
If the node with the Activation Agent fails, then you have to perform these steps:
Disable the Activation Agent on the failed node, so that when the node becomes active again, it will not run the Activation Agent (because another node is already running the Activation Agent).
Enable the Activation Agent on another node.
To Disable an Activation Agent
To disable an Activation Agent, you comment out its activationAgent element in the bpel.xml file. In the following example, the comment lines surround the activation agent that you want to disable.
<activationAgents> <!-- start comment <activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="InboundPL"> <property name="InputFileDir">C:/ora_home/integration/bpm/samples/tutorials/ 121.FileAdapter/ComplexStructure/InputDir/</property> <property name="portType">Read_ptt</property> </activationAgent> end comment --> </activationAgents>
This topology can be used for all adapters. The active-passive topology is also called OracleAS Cold Failover Cluster topology.
In an active-passive topology (Figure 5-8), you have two nodes in a hardware cluster. One of the nodes is the active node, and the other node is the passive node. There is also a shared storage; you install the Oracle home directories on this shared storage. The shared storage is mounted only on the active node.
The active node in the hardware cluster is associated with a virtual hostname and IP. Clients use the virtual hostname to access the active node in the cluster.
During runtime, the active node runs the processes. The virtual hostname points to the active node. If the active node becomes unavailable, then a failover event occurs. The passive node becomes the new active node and runs the processes.
You install and manage Oracle BPEL Process Manager as you would for a single-node deployment, except for these differences:
You install the Oracle home directories on the shared storage.
Clients access the active node using the virtual hostname. They do not need to know which node is actually running Oracle BPEL Process Manager.
Figure 5-8 Oracle BPEL Process Manager with Adapters in OracleAS Cold Failover Cluster Topology
Web connections to OracleBI Discoverer Server are managed through the Discoverer servlet. The servlet is responsible for brokering between the client and a Discoverer session component that then manages the actual transactions. Discoverer session components are initiated and managed by the OAD (Object Activation Daemon). Each machine has an OAD that manages its own Discoverer sessions. The OAD and session component are both monitored and managed by OPMN.
OracleBI Discoverer can be configured for high availability in the following ways:
Process monitoring and restart
OPMN is configured to monitor and restart OracleBI Discoverer processes on each middle-tier node. See Chapter 4 of Oracle Business Intelligence Discoverer Configuration Guide.
OracleAS Web Cache can be set up to perform as a load balancer for OracleBI Discoverer requests. See Chapter 5 of Oracle Business Intelligence Discoverer Configuration Guide.
|
See Also: The chapter on installing in a multi machine environment in the Oracle Business Intelligence Discoverer Configuration Guide for multi machine considerations and pre-requisites for providing load balancing for OracleBI Discoverer |
The OracleBI Discoverer Preference Server stores individual user preferences across sessions. It is managed, like the session server, by the OAD. In a multiple machine environment, distributed session servers can be configured to access one centrally located OracleBI Discoverer Preferences Server. The latter is monitored and managed by OPMN.
The OracleBI Discoverer Preferences Server can be made highly available by deploying multiple instances that are fronted and serviced by a load balancer router and/or OracleAS Web Cache. Several considerations should be noted for managing session information for this scenario.
When deploying multiple OracleBI Discoverer middle-tiers behind a load balancer, you have two options for configuring the OracleBI Discoverer Preferences Server such that user preferences are consistent across a session:
Enable session binding either in the load balancer router or in the OracleAS Web Cache tier. This ensures that a particular user will always be directed to the machine where their local preferences are stored. For details on configuring session binding for your load balancer router, refer to instructions from your particular load balancer hardware vendor. For configuring OracleAS Web Cache session binding, see the Oracle Application Server Web Cache Administrator's Guide.
Configure all the OracleBI Discoverer Servers to share a single preference server. This ensures that all user preferences are centralized, although, all preference information is now dependent on the availability of one machine.
|
Note: For instructions on how to configure a centralized OracleBI Discoverer Preferences Server, see the chapter on installing in a multiple machine environment in the Oracle Business Intelligence Discoverer Configuration Guide. |
Protecting the OracleBI Discoverer Preferences Server
Loss of either the machine which hosts the OracleBI Discoverer Preference Server or the information stored on that server does not impact availability of OracleBI Discoverer. However, it means that users lose their stored preferences information.To limit the loss of preferences information, the data on the OracleBI Discoverer Preferences Server should be backed up regularly, in particular, the file <ORACLE_HOME>/discoverer/util/pref.txt. This file holds the preferences information.
In both active-active and active-passive environments, you need to ensure that the domain controller is running on an active node. If the node on which the domain controller is running becomes unavailable, you have to migrate the domain controller to another node. This is because the domain controller can run only on one node at any given time.
If you installed the Oracle Content Management SDK in an OracleAS Cold Failover Cluster (Middle-Tier), and a failover or failback event occurs, you need to migrate the domain controller to the new active node.
In an active-active environment, if the node on which the domain controller is running becomes unavailable, then you have to migrate it to another node.
For details on how to migrate the domain controller, see the section "Migrating the Domain Controller" in chapter 3, "Managing the Oracle CM SDK Domain", of the Oracle Content Management SDK Administrator's Guide. You can find this guide on the "Oracle Content Management SDK" CD-ROM.
