For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

SW_159148's avatar
SW_159148
Icon for Nimbostratus rankNimbostratus
Oct 29, 2014

Balancing two Front End to two Back End servers

I have a configuration with two front end servers(Front1 & Front2) that communicate to virtual servers that load balances across two backend servers(Back1 & Back2) for a non-stand TCP ports, SQL, and 443. I have source address affinity configured with 900 seconds which is required by my vendor. The connections between frontend and backend servers are long lived.

 

Here’s my issue: When we bring down one backend(Back1) server for maintenance, all connections & persistence sourced from Front1 & Front2 move to the active backend server(Back2) as expected. When the backend server(Back1) comes out of maintenance, new connections will always go to the server that remained active(Back2). In this scenario, Front1 & Front2 will never connect to the server that went in/out of maintenance(Back1).

 

I’m trying to find a solution for this. I have the following options which I think will work, but I could use some help creating the irule for each option. If someone has any better ideas, I’d like to hear them. I would appreciate any help with this.

 

Option 1 – iRule - Mapping One-to-One If Destination Back1 IP/Port is up and destination Back2 IP/Port is up, Then send Front1 to Back1 and Front2 to Back2 If Back1 IP/Port is down, send all to Back2 IP/Port If Back2 IP/Port is down, send all to Back1 IP/Port

 

Option 2 – iRule – Clear Persistence when server goes down/up Monitor both pool members. If one member goes down and up, clear persistence.

 

Thanks,

 

application delivery
deployment
design
devops
iRules
LTM

1 Reply

  • Jason_40733's avatar
    Jason_40733
    Icon for Cirrocumulus rankCirrocumulus
    Oct 29, 2014

    For option 1, if you create two pools with priority group activation you'll get a simple iRule with low overhead.

    Pool1  primary back1, secondary back2
Pool2  primary back2, secondary back1

    Then in the iRule just split by IP of the incoming client to pool1/pool2.

    when CLIENT_ACCEPTED {     
    if { [class match [IP::client_addr] equals "10.10.10.1"] } {        
        pool pool1             
    } elseif { [class match [IP::client_addr] equals "10.10.10.2"] } {        
        pool pool2             
    } else {        
        drop
    } 
}

    Something like that might work. Option 2 I'm not as familiar with catching the change in status using an iRule. Probably could be done easily.. I just haven't done it.

    Jason