3 Preparing the Network for an Enterprise Deployment

This chapter describes the network environment preconfiguration required by the WebCenter Portal 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 Balancer"

• Section 3.4, "About IPs and Virtual IPs"

• Section 3.5, "About Firewalls and Ports"

• Section 3.6, "About LDAP as Credential and Policy Store"

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.

3.2 About Virtual Server Names Used by the Topology

The WebCenter Portal enterprise topology uses the following virtual server names:

• Section 3.2.1, "wcp.mycompany.com"

• Section 3.2.2, "admin.mycompany.com"

• Section 3.2.3, "wcpinternal.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 Balancer."

Note:

The only virtual server name which is accessed by clients is the externally facing URL wcp.mycompany.com. All other URLs are for internal use only. See also, Section 2.1.3.1, "Load Balancer Requirements".

3.2.1 wcp.mycompany.com

wcp.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to runtime SOA and WebCenter Portal components, such as soa-infra, Workflow, and the Spaces application. Traffic to SSL is configured. Clients access this service using the address wcp.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 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 wcpinternal.mycompany.com

wcpinternal.mycompany.com is a virtual server name used for internal invocations of Oracle WebCenter Portal 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 wcpinternal.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 below contains high-level steps. The actual steps you will perform vary depending on the type of load balancer you use. For detailed instructions for completing the procedure below 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 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 described in Section 3.2, "About Virtual Server Names Used by the Topology.":

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 wcp.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, wcp.mycompany.com). The frontend address is the externally facing host name used by your system and that will be exposed in the Internet.

   • Configure this virtual server with port 80 and port 443. Any request that goes to port 80 should be redirected to port 443.

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

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

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

   • For this virtual server, use the internal address as the virtual server address (for example, wcpinternal.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 time response that you can expect from your WebCenter Portal 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.6, "Configuring Virtual Hosts" you should be able to access the virtual host name addresses. If you cannot access them, review this procedure to ensure this procedure was completed correctly.

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 VIP and IP is attached to the WebLogic server that uses it. VIP1 is failed 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. 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 WCPHOST1 and is used by all the WebCenter Portal servers (WC_Spaces1, WC_Portlets1, WC_Collaboration1, WC_Utilities1 and ClusterInst1.

IP4 is the physical IP of WCPHOST2 and is used by all the WebCenter Portal servers (WC_Spaces2, WC_Portlets2, WC_Collaboration2, WC_Utilities2 and ClusterInst2.

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

Table 3-1 provides descriptions of 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 (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).

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 to 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 WebCenter Portal 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.

Note:

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

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 WebCenter Portal.
Browser request	FW0	443	HTTPS / Load Balancer	Inbound	Timeout depends on all HTML content and the type of process model used for WebCenter Portal.
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 Balancer."
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.
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.
Communication between Spaces_Cluster members	n/a	9000	TCP/IP Unicast	n/a	By default, this communication uses the same port as the server's listen address.
Communication between Portlet_Cluster members	n/a	9001	TCP/IP Unicast	n/a	By default, this communication uses the same port as the server's listen address.
Communication between Collab_Cluster members	n/a	9002	TCP/IP Unicast	n/a	By default, this communication uses the same port as the server's listen address.
Communication between Utilities_Cluster members	n/a	9003	TCP/IP Unicast	n/a	By default, this communication uses the same port as the server's listen address.
WebCenter Content access	FW1	16200	HTTP / WLS_WCCn	Inbound	Browser-based access. Configurable session timeouts.
Communication between WCC_Cluster members	n/a	16200	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	n/a
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 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.
Identity Server access	FW1	6022	OAP	Inbound
Database access	FW2	1521	SQL*Net	Both	Timeout depends on all database content and on the type of process model used for WebCenter Portal.
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.
WebCenter Portal access to WebCenter Content Server	FW2	4444	TCP/IP socket	n/a	Persistent connection. Configurable timeout.
WebCenter Portal access to Inbound Refinery	FW2	5555	TCP/IP socket	n/a	n/a
JOC for OWSM	n/a	9991	TCP/IP	n/a	n/a
Coherence for deployment	n/a	8088 Range: 8000 - 8090		n/a	n/a

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.

Note:

The domain home is the physical directory from which the server runs, that is, /aserver or /mserver. Changes made to configuration files in the Administration Server domain directory are propagated out. However, changes made to Managed Server domain directories are overwritten.

An Oracle Fusion Middleware WebCenter Portal Enterprise Deployment Topology uses different domain homes for the Administration Server and the managed server as described in the Chapter 4, "About Recommended Locations for the Different Directories". Derived from this, and for integrity and consistency purposes, Oracle requires the use of an LDAP as policy and credential store in context of Oracle Fusion Middleware WebCenter Portal Enterprise Deployment Topology.

To configure the WebCenter Portal Enterprise Deployment Topology with an LDAP as Credential and Policy store, follow the steps in Section 15.2, "Configuring the Credential Store" and Section 15.3, "Configuring the Policy Store."