3 Preparing the Network for an Enterprise Deployment

This chapter describes the network environment preconfiguration required by the SOA 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:

Section 3.1, "Overview of Preparing the Network for an Enterprise Deployment"
Section 3.2, "About Virtual Server Names Used by the Topology"
Section 3.3, "Configuring the Load Balancers"
Section 3.4, "About IPs and Virtual IPs"
Section 3.6, "About Firewalls and Ports"

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 configuring the virtual hosts and associated ports later during Web tier configuration and the installation of the different software components. After reading this chapter, prepare a list of virtual host names and VIPs to be used in this environment.

3.2 About Virtual Server Names Used by the Topology

The SOA enterprise topology uses the following virtual server names:

soa.mycompany.com
admin.mycompany.com
osb.mycompany.com
soainternal.mycompany.com

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.

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

3.2.1 so a.mycompany.com

soa.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime SOA components, such as soa-infra, workflow, and B2B. Traffic to SSL is configured. Clients access this service using the address soa.mycompany.com:443.

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

3.2.3 osb.mycompany.com

osb.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime Oracle Service Bus resources and proxy services. Traffic to SSL is configured. Clients access this service using the address osb.mycompany.com:443.

3.2.4 soa internal.mycompany.com

soainternal.mycompany.com is a virtual server name used for internal invocations of SOA services. This url is not exposed to the internet and is only accessible from the intranet. (For SOA systems, users can set this while modeling composites or at runtime with the appropriate EM/MBeans, as the url to be used for internal services invocations.)

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

3.3 Configuring the Load Balancers

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

There are two load balancer devices in the recommended topologies. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various DMZs. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.

3.3.1 Load Balancer Requirements

The enterprise topologies use 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.
Monitoring of ports (HTTP and HTTPS).
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 WebLogic Clusters, 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.
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, you should use it.
Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
Other: 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 machine.
SSL acceleration (this feature is recommended, but not required).
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 Management 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.

3.3.2 Load Balancer Configuration Procedures

The procedures for configuring a load balancer differ, depending on the specific type of load balancer. Refer to the vendor supplied documentation for actual steps. The following steps outline the general configuration flow:

Create a pool of servers. This pool contains a list of servers and the ports that are included in the load balancing definition. For example, for load balancing between the web hosts you create a pool of servers which would direct requests to hosts WEBHOST1 and WEBHOST2 on port 7777.
Create rules to determine whether or not a given host and service is available and assign it to the pool of servers described in Step 1.
Create a Virtual Server on the load balancer. This is the address and port that receives requests used by the application. For example, to load balance Web Tier requests you would create a virtual host for sso.mycompany.com:80.
1. If your load balancer supports it, specify whether or not the virtual server is available internally, externally or both. Ensure that internal addresses are only resolvable from inside the network.
2. Configure SSL Termination, if applicable, for the virtual server.
3. Assign the Pool of servers created in Step 1 to the virtual server.
Tune the time out settings as listed in Table 3-4, "Ports Used". This includes time to detect whether a service is down.

3.3.3 Load Balancer Configuration

For an Oracle SOA deployment, configure your load balancer as shown in Table 3-1.

Table 3-1 Load Balancer Configuration

