| Oracle® Application Server Enterprise Deployment Guide 10g (10.1.4.0.1) Part Number B28184-02 |
|
|
View PDF |
| Oracle® Application Server Enterprise Deployment Guide 10g (10.1.4.0.1) Part Number B28184-02 |
|
|
View PDF |
Enterprise Deployments In This Guide
An enterprise deployment an Oracle Application Server configuration that is designed to support large-scale, mission-critical business software applications. The hardware and software in an Enterprise Deployment configuration 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
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
Security systems are integrated
Administrative access is isolated
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
The Oracle Application Server configurations discussed in this guide are designed to ensure security of all transactions, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications. The security and high availability benefits of the Oracle Application Server configurations are realized through isolation in firewall zones and replication of software components.
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.
Direct 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.
Identity Management components are in the DMZ.
All communication between components across DMZs is restricted by port and protocol, according to firewall rules.
This guide provides configuration instructions for two Enterprise Deployments:
Figure 1-1 shows the enterprise deployment architecture for J2EE applications that use JAZN/SSO-DAS for user authentication.
Figure 1-2 shows the enterprise deployment architecture for J2EE applications that use Oracle Access Manager or JAZN LDAP for user authentication.
Note:
The Load Balancing Router is not used in front of the Oracle Internet Directory servers; JAZN LDAP could be configured to individual Oracle Internet Directory servers, or a Load Balancing Router can be placed in front of the servers for high availability.The servers in the myJ2EECompany system are grouped into tiers as follows:
Web Tier — WEBHOST1 and WEBHOST2, with Oracle HTTP Server installed.
Note:
The WebPass component is not available on Windows at the time of publication. Therefore, WEBHOST1 and WEBHOST2 in the myJ2EEOracle Access Manager configuration must be servers with operating systems other than Windows.Application Tier — APPHOST1 and APPHOST2, with Oracle Containers for J2EE installed, and multiple OC4J instances with applications deployed. In myJ2EE with Oracle Access Manager, this tier also includes WebGate, WebPass, and Oracle Access Manager Identity Server, Access Server, Access Manager, and ADMINHOST, for administrator use.
Note:
The Access Manager component is not available on Windows at the time of publication. Therefore, ADMINHOST in the myJ2EEOracle Access Manager configuration must be a server with an operating system other than Windows.Data Tier — OIDHOST1 and OIDHOST2, with 10g (10.1.4.0.1) Oracle Internet Directory installed, and INFRADBHOST1 and INFRADBHOST2, the two-node Real Application Clusters database.
Figure 1-1 Enterprise Deployment Architecture for myJ2EEcompany.com with JAZN-SSO/DAS
Figure 1-2 Enterprise Deployment Architecture for myJ2EEcompany.com with Oracle Access Manager
Table 1-1, Table 1-2 and Table 1-3 list minimum hardware requirements for the Enterprise Deployments 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 in use.
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 |
|
ADMINHOST |
300 MHz or higher Intel Pentium processor recommended |
400 MB |
512 MB |
n/a |
512 MB |
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 |
|
ADMINHOST |
Pentium (32-bit), 450 MHz or greater |
520 MB |
512 MB |
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 |
|
ADMINHOST |
450 MHz or greater; Oracle recommends a multiple CPU computer |
750 MB |
512 MB |
250 MB |
1.5 GB |
Production requirements vary depending on applications and the number of users. All 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 installation and configuration of the second server on the tier (WEBHOST2, APPHOST2, INFRADBHOST2) to add a third server where it is needed.
To determine hardware needs with a greater degree of precision, you might consider the options presented in Table 1-4.
Table 1-4 Hardware Sizing Options
| Option | Benefit | Disadvantage |
|---|---|---|
|
Create a prototype of the deployment architecture and stress test it |
|
|
|
Use the iSizer tool |
|
|
The variants described in this section enable you to achieve deployment goals using fewer servers, different software, or alternative configurations.
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 directory servers in the system remains available. When an Oracle Directory server resumes functioning after being unavailable, replication from the surviving directory server resumes automatically and synchronizes the contents between the directory servers forming the directory replication group. In addition, any changes made on one directory server instance are reflected on the second directory server instance.
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".
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 OIDHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy OIDHOST2 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.
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, "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, "Managing Oracle Application Server Cold Failover Cluster (Identity Management)".
Proxies change the way the Oracle HTTP Server processes client requests.
A forward proxy is an intermediary server between a client and the origin server containing the content. Forward proxies are usually used to provide Internet access to internal clients that are otherwise restricted by a firewall. To get content from the origin server, the client sends a request to the proxy, naming the origin server as the target. The proxy requests the content from the origin server and returns it to the client. The client must be configured to use the forward proxy to access other sites.
A reverse proxy is a server that appears to outside clients to be the content server. It relays requests from outside the firewall to servers behind the firewall, and delivers retrieved content back to the client. A firewall rule allows access only to the proxy server, so that the content servers are protected. The proxy server changes URLs listed in the headers of any messages generated by the content servers, so that external clients are given no information about the servers behind the firewall. No configuration of clients is necessary with a reverse proxy (the client makes requests for content in the name-space of the reverse proxy). The reverse proxy decides where to send the requests, and returns the content as if it was the origin server.
For certain types of J2EE applications, such as JMS-based or EJB-based applications, there may be other variants to these architectures. Refer to the Oracle Containers for J2EE Configuration and Administration Guide, and the Oracle Containers for J2EE Developer's Guide for more information on these variants.
Table 1-5 summarizes the process by which you install and configure myJ2EECompany with each of the user authentication methods. Follow the procedures indicated in the column for the configuration of your choice.
Table 1-5 Enterprise Deployment Configuration Procedures
