| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.2) Part Number E21032-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.2) Part Number E21032-03 |
|
|
PDF · Mobi · ePub |
This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topologies.
This chapter includes the following topics:
The minimum hardware requirements for the Enterprise Deployment on Linux operating systems are listed in Table 2-1. The memory figures represent the memory required to install and run an Oracle Fusion Middleware server; however, for most production sites, you should configure at least 4 GB of physical memory.
For detailed requirements, or for requirements for other platforms, see the Oracle Fusion Middleware Installation Guide for that platform.
Table 2-1 Typical Hardware Requirements
| Server | Processor | Disk | Memory | TMP Directory | Swap |
|---|---|---|---|---|---|
|
|
4 or more X Pentium 1.5 GHz or greater |
nXm n=Number of disks, at least 4 (striped as one disk). m=Size of the disk (minimum of 30 GB) |
6-16 GB |
Default |
Default |
|
|
2 or more X Pentium 1.5 GHz or greater |
10 GB |
4 GB |
Default |
Default |
|
|
2 or more X Pentium 1.5 GHz or greater |
10 GB |
6 GB |
Default |
Default |
|
|
2 or more X Pentium 1.5 GHz or greater |
10 GB |
4 GB |
Default |
Default |
These are the typical hardware requirements. For each tier, carefully consider the load, throughput, response time and other requirements to plan the actual capacity required. The number of nodes, CPUs, and memory required can vary for each tier based on the deployment profile.Production requirements may vary depending on applications and the number of users.
The Enterprise Deployment configurations described in this guide use two servers for each tier to provide failover capability; however, this does not presume adequate computing resources for any application or user population. If the system workload increases such that performance is degraded, you can add servers to the configuration by repeating the instructions for the second server (that is, WEBHOST2, IDMHOST2, OIDHOST2, OVDHOST2, OIDDBHOST2) to install and configure additional servers where needed.
Note:
Oracle recommends configuring all nodes in the topology identically with respect to operating system levels, patch levels, user accounts, and user groups.
This section describes the network prerequisites for the enterprise deployment topologies:
Load balancers
Configuring virtual server names and ports on the load balancer
WebLogic Administration Server Virtual IP Addresses
Managing Oracle Fusion Middleware component connections
Oracle Access Manager communication protocols and terminology
Firewall and port configuration
This section contains the following topics:
Section 2.2.2, "Configuring Virtual Server Names and Ports on the Load Balancer"
Section 2.2.4, "Managing Oracle Fusion Middleware Component Connections"
Section 2.2.5, "Oracle Access Manager Communication Protocol and Terminology"
The enterprise topologies use an external load balancer. This external load balancer must have the following features:
Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.
Port translation configuration.
Monitoring of ports (HTTP and HTTPS).
Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for OracleAS Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.
The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.
Ability to detect node failures and immediately stop routing traffic to the failed node.
Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.
Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.
Sticky routing capability: Ability to maintain sticky connections to components based on cookies or URL.
SSL acceleration (this feature is recommended, but not required).
Configure the virtual server(s) in the load balancer for the directory tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between the Oracle Access Manager and the directory tier.
Ability to Preserve the Client IP Addresses: The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.
Several virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.
There are two load balancer devices in the recommended topologies. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various DMZs. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.
When setting up your load balancer, you must define an HTTP profile that adds a request header to all HTTP requests. You must assign this HTTP profile to each of the virtual server names in this section which receive a request which is of the type HTTPS.
The HTTP profile inserts the following request header:
Header Name: IS_SSL Header Value: ssl
The rest of this document assumes that the deployment is one of those shown in Chapter 1.
This entry is only required if Identity information is stored in an Oracle Internet Directory.
This virtual server is enabled on LBR2. It acts as the access point for all identity-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the directory tier. Traffic to both SSL and non-SSL is configured. The clients access this service using the address oididstore.mycompany.com:636 for SSL and oididstore.mycompany.com:389 for non-SSL.
Monitor the heartbeat of the Oracle Internet Directory processes on OIDHOST1 and OIDHOST2. If an Oracle Internet Directory process stops on OIDHOST1 or OIDHOST2, or if either host OIDHOST1 or OIDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
This virtual server is enabled on LBR2. It acts as the access point for all policy-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the directory tier. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address policystore.mycompany.com:636 for SSL and policystore.mycompany.com:389 for non-SSL.
Note:
Oracle recommends that you configure the same port for SSL connections on the LDAP server and Oracle Internet Directory on the computers on which Oracle Internet Directory is installed.
This is a requirement for most Oracle 11g products that use Oracle Internet Directory through the load balancing router.
Monitor the heartbeat of the Oracle Internet Directory processes on OIDHOST1 and OIDHOST2. If an Oracle Internet Directory process stops on OIDHOST1 or OIDHOST2, or if either host OIDHOST1 or OIDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
This virtual server is enabled on LBR2. It acts as the access point for all Identity Store LDAP traffic. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address idstore.mycompany.com:636 for SSL and idstore.mycompany.com:389 for non-SSL.
If your Identity Store is accessed through Oracle Virtual Directory, monitor the heartbeat of the Oracle Virtual Directory processes on OVDHOST1 and OVDHOST2. If an Oracle Virtual Directory process stops on OVDHOST1 or OVDHOST2, or if either host OVDHOST1 or OVDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
If your Identity Store is in Oracle Internet Directory and is accessed directly, monitor the heartbeat of the Oracle Internet Directory processes on the Oracle Internet Directory Hosts. If an Oracle Internet Directory process stops on one OIDHOST or one OIDHOST is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
If you have an Oracle Internet Directory-only topology, idstore.mycompany.com points to the Oracle Identity Federation in which you are storing your identity data. If you are storing your identity data in a third-party directory or want to front your Oracle Internet Directory Identity Store with Oracle Virtual Directory, then idstore points to Oracle Virtual Directory.
This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address admin.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Directory Services Manager.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the admin.mycompany.com virtual host.
oiminternal.mycompany.com
This virtual server is enabled on LBR1. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address oiminternal.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services
Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the oiminternal.mycompany.com virtual host.
This is the virtual name which fronts all Identity Management components, including Oracle Identity Manager, Oracle Access Manager, and Oracle Identity Federation.
This virtual server is enabled on LBR1. It acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address sso.mycompany.com:443 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.
Configure this virtual server in the load balancer with both port 80 and port 443.
This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.
In addition, ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.
A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.
The following is a list of the Virtual IP addresses required by Oracle Identity Management:
adminvhn.mycompany.com
In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from IDMHOST1 to IDMSHOST2, or vice versa.
soavhnx
One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration.
Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.
oimvhnx
One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.
Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.
To ensure consistent availability of all services, ensure that the connection timeout values for all Oracle Fusion Middleware components are set to a lower timeout value than that on the firewall and load balancing router. If the firewall or load balancing router drops a connection without sending a TCP close notification message, then Oracle Fusion Middleware components continue to try to use the connection when it is no longer available.
This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.
Oracle Access Protocol (OAP) enables communication between Access System components (for example, Access Manager server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.
The request flow when a user requests access is as follows:
The user requests access to a protected resource over HTTP or HTTPS.
The WebGate intercepts the request.
The WebGate forwards the request to the Oracle Access Manager server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).
The Oracle Access Manager server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.
Following authentication, the WebGate prompts the Oracle Access Manager server over Oracle Access Protocol and the Oracle Access Manager server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.
If the access policy is valid, the user is allowed to access the desired content and/or applications.
If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.
Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.
Most port numbers are assigned during installation.
Table 2-2 lists the ports used in the Oracle Identity Management topologies, including the ports that you must open on the firewalls in the topologies.
Firewall notation:
FW0 refers to the outermost firewall.
FW1 refers to the firewall between the web tier and the application tier.
FW2 refers to the firewall between the application tier and the directory tier.
Table 2-2 Ports Used in the Oracle Identity Management Enterprise Deployment topologies
| Type | Firewall | Port and Port Range | Protocol / Application | Inbound / Outbound | Timeout |
|---|---|---|---|---|---|
|
Browser request |
FW0 |
80 |
HTTP / Load balancer |
Both |
Timeout depends on all HTML content and the type of process model used for Oracle Identity Management. |
|
Browser request |
FW0 |
443 |
HTTPS / Load balancer |
Both |
Timeout depends on all HTML content and the type of process model used for Oracle Identity Management. |
|
Oracle WebLogic Administration Server access from web tier |
FW1 |
7001 |
HTTP / Oracle HTTP Server and Administration Server |
Inbound |
N/A |
|
Enterprise Manager Agent - web tier to Enterprise Manager |
FW1 |
5160 |
HTTP / Enterprise Manager Agent and Enterprise Manager |
Both |
N/A |
|
Oracle HTTP Server to |
FW1 |
7006 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
Oracle HTTP Server to |
FW1 |
14100 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
Oracle HTTP Server |
FW1 |
14000 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the mod_weblogic parameters used |
|
Oracle HTTP Server |
FW1 |
8001 |
HTTP / Oracle HTTP Server to WebLogic Server |
Both |
Timeout depends on the mod_weblogic parameters used |
|
Oracle Process Manager and Notification Server (OPMN) access in web tier |
FW1 |
OPMN remote port |
HTTP / Administration Server to OPMN |
Outbound |
N/A |
|
Oracle HTTP Server proxy port |
FW1 |
9999 |
HTTP / Administration Server to Oracle HTTP Server |
Outbound |
N/A |
|
Oracle Access Manager Server 11g |
FW1 |
5574-5575 |
OAP |
Both |
N/A |
|
Oracle Coherence Port |
FW1 |
8000 - 8090 |
TCMP |
Both |
N/A |
|
Oracle WebLogic Administration Server access from directory tier |
FW2 |
7001 |
HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server |
Outbound |
N/A |
|
Enterprise Manager Agent - directory tier to Enterprise Manager |
FW2 |
5160 |
HTTP / Enterprise Manager Agent and Enterprise Manager |
Both |
N/A |
|
OPMN access in directory tier |
FW2 |
OPMN remote port |
HTTP / Administration Server to OPMN |
Inbound |
N/A |
|
Oracle Virtual Directory proxy port |
FW2 |
8899 |
HTTP / Administration Server to Oracle Virtual Directory |
Inbound |
N/A |
|
Database access |
FW2 |
1521 |
SQL*Net |
Both |
Timeout depends on all database content and on the type of process model used for Oracle Identity Management. |
|
Oracle Internet Directory access |
FW2 |
389 |
LDAP |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Internet Directory access |
FW2 |
636 |
LDAP SSL |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
6501 |
LDAP |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
7501 |
LDAP SSL |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Identity Federation access |
FW2 |
7499 |
HTTP |
Both |
N/A |
|
OIN |
FW2 |
7001 |
HTTP |
Both |
N/A |
|
Load balancer to Oracle HTTP Server |
N/A |
7777 |
HTTP |
N/A |
N/A |
|
Session replication within a WebLogic Server cluster |
N/A |
N/A |
N/A |
N/A |
By default, this communication uses the same port as the server's listen address. |
|
Node Manager |
N/A |
5556 |
TCP/IP |
N/A |
N/A |
Note:
Additional ports might need to be opened across the firewalls to enable applications in external domains, such as SOA or WebCenter domains, to authenticate against this Identity Management domain.
A domain is the basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. You can define multiple domains based on different system administrators' responsibilities, application boundaries, or geographical locations of servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.
In the context of Identity Management, it is recommended that you deploy the Identity Management components, plus SOA, in a separate WebLogic Server domain from the one where SOA, WebCenter and other customer applications might be deployed. In a typical enterprise deployment, the administration of identity management components such as LDAP directory, single sign-on solutions, and provisioning solutions is done by a different set of administrators from those who administer the middleware infrastructure and applications.
It is technically possible to deploy everything in a single domain in a development or test environment. However, in a production environment, the recommendation to use separate domains creates a logical administrative boundary between the identity management stack and the rest of the middleware and application deployment.
This section details the directories and directory structure that Oracle recommends for an EDG topology. 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.
This section contains the following topics:
Section 2.4.1, "Directory Structure Terminology and Environment Variables"
Section 2.4.2, "Recommended Locations for the Different Directories"
This section describes directory structure terminology and environment variables.
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 environment 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 environment variable and related directory path contains installed files necessary to host a WebLogic Server, for example MW_HOME/wlserver_10.3.
ORACLE_HOME: This environment 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 environment 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 2.4.2, "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 location of the artifacts related to the WebLogic Administration Server. These artifacts are kept separate from those belonging to managed servers to allow the Administration server to be independently managed and failed over. A typical example is: ORACLE_BASE/admin/IDMDomain/aserver
MSERVER_HOME: This is the location of artifacts related to managed servers. These are stored separately from the Administration server. A typical example is: ORACLE_BASE/admin/IDMDomain/mserver
Oracle Fusion Middleware 11g enables you to create multiple Identity Management servers 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. For maximum availability, however, Oracle recommends using redundant binary installations. In the Enterprise Deployment model, you install two MW_HOMEs (each of which has a WL_HOME and an ORACLE_HOME for each product suite in shared storage. When scaling out or scaling up, you can use either one of these two locations for additional servers of the same type without performing more installations. Ideally, users should use two different volumes for redundant binary location 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 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, 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 19.3.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. 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 domains apply to a single shared domain. 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.
Based on the above assumptions, the following 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.
Note:
In the following table, wherever shared storage is required for a directory, the shared storage column specification is qualified with the word Yes. When using local disk or shared storage is optional, the shared storage column specification is qualified with the word Optional. The shared storage locations are examples and can be changed as long as the provided mount points are used.
When you're installing a high availability topology across multiple homes, Oracle recommends using the same directory structure for all nodes.
Table 2-3 Recommended Directory Structure
| Environment Variable | Mount Point or Directory Structure | Shared Storage Location | Host Name | Shared Storage | |
|---|---|---|---|---|---|
|
Common |
|
|
|||
|
|
|
||||
|
|
|
||||
|
|
|
||||
|
Web Tier |
|
|
Optional |
||
|
|
|
Optional |
|||
|
Identity Management Application Tier |
|
|
|
|
Yes |
|
|
|
|
|
Yes |
|
|
|
|
Yes |
|||
|
|
|
||||
|
|
|
||||
|
|
|
Yes |
|||
|
|
|
Optional |
|||
|
|
|
|
|
Yes |
|
|
|
|
||||
|
|
|
||||
|
|
|
Optional |
|||
|
|
|
||||
|
|
|
||||
|
Directory Tier |
|
|
Optional |
||
|
|
|
Optional |
The following commands are examples. Use the appropriate commands for your Operating System.
To mount volume/vol/MW_HOME1 on the shared storage to the MW_HOME mountpoint on IDMHOST1 run the following command on IDMHOST1 as root:
mount storageHost:/Path_to_MW_HOME1_volume_on_SharedDisk \ MW_HOME_moutpoint_on_IDMHOST1 -t nfs \ -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
For Example:
mount storageHost:/vol/MW_HOME1 /u01/app/oracle/product/fmw -t nfs \ -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
To mount volume/vol/MW_HOME2 on the shared storage to the MW_HOME mountpoint on IDMHOST2 run the following command on IDMHOST2 as root:
mount storageHost:/Path_to_MW_HOME2_volume_on_SharedDisk \ MW_HOME_moutpoint_on_IDMHOST2 -t nfs \ -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
For Example:
mount storageHost:/vol/MW_HOME2 /u01/app/oracle/product/fmw -t nfs \ -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
To mount volume/vol/ADMIN on the shared storage to the AServer_Home mountpoint on IDMHOST1 run the following command on IDMHOST1 as root:
mount storageHost:/Path_to_ADMIN_volume_on_SharedDisk \ ASERVER_HOME_moutpoint_on_IDMHOST1 -t nfs \ -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
For Example:
mount storageHost:/vol/ADMIN /u01/app/oracle/admin/IDMDomain/aserver -t nfs \
-o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
Figure 2-1 shows the recommended directory structure.
Figure 2-1 Directory Structure for Identity Management
Table 2-4 explains what the color-coded elements in Figure 2-1 mean. The directory structure in Figure 2-1 does not show other required internal directories such as ORACLE_COMMON_HOME and jrockit.
Table 2-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 |
 |
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 |
 |
Fixed name. |
 |
Installation-dependent name. |
|
 Copyright © 2004, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|