Skip Headers
Oracle® Exalogic Elastic Cloud Enterprise Deployment Guide for Oracle Identity Management
Release EL X2-2 and EL X3-2

Part Number E35832-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

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

3 Configuring the Network for an Enterprise Deployment

This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topologies.

This chapter includes the following topics:

3.1 Overview of Preparing the Network for an Enterprise Deployment

Table 3-1 summarizes the steps required to set up the network for an Enterprise Deployment on the Exalogic machine.

Table 3-1 Overview of the Network Configuration Process for an Exalogic Enterprise Deployment

Task Description More Information

Verify the Exalogic network configuration

It is important to make sure that you have performed any required Exalogic network setup procedures before you configure the network for an enterprise deployment.

For example, the enterprise deployment requires that you have configured the Ethernet over InfiniBand (EoIB) network.

Section 3.2, "Verifying the Exalogic Network Configuration"

Define the required virtual server names

The enterprise deployment requires that specific virtual server names be defined on your network. They must resolve to the specific compute nodes and servers in the topology.

Section 3.3, "Defining the Required Virtual Server Names"

Configure the external hardware load balancer

The external hardware load balancer must be configured to accept requests from both external customers and company administrators and route them to the appropriate URLs in the topology.

Section 3.4, "Configuring the Load Balancer When Using Oracle Traffic Director as Your Web Tier"

Define the required Virtual IP Addresses

The enterprise deployment requires a set of virtual server names for routing requests to the proper server or service within the topology.

Section 3.5, "About IP Addresses and Virtual IP Addresses"

Configure the firewalls

When you install and configure the firewalls for your topology, use this information to open only the required ports and set the proper timeouts for each port.

Section 3.6, "Configuring Firewall Ports"


3.2 Verifying the Exalogic Network Configuration

Before configuring the network for an enterprise deployment reference topology, verify the existing Exalogic network configuration.

This section contains the following topics:

3.2.1 Understanding the Network Requirements for the Enterprise Topology

When you initially set up your Exalogic machine, the default network is running IP over InfiniBand (IPoIB). In addition to IPoIB, you must manually configure Ethernet over InfiniBand (EoIB) network access.

This chapter is based on the assumption that you have set up and configured an Exalogic Machine, as described in the Oracle Fusion Middleware Exalogic Machine Owner's Guide. This configuration includes the installation and configuration of the IP over InfiniBand (IPoIB) and Ethernet over InfiniBand (EoIB) networks, network gateways and switches, assignment of IP addresses and routing tables.

The goal of the network configuration is to:

  • Use IPoIB for communications between the components whenever possible, for example, between the Oracle Traffic Director hosts in the Web tier and the Identity Management hosts in the Application tier.

  • Use EoIB for communications between the Oracle Traffic Director hosts and the hardware load balancer.

  • Use EoIB for communications between the IDMHOSTs and the Oracle RAC Database.

For more information about the topology, refer to Figure 2-1, "Oracle Identity Management on Exalogic, Deployed with Oracle Traffic Director and an Oracle RAC Database"

3.2.2 About Ethernet over InfiniBand (EoIB) Configuration

Oracle Identity Management enterprise deployment on Exalogic uses EoIB for the following communication:

  • Communication between the hardware load balancer and the Oracle Traffic Director hosts. As a result, the load balancer should communicate with the Oracle Traffic Director hosts only through the EoIB interface on WEBHOST1 and WEBHOST2. When referencing the Oracle Traffic Director hosts from the load balancer, be sure to use the EoIB IP address only. The Oracle Traffic Director EoIB addresses are the only addresses accessible in the DMZ network.

  • Communication between the Identity Management hosts and the Oracle RAC Database. As a result, the database connections should be configured to communicate only through the EoIB interface on IDMHOST1 and IDMHOST2.

All other communication within the topology is performed over the higher performance and secure IPoIB network interfaces.

EoIB is not set up by default; it is a manual procedure documented in the Oracle Fusion Middleware Exalogic Machine Owner's Guide. If you have not set up EoIB go to "Configuring Ethernet Over InfiniBand" and follow the instructions.

Note:

Once the EoIB interface is created, an IP address is available. Make sure this IP address is accessible both inside and outside of the rack.

If you have already configured EoIB for you enterprise deployment, proceed to Section 3.2.3, "Verifying the Network Interfaces."

