4 Preparing the File System for an Enterprise Deployment

This chapter describes how to prepare the file system for an Oracle Identity Management enterprise deployment.

The file system model described in this guide was chosen for maximum availability, best isolation of components, symmetry in the configuration, and facilitation of backup and disaster recovery. The rest of the guide uses this directory structure and directory terminology. Other directory layouts are possible and supported.

This chapter contains the following topics:

• Section 4.1, "Overview of Preparing the File System for Enterprise Deployment"

• Section 4.2, "Terminology for Directories and Directory Variables"

• Section 4.3, "ASERVER_HOME and MSERVER_HOME"

• Section 4.4, "About Recommended Locations for the Different Directories"

• Section 4.5, "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 Variables

This section describes the directory variables used throughout this guide for configuring the Oracle Identity Management enterprise deployment. You are not required to set these as environment variables. 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. For example: u01/app/oracle

• MW_HOME: This variable and related directory path refers to the location where Oracle Fusion Middleware resides. A MW_HOME has a WL_HOME, an ORACLE_COMMON_HOME and one or more ORACLE_HOMEs. An example of a typical MW_HOME is ORACLE_BASE/product/fmw

• WL_HOME: This variable and related directory path contains installed files necessary to host a WebLogic Server, for example MW_HOME/wlserver_10.3.

• ORACLE_HOME: This variable points to the location where an Oracle Fusion Middleware product, such as Oracle HTTP Server, Oracle SOA Suite, or Oracle Internet Directory is installed and the binaries of that product are being used in a current procedure. For example: MW_HOME/iam

• ORACLE_COMMON_HOME: This variable and related directory path refer to the location where the Oracle Fusion Middleware Common Java Required Files (JRF) Libraries and Oracle Fusion Middleware Enterprise Manager Libraries are installed. An example is: MW_HOME/oracle_common

• Domain directory: This path refers to the file system 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 as described Section 4.4, "About Recommended Locations for the Different Directories."

• ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files. An example is: ORACLE_BASE/admin/ohs_inst1

• ASERVER_HOME: This is the primary location of the domain configuration. A typical example is: ORACLE_BASE/admin/IDMDomain/aserver

• MSERVER_HOME: This is a copy of the domain configuration used to start and stop managed servers. A typical example is: ORACLE_BASE/admin/IDMDomain/mserver

4.3 ASERVER_HOME and MSERVER_HOME

As described in the previous section ASERVER_HOME and MSERVER_HOME are two locations for the domain, a primary and a copy location, respectively. Having two separate locations allows you to administer the managed servers independently of the administration server.

ASERVER_HOME, the primary copy, is mounted on shared storage so that the administration server can be failed over to another host if the primary host becomes unavailable. This is necessary because the administration server is a singleton service. That is, it can only be active on one host at any given time. ASERVER_HOME is placed onto shared storage and is mounted exclusively to the host which is running the administration server. In the event of the failure of that host, the ASERVER_HOME directory is mounted on a different host and the administration server started on that host.

A copy of the domain server, MSERVER_HOME, is placed onto local storage, and managed servers are started from this copy. You create the copy using the weblogic utilities pack and unpack. The reason for using the copy is that starting managed servers from shared storage is unnecessary and incurs a performance penalty. Allowing managed servers to write to local storage eliminates the performance problem.

When extending a domain, always use the primary ASERVER_HOME location.

4.4 About Recommended Locations for the Different Directories

Oracle Fusion Middleware 11g enables you to create multiple Identity Management components from one single binary installation. This allows you to install binaries in a single location on a shared storage and reuse this installation for the servers in different nodes.

When an ORACLE_HOME or a WL_HOME is shared by multiple servers in different nodes, keep the Oracle Inventory and Middleware home lists 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 file beahomelist located in a directory called bea in the users home directory, for example: /home/oracle/bea/beahomelist. This is required for any nodes installed in addition to the two used in this Enterprise Deployment. An example of the oraInventory and beahomelist updates is provided in the scale-out steps included in this guide. See Section 21.4.2, "Scaling Out the Topology."

Oracle recommends also separating the domain directory used by the WebLogic 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 shared storage to allow failover to another node with the same configuration. The managed servers' domain directories can reside in local or shared storage.

You can use a shared domain directory for all managed servers in different nodes or use one domain directory for each node. Sharing domain directories for managed servers facilitates the scale-out procedures. It is not recommended to place managed server directories onto shared storage because of the potential performance impact. 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 domain directory for each node is used for each managed server.

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

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

For the application tier, it is recommended to have Middleware Home (MW_HOME) on a shared disk. It is recommended to have two MW_HOMEs in the domain for High Availability. An application tier node mounts either one of these on a mount point. This mount point should be the same on all the application tier nodes. Additional servers (when scaling out or up) of the same type can use one of these MW_HOMEs without requiring more installations.

If you are implementing a split domain topology, you also need a separate MW_HOME for the second domain. This will facilitate independent patching.

This section contains the following topics:

• Section 4.4.1, "Local Storage"

• Section 4.4.2, "Shared Storage"

• Section 4.4.3, "Redundant Binary Installations"

