Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Content
11g Release 1 (11.1.1)

Part Number E15483-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

4 Preparing the File System for an Enterprise Deployment

This chapter describes how to prepare your file system for an Oracle WebCenter Content enterprise deployment. It provides information about recommended directory structure and locations, and it includes a procedure for configuring shared storage.

This chapter includes the following topics:

4.1 Overview of Preparing the File System for Enterprise Deployment

It is important to set up your file system in a way that makes the enterprise deployment easier to understand, configure, and manage. Oracle recommends setting up your files system according to information in this chapter. The terminology defined in this chapter is used in diagrams and procedures throughout the guide.

Use this chapter as a reference to help understand the directory variables used in the installation and configuration procedures. Other directory layouts are possible and supported, but the model adopted in this guide is chosen for maximum availability, providing both the best isolation of components and symmetry in the configuration and facilitating backup and disaster recovery. The rest of the document uses this directory structure and directory terminology.

4.2 Terminology for Directories and Directory Environment Variables

This section describes the directory environment variables used throughout this guide for configuring the Oracle WebCenter Content enterprise deployment. The following directory variables are used to describe the directories installed and configured in the guide:

Tip:

You can simplify directory navigation by using environment variables as shortcuts to the locations in this section. For example, you could use an environment variable called $ORACLE_BASE in Linux to refer to /u01/app/oracle (that is, the recommended ORACLE_BASE location). In Windows, you would use %ORACLE_BASE% and use Windows-specific commands.

4.3 Recommended Locations for the Different Directories

With Oracle Fusion Middleware 11g, you can create multiple managed servers from a single binary installation. This allows the installation of binaries in a single location on a shared storage and the reuse of this installation by the servers in different nodes. For maximum availability, however, Oracle recommends using redundant binary installations.

In the enterprise deployment model, two Oracle Fusion Middleware homes (MW_HOME), each of which has a WL_HOME and an ORACLE_HOME for each product suite, are installed in a shared storage. Additional servers (when scaling out or up) of the same type can use either one of these two locations without requiring more installations. Ideally, users should use two different volumes (referred to as VOL1 and VOL2 in the following text) for redundant binary location, thus isolating as much as possible the failures in each volume. For additional protection, Oracle recommends that these volumes are disk-mirrored. If multiple volumes are not available, Oracle recommends using mount points to simulate the same mount location in a different directory in the shared storage. Although this does not guarantee the protection that multiple volumes provide, it does allow protection from user deletions and individual file corruption.

When an ORACLE_HOME or a WL_HOME is shared by multiple servers in different nodes, Oracle recommends maintaining the Oracle Inventory (oraInventory) and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and attach an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the user_home/bea/beahomelist file. This would be required for any nodes installed in addition to the two nodes used in this enterprise deployment. An example of the oraInventory and beahomelist updates is provided in the scale-out steps included in this guide.

Oracle recommends also separating the domain directory used by the Administration Server from the domain directory used by managed servers. This allows a symmetric configuration for the domain directories used by managed servers and isolates the failover of the Administration Server. The domain directory for the Administration Server must reside in a shared storage to allow failover to another node with the same configuration. The domain directories of the managed servers can reside in local or shared storage, except that the WebCenter Content and Inbound Refinery managed servers cannot reside in shared storage. These managed servers include Oracle WebCenter Content Server, which uses node-specific files, such as intradoc.cfg.

You can use a shared domain directory for all other managed servers in different nodes or use one domain directory per node. Except for WebCenter Content and Inbound Refinery managed servers, sharing domain directories for managed servers facilitates the scale-out procedures. In this case, the deployment should conform to the requirements (if any) of the storage system to facilitate multiple machines mounting the same shared volume. The configuration steps provided in this enterprise deployment topology assume that a local (per node) domain directory is used for each managed server.

All procedures that apply to multiple local domains apply to a single, shared domain. Hence, this enterprise deployment guide uses a model where one domain directory is used per node. The directory can be local or reside in shared storage. JMS file stores and JTA transaction logs need to be placed on a shared storage to ensure that they are available from multiple boxes for recovery in the case of a server failure or migration.

Based on the previous assumptions, the following paragraphs describe the recommended directories. Wherever a shared storage location is directly specified, it is implied that shared storage is required for that directory. When using local disk or shared storage is optional, the mount specification is qualified with "if using a shared disk." The shared storage locations are examples and can be changed as long as the provided mount points are used. Oracle recommends this structure in the shared storage device for consistency and simplicity.

ORACLE_BASE:

/u01/app/oracle

MW_HOME (application tier):

ORACLE_BASE/product/fmw

ORACLE_HOME (web tier):

