Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence
11g Release 1 (11.1.1)

Part Number E15722-05
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 describes and illustrates the enterprise deployment reference topology described in this guide. Use this chapter to help you plan your Oracle Business Intelligence enterprise deployment.

This chapter includes the following topics:

2.1 Overview of Enterprise Deployment Reference Topologies

The instructions and diagrams in this document describe a reference topology, to which variations may be applied. Use this section to plan your enterprise deployment topology.

This section covers these topics:

2.1.1 Reference Topologies Documented in the Guide

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

Figure 2-1 MyBICompany Topology with Oracle Access Manager

Description of Figure 2-1 follows
Description of "Figure 2-1 MyBICompany 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 IDM (Identity Management) 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 the 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.

The following is a list of benefits provided by using Oracle HTTP Server as an intermediate point between the load balancer and the different WebLogic Servers:

  • It provides a sacrificial area/DMZ. This is a common requirement in security audits and is a major problem with load balancer/WebLogic systems. If a load balancer routes directly to the WebLogic Server, requests move from the load balancer to the application tier in one single HTTP jump, causing security concerns.

  • It allows the WebLogic Server cluster membership to be reconfigured (new servers added, others removed) without having to change the Web server configuration (as long as at least some of the servers in the configured list remain alive). The plug-in learns about the cluster membership and directs work accordingly.

  • Faster fail-over in the event of WebLogic Server instance failure. The plug-in actively learns about the failed WebLogic Server instance using information supplied by its peers. It avoids the failed server until the peers notify the plug-in that it is again available. Load balancers are typically more limited.

  • Oracle HTTP Server delivers static content more efficiently and faster than WebLogic Server.

  • HTTP redirection over and above what WebLogic Server provides. You can use Oracle HTTP Server as a front end against many different WebLogic Server clusters, and perhaps do content-based routing.

  • If SSO is required, only Oracle HTTP Server (not WebLogic Server) supports Oracle Identity Management.

Through mod_wl_ohs, which allows requests to be proxied from Oracle HTTP Server to Oracle WebLogic Server, Oracle HTTP Server forwards the requests to Oracle 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

    This feature is necessary so that incoming requests on the virtual host name and port are directed to a different port on the back-end servers.

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

  • Ability to configure virtual server names and ports

    Note 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 multiple ports. For example, for Oracle HTTP Server in the Web tier, the load balancer must 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.

  • Ability to configure the virtual server to return immediately to the calling client

    It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end 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 computer.

  • Sticky routing capability

    Sticky routing capability is the ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

  • SSL acceleration

    The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the back-end 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 EDG.

2.1.4 About the Application Tier

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

In this tier, APPHOST1 and APPHOST2 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.5, "Manually Failing Over the Administration Server to APPHOST2"); alternatively, you can configure the Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster (not shown in this architecture).

The Oracle Business Intelligence Cluster Controller and Oracle BI Scheduler system components run on APPHOST1 and APPHOST2 in an active-passive configuration. The other Oracle Business Intelligence system components, Oracle BI Server, Oracle BI JavaHost, and Oracle BI Presentation Services, run on APPHOST1 and APPHOST2 in an active-active configuration. All system components are managed by OPMN and do not run in the Managed Servers.

The Oracle Business Intelligence Java components, including Oracle Real-Time Decisions, Oracle BI Publisher, Oracle BI for Microsoft Office, and the Oracle BI Enterprise Edition Analytics application, run in the two Managed Servers on APPHOST1 and APPHOST2. Oracle Web Services Manager (Oracle WSM) is another Java component that provides a policy framework to manage and secure Web services in the EDG topology. WSM Policy Manager runs in active-active configuration in the two Managed Servers in APPHOST1 and APPHOST2.

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 the Oracle Business Intelligence components. The Oracle Business Intelligence 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 EDG.

2.1.6 About the Unicast Requirement for Communication

Oracle recommends that the nodes in the MyBICompany 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 must 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 document 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.

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

APPHOSTn

20 GB or more

8 GB

Default

Default


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

Table 2-2 Components and Installation Sources

Component Details

Oracle Database 10g or 11g

Oracle Database (in 10g series, 10.2.0.4 or higher; in 11g series, 11.1.0.7 or higher)

Repository Creation Utility (RCU)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.1.0)

Oracle WebLogic Server (WLS)

Oracle Weblogic Server (10.3.6)

Oracle HTTP Server

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.5.0)

Oracle Business Intelligence

Oracle Business Intelligence Enterprise Edition 11g (11.1.1.6.0)

and

Oracle Business Intelligence Enterprise Edition 11g (11.1.1.6.2) patch

Oracle Access Manager 10g Webgate

or

Oracle Access Manager 11g Webgate

Oracle Access Manager 10g Webgates (10.1.4.3.0); OAM OHS 11g Webgates per platform

Oracle Access Manager 11g Webgates (11.1.1.5.0); OAM OHS 11g Webgates per platform

Oracle Virtual Directory (OVD)

Oracle Identity Management 11g (11.1.1.5.0)


2.4 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 and adapters. 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.5 Road Map for the Reference Topology Installation and Configuration

Table 2-3 describes each of the steps in the enterprise deployment process for Oracle Business Intelligence. The table also provides information on where to obtain more information on each step in the process.

Table 2-3 Steps in the Oracle Business Intelligence Enterprise Deployment Process

Step Description More Information

Prepare your Network for the Enterprise Deployment

Understand concepts like virtual server names, 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 the 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 the Enterprise Deployment

Review database requirements, create database services, load the Oracle Business Intelligence schemas in the Oracle RAC database, and back up the database.

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

Install the Software for the Enterprise Deployment

Install Oracle HTTP Server, Oracle WebLogic Server, and Oracle Fusion Middleware.

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

Configure the Web Tier for the Enterprise Deployment

Associate the Oracle Web tier with the Oracle WebLogic Domain, configure the load balancer, and configure virtual host names.

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

Create a Domain with the Administration Server and First Managed Server

Run the Oracle Business Intelligence Configuration Assistant to create a domain and perform post-configuration and verification tasks.

Chapter 8, "Creating a Domain with the Administration Server and First Managed Server"

Scale Out the Oracle Business Intelligence System

Extend the domain by scaling out Oracle Business Intelligence on APPHOST2, including scaling the BI system, scaling system components, configuring secondary instances of singleton system components, and performing additional high availability configuration.

Chapter 9, "Scaling Out the Oracle Business Intelligence System"

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 10, "Setting Up Node Manager for an Enterprise Deployment"

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 11, "Configuring Server Migration for an Enterprise Deployment"

Integrate with Oracle Identity Management

Configure the credential and policy store, integrate with Oracle Access Manager 10g or 11g, and back up the Identity Management configuration.

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

Manage your Enterprise Deployment

Learn to start and stop Oracle Business Intelligence, monitor, scale, and patch your enterprise deployment, perform backups and recoveries, and review troubleshooting information.

Chapter 13, "Managing Enterprise Deployments"