2 Planning Your Oracle Portal

This chapter details the task flow involved in planning, installing, configuring, and administering Oracle 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:

• What Do I Need to Consider?

• What Do I Need to Do?

Note: You may want to review Chapter 1, "Understanding the Oracle Portal Architecture" if you are unfamiliar with the terms used in this chapter.

2.1 What Do I Need to Consider?

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:

• Which Topology Is Right for Me?

• How Much Hardware Do I Need?

• How Can I Maximize Performance?

• How Can I Make My Portal Scale?

• How Can I Make My Portal Highly Available?

• How Can I Secure My Portal?

• How Should I Configure My Hardware and Software?

• Getting the Most Out of Your Configuration

2.1.1 Which Topology Is Right for Me?

Oracle Fusion Middleware offers a variety of topology options. The Oracle Fusion Middleware recommended topologies range from small general development implementations to very large enterprise-wide implementations.

See Also: Overview of the recommended topologies in the Oracle Fusion Middleware Concepts guide. High Availability for WebLogic Server.

2.1.2 How Much Hardware Do I Need?

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. If the primary function of the Portal is integration, then the majority of load will generally be on the Middle tier. If, on the other hand, the Portal is content driven with significant amounts of customization, then the balance shifts to the repository/infrastructure.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 Oracle 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.

See Also: Oracle Fusion Middleware Administrator's Guide

2.1.3 How Can I Maximize Performance?

Response time is the elapsed time between when a user request is issued and when the response to that request has been completed. 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 Oracle Portal configuration offers improved availability 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 Oracle Portal" for more information.

  
  

  See Also: Oracle Fusion Middleware Performance and Tuning Guide

  
  

• Choosing optimal cache options for pages, portlet instances, and templates

  Caching is the primary way to maximize performance in Oracle Portal. Using a distributed architecture will increase system availability and speed, but cache methodology is by far the most important. To improve performance and scalability, Oracle Portal provides several caching options as described in the chapter on improving page performance in the Oracle Fusion Middleware User's Guide for Oracle Portal.

2.1.4 How Can I Make My Portal Scale?

Redundancy enables you to scale your system by providing identically configured duplicate computers to provide enough capacity to service requests, and provide backups in case of failures and errors.

In addition, you can improve scalability by choosing optimal cache options for pages, portlet instances, and templates. Oracle Portal provides several caching options. For more information, refer to the chapter about improving page performance in the Oracle Fusion Middleware User's Guide for Oracle Portal.

Refer to Section 2.1.8.3, "Scalability" and Section 1.3, "Understanding Caching in Oracle Portal" for more information.

2.1.5 How Can I Make My Portal Highly Available?

Clustering also enables you to achieve a higher level of system availability than is possible with only a single Oracle Fusion Middleware instance. An application running on a single instance of an Oracle Fusion Middleware 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.

See Also: Oracle Fusion Middleware High Availability Guide

2.1.6 How Can I Secure My Portal?

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, Oracle Portal leverages other components of Oracle Fusion Middleware and Oracle Database 11g to provide strong protection for your portal. Oracle 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 Web Cache

• Oracle Internet Directory

• Oracle Delegated Administration Services

• Oracle Directory Integration Platform

See Chapter 7, "Securing Oracle Portal" for more information.

2.1.7 How Should I Configure My Hardware and Software?

This section discusses how you should configure your hardware and software installations for optimal use of Oracle Portal and all related Oracle Fusion Middleware components. This section explains how you can configure your hardware to set up a small development environment, and deploy larger sites serving many users.

2.1.7.1 Using a Single Computer

In the simplest configuration, all of the Oracle Fusion Middleware component pieces 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 Oracle Portal, Oracle Internet Directory, and OracleAS Single Sign-On.

Figure 2-1 Oracle Portal Single Computer Configuration

Description of "Figure 2-1 Oracle Portal Single Computer Configuration"

This configuration works nicely in a small development environment in which your developers are using Oracle 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.

2.1.7.2 Using Multiple Computers

If a single computer configuration does not suit your needs, consider moving the various pieces of the Oracle Portal architecture to other computers. When configuring your Web portal, you will require more servers depending on the size of your site, where each server performs specialized work. Adding extra hardware increases performance, and adding more software instances supports redundancy.

Deployment options for configuring larger Web portal sites include:

• Separating the Middle Tier from the Oracle Metadata Repository

• Installing Oracle Identity Management Separately

• Adding Middle-Tier Instances

• Installing Oracle Web Cache Separately from the Middle Tier

• Configuring High Availability for the Infrastructure

Perform the tasks in 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.

2.1.7.2.1 Separating the Middle Tier from the Oracle Metadata Repository

The first thing you should consider when configuring a larger system is installing the middle tier separately, as shown in Figure 2-2.

See Also: Oracle Fusion Middleware Performance and Tuning Guide

Figure 2-2 Separating the Fusion Middleware Middle Tier from the Infrastructure

Description of "Figure 2-2 Separating the Fusion Middleware Middle Tier from the Infrastructure"

This frees the Oracle 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 Oracle 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.

2.1.7.2.2 Installing Oracle Identity Management Separately

OracleAS Single Sign-On authenticates user credentials against Oracle Internet Directory for Oracle 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 Oracle Portal site, they can access any other OracleAS Single Sign-On secured application.

As shown in Figure 2-3, Oracle Identity Management is located on a different computer from the Oracle Metadata Repository. A single instance of Oracle Identity Management can be configured to work with multiple Oracle products, including multiple instances of the Oracle Portal middle tier.

