7 Preparing Storage for an Enterprise Deployment

This chapter describes how to prepare storage for an Oracle Identity and Access Management enterprise deployment.

The storage 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 a directory structure and directory terminology based on this storage model. Other directory layouts are possible and supported.

This chapter contains the following topics:

7.1 Overview of Preparing Storage for Enterprise Deployment

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

7.2 Terminology for Directories and Directory Variables

This section describes the directory variables used throughout this guide for configuring the Oracle Identity and Access 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:

  • IDM_TOP: This environment variable and related directory path refers to the base directory under which the Oracle Binaries and configuration information is stored.

  • 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.

    There is a different MW_HOME for each product suite.

    In this guide, this value might be preceded by a product suite abbreviation, for example: DIR_MW_HOME, IAD_MW_HOME, IGD_MW_HOME, and WEB_MW_HOME.

  • WL_HOME: This variable and related directory path contains installed files necessary to host a WebLogic Server. The WL_HOME directory is a peer of Oracle home directory and resides within the MW_HOME.

  • ORACLE_HOME: This variable points to the location where an Oracle Fusion Middleware product, such as Oracle HTTP Server or Oracle SOA Suite is installed and the binaries of that product are being used in a current procedure. In this guide, this value might be preceded by a product suite abbreviation, for example: IAD_ORACLE_HOME, IGD_ORACLE_HOME, WEB_ORACLE_HOME, WEBGATE_ORACLE_HOME, SOA_ORACLE_HOME, and OUD_ORACLE_HOME.

  • 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

  • ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache or Oracle HTTP Server. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files.

    In this guide, this value might be preceded by a product suite abbreviation, such as WEB_ORACLE_INSTANCE.

  • JAVA_HOME: This is the location where Oracle java JDK is installed.

  • ASERVER_HOME: This path refers to the file system location where the Oracle WebLogic domain information (configuration artifacts) are stored.

    There is a different ASERVER_HOME for each domain used, specifically: IGD_ASERVER_HOME and IAD_ASERVER_HOME

  • MSERVER_HOME: This path refers to the local file system location where the Oracle WebLogic domain information (configuration artifacts) are stored.This directory is generated by the pack/unpack utilities and is a subset of the ASERVER_HOME. It is used to start and stop managed servers. The Administration Server is still started from the ASERVER_HOME directory.

    There is a different MSERVER_HOME for each domain used. Optionally, it can be used to start and stop managed servers.

For more information about, and examples of these variables, see Section 7.5.5, "Recommended Directory Locations."

7.3 Overview of Enterprise Deployment Storage

When deciding how to prepare shared storage, consider the following:

Sharing Requirements

An artifact is either shared, or not-shared (or private), or available:

  • Shared: The artifact resides on shared storage and can be simultaneously viewed and accessed by all client machines.

  • Available: The artifact resides on shared storage, but only one client machine can view and access the artifact at a time. If this machine fails, another client machine can then access the artifact.

  • Not-shared: The artifact can reside on local storage and never needs to be accessible by other machines.

Read/Write Requirements

An artifact will also have specific read/write requirements:

  • Read-Only: This artifact is rarely altered but only read at runtime.

  • Read-Write: This artifact is both read and written to at runtime.

Artifact Characteristics

With these requirements in mind, the artifacts deployed in a typical enterprise deployment are classified in Table 7-1.

Table 7-1 Typical Artifacts Deployed

Artifact type Sharing Read/Write

Binaries - Application Tier

Shared

Read-Only

Binaries - Web Tier

Private

Read-Only

Configuration - Directory Tier

Private

Read-Write

Configuration - Web Tier

Private

Read-Write

Managed Server Domain Home

Private

Read-Write

Admin Server Domain Home

Available

Read-Write

Runtime Files

Available

Read-Write

Node Manager Configuration

Private

Read-Write

Application Specific Files

Shared

Read-Write

7.4 About File Systems

After you create the partitions on your storage, you must place file systems on the partitions so that you can store the Oracle files. For local or direct attached shared storage, the file system type is most likely the default type for your operating system, for example: EXT3 for Linux.

If your shared storage is on network attached storage (NAS), which is accessed by two or more hosts either exclusively or concurrently, then you must use a supported clustered file system such as NFS version 3 or 4. Such file systems provide conflict resolution and locking capabilities.

