Vip target VIP

If you know the pool name associated with the virtual server, you could use 'active_members pool_name' (Click here) to verify there is one or more pool member up before selecting the corresponding VIP for the request.

 

 

Aaron

Thanks for the reply... I guess the best method is to disable "all nodes" in a pod_pool rather than disabling the VIP itself. I'll clean up the logic a little to include monitoring the pods and post the final iRule after testing.

 

 

 

Yep. There isn't a method for getting the state of a VIP in an iRule. As we've just recently gotten the ability to specify a virtual server for a request, this wasn't an issue before. If you'd like to see this functionality considered for addition, you could open a case with F5's support group (https://websupport.f5.com).

 

 

Aaron

Aaron's exactly right here, as usual. There isn't much monitoring of VIP state in iRules yet, but I wouldn't be surprised if we saw more of that soon, as we're able to use virtuals as targets now in iRule logic.

 

 

Definitely send in a case asking for this, though, if it's something that would be beneficial to you.

 

 

Colin

We decided to modify the logic slightly... Instead of RR connections to the Pod VIP's we allow the first connection (no cookie set) to go to a "master pool" which includes all the nodes contained in each pod. We will use least connections (LB Algorithm) on this master pool to ensure the new request goes to not only the most available pod but also the server with the least connections. My thoughts are that once the logic sends this initial connection to the most available node, we can set a persist cookie on the reply. This cookie name/value is being set correctly based on server info in the podx_class but I need to include the proper persist value (Server:port) inside the cookie.

 

 

Question: Can anyone tell me how to set the value of the cookie so when the return comes back, and the iRule logic sends the return request to the proper VIP, the cookie can be used to persist to the proper node inside the pod pool?

 

 

Thanks,

 

 

when HTTP_REQUEST {

 

set reqcookie [findstr [HTTP::cookie names] "my_cookie"]

 

if { $reqcookie starts_with "my_cookie"} {

 

set podcookie [findstr $reqcookie "my_cookie" 9 " "]

 

set podvip [findclass "$podcookie" $::pod_ip " "]

 

virtual $podvip

 

} else {

 

pool master_pod_pool

 

}

 

}

 

when HTTP_RESPONSE {

 

if { [matchclass [IP::server_addr] equals $::pod1_class] } {

 

HTTP::cookie insert name "pod1" value [IP::server_addr]

 

} elseif { [matchclass [IP::server_addr] equals $::pod2_class] } {

 

HTTP::cookie insert name "pod2" value [IP::server_addr]

 

} elseif { [matchclass [IP::server_addr] equals $::pod3_class] } {

 

HTTP::cookie insert name "pod3" value [IP::server_addr]

 

}

 

}

Are you serving data on more than one port inside the pools? If you're not, then you just need the IP address of the member to reference it once you're at the proper virtual.

 

 

pool member should be fine.

 

 

Colin

Here's what I have come up with. This will only have one VIP, and the logic will maintain POD/pool persistence, but not always to the same server. Please let me know what you all think, and where I can improve things. I wanted to create a switch structure in the HTTP_RESPONSE section, but couldn't get through the syntax due to the matchclass requirements. Thanks in advance...

 
   Assumptions: 
 One VIP with this iRule assigned and a default pool of pool_all_servers. 
 One pool for each pod of servers, and another for all servers (3 total in this example). 
 There is an address dataset for each pod that includes the IP's for every server in that pod. 
 Ramp up time set to 300 sec on each of the pod pools, but not the pool_all_servers pool. 
  
  
 when HTTP_REQUEST {  
 LB::mode leastconns 
 set strPoolID [HTTP::cookie "pod"]     
 if { $strPoolID !=""} { 
    if {[active_members pool_www_pod_$strPoolID] > 0} { 
              pod cookie identified and used to load balance to that pod/pool 
 pool pool_www_pod_$strPoolID 
     } else { 
  if original pool is down, use the default pool.. 
  User will lose session, but will get page. 
 HTTP::cookie remove "pod" 
         pool [LB::server pool] 
         log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool pool_www_pod_$strPoolID is down" 
         } 
     } 
 else { 
  if no pod cookie is present - ie new session, then use the default pool and lb mode least connections. 
     log local0. "using pool [LB::server pool] since we dont have a pod yet" 
   pool [LB::server pool] 
 } 
 } 
 when HTTP_RESPONSE {  
 if { [matchclass [IP::server_addr] equals $::dg_pod_1_ips] } {  
 set strPodNumber "1"  
 } elseif { [matchclass [IP::server_addr] equals $::dg_pod_2_ips] } {  
 set strPodNumber "2" 
 } else { 
 log local0. "we have problems getting value of pod cookie or it isnt 1 or 2" 
 } 
 HTTP::cookie insert name "pod" value $strPodNumber path / 
 } 
 

If anyone could provide some feedback, it would be greatly appreciated. We think we have the logic down, but want to verify want kind of impact this will have on CPU, etc. Is there a better (read: more efficient) way of accomplishing this? Thanks in advance.

Brice,

 

 

Your logic gets you back to the correct pod pool but it does not account for node persist once inside the pool. As Colin stated in a previous reply,

 

setting the server IP as the value inside the cookie should be enough for LTM to ensure the proper node selection. This implies that my latest iRule logic

 

should work fine as is. Let's take this offline and discuss your thoughts on eliminating the PodVip. It appears to be a solid alternative. We would simply need

 

to insert the cookie with the value of the pod pool name and Node IP. This would be a simple change to your iRule where $strPodNumber would set as the

 

pool name and we would include [IP::server_addr]as a second value inside the cookie.

 

 

GZ

This may be simpler & more efficient approach, esp if the default pool idea is working well and you'd like to support it still:

 

 

If you use 2 cookies - one for pod choice and one for LTM persistence, you can let LTM built in persistence options do the heavy lifting re:persistence mgmt, and use your existing rule logic to set the pod cookie. To enforce persistence across multiple pools, apply a persistence profile with a custom cookie name. That way the system will look for or insert the same cookie name in the default pool and the pod-specific pool...

 

 

That way you'd avoid the overhead of having to parse both values from the same cookie, and of building & managing the persistence cookie.

 

 

HTH

 

/deb