Load Balancer Configuration for Fusion Applications

Background

The Fusion Applications installation guide describes how load balancers are used and which features are required when planning a highly available Fusion Applications environment. The Oracle documentation does not contain supplier specific configuration settings for the load balancers.

The purpose of this post is to help facilitate the discussion between the networking teams and Fusion Applications Administrators by providing additional guidance on how to configure and troubleshoot the use of a load balancer with Fusion Applications.

The contents of this post are largely based on the commonly used BIG-IP device however you can use any load balancer which meets the requirements outlined in the section “Planning Network Configuration” of the Fusion Applications installation guide.

The following flow diagrams outlines the steps we will be following in order to configure your device.

DDA_LBRConfigFlowImage1

Update Installation Workbook

Prior to completing the “Network Virtual Hosts” tab in your installation workbook you must have read all previous chapters and sections of the Fusion Applications installation including the section titled “Network- Virtual Hosts: Planning Network Configuration”.

Planning your DNS entries

Only external addressing needs to be resolved on the DNS, all internal traffic will be resolved using /etc/hosts. When provisioning a highly available Fusion Applications environment both external and internal HTTP traffic will be routed via the load balancer and not directly to the OHS, therefore under the FA and IDM OHS configuration section all names resolution options must be set to “Hosts”

Network - Virtual Hosts Tab

Under the Load Balancer configuration sections only the External Names Resolution must be set to “DNS” all others should be set to “Hosts”

LBR DNS Network Configuration

Planning your virtual servers

In Fusion Applications a unique VIP can be defined for each domain and for both internal and external traffic. This supports the use of more than one device, however many of our customers only have one load balancer device and prefer to create a minimal set of virtual servers. You will need to discuss the requirement with your local networking team and follow your organizations recommended best practices.

The following example is representative of a deployment with more than one load balancing device and the use of a unique VIP for each domain.

LBR VIP Configuration v1

The following example is representative of a deployment with only one device and a minimal set of VIP’s defined.

LBR VIP Network Configuration v2

Once you have finalized the requirements with your local networking team update your workbook with the virtual server IP addresses under the column headings Internal and External IP endpoints.

Create Health Monitors

Use Active Monitoring and not Simple Monitoring. The default health monitor is the icmp monitor, this is simple monitor and will only let you know if the status of the node is UP or DOWN and not if the application or service is running. If you use simple monitoring and the node is UP and the service unavailable then traffic will continue to be routed to the node resulting in errors appearing in the application logs such as “connection reset by peer”. This may result in dropped sessions, authentication issues and errors during start-up.

Eg. You define a server pool named A and in this pool you include 2 nodes IP 10.xxx.xxx.60 and 10.xxx.xxx.61.The OHS was not started on node 1 (10.xxx.xxx.60) and is only running on node 2 (10.xxx.xxx.61).

If you use simple monitoring then both nodes are shown as UP and the load balancer will continue to route requests to both nodes resulting in errors such as “connection reset by peer” when traffic is routed to node 1 (10.xxx.xxx.60). If you use Active monitoring the load balancer will be aware that the OHS on this node is not accepting requests and all traffic will be routed to node 2 (10.xxx.xxx.61).

Use the information below in your installation workbook to help you define active monitoring of the health and performance of your node or pool.

LBR OHS Port Monitoring

LBR LDAP Network Port Monitoring

Create Server Pools

The pool is a logical set of devices, such as ldap or web servers that are grouped together to receive and process traffic. In Fusion Applications you will define pools for the FA and IDM OHS, UCM and IDM Directory Tiers. The load balancer device will receive a request from the client and route that request to one of the servers defined within your pool. Typically you will need to create a pool for every pairing of device and service port. Use the information from the “Network – Virtual Hosts” and “Topology” tabs in your installation workbook to help configure your pools.

DDA_LBR_Network_Server_Pools

Using the information above we will now define our pools for the FA and IDM OHS, UCM and IDM Directory Tiers.

WebTier

The following server pools will be used to load balance the internal and external traffic for both your FA and Auth OHS. The members contain the address for the nodes/machine names where the OHS will be running and are documented in your “Topology” tab, the internal and external ports are documented in the “Network – Virtual Hosts” tab as illustrated in the image above.

