|
Oracle® Application Server Enterprise Deployment Guide
10g Release 3 (10.1.3) B25210-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Enterprise Deployment Guide
10g Release 3 (10.1.3) B25210-02 |
|
|
Previous |
Next |
This chapter introduces Oracle Application Server installation types and architectures and the nomenclature used in this guide to describe the Enterprise Deployment architectures. It contains the following topics:
Section 2.1, "Creating Solutions with Oracle Application Server"
Section 2.2, "Enterprise Deployment Nomenclature"
Section 2.3, "Understanding the Enterprise Deployment Architecture"
Section 2.4, "What's New in myJ2EE"
Section 2.5, "Understanding Deployment Variants"
Section 2.6, "How to Use this Guide: The Enterprise Deployment Configuration Process"
Oracle Application Server 10g Release 3 (10.1.3) is a complete, fully integrated product that delivers a wide range of solutions to business and technology challenges. This guide presents a subset of these, in the form of recommendations based on deployments by Oracle customers.
This guide provides installation and configuration steps for the J2EE Server and Process Management installation type, using Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider/LDAP authentication.
For complete descriptions of the components comprising these installation types and selections, see the Oracle Application Server Concepts guide.
The naming convention for the components and computers is established in the architecture diagram on and is used throughout this guide. Server names and their related URLs and IP addresses are provided in Table 2-1. The external load balancer nomenclature is provided in Table 2-2.
Table 2-1 Server Name, URL and IP Address Reference
| Description | Name | URL | IP Address |
|---|---|---|---|
|
Servers with 2-node Real Application Clusters database for Security Metadata Repository |
INFRADBHOST2 |
infradbhost1.mycompany.com infradbhost2.mycompany.com |
xxx.xxxx.xxx.225 xxx.xxxx.xxx.226 |
|
OIDHOST2 |
oidhost1.mycompany.com oidhost2.mycompany.com |
xxx.xxx.xxx.229 xxx.xxx.xxx.230 |
|
|
APPHOST2 |
apphost1.mycompany.com apphost2.mycompany.com |
xxx.xxx.xxx.233 xxx.xxx.xxx.234 |
|
|
WEBHOST2 |
webhost1.mycompany.com webhost2.mycompany.com |
xxx.xxx.xxx.235 xxx.xxx.xxx.236 |
This section briefly describes the Enterprise Deployment architecture in this guide, including minimum hardware requirements and a diagram of the architecture.
Figure 2-1 shows the enterprise deployment architecture for J2EE applications that use the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider for user authentication.
The servers in the myJ2EECompany system are grouped into tiers as follows:
Web Tier — WEBHOST1 and WEBHOST2, with Oracle HTTP Server installed.
Application Tier — APPHOST1 and APPHOST2, with Oracle Containers for J2EE installed, and multiple OC4J instances with applications deployed.
Data Tier — OIDHOST1 and OIDHOST2, with 10g Release 2 (10.1.2) Oracle Internet Directory installed, and INFRADBHOST1 and INFRADBHOST2, the two-node Real Application Clusters database.
Table 2-3, Table 2-4 and Table 2-5 identify the basic, minimum hardware requirements for the servers in the myJ2EE architecture 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 2-3 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 2-4 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 2-5 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 2-1 Enterprise Deployment Architecture for myJ2EEcompany.com
The myJ2EE Enterprise Deployment Architecture functions as it did in prior releases, but clustering, request routing, and authentication and authorization have changed in Oracle Application Server 10g Release 3 (10.1.3). Table 2-6 lists and compares the features and configuration methods for the prior and current releases.
Table 2-6 myJ2EE Enterprise Deployment Configuration in Prior Releases and the Current Release
| Feature | In Prior Releases... | In 10g Release 3 (10.1.3)... |
|---|---|---|
|
|
Additional OC4J instances were created Oracle Enterprise Manager 10g Application Server Control Console |
Additional OC4J instances are created with the |
|
Note: A comprehensive discussion of clustering options, methods, concepts and terminology is provided by Chapters 8 and 9 of the Oracle Containers for J2EE Configuration and Administration Guide.
|
Creation: An Oracle Application Server instance was designated during installation as a member of an existing file-based or database-based farm, or the founding member of a new farm. Clusters were created within the farm using the Oracle Enterprise Manager 10g Application Server Control Console. The second instance, and all successive instances to join a cluster, adopted the founding cluster member's configuration. Aggregation: One or more clusters (each containing one or more instances) were members of a farm; one farm in each computer. Connectivity: Computers were explicitly specified in the Status Viewing/Management: Oracle Enterprise Manager 10g Application Server Control Console provided status information on the cluster. The farm's cluster and instance configuration information was stored in the Distributed Configuration Management repository. The |
Creation: Cluster is created during installation, by providing a multicast address and port to the installer, or after installation, using Oracle Process Manager and Notification Server utilities. Aggregation: A cluster comprises two or more Oracle Application Server instances. The Connectivity: The Oracle Process Manager and Notification Server's Oracle Notification Server (ONS) maintains a cluster topology map in the
Status Viewing/Management: The Any change to a configuration file must be manually applied to the same configuration file of each OC4J instance in the cluster. |
|
|
|
|
|
Application Clusters for session and state replication Note: A comprehensive discussion of clustering options, methods, concepts and terminology is provided by Chapters 8 and 9 of the Oracle Containers for J2EE Configuration and Administration Guide. |
An Oracle Application Server Cluster, containing an OC4J island (a group of OC4J instances across which HTTP session data was replicated), was created. Only Web applications could use the island configuration; EJB applications could not. These XML elements were used to configure clusters:
|
Clustering is enabled by the Clustering can be global for all applications in an OC4J instance, or application-level, for a given application or applications in an OC4J instance. You can specify the scope, timing and attributes of the replicated session or state data. |
|
The The |
Load balancing is dynamic; no configuration is required. Oracle HTTP Server instances are updated with information on each OC4J instance (and its deployed applications) in a cluster. You can specify the OC4J instances to which the Oracle HTTP Server routes requests. |
|
|
The Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider (also referred to as JAZN) LDAP-based provider is used for authentication and authorization to the OC4J applications. This provider is used without Oracle Application Server Single Sign-On, because communication to the data tier is prohibited (Oracle Application Server Single Sign-On requires Portal Services access to the database). |
See Section 5.4, "Configuring Application Authentication and Authorization" for instructions. |
Figure 2-1, "Enterprise Deployment Architecture for myJ2EEcompany.com", shows a standard enterprise deployment architecture. 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.
Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider (on the Application Tier in Figure 2-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.
For certain types of J2EE applications, such as JMS-based or EJB-based applications, other variants may exist. Refer to the Oracle Containers for J2EE Configuration and Administration Guide, the Oracle Containers for J2EE Developer's Guide and the Oracle Containers for J2EE Developer's Guide for more information on these variants.
This section describes the variants for the Data Tier. The Data Tier is depicted in Figure 2-1, "Enterprise Deployment Architecture for myJ2EEcompany.com", and comprises the INFRADBHOST1 and INFRADBHOST2 computers.
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, 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)".
This section describes the variants for the Web Server Tier. The Web Server Tier is depicted in Figure 2-1, "Enterprise Deployment Architecture for myJ2EEcompany.com", the Web Server Tier comprises the WEBHOST1 and WEBHOST2 computers.
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 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.
For additional information on configuration variants with OracleAS Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.
The architectures described in this guide can be deployed in environments with 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 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.
There are two ways to install Oracle HTTP Server on the Web Server Tier: as a standalone Web server, or as part of the Integrated Web Server, J2EE Server and Process Management installation type.
Some security plans discourage installation of any Java executables on the Web Server tier. For this reason, this guide presents the installation of the Oracle HTTP Server as a standalone Web server. The Oracle HTTP Server is managed by the opmnctl utility (invoked by the Start menu on Windows systems) instead of the Oracle Enterprise Manager 10g Application Server Control Console.
This guide contains instructions for configuring the myJ2EE Enterprise Deployment shown in Figure 2-1, using JAZN LDAP authentication and authorization, two Oracle Internet Directory servers and a Load Balancing Router.
The configuration process for myJ2EE is as follows:
Install the Metadata Repository on INFRADBHOST1 and INFRADBHOST2, as described in Section 4.1, "Installing the Oracle Application Server Metadata Repository for the Security Infrastructure".
Install Oracle Internet Directory on OIDHOST1 and OIDHOST2, as described in Section 4.2, "Installing the Oracle Internet Directory Instances in the Data Tier".
Configure the Load Balancing Router or proxy server and related components, as described in Section 5.3, "Configuring the Oracle HTTP Server with the Load Balancing Router".
Install an Oracle Application Server Integrated Web Server, J2EE Server and Process Management instance on APPHOST1 and APPHOST2, as described in Section 5.2.1, "Installing the Application Tier Application Server Instances on APPHOST1 and APPHOST2".
If necessary, create additional OC4J instances in the Oracle Application Server instance on APPHOST1, as described in Section 5.2.1, "Installing the Application Tier Application Server Instances on APPHOST1 and APPHOST2".
Deploy applications as described in Section 5.2.3, "Deploying J2EE Applications".
Install an Oracle Application Server Integrated Web Server, J2EE Server and Process Management instance on WEBHOST1 and WEBHOST2, as described in Section 5.2.2, "Installing the Oracle HTTP Servers on WEBHOST1 and WEBHOST2".
Configure the Oracle HTTP Server with the Load Balancing Router as described in Section 5.3, "Configuring the Oracle HTTP Server with the Load Balancing Router".
Configure application authentication and authorization with the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider as described in Section 5.4, "Configuring Application Authentication and Authorization".