7.5 Understanding the Enterprise Deployment Directory Structure

Each Oracle Fusion Middleware enterprise deployment is based on a similar directory structure. This directory structure has been designed to separate binaries, configuration, and runtime information. Binaries are defined as the Oracle software installation. Binaries include such things as the JDK, WebLogic Server, and the Oracle Fusion Middleware software being used (for example, Oracle Identity and Access Management or WebCenter).

The runtime directories are written to at runtime and hold information such as JMS queue files. The Server Domain Home directories are read from and written to at runtime.

For more information, see the following topics:

7.5.1 Recommendations for Binary (Middleware Home) Directories

The following sections describe guidelines for using shared storage for your Oracle Fusion Middleware middleware home directories:

7.5.1.1 About the Binary (Middleware Home) Directories

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

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

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

In a multi-tiered deployment, it is often not possible to mount a single share across the tiers. For example, the directory tier to the application tier. For LDAP deployments, you have three options:

  • Create a separate share for the directory binaries which is mounted only to the LDAP hosts using the same mount point as that of the application tier binaries. For example: /u01/oracle/products

    This option is recommended if you have firewalls between your zones.

  • Use the same share for both the application tier and the directory tier.

    This option is recommended if firewalls are not used between the directory and the application tiers. For example, in Exalogic deployments.

  • Install the directory binaries locally.

    This option is only applicable if you are performing a manual deployment.

The Web tier binaries are not shared. These are placed onto local storage so that SAN storage does not have to be mounted in the DMZ.

For more information about the structure and content of an Oracle Fusion Middleware home, see Section 7.2, "Terminology for Directories and Directory Variables".

7.5.1.2 About Sharing a Single Middleware Home

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

This enterprise deployment guide uses one middleware home per domain with additional middleware homes for directory and the Web servers.

The advantage of using multiple middleware homes is that they can be patched independently, placing no dependencies on common files. In this way it is possible to patch directory at a different time to identity, which may be patched at a different time to access.

To update the oraInventory for a host and attach a Middleware home on shared storage, use the following command:

ORACLE_HOME/oui/bin/attachHome.sh

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

7.5.1.3 About Using Redundant Binary (Middleware Home) Directories

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

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

Should one Middleware home become corrupted or unavailable, only half your servers are affected. 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.

This is normally achieved post deployment by performing the following steps:

  1. Create a new shared volume for binaries.

  2. Leave the original mounted volume on odd numbered servers. for example: OAMHOST1, OIMHOST1

  3. Mount the new volume in the same location on even mounted servers, for example: OAMHOST2, OIMHOST2

  4. Copy the files on volume1 to volume2 by copying from an odd numbered host to an even numbered host.

7.5.2 About the Lifecycle Repository

The lifecycle repository contains the Life Cycle Management tools, such as the deployment and patching tools. It also contains a software repository which includes the software to be installed as well as any patches to be applied.

It is recommended that the lifecycle repository be mounted onto every host in the topology for the duration of provisioning. This allows the deployment process to place files into this location ready for use by other process steps that might be running on different hosts. Having a centralized repository saves you from having to manually copy files around during the provisioning process.

Having a centralized repository is also important for patching. The repository is only required when provisioning or patching is occurring. At other times, this disk share can be unmounted from any or all hosts, ensuring security across zones is maintained.

The advantages of having a shared lifecycle repository are:

  1. Single location for software.

  2. Simplified deployment provisioning.

  3. Simplified patching.

Some organizations may prohibit the mounting of file systems across zones, even if it is only for the duration of initial provisioning or for patching. In this case, when you undertake deployment provisioning, you must duplicate the software repository and perform a number of manual file copies during the deployment process.

For simplicity, this guide recommends using a single shared lifecycle repository. However the guide does include the necessary extra manual steps in case this is not possible.

7.5.3 Recommendations for Domain Configuration Files

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

7.5.3.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 Oracle WebLogic Server domains, see Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server.

In an enterprise deployment, it is important to understand 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 any given time.

ASERVER_HOME is the primary location of the domain configuration. MSERVER_HOME is a copy of the domain configuration that is used to start and stop managed servers. The WebLogic Administration Server automatically copies configuration changes applied to the ASERVER_HOME domain configuration to all those MSERVER_HOME configuration directories that have been registered to be part of the domain. However, the MSERVER_HOME directories also contain deployments and data specific to the managed servers. For that reason, when performing backups, you must include both ASERVER_HOME and MSERVER_HOME.