Pool Name
Member
Member
Port
Description
prd-fa-fin-int_10603
10.xxx.xx.62
10.xxx.xx.63
10603
Internal HTTP traffic for FA
prd-fa-prj-int_10605
10.xxx.xx.62
10.xxx.xx.63
10605
Internal HTTP traffic for FA
prd-fa-prc-int_10607
10.xxx.xx.62
10.xxx.xx.63
10607
Internal HTTP traffic for FA
prd-fa-sp-int_10609
10.xxx.xx.62
10.xxx.xx.63
10609
Internal HTTP traffic for FA
prd-fa-ic-int_10611
10.xxx.xx.62
10.xxx.xx.63
10611
Internal HTTP traffic for FA
prd-fa-fs-int_10613
10.xxx.xx.62
10.xxx.xx.63
10613
Internal HTTP traffic for FA
prd-fa-crm-int_10615
10.xxx.xx.62
10.xxx.xx.63
10615
Internal HTTP traffic for FA
prd-fa-scm-int_10617
10.xxx.xx.62
10.xxx.xx.63
10617
Internal HTTP traffic for FA
prd-fa-hcm-int_10619
10.xxx.xx.62
10.xxx.xx.63
10619
Internal HTTP traffic for FA
prd-fa-bi-int_10621
10.xxx.xx.62
10.xxx.xx.63
10621
Internal HTTP traffic for FA
Pool Name
Member
Member
Port
Description
prd-fa-fin-ext_10604
10.xxx.xx.62
10.xxx.xx.63
10604
External HTTP traffic for FA
prd-fa-prj-ext_10606
10.xxx.xx.62
10.xxx.xx.63
10606
External HTTP traffic for FA
prd-fa-prc-ext_10608
10.xxx.xx.62
10.xxx.xx.63
10608
External HTTP traffic for FA
prd-fa-sp-ext_10610
10.xxx.xx.62
10.xxx.xx.63
10610
External HTTP traffic for FA
prd-fa-ic-ext_10612
10.xxx.xx.62
10.xxx.xx.63
10612
External HTTP traffic for FA
prd-fa-fs-ext_10614
10.xxx.xx.62
10.xxx.xx.63
10614
External HTTP traffic for FA
prd-fa-crm-ext_10616
10.xxx.xx.62
10.xxx.xx.63
10616
External HTTP traffic for FA
prd-fa-scm-ext_10618
10.xxx.xx.62
10.xxx.xx.63
10618
External HTTP traffic for FA
prd-fa-hcm-ext_10620
10.xxx.xx.62
10.xxx.xx.63
10620
External HTTP traffic for FA
prd-fa-bi-ext_10622
10.xxx.xx.62
10.xxx.xx.63
10622
External HTTP traffic for FA
Pool Name
Member
Member
Port
Description
prd-fa-idm-int_7777
10.xxx.xx.64
10.xxx.xx.65
7777
Internal HTTP traffic for IDM
prd-fa-idm-ext_7777
10.xxx.xx.64
10.xxx.xx.65
7777
External HTTP traffic for IDM
prd-fa-idm-admin_7777
10.xxx.xx.64
10.xxx.xx.65
7777
Internal HTTP traffic for IDM

UCM

Pool Name
Member
Member
Port
Description
prd-fa-ucm-int_6300
10.xxx.xx.66
10.xxx.xx.67
6300
Internal traffic for FA

Directory Tier

Pool Name
Member
Member
Port
Description
prd-fa-policystore-int_3060
10.xxx.xx.68
10.xxx.xx.69
3060
Internal LDAP traffic for policy store (OID)
prd-fa-idstore-int_6501
10.xxx.xx.68
10.xxx.xx.69
6501
Internal LDAP traffic for id store (OVD)

Installing SSL Certificates

When provisioning Fusion Applications with a load balancer option SSL will terminate at the load balancer and not the OHS. This is known as SSL offloading and you will need to use load balancer capabilities to cypher/uncypher traffic from clients to the web application platform. The SSL certificates provide authentication between a server and a client computer, as the SSL is terminating on the load balancer you will need to install the SSL certificates on your load balancing device.

Creating Routing Rules

The majority of load balancers support some form of functionality where routing rules can be configured and used to redirect network traffic. These rules effectively allow you to reduce the number of virtual servers required as you can use the rules to inspect and then re-direct any network traffic passing through the VIP to a specific pool. Devices will behave differently so it is recommended that if possible you initially log your fields so you gain a better understanding of how your load balancer behaves and build your rules based on this understanding.

Below is a snippet of an irule used in the BIG-IP device to re-direct traffic from a single virtual server IP address to multiple pools.

