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 the Oracle Business Intelligence enterprise deployment.

This chapter includes the following topics:

Section 2.1, "Overview of Enterprise Deployment Reference Topologies"
Section 2.2, "Hardware Requirements for an Enterprise Deployment on Linux"
Section 2.3, "Identifying the Software Components to Install"
Section 2.4, "About LDAP as Credential and Policy Store"
Section 2.5, "Clock Synchronization"
Section 2.6, "Road Map for the Reference Topology Installation and Configuration"

2.1 Overview of Enterprise Deployment Reference Topologies

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

This section covers these topics:

Section 2.1.1, "Reference Topologies Documented in the Guide"
Section 2.1.2, "About Oracle Identity Management Integration"
Section 2.1.3, "About the Web Tier Nodes"
Section 2.1.4, "About the Application Tier"
Section 2.1.5, "About the Data Tier"
Section 2.1.6, "About the Unicast Requirement for Communication"

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 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 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, then 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 and 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, then 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 WebLogic Server, Oracle HTTP Server forwards the requests to WebLogic Server that is 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 that is 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 that protects the web tier, only the HTTP ports are open: 443 for HTTPS, and 80 for HTTP.

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 13.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, Oracle BI Scheduler, and Oracle Essbase Server 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, and the Oracle BI Presentation Services Plug-in (also called 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.

Starting with Release 11.1.1.7, Oracle BI Add-in for Microsoft Office is replaced by Oracle Hyperion Smart View for Office (Smart View) as a comprehensive tool for accessing and integrating Oracle Business Intelligence and Enterprise Performance Management content from Microsoft Office products. Smart View provides a common Microsoft Office interface designed for Oracle Business Intelligence and Oracle Enterprise Performance Management.

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 that the Oracle Business Intelligence components need. The Oracle Business Intelligence components that are running in the application tier access this database.

On the firewall that protects the data tier, the database listener port (typically, 1521) must be open. The LDAP ports (typically, 389 and 636) must also be open for the traffic that accesses 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 might 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 the enterprise deployment, review the Oracle Fusion Middleware System Requirements and Specifications document on the Oracle Technology Network (OTN) to ensure that the 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 that are 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, and 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

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

WEBHOSTn

10 GB

4 GB

Default

APPHOSTn

20 GB or more

8 GB

Default

2.3 Identifying the Software Components to Install

Table 2-2 lists the Oracle software that you must 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 About LDAP as Credential and Policy Store

With Oracle Fusion Middleware, you can use different types of credential and policy stores in a WebLogic domain. Domains can use stores based on XML files or on different types of LDAP providers. When a domain uses an LDAP store, all policy and credential data is kept and maintained in a centralized store. However, when using XML policy stores, the changes made on Managed Servers are not propagated to the Administration Server unless they use the same domain home.

The Oracle Business Intelligence enterprise deployment topology uses different domain homes for the Administration Server and the Managed Servers, as described in Section 4.3, "About Recommended Locations for the Different Directories." Derived from this, and for integrity and consistency purposes, Oracle requires the use of an LDAP store as the credential and policy store in the context of an Oracle Business Intelligence enterprise deployment. To configure the Oracle Business Intelligence enterprise deployment with an LDAP store as the credential and policy store, follow the steps in Section 12.1, "Configuring the Credential and Policy Store."

2.5 Clock Synchronization

The clocks of all servers that participate 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 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 the operating system documentation for more information.

2.6 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 the Network for the Enterprise Deployment	Understand concepts like virtual server names, IPs, and virtual IPS, and configure the load balancer by defining virtual host names.	Chapter 3, "Preparing the Network for an Enterprise Deployment"
Prepare the 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 the 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 if a failure occurs. The WLS_SOA2 managed server is configured to restart on SOAHOST1 if a failure occurs.	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 the Enterprise Deployment	Learn to start and stop Oracle Business Intelligence, monitor, scale, and patch the enterprise deployment, perform backups and recoveries, and review troubleshooting information.	Chapter 13, "Managing Enterprise Deployments"