3 Preparing the Network for an Enterprise Deployment

This chapter describes the network environment configuration required by the Oracle Fusion Applications reference enterprise deployment topology, as well as recommendations for shared storage and directory structure.

This chapter includes the following topics:

Section 3.1, "External Virtual Server Names"
Section 3.2, "Internal Virtual IPs"
Section 3.3, "Load Balancer Configuration"
Section 3.4, "Reference Enterprise Deployment Directory Structure"
Section 3.5, "Shared Storage"
Section 3.6, "IPs and Virtual IPs"
Section 3.7, "Firewalls and Ports"
Section 3.8, "Clock Synchronization"

3.1 External Virtual Server Names

The Oracle Fusion Applications enterprise deployment topology uses the following externally accessible load balancer virtual IPs that are created on the Load Balancer:

crmexternal.mycompany.com
finexternal.mycompany.com
hcmexternal.mycompany.com
scmexternal.mycompany.com
biexternal.mycompany.com
commonexternal.mycompany.com
icexternal.mycompany.com

These virtual server names act as the access point for all HTTP traffic to the runtime components for Oracle Fusion Customer Relationship Management. The HTTP traffic from client browser to LBR is always in SSL.

These VIPs receive all the requests externally (from the intranet or internet) on port 443 in SSL mode. These requests are forwarded to one of Oracle HTTP Server's "external virtual hosts specific to each domain" on WEBHOST1 or WEBHOST2.

Note:

All external VIPs listed above are also configured on port 80, and any request that is received on port 80 will be forwarded back to port 443. This is to prevent a browser error when the user types the URL without the http:// and the browser uses the default 80 port. If the user types https://, the browser uses the default 443 port.

3.2 Internal Virtual IPs

The following Oracle Fusion Customer Relationship Management deployment topology also requires separate secure network address translations (NATs) internal VIPS for each domain. These VIPs are used for transactional and administrative access.

crminternal.mycompany.com
fininternal.mycompany.com
hcminternal.mycompany.com
scminternal.mycompany.com
biinternal.mycompany.com
commoninternal.mycompany.com
icinternal.mycompany.com

The above virtual URLs (VIPs) are defined on the load balancer and are used for internal invocations of services within the data center. The URLs are not exposed to the internet or intranet, and are only accessible within the data center.

The VIPs receive all the requests internally on port 7777 in non-SSL mode. All the internal services/clients access these VIPs using the above virtual addresses, and the requests are then forwarded to one of Oracle HTTP Server's "internal virtual hosts specific to each domain" on WEBHOST1 or WEBHOST2.

For additional Oracle WebLogic Server security, you can configure the internal VIPs listed above with a load-balancing router rule that accepts requests only from well-known hosts like CRMHOST1, CRMHOST2, or from the system administrator host, and rejects all other requests.

Note that an additional VIP, COMMONUCMVH1.mycompany.com, is used to load balance the traffic to the UCM_server instances.

3.3 Load Balancer Configuration

The Oracle Fusion Applications enterprise topology requires an external load balancer with SSL acceleration. To configure the load balancer with above VIPs listed above, refer to vendor-specific load balancer configuration instructions.

Note:

The Oracle Technology Network (http://otn.oracle.com) provides a list of validated load balancers and their configurations.

3.4 Reference Enterprise Deployment Directory Structure

This section describes the directory structure specifically used by the Oracle Fusion Applications reference enterprise deployment topology. It includes the following topics:

Section 3.4.1, "Directory Structure"
Section 3.4.2, "Binary Directory Structure"
Section 3.4.3, "Domain Configuration Directory Structure"

For general information about Oracle Fusion Applications architecture and concepts, see "Introduction to Oracle Fusion Applications for System Administrators" in Oracle Fusion Applications Administrator's Guide.

3.4.1 Directory Structure

Figure 3-1 shows the enterprise deployment directory structure and its dependencies.

Figure 3-1 Enterprise Deployment Directory Structure for Oracle Fusion Applications

ED Directory Structure for Oracle Fusion Applications

3.4.2 Binary Directory Structure

The binaries in the Oracle Fusion Applications reference enterprise deployment topology (the Oracle Fusion Middleware home and Oracle home) are on a shared disk. In order to avoid disk corruption, you may choose to maintain snapshots.

The file system for the binaries should be mounted on all the nodes with the exact mount point and path. For example, /u01/oracle.

3.4.3 Domain Configuration Directory Structure

The domain configuration directory structure is created on a shared disk, and its mount point should be visible from all nodes This path will be used by the components that require shared resources and also administration servers to start active-passive processes. For example, /u01/oracle.

3.5 Shared Storage

For binaries: the file system is optimized for read operations.

For config: the file system should be optimized for read/write operations. For example, AdminServer Domain directory and Oracle Business Intelligence shared folders like Oracle Business Intelligence WebCat, RPD cache, Essbase ARBORPATH, and Oracle Business Intelligence config.

Note:

The minimum amount of shared storage is 500 GB.

The following steps show how to create and mount shared storage locations for binaries and config so that CRMHOST1 and CRMHOST2 can see the same location.

"nasfiler" is the shared storage filer.

From CRMHOST1:

CRMHOST1> mount nasfiler:/vol/vol1/u01/oracle /u01/oracle -t nfs

From CRMHOST2:

CRMHOST2> mount nasfiler:/vol/vol1/u01/oracle /u01/oracle -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 CRMHOST1. The options may differ.

mount nasfiler:/vol/vol1/u01/oracle
/u01/oracle -t nfs -o 
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,
wsize=32768

Contact your storage vendor and computer administrator for the correct options for your environment.

3.5.1 Shared Storage for Oracle Business Intelligence

For general information, see "Shared Storage and Recommended Directory Structure" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.

Shared Storage Locations

In addition, Oracle Business Intelligence has two specific shared-storage locations.

Location for Data Warehouse Console Configuration folder:

ORACLE_BASE/config/BIShared/dac
- Mounted from: All nodes containing the instance of DAC in the cluster or where DAC can be migrated to must mount this location (all nodes must have read/write access)
Location for shared Essbase ARBORPATH:

ORACLE_BASE/config/BIShared/Essbase
- Mounted from: All nodes containing the instance of Essbase in the cluster must mount this location (all nodes must have read/write access)

Note:

ORACLE_BASE is /u01/oracle.

3.6 IPs and Virtual IPs

Configure the Administration Server and the Managed Servers to listen on different virtual IPs and physical IPs.

The following VIPs are required to configure specific components:

Virtual IPs for AdminServer are needed for every domain to configure AdminServer in active-passive mode. These VIPs are shared across CRMHOST1 and CRMHOST2, depending on where the Administration Server is running.
Virtual IPs for all Oracle SOA Suite servers in every domain, and Oracle Business Intelligence servers in the Oracle Business Intelligence domain are needed to support server migration. These components are implemented in active-active mode, so these VIPs are needed for CRMHOST1 and CRMHOST2.
When requesting VIPs, ensure that they are in the same subnet as CRMHOST1 and CRMHOST2 with netmask.

Table 3-1 provides descriptions of the various virtual hosts.

Table 3-1 Virtual Hosts

Virtual IP	VIP Maps to...	Description
VIP1	`CRMADMINVH`	The virtual host name that is the listen address for the CRM Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the CRM Administration Server process is running (`CRMHOST1` by default).
VIP2	`CRMSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server1` process is running (`CRMHOST1` by default).
VIP3	`CRMSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server2` process is running (`CRMHOST2` by default).
VIP4	`COMMONADMINVH`	The virtual host name that is the listen address for the CommonDomain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the CommonDomain Administration Server process is running (`CRMHOST1` by default).
VIP5	`COMMONSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server1` process is running (`CRMHOST1` by default).
VIP6	`COMMONSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server2` process is running (`CRMHOST2` by default).
VIP7	`FINADMINVH`	The virtual host name that is the listen address for the FinancialDomain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the FinancialDomain Administration Server process is running (`CRMHOST1` by default).
VIP8	`FINSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server1` process is running (`CRMHOST1` by default).
VIP9	`FINSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server2` process is running (`CRMHOST2` by default).
VIP10	`HCMADMINVH`	The virtual host name that is the listen address for the HCMDomain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the HCMDomain Administration Server process is running (`CRMHOST1` by default).
VIP11	`HCMSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server1` process is running (`CRMHOST1` by default).
VIP12	`HCMSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server2` process is running (`CRMHOST2` by default).
VIP13	`SCMADMINVH`	The virtual host name that is the listen address for the SCMDomain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the SCMDomain Administration Server process is running (`CRMHOST1` by default).
VIP14	`SCMSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server1` process is running (`CRMHOST1` by default).
VIP15	`SCMSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server2` process is running (`CRMHOST2` by default).
VIP16	`BIADMINVH`	The virtual host name that is the listen address for the BIDomain Administration Server. It is enabled on the node where the BIDomain Administration Server process is running (`CRMHOST1` by default).
VIP17	`BIVH1`	The virtual host name that maps to the listen address for `bi_server1` and fails over with server migration of this Managed Server. It is enabled on the node where `bi_server1` process is running (`CRMHOST1` by default).
VIP18	`BIVH2`	The virtual host name that maps to the listen address for `bi_server2` and fails over with server migration of this Managed Server. It is enabled on the node where `bi_server2` process is running (`CRMHOST2` by default).
VIP19	`ICSOAVH1`	The virtual host name that maps to the listen address for `soa_server1` and fails over with server migration of this Managed Server. It is enabled on the node where soa_server1 process is running (`CRMHOST1` by default).
VIP20	`ICSOAVH2`	The virtual host name that maps to the listen address for `soa_server2` and fails over with server migration of this Managed Server. It is enabled on the node where soa_server2 process is running (`CRMHOST2` by default).
VIP21	`ICADMINVH`	The virtual host name that is the listen address for the ICDomain Administration Server. It is enabled on the node where the ICDomain Administration Server process is running (`CRMHOST1` by default).
VIP22	`CRMSOAVH3`	The virtual host name that maps to the listen address for `soa_server3` and fails over with server migration of this Managed Server. It is enabled on the node where `soa_server3` process is running (`CRMHOST3` by default).
VIP23	`FUSIONDBHOST1`	The virtual host name that is the listen address for the database Oracle RAC database server. It is enabled on the node where the database is running.

3.7 Firewalls and Ports

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 3-2 lists the ports used in the Oracle Fusion Customer Relationship Management topology, including the ports that you must open on the firewalls in the topology.

Firewall notation:

FW1 refers to the outermost firewall
FW2 refers to the firewall between the Oracle Web Tier and the application tier
FW3 refers to the firewall between the application tier and the data tier
dst refers to destination

Table 3-2 Ports Used

Type	Firewall	Port and Port Range	Protocol / Application	Inbound / Outbound	Other Considerations and Timeout Guidelines
Browser request	FW1	80 (dst)	HTTP	Inbound	Timeout depends on all HTML content and the type of process model used for Oracle Fusion Applications.
Browser request	FW1	443	HTTPS / Load Balancer	Inbound	Timeout depends on all HTML content and the type of process model used for Oracle Fusion Applications.
Browser request	FW1	443 (dst)	HTTPS	Outbound	Open connection to `http://xmlns.oracle.com/adf/config` only
OAP	N/A	8181	HTTP	N/A
Oracle HTTP Server registration with Administration Server	FW2	7001 (both)	HTTP/t3	Inbound	Set the timeout to a short period (5-10 seconds).
Oracle HTTP Server registration with Administration Server	FW2	OPMN port 7043 (dst) and Oracle HTTP Server Admin Port 7044 (dst)	TCP and HTTP, respectively	Outbound	Set the timeout to a short period (5-10 seconds).
All Domain Servers	FW2	7777 (dst)	HTTP	Outbound	Managed Servers are sending packets to LBR internal VIPS with port 7777
All Domains: Server Migration and Multicast VIPs	FW2		Multicast	Outbound
Common Domain	FW2	7001-7035 (dst)	HTTP	Inbound
Financial Domain	FW2	7401-7430 (dst)	HTTP	Inbound
Supply Chain Domain	FW2	7801-7830 (dst)	HTTP	Inbound
Customer Relationship Management Domain	FW2	9001-9040 (dst)	HTTP	Inbound
Human Capital Management Domain	FW2	9401-9430 (dst)	HTTP	Inbound
Business Intelligence Domain	FW2	10201-10230 (dst)	HTTP	Inbound
Incentive Compensation Domain	FW2	9801-9830 (dst)	HTTP	Inbound
Common Administration Console access	FW2	7001 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
Financial Administration Console access	FW2	7401 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
SCM Administration Console access	FW2	7801 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
CRMAdministration Console access	FW2	9001 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
HCM Administration Console access	FW2	9401 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
IC Administration Console access	FW2	9801 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
BI Administration Console access	FW2	10201 (both)	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
Node Manager	N/A	5556	TCP/IP	N/A	N/A
Access Server access	FW2	5574-5575	OAP	Both	For actual values, see "Firewalls and Ports" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.
Identity Server access	FW2	6022	OAP	Inbound
Database access for Oracle BI Server and Oracle BI Publisher JDBC Data Sources	FW2	Listening port for client connections to the listener (both)	SQL*Net	Both	Timeout depends on all database content and on the type of process model used for Oracle BI
Database access	FW3	1521 (both)	SQL*Net	Both	Timeout depends on all database content and on the type of process model used for Oracle Fusion Applications.
Coherence for deployment	N/A	8088 and 8089 (both)		N/A	N/A
Oracle Internet Directory access	FW3	389 (dst)	LDAP	Inbound	You should tune the directory server's parameters based on load balancer, and not the other way around.
Oracle Internet Directory access	FW3	636 (dst)	LDAP SSL	Inbound	You should tune the directory server's parameters based on load balancer, and not the other way around.
JOC for OWSM	N/A	9991	TCP/IP	N/A	N/A

Note:

The firewall ports depend on the definition of TCP/IP ports.

3.8 Clock Synchronization

The clocks of all servers participating in the cluster must be synchronized to within one second difference. To accomplish this, use a single network time server and then point each server to that network time server.

The procedure for pointing to the network time server is different on different operating systems. Refer to your operating system documentation for more information.