when HTTP_REQUEST {
switch [string tolower[HTTP::uri]] starts_with {
  'http://fin-internal.mycompany.com' 
    { pool prd-fa-fin-int_10603 }
  'https://fin.mycompany.com' 
    { pool prd-fa-fin-ext_10604 }
  'http://prj-internal.mycompany.com' 
    { pool prd-fa-prj-int_10605 }

 

Create Profiles

The load balancer will be used to route the following traffic:

External HTTPS traffic from the end user to the Fusion Applications OHS and IDM Web Tiers

Internal HTTP traffic from the mid tiers to the Web Tiers

Internal LDAP (TCP) traffic from the mid tiers to the directory tiers (Policy and Identity Stores)

Internal TCP traffic from the mid tiers to the Oracle WebCenter Content (UCM) socket listeners

Ensure you use the correct profile for each type of traffic such as an SSL profile for the external HTTPS traffic and TCP profile for LDAP and UCM traffic. If a profile does not exist then you may need to create one.

Creating Virtual Servers

Refer to the section Planning Virtual Servers – VIPs, review your workbook entries based on your listening ports, profiles and routing rules, update the workbook if required when creating your virtual servers.

Validate Configuration

Once you have completed your load balancer configuration some simple tests can be done to validate the configuration before starting the provisioning of Fusion Applications or during scale out. The best means of doing this is by creating a script to spawn a process on your web server which will listen on the required port and return an HTTP 200 OK status.

You can then test your load balancer entries by making an HTTP request using wget or similar using your load balancer entries, if your configuration is correct then you should receive a HTTP 200 response.

The below script is missing a brace and will not run correctly without the brace, it should however give you a good idea of what the script does and works. If you are struggling to make it run then try searching for “listen port perl script” and you will find a number of hits that can assist you.

 

#!/usr/local/bin/perl

use IO::Socket;
use POSIX qw{sys_wait_h strftime};

$uname = qx{uname -n};

if (@ARGV != 1) {
print “Usage: $0 port \n”;
exit 1;
}

$port = $ARGV[0];
$time = time;

FORK: {
if ($pid = fork) {
#
# Parent. $pid is the child’s pid.
#
port() if $port;
wait;
} elsif (defined $pid) {
#
# Child
#
# form() if $form_port;
exit 0;
} elsif ($! =~ /No more process/) {
sleep 5;
redo FORK;
} else {
die “Could not fork ($!)\n”;
}
}
sub port {
my($sock, $client, $req);

$sock = IO::Socket::INET->new(
Listen => 10,
LocalPort => $port,
Reuse => 1,
Proto => ‘tcp’
);

die “Unable to listen on port $port ($!).\n” unless $sock;

while ($client = $sock->accept) {
$r = “”;
my $name = gethostbyaddr(inet_aton($client->peerhost), AF_INET);
print “$port: connect from “, $client->peerhost, ” ($name) at t+”, time-$time, strftime(” (%H:%M:%S)”, localtime(time)), “\n”;
while(<$client>) {
s/\r//;
chomp;
print “$port: received $_\n”;
$req = $_ if /GET|HEAD|PUT|POST/;
if ($_ eq “” && $req) {
($proto) = (split $req)[2] || “HTTP/1.1”;
print $client
“$proto 200 OK\n”,
“Server: Apache/1.3.19 (Unix)\n”,
“Content-Type: text/html\n”,
“\n”,
“<html><body>You have reached port $port on $uname</body></html>\n”;
print “$port: responded\n”;
last;
}
}
close $client;
}

close $server;

 

 

 

 

 

 

Comments

  1. Hi Dereck,

    Thanks for detailing each step. Have few doubt.

    As you highlighted “The following example is representative of a deployment with only one device and a minimal set of VIP’s defined.”

    1) Using same VIP for both External and Internal ULR.

    – Is it possible to have all internal URL running on port 80 and external URL on port 443?
    – If above case is possible then can keep the single External name and single Internal name? I believe keeping single internal name will create confusion for redirection when we try to access console or em url. Not sure on how single external name will work or fail.
    – I believe, either port number or External/ internal name should be different then only it can distinguish which domain to access.

    2) For UCM, Is 6300 a backend port on FA app server? Mapping will be like

    prd-fa-ucm-int_6300 : 6300 —> 10.xxx.xx.66 & 10.xxx.xx.67 : 6300

    Regards,
    Ajay

Add Your Comment