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 Master Index
Master Index
Go to Feedback page
Contact Us

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

3 Preparing the Network for an Enterprise Deployment

This chapter describes the network environment preconfiguration required by the Oracle Business Intelligence enterprise topology. Use this chapter to plan your configuration of virtual server names, load balancers, IPs and Virtual IPs, and firewalls and ports.

This chapter includes the following topics:

3.1 Overview of Preparing the Network for an Enterprise Deployment

You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

You must ensure that every computer where you plan to run Oracle Business Intelligence can access (ping) the primary host computer of your cluster using its fully qualified domain name. For the installation to succeed, every computer on which you scale out your installation must be able to support bidirectional communication with the Administration Server on the cluster's primary host.

3.2 About Virtual Server Names Used by the Topology

The BI enterprise topology uses the following virtual server names:

Ensure that the virtual server names are associated with IP addresses and are part of your DNS. The nodes running Oracle Fusion Middleware must be able to resolve these virtual server names.

In addition, the virtual IP addresses must be on the same subnet as the physical host IP addresses.

You will define the virtual server names on the load balancer using the procedure in Section 3.3, "Configuring the Load Balancer."

3.2.1 bi.mycompany.com

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the run-time Oracle BI components. Traffic to SSL is configured. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

3.2.2 admin.mycompany.com

admin.mycompany.com is a virtual server name that acts as the access point for all internal HTTP traffic that is directed to administration services such as Oracle WebLogic Administration Server Console and Oracle Enterprise Manager.

The incoming traffic from clients is not SSL-enabled. Clients access this service using the address admin.mycompany.com:80 and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2. This virtual server is defined on the load balancer.

3.2.3 biinternal.mycompany.com

biinternal.mycompany.com is a virtual server name used for internal invocation of BI services. This URL is not exposed to the internet and is only accessible from the intranet.

The incoming traffic from clients is not SSL-enabled. Clients access this service using the address biinternal.mycompany.com:80 and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2. This virtual server is defined on the load balancer.

3.3 Configuring the Load Balancer

This enterprise topology uses an external load balancer. Configure the load balancer by defining the virtual server names described in Section 3.2, "About Virtual Server Names Used by the Topology."

The procedure described in this section contains high-level steps. The actual steps you will perform vary depending on the type of load balancer you use. For detailed instructions, consult the documentation for your load balancer.

For more information on load balancers, see Section 2.1.3, "About the Web Tier Nodes."

Note:

For more information on validated load balancers and their configuration, see the following page on the Oracle Technology Network at:

http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html

To configure the load balancer by defining the virtual server names:

  1. Create a pool of servers. You will assign this pool to virtual servers.

  2. Add the addresses of the Oracle HTTP Server hosts to the pool. For example:

    • WEBHOST1:7777

    • WEBHOST2:7777

  3. Configure a virtual server in the load balancer for bi.mycompany.com:443 and define the following rules for this virtual server:

    • For this virtual server, use your system's frontend address as the virtual server address (for example, bi.mycompany.com). The frontend address is the externally facing host name used by your system that will be exposed in the Internet.

    • Configure this virtual server with port 80 and port 443. Any request that goes to port 80 (non-ssl protocol) should be redirected to port 443 (ssl protocol).

    • Specify HTTP as the protocol.

    • Enable address and port translation.

    • Enable reset of connections when services and/or nodes are down.

    • Assign the pool created in step 1 to the virtual server.

    • Create rules to filter out access to /console and /em on this virtual server.

  4. Configure a virtual server in the load balancer for admin.mycompany.com:80 and define the following rules for this virtual server:

    • For this virtual server, use your internal administration address as the virtual server address (for example, admin.mycompany.com). This address is typically not externalized.

    • Specify HTTP as the protocol.

    • Enable address and port translation.

    • Enable reset of connections when services and/or nodes are down.

    • Optionally, create rules to allow access only to /console and /em on this virtual server.

    • Assign the pool created in step 1 to the virtual server.

  5. Configure a virtual server in the load balancer for biinternal.mycompany.com:80 and define the following rules for this virtual server:

    • For this virtual server, use your internal administration address as the virtual server address (for example, biinternal.mycompany.com). This address is typically not externalized.

    • Specify HTTP as the protocol.

    • Enable address and port translation.

    • Enable reset of connections when services and/or nodes are down.

    • Assign the pool created in step 1 to the virtual server.

    • Optionally, create rules to filter out access to /console and /em on this virtual server.

  6. Configure monitors for the Oracle HTTP Server nodes to detect failures in these nodes:

    • Set up a monitor to regularly ping the "/" URL context.

      Tip:

      Use GET /\n\n instead if the Oracle HTTP Server's document root does not include index.htm and Oracle WebLogic Server returns a 404 error for "/".

    • For the ping interval, specify a value that does not overload your system. You can try 5 seconds as a starting point.

    • For the timeout period, specify a value that can account for the longest response time that you can expect from your BI system, that is, specify a value greater than the longest period of time any of your requests to HTTP servers can take.

After you configure the virtual host in Section 7.5, "Configuring Virtual Hosts," you should be able to access the virtual host name addresses. If you cannot access them, review this procedure to ensure that it was completed correctly.

3.4 About IPs and Virtual IPs

Table 3-1 describes the various virtual hosts.

Table 3-1 Virtual Hosts

Virtual IP VIP Maps to... Description

VIP1