ORACLE_BASE/product/fmw/web

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soa or MW_HOME/wcc

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

ORACLE_INSTANCE (OHS instance):

ORACLE_BASE/admin/instance_name

Domain Directory for Administration Server Domain Directory:

ORACLE_BASE/admin/domain_name/aserver/domain_name (The last domain_name directory is added by Fusion Middleware Configuration Wizard)

Domain Directory for Managed Server Directory:

ORACLE_BASE/admin/domain_name/mserver/domain_name

Note:

This procedure is really dependent on shared storage. The preceding example is specific to NAS, but other storage types may provide this redundancy with different types of mappings.

Location of JMS file-based stores and Tlogs:

ORACLE_BASE/admin/domain_name/cluster_name/jms

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

Location of Oracle WebCenter Content: Imaging input files, images, and samples input directories:

ORACLE_BASE/admin/domain_name/img_cluster_name/input_files

ORACLE_BASE/admin/domain_name/img_cluster_name/input_files/Samples

ORACLE_BASE/admin/domain_name/img_cluster_name/images

The location of input files and images may vary according to each customer's implementation needs. It is relevant, however, that image files are located in a device isolated from other concurrent accesses that can degrade the performance of the system. A separate volume can be used for this purpose. In general, it is good practice to place the files under the cluster directory structure for consistent backups and maintenance.

In a multinode Imaging installation, this location is shared among all the input agents and must be accessible by all agents. If input agents are on different machines, this must be a shared network.

Note:

In order to process input files, the input agent must have the appropriate permissions on the input directory and the input directory must allow file locking. The input agent requires that the user account that is running the WebLogic Server service have read and write privileges to the input directory and all files and subdirectories in the input directory. These privileges are required so that the input agent can move the files to the various directories as it works on them. File locking on the share is needed by the input agent to coordinate actions between servers in the cluster.

Location of the Oracle WebCenter Content vault (native file repository):

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vault

Location of the Inbound Refinery directory:

ORACLE_BASE/admin/domain_name/ibr_cluster_name

ORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrN (where N is the number of an Inbound Refinery instance)

Location of the application directory for the Administration Server:

ORACLE_BASE/admin/domain_name/aserver/applications

Location of the application directory for a managed server:

ORACLE_BASE/admin/domain_name/mserver/applications

Note:

This directory is local in the context of the Oracle WebCenter Content enterprise deployment. A shared domain directory for a managed server with Content Server does not work because certain files within the domain, such as intradoc.cfg, are specific to each node.

Figure 4-1 shows this directory structure in a diagram.

Figure 4-1 Enterprise Deployment Directory Structure for Oracle WebCenter Content

Description of Figure 4-1 follows
Description of "Figure 4-1 Enterprise Deployment Directory Structure for Oracle WebCenter Content"

The directory structure in Figure 4-1 does not show other required internal directories, such as oracle_common and jrockit.

Table 4-1 explains what the various color-coded elements in Figure 4-1 mean.

Table 4-1 Directory Structure Elements

Element Explanation

Admin Server element

The Administration Server domain directories, applications, deployment plans, file adapter control directory, JMS and TX logs, and the entire MW_HOME are on a shared disk.

Managed server elements

The managed server domain directories can be on a local disk or a shared disk. Further, if you want to share the managed server domain directories on multiple nodes, then you must mount the same shared disk location across the nodes. The instance_name directory for the web tier can be on a local disk or a shared disk.

Fixed name element

Fixed name.

Installation-dependent names

Installation-dependent name.


Figure 4-2 shows an example configuration for shared storage with multiple volumes for Oracle SOA Suite.

Figure 4-2 Example Configuration for Shared Storage

Shared storage, explained in table following image.
Description of "Figure 4-2 Example Configuration for Shared Storage"

Table 4-2 summarizes the directory structure for an Oracle WebLogic Server domain that includes Oracle SOA Suite and Oracle WebCenter Content managed servers that share storage.

Table 4-2 Contents of Shared Storage

Server Type of Data Volume in Shared Storage Directory Files

WLS_WCC1

Tx Logs

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs

The transaction directory is common (decided by WebLogic Server), but the files are separate.

WLS_WCC2

Tx Logs

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs

The transaction directory is common (decided by WebLogic Server), but the files are separate.

WLS_WCC1

JMS Stores

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/jms

The transaction directory is common (decided by WebLogic Server), but the files are separate; for example: WCCJMSStore1, UMSJMSStore1, and so on.

WLS_WCC2

JMS Stores

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/jms

The transaction directory is common (decided by WebLogic Server), but the files are separate; for example: WCCJMSStore2, UMSJMSStore2, and so on.

WLS_SOA1 and WLS_WCC1

WLS Install