• Section 4.4.4, "Directory Structure"

4.4.1 Local Storage

In an Enterprise Deployment it is recommended that the following directories be created on local storage:

Table 4-1 Local Storage Directories

Tier	Environment Variable	Directory	Hosts
Web Tier	MW_HOME	/u01/app/oracle/product/fmw	WEBHOST1 WEBHOST2
Web Tier and Directory Tier	ORACLE_INSTANCE	/u01/app/oracle/admin/instancename	WEBHOST1 WEBHOST2
Directory Tier	MW_HOME	/u01/app/oracle/product/fmw	OIDHOST1 OIDHOST2 OVDHOST1 OVDHOST2
Application Tier and Directory Tier	MSERVER_HOME	/u01/app/oracle/admin/domain_name/mserver	IDMHOST1 IDMHOST2 OIMHOST1 OIMHOST2

4.4.2 Shared Storage

In an Enterprise Deployment it is recommended that the volumes shown in Table 4-2 or Table 4-3 be created on shared Storage. Note that the details differ, depending on whether you are using a single domain or split domain topology. You can mount shared storage either exclusively or shared. If you mount it exclusively, it will be mounted to only one host at a time. (This is typically used for active/passive failover).

When scaling out or scaling up, you can use the shared MW_HOME for additional servers of the same type without performing more software installations.

Table 4-2 Single Domain Topology

Tier	Environment Variable	Volume	Mount Point	Mounted on Hosts	Exclusive Mount
Application Tier	MW_HOME	VOL1/MW_HOME1	/u01/app/oracle/product/fmw	IDMHOST1 IDMHOST2 OIMHOST1 OIMHOST2	No
Application Tier	ASERVER_HOME	VOL1/ADMIN1	/u01/app/oracle/admin/domain_name/aserver	IDMHOST1 IDMHOST2	Yes
Application Tier		VOL1/SOA	/u01/app/oracle/admin/domain_name/soa_cluster	OIMHOST1 OIMHOST2	No
Application Tier		VOL1/OIM	/u01/app/oracle/admin/domain_name/oim_cluster	OIMHOST1 OIMHOST2	No

Table 4-3 Split Domain Topology

Tier	Environment Variable	Volume	Mount Point	Mounted on Hosts	Exclusive Mount
Application Tier	MW_HOME	VOL1/MW_HOME1	/u01/app/oracle/product/fmw	IDMHOST1 IDMHOST2	No
Application Tier	ASERVER_HOME	VOL1/ADMIN1	/u01/app/oracle/admin/domain_name/aserver	IDMHOST1 IDMHOST2	Yes
Application Tier	MW_HOME	VOL2/MW_HOME2	/u01/app/oracle/product/fmw	OIMHOST1 OIMHOST2	No
Application Tier	ASERVER_HOME	VOL2/ADMIN2	/u01/app/oracle/admin/domain_name/aserver	OIMHOST1 OIMHOST2	Yes
Application Tier		VOL2/SOA	/u01/app/oracle/admin/domain_name/soa_cluster	OIMHOST1 OIMHOST2	No
Application Tier		VOL2/OIM	/u01/app/oracle/admin/domain_name/oim_cluster	OIMHOST1 OIMHOST2	No

4.4.3 Redundant Binary Installations

For maximum availability, Oracle recommends using redundant binary installations. In the redundant Enterprise deployment model, you create two identical MW_HOMEs, each of which has a WL_HOME and an ORACLE_HOME for each product suite in shared storage. You then mount one of these MW_HOMEs to one set of servers, and the other to the remaining ones. Each MW_HOME has the same mount point, so regardless of which server you are connected to, MW_HOME has the same path.

Adopting this approach protects you from user errors, such as accidental deletion of files in the MW_HOME. Should such an error occur, only half your servers are affected. Ideally, these MW_HOMEs should be on two different volumes in order to isolate the failures in each volume as much as possible. For additional protection, Oracle recommends that you disk mirror these volumes.

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

4.4.4 Directory Structure

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

Figure 4-1 shows the recommended directory structure.

Figure 4-2 shows the recommended structure to use with a split directory topology.

Figure 4-1 Directory Structure for Identity Management

Figure 4-2 Directory Structure for Identity Management Split Domain Topology

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

The directory structure in Figure 4-1 and Figure 4-2 do not show other required internal directories such as ORACLE_COMMON_HOME and jrockit.

Table 4-4 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. 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.
	Installation-dependent name.

4.5 Configuring Shared Storage

Use the following commands to create and mount shared storage locations so that each server pair, such as IDMHOST1 and IDMHOST2, can see the same location for binary installation in two separate volumes. Repeat the commands for the following server pairs:

1. IDMHOST1 and IDMHOST2

2. OIMHOST1 and OIMHOST2

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 IDMHOST1:

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

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs
/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs -t nfs

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs
/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs -t nfs

From IDMHOST2:

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

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs
/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs -t nfs

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs
/ORACLE_BASE/stores/idmdomain/soa_cluster/tlogs -t nfs

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 IDMHOST1. The options may differ depending on the specific storage device.

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.