1 Overview

This chapter introduces the Oracle Application Server Enterprise Deployment configurations. It contains the following topics:

Section 1.1, "What is an Enterprise Deployment?"

Section 1.2, "A Standard Enterprise Deployment for J2EE Applications: myJ2EECompany.com"

Section 1.3, "A Standard Enterprise Deployment for Portal Applications: myPortalCompany.com"

Section 1.4, "Benefits of the Standard Enterprise Topology"

Section 1.5, "Variants to the Standard Enterprise Deployment Configurations"

Section 1.6, "Enterprise Deployment Nomenclature"

Section 1.7, "How to Use This Guide: The Enterprise Deployment Configuration Process"

Section 1.8, "Best Practices for Installing and Configuring Enterprise Deployments"

1.1 What is an Enterprise Deployment?

An enterprise deployment is an Oracle Application Server configuration that supports large-scale, mission-critical business software applications. The hardware and software in an enterprise deployment delivers:

High quality service

The system workload is managed and balanced effectively
Applications continue to operate when resources are added or removed
System maintenance and unexpected failures cause zero downtime

Built-in Security

All incoming network traffic is received by the load balancing router on a single, secure port and directed to internal IP addresses within the firewall; inside the firewall, functional components are grouped within DMZs
User accounts are provisioned and managed centrally
Delegation of administration is performed consistently
Security systems are integrated

Efficient software provisioning and management

Application distribution is simple
Systems are managed and monitored as one logical unit in a central console
Death detection and restart mechanisms ensure availability

1.2 A Standard Enterprise Deployment for J2EE Applications: myJ2EECompany.com

Figure 1-1 shows the enterprise deployment architecture for any J2EE application that uses JAZN LDAP for user authentication. If you need to use the Single Sign-On Server for authentication for J2EE applications, you should use the Standard Enterprise Deployment for Portal Applications: myPortalCompany.com described in Section 1.3.

For certain types of J2EE applications, such as JMS-based or EJB-based applications, there may be additional variants to these architectures. Refer to the Oracle Application Server Containers for J2EE Services Guide and Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide for more information on these variants.

The servers in the myJ2EECompany system are grouped into tiers as follows:

Web Tier — WEBHOST1 and WEBHOST2, with OracleAS Web Cache and Oracle HTTP Server installed.
Application Tier — APPHOST1 and APPHOST2, with Oracle Application Server Containers for J2EE installed, and multiple OC4J instances with applications deployed.
Data Tier — OIDHOST1 and OIDHOST2, with Oracle Internet Directory installed, and INFRADBHOST1 and INFRADBHOST2, the two-node Real Application Clusters database.

Table 1-1, Table 1-2 and Table 1-3 identify the basic, minimum hardware requirements for the servers in the myJ2EECompany system on Windows, Linux and Solaris operating systems, respectively. The memory figures represent the memory required to install and run Oracle Application Server; however, for most production sites, you should configure at least 1 GB of physical memory.

For detailed requirements, or for requirements for a platform other than these, see the Oracle Application Server Installation Guide for the platform you are using.

Table 1-1 myJ2EECompany Hardware Requirements (Windows)

Server	Processor	Disk	Memory	TMP Directory	Swap
WEBHOST and APPHOST	300 MHz or higher Intel Pentium processor recommended	400 MB	512 MB	55 MB to run the installer; 256 MB needed for some installation types	512 MB
OIDHOST and INFRADBHOST	300 MHz or higher Intel Pentium processor recommended	2.5 GB	1 GB	55 MB to run the installer; 256 MB needed for some installation types	1 GB

Table 1-2 myJ2EECompany Hardware Requirements (Linux)

Server	Processor	Disk	Memory	TMP Directory	Swap
WEBHOST and APPHOST	Pentium (32-bit), 450 MHz or greater	520 MB	512 MB	400 MB	1.5 GB
OIDHOST and INFRADBHOST	Pentium (32-bit), 450 MHz or greater	2.5 GB	1 GB	400 MB	1.5 GB

Table 1-3 myJ2EECompany Hardware Requirements (Solaris)

Server	Processor	Disk	Memory	TMP Directory	Swap
WEBHOST and APPHOST	450 MHz or greater; Oracle recommends a multiple CPU computer	750 MB	512 MB	250 MB	1.5 GB
OIDHOST	450 MHz or greater; Oracle recommends a multiple CPU computer	1.54 GB	1 GB	250 MB	1.5 GB
INFRADBHOST	450 MHz or greater; Oracle recommends a multiple CPU computer	3.93 GB	1 GB	250 MB	1.5 GB

