|
Oracle® Application Server 10g Best Practices
10g (9.0.4) Part No. B12223-01 |
|
|
|
|
Oracle® Application Server 10g Best Practices
10g (9.0.4) Part No. B12223-01 |
|
|
|
|
This chapter describes deployment best practices for Oracle Application Server. It includes the following topics:
In an enterprise environment, there is demand for highly available, scalable and secured enterprise architecture for global application deployment to support worldwide customers. Oracle Application Server 10g users expect high availability for:
Middle-tier components such as OracleAS Web Cache, OracleAS Portal, OracleAS Wireless.
Identity Management components such as OracleAS Single Sign-On, Delegated Administration Services, and Oracle Internet Directory.
Custom J2EE applications.
Backend OracleAS Metadata Repository.
Optimally, there should not be a single point of failure at any time, with any tier, and with any component.
The following is a description of a Portal and Wireless deployment in an enterprise environment.
The Portal and Wireless install type components require an OracleAS Infrastructure 10g. The infrastructure includes:
Identity Management components including Oracle Internet Directory, Oracle Application Server Single Sign-On (OracleAS Single Sign-On), Oracle Delegated Administration Services (DAS), Oracle Directory Integration and Provisioning (DIP), and Oracle Application Server Certificate Authority (OCA).
An Identity Management database consisting of an Oracle Application Server Metadata Repository (OracleAS Metadata Repository).
If there is a DMZ or multiple DMZs in the network topology, all the Application and Web tier components must reside in the Web tier DMZ. The data tier components reside in the intranet or data tier DMZ.
The following are security requirements for deployment:
Distribute Oracle Application Server components between your Web and data tiers. Your Web application components should reside in the external DMZ and your database components should reside behind the internal or external DMZ. Components such as Oracle Internet Directory and DIP are considered as data tier components and they must reside in the data tier DMZ. Other Identity Management components such as Oracle HTTP Server, OracleAS Single Sign-On, and DAS will be in the Web tier DMZ.
Communication between different components across the DMZ will be restricted for Port and protocol level, monitored by different firewall rules and intrusion detection.
Isolate each DMZ as a zone and allow only required traffic/protocol between the DMZs on specific port.
Do not allow any communication between two firewalls at a time.
If communication starts in one firewall zone it must end in the next firewall zone.
External direct communication from end-users must end at the external load-balancer (LBR) level.
There should not any communication for the end user to the internal data tier (DMZ).
Figure 1-1 is an example of component level High Availability architecture.
This section describes infrastructure deployment considerations. It includes the following topics:
A highly available enterprise deployment requires end-to-end architecture for availability and scalability. The OracleAS Metadata Repository, Oracle Internet Directory, and optionally, the DIP Server, are considered components of the data tier. You should deploy these components in the data tier DMZ.
Figure 1-2 is an example data tier infrastructure component deployment. In this example, the data tier High Availability is provided with Real Application Clusters (RAC), and multiple Oracle Internet Directory servers.
Identity management components including Oracle HTTP Server, OracleAS Single Sign-On, and DAS should reside on the Web-tier or external DMZ.
For highly available deployment, you can have multiple identity management servers configured with same backend metadata repository. Identity Management servers can be configured with an external load balancer for external access.
If you have two Oracle Internet Directory servers running in your deployment, you can have a load balancer for LDAP traffic from OracleAS Single Sign-On and DAS to the two Oracle Internet Directories.
Figure 1-3 is an example of a highly available Identity Management installation.
Figure 1-3 High Availability Identity Management Installation
Your application server middle tier should be installed and deployed in the Web tier or external DMZ. If your enterprise uses multiple middle-tier applications for high availability and scalability, you must deploy with a load balancer. When you use the load balancer consider the following:
Parallel Page Engine (PPE) Loopback: PPE loops or routes back to OracleAS Web Cache to access mod_plsql for database connection. If OracleAS Web Cache is unresponsive, the PPE should be able to loopback to OracleAS Web Cache on the existing middle-tier. This is accomplished by looping back to LBR via Network Address Translations (NAT). For more information refer to the Oracle Application Server Portal User's Guide.
Invalidation: Database sends invalidation message to OracleAS Web Cache, if there are multiple OracleAS Web Cache nodes Invalidation has to be load balanced across multiple OracleAS Web Cache nodes for High Availability. For more information refer to the Oracle Application Server Portal User's Guide.
SSL implementation: Oracle AS will allow the customer to run their entire Application server in SSL mode using either software SSL or Hardware based SSL also called SSL accelerator (nCypher).
The following are characteristics of the end to end enterprise architecture for highly available, scalable and secured application server deployment:
Highly available, scalable and secured architecture.
Component separation to Web tier DMZ and data tier DMZ
Encryption enforcement (SSL) for component communication outside the firewall. For ex: Communication from LBR to end-user or vice versa.
SSL accelerator(nCypher) configuration with application server for performance improvement.
No communication between two firewalls at a time.
|
Note: There may an exception for invalidation messages if there are multiple firewalls between LBR and database. But, this communication originates from data tier DMZ to Web tier DMZ in one direction, Reverse communication must be restricted. |
Component level HA
OracleAS Web Cache Clustering
If you want to deploy OracleAS Web Cache and OracleAS Portal in remote locations, consider deploying an instance of OracleAS Web Cache and an instance of the OracleAS Portal mid-tier at each remote location. This deployment can improve performance because many pages will be served from local caches and will not require any communication over the WAN.
In this deployment, each cache contacts the local OracleAS Portal mid-tier instance, instead of all caches contacting one OracleAS Portal instance at the data center. Each remote cache should cache content for the application Web servers. In addition, you can configure the remote caches as an invalidation-only cache cluster so that you can easily propagate invalidation across the caches in all locations.
Figure 1-4 shows a topology that consists of OracleAS Web Cache and OracleAS Portal deployed in the middle tier at each location.
Figure 1-4 OracleAS Web Cache and OracleAS Portal Deployed at Remote Locations