VOL1

MW_HOME

Individual in each volume, but both servers see the same directory structure (SOAHOST2 and WCCHOST2 mount VOL1).

WLS_SOA1 and WLS_WCC1

WLS Install

VOL2

MW_HOME

Individual in each volume, but both servers see the same directory structure (SOAHOST2 and WCCHOST2 mount VOL2).

WLS_WCC1

WCC Install

VOL1

MW_HOME/wcc

Individual in each volume, but both servers see the same directory structure.

WLS_WCC2

WCC Install

VOL2

MW_HOME/wcc

Individual in each volume, but both servers see the same directory structure.

WLS_SOA1

Domain Config

VOL1

ORACLE_BASE/admin/domain_name/aserver/domain_name

Used by only one server where the Administration Server is running.

WLS_WCC1

Domain Config

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

Individual in each volume, but both servers see the same directory structure.

WLS_WCC2

Domain Config

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

Individual in each volume, but both servers see the same directory structure.

WLS_WCC1

Web and Vault Files

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/vault

Directory for vault files on a separate volume with locking disabled.

WLS_WCC1

Web and Vault Files

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/weblayout

Directory for weblayout files on a separate volume with locking disabled.

WLS_WCC2

Web and Vault Files

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/vault

Directory for vault files on a separate volume with locking disabled.

WLS_WCC2

Web and Vault Files

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/weblayout

Directory for weblayout files on a separate volume with locking disabled.

WLS_IBR1

Inbound Refinery Files

VOL3

ORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrn

Directory for all Inbound Refinery files on a separate volume with locking disabled.


Note:

VOL3 is mounted as an NFS nolock volume. For details, see Section 4.4, "Configuring Shared Storage".

4.4 Configuring Shared Storage

Use the following commands to create and mount shared storage locations so that WCCHOST1 and WCCHOST2 can see the same location for binary installation in two separate volumes.

Note:

The user ID used to create a shared storage file system owns those files and has read, write, and execute privileges for them. Other users in the operating system group can read and execute the files, but they do not have write privileges. For more information about installation and configuration privileges, see the "Understanding Installation and Configuration Privileges and Users" section in the Oracle Fusion Middleware Installation Planning Guide.

In the commands, nasfiler is the shared storage filer.

From SOAHOST1 and from WCCHOST1:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

From SOAHOST2 and from WCCHOST2:

mount nasfiler:/vol/vol2/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

If only one volume is available, you can provide redundancy for the binaries by using two different directories in the shared storage and mounting them to the same directory in the Oracle WebCenter Content servers:

From SOAHOST1 and from WCCHOST1:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw1 ORACLE_BASE/product/fmw -t nfs

From SOAHOST2 and from WCCHOST2:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw2 ORACLE_BASE/product/fmw -t nfs

The following commands show how to share the Oracle WebCenter Content TX logs location across different nodes:

From WCCHOST1:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs -t nfs

From WCCHOST2:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs -t nfs

The following commands show how to share the Imaging jms location across different nodes:

From WCCHOST1:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/img_cluster_name/jms 
ORACLE_BASE/admin/domain_name/img_cluster_name/jms  -t nfs

From WCCHOST2:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/img_cluster_name/jms 
ORACLE_BASE/admin/domain_name/img_cluster_name/jms  -t nfs

The following commands show how to share WebCenter Content and Inbound Refinery files across different nodes:

WCPAHOST1> mount nasfiler:/vol/vol3/ORACLE_BASE/admin/wcdomain/wcc_cluster_name/vault
-t nfs -o rw,bg,hard,vers=3,nolock

WCPHOST1> mount nasfiler:/vol/vol3/ORACLE_BASE/admin/wcdomain/ibr_cluster_name/
nfs -o rw,bg,hard,vers=3,nolock 

And likewise for WCPHOST2.

Validating the Shared Storage Configuration

Ensure that you can read and write files to the newly mounted directories by creating a test file in the shared storage location you just configured.

For example:

cd newly_mounted_directory
touch testfile

Verify that the owner and permissions are correct:

ls -l testfile

Then remove the file:

rm testfile

Note:

The shared storage can be a NAS or SAN device. The following illustrates an example of creating storage for a NAS device from SOAHOST1. The options may differ.

mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

Contact your storage vendor and machine administrator for the correct options for your environment.

4.5 Preparing the File System for Enterprise Deployment Summary

After reading this chapter you should have an understanding of the recommended file structure defined in this guide. You should also be prepared to configure shared storage for your Oracle WebCenter Content enterprise deployment. Chapter 5, "Preparing the Database for an Enterprise Deployment" describes how to set up the database, load the metadata repository in the Oracle RAC database, and back up the database.