7.5.3.2 Shared Storage Requirements for Administration Server Domain Configuration Files

Administration Server configuration files must reside on Shared Storage. This allows the administration server to be started on a different host should the primary host become unavailable. The directory where the administration server files is located is known as the ASERVER_HOME directory. This directory is located on shared storage and mounted to each host in the application tier.

Managed Server configuration Files should reside on local storage to prevent performance issues associated with contention. The directory where the managed server configuration files are located is known as the MSERVER_HOME directory. It is highly recommended that managed server domain configuration files be placed onto local storage.

7.5.3.3 Local Storage Requirements for Managed Server Domain Configuration Files

If you must use shared storage, it is recommended that you create a storage partition for each node and mount that storage exclusively to that node

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

7.5.4 Shared Storage Recommendations for Runtime Files

Files and directories that might need to be available to all members of a cluster are separated into their own directories. These include JMS files, transaction logs, and other artifacts that belong to only one member machine of a cluster, but might need to be available to other machines in case of failover.

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

Transaction logs' contents are relatively short-lived and their contents may usually relate to JMS operations. For backup and disaster protection purposes, it is important that both type of stores (jms and tlogs) are copied synchronously or continuously, and are in the same consistency group or replication_project as JMS stores (if multiple volumes are used for tlogs and jms replication). This way, immediate and synchronized copies of both stores are created. This will minimize data loss and will guaranty consistency.

7.5.5 Recommended Directory Locations

This section describes the recommended use of shared and local storage.

This section includes the following topics:

7.5.5.1 Life Cycle Management and Deployment Repository

A separate share is required to hold the Life Cycle Management tools and Deployment Repository. This share is only required during deployment and any subsequent patching. Once deployment is complete, you can unmount this share from each host.

Note:

If you have patches that you want to deploy using the patch management tool, you must remount this share while you are applying the patches.

Ideally, you should mount this share on ALL hosts for the duration of provisioning. Doing so will make the provisioning process simpler, as you will not need to manually copy any files, such as the keystores required by the Web Tier. If your organization prohibits sharing the LCM_HOME to the Web tier hosts (even for the duration of deployment), you must create a local copy of the contents of this share on the DMZ hosts and make manual file copies during the deployment phases.

Figure 7-1 Deployment Repository

Surrounding text describes Figure 7-1 .

Note:

The Life Cycle Management Repository is mandatory for LCM deployments. For Manual deployments, it is recommended. For simplicity, this guide assumes that you are using a deployment repository for both LCM and manual deployments.

If you download the software repository from http://edelivery.oracle.com, then the repository directory tree will be created for you. If you download the products individually, then you need to create the directory tree and create a separate sub directory for each product.

7.5.5.2 Shared Storage

In an Enterprise Deployment for IAM the following shared storage is required. The shared storage you create is the same regardless of whether you are creating a consolidated or distributed deployment. What does differ is the hosts you mount that shared on.

The recommended layout is described in Table 7-2 and Table 7-3 and shown in Figure 7-2.

Note:

Even though it is not shared, the IDM_TOP location must be writable.

Table 7-2 Volumes on Shared Storage–Distributed Topology

Environment Variable Volume Name Mount Point Mounted on Hosts Exclusive

SW_ROOT

Binaries

/u01/oracle/products

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2 LDAPHOST1 LDAPHOST2Foot 1 

No

SHARED_CONFIG_DIR

sharedConfig

/u01/oracle/config

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2

No

DIR_MW_HOMEFoot 2 

dirBinaries

/u01/oracle/products

LDAPHOST1 LDAPHOST2

No

RT_HOME

runTime

/u01/oracle/runtime

OIMHOST1 OIMHOST2

  

Footnote 1 Only mount to LDAPHOST1 and LDAPHOST2 when directory is in the Application Zone

Footnote 2 Only required when directory is being placed into a Directory/Database Zone

Table 7-3 Volumes on Shared Storage–Consolidated Topology

Environment Variable Volume Name Mount Point Mounted on Hosts Exclusive

SW_ROOT

Binaries

/u01/oracle/products

