Oracle UCM and Inbound Refinery High Availability Architecture

Configuring High Availability for Enterprise Content Management 11-15

11.2.2.1.1 Starting and Stopping the Cluster When the cluster starts, each Oracle UCM

node goes through its normal initialization sequence, which parses, prepares, and caches its resources, prepares its connections, and so on. If a node is part of a cluster then in-memory replication is initiated if other cluster members are available. One or all members of the cluster can be started at any one time. Shutting down a cluster member will only involve that cluster member being unavailable to service requests. When a server is shut down gracefully, it will finish processing current requests, signal its unavailability, and then release all shared resources and close its file and database connections. All session state will be replicated as well, allowing users originally connected to this cluster member to fail over to another member of the cluster.

11.2.2.1.2 Cluster-Wide Configuration Changes At the cluster level, new Oracle UCM

features or customization of behaviors can be introduced through Oracle UCM internal components. Nodes need to be restarted to pick up these new changes. For example, the metadata model can change system wide. For instance, a metadata field can be added, modified, or deleted. The system behavior that was driven by these metadata fields can be changed. This change would automatically be picked up by cluster nodes through notification between nodes. For changes to occur on each cluster member, the first node needs to have shared folders configured. As long as all the shared folders have the same mount point on each cluster node, the other nodes do not need do make manual changes using WebLogic Server packunpack.

11.2.2.2 Oracle UCM and Inbound Refinery High Availability Architecture

Oracle UCM can be configured with one or more Inbound Refinery instances to provide document conversions. Inbound Refinery is a conversion server that manages file conversions for electronic documents such as documents, digital images, and motion video. It also provides thumbnailing functionality for documents and images, the ability to extract and use EXIF data from digital images and XMP data from electronic files generated from programs such as Adobe Photoshop and Adobe Illustrator, and storyboarding for video. For more information about Inbound Refinery, refer to Oracle Fusion Middleware Administrators Guide for Conversion. The number of Inbound Refinery instances which need to be installed will depend on the amount of conversions which need to be supported. For availability, it is recommended that at least two Inbound Refinery instances be installed. All of the Inbound Refinery instances should be made available as providers to all members of a Content Server cluster.

11.2.2.2.1 Content Server and Inbound Refinery Communication All communication

between a Content Server and an Inbound Refinery is initiated by the Content Server. This includes: ■ Regular checks of all available Inbound Refinery instances to determine their status. ■ The initiation of a job request. ■ Retrieval of completed jobs. The status includes information on whether the Inbound Refinery is available to accept requests. This will depend on how busy the Inbound Refinery is. If no Inbound Refinery instances are available, the request is retried. 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