Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Portal
11g Release 1 (11.1.1.6.0)

Part Number E12037-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Introduction to the Enterprise Deployment Reference Topology

This chapter provides an overview of the enterprise topology for Oracle WebCenter Portal. It contains the following sections:

2.1 Overview of Enterprise Deployment Reference Topology

This section describes the enterprise topology for WebCenter Portal. Use this section to plan your enterprise deployment topology.

This section covers these topics:

2.1.1 Reference Topology Documented in the Guide

This guide provides configuration instructions for a reference enterprise topology that uses Oracle WebCenter Portal with Oracle Access Manager, as shown in Figure 2-1.

Note:

Your actual enterprise deployment topology may require variations on the topology described in this guide.

Figure 2-1 MyWCPCompany Topology with Oracle Access Manager

MyWCCompany Topology with Oracle Access Manager

2.1.2 About Oracle Identity Management Integration

Integration with the Oracle Identity Management system is an important aspect of the enterprise deployment architecture. This integration provides features such as single sign-on, integration with Oracle Platform Security Services, centralized identity and credential store, and authentication for the WebLogic domain. The Oracle Identity Management (IDM) enterprise deployment is separate from this enterprise deployment and exists in a separate domain by itself. For more information on Oracle Identity Management in an enterprise deployment context, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

The primary interface to the Oracle Identity Management enterprise deployment is the LDAP traffic to the LDAP servers, the OAP (Oracle Access Protocol) to the OAM Access Servers, and the HTTP redirection of authentication requests.

2.1.3 About the Web Tier Nodes

Nodes in the web tier are located in the DMZ public zone.

In this tier, two nodes WEBHOST1 and WEBHOST2 run Oracle HTTP Server configured with WebGate and mod_wl_ohs.

Through mod_wl_ohs, which allows requests to be proxied from Oracle HTTP Server to WebLogic Server, Oracle HTTP Server forwards the requests to WebLogic Server running in the application tier.

WebGate (which is an Oracle Access Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager running on OAMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.

The web tier also includes a load balancer router to handle external requests. External requests are sent to the virtual host names configured on the load balancer. The load balancer then forwards the requests to Oracle HTTP Server.

The WebGate module in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as querying user groups.

On the firewall protecting the web tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.

2.1.3.1 Load Balancer Requirements

This enterprise topology uses an external load balancer. This external load balancer should have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration should be possible so that incoming requests on the virtual host name and port are directed to a different port on the backend servers.

  • Monitoring of ports on the servers in the pool to determine availability of a service.

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle HTTP Server in the web tier, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • Fault-tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the backend services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • Sticky routing capability: Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

  • The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP). Typically, this feature is called SSL acceleration and it is required for this Enterprise Deployment.

Note:

The load balancer is the entry point for all client requests through the externally facing URL. Although internal URLs are configured as well these are not intended for general use by clients but are for internal use. The WebCenter Portal enterprise deployment topology does not support an 'Inside/Outside' set up.

2.1.4 About the Application Tier

Nodes in the application tier are located in the DMZ secure zone.

In this tier, two nodes SOAHOST1 and SOAHOST2 run the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control, but in an active-passive configuration. You can fail over the Administration Server manually (see Section 8.6.6, "Manually Failing Over the Administration Server to SOAHOST2"); alternatively you can configure the Oracle WebLogic Server Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster (not shown in this architecture).

Oracle WebCenter Portal components run on WCPHOST1 and WCPHOST2 in an active-active configuration. Typically the managed servers are called WC_Spaces (for the Spaces application), WC_Portlet (for portlet and pagelet producers), WC_Collaboration (for Discussions), and WC_Utilities (for Analytics, Activity Graph, and Personalization). You can also create custom managed servers to run applications built using WebCenter Portal: Framework.

WCPHOST1 and WCPHOST2 also run Oracle WebCenter Content Server is configured in an active-active manner.

If you are also running SOA components in this topology, SOAHOST1 and SOAHOST2 run on WebLogic Server configured with the WLS_SOA and WLS_WSM managed servers, which run SOA components. These components are configured in an active-active manner.

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure Web services in the Enterprise Deployment topology. WSM Policy Manager also runs in active-active configuration in two additional WebLogic Servers.

On the firewall protecting the application tier, the HTTP ports, OAP port, and proxy port are open. The OAP port is for the WebGate module running in Oracle HTTP Server in the web tier to communicate with Oracle Access Manager. Applications requiring external HTTP access use Oracle HTTP Server as the proxy. (The proxy on the Oracle HTTP Server must be enabled to allow this access.)

2.1.5 About the Data Tier

Nodes in the data tier are located in the most secured network zone (the intranet).

