Forum Discussion

mski_151743's avatar
mski_151743
Icon for Nimbostratus rankNimbostratus
May 01, 2014

Jolt/Tuxedo Pool Member Question

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

 

11 Replies

  • Greg_Crosby_319's avatar
    Greg_Crosby_319
    Historic F5 Account

    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.

     

    • mski_151743's avatar
      mski_151743
      Icon for Nimbostratus rankNimbostratus
      Hi Greg, Right now, I have a port 9000 VIP (IP = 10.10.10.10 for example) listening on ANY port for testing purposes and Port Translation is turned on. No other pools are using this VIP in this QA environment. I have both pool members also listening on ANY port for testing purposes. Would this be the same as adding two new members with the other pair of ports? If I am understanding your suggestion correctly, do I need to have two members listing on 9000 and two members listening on 9050 in the same pool? I will try your suggestion, but I have to wait until 5/8. Thanks! Matt
    • mski_151743's avatar
      mski_151743
      Icon for Nimbostratus rankNimbostratus
      Sorry for the book, but here's some additional info in case it changes your suggestion above. I changed some info around, however, the ports are what I am to be using. I originally had the VIP listening on 9000, but opened it up to ANY for testing purposes because the application tests were failing across the F5. I have port translation checked on the VIP. At the pool level, I also opened them up to ANY ports for testing purposes. VIP: Name: test-vip-9000 IP: 10.1.5.20 Destination Port: Any Pool: Name: test-pool-9000 Health Monitors: test_monitor_9000 test_monitor_9050 Members: 10.1.8.20(0) 10.1.8.21(0) The application architect wants his Web server to start a session on destination port 9000, hit the VIP then go to 9050 or vice versa. His application works fine when his web server initiates a session on destination port 9000, hits the VIP and goes to a 9000 member. It also works when the destination port 9050 hits the VIP and goes to a 9050 pool member. To sum it up: Web Server destination port to VIP to member tests: Destination Port 9000 to VIP to 9000 member - application works. Destination port 9050 to VIP to 9050 member - application works. Destination Port 9000 to VIP to 9050 member - application fails. Destination Port 9050 to VIP to 9000 member - application fails.
  • 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.

     

    • mski_151743's avatar
      mski_151743
      Icon for Nimbostratus rankNimbostratus
      I agree with your response. My question is: Is this possible? I would say no. I have never seen a load balancer listen on one port at the VIP level then translate to multiple ports and multiple members in one pool. The application architect says the above tests should work, but I don't see how the VIP would understand when to send traffic to a 9000 member or a 9050 member when the destination port is 9000 for instance.
  • 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.

     

    • mski_151743's avatar
      mski_151743
      Icon for Nimbostratus rankNimbostratus
      I agree with your response. My question is: Is this possible? I would say no. I have never seen a load balancer listen on one port at the VIP level then translate to multiple ports and multiple members in one pool. The application architect says the above tests should work, but I don't see how the VIP would understand when to send traffic to a 9000 member or a 9050 member when the destination port is 9000 for instance.
  • 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.

     

  • 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

     

  • Hi Guys, Do you have any link for steps how to configure BIG IP LB to load balance JSL traffic among multiple Tuxedos. Thanks very much in advance!

     

  • doke2's avatar
    doke2
    Icon for Nimbostratus rankNimbostratus

    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
    }