iRule to test tcp availability

Is this a scenario where an application runs on a specified port and you have pools defined for each application based on that port?

 

 

If so, I think a TCP monitor applied to each pool might be a safe bet. With a given number of servers in a pool, the monitor would keep track of which server was alive at any given moment (within the monitor's window).

Kevin,

 

Thanks for the response! Yes, each application runs on a specified port. I am trying to avoid a pool per application because that would be around 100 pools and that number will grow with time. I'm really looking for something dynamic so I don't have to create a new pool each time an application is added.

 

 

--

 

Kris Dames

 

Posted By krisdames on 03/11/2013 04:25 PM

 

 

The whole setup is essentially a high availability scheme.

 

 

 

 

Can you provide more detail as to why it is setup this way? This does sound like a mess.

 

 

Chris

 

I still tend to believe the pool option is your best approach, and you can certainly automate the management and creation of these pools with some pretty simple TMSH scripts.

 

 

That said, and this is a little on the wacky side, but you might also be able to do something like this:

 

1. Maintain a data group of all of the applications by port number (essentially a list of ports - assuming all of the servers will serve every application).

 

 

2. Create an internally-accessible "service" virtual server that maintains a table. It would also have an iRule that both populates/creates the table and that accepts simple HTTP requests to update the table entries. The table consist of one subtable per application (port) and each subtable defines the status of each IP per that port.

 

Ex. subtable "9500":

 

IP1: down

 

IP2: down

 

IP3: up

 

IP4: down

 

IP5: down

 

IP6: down

 

 

3. A monitor script attached to the service VIP that cycles through the data group (or subtables) and updates the status of each value (up or down) in the subtables - via a simple HTTP call to the VIP.

 

 

4. You application virtual servers would then check for the one "up" value in a given subtable before forwarding to the node.

 

 

It's absolutely imperative that the service VIP not be accessible to users. Also, depending on the frequency of the VIP's monitor and how many applications it has to cycle through, it may not respond as quickly as having a monitor attached to individual pools.

 

what about this one?

[root@ve10:Active] config  b virtual bar list
virtual bar {
   snat automap
   pool foo
   destination 172.28.19.252:any
   ip protocol 6
   rules myrule
}
[root@ve10:Active] config  b pool foo list
pool foo {
   members {
      200.200.200.101:any {}
      200.200.200.102:any {}
      200.200.200.111:any {}
      200.200.200.112:any {}
   }
}
[root@ve10:Active] config  b rule myrule list
rule myrule {
   when CLIENT_ACCEPTED {
  set c 1
  log local0. "--"
  log local0. "\[table lookup tbl[TCP::local_port]\] [table lookup tbl[TCP::local_port]]"
  if { [table lookup tbl[TCP::local_port]] ne "" } {
    node [table lookup tbl[TCP::local_port]]
    log local0. "node [table lookup tbl[TCP::local_port]]"
  }
}
when LB_SELECTED {
  log local0. "\[LB::server addr\] [LB::server addr]"
}
when LB_FAILED {
  if { $c < [active_members foo] } {
    LB::reselect pool foo
    log local0. "LB::reselect pool foo"
    incr c
  }
}
when SERVER_CONNECTED {
  table set "tbl[TCP::remote_port]" [IP::remote_addr]
  log local0. "table set \"tbl[TCP::remote_port]\" [IP::remote_addr]"
  log local0. "connection [IP::client_addr]:[TCP::client_port] > [clientside {IP::local_addr}]:[clientside {TCP::local_port}] > [IP::remote_addr]:[TCP::remote_port]"
}
}

 1st request: load balance and save successful pool member

Mar 12 22:17:36 local/tmm info tmm[4950]: Rule myrule : --
Mar 12 22:17:36 local/tmm info tmm[4950]: Rule myrule : [table lookup tbl80]
Mar 12 22:17:36 local/tmm info tmm[4950]: Rule myrule : [LB::server addr] 200.200.200.101
Mar 12 22:17:36 local/tmm info tmm[4950]: Rule myrule : table set "tbl80" 200.200.200.101
Mar 12 22:17:36 local/tmm info tmm[4950]: Rule myrule : connection 172.28.19.251:43695 > 172.28.19.252:80 > 200.200.200.101:80

 2nd request: send request to the pool member previously saved

Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : --
Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : [table lookup tbl80] 200.200.200.101
Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : node 200.200.200.101
Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : [LB::server addr] 200.200.200.101
Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : table set "tbl80" 200.200.200.101
Mar 12 22:17:44 local/tmm info tmm[4950]: Rule myrule : connection 172.28.19.251:43696 > 172.28.19.252:80 > 200.200.200.101:80

 3rd request: if server is changed to another pool member (i.e. 200.200.200.101:80 is no longer availabe), load balance and save new successful pool member

Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : --
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : [table lookup tbl80] 200.200.200.101
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : node 200.200.200.101
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : [LB::server addr] 200.200.200.101
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : LB::reselect pool foo
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : [LB::server addr] 200.200.200.111
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : table set "tbl80" 200.200.200.111
Mar 12 22:18:02 local/tmm info tmm[4950]: Rule myrule : connection 172.28.19.251:43697 > 172.28.19.252:80 > 200.200.200.111:80

Kevin,

 

Thank you kindly for the response. I think this is a good idea and I believe it would work. The only issue I have with it is that I would have to maintain the data group and I am willing to sacrifice some overhead on the F5 in order to make this as dynamic as possible.

 

--

 

Kris

 

 

A 100-application data group should only need 100 entries. But then again 100 individual pools wouldn't be a big deal either - and would make your monitoring efforts MUCH more robust. The big issue seems to the management of each. Enter iControls and TMSH management scripts. ;)

nitass,

 

 

I had to set the increment variable to 0 instead of 1 because the test was stopping before the last pool member was tested. Other than than, the logic is great and it seems to be working (our developers are performing more rigorous testing as I speak). This is exactly what I was looking for because it requires no maintenance. Well done!

 

 

--

 

Kris

 

 

I had to set the increment variable to 0 instead of 1 because the test was stopping before the last pool member was tested.oh yes, thanks!