Figure 1-1 Enterprise Deployment Architecture for myJ2EECompany.com

1.3 A Standard Enterprise Deployment for Portal Applications: myPortalCompany.com

Figure 1-2 shows the enterprise deployment architecture for OracleAS Portal applications.

The servers in the myPortalCompany system are grouped into tiers as follows:

Application Tier — APPHOST1 and APPHOST2
Identity Management Tier — IDMHOST1 and IDMHOST2
Data Tier — OIDHOST1 and OIDHOST2, with Oracle Internet Directory installed, and INFRADBHOST1 and INFRADBHOST2, the two-node Real Application Clusters database.

Table 1-4, Table 1-5 and Table 1-6 identify the basic, minimum hardware requirements for the servers in the myPortalCompany system on Windows, Linux and Solaris operating systems, respectively. The memory figures represent the memory required to install and run Oracle Application Server; however, for most production sites, you should configure at least 1 GB of physical memory. Table 1-7 describes the servers used in the Oracle test environment for myPortalCompany.

For detailed requirements, or for requirements for a platform other than these, see the Oracle Application Server Installation Guide for the platform you are using.

Table 1-4 myPortalCompany Hardware Requirements (Windows)

Server	Processor	Disk	Memory	TMP Directory	Swap
APPHOST, IDMHOST, OIDHOST, and INFRADBHOST	300 MHz or higher Intel Pentium processor recommended	2.5 GB	1 GB	55 MB to run the installer; 256 MB needed for some installation types	1 GB

Table 1-5 myPortalCompany Hardware Requirements (Linux)

Server	Processor	Disk	Memory	TMP Directory	Swap
APPHOST, IDMHOST, OIDHOST and INFRADBHOST	Pentium (32-bit), 450 MHz or greater	2.5 GB	1 GB	400 MB	1.5 GB

Table 1-6 myJ2EECompany Hardware Requirements (Solaris)

Server	Processor	Disk	Memory	TMP Directory	Swap
APPHOST, IDMHOST, OIDHOST and INFRADBHOST	450 MHz or greater; Oracle recommends a multiple CPU computer	750 MB	512 MB	250 MB	1.5 GB

Figure 1-2 Enterprise Deployment Architecture for myPortalCompany.com

Description of the illustration asted001.gif

Table 1-7 myPortalCompany Servers in Oracle Test Environment

Server	Platform	Virtual Memory	TMP	RAM	CPU
INFRADBHOST1 and INFRADBHOST2	Windows 2000	2 GB	Not applicable	2 GB	3 GHz
OIDHOST1	Windows 2000	3 GB	Not applicable	2 GB	3 GHz
OIDHOST2	Windows 2000	2GB	Not applicable	2 GB	3 GHz
IDMHOST1 and IDMHOST2	Windows 2000	2 GB	Not applicable	3.75 GB	3 GHz
APPDBHOST1 and APPHOST2	Red Hat Linux 2.1	2 GB	2.5 GB	6 GB	4 CPU, 3 GHz
APPHOST1 and APPHOST2	Windows 2000	1.6 GB	Not applicable	3.75 GB	3 GHz

1.4 Benefits of the Standard Enterprise Topology

The Oracle Application Server configurations shown in myJ2EECompany.com and myPortalCompany.com are designed to ensure security of all transactions, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing. This section explains how the security and high availability benefits of the two configurations are achieved.

1.4.1 Built-in Security

The Enterprise Deployment architectures are secure because every functional group of software components is isolated in its own DMZ, and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of compliance with standards:

All external communication received on port 80 is redirected to port 443.
Communication from external clients does not go beyond the Load Balancing Router level.
No direct communication from the Load Balancing Router to the Data tier DMZ is allowed.
Components are separated between DMZs on the Web Tier, Application Tier, and the Data Tier.
Communication between two firewalls at any one time is prohibited.
If a communication begins in one firewall zone, it must end in the next firewall zone.
Oracle Internet Directory is isolated in the Data tier DMZ.
Identity Management components such as Oracle HTTP Server, OracleAS Single Sign-On, and Oracle Delegated Administration Services are in the DMZ.
All communication between components across DMZs is restricted by port and protocol, according to firewall rules.

1.4.2 High Availability

The Enterprise Deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.