3.2.3 Verifying the Network Interfaces

Verify that each compute node in the topology has both an IPoIB and EoIB interface configured and working. You can verify these interfaces using the ifconfig and route commands. Compare the output from these commands to the information in table Table 3-2.

For example, to verify the network interfaces using the ifconfig command:

ifconfig

See Example 3-1 for example output.

Example 3-1 ifconfig Command Output Example

bond0     Link encap:Ethernet  HWaddr 00:21:F6:0E:0E:01
          inet addr:10.244.45.215  Bcast:10.244.47.255  Mask:255.255.248.0
 
bond1     Link encap:InfiniBand  HWaddr 80:00:00:4A:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
          inet addr:192.168.10.5  Bcast:192.168.15.255  Mask:255.255.248.0
 
eth0      Link encap:Ethernet  HWaddr 00:21:28:E8:50:E0
          inet addr:10.244.64.56  Bcast:10.244.71.255  Mask:255.255.248.0
 
eth4_8123 Link encap:Ethernet  HWaddr 00:21:F6:0E:0E:01
 
eth5_8123 Link encap:Ethernet  HWaddr 00:21:F6:0E:0E:02
 
ib0       Link encap:InfiniBand  HWaddr 80:00:00:4A:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
 
ib1       Link encap:InfiniBand  HWaddr 80:00:00:4B:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
 
lo        Link encap:Local Loopback

Run the route command to view the Kernel IP routing table:

route -n

Notice that in Example 3-2, the default traffic goes through bond0 interface.

Example 3-2 route Command Output Example

Kernel IP routing table
Destination     Gateway           Genmask     Flags   Metric   Ref    Use   Iface
10.n.n.n       0.0.0.0        255.255.248.0   U       0        0        0   bond0
10.n.n.n       0.0.0.0        255.255.248.0   U       0        0        0   eth0
192.n.n.n      0.0.0.0        255.255.248.0   U       0        0        0   bond1
169.254.0.0    0.0.0.0        255.255.0.0     U       0        0        0   eth0
0.0.0.0        10.n.n.n       0.0.0.0         UG      0        0        0   bond0

3.2.4 Summary of the Network Interfaces on Each Compute Node

This section describes the network interfaces for each compute node. Compare the output of the ifconfig and route commands with the values in the tables. This will verify that IPoIB and EoIB are configured properly.

Table 3-2 lists the network interfaces for WEBHOST1.

Table 3-2 Network Interfaces and Connections

Host name IPoIB EoIB Virtual Hosts VLAN VIRTUAL HOST NAMES/NIC/Example VIPS VLAN

WEBHOST1

Yes

Example:

192.168.10.120

Yes

Example:

10.244.45.211

 

IPoIB:

Default VLAN

EoIB:

Create VLAN1

idminternal.mycompany.com:

bond0:1->10.244.45.211

oudinternal.mycompany.com:

bond1:2->192.168.10.120

IPoIB:

Default VLAN

EoIB:

Create VLAN1

WEBHOST2

Yes

Example:

192.n.n.n

Yes

Example:

10.n.n.n

 

IPoIB:

Default VLAN

EoIB:

Use VLAN1

 

IPoIB:

Default VLAN

EoIB:

Use VLAN1

IDMHOST1

Yes

Example:

192.168.10.200

Yes

Example:

10.n.n.n

ADMINVHN

OIMHOST1VHN

SOAHOST1VHN

IPoIB:

Default VLAN

EoIB:

Create VLAN2

ADMINVHN:

bond1:1->192.168.10.200

OIMHOST1VHN:

bond1:2->192.168.10.100

SOAHOST1VHN:

bond1:3->192.168.10.110

IPoIB:

Default VLAN

EoIB:

Create VLAN2

IDMHOST2

Example:

192.168.10.101

Yes

Example:

10.n.n.n

OIMHOST2VHN

SOAHOST2VHN

IPoIB:

Default VLAN

EoIB:

Use VLAN2

OIMHOST2VHN:

bond1:1->192.168.10.101

SOAHOST2VHN:

bond1:2->192.168.10.111

IPoIB:

Default VLAN EoIB:

Use VLAN2


Note:

If you have the DNS entry for oudinternal.mycompany.com and idminternal.mycompany.com, you can use either DNS based ( Ex: 10.244.*.*) IPs or local ( Internal ex: 192.168.*.*). if you use the local IPs you must have entries in the /etc/hosts.

