This chapter describes the network environment preconfiguration that the Oracle Business Intelligence enterprise topology requires. Use this chapter to plan the configuration of virtual server names, load balancers, IPs and Virtual IPs, and firewalls and ports.
This chapter includes the following topics:
Section 3.1, "Overview of Preparing the Network for an Enterprise Deployment"
Section 3.2, "About Virtual Server Names Used by the Topology"
You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers must be configured to the appropriate real hosts and ports for the services that are running. Also, the load balancer must 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 the cluster using its fully qualified domain name. For the installation to succeed, every computer on which you scale out the installation must be able to support bidirectional communication with the Administration Server on the cluster's primary host.
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 the DNS. The nodes that are 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 define the virtual server names on the load balancer using the procedure in Section 3.3, "Configuring the Load Balancer."
bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime Oracle Business Intelligence 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.
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 Server 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.
biinternal.mycompany.com is a virtual server name that is 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.
Several virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services that are 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.
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."
After you configure the virtual host in Section 7.5, "Defining Virtual Hosts," you can access the virtual host name addresses. If you cannot access them, then review this procedure to ensure that it was completed correctly.
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
This enterprise topology uses an external load balancer. This external load balancer must 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 must allow configuration of multiple virtual servers. For each virtual server, the load balancer must 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 the 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
Resource monitoring, port monitoring, process failure detection
The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, then you should use it.
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 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 must have the ability 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 is required for this EDG.
Connection timeout for TCP Connections
Configure the virtual server(s) in the load balancer for the directory tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between Oracle Access Manager and the directory tier.
Ability to preserve the client IP addresses
The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.
The procedure described in this section contains high-level steps. The actual steps that you perform vary depending on the type of load balancer that you use. For detailed instructions, consult the documentation for the load balancer.
Perform the following steps to configure the load balancer by defining the virtual server names:
Create a pool of servers. You assign this pool to virtual servers.
Add the addresses of the Oracle HTTP Server hosts to the pool. For example:
WEBHOST1:7777
WEBHOST2:7777
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 the system's frontend address as the virtual server address (for example, bi.mycompany.com). The frontend address is the externally facing host name that is used by the system that is exposed in the Internet.
Configure this virtual server with port 80 and port 443. Any request that goes to port 80 (non-ssl protocol) must 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.
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 the 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.
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 the 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.
Configure monitors for the Oracle HTTP Server nodes to detect failures in these nodes:
Configure 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 the system. You can try five 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 the Oracle Business Intelligence system; that is, specify a value greater than the longest period of time any of the requests to HTTP servers can take.
Table 3-1 describes the various virtual hosts.
| Virtual IP | VIP Maps to... | Description |
|---|---|---|
|
VIP1 |
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 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 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). |
The Administration Server must be configured to listen on a virtual IP Address to enable it to seamlessly failover from one host to another. In case of a failure, the Administration Server, along with the virtual IP Address, can be migrated from one host to another.
However, before the Administration Server can be configured to listen on a virtual IP Address, one of the network interface cards on the host that is running the Administration Server must be configured to listen on this virtual IP Address. The steps to enable a virtual IP Address are completely dependent on the operating system.
Perform the following steps to enable a virtual IP Address on APPHOST1. In a UNIX environment, the command must be run as the root user.
On APPHOST1, run the ifconfig command to get the value of the netmask. In a UNIX environment, run this command as the root user. For example:
[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
On APPHOST1, 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
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 the following section for information about enabling VIP2 and VIP3 for the Managed Servers on APPHOST1 and APPHOST2.
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 Oracle BI computers (VIP2 on APPHOST1 and VIP3 on APPHOST2), and they must correctly resolve to the virtual host names in the network system that is 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 that is 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 a UNIX environment, the command must be run as the root user:
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
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
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 3.4.1, "Enabling ADMINVHN on APPHOST1" for information about enabling VIP1 for the Administration Server on APPHOST1.
Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers that these services use 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 that the Oracle Business Intelligence topology uses, including the ports that you must open on the firewalls in the topology.
Firewall notation:
FW0 refers to the outermost firewall.
FW1 refers to the firewall between the web tier and the application tier.
FW2 refers to the firewall between the application tier and the data tier.
| 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. |
|
n/a |
7777 |
HTTP |
n/a |
||
|
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). |
|
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. |
|
FW1 |
7001 |
HTTP / Administration Server and Enterprise Manager |
Both |
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). |
|
|
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 |
|
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 |
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 |
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.