4 Preparing the File System for an Enterprise Deployment

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

This chapter includes the following topics:

Section 4.1, "Overview of Preparing the File System for Enterprise Deployment"
Section 4.2, "Terminology for Directories and Directory Environment Variables"
Section 4.3, "About Recommended Locations for the Different Directories"
Section 4.4, "Configuring Shared Storage"

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 Business Intelligence enterprise deployment. The following directory variables are used to describe the directories installed and configured in the guide:

ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.
MW_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware resides.
WL_HOME: This environment variable and related directory path contains installed files necessary to host an Oracle WebLogic Server.
ORACLE_HOME: This environment variable and related directory path refers to the directory where the binaries required to run Oracle Business Intelligence are installed.
ORACLE_COMMON_HOME: This environment variable and related directory path refers to the Oracle home that contains the binary and library files required for Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).
Domain directory: This directory path refers to the location where the Oracle WebLogic domain information (configuration artifacts) is stored. Different WLS Servers can use different domain directories even when in the same node.
ORACLE_INSTANCE: An Oracle instance directory contains configuration files, log files, and temporary files for one or more Oracle system components (such as Oracle BI Server, Oracle BI Presentation Services, Oracle HTTP Server, and so on).

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 About Recommended Locations for the Different Directories

Oracle Business Intelligence 11g supports the deployment and instantiation of multiple processes (such as Managed Servers, BI Servers, and Presentation Services servers) from a single binary installation. This capability simplifies lifecycle operations like patching, upgrade, and test-to-production, as well as scale-out operations for an Oracle Business Intelligence deployment. However, for maximum availability, Oracle recommends using redundant binary installations. In the EDG 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 subsequent 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 on different computers, you should keep the Oracle Inventory (oraInventory) and Middleware home list on those computers up-to-date. Doing so ensures consistency when you perform future installations or apply patches. To update the oraInventory on a computer 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 is required for any additional computers where Oracle Business Intelligence is installed, in addition to the two computers used in this EDG.

Oracle recommends also separating the domain directory used by the Administration Server from the domain directory used by the 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 computer with the same configuration. The domain directories of the Managed Servers can reside in a local or shared storage.

You can use a shared domain directory for all Managed Servers on different computers, or use one domain directory for each computer. 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 computers mounting the same shared volume.

All procedures that apply to multiple local domains apply to a single shared domain. Therefore, this enterprise deployment guide uses a model where one domain directory is used for each computer. The directory can be local or reside in shared storage.

4.3.1 Recommended Directory Locations

This section describes the directories recommended. 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. However, 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

Mount point: ORACLE_BASE/product/fmw
Shared storage location: ORACLE_BASE/product/fmw (VOL1 and VOL2)
Mounted from: Nodes alternatively mount VOL1 or VOL2 in such a way that at least half the nodes use an installation and the other half use the other one. In the EDG for Oracle Business Intelligence, APPHOST1 mounts VOL1 and APPHOST2 mounts VOL2. When only one volume is available, nodes mount two different directories in shared storage alternatively (that is, for example, APPHOST1 would use ORACLE_BASE/product/fmw1 as shared storage location and APPHOST2 would use ORACLE_BASE/product/fmw2 as shared storage location).

Note:

When there is just one volume available in the shared storage, you can provide redundancy using different directories to protect from accidental file deletions and for patching purposes. Two MW_HOMEs would be available; at least one at ORACLE_BASE/product/fmw1, and another at ORACLE_BASE/product/fmw2. These MW_HOMEs are mounted on the same mount point in all nodes.

MW_HOME (Web tier):

ORACLE_BASE/product/fmw/web

Mount point: ORACLE_BASE/product/fmw
Shared storage location: ORACLE_BASE/product/fmw (VOL1 and VOL2)
Mounted from: For shared storage installations, nodes alternatively mount VOL1 or VOL2 in such a way that at least half the nodes use an installation and the other half use the other one. In the EDG for BI, WEBHOST1 would mount VOL1 and WEBHOST2 would mount VOL2. When only one volume is available, nodes mount the two suggested directories in shared storage alternatively (that is, for example, WEBHOST1 would use ORACLE_BASE/product/fmw1 as shared storage location and WEBHOST2 would use ORACLE_BASE/product/fmw2 as shared storage location).

Note:

Web tier installation is usually performed on local storage to the WEBHOST nodes. When using shared storage, appropriate security restrictions for access to the storage device across tiers must be considered.

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/Oracle_BI1

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

ORACLE_INSTANCE:

ORACLE_BASE/admin/instance_name

If you are using a shared disk, the mount point on the system is ORACLE_BASE/admin/instance_name mounted to ORACLE_BASE/admin/instance_name (VOL1).

Note:

(VOL1) is optional; you could also use (VOL2).

Domain Directory for Admin Directory:

ORACLE_BASE/admin/domain_name/aserver/domain_name (the last "domain_name" is added by the Configuration Assistant).

Mount point on system: ORACLE_BASE/admin/domain_name/aserver
Shared storage location: ORACLE_BASE/admin/domain_name
Mounted from: Only the node where the Administration Server is running needs to mount this directory. When the Administration Server is relocated (failed over) to a different node, the node then mounts the same shared storage location on the same mount point. The remaining nodes in the topology do not need to mount this location.

Domain Directory for Managed Server:

ORACLE_BASE/admin/domain_name/mserver/domain_name