In the Web Server and Application Tiers, communication between components proceeds as follows:

The external Load Balancing Router does the following:

Receives end user requests on port 443, at the URL portal.mycompany.com, and balances the requests to one of the OracleAS Web Cache listeners on port 7777.
Receives invalidation messages from the Application Metadata Repository on port 4001, and balances the requests to one of the OracleAS Web Cache listeners on port 4001. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 4001, but this port is not visible to external traffic.

Receives web provider design time messages (and the init_session call, for session based providers) on port 7777 from the Application Metadata Repository, and balances the requests to one of the OracleAS Web Cache listeners on port 7777. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 7777, but this port is not visible to external traffic.

Note:

Although OracleAS Web Cache is clustered, invalidation and web provider messages cannot be sent directly to a OracleAS Web Cache server, because if that particular OracleAS Web Cache is not functioning, then there is no way for the Metadata Repository to communicate with the other OracleAS Web Cache instance. The Load Balancing Router's management of the invalidation and web provider messages provides component level high availability.

The Load Balancing Router balances the requests to one of the two OracleAS Web Cache servers on port 7777.
Each OracleAS Web Cache server receives the requests from and passes them to one of the two OracleAS Portal Oracle HTTP Servers on port 7778.

Note:
Since all of the OracleAS Portal sessions are stateless, these requests can be routed from any OracleAS Web Cache server to any OracleAS Portal Oracle HTTP Server, and vice versa.

The OracleAS Portal Parallel Page Engine also loops back to the Load Balancing Router (through the internal Network Address Translation port) to reach mod_plsql to get the metadata information to construct the page. The Load Balancing Router is configured to handle Parallel Page Engine loop back calls, and load balances them to one of the Webcache listeners on port 7777.

Note:

The Parallel Page Engine constructs OracleAS Portal pages based on metadata in the Metadata Repository. To read the metadata, it loops back to mod_plsql through the local OracleAS Web Cache instance. However, if that OracleAS Web Cache instance is down, there is no way for the Parallel Page Engine to reach mod_plsql or the other OracleAS Web Cache instance. If Parallel Page Engine loops back to the Load Balancing Router, the Load Balancing Router can balance requests to mod_plsql through the surviving OracleAS Web Cache instance, which can still balance the requests to the Oracle HTTP Server on the first middle tier. This exemplifies component level high availability and intelligent routing for efficient resource utilization.

When the request goes to portal.mycompany.com, OracleAS Portal determines whether the request is authenticated with OracleAS Single Sign-On; if not, it will redirect the request to the OracleAS Single Sign-On URL, login.mycompany.com.

In the Identity Management Tier, communication proceeds as follows:

OracleAS Single Sign-On receives a user request at login.mycompany.com.

OracleAS Single Sign-On authenticates the credentials with one of two Oracle Internet Directory instances, through the internal Load Balancing Router that is configured to manage Oracle Internet Directory traffic.

Note:

Two Oracle Internet Directory instances on different computers are using the same Metadata Repository. If the Identity Management components (OracleAS Single Sign-On, Oracle Delegated Administration Services) directly communicate with an Oracle Internet Directory instance, and that instance stops working, then there would be no way for the Identity Management components to redirect the traffic to the surviving Oracle Internet Directory instance. Thus the Load Balancing Router ensures high availability in re-routing traffic from a failed Oracle Internet Directory instance to a surviving instance.

1.5 Variants to the Standard Enterprise Deployment Configurations

Figure 1-1, "Enterprise Deployment Architecture for myJ2EECompany.com" and Figure 1-2, "Enterprise Deployment Architecture for myPortalCompany.com" show standard enterprise deployment architectures. Some characteristics of the standard enterprise deployment configuration are:

A two-node Real Application Clusters (RAC) database on the Data Tier is used to provide high availability (multiple database instances access a shared database of data files).
Oracle Internet Directory is installed on the Data Tier.
OracleAS Single Sign-On (on the Identity Management tier Figure 1-2), or the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider (on the Application Tier in Figure 1-1), is used for authentication and authorization.

Several variants exist for these and other elements of the enterprise deployment architectures. They are described in this section, categorized by the tier on which they are implemented (Data, Identity Management, Application, or Web). The variants enable you to achieve your deployment goals using fewer servers, different software, or alternative configurations.

1.5.1 Understanding Data Tier Variants