In this tier, an Oracle RAC database runs on the nodes CUSTDBHOST1 and CUSTDBHOST2. The database contains the schemas needed by WebCenter Portal, WebCenter Content, and SOA Suite components. WebCenter Portal, WebCenter Content, and SOA components running in the application tier access this database.

On the firewall protecting the data tier, the database listener port (typically, 1521) is required to be open. The LDAP ports (typically, 389 and 636) are also required to be open for the traffic accessing the LDAP storage in the IDM Enterprise Deployment.

2.1.6 About the Unicast Requirement for Communication

Oracle recommends that the nodes in the MyWCPCompany topology communicate using unicast. Unlike multicast communication, unicast does not require cross-network configuration and it reduces potential network errors that can occur from multicast address conflicts as well.

In unicast messaging mode, the default listening port of the server is used if no channel is configured.

Cluster members communicate to the group leader when they need to send a broadcast message which is usually the heartbeat message. When the cluster members detect the failure of a group leader, the next oldest member becomes the group leader.

The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing between multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes (from unicast to multicast or from multicast to unicast).

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.)

2.2 Hardware Requirements for an Enterprise Deployment on Linux

Before you install and configure your enterprise deployment, review the Oracle Fusion Middleware System Requirements and Specifications on the Oracle Technology Network (OTN) to ensure that your environment meets the minimum installation requirements for the products you are installing.

In addition, Table 2-1 lists the typical hardware requirements for the enterprise deployment described in this guide on Linux operating systems.

You must perform the appropriate capacity planning to determine the number of nodes, CPU, and memory requirements for each node depending on the specific system's load, as well as the throughput and response requirements. These will vary for each WebCenter Portal application or custom SOA system being used.

Table 2-1 Typical Hardware Requirements

Server Disk Memory TMP Directory Swap

Database

nXm

n = number of disks, at least 4 (striped as one disk)

m = size of the disk (minimum of 30 GB)

6-8 GB

Default

Default

WEBHOSTn

10 GB

4 GB

Default

Default

SOAHOSTn

10 GBFoot 1 

10 GB

Default

Default

WCPHOSTn

10 GB

10 GB

Default

Default


Footnote 1 For a shared storage Middleware home configuration, two installations suffice by making a total of 20 GB independently of the number of slots. See also, Section 4.4, "Configuring Shared Storage".

2.3 Clock Synchronization

The clocks of all servers participating in the cluster must be synchronized to within one second difference to enable proper functioning of jobs, adapters, and Oracle B2B. To accomplish this, use a single network time server and then point each server to that network time server.

The procedure for pointing to the network time server is different on different operating systems. Refer to your operating system documentation for more information.

2.4 Identifying the Software Components to Install

Table 2-2 lists the Oracle software you will need to obtain before starting the procedures in this guide.

For complete information about downloading Oracle Fusion Middleware software, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on the Oracle Technology Network (OTN).

See also, Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

Table 2-2 Components and Installation Sources

Component Distribution Medium

Oracle Database 10g or 11g

Oracle Database 10g distribution (10.2.0.4 or later SE or EE version of the database) using the AL32UTF8 character set.

Oracle Database Server 11g distribution (11.1.0.7 or later SE or EE version of the database), using the AL32UTF8 character set.

Repository Creation Utility (RCU)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.6) distribution

Oracle WebLogic Server (WLS)

Oracle WebLogic Server (10.3.6) distribution

Oracle HTTP Server (OHS)

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.6) distribution

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.6) distribution

Oracle WebCenter Portal

Oracle WebCenter Portal 11g (11.1.1.6) distribution

Oracle WebCenter Content

Oracle WebCenter Content 11g (11.1.1.6) distribution

Oracle Access Manager (OAM) WebGate

WebGate 10g (10.1.4.3) for OAM 10g or WebGate 11g (11.1.1.3) for OAM 11g.

Oracle Virtual Directory (OVD)

Oracle Identity and Access Management 11g (11.1.1.5) distribution

Oracle Internet Directory (OID)

Oracle Identity and Access Management 11g (11.1.1.5) distribution


2.5 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle WebCenter Portal enterprise deployment, review the flow chart in Figure 2-2. This flow chart illustrates the high-level process for completing the enterprise deployment documented in this guide. Table 2-3 describes the steps in the flow chart and directs you to the appropriate section or chapter for each step.

This section covers the following topics:

2.5.1 Flow Chart of the Oracle WebCenter Portal Enterprise Deployment Process

Figure 2-2 provides a flow chart of the Oracle WebCenter Portal enterprise deployment process. Review this chart to become familiar with the steps that you must follow, based on the existing environment.

Figure 2-2 Flow Chart of the Oracle WebCenter Portal Enterprise Deployment Process

Description of Figure 2-2 follows
Description of "Figure 2-2 Flow Chart of the Oracle WebCenter Portal Enterprise Deployment Process"

2.5.2 Steps in the Oracle WebCenter Portal Enterprise Deployment Process

