3 Preparing the Network for an Enterprise Deployment

This chapter describes the network environment preconfiguration required by the Oracle WebCenter Content enterprise deployment topology. Use this chapter to plan your configuration of virtual server names, load balancers, IP addresses, virtual IP addresses, and firewalls and ports.

This chapter includes the following sections:

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 Virtual Server Names Used by the Topology

The Oracle WebCenter Content 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.

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

3.2.1 admin.mycompany.com

The address 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 Console and Oracle Enterprise Manager Fusion Middleware Control.

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.2 wcc.mycompany.com

The address wcc.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime Oracle WebCenter Content components. Traffic to SSL is configured. Clients access this service using the address wcc.mycompany.com:443 for HTTP.

3.2.3 wccinternal.mycompany.com

The address wccinternal.mycompany.com is a virtual server name used for internal invocations of SOA and WebCenter Content services. This URL is not exposed to the Internet and is accessible only from the intranet. (For Oracle SOA Suite systems, users can set this URL while modeling composites or at runtime with the appropriate MBean through Fusion Middleware Control, as the URL to be used for invoking internal services.) You can use this URL for any service call back to WebCenter Content components from Oracle SOA Suite.

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

3.2.4 ucminternal.mycompany.com

The address ucminternal.mycompany.com is a virtual server name that acts as the access point for all internal Remote Intradoc Client (RIDC) TCP traffic to the runtime Oracle WebCenter Content components. Applications like Imaging and Capture access this service using the address ucminternal.mycompany.com:6300 for RIDC connections, and the requests are forwarded to port 4444 on WCCHOST1 and WCCHOST2.

3.3 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. In either case, it is highly recommended to deploy a given load balancer device in fault-tolerant mode.

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

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

3.3.1 Understanding 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 Server 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, and 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 required.

  • Configuration of the virtual server or servers 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 Oracle Technology Network provides a list of validated load balancers and their configuration at http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html.

3.3.2 Configuring a Load Balancer

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:

  1. Configure an HTTP monitor 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 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 Oracle WebCenter Content system, that is, specify a value greater than the longest period of time any of your requests to HTTP servers can take.

  2. Configure a TCP/IP monitor for the WCCHOSTn nodes to detect failures in these nodes:

    • The monitor should be a TCP-Half-Open type.

    • The monitor should ping the nodes at the Oracle WebCenter Content Server port, 4444, every 5 seconds, with a timeout value of 16 seconds.

  3. Create a pool of servers and assign the HTTP monitor created in Step 1 to the pool. 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 that would direct requests to hosts WEBHOST1 and WEBHOST2 on port 7777.

  4. Also create a pool of servers and assign the TCP/IP monitor created in step 2 to the pool, which would direct RIDC requests to hosts WCCHOST1 and WCCHOST2 on port 4444.

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

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

    • Use your internal administration address as the virtual server address (admin.mycompany.com). This address is typically not externalized.

    • Specify HTTP as the protocol.

    • Configure this virtual server with port 80. HTTP requests that go to port 80 should be redirected to port 7777 on the HTTP nodes.

    • Enable address and port translation.

    • Enable reset of connections when services, nodes, or both are down.

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

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

  7. Configure a virtual server in the load balancer for wccinternal.mycompany.com:80, and define the following rules for this virtual server:

    • Use your internal Oracle WebCenter Content address as the virtual server address (wccinternal.mycompany.com). This address is typically not externalized.

    • Specify HTTP as the protocol.

    • Configure this virtual server with port 80. HTTP requests that go to port 80 should be redirected to port 7777 on the HTTP nodes.

    • Enable address and port translation.

    • Enable reset of connections when services, nodes, or both are down.

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

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

  8. Configure a virtual server in the load balancer for ucminternal.mycompany.com:6300, and define the following rules for this virtual server:

    • Use the internal address (ucminternal.mycompany.com) as the virtual server address. This address is typically not externalized.

    • Specify TCP/IP as the protocol.

    • Configure this virtual server with port 6300. RIDC requests that go to port 6300 should be redirected to port 4444 on the Content Server nodes.

    • Enable address and port translation.

    • Enable reset of connections when services, nodes, or both are down.

    • Assign the pool created in step 3 to the virtual server, for RIDC requests.

After you configure the virtual hosts in Section 8.5, "Defining 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 IP Addresses and Virtual IP Addresses

Configure the Administration Server and the Managed Servers to listen on different physical IP addresses and virtual IPs addresses, as illustrated in Figure 3-1. As this figure shows, each IP address and virtual IP address is attached to the Oracle WebLogic Server instance that uses it. VIP1 is failed manually to restart the Administration Server in WCCHOST2. If Oracle SOA Suite is configured to use with Imaging, WLS_SOA1 and WLS_SOA2 use VIP2 and VIP3 to fail over from WCCHOST1 to WCCHOST2 and from WCCHOST2 to WCCHOST1, respectively, through the Oracle WebLogic Server migration feature. WLS_IMG1 and WLS_IMG2 also use server migration to fail over VIP4 and VIP5, respectively, from WCCHOST1 to WCCHOST2 and from WCCHOST2 to WCCHOST1. Likewise, WLS_CPT1 and WLS_CPT2 use VIP6 and VIP7 for failovers.