If you are using a shared disk, the mount point on the system is ORACLE_BASE/admin/domain_name/mserver mounted to ORACLE_BASE/admin/domain_name/Noden/mserver/ (each node uses a different domain directory for Managed Servers).

Note:

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

Location for JMS file-based stores and Tlogs:

ORACLE_BASE/admin/domain_name/cluster_name/jms

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

Mount point: ORACLE_BASE/admin/domain_name/cluster_name
Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name
Mounted from: All nodes running BI components must mount this shared storage location so that transaction logs and JMS stores are available when server migration to another node takes place.

Location for Oracle BI Presentation Catalog:

ORACLE_BASE/admin/domain_name/cluster_name/catalog/customCatalog (where customCatalog is an example of the catalog name)

Mount point: ORACLE_BASE/admin/domain_name/cluster_name
Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name
Mounted from: All nodes containing the instances of Presentation Services in the cluster mount this location (all nodes must have read and write access).

Note that the Oracle BI Presentation Catalog is called Presentation Service Repository in Fusion Middleware Control.

Location for Repository Publishing Directory:

ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD

Mount point: ORACLE_BASE/admin/domain_name/cluster_name
Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name
Mounted from: All nodes containing the instances of BI Server in the cluster mount this location. The master BI Server must have read and write access to this directory. All other BI Servers must have read access.

Note that the repository publishing directory is identified as the Shared Location for the BI Server Repository in Fusion Middleware Control.

Location for BI Server Global Cache:

ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache

Mount point: ORACLE_BASE/admin/domain_name/cluster_name

Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name

Mounted from: All nodes containing the instances of BI Server in the cluster mount this location. The master BI Server must have read and write access to this directory. All other BI Servers must have read access.

Location for BI Publisher Configuration Folder:

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config

Mount point: ORACLE_BASE/admin/domain_name/cluster_name
Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name
Mounted from: All nodes containing the instances of BI Publisher in the cluster mount this location with read/write access.

Location for BI Publisher Scheduler Temp Directory:

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp

Mount point: ORACLE_BASE/admin/domain_name/cluster_name
Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name
Mounted from: All nodes containing the instances of BI Publisher in the cluster mount this location with read/write access.

Location for Application Directory for Administration Server:

ORACLE_BASE/admin/domain_name/aserver/applications

Mount point: ORACLE_BASE/admin/domain_name/aserver/applications
Shared storage location: ORACLE_BASE/admin/domain_name/aserver

Location for Application Directory for Managed Server:

ORACLE_BASE/admin/domain_name/mserver/applications

Note:

This directory is local in the context of the EDG for Oracle Business Intelligence.

4.3.2 Directory Structure and Configurations

This section provides a diagram to help illustrate the recommended directory structure and shared storage.

Figure 4-1 shows the recommended directory structure.

Figure 4-1 EDG Directory Structure for Oracle Business Intelligence

Description of "Figure 4-1 EDG Directory Structure for Oracle Business Intelligence"

Note that the directory structure in Figure 4-1 does not show other required internal directories such as oracle_common. It also does not show shared component directories; see Section 4.4, "Configuring Shared Storage" for information about shared directories.

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

Table 4-1 Directory Structure Elements

Element	Explanation
	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.
	The Managed Server domain directories can be on a local disk or a shared disk. To share the Managed Server domain directories on multiple computers, you must mount the same shared disk location across the computers. The instance_name directory for the Web tier can be on a local disk or a shared disk.
	Fixed name.
	Installation-dependent name.

4.4 Configuring Shared Storage

Use the following commands to create and mount shared storage locations so that APPHOST1 and APPHOST2 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 and has read, write, and execute privileges for those files. 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.

"nasfiler" is the shared storage filer.

From APPHOST1:

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw
/u01/app/oracle/product/fmw -t nfs

From APPHOST2:

APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw
/u01/app/oracle/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 APPHOST servers:

From APPHOST1:

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/product/fmw1
/u01/app/oracle/product/fmw -t nfs

From APPHOST2:

APPHOST2> mount nasfiler:/vol/vol2/u01/app/oracle/product/fmw2
/u01/app/oracle/product/fmw -t nfs

The following commands show how to share the BI TX logs location across different nodes:

APPHOST1> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundation_domain/
bi_cluster/tlogs /u01/app/oracle/stores/bifoundation_domain/
bi_cluster/tlogs -t nfs

APHOST2> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundatin_domain/
bi_cluster/tlogs /u01/app/oracle/stores/bifoundation_domain/
bi_cluster/tlogs -t nfs

Note:

The shared storage can be a NAS or SAN device. The following illustrates an example of creating storage for a NAS device from APPHOST1. The options may differ depending on the specific storage device.

APPHOST1> 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 computer administrator for the correct options for your environment.

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

4.4.1 Ensuring That Shared Network Files Are Accessible in Windows Environments

In Windows environments, shared storage is typically specified using Universal Naming Convention (UNC). UNC is a PC format for specifying locations of resources on a local area network. UNC uses the following format:

\\server_name\shared_resource_path_name

In addition, you must use named users to run OPMN processes in Windows environments so that the shared network files are accessible.

To run OPMN processes using a named user:

Open the Services dialog. For example, select Start > Programs > Administrative Tools > Services.
Right-click OracleProcessManager_instancen and then select Properties.
Select the Log On tab.
Select This account, and then provide a user name and password.
Click OK.