Forum Discussion

TMcGov_92811's avatar
TMcGov_92811
Icon for Nimbostratus rankNimbostratus
Feb 18, 2009

Forcing the use of a new pool and new member based on the current pool and member

I have a situation where I have an iRule that will direct HTTP requests to a certain pool based on a URI. Other traffic will go to the default pool. Here is a snippet of that.

 

 

when HTTP_REQUEST {

 

if { [HTTP::uri] contains "/cf/" or [HTTP::uri] contains "/hf/"} {

 

pool Pool-A

 

} else {

 

pool Pool-B

 

}

 

}

 

 

Here are Pool A's members

 

10.77.177.78 (ohs1)

 

10.77.177.79 (ohs2)

 

10.77.177.80 (ohs3)

 

 

Here are Pool B's members

 

10.77.177.88 (ohs4)

 

10.77.177.89 (ohs5)

 

10.77.177.90 (ohs6)

 

 

Usually, a user will hit the default pool, Pool-B. Then they will click on a link that will contain /cf/ or /hf/ and they will be routed to the Pool-A. In this Oracle webserver environment, we want to "pin" together members of these two pools. In this case, .78 and .88; .79 and .89; and .80 and .90. The desired effect is that that if a user hits ohs4 in Pool-B, we want to make sure that if they are routed to Pool-A because of the URI, they hit their corresponding pinned member, ohs1. Similarily, original requests that hit ohs5 should hit ohs2 for /cf/ and /hf/ URIs, and ohs6 to ohs3.

 

 

Is there a way to accomplish this ?
application delivery
dev
devops
iRules
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Feb 18, 2009
    I believe so.

     

    You might want to take a look at the following. Keep in mind that this is more untested psudeo code. It's simply to get you thinking about how it can be used to pin down. Of course there are other briliant minds out there that probably have a better answer and I hope they do.

     

     

     
 when HTTP_REQUEST {  
 switch -glob [HTTP::uri] { 
 "*/cf/*" {  
 switch $pin { 
 "10.77.177.88" { node 10.77.177.78 80 } 
 "10.77.177.89" { node 10.77.177.79 80 } 
 "10.77.177.90" { node 10.77.177.80 80 } 
 default { pool Pool-A } 
 } 
 } 
 "*/hf/*"  
 {  
 switch $pin { 
 "10.77.177.78" { node 10.77.177.88 80 } 
 "10.77.177.79" { node 10.77.177.89 80 } 
 "10.77.177.80" { node 10.77.177.90 80 } 
 default { pool Pool-B } 
 } 
 } 
 } 
 when LB_SELECTED { 
 set pin[LB::server addr] 
 }

     

     

    hope this helps

     

    CB
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Feb 19, 2009
    It might get a bit more complicated than that:

     

     

    - Can a client ever make a request directly to Pool-A first? If so, do you want to also map the pool members the other way to Pool-B?

     

     

    - What do you want to happen if one pool member from Pool-A is down but the corresponding pool member from Pool-B is up?

     

     

    I think it might be cleaner to use persistence to enforce this logic. When a request is made to either pool, you could insert a persistence cookie for both pools that maps member one from Pool-A to member one in Pool-B.

     

     

    You could also configure monitors that would mark both corresponding pool members down if either paired pool member was down.

     

     

    Aaron