For information about the WebLogic Server migration feature, see the Oracle Fusion Middleware High Availability Guide.

Physical IP addresses (nonvirtual) are fixed to each node. IP1 is a physical IP address of WCCHOST1 and is used as the listen address by the WLS_WCC1 server. IP2 is a physical IP address of WCCHOST2 and is used as the listen address by the WLS_WCC2 server.

The virtual IP address db-scan.mycompany.com is the database Oracle Single Client Access Name (SCAN) address for a GridLink data source.

Figure 3-1 IP and Virtual IP Addresses Mapped to the Administration Server and Managed Servers

IP and VIP mapping to admin and managed servers
Description of "Figure 3-1 IP and Virtual IP Addresses Mapped to the Administration Server and Managed Servers"

Table 3-1 provides descriptions of the various virtual hosts to which the virtual IP addresses are mapped.

Table 3-1 Virtual Hosts Mapped to Virtual IP Addresses

Virtual IP Address Virtual Host Name 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 (WCCHOST1 by default).

VIP2

WCCHOST1VHN1

WCCHOST1VHN1 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 the WLS_SOA1 process is running (WCCHOST1 by default).

VIP3

WCCHOST2VHN1

WCCHOST2VHN1 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 the WLS_SOA2 process is running (WCCHOST2 by default).

VIP4

WCCHOST1VHN2

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

VIP5

WCCHOST2VHN2

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

VIP6

WCCHOST1VHN3

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

VIP7

WCCHOST2VHN3

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

db-scan.mycompany.com

  

db-scan.mycompany.com is the database Oracle Single Client Access Name (SCAN) address for a GridLink data source.

3.5 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 WebCenter Content 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 Oracle Web Tier and the application tier.

  • FW2 refers to the firewall between the application tier and the data tier.

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 Oracle SOA Suite.

Browser request

FW0

443

HTTPS / Load Balancer

Inbound

Timeout depends on all HTML content and the type of process model used for Oracle SOA Suite.

Browser request

FW1

80

HTTP / Load Balancer

Outbound (for intranet clients)

Timeout depends on all HTML content and the type of process model used for Oracle SOA Suite.

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 Oracle SOA Suite.

Callbacks and outbound invocations

FW1

80

HTTP / Load Balancer

Outbound

Timeout depends on all HTML content and the type of process model used for Oracle SOA Suite.

Callbacks and Outbound invocations

FW1

443

HTTPS / Load Balancer

Outbound

Timeout depends on all HTML content and the type of process model used for Oracle SOA Suite.

Oracle Notification Server (ONS)

FW2

6200

ONS

Both

Both required for Gridlink. An ONS server runs on each database server.

Load balancer to Oracle HTTP Server

n/a

7777

HTTP

n/a

See Section 3.3, "Load Balancers."

Load balancer to Remote Intradoc Client (RIDC)

FW1

6300

TCP/IP Unicast

n/a

The connection persists.

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

Oracle SOA Suite and Oracle WSM server access

FW1

8001

Range: 8000 - 8080

HTTP / WLS_SOAn

Inbound and Outbound

Timeout varies based on the type of process model used for Oracle SOA Suite.

Oracle WebCenter Content access

FW1

16200

HTTP / WLS_WCCn

Inbound

Browser-based access. Configurable session timeouts.

Oracle WebCenter Content: Imaging access

FW1

16000

HTTP / WLS_IMGn

Inbound

Browser-based access. Configurable session timeouts.

Oracle WebCenter Capture access

FW1

16400

HTTP / WLS_CPTn

Inbound

Browser-based access. Configurable session timeouts.

Imaging connection to Oracle WebCenter Content

FW1

6300

TCP/IP Unicast

n/a

Persistent connection. Timeout configurable on Content Server.

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

Communication between IMG_Cluster members

n/a

16000

TCP/IP Unicast

n/a

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

Communication between CPT_Cluster members

n/a

16400

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 Oracle Enterprise Manager Fusion Middleware Control

t3

Both

You should tune this timeout based on the type of access to the administration console (whether it is planned to use the 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 "Firewall and Port Configuration" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

Access Server access

FW1

5575
(Oracle Access Manager 11g)

6021
(Oracle Access Manager 10g)

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 (Oracle Access Manager 10g)

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 Oracle SOA Suite.

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

Range: 9988-9998

TCP/IP

n/a

n/a

Browser request

n/a

16250

16250

HTTP / WLS_IBRn

n/a

Browser-based access. Configurable session timeouts.

Note:

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