3.3 Defining the Required Virtual Server Names

A virtual host is associated with an IP address that is not permanently bound to a server or load balancing appliance. It is always enabled on a server or load balancing appliance but may move between servers/appliances as needed.

The sso.mycompany.com and admin.mycompany.com virtual servers are defined on the hardware load balancer. The oudinternal.mycompany.com and idminternal.mycompany.com are defined on Oracle Traffic Director.

The compute nodes on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.

Virtual servers admin.mycompany.com and sso.mycompany.com should be configured in DNS. Although the others may be configured in DNS, they need not be and can be set up in the local host files of the compute nodes for added security.

Note:

If the virtual server must be visible only in the Exalogic rack, associate them with a virtual IP address bond0 (IPoIB) and 192.168.*.* address. These addresses are updated in the /etc/hosts file.

If the Virtual server must be visible outside of the Exalogic rack, associate it with a virtual IP address bond1 (EoIB) address, which is a DNS address.

The Exalogic enterprise deployment reference topology uses the following virtual server names:

3.3.1 sso.mycompany.com

Note the following when defining this virtual server name:

  • This virtual server is an EoIB address. It is the virtual name which fronts all Identity Management components, including Oracle Access Management and Oracle Identity Manager.

  • This virtual server acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address https://SSO.mycompany.com:443 and in turn forward these to port 7777 (OTD_PORT) on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.

  • Configure this virtual server on the hardware load balancer with port 443 (HTTP_SSL_PORT).

  • This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

  • This virtual server is configured on the load balancer and is enabled in DNS.

3.3.2 admin.mycompany.com

Note the following when defining this virtual server name:

  • This virtual server is an EoIB address. It routes the hardware load balancer requests to Administration console, Enterprise Manager, and the oamconsole servers.

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services.

    The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address ADMIN.mycompany.com:80 and in turn forward these to port 7777 (OTD_PORT) on WEBHOST1 and WEBHOST2.

    The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Authorization Policy Manager, and Oracle Directory Services Manager.

  • Configure this virtual server on the hardware load balancer. Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host.

    Only traffic inside the DMZ should be able to access these URLs on the ADMIN.mycompany.com virtual host.

  • This virtual server is configured on the load balancer and is enabled in DNS.

3.3.3 oudinternal.mycompany.com

Note the following about this virtual server name:

  • This virtual server is an IPoIB address. It acts as a load balancer, routing requests to the OUD instances.

  • This virtual server is defined later in Section 7.8, "Defining the Required Oracle Traffic Director Virtual Servers for an Enterprise Deployment."

  • This virtual server acts as the access point for all Identity Store LDAP traffic. The clients access this service using the address OUDINTERNAL.mycompany.com:1489 for non-SSL.

  • Use this virtual server to monitor the heartbeat of the Oracle Unified Directory processes. If an Oracle Unified Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Unified Directory instance.

  • This virtual server directs traffic to each of the Oracle Unified Directory instances on port 1389 (LDAP_DIR_PORT).

  • This virtual server directs traffic received on port 636 (LDAP_LBR_SSL_PORT) to each of the Oracle Unified Directory instances on port 1636 (LDAP_DIR_SSL_PORT).

  • This virtual server is configured using OTD and is resolvable only inside the Exalogic Rack.

3.3.4 idminternal.mycompany.com

Note the following about this virtual server name:

  • This virtual server is an IPoIB (ex bond1:2->192.168.10.120) address. It acts as a load balancer, routing requests to SOA servers on IDMHOST1 and IDMHOST2.

  • This virtual server is defined later in Section 7.8, "Defining the Required Oracle Traffic Director Virtual Servers for an Enterprise Deployment."

  • This virtual server is enabled on Oracle Traffic Director. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IDMINTERNAL.mycompany.com:80 and in turn forward these to port 7777 (OTD_PORT) on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services

  • Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IDMINTERNAL.mycompany.com virtual host.

  • Add this virtual server is configured using OTD and is resolvable only inside the Exalogic Rack

3.4 Configuring the Load Balancer When Using Oracle Traffic Director as Your Web Tier

This enterprise topology uses an external hardware load balancer.

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

Note:

Oracle supports most industry-standard load balancers. For a list of load balancers that were supported by previous Oracle middleware software releases, see the following information on the Oracle Technology Network:

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