Virtual Host	Server Pool	Protocol	SSL Termination	External	Other Required Configuration/Comments
`admin.mycompany.com:80`	`WEBHOST1.mycompany.com:7777` `WEBHOST2.mycompany.com:7777`	HTTP	No	No	Use your internal administration address as the virtual server address (for example, `admin.mycompany.com`). 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.
`soa.mycompany.com:443`	`WEBHOST1.mycompany.com:7777` `WEBHOST2.mycompany.com:7777`	HTTP	No	Yes	Use your system's frontend address as the virtual server address (for example, `soa.mycompany.com`). The frontend address is the externally facing host name used by your system and that will be exposed in the Internet. Use port 80 and port 443. Any request that goes to port 80 (non-ssl protocol) should be redirected to port 443 (ssl protocol). Specify ANY as the protocol (non-HTTP protocols are required for B2B). 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.
`soainternal.mycompany.com:80`	`WEBHOST1.mycompany.com:7777` `WEBHOST2.mycompany.com:7777`	HTTP	No	No	Use your internal administration address as the virtual server address (for example, `soainternal.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.
`osb.mycompany.com:443`	`WEBHOST1.mycompany.com:7777` `WEBHOST2.mycompany.com:7777`	HTTP	No	No	Specify HTTP as the protocol.

3.4 About IPs and Virtual IPs

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 3-1. As shown in this figure, each virtual IP and IP is attached to the WebLogic server that uses it. VIP1 is failed over manually to restart the Administration Server in SOAHOST2. VIP2 and VIP3 fail over from SOAHOST1 to SOAHOST2 and from SOAHOST2 to SOAHOST1 respectively through Oracle WebLogic Server Migration feature. WLS_BAM1 also uses server migration to failover VIP4 from BAMHOST1 to BAMHOST2.

See Oracle Fusion Middleware High Availability Guide for information on the WebLogic Server Migration feature.

Physical IPs (non virtual) are fixed to each node. IP1 is the physical IP of SOAHOST1 and is used by the WLS_WSM1 WebServices Policy Manager server. IP2 is the physical IP of SOAHOST2 and is used by the WLS_WSM2 WebServices Policy Manager server. IP3 is the physical IP of BAMHOST2 and is used as the listen address by the WLS_BAM2 Server.

Figure 3-1 IPs and Virtual IPs Mapped to Administration Server and Managed Servers

IP and VIP mapping to admin and managed servers

Table 3-2 provides descriptions of the various virtual hosts.

Table 3-2 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 (SOAHOST1 by default).
VIP2	SOAHOST1VHN1	SOAHOST1VHN1 is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA1 process is running (SOAHOST1 by default).
VIP3	SOAHOST2VHN1	SOAHOST2VHN1 is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA2 process is running (SOAHOST2 by default).
VIP4	BAMHOST1VHN1	BAMHOST1VHN1 is the virtual host name that maps to the listen address for WLS_BAM1 and fails over with server migration of this managed server. It is enabled on the node where WLS_BAM1 process is running (BAMHOST1 by default).
VIP5	SOAHOST1VHN2	SOAHOST1VHN2 is the virtual host name that maps to the listen address for the WLS_OSB1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OSB1 process us running (SOAHOST1 by default)
VIP6	SOAHOST2VHN2	SOAHOST2VHN2 is the virtual host name that maps to the listen address for the WLS_OSB2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OSB2 process us running (SOAHOST2 by default)

3.5 Enabling Virtual IP Addresses for Administration Servers

Note that this step is required for failover of the WebLogic Administration Server, regardless of whether other Oracle Fusion Middleware components are installed later or not.

You associate the Administration Server with a virtual IP address. This allows the Administration Server to be started on a different host if the primary host fails.

Check that the virtual host is enabled as follows:

Table 3-3 Virtual Hosts

VIP	Enabled on Host
ADMINVHN.mycompany.com	SOAHOST1
SOAHOST1VHN1.mycompany.com	SOAHOST1
SOAHOST2VHN1.mycompany.com	SOAHOST2
BAMHOST1VHN1.mycompany.com	BAMHOST1
SOAHOST1VHN2.mycompany.com	SOAHOST1
SOAHOST2VHN2.mycompany.com	SOAHOST2

Note:

This is the DNS name associated with the floating IP address. It is not the DNS name of the virtual host configured on the load balancer.

Linux

To enable the virtual IP address, run the following commands as root:

/sbin/ifconfig interface:index IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

where interface is eth0, or eth1, and index is 0, 1, or 2.

For example:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

Enable your network to register the new location of the virtual IP address:

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

Validate that the address is available by pinging it from another node, for example:

/bin/ping 100.200.140.206

Windows

To enable the virtual IP address, run the following command:

netsh interface ip add address interface IP_Address netmask

where IP_Address is the virtual IP address and the netmask is the associated netmask.

In the following example, the IP address is enabled on the interface Local Area Connection.

netsh interface ip add address "Local Area connection" 100.200.140.206 255.255.255.0

3.6 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-4 lists the ports used in the SOA topology, 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.

Table 3-4 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 SOA.
Browser request	FW0	443	HTTPS / Load Balancer	Inbound	Timeout depends on all HTML content and the type of process model used for SOA.
Browser request	FW1	80	HTTPS / Load Balancer	Outbound (for intranet clients)	Timeout depends on all HTML content and the type of process model used for SOA.
Browser request	FW1	443	HTTPS / Load Balancer	Outbound (for intranet clients)	Timeout depends on all HTML content and the type of process model used for SOA.
Callbacks and Outbound invocations	FW1	80	HTTPS / Load Balancer	Outbound	Timeout depends on all HTML content and the type of process model used for SOA.
Callbacks and Outbound invocations	FW1	443	HTTPS / Load Balancer	Outbound	Timeout depends on all HTML content and the type of process model used for SOA.
Load balancer to Oracle HTTP Server	n/a	7777	HTTP	n/a	See Section 3.3, "Configuring the Load Balancers."
OHS registration with Administration Server	FW1	7001	HTTP/t3	Inbound	Set the timeout to a short period (5-10 seconds).
OHS management by Administration Server	FW1	OPMN port (6701) and OHS Admin Port (7779)	TCP and HTTP, respectively	Outbound	Set the timeout to a short period (5-10 seconds).
WSM-PM access	FW1	7010 Range: 7010 - 7999	HTTP / WLS_WSM-PMn	Inbound	Set the timeout to 60 seconds.
SOA Server access	FW1	8001 Range: 8000 - 8010	HTTP / WLS_SOAn	Inbound	Timeout varies based on the type of process model used for SOA.
Oracle Service Bus Access	FW1	8011 Range: 8011-8021	HTTP / WLS_OSBn	Inbound/ Outbound	Set the timeout to a short period (5-10 seconds).
BAM access	FW1	9001 Range: 9000 - 9080	HTTP / WLS_BAMn	Inbound	Connections to BAM WebApps are kept open until the report/browser is closed, so set the timeout as high as the longest expected user session.
Communication between SOA Cluster members	n/a	8001	TCP/IP Unicast	n/a	By default, this communication uses the same port as the server's listen address.
Communication between WSM Cluster members	n/a	7010	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.
Administration Console access	FW1	7001	HTTP / Administration Server and Enterprise Manager t3	Both	You should tune this timeout based on the type of access to the admin console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).
Node Manager	n/a	5556	TCP/IP	n/a	n/a For actual values, see "Firewalls and Ports" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.
Access Server access	FW1	6021 (OAM 10g) 5575 (OAM 11g)	OAP	Inbound	For actual values, see "Firewalls and Ports" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.
Identity Server access (OAM 10g)	FW1	6022	OAP	Inbound	n/a
Database access	FW2	1521	SQL*Net	Both	Timeout depends on all database content and on the type of process model used for SOA.
Coherence for deployment	n/a	8088 Range: 8000 - 8090		n/a	n/a
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
Oracle Notification Server (ONS)	FW2	6200	ONS	Both	Required for Gridlink. An ONS server runs on each database server.