01-May-2014 14:45
My client wants a VIP listening on 9000, which is no problem. He then wants both pool members to listen on 9000 and 9050 at the same time. When his Web Server hits the VIP on 9000, the F5 directs the request to one of the members (round robin) on 9000. That part works fine. He also wants the web server to hit the 9000 VIP on port 9050, then have one of the two members answer on 9050. I've done one to one port translation before, but not one to many port translation. Can an iRule handle this or is this just not possible?
This application is Jolt. Tuxedo runs on top of that and handles some other processes. These all run under PeopleSoft. From what I've read, and there's not much info out there, the Web Server should not have a load balancer (F5 in my case) between the Application Servers. Has anyone encountered this Application or similar request?
Example on the F5:
VIP = 9000 Pool Member 1 = 9000 & 9050 Pool Member 2 = 9000 & 9050
01-May-2014 15:32
If I am reading the question correctly, it sounds like the Web server needs to communicate to the BIG-IP on port 9000 and on port 9050. Try creating two vs's using the same ip address; one using port 9000 and one using 9050. Create a pool for each with the members using the correct port. Since the BIG-IP is a default deny system, it will not listen for requests on port 9050 from the web server without the virtual server being created and enabled. Sounds like persistence is going to be required as well since you want the same member to respond on each port. Select a persistence method, such as source affinity persistence, and check the box "match across services" to force the same node to respond to the web server port 9000 and 9050.
02-May-2014 14:04
02-May-2014 14:37
03-May-2014 00:47
Destination Port 9000 to VIP to 9050 member - application fails.
Destination Port 9050 to VIP to 9000 member - application fails.
it fails because virtual server has no idea it has to translate destination port to 9050 or 9000 (since pool member is listening on any port).
Destination Port 9000 to VIP to 9000 member - application works.
Destination port 9050 to VIP to 9050 member - application works.
it works because virtual server port and pool member port are same.
06-May-2014 14:22
03-May-2014 00:47
Destination Port 9000 to VIP to 9050 member - application fails.
Destination Port 9050 to VIP to 9000 member - application fails.
it fails because virtual server has no idea it has to translate destination port to 9050 or 9000 (since pool member is listening on any port).
Destination Port 9000 to VIP to 9000 member - application works.
Destination port 9050 to VIP to 9050 member - application works.
it works because virtual server port and pool member port are same.
06-May-2014 14:22
23-Feb-2015 06:24
We are considering the same solution. Were you successful?
Oracle specialist in PeopleSoft to redesign the architecture of PeopleSoft so it scales better. One of the changed is that they requested a VIP to load balance Jolt requests.
02-Jul-2015 08:03
Did you ever get this working? We're trying to do a similar thing in our PeopleSoft environment with the F5s and I haven't been able to get it completely working
19-May-2023 11:05
This is the only thread I can find about load balancing JOLT for Oracle Peoplesoft. So I'm going to post what I had to do to get JOLT through the f5, in hopes it will save a little frustration for someone else.
The JOLT protocol uses multiple ports, kinda like passive FTP. The initial connection is on an instance configured port, usually 9200/TCP. Then the server specifies a temporary port for the rest of the conversation, and the client makes a new TCP connecton to that port, often something like 9201, 9202, 9203...
To get it through the f5 LTM, I had to put it on it's own destination IP, and use the "any" port.
ltm pool sc2fi-dev_jolt {
description "sc2fiX-dev jolt"
members {
10.1.122.144:any {
address 10.1.122.144
priority-group 10
}
10.1.122.145:any {
address 10.1.122.145
priority-group 1
}
}
min-active-members 1
min-up-members 1
}
ltm virtual udfin-dev_jolt {
description "udfin jolt"
destination 10.2.56.11:any
ip-protocol tcp
mask 255.255.255.255
pool sc2fi-dev_jolt
profiles {
tcp-lan-optimized { }
}
rules {
log
}
source 0.0.0.0/0
source-address-translation {
pool dr-sc-app
type snat
}
translate-address enabled
translate-port disabled
vlans {
subnet56
}
vlans-enabled
vs-index 46
}
net packet-filter udfin-dev-jolt {
action accept
order 320
rule "dst host 10.2.56.11 and proto TCP and dst portrange 9000-9500 and ( src net 10.2.4.128/27 or src net 10.1.11.0/24 )"
vlan subnet56
}