IAMHOST1 IAMHOST2 LDAPHOST1 LDAPHOST2Foot 1 

No

SHARED_CONFIG_DIR

sharedConfig

/u01/oracle/config

IAMHOST1 IAMHOST2

No

RT_HOME

runTime

/u01/oracle/runtime

IAMHOST1 IAMHOST2

  

Footnote 1 Only mount to LDAPHOST1 and LDAPHOST2 when directory is in the Application Zone

Notes on Shared Storage

Oracle IAM requires shared storage for product binaries and for shared configuration information.

If you are using a dedicated directory zone, and your organization prohibits the mounting of storage across zones, create a separate binary share for the directory tier.

If, however, you are not creating a separate directory zone, or if you are not prevented from mounting file systems across zones, you require only one share for all binaries (except Web Tier binaries).

In an Exalogic deployment, it is not necessary to separate out the binaries for the directory and application tiers.

If you do create two different binary shares (one for the application tier and one for the directory tier), they must have the same host mount point.

If you are using NFSv4, you will need a NIS server. You must ensure that the users referenced in Section 9.7, "Configuring Users and Groups" are created in NIS server, prior to being able to grant storage ownership to those NIS users.

Figure 7-2 Recommended Shared Storage Directory Structure

Surrounding text describes Figure 7-2 .

The figure shows the shared storage directory hierarchy. Under the mount point, /u01/oracle (IDM_TOP) are the directories config and products.

If you plan to deploy your directory into a different zone from the application tier and you do not want to mount your storage across zones, then you can create shared storage dedicated to the directory tier for the purposes of holding DIR_MW_HOME. Note that this will still have the same mount point as the shared storage in the application tier, for example: /u01/oracle.

The directory config contains domains, which contains:

  • IAMAccessDomain (IAD_ASERVER_HOME). IAMAccessDomain has three subdirectories: applications, servers, and keystores. The servers directory has a subdirectory, AdminServer.

  • IAMGovernanceDomain (IGD_ASERVER_HOME). IAMGovernanceDomain has five subdirectories: applications, servers, keystores, jms, and tlogs. The servers directory has a subdirectory, AdminServer.

The directory products contains the directories access, dir, and identity.

The directory access (IAD_MW_HOME) has four subdirectories: iam (IAD_ORACLE_HOME), oracle_common (ORACLE_COMMON_HOME), wlserver_10.3 (WL_HOME), and jdk (JAVA_HOME).

The directory identity (IGD_MW_HOME) has five subdirectories: iam (IGD_ORACLE_HOME), soa (SOA_ORACLE_HOME), oracle_common (ORACLE_COMMON_HOME), wlserver_10.3 (WL_HOME), and jdk (JAVA_HOME).

The directory runtime is used to store artefacts generated at runtime. For example, JMS and TLOG files.

If you have a dedicated directory tier, the share for SW_ROOT will be different depending on whether or not you are on an LDAPHOST or an IAMHOST.

7.5.5.3 Private Storage

Private storage refers to shared disk volumes that have been exclusively mounted or local storage.

Every host uses private storage for configuration information. In addition, the Web Tier hosts can store their binaries on private storage. This is especially important where the Web Tier hosts reside in a DMZ.

If you are installing on physical Exalogic without an external OHS, it is recommended that WEB_MW_HOME be placed onto shared storage. This is because, the OTD host is inside the Exalogic appliance and therefore has access to the ZFS storage device.

If you are installing on virtual Exalogic, it is recommended that the exclusively mounted shares on the shared storage are used, to enable simpler backups.

If you are using Exalogic or are mounting NFS shares to your web tier, then Webtier binaries can also reside on shared storage. The mount point for the binaries is the same whether it is on shared or private storage. If you are using Exalogic physical deployment where the web tier and the application tier are on the same compute nodes, then you do not need to create a separate share for the webtier binaries.

Table 7-4 Private Storage Directories - Distributed Topology

Tier Environment Variable Directory Hosts

Web Tier

WEB_MW_HOME

/u01/oracle/products

WEBHOST1

WEBHOST2
 

OHS_ORACLE_INSTANCE

/u02/private/oracle/config/instances/ohsn

WEBHOST1

WEBHOST2
 

OTD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/otdn

WEBHOST1

WEBHOST2
 

