|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) B14037-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) B14037-03 |
|
|
Previous |
Next |
This chapter details the task flow involved in planning, installing, configuring, and administering Oracle Application Server Portal. After reading this chapter, you should understand how to plan the hardware and software you need to effectively build a portal.
This chapter contains the following sections:
|
Note: You may want to review Chapter 1, "Understanding the OracleAS Portal Architecture" if you are unfamiliar with the terms used in this chapter. |
To develop a plan for configuring your portal, it is critical that you have a firm grasp of the goals you want your system to achieve. Take a look at the following sections to see what's involved in each of these crucial decision points:
Oracle Application Server offers a variety of topology options. The Oracle Application Server recommended topologies range from small general development implementations to very large enterprise-wide implementations.
|
See Also: Overview of the recommended topologies in Oracle Application Server Concepts located in the Oracle Application Server 10g Documentation Library. |
Servers, databases, and resources supporting your Web portal must handle wide variations in user traffic, especially during peak intervals.
As with any Web portal, the server and database capacity with which you will need to deploy a portal largely depends on the number of user requests that you anticipate. Displaying a single page to a user may require many separate transactions, from verifying whether the user has permission to view the page, to loading the images that appear on the page, to calling a style sheet that contains formatting information for the page.
The upper and lower limits of what you will need are determined by how you expect your users to use the portal. At a minimum, you will need enough server capacity to satisfy the average load during a work day, with response times that are acceptable to your user base. If possible, you should strive to satisfy the volume of page requests you anticipate during peak intervals of high user activity. Hardware resources such as CPU, memory, I/O capacity, and network bandwidth are key to reducing response times. You must install OracleAS Portal on a server or group of servers that can handle a large number of transactions, or your users will experience slow response times.
Adding more servers and database capacity will certainly improve your Web portal's performance, but unless you have unlimited funds at your disposal, you will need to balance good performance against the costs configured to use each new piece of hardware and software.
Response time is the time between the receipt of a user request and the completion of the response to the request. Your Web portal should respond as quickly as possible with the least amount of software and hardware overhead. Some performance considerations are:
Distributing the load
If you anticipate a heavy volume of traffic on your Web portal, you can distribute the load across multiple servers, each with its own middle-tier instance. If one server is overloaded with too much traffic, a second server can handle the overflow. See Section 2.1.8.1, "Load Balancing" for more information.
Protecting against failures
A distributed OracleAS Portal configuration offers improved performance over a single server configuration because you are making more software and hardware resources available to the Web portal. You can use additional servers and software to provide failover, thus ensuring system stability. See Section 2.1.8.2, "Failover and Redundancy" for more information.
Implementing cache clusters
To increase the availability and scalability of medium to large deployments, you can configure cache clusters. Cache clusters provide failure detection and failover, increasing the availability of your Web site. See Section 1.3, "Understanding Caching in OracleAS Portal" for more information.
Clustering enables you to scale your system beyond the limitations of a single application server instance on a single host. A cluster unifies multiple application server instances spread over multiple hosts to collectively serve a single group of applications. In this way, clustering makes it possible to serve increasing numbers of concurrent users after the capacity of a single piece of hardware is exhausted. Refer to Section 2.1.8.3, "Scalability" and Section 1.3, "Understanding Caching in OracleAS Portal" for more information.
Clustering also enables you to achieve a higher level of system availability than is possible with only a single application server instance. An application running on a single instance of an application server is dependent on the operating system and host on which the server is running. In this case, the host poses as a single point of failure because if the host goes down, the application becomes unavailable.
Application server clusters enable higher availability by providing redundancy and backup and eliminating a single point of failure. Clients access the cluster through a load balancing router that can send requests to any application server instance in the cluster. In the case that an application server instance becomes unavailable, the load balancing router can continue forwarding requests to the remaining application server instances, as any instance can service any request.
Sensitive data should be secured without affecting content that you want to make available to all users.
To support a flexible approach to controlling access to Web content, OracleAS Portal leverages other components of Oracle Application Server and Oracle Database 10g to provide strong protection for your portal. OracleAS Portal interacts with all of the following components to implement its security model:
Oracle Application Server Single Sign-On
mod_osso, an Oracle HTTP Server listener module, which facilitates Single Sign-On for J2EE web applications.
Oracle Application Server Web Cache
Oracle Internet Directory
Oracle Delegated Administration Services
Oracle Directory Integration Platform
See Chapter 6, "Securing OracleAS Portal" for more information.
This section discusses how you should configure your hardware and software installations for optimal use of OracleAS Portal and all related Oracle Application Server components. This section explains how you can configure your hardware to set up a small development environment, and deploy larger sites serving many users.
In the simplest configuration, all of the component pieces (application server and infrastructure) are installed on a single computer as shown in Figure 2-1. In fact, a single database could also reside on the computer, containing separate schemas for OracleAS Portal, Oracle Internet Directory, and OracleAS Single Sign-On.
Figure 2-1 OracleAS Portal Single Computer Configuration
This configuration works nicely in a small development environment in which your developers are using OracleAS Portal's declarative interface to build pages, portlets and applications. It also easily supports a small deployment of the finished Web portal. If you expect to deploy a larger site that delivers more content to more users, you will need more than a single server or the simple configuration shown in Figure 2-1.
If a single computer configuration does not suit your needs, consider moving the various pieces of the OracleAS Portal architecture to other computers. A rule of thumb when configuring your Web portal is: the larger the site, the more servers you will require, each server performing more specialized work. Adding extra hardware increases performance. Adding more software instances supports redundancy.
Deployment options for configuring larger Web portal sites include:
Separating the Middle Tier from the OracleAS Metadata Repository
Installing OracleAS Web Cache Separately from the Middle Tier
These tasks should be performed in the order they appear in on this list until you are satisfied that your configuration can handle the demands of your deployed Web portal. If your site must handle only a moderate workload, you could first separate the middle tier from the database, then consider moving Oracle Identity Management to another server. You probably will not need to perform all of these configuration tasks. But as the site grows, you should expand its underlying configuration by following the sequence shown in this list.
|
Note: Before you go online with your Web portal, it's a good idea to set up and test a small pilot system. This enables you to gather valuable configuration and tuning information based on real usage patterns, without affecting the users you plan to serve. |
The first thing you should consider when configuring a larger system is installing the middle tier separately, as shown in Figure 2-2.
Figure 2-2 Separating the Application Server Middle Tier from the Infrastructure
This frees the OracleAS Metadata Repository and the middle tier from having to compete for hardware resources, such as I/O, memory, and disk space. Installing them on separate computers also gives you more flexibility in performance tuning. This is important for sites that plan on storing a lot of content in the OracleAS Metadata Repository. Tuning parameters, such as those for an operating system, are different from those for middle-tier components such as the HTTP server. Setting a performance parameter for one may not provide optimal performance for another.
In 10g Release 2 (10.1.2), the Oracle Universal installer can install a new database seeded with the OracleAS Metadata Repository, or it can use an existing database (customer database). If you want to use an existing database, you need to run the new Oracle Application Server Metadata Repository Creation Assistant tool, available on the OracleAS Metadata Repository Creation Assistant CD-ROM, to populate the existing database with the OracleAS Metadata Repository. You do this before running the installer to install other Oracle Application Server components.
OracleAS Single Sign-On authenticates user credentials against Oracle Internet Directory for OracleAS Portal and other applications, thus requiring users to log on to the Web portal only once with a single user name and password, to enable access to multiple accounts and applications.
Once users have logged in to a deployed OracleAS Portal site, they can access any other OracleAS Single Sign-On secured application from portlets within the portal.
As shown in Figure 2-3, Oracle Identity Management is located on a different computer from the OracleAS Metadata Repository. A single instance of Oracle Identity Management can be configured to work with multiple Oracle products, including multiple instances of the OracleAS Portal middle tier.
Figure 2-3 Oracle Identity Management Installed on a Separate Computer
The system shown in Figure 2-3 is an example of a distributed configuration. The configuration includes a centralized Oracle Identity Management server that could support multiple middle-tier instances. Moving Oracle Identity Management to its own server gives you the flexibility to tune its performance independently of the database and middle tier.
In addition, isolating Oracle Identity Management from middle-tier installations ensures greater stability for the entire distributed system. If the computer where a middle tier is installed fails, OracleAS Single Sign-On and other middle-tier instances that rely on it to validate logins are not affected. Additionally, different security policies can be used to manage the various computers in the configuration.
|
See Also: Oracle Application Server Installation Guide |
You can add redundant middle-tier instances, each with identical configuration settings, to support the largest Web portals. The added middle-tier instances are shown in Figure 2-4. It is a good idea to install each middle-tier instance on its own computer to isolate any hardware failures.
The middle tier forwards user requests for portal pages to a provider, then assembles the pages with the returned content. As you add more middle-tier instances to your OracleAS Portal configuration, you increase the capacity for user requests and improve the overall performance of your portal. In addition, because the middle tier performs some processing before forwarding a request, less time is spent sending and receiving data over the network. Database and network resources are used more efficiently.
|
Note: For this configuration, you must use a Load Balancing Router (LBR). See Section 2.1.8.1, "Load Balancing" for more information. |
You can also separate the OracleAS Web Cache server from the middle tier to enable better caching of data, faster request times, and reduction in the load on the middle tier. This also improves the performance of OracleAS Portal.
A distributed OracleAS Portal configuration offers improved performance over a single computer configuration because you are making more software and hardware resources available to the Web portal. But there are other benefits. You can use additional servers and software to provide failover, thus ensuring system stability. And you can deal with wide fluctuations in the amount of work your Web portal is expected to perform over the course of a day using load balancing between multiple servers. Finally, you can add more servers to a distributed configuration to support more users, thus providing scalability.
If you anticipate a heavy volume of traffic on your Web portal, you can distribute the load across multiple servers, each with its own middle-tier instance. If one server is overloaded with too much traffic, a second server can handle the overflow.
Oracle Application Server provides its own load balancing capability by pooling server instances to service incoming requests. If one instance does not respond, then the request is forwarded to another instance. This ensures that content and applications are always available to users of your deployed site.
For very large sites, you can add a Load Balancing Router (LBR) to distribute incoming requests to the middle-tier servers, as shown in Figure 2-5. An LBR is a very fast network device that distributes network requests across a large number of servers. It provides users of your portal with a single published address, instead of them having to send each request to a particular middle-tier server.
Figure 2-5 Multiple Server Configuration Using a Load Balancing Router
See Section 5.3, "Configuring Multiple Middle Tiers with a Load Balancing Router" for more information on adding an LBR to distribute incoming requests to middle-tier servers.
As an example, the high traffic personal site, My.Oracle.com (MOC), uses an LBR to sort requests. Because the software logic for distributing loads is contained in the LBR itself rather than installed separately on each individual middle-tier server, an LBR lowers the overall administrative costs of your configuration. MOC is both an intranet and extranet Web site. It provides Oracle employees with a single customizable entry point to all of Oracle's online services as well business information from external providers.
Adding an LBR can also help your configuration deal with load variations. Users may access your site, use its applications, and request content at a much higher frequency during certain peak intervals, for example, between 9 AM and 10 AM when most users log on to begin their work day. During these periods of heavy traffic, the LBR can distribute page requests among the various middle-tier instances to ensure quick response times.
If your peak load occurs on a regular basis, consider a configuration that specifically addresses the need to handle peak load requirements. If your peak load is infrequent, you may be willing to tolerate slower response times at peak intervals rather than spend additional money on hardware.
Note that the LBR itself can be configured to support failover. The My.Oracle.com configuration in Figure 2-6 could add a second LBR, which would be available in case the primary router fails.
Failover is the ability to switch to a backup when part of your system fails, such as a server or database. When an Oracle Database 10g fails, for example, it restarts using any preserved state information from the backup.
Redundancy is the technique of providing duplicate computers configured identically. The redundant computers provide enough capacity to service requests, and provide backups in case of failures and errors. You implement redundancy by increasing the number of computers in your configuration. One server is typically active while the other monitors the first server's activity, ready to take over if it fails.
As shown in Figure 2-6, My Oracle.com provides for failover using an additional middle-tier server that can take over if any of the other servers encounter problems that cause them to fail.
|
Note: The components depicted in Figure 2-6 represent only one of many possible configurations. Oracle does not expressly recommend or endorse these specific vendors, or components, or both. |
Figure 2-6 My Oracle.com Middle-Tier Configuration
To set up redundant middle-tier instances, you configure the original and each redundant instance with identical server name and server port entries, for example, my.oracle.com and port 5000.
One alternative to redundancy is to set up failover by using any excess capacity that you have in your overall configuration. For example, you might have four middle-tier servers, each running at 75% capacity. If one server fails, the other three can take over the workload of the fourth (25% X 3 = 75%, which is the capacity of the failing server).
Scalability is the ability of a Web portal to handle more requests as the number of users and the volume of content increases over time. As the portal handles more traffic, users should not notice any change in performance, as measured by response intervals and frequency of errors. If scalability is your goal, you need a flexible configuration that will enable you to add database capacity and servers incrementally as needed without adversely affecting the rest of your configuration.
When My.Oracle.com (MOC) was set up, for example, it was initially expected to serve approximately 40,000 Oracle employees. The user base is anticipated to expand eventually to a million and a half, most of them users of the Oracle Technology Network (OTN), each automatically provided with an MOC account.
This section describes the task flow involved in planning, installing, configuring, and administering OracleAS Portal.
Successfully deploying OracleAS Portal consists of the following steps:
Upgrading OracleAS Portal (if necessary)
Performing Post-Installation Configuration (basic configuration and administration)
The following sections provide high-level descriptions of each step and point to more detailed information in various locations, including this configuration guide, other Oracle Application Server 10g Documentation Library books, technical white papers, and Oracle Technology Network, http://www.oracle.com/technology/.
If you are new to OracleAS Portal, you may benefit from reading Chapter 1, "Understanding the OracleAS Portal Architecture" to understand how OracleAS Portal fits into the Oracle Application Server architecture.
These white papers may also be helpful:
OracleAS Portal Architecture Overview
Planning Your OracleAS Portal Configuration
You can find these white papers on the Oracle Technology Network (OTN) at http://www.oracle.com/technology/.
You will find the latest information on upgrading from an earlier release of OracleAS Portal on Portal Center, http://portalcenter.oracle.com/upgrades. On the Upgrade page, you will find:
Instructions for downloading the upgrade scripts
Online documentation in the form of the OracleAS Portal - Upgrading the Database Repository Release 3.0.9 to 9.0.4, and OracleAS Portal - Upgrading the Database Repository Release 9.0.2 to 9.0.4 guides.
Links to related documentation, such as Database Migration guides and the Oracle Application Server Migration guides.
To ensure a smooth installation, you must verify that you have fulfilled all prerequisites and have performed all pre-installation steps. The Oracle Application Server Installation Guide contains the general Oracle Application Server requirements, while Chapter 3, "Installing OracleAS Portal" discusses the portal-specific steps.
The Oracle Application Server Installation Guide contains the steps for installing the Oracle Application Server middle tier and infrastructure required to run OracleAS Portal. Refer to Chapter 3, "Installing OracleAS Portal" for additional information.
Chapter 4, "Performing Basic Configuration and Administration" contains information about all the post-configuration tasks that can be performed by the OracleAS Portal administrator.
You will find additional information in the paper "Strategies for Administering Privileges in OracleAS Portal," on Oracle Technology Network, http://www.oracle.com/technology/.
Part III, "Advanced Configuration Topics" is targeted at the Oracle Application Server administrator. Chapter 5, "Performing Advanced Configuration" provides instructions on how to perform more advanced OracleAS Portal configuration and integration configuration, including virtual hosts, Load balancing routers, proxy server, OracleAS Web Cache, and OracleAS Single Sign-On configuration. Other chapters in the part deal with setting up Search, Import and Export, and more.
Chapter 6, "Securing OracleAS Portal" contains in-depth information on how to configure the security features in OracleAS Portal.
OracleAS Portal can be monitored through the Oracle Enterprise Manager 10g Application Server Control Console. Additionally there are performance reports that can be generated to monitor performance.
See Chapter 7, "Monitoring and Administering OracleAS Portal" for more information on monitoring OracleAS Portal.
You will find additional information on the following topics, on Oracle Technology Network, http://www.oracle.com/technology/.
The paper "Tuning Oracle Net Services to optimize mod_plsql Database access times"
|
Note: Portal Services leverage Oracle Net Services to connect to the OracleAS Portal schema in the OracleAS Metadata Repository. The tuning steps mentioned in this document are still applicable to OracleAS Portal. |
The paper "Object Access Reporting from the Performance Logs in Oracle9iAS Portal"
Appendix K, "Troubleshooting OracleAS Portal" discusses various issues and ways for resolving and diagnosing problems.
Refer to the book Oracle Application Server Portal Error Messages Guide, for more information on error messages.