Figure 2-3 Oracle Identity Management Installed on a Separate Computer

Description of "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 Fusion Middleware Installation Planning Guide

2.1.7.2.3 Adding Middle-Tier Instances

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.

Figure 2-4 Multiple Middle Tiers

Description of "Figure 2-4 Multiple Middle Tiers"

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 Oracle Portal configuration, you increase the capacity for user requests and improve the overall performance of your portal. 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.

2.1.7.2.4 Installing Oracle Web Cache Separately from the Middle Tier

You can also separate the Oracle 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.

Separating the Web Cache can improve performance by making it easier to tune the system, since it is memory intensive rather than CPU intensive. Separating the components can also bring cached data closer to the end user, effectively increasing security by limiting what content is cached "at the network edge" for a given user community. For example, in a typical inside/outside scenario, separate Web Caches can target the community with specific cached content.

2.1.7.2.5 Configuring High Availability for the Infrastructure

In Oracle Fusion Middleware 11g, all Oracle High Availability (HA) solutions, including Cold Failover Cluster, Data Guard, and Real Application Clusters (RAC), are supported for the OracleAS Infrastructure.

See Also: Oracle Fusion Middleware High Availability Guide

2.1.8 Getting the Most Out of Your Configuration

A distributed Oracle 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.

2.1.8.1 Load Balancing

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 Fusion Middleware 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 load balancing hardware or software to distribute incoming requests to the middle-tier servers. Figure 2-5 shows a Load Balancing Router (LBR), a very fast network device that distributes network requests across a large number of servers, being used for this purpose. This is the most common approach to load balancing, and 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

Description of "Figure 2-5 Multiple Server Configuration Using a Load Balancing Router"

See Section 6.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 a.m. and 10 a.m. 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.

2.1.8.2 Failover and Redundancy

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 11g 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

Description of "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 site name and server port entries, for example, my.oracle.com and port 5000. That is, although the pysical site names and ports can be different, the virtual host references for the redundant tiers must be the same.

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).

2.1.8.3 Scalability

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.

2.2 What Do I Need to Do?

This section describes the task flow involved in planning, installing, configuring, and administering Oracle Portal.

Successfully deploying Oracle Portal consists of the following steps:

1. Planning Your Portal

2. Upgrading Oracle Portal (if necessary)

3. Verifying Pre-Installation Requirements

4. Installing Oracle Fusion Middleware

5. Performing Post-Installation Configuration (basic configuration and administration)

6. Performing Advanced Configuration

7. Securing Oracle Portal

8. Monitoring Oracle Portal

9. Troubleshooting Oracle Portal

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 Fusion Middleware 11g Documentation Library books, technical white papers, and OTN, http://www.oracle.com/technology/.

2.2.1 Planning Your Portal

If you are new to Oracle Portal, you may benefit from reading Chapter 1, "Understanding the Oracle Portal Architecture" to understand how Oracle Portal fits into the Oracle Fusion Middleware architecture.

You can find more information about planning your Oracle Portal configuration on Portal Center at http://www.oracle.com/technology/products/ias/portal/index.html.

2.2.2 Upgrading Oracle Portal

You will find the latest information on upgrading from an earlier release of Oracle Portal on OTN, http://www.oracle.com/technology/products/ias/portal/upgrade.html. On the Upgrade page, you will find:

• Instructions for downloading the upgrade scripts.

• Online upgrade documentation.

2.2.3 Verifying Pre-Installation Requirements

To ensure a smooth installation, you must verify that you have fulfilled all prerequisites and have performed all pre-installation steps. The Oracle Fusion Middleware Installation Planning Guide contains the general Oracle Fusion Middleware requirements, while Chapter 3, "Pre-Installation and Post-Installation Tasks" discusses the portal-specific steps.

2.2.4 Installing Oracle Fusion Middleware

The Oracle Fusion Middleware Installation Planning Guide contains the steps for installing the Oracle Fusion Middleware middle tier and infrastructure required to run Oracle Portal. Refer to Chapter 3, "Pre-Installation and Post-Installation Tasks" for additional information.

2.2.5 Performing Post-Installation Configuration

Chapter 5, "Basic Configuration and Administration" contains information about all the post-configuration tasks that can be performed by the Oracle Portal administrator.

You can find additional information on Portal Center at, http://www.oracle.com/technology/products/ias/portal/index.html.

2.2.6 Performing Advanced Configuration

Part III, "Advanced Configuration Topics" is targeted at the Oracle Fusion Middleware administrator. Chapter 6, "Advanced Configuration" provides instructions on how to perform more advanced Oracle Portal configuration and integration configuration, including virtual hosts, load balancing routers, proxy server, Oracle Web Cache, and OracleAS Single Sign-On configuration. Other chapters in Part III deal with setting up features such as search, import and export, and more.

2.2.7 Securing Oracle Portal

Chapter 7, "Securing Oracle Portal" contains in-depth information on how to configure the security features in Oracle Portal.

2.2.8 Monitoring Oracle Portal

You can monitor Oracle Portal through the Oracle Enterprise Manager 11g Fusion Middleware Control. For details, see Chapter 8, "Monitoring and Administering Oracle Portal".

In addition, you can generate performance reports to monitor portal performance. See Section 10.5, "Generating Performance Reports". This performance information will be useful later on, for tuning Oracle Portal performance. See Chapter 10, "Tuning Performance in Oracle Portal".

2.2.9 Troubleshooting Oracle Portal

Appendix G, "Troubleshooting Oracle Portal" discusses various issues and ways for resolving and diagnosing problems.