4 Preparing the File System for an Enterprise Deployment

This chapter describes how to prepare the 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:

4.1 Overview of Preparing the File System for Enterprise Deployment

It is important to set up the file system in a way that makes the enterprise deployment easier to understand, configure, and manage. Oracle recommends setting up the file 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 Variables

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

  • ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.

  • MW_HOME: This variable and related directory path refers to the location where Oracle Fusion Middleware resides.

  • WL_HOME: This 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 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 WebLogic 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).

  • JAVA_HOME: This environment variable and related directory path refers to the location where JRockit is installed.

  • ASERVER_HOME: This variable and related directory path refers the primary location of the domain configuration.

  • MSERVER_HOME: This variable and related directory path refers to the domain configuration that is used to start and stop Managed Servers.

  • WEBGATE_ORACLE_HOME: This variable and related directory path refers to the location of the WebGate installation.

Tip:

You can simplify directory navigation by using environment variables as shortcuts to the locations in this section. For example, you 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 use %ORACLE_BASE% and use Windows-specific commands.

4.3 About Recommended Locations for the Different Directories

The following sections describe basic recommendations for using shared storage for an enterprise deployment topology:

4.3.1 Shared Storage Recommendations for Binary (Oracle Home) Directories

The following sections describe guidelines for using shared storage for Oracle Fusion Middleware Oracle Home directories:

4.3.1.1 About the Binary (Oracle Home) Directories

When you install any Oracle Fusion Middleware product, you install the product into an Oracle home. The binary files that are installed in the Oracle home are read-only and remain unchanged unless the Oracle home is patched or upgraded to a newer version.

In a typical production environment, the Oracle home is saved in a separate location from the domain configuration files, which you create using the Oracle Fusion Middleware Configuration Assistant.

The Middleware home for an Oracle Fusion Middleware installation contains the binary files for Oracle WebLogic Server, the Oracle Fusion Middleware infrastructure files, and any Oracle Fusion Middleware product-specific directories.

For more information about the structure and contents of an Oracle Fusion Middleware Oracle home, see Oracle Fusion Middleware Concepts.

4.3.1.2 About Sharing a Single Oracle Home for Multiple Domains

Oracle Fusion Middleware enables you to configure multiple Oracle WebLogic Server domains from a single Oracle home. This ability allows you to install the Oracle home in a single location on a shared volume and reuse the Oracle home for multiple host installations.

When an Oracle home is shared by multiple servers on different hosts, keep certain best practices in mind. In particular, ensure that the Oracle Inventory (oraInventory) on each host is updated for consistency and for the application of patches.

To update the oraInventory for a host and attach an Oracle home on shared storage, enter the following command:

ORACLE_HOME/oui/bin/attachHome.sh

For more information about the oraInventory, see "About the Oracle Universal Installer Inventory" in Oracle Universal Installer Concepts Guide.

To update the Middleware home list to add or remove a MW_HOME, edit the user_home/bea/beahomelist file.

4.3.1.3 About Using Redundant Binary (Oracle Home) Directories

For maximum availability, Oracle recommends using redundant binary installations on shared storage.

In this model, you install two identical Oracle homes for the Oracle Fusion Middleware software on two different shared volumes. You then mount one of the Oracle homes to one set of servers, and the other Oracle home to the remaining servers. Each Oracle home has the same mount point, so the Oracle home always has the same path, regardless of which Oracle home the server is using.

If one Oracle home becomes corrupted or unavailable, then only half the servers are affected. For additional protection, Oracle recommends that you disk-mirror these volumes.

If separate volumes are not available on shared storage, then Oracle recommends simulating separate volumes using different directories within the same volume and mounting those to the same mount location on the host side. Although this approach does not guarantee the protection that multiple volumes provide, the approach does allow protection from user deletions and individual file corruption.

4.3.2 Shared Storage Recommendations for Domain Configuration Files

The following sections describe guidelines for using shared storage for the Oracle WebLogic Server domain configuration files that you create when you configure Oracle Fusion Middleware products in an enterprise deployment:

4.3.2.1 About Oracle WebLogic Server Administration and Managed Server Domain Configuration Files

When you configure an Oracle Fusion Middleware product, you create or extend an Oracle WebLogic Server domain. Each Oracle WebLogic Server domain consists of a single Administration Server and one or more Managed Servers.

For more information about domains, see Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server.

In an enterprise deployment, bear in mind that the Managed Servers in a domain can be configured for active-active high availability. However, the Administration Server cannot. The Administration Server is a singleton service. That is, it can be active on only one host at one time.

4.3.2.2 Shared Storage Requirements for Administration and Managed Server Domain Configuration Files