Table 2-3 describes each of the steps in the enterprise deployment process flow chart for Oracle WebCenter Portal, shown in Figure 2-2. The table also provides information on where to obtain more information on each step in the process.

Table 2-3 Steps in the Oracle WebCenter Portal Enterprise Deployment Process

Step Description More Information

Prepare your network for enterprise deployment

To prepare your network for an enterprise deployment, understand concepts, such as virtual server names and IPs and virtual IPS, and configure your load balancer by defining virtual host names.

Chapter 3, "Preparing the Network for an Enterprise Deployment"

Prepare your file system for enterprise deployment

To prepare your file system for an enterprise deployment, review the terminology for directories and directory environment variables, and configure shared storage.

Chapter 4, "Preparing the File System for an Enterprise Deployment"

Prepare your database for enterprise deployment

To prepare your database for an enterprise deployment, review database requirements, create database services, load the metadata repository in the Oracle RAC database, configure SOA, WCP, and WCC schemas for transactional recovery privileges, and back up the database.

Chapter 5, "Preparing the Database for an Enterprise Deployment"

Install the software

Install Oracle HTTP Server, Oracle WebLogic Server, Oracle Fusion Middleware, and apply patchsets to Oracle Fusion Middleware components.

Chapter 6, "Installing the Software for an Enterprise Deployment"

Configure the web tier

Configure the Oracle web tier by associating the Oracle web tier with the Oracle WebLogic Domain, Configuring Oracle HTTP Server with the load balancer, and configuring virtual host names.

Chapter 7, "Configuring the Web Tier for an Enterprise Deployment"

Create a domain

Run the Configuration Wizard to create a domain.

Chapter 8, "Creating a Domain for an Enterprise Deployment"

Extend the domain for SOA

Extend the existing WebLogic domain by running the Configuration Wizard to configure Oracle SOA components.

Chapter 9, "Extending the Domain for SOA Components"

Extend the domain for WebCenter Portal

Extend the existing WebLogic domain by running the Configuration Wizard and configure Oracle WebCenter Portal.

Chapter 10, "Extending the Domain for WebCenter Portal Components"

Set up Node Manager

Set up Node manager by enabling host name verification, starting Node Manager, and configuring WebLogic Servers to use custom keystores.

Chapter 11, "Setting Up Node Manager for an Enterprise Deployment"

Configure external WebCenter Portal services

Set up and configure external services for WebCenter Portal applications such as discussions, mail, search, and so on.

Chapter 12, "Configuring External WebCenter Portal Services for an Enterprise Deployment"

Extend the domain for WebCenter Content

Extend the existing WebLogic domain by running the Configuration Wizard and configure Content Server and Inbound Refinery.

Chapter 13, "Extending the Domain to Include Oracle WebCenter Content"

Configure Server Migration

Configure server migration for the WLS_SOA1 and WLS_SOA2 managed servers. The WLS_SOA1 managed server is configured to restart on SOAHOST2 should a failure occur. The WLS_SOA2 managed server is configured to restart on SOAHOST1 should a failure occur.

Chapter 14, "Configuring Server Migration for an Enterprise Deployment"

Integrate with Identity Management

You can integrate your Oracle SOA enterprise deployment with Oracle Identity Management 10g or 11g.

Chapter 15, "Integrating an Enterprise Deployment with Oracle Identity Management"


2.5.3 Understanding the Incremental, Modular Approach to Enterprise Deployment

By design, this document describes an incremental and modular approach to setting up an enterprise deployment.

The instructions for setting up the storage, database, networking, and web tier infrastructure are similar to the instructions provided in the other Oracle Fusion Middleware Enterprise Deployment Guides. These elements of the topology provide the foundation for the Oracle WebLogic Server domain you later configure to support the enterprise deployment.

When you create the domain, the instructions vary from guide to guide. However, all the Enterprise Deployment Guides provide separate, modular instructions for creating and extending an Oracle WebLogic Server domain, as follows:

  1. Install the Oracle Fusion Middleware software on disk and create the necessary binary directories.

  2. Run the Oracle Fusion Middleware Configuration Wizard to create the domain and configure only the administration components.

    The administration components include the Administration Server, Oracle WebLogic Server Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Web Services Manager.

  3. Run the Configuration Wizard again to extend the domain to include the primary Oracle Fusion Middleware product you want to use.

  4. Optionally, run the Configuration Wizard again to extend the domain to include other supporting components and products.

This incremental approach allows you to verify the environment after each pass of the Configuration Wizard. It also simplifies troubleshooting during the setup process.

In addition, this modular approach allows you to consider alternative topologies. Specifically, after you configure the Administration components, the domain you create does not need to contain all the components described in this guide. Instead, you can use the domain extension chapters independently and selectively, to configure individual components that are required for your specific organization.