This section contains the following topics:

3.4.1 Load Balancer Requirements

The enterprise topologies use an external load balancer. The 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 URL, 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 fault-tolerant so that if a software or hardware failure occurs in the appliance and alternate failover device can resume operations.

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

  • Ability to add WL-Proxy-SSL: true to the HTTP Request Header. Some load balancers do this automatically

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

  1. 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 (OTD_PORT).

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

  3. 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 https://sso.mycompany.com:443.

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

  5. Configure SSL Termination, if applicable, for the virtual server.

  6. Assign the Pool of servers created in Step 1 to the virtual server.

  7. Tune the time out settings as listed in Section 3.6, "Ports Used in the Reference Topology". This includes time to detect whether a service is down.

3.4.3 Load Balancer Configuration Details

For an Identity Management deployment, configure your load balancer as shown in Table 3-3.

Table 3-3 Load Balancer Configuration Details

Virtual Host Server Pool Protocol SSL Termination External Other Required Configuration/Comments

SSO.mycompany.com:80

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

No

Yes

Identity Management requires that the following be added to the HTTP header:

Header Name: IS_SSLFoot 1 

Header Value: ssl

SSO.mycompany.com:443

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

Yes

Yes

Identity Management requires that the following be added to the HTTP header:

Header Name: IS_SSL

Header Value: ssl

ADMIN.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

 

oudinternal.mycompany.com:1489

IDMHOST1.mycompany.com:1389

IDMHOST2.mycompany.com:1389

LDAP

No

No

Only required if Identity Management users are stored in an Oracle Unified Directory.


Footnote 1 For information about configuring IS_SSL, see "About User Defined WebGate Parameters" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

3.5 About IP Addresses and Virtual IP Addresses

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.

The following is a list of the Virtual IP addresses required by Oracle Identity Management:

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs.

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

Table 3-4 VIP Addresses and Virtual Hosts

Virtual Host Name Description

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 (IDMHOST1 by default).

OIMADMINVHN

OIMADMINVHN is the virtual host name that is the listen address for the Oracle Identity Manager Administration Server. It fails over with manual failover of the Administration Server. It is enabled on the node where the Oracle Identity Manager Administration Server process is running (IDMHOST1 by default).

SOAHOST1VHN

SOAHOST1VHN 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 (IDMHOST1 by default).

OIMHOST1VHN

OIMHOST1VHN is the virtual host name that maps to the listen address for the WLS_OIM1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM1 process us running (IDMHOST1 by default)

SOAHOST2VHN

SOAHOST2VHN 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 (IDMHOST2 by default).

OIMHOST2VHN

OIMHOST2VHN is the virtual host name that maps to the listen address for the WLS_OIM2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM2 process us running (IDMHOST2 by default)


3.6 Configuring Firewall 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-5 lists the ports used in the Oracle Exalogic deployment reference topology, including the ports that you must open on the firewalls in the topology.

Firewall notation:

Table 3-5 Ports Used in the Reference Topology

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 process models used for the Oracle Fusion Middleware products you are using in the Exalogic environment.

Browser request

FW0

443

HTTPS / Load Balancer

Inbound

Timeout depends on all HTML content and the process models used for the Oracle Fusion Middleware products you are using in the Exalogic environment.

Load balancer to Oracle Traffic Director

n/a

7777 as the example HTTP port for WEBHOST1 and WEBHOST2.

4443 as the example HTTPS port for WEBHOST1 and WEBHOST2.

HTTP/HTTPS

n/a

See Section 3.4, "Configuring the Load Balancer When Using Oracle Traffic Director as Your Web Tier."

For actual values, see the topic "Port Numbers by Component" in the Oracle Fusion Middleware Administrator's Guide.

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

Coherence

n/a

8088

Range: 8080 - 8090

 

n/a

n/a

Application tier to data tier (Oracle database or RAC outside of Oracle Exalogic machine via Ethernet)

FW2

1521

 

n/a

n/a

Managed Server Access (WLS_OAM1, WLS_OAM2, WLS_OIM1. WLS_OIM2, WLS_SOA1, WLS_SOA2)

FW1

8001

14000, 14100

HTTP

Inbound

Managed Servers, which use BOND1 floating IP addresses, are accessed via Oracle HTTP Server.