Oracle recommends creating two copies of the domain configuration files:

  • One copy is for the Administration Server configuration files.

    You install this directory on shared storage and mount it exclusively to the host that is running the Administration Server.

    In the event of the failure of that host, you can mount the directory on a different host and the Administration Server started on that host.

  • The other copy is for the Managed Server configuration files.

    The Managed Servers' domain directories can reside in local or shared storage. Sharing domain directories for Managed Servers facilitates the scale-out procedures. However, sharing the Managed Server configuration files can also have a potential performance impact.

    As a result, the deployment that you decide on should conform to the requirements (if any) of the storage system. Some storage systems offer configuration options to facilitate multiple machines mounting the same shared volume.

    The configuration steps that are provided for this enterprise deployment topology assume that a local domain directory for each node is used for each Managed Server.

4.3.3 Shared Storage Recommendations for JMS File Stores and JTA Transaction Logs

JMS file stores and JTA transaction logs must be placed on shared storage to ensure that they are available from multiple hosts for recovery in the case of a server failure or migration.

For more information on using JMS and JTA information in a file store, see "Using the WebLogic Persistence Store" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.

4.3.4 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 when the provided mount points are used. However, Oracle recommends this structure in the shared storage device for consistency and simplicity.

ORACLE_BASE:

Recommended directory = /u01/app/oracle

Domain Directory for Administration Server Domain Directory:

ORACLE_BASE/admin/domain_name/aserver/domain_name

  • Mount point on system: ORACLE_BASE/admin/domain_name/aserver

  • Shared storage location: ORACLE_BASE/admin/domain_name/aserver

  • 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 Domain Directory:

ORACLE_BASE/admin/domain_name/mserver/domain_name

  • If you are using a shared disk, then 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 shared-storage dependent. The example in the preceding bullet point is specific to NAS, but other storage types might 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 that run Oracle 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 Application Directory for Administration Server:

ORACLE_BASE/admin/domain_name/aserver/applications

  • Mount point: ORACLE_BASE/admin/domain_name/aserver

  • Shared storage location: ORACLE_BASE/admin/domain_name/aserver

  • Mounted from: Only the node where the Administration Server is running must 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.

Location for Application Directory for Managed Server:

ORACLE_BASE/admin/domain_name/mserver/applications

Note:

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

MW_HOME (Application Tier):

Recommended directory = 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 enterprise deployment 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 uses ORACLE_BASE/product/fmw1 as shared storage location and APPHOST2 uses 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 are 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):

Recommended directory = 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 mounts VOL1 and WEBHOST2 mounts VOL2. When only one volume is available, nodes mount the two suggested directories in shared storage alternatively (that is, for example, WEBHOST1 uses ORACLE_BASE/product/fmw1 as shared storage location and WEBHOST2 uses 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:

Recommended directory = MW_HOME/wlserver_10.3

ORACLE_HOME:

Recommended directory = MW_HOME/Oracle_BI1

ORACLE_COMMON_HOME:

Recommended directory = MW_HOME/oracle_common

ORACLE_INSTANCE:

Recommended directory = ORACLE_BASE/admin/instance_name

  • If you are using a shared disk, then 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 can also use (VOL2).

Location for Oracle BI Presentation Catalog:

Recommended directory = 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 that contain 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:

Recommended 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 that contain 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 Essbase Agent Shared Folder Path

Recommended directory = ORACLE_BASE/admin/domain_name/cluster_name/Essbase/essbaseserver1

  • Mount point: ORACLE_BASE/admin/domain_name/cluster_name

  • Shared storage location: ORACLE_BASE/admin/domain_name/cluster_name

  • Mounted from: All nodes that contain the instances of Essbase Agent in the cluster mount this location (all nodes must have read and write access).

Location for BI Server Global Cache:

Recommended directory = 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 that contain 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:

Recommended directory = 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 that contain the instances of BI Publisher in the cluster mount this location with read/write access.

Location for BI Publisher Scheduler Temp Directory:

Recommended 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 that contain the instances of BI Publisher in the cluster mount this location with read/write access.

4.3.5 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 follows
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. The structure shows directories for application configuration files such as the RPD Publishing directory, the shared Oracle BI Presentation Catalog, the Global Cache, and the Essbase Shared Folder Path. 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

Administration 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 element

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 element

Fixed name.

Installation-dependent names element

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 that is 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 "Understanding Installation and Configuration Privileges and Users" section in 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, then you can provide redundancy for the binary files 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 location of the JTA transaction logs across different nodes:

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

APHOST2> mount nasfiler:/vol/vol1/u01/app/oracle/stores/bifoundatin_domain/
bi_cluster/tlogs /u01/app/oracle/admin/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 might 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 the 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.

Perform the following steps to run OPMN processes using a named user:

  1. Open the Services dialog. For example, select Start > Programs > Administrative Tools > Services.

  2. Right-click OracleProcessManager_instancen and then select Properties.

  3. Select the Log On tab.

  4. Select This account, and provide a user name and password.

  5. Click OK.