Difference between revisions of "Talk:Locality-Based Least-Connection Scheduling"

From LVSKB
Jump to: navigation, search
 
(Expiration algorithm)
Line 24: Line 24:
 
Please correct me if I am wrong.
 
Please correct me if I am wrong.
 
:[[User:Jkrzyszt|Jkrzyszt]] 02:31, 16 September 2006 (CST)
 
:[[User:Jkrzyszt|Jkrzyszt]] 02:31, 16 September 2006 (CST)
 +
--------
 +
When I started to use the lblc algorithm I found that it provides an extra feature
 +
- some kind of connection persistance.
 +
However, the expiration algorithm, as it is, does not take into account
 +
if the destination map just to be removed is related to any active connections.
 +
This way, connection persistance is not guaranteed, even with very high weights set.
 +
 +
You may ask why not to use the persistance option.
 +
Well, the lblc algorithm is designed to be used together with fwmark in transparent cache clusters.
 +
If such a cluster is accessed through another proxy (that applies access control rules, for example),
 +
using classical persistance solution is not an option
 +
because all the traffic from this proxy would be directed to the same cache.
 +
 +
I am going to investigate the sources if it would be possible to check for no active
 +
(or maybe even inactive) conections using the specific map before it can be removed
 +
from the list.
 +
 +
I would appreciate any comments on this matter.
 +
 +
:Janusz [[User:Jkrzyszt|Jkrzyszt]] 22:20, 18 September 2006 (CST)

Revision as of 14:20, 18 September 2006

Expiration algorithm

I find it usefull for understanding why subsequent connections to the same destination IP address may not follow the same path.

ServerNode[] is a list of maps from destination IP address to server;
C(ServerNode[]) is the current number of not NULL maps in the list;
Now is the current system time;
net.ipv4.vs.lblc_expiration is the sysctl parameter (default 24 hours).

Every 1 minute:

Count = C(ServerNode[]);
if (Count > 16384) then {
  for (dest_ip = 0.0.0.0;
       C(ServerNode[]) > min((Count-16384)*4/3, 8192);
       dest_ip++) {
    if (ServerNode[dest_ip].server is not NULL AND
        ServerNode[dest_ip].lastuse < Now - 6 minutes) then
      ServerNode[dest_ip].server = NULL;
  }
}

Every 30 minutes:

for (dest_ip = 0.0.0.0; dest_ip < 255.255.255.255; dest_ip++) {
   if (ServerNode[dest_ip].server is not NULL AND
       ServerNode[dest_ip].lastuse < Now - net.ipv4.vs.lblc_expiration) then
     ServerNode[dest_ip].server = NULL;
}

Please correct me if I am wrong.

Jkrzyszt 02:31, 16 September 2006 (CST)

When I started to use the lblc algorithm I found that it provides an extra feature - some kind of connection persistance. However, the expiration algorithm, as it is, does not take into account if the destination map just to be removed is related to any active connections. This way, connection persistance is not guaranteed, even with very high weights set.

You may ask why not to use the persistance option. Well, the lblc algorithm is designed to be used together with fwmark in transparent cache clusters. If such a cluster is accessed through another proxy (that applies access control rules, for example), using classical persistance solution is not an option because all the traffic from this proxy would be directed to the same cache.

I am going to investigate the sources if it would be possible to check for no active (or maybe even inactive) conections using the specific map before it can be removed from the list.

I would appreciate any comments on this matter.

Janusz Jkrzyszt 22:20, 18 September 2006 (CST)