MSAS_ORACLE_INSTANCE

/u02/private/oracle/config/instances/gatewayid

WEBHOST1

WEBHOST2
 

OTD_ORACLE_HOME

/u01/oracle/products/web/otd

WEBHOST1

WEBHOST2
 

OHS_ORACLE_HOME

/u01/oracle/products/web/ohs

WEBHOST1

WEBHOST2

Application Tier

LDAP_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oidn

LDAPHOST1

LDAPHOST2
 

IAD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMAccessDomain

OAMHOST1

OAMHOST2
 

IGD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMGovernanceDomain

OIMHOST1

OIMHOST2

Directory Tier

DIR_MW_HOMEFoot 1 

/u01/oracle/products

LDAPHOST1

LDAPHOST2
 

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

LDAPHOST1

LDAPHOST2
 

OID_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oidn

LDAPHOST1

LDAPHOST2

Footnote 1 Only required when directory is being placed into a Directory/Database Zone

Table 7-5 Private Storage Directories - Consolidated Topology

Tier Environment Variable Directory Hosts

Web Tier

WEB_MW_HOME

/u01/oracle/products

WEBHOST1

WEBHOST2
 

OHS_ORACLE_INSTANCE

/u02/private/oracle/config/instances/ohsn

WEBHOST1

WEBHOST2
 

OTD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/otdn

WEBHOST1

WEBHOST2
 

MSAS_ORACLE_INSTANCE

/u02/private/oracle/config/instances/gatewayid

WEBHOST1

WEBHOST2
 

OTD_ORACLE_HOME

/u01/oracle/products/web/otd

WEBHOST1

WEBHOST2
 

OHS_ORACLE_HOME

/u01/oracle/products/web/ohs

WEBHOST1

WEBHOST2

Application Tier

LDAP_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oidn

IAMHOST1

IAMHOST2
 

IAD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMAccessDomain

IAMHOST1

IAMHOST2
 

IGD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMGovernanceDomain

IAMHOST1

IAMHOST2

Directory Tier

DIR_MW_HOMEFoot 1 

/u01/oracle/products

IAMHOST1

IAMHOST2
 

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

IAMHOST1

IAMHOST2
 

OID_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oidn

IAMHOST1

IAMHOST2

Footnote 1 Only required when directory is being placed into a Directory/Database Zone

Note:

OTD_ORACLE_HOME is only used when Oracle Traffic Director is deployed.

Figure 7-3 Recommended Private Storage Directory Structure

Surrounding text describes Figure 7-3 .

The figure shows the local storage directory hierarchy. The top level directory, /u02/private/oracle (LOCAL_ROOT), has a subdirectory, config.

Note:

The otdn directory is only for Exalogic deployments.

The directory config has a subdirectory for each product that has an instance, that is, Web Server and LDAP (in this case, Oracle HTTP Server and Oracle Unified Directory). The appropriate directory only appears on the relevant host, that is, the WEB_ORACLE_INSTANCE directory only appears on the WEBHOSTS

The domains directory contains one subdirectory for each domain in the topology, that is, IAMAccessDomain and IAMGovernanceDomain.

IAMAccessDomain (IAD_MSERVER_HOME) contains applications and servers. The servers directory contains wls_oamn, where n is the Access Manager instance. If OAAM is configured, this folder also contains wls_oaamn and wls_oaam_adminn

IAMGovernanceDomain (IGD_MSERVER_HOME), which contains applications and servers. The servers directory contains wls_oimn and wls_soan, where n is the Oracle Identity Manager and SOA instance, respectively.

Figure 7-4 Recommended Directory Structure for Private Binary Storage on Webhosts

Surrounding text describes Figure 7-4 .

Figure 7-4 shows the local binary storage directory hierarchy. The top level directory, /u01/oracle (IDM_TOP), has a subdirectory, products.

The products directory contains the web directory (WEB_MW_HOME), which has four subdirectories: web (WEB_ORACLE_HOME), webgate (WEBGATE_ORACLE_HOME), oracle_common (ORACLE_COMMON_HOME), and jdk (JAVA_HOME).

Note:

While it is recommended that you put WEB_ORACLE_INSTANCE directories onto local storage, you can use shared storage. If you use shared storage, you must ensure that the HTTP lock file is placed on discrete locations.