|
Oracle® Application Server 10g Advanced Topologies for Enterprise Deployments
10g (9.0.4) Part No. B12115-01 |
|
|
|
|
Oracle® Application Server 10g Advanced Topologies for Enterprise Deployments
10g (9.0.4) Part No. B12115-01 |
|
|
|
|
The following sections contains networking considerations in an Oracle Application Server topology:
Oracle Application Server has several features to connect and manage the various parts of an enterprise deployment topology, including:
DCM is a management framework that enables you to manage the configurations of multiple Oracle Application Server instances across an enterprise deployment topology. DCM consists of clients, a daemon, and a metadata repository.
DCM features enable you to:
Manage clusters and farms of Oracle Application Server instances. Manage the configuration of individual components, such as Oracle Application Server Containers for J2EE instances, Oracle HTTP Server instances, and Oracle Process Management and Notification, or Java Authentication and Authorization Service.
Perform cluster-wide Oracle Application Server Containers for J2EE application deployment, especially in Development Life Cycle topology.
Manage versions of configurations with archive, save and restore, and import and export functions. You can automate some of these functions as part of routine systems maintenance.
dcmctl is the Distributed Configuration Management command-line utility. You can use it to manage configurations and deploy applications. Instructions on using dcmctl and complete descriptions of all commands are described in Chapter 2, "dcmctl Commands "in the Distributed Configuration Management Reference Guide.
All configuration and topology data is stored in the Distributed Configuration Management metadata repository, which may be part of the Oracle Application Server Metadata Repository.
For additional information on working with DCM, see the Distributed Configuration Management Reference Guide.
OPMN is installed and configured with every Oracle Application Server installation type and is essential for running Oracle Application Server.
OPMN features the following functionality:
Provides a command-line interface for process control and monitoring for single or multiple Oracle Application Server components and instances.
Provides an integrated way to manage Oracle Application Server components.
Enables management of Oracle Application Server subcomponents and sub-subcomponents.
Channels all events from different Oracle Application Server component instances to all Oracle Application Server components that can utilize them.
Solves interdependency issues between Oracle Application Server components by enabling you to start and stop components in order.
Enables customizing of enterprise functionality by using event scripts.
Enables gathering of host and Oracle Application Server process statistics and tasks.
Provides automatic restart of Oracle Application Server processes when they become unresponsive, terminate unexpectedly, or become unreachable as determined by ping and notification operations.
Provides automatic death detection of Oracle Application Server processes
Does not depend on any other Oracle Application Server component being up and running before it can be started and used.
The OPMN server should be started as soon as possible after turning on the host. OPMN must be running whenever OPMN-managed components are turned on or off.
Oracle Application Server components managed by OPMN should never be started or stopped manually. Do not use command line scripts or utilities from previous versions of Oracle Application Server for starting and stopping Oracle Application Server components. OPMN must be the last service turned off whenever you reboot or turn off your computer.
Use the Application Server Control and the opmnctl command line utility to start or stop Oracle Application Server components.
For more information about OPMN, see Oracle Process Manager and Notification Server Administrator’s Guide
LDAP is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to communicate.
Oracle Internet Directory is a general purpose directory service that enables fast retrieval and centralized management of information about dispersed users and network resources. It combines Lightweight Directory Access Protocol (LDAP) Version 3 with the high performance, scalability, robustness, and availability of Oracle9i.
For more information on working with LDAP and Oracle Internet Directory, see Oracle Internet Directory Administrator’s Guide. Make sure your application developers read Oracle Internet Directory Application Developer’s Guide.
Oracle Enterprise Manager Application Server Control enables Web site administrators to configure Oracle Application Server instances, to monitor and optimize them for performance and scalability, and to respond proactively to problem conditions.
The Application Server Control allows administrators to stop and restart Oracle Application Server instances from the Oracle Application Server Instance Home Page. They can also modify the configuration settings based on performance statistics collected to improve performance and scalability or to address any problems.The Application Server Control provides performance metrics for each component in both tabular and chart formats so you can identify problem conditions at a glance. When you drill down on an Oracle Application Server, you can view the status, historical uptime statistics, and the current performance and availability for each Oracle Application Server instance.
Metrics vary from one component type to another, but typical metrics include:
Up/down status
Memory usage
Error rate
Start time
Number of connections
In a distributed installation of Oracle Application Server, such as an Enterprise Topology, you’ll need to configure ports in the firewalls to allow Oracle Application Server services to work correctly. Specifically, you’ll need to allow for:
HTTP and HTTPS to be open for users (clients) to contact the web server
Application servers (middle tier installations) to communicate with the Infrastructure (SQL*Net, ORCL-LDAP, ORCL-LDAP-SSL, ONS, OPMN)
Application servers to databases, SQL*Net, and LDAP protocols if necessary
Port 1814 for Enterprise Manager (for Infrastructure and middle tier installations) and for any other tools and services, such as LDAP ports.
AJP to be opened for mod_oc4j to OC4J communications
|
Note: Default ports may differ between operating systems (Solaris, Windows, and Linux). Use Application Server Control to discover and manage ports. |
Oracle Enterprise Manager Application Server Control is the preferred way to track port information if default ports have been changed. For default port information refer to the default ports section of the Oracle Application Server 10g Administrator's Guide.
Firewall Stateful Inspection is not used between DMZ, mid-iers, and infrastructure and Oracle recommends that FSI be used in the external internet interface.
For information about configuring and managing firewalls, see your administrator or the documentation for your firewall implementation.
mod_oc4j is located within Oracle HTTP Server and (1) identifies the requests it needs to act on, (2) determines which OC4J to route those requests to, and (3) communicates with that process. Mod_oc4j now extracts some relevant parameters (for example SSL information, certain environment variables, etc.) and forwards them to OC4J, using AJP13 protocol.
mod_oc4j analyzes the response from OC4J and takes appropriate actions, for example, if a Single Sign-On redirect is required.
By default, OPMN processes on all Oracle Application Server instances in the farm notify each other of the up/down status of OC4J within their instance. In turn, every OPMN also notifies its local mod_oc4j of changes in the OC4J status on all machines within the cluster. This allows mod_oc4j to keep its routing table updated, without any intervention from an administrator.
As a security practice, you can place mod_oc4j in one tier (usually in a DMZ tier) and have it communicate with OC4J processes that are located in another tier (usually another DMZ tier). Since mod_oc4j uses AJP to communicate to other OC4J instances, it is important to have the correct ports opened for AJP and OPMN.
For more information about OC4J architecture, see the whitepaper Oracle9i Application Server: mod_oc4j Technical Overview at http://otn.oracle.com/products/ias/ohs/collateral/r2/mod_oc4j_wp.pdf.
The Application Server 10g Port Tunneling (iASPT) feature reduces the number of ports required to communicate to multiple OC4J processes to one. The iASPT process acts as a communication concentrators for connections between Oracle HTTP Server (OHS) and the Java virtual machine (JVM). (OHS) does not connect directly to the servlet engines, instead, OHS connects to an iASPT. iASPT then forwards communication on to the servlet engine. Each iASPT routes requests to multiple servlet engines. By doing this concentration of connections, you’re only required to open one port per iASPT process on the internal firewall DMZ rather than one port per OC4J container.
As part of configuring iASPT, you’ll need to need to tell iASPT where mod_oc4j lives and where the OC4J containers are. There are several directives to add in mod_oc4j, such as wallet files and their passwords. On the server containing the target OC4J instance, you’ll need to configure opmn.xml and set the iASPT status to enabled, as well as specify the port or range of ports use. Finally, modify iaspt.conf to validate for the correct location of wallet and port information.
For complete information on configuring iASPT, see Chapter 10 of Oracle HTTP Server Administrator's Guide.
In a configuration where there is a pool of applications servers (called a resource pool), and a pool of Single Sign-On servers, you’ll need to add a virtual IP address to the load balancers (either software or hardware) then add pools to the virtual IP addresses. The application server pool needs to have persistence specified. Often, this is an active HTTP cookie setting in the software or hardware configuration page in the load balancer. See your administrator or documentation for your load balancer.
With SSL, cookies are problematic because of how encryption works. Often, you’ll need to use the SSL session ID to specify persistence in your load balancer. Chapter 5 of Oracle Application Server Portal Configuration Guide contains extensive information on load balancing. Some of that information is presented in the following section.
This section describes how you can set up multiple middle-tiers, front-ended by a load balancing router (LBR) to access the same OracleAS Metadata Repository.
The purpose of a Load Balancing Router (LBR) is to provide a single published address to the client tier, and front-end a farm of servers that actually service the requests, based on the distribution of the requests done by the LBR. The LBR itself is a very fast network device that can distribute Web requests to a large number of physical servers.
Let us assume that we want to configure the multiple middle-tier configuration, shown in Figure 4-1. In the example, we show OracleAS Web Cache on the same machine as the Portal and Wireless middle-tier, although they can theoretically be on different machines.
Figure 4-1 Multiple Middle-Tier Configuration with Load Balancer
Table 4-1 Additional information About the Graphic
| Machine | Details |
|---|---|
| Load balancing router | Machine Name: lbr.abc.com
IP Address: Listening Port: Invalidation Port: |
| Oracle Application Server (Portal and Wireless middle-tier) 1 | Machine Name: m1.abc.com
IP Address: Oracle HTTP Server Listening Port: OracleAS Web Cache Listening Port: 7777 OracleAS Web Cache Invalidation Port: 4001 |
| Oracle Application Server (Portal and Wireless middle-tier) 2 | Machine Name: m2.abc.com
IP Address: M2.M2.M2.M2 Oracle HTTP Server Listening Port: 7778 OracleAS Web Cache Listening Port: 7777 OracleAS Web Cache Invalidation Port: 4001 |
To understand how to configure OracleAS Portal with LBR, it is important to understand the internal architecture of Portal:
The Parallel Page Engine (PPE) in Portal makes loopback connections to Oracle Application Server Web Cache for requesting page metadata information. In a default configuration, OracleAS Web Cache and the OracleAS Portal middle-tier are on the same machine and the loopback is local. When Oracle Application Server is front-ended by an LBR, all loopback requests from the PPE will start contacting OracleAS Web Cache through the LBR. Assume that the OracleAS Portal middle-tier and OracleAS Web Cache are on the same machine, or even on the same subnet. Then, without additional configuration, loopback requests result in network handshake issues during the socket connection calls.
In order for loopbacks to happen successfully, you must set up a Network Address Translation (NAT) bounce back rule in the LBR, which essentially configures the LBR as a proxy for requests coming to it from inside the firewall. This causes the response to be sent back to the source address on the network, and then forwarded back to the client.
OracleAS Portal leverages OracleAS Web Cache to cache a lot of its content. When cached content in OracleAS Web Cache changes, OracleAS Portal sends Web Cache invalidation requests from the database to OracleAS Web Cache. OracleAS Portal can only send invalidation messages to one Web Cache node. In an OracleAS Web Cache cluster, Portal relies on one OracleAS Web Cache member to invalidate content in the other member of the cluster.
When Oracle Application Server is front-ended by an LBR, the LBR must be configured to accept invalidation requests from the database and balance the load among the cluster members.
|
Note: You will notice that the infrastructure is behind the LBR. The infrastructure can be one host, or distributed over multiple hosts. In order to configure the infrastructure properly, refer to the Chapter titled "Advanced Configurations" in the Oracle Application Server Single Sign-On Administrator’s Guide |
To configure the server so that the PPE loops back to the LBR for the loopback connections, you must perform the following steps:
Install a Single Portal and Wireless Middle-Tier
Step 1: Install a Single Portal and Wireless Middle-Tier (M1)
Step 2: Configure OracleAS Portal on M1 to Be Accessed Through the LBR
Step 3: Confirm That OracleAS Portal is Up and Running
Step 5: Configure the New Middle-Tier (M2) to Run Your Existing Portal
For complete information about these steps, see Chapter 5 of the Oracle Application Server Portal Configuration Guide.
|
See Also: For information on the platform used, see Oracle Application Server 10g Installation Guide. |
A reverse proxy server is a host process that is used as part of a firewall architecture to isolate the internal hosts from the externally accessible host(s). It does this by providing a proxy through which external requests must pass to access internal services. Typically, a proxy server takes the form of a dual-homed host. This means that it is a host with two network interface cards. One interface connects to the external network, and the other interface connects to the internal network, or demilitarized zone (DMZ) of the firewall.
Figure 4-2 shows an architecture in which the browser accesses the server through the hostname that is published by the proxy server. The proxy server then forwards the request to the actual host within the firewall.
For this example, we will assume that you have properly configured the OracleAS Single Sign-On server to work with the reverse proxy server.
|
See Also: Chapter 9, "Deploying Oracle Application Server Single Sign-On with a Proxy Server" in the Oracle Application Server Single Sign-On Administrator’s Guide. |
Figure 4-2 Internet Configuration with Reverse Proxy Server
For this example, let’s assume the following:
The published address is www.abc.com.
Internal to the firewall, the server name for the Oracle Application Server middle-tier is internal.company.com. This Application Server middle-tier machine hosts contains both OracleAS Web Cache, as well as the Oracle HTTP Server.
Externally, the server is addressed with the default port 80; however, internally, the internal.company.com is listening on port 7777.
Information to complete these steps to configure OracleAS Portal for the architecture shown in Figure 4-1 can be found in Chapter 5 of the Oracle Application Server Portal Configuration Guide.
You’ll find additional information about how to set up proxy servers in the paper "A Primer on Proxy Servers," on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
|
 Copyright © 2003, Oracle Corporation All rights reserved |
|