Oracle URM High Availability Protection from Failure and Expected Behaviors

11-16 Oracle Fusion Middleware High Availability Guide When jobs are completed, this information will appear as part of the Content Servers status request. If so, the Content Server will initiate download of the completed job.

11.2.2.2.2 Content Server Clusters and Inbound Refinery Instances In a Content Server

cluster, the list of all available Inbound Refinery instances is shared among members of the cluster. That is, when a new Inbound Refinery instance is added, it becomes available for any Content Server cluster member to use. However, each individual Content Server communicates independently with all the available Inbound Refinery instances. There is no shared status in a Content Server cluster. Likewise, all Inbound Refinery instances operate completely independently, responding to requests from Content Servers. Inbound Refinery instances do not share any information.

11.2.2.2.3 Inbound Refinery Instances and Load Balancers Load balancers cannot be used

in front of a collection of Inbound Refinery instances for the following reasons: ■ A Content Server expects to be able to contact an Inbound Refinery directly to get status and availability information. ■ When a job is finished, a Content Server must be able to access the one Inbound Refinery that has the specific job and initiate a download.

11.2.2.2.4 Inbound Refinery Availability Requests to Inbound Refinery do not occur in

real-time since all requests are asynchronous requests mediated by Content Server. Users access Content Servers, and Content Servers then delegate requests to available Inbound Refinery instances. Enough Inbound Refinery instances should be configured so that if one or more fail, there are always other Inbound Refinery instances available to service requests. A Content Server will never mark an Inbound Refinery as failed. If unable to contact an Inbound Refinery, then Content Server will choose another available Inbound Refinery and will continue to check the availability of all Inbound Refinery instances. It is the responsibility of a system administrator to manually remove failed Inbound Refinery instances from the Content Server lists.

11.2.2.3 Oracle URM High Availability

Oracle URM and Oracle UCM share the same architecture. As such, all high availability considerations which apply to Oracle UCM also apply to Oracle URM. When configuring high availability, there are only two differences to note between Oracle UCM and Oracle URM: 1. Oracle URM will store its file system metadata in a different directory than Oracle UCM. 2. When configuring an HTTP Server in front of an Oracle URM cluster, a different session cookie name must be used than that of Oracle UCM. More details on these two configuration differences are provided in the section below on the Oracle ECM High Availability Configuration Steps.

11.2.2.4 Protection from Failure and Expected Behaviors

The following features help protect an Oracle UCM node from failure: Configuring High Availability for Enterprise Content Management 11-17 ■ Load balancing can be achieved by using an external load balancer. The session does not need additional sticky state data other than its authentication information. ■ The load balancer can be configured in front of Oracle UCM. Multi data sources can be configured with Oracle UCM to support Oracle RAC. Timeouts and retries are also supported. ■ Oracle UCM uses standard WebLogic Server persistent session. ■ Oracle UCM does not use EJBs. ■ Death can be detected using the Oracle UCM PING_SERVER service. When a node is restarted, it does not affect other nodes in the cluster. ■ Failover is handled either by the load balancer in front of the Oracle UCM nodes, or by the WLS module in Apache. Ongoing requests from the client would fail, but subsequent requests are rerouted to active nodes. Unfinished transactions would not complete. ■ Configuration information from the node is not lost, because it is stored on the shared file system and in the database. ■ When a node fails, a database connection between the node and the database should be reclaimed by the database. ■ Although instances normally do not get hung, it can occur because of unknown deadlock conditions in the Oracle UCM product or customized versions of Oracle UCM. ■ Users with active sessions should not experience any disruption as their sessions fail over to an active server. This includes users with UCM administration applets open. ■ After the installation of Oracle UCM is complete, the following value should be set in the config.cfg file. This will allow retry logic during an Oracle RAC failover: ServiceAllowRetry=true If this value is not set, user will need to manually retry any operation that was in progress when the failover began. The value can be set using the WebLogic Server Administration Console for Oracle UCM at the following URL: http:hostname:portcs Go to Administration Admin Server General Configuration and add ServiceAllowRetry=true to Additional Configuration Variables. Save and restart all the UCM managed servers. The new value should appear in config.cfg at the following location: SHARED_DISK_LOCATION_FOR_UCM ucmcsconfigconfig.cfg

11.2.2.5 Troubleshooting Oracle UCM High Availability