ADMINVHN

ADMINVHN is the virtual host name that is the listen address for the Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running (APPHOST1 by default).

VIP2

APPHOST1VHN1

APPHOST1VHN1 is the virtual host name that maps to the listen address for bi_server1 and fails over with server migration of this Managed Server. It is enabled on the node where the bi_server1 process is running (APPHOST1 by default).

VIP3

APPHOST2VHN1

APPHOST2VHN1 is the virtual host name that maps to the listen address for bi_server2 and fails over with server migration of this Managed Server. It is enabled on the node where the bi_server2 process is running (APPHOST2 by default).


3.4.1 Enabling Virtual IPs for the Managed Servers

The BI domain uses virtual host names as the listen addresses for the Oracle Business Intelligence Managed Servers. You must enable the VIPs, mapping each of these host names on the two BI computers (VIP2 on APPHOST1 and VIP3 on APPHOST2), and they must correctly resolve to the virtual host names in the network system used by the topology (either by DNS Server or hosts resolution).

Before the Managed Servers can be configured to listen on a virtual IP Address, one of the network interface cards on the host running the Managed Server must be configured to listen on this virtual IP Address.

Perform the following steps once on each host to enable the appropriate virtual IP Address (VIP2 on APPHOST1 and VIP3 on APPHOST2). In an UNIX environment, the command must be run as the root user:

  1. On the appropriate host (APPHOST1 or APPHOST2), run the ifconfig command to get the value of the netmask. In a UNIX environment, run this command as the root user. For example, on APPHOST1:

    [root@APPHOST1 ~] # /sbin/ifconfig
    eth0     Link encap:Ethernet  HWaddr 00:11:43:D7:5B:06
         inet addr:139.185.140.51  Bcast:139.185.140.255  Mask:255.255.255.0
         inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
         TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:4036851474 (3.7 GiB)  TX bytes:2770209798 (2.5 GiB)
         Base address:0xecc0 Memory:dfae0000-dfb00000
    
  2. Bind the virtual IP Address to the network interface card using ifconfig. In a UNIX environment, run this command as the root user. Use a netmask value that was obtained in Step 1.

    The syntax and usage for the ifconfig command is as follows:

    /sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
    

    For example:

    /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
    
  3. Update the routing table using arping. In a UNIX environment, run this command as the root user.

    /sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
    

    For example:

    /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
    

See also Section 8.3.4.1, "Enabling ADMINVHN on APPHOST1" for information about enabling VIP1 for the Administration Server on APPHOST1.

3.5 About Firewalls and Ports

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and ensure that the same port number is not used by two services on a host.

Most port numbers are assigned during installation.

Table 3-2 lists the ports used in the Oracle Business Intelligence topology, including the ports that you must open on the firewalls in the topology.

Firewall notation:

Table 3-2 Ports Used

Type Firewall Port and Port Range Protocol / Application Inbound / Outbound Other Considerations and Timeout Guidelines

Browser request

FW0

80

HTTP / Load Balancer

Inbound

Timeout depends on all HTML content and the type of process model used for BI.

Browser request

FW0

443

HTTPS / Load Balancer

Inbound

Timeout depends on all HTML content and the type of process model used for BI.

Load balancer to Oracle HTTP Server

n/a

7777

HTTP

n/a

See Section 3.3, "Configuring the Load Balancer."

Oracle HTTP Server registration with Administration Server

FW1

7001

HTTP/t3

Inbound

Set the timeout to a short period (5-10 seconds).

Oracle HTTP Server management by Administration Server

FW1

OPMN port (6701) and Oracle HTTP Server Admin Port (7779)

TCP and HTTP, respectively

Outbound

Set the timeout to a short period (5-10 seconds).

BI Server access

FW1

9704

HTTP/bi_servern

Inbound

Timeout varies based on the type of process model used for BI.

Communication between BI Cluster members

n/a

9704

TCP/IP Unicast

n/a

By default, this communication uses the same port as the server's listen address.

Session replication within a WebLogic Server cluster

n/a

n/a

n/a

n/a

By default, this communication uses the same port as the server's listen address.

Oracle WebLogic Server Administration Console access

FW1

7001

HTTP / Administration Server and Enterprise Manager

Both

You should tune this timeout based on the type of access to the Administration Console (whether you plan to use the Administration Console from application tier clients, or from clients external to the application tier).

Node Manager

n/a

5556

TCP/IP

n/a

n/a

For actual values, see "Firewall and Port Configuration" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

Access Server access

FW1

6021

OAP

Inbound

For actual values, see "Firewall and Port Configuration" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

Identity Server access

FW1

6022

OAP

Inbound

n/a

Database access for BI Server and BI Publisher JDBC data sources

FW1

Listening port for client connections to the listener

SQL*Net

Both

Timeout depends on all database content and on the type of process model used for BI

Database access

FW2

1521

SQL*Net

Both

Timeout depends on all database content and on the type of process model used for BI.

Oracle Internet Directory access

FW2

389

LDAP

Inbound

You should tune the directory server's parameters based on load balancer, and not the other way around.

Oracle Internet Directory access

FW2

636

LDAP SSL

Inbound

You should tune the directory server's parameters based on load balancer, and not the other way around.

JOC for OWSM

n/a

9991

TCP/IP

n/a

n/a


Note:

The firewall ports depend on the definition of TCP/IP ports.

3.6 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 your 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."