This section describes the variants for the Data Tier. The Data Tier is depicted in Figure 1-2, "Enterprise Deployment Architecture for myPortalCompany.com", and comprises the INFRADBHOST1 and INFRADBHOST2 computers.

1.5.1.1 Using Multimaster Replication with Oracle Internet Directory

Multimaster replication is an Oracle Internet Directory software solution that ensures read and write access to Oracle Internet Directory at all times, if at least one of the computers in the system remains available. When a computer resumes functioning after unavailability, replication from the surviving computer resumes automatically and synchronizes the contents between the computers. In addition, changes made on one directory server instance are reflected on the second directory server instance.

Multimaster replication of Oracle Internet Directory differs from the standard configuration in that the Oracle Internet Directory server and the database are on the same computer, whereas in the standard configuration the first Oracle Internet Directory instance and a database instance occupy IDMHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy IDMHOST2 and INFRADBHOST2. Thus, the replicated Oracle Internet Directory operates two fewer servers than the RAC configuration.

To implement multimaster replication in Oracle Internet Directory, follow the instructions in the Oracle Internet Directory Administrator's Guide, Oracle Internet Directory Replication Administration chapter, section titled "Installing and Configuring Multimaster Replication".

1.5.1.2 Using the Oracle Application Server Cold Failover Cluster (Identity Management) Solution

The OracleAS Cold Failover Cluster (Identity Management) solution is a hardware cluster comprising two computers. The computer that is actively executing an Infrastructure installation at any given time is called the primary (hot) node. If this node fails, the hardware cluster automatically diverts Infrastructure operations to the secondary (cold) node.

Each hardware cluster node is a standalone server that runs its own set of processes, but accesses a shared storage subsystem. The cluster can access the same storage, usually disks, from both nodes, but only the primary node has active access to the storage at any given time. If the primary node fails, the hardware cluster's software grants the secondary node access to the storage.

Note:

For a detailed discussion of the OracleAS Cold Failover Cluster (Identity Management) solution, see the Oracle Application Server High Availability Guide

The OracleAS Cold Failover Cluster (Identity Management) solution differs from the standard configuration in the following ways:

The Oracle Internet Directory server and the database are on the same computer, whereas in the standard configuration the first Oracle Internet Directory instance and a database instance occupy IDMHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy IDMHOST2 and INFRADBHOST2. Thus, the OracleAS Cold Failover Cluster (Identity Management) solution operates two fewer servers than the RAC configuration.
In the event of node failure, clients will experience a brief interruption of service while the workload is diverted to the cold node.

1.5.1.2.1 Using the OracleAS Cold Failover Cluster (Identity Management) Solution

To implement the OracleAS Cold Failover Cluster (Identity Management) solution:

Obtain and configure a hardware cluster.
Install and configure the Oracle Application Server instances on the cluster computers to use the OracleAS Cold Failover Cluster (Identity Management) solution. Follow the instructions in the Oracle Application Server Installation Guide, section 11.5, "Installing an OracleAS Cold Failover Cluster (Identity Management) Configuration".
Manage the OracleAS Cold Failover Cluster (Identity Management) solution, following the instructions from the Oracle Application Server High Availability Guide, section 6.3, "Managing Oracle Application Server Cold Failover Cluster (Identity Management)".

1.5.2 Understanding Identity Management Tier Variants

This section describes the variants for the Identity Management Tier. The Identity Management Tier is depicted in Figure 1-2, "Enterprise Deployment Architecture for myPortalCompany.com", and comprises the IDMHOST1 and IDMHOST2 computers.

1.5.2.1 Oracle Internet Directory: Data Tier or Identity Management Tier?

Oracle Internet Directory can be installed on the Identity Management Tier, along with OracleAS Single Sign-On and Oracle Delegated Administration Services. This is typical of configurations that provide a complete, local identity management system (Oracle Internet Directory and Oracle Application Server Single Sign-On) on one computer to applications located near that computer. See the Oracle Identity Management Concepts and Deployment Planning Guide, Chapter 3, "Oracle Identity Management Deployment Planning", section titled "Planning the Physical Network Topologies".

In the standard configuration, in which Oracle Internet Directory is installed on the Data Tier, Oracle Internet Directory and its metadata repository are behind a firewall, and is isolated from Internet traffic.

1.5.2.2 Oracle Internet Directory: AD/iPlanet Integration

Oracle Identity Management provides a set of components for integrating with other identity management environments, including various services and APIs, preconfigured directory connectivity solutions and standards support. For example, Oracle Identity Management allows for integration with various 3rd party directories, including Microsoft Active Directory and SunONE Directory Server.

By default, Oracle Directory Integration and Provisioning is installed as a component of Oracle Internet Directory. However, you can also install Oracle Directory Integration and Provisioning in a standalone installation. You should install a standalone instance of Oracle Directory Integration and Provisioning under the following circumstances:

When you need Oracle Internet Directory to run on a separate host for performance reasons
When the applications that you need to provision and synchronize required intensive processing
You need to run multiple instances of Oracle Directory Integration and Provisioning for high availability

See the Oracle Identity Management Integration Guide for detailed information on configuration options.

1.5.2.3 Oracle Application Server Single Sign-On: Using Netegrity

Several third-party access management vendors provide authentication adapters for the OracleAS Single Sign-On server. These products enable you to integrate a third-party system with the Oracle system without having to write your own code.The link that follows provides information about these vendors' products. All of the vendors listed certify that their products work with OracleAS Single Sign-On. See the section Single Sign-On under the heading Documentation, which appears near the bottom of the page.

http://www.oracle.com/technology/products/id_mgmt/partners/index.html

For example, Netegrity provides Siteminder Agent for Oracle Application Server. The agent delivers a mechanism to enable integration between heterogeneous, enterprise wide SiteMinder implementation with the OracleAS Single Sign-On environment. The agent provides enhanced security to protect Oracle Web-based resources, including session synchronization and revalidation of the user's SiteMinder session behind the DMZ in a trusted zone or corporate internal network prior to initiating the Oracle session. For the current information on version, platform support and configuration guide, visit:

http://www.netegrity.com

1.5.2.4 Oracle Application Server Single Sign-On: Windows Authentication

Windows native authentication is an authentication scheme for those who use Internet Explorer on Windows platforms. When this feature is enabled in OracleAS Single Sign-On, users log in to single sign-on partner applications automatically using Kerberos credentials obtained when the user logs in to a Windows computer. Using the Simple Protected GSS-API Negotiation Protocol (SPNEGO), browsers that are Internet Explorer 5.0 and greater can automatically pass the user's Kerberos credentials to a Kerberos-enabled Web server when the server requests these credentials. The Web server can then decrypt the credentials and authenticate the user.Before setting up Windows native authentication, you must first set up Active Directory (AD) Synchronization to Oracle Internet Directory. See the Oracle Internet Directory Administrator's Guide for instructions on how to do this.

1.5.3 Understanding Application Tier Variants

This section describes the variants for the Application Tier. The Application Tier is depicted in Figure 1-2, "Enterprise Deployment Architecture for myPortalCompany.com", and comprises the APPHOST1 and APPHOST2 computers.

1.5.3.1 J2EE Applications: File Based or Database Repository?

An Oracle Application Server Farm is a collection of instances that share the same configuration management metadata repository. A farm can be either a Oracle Application Server File-based Farm or Oracle Application Server Database-based Farm. Within these farm types, there are three types of metadata repository configuration: File-based (with standalone instance), File-based (with repository host instance) and Database:

File-based repository (standalone instance) — Every instance includes a local file- based repository. In a standalone instance, this repository stores the configuration metadata for the instance. When an instance is part of an OracleAS Database-based Farm or an OracleAS File-based Farm, and the instance is not the repository host, the local file-based repository contains the Bill of Materials (BOM) that Distributed Configuration Management uses to validate that the instance is synchronized with the configuration metadata in the repository.
File-based repository (with repository host instance) — When an instance is defined as the repository host for an OracleAS File-based Farm, the repository for the instance contains the configuration metadata for all instances in the farm.
Database repository - comprised of DCM schema. Storing the metadata repository in a database may be useful as part of a site's high availability and backup strategy. Using a database repository, the database serves as the repository host.

In all three metadata repository scenarios (database repository, file-based repository with a standalone instance, or file-based repository host instance), an instance always has a local file based repository. If the instance is not included in a farm, this is the sole storage for the configuration metadata for the instance.The choice of database repository or file-based repository has a low impact on a system's availability. In case of repository failure or downtime, the J2EE cluster continues to operate. Only the distributed management features are unavailable during the repository downtime. Table 1-8 compares repository types in light of operational considerations.

Table 1-8 OracleAS File-based Farm and OracleAS Database-based Farm Comparison

Consideration	Advantage
Number of computers in a farm	No known limitation for an OracleAS File-based Farm or an OracleAS Database-based Farm
Deployment frequency	Deployment is faster in an OracleAS File-based Farm
Recovery for manageability	Recovery from a system failure is faster with OracleAS File-based Farm
Reliability	High Availability features provided by the database (RAC, for example) are far superior to the OracleAS File-based Farm
Rolling upgrade needs	There is less downtime for management involved in an OracleAS File-based Farm rolling upgrade than in an OracleAS Database-based Farm rolling upgrade

1.5.4 Understanding Web Server Tier Variants

This section describes the variants for the Web Server Tier. The Web Server Tier is depicted in Figure 1-2, "Enterprise Deployment Architecture for myPortalCompany.com", and comprises the APPHOST1 and APPHOST2 computers.

In Figure 1-1, "Enterprise Deployment Architecture for myJ2EECompany.com", the Web Server Tier comprises the WEBHOST1 and WEBHOST2 computers.

1.5.4.1 Oracle Application Server Web Cache Placement, Clustering and Deployment Considerations

OracleAS Web Cache is a content-aware server accelerator, or reverse proxy server, that improves the performance, scalability, and availability of Web sites that run on Oracle Application Server. Oracle recommends configuring multiple instances of OracleAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating OracleAS Web Cache cache instances that provide a single logical cache.When deploying topologies described in this document, one variant is to place OracleAS Web Cache on a separate host. This is particularly useful in environments with large amounts of cacheable content. This architecture modification provides flexibility in choosing the number of computers to operate OracleAS Web Cache, as well as defining separate hardware profile for OracleAS Web Cache servers and J2EE or OracleAS Portal servers. Typically, a large amount of RAM and fast access to file storage are the most critical components in the performance of the OracleAS Web Cache server. Another possibility is to place a firewall between OracleAS Web Cache and the Oracle HTTP Server; this would provide an additional layer of security.

Note:

In an OracleAS Portal environment, specific configuration is needed to ensure that cache invalidation messages can reach, and be be correctly routed to, the Web Server Tier.

For additional information on configuration variants with OracleAS Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.

1.5.4.2 Oracle HTTP Server: Forward and Reverse Proxies

The architectures described in this guide can be deployed in environments with additional forward or reverse proxy servers.Proxy scenarios change the way the clients' IP addresses are seen by the Oracle HTTP Server. This can be adjusted to better match Web applications' expectations by transferring the clients' IP addresses through proxies in additional HTTP headers and making the HTTP Server use the header values, either with explicit configuration or implicitly, by overall replacing the "physical" request connection information with the header values.The Oracle HTTP Server and applications in an Oracle HTTP Server handle information about clients. Because clients are often identified by their IP addresses, scenarios in which reverse ("transparent") or forward ("normal") proxies are part of the whole system may require adjustments in how the client's IP addresses are seen by the Oracle HTTP Server. For more information on how to configure Oracle HTTP Server for these environments, see the Oracle HTTP Server Administrator's Guide.For information on how to integrate OracleAS Web Cache with an additional proxy server, see the Oracle Application Server Web Cache Administrator's Guide.

1.6 Enterprise Deployment Nomenclature

The naming convention for the components and computers is established in Figure 1-1 and Figure 1-2, and is used throughout this guide. Server names, and their related URLs and IP addresses are provided in Table 1-9. The external load balancer nomenclature is provided in Table 1-10.

Table 1-9 Server Name, URL and IP Address Reference

Description	Name	URL	IP Address
Servers with 2-node Real Application Clusters database for Security Metadata Repository	INFRADBHOST1 INFRADBHOST2	infradbhost1.mycompany.com infradbhost2.mycompany.com	xxx.xxxx.xxx.225 xxx.xxxx.xxx.226
Servers with 2-node Real Application Clusters database for Application Metadata Repository	APPDBHOST1 APPDBHOST2	appdbhost1.mycompany.com appdbhost2.mycompany.com	xxx.xxxx.xxx.227 xxx.xxxx.xxx.228
Oracle Internet Directory servers	OIDHOST1 OIDHOST2	oidhost1.mycompany.com oidhost2.mycompany.com	xxx.xxx.xxx.229 xxx.xxx.xxx.230
Identity Management servers	IDMHOST1 IDMHOST2	idmhost1.mycompany.com idmhost2.mycompany.com	xxx.xxx.xxx.231 xxx.xxx.xxx.232
Application middle tier servers	APPHOST1 APPHOST2	apphost1.mycompany.com apphost2.mycompany.com	xxx.xxx.xxx.233 xxx.xxx.xxx.234
Web tier servers (myJ2EECompany)	WEBHOST1 WEBHOST2	webhost1.mycompany.com webhost2.mycompany.com	xxx.xxx.xxx.235 xxx.xxx.xxx.236

Table 1-10 External Load Balancer Name, URL and IP Address Reference

Description	URL	IP Address
Virtual IP Addresses	portal.mycompany.com:443 login.mycompany.com:443	xxx.yyy.zzz.220 xxx.yyy.zzz.220 xxx.yyy.zzz.222 xxx.yyy.zzz.222
Virtual IP Address (myJ2EECompany)	myapp.mycompany.com:443	xxx.yyy.zzz.220
Failover Virtual IP Addresses	portal.mycompany.com:443 login.mycompany.com:443	xxx.yyy.zzz.221 xxx.yyy.zzz.223
Internal Load Balancer for LDAP traffic	oid.mycompany.com:389/636	xxx.yyy.zzz.12
Failover Virtual IP Addresses (VIPs)	oid.mycompany.com:389/636	xxx.yyy.zzz.13
Internal Ports: Source Network Address Translation (SNAT) for VIP1	portal.mycompany.com:7777 portal.mycompany.com:4001	xxx.yyy.zzz.14 xxx.yyy.zzz.15

1.7 How to Use This Guide: The Enterprise Deployment Configuration Process

This guide is organized to reflect the chronology of the installation and configuration process for the myJ2EECompany and myPortalCompany architectures. The configuration process for each is detailed in the following sections.

1.7.1 Installing and Configuring myJ2EE Company

Install the Metadata Repository on INFRADBHOST1 and INFRADBHOST2.
Install Oracle Internet Directory on OIDHOST1 and OIDHOST2.
Install an Oracle Application Server J2EE and Web Cache installation on APPHOST1 and APPHOST2. Configure OC4J, and disable OracleAS Web Cache and Oracle HTTP Server.
Create OC4J instances in the Oracle Application Server instances on APPHOST1 and APPHOST2, and deploy applications on the instances.
Create a DCM-Managed Oracle Application Server Cluster and add the instances to it.
Install an Oracle Application Server J2EE and Web Cache installation on WEBHOST1 and WEBHOST2. Configure OracleAS Web Cache and Oracle HTTP Server, and disable OC4J.
Configure the Load Balancing Router.
Configure the Oracle HTTP Server with the Load Balancing Router.
Configure OC4J routing.
Configure application authentication and authorization with the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider.
(Optional) Configure Secure Sockets Layer for Oracle HTTP Server, OracleAS Web Cache, OC4J and mod_oc4J.

1.7.2 Installing and Configuring myPortalCompany

Install the Metadata Repository on INFRADBHOST1 and INFRADBHOST2.
Install Oracle Internet Directory on OIDHOST1 and OIDHOST2.
Install Oracle Delegated Administration Services, Oracle Application Server Single Sign-On and Oracle HTTP Server on IDMHOST1 and IDMHOST2.
Install OracleAS Web Cache, OracleAS Portal, and Oracle HTTP Server on APPHOST1.
Configure the Load Balancing Router and related components.
Install OracleAS Web Cache, OracleAS Portal, and Oracle HTTP Server on APPHOST2
Configure application server components and the Load Balancing Router on APPHOST2.
Configure OracleAS Web Cache and the Load Balancing Router.

1.8 Best Practices for Installing and Configuring Enterprise Deployments

Observation of the following practices may save you time as you install and configure the architectures described in this guide:

Before each configuration step, make a complete file system backup of the entire Oracle home, capturing the previous step on all computers at the same time. If there is a problem at any point during installation or configuration, you can then return to the previous state by restoring the backup to all computers at the same time.

Note:

On UNIX systems, when using the tar utility, issue the tar or untar command as the root user. Some of the executables in Oracle software are owned by root. Backing up files in this way as the root user does not change ownership of the file system, or symbolic links inside folders and subfolders.

Try to keep user IDs, group IDs, Oracle home paths and directory structures the same on both computers for each component installed.
Use the static ports feature of the installer when installing components, to ensure that the same ports are used on both computers for each component. (Ideally, you would use the same staticports.ini file for the first and second installations of a given installation type on each tier.)