LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Release new code: Scheduler for distributed caching

To: Joe Cooper <joe@xxxxxxxxxxxxx>
Subject: Re: Release new code: Scheduler for distributed caching
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Thomas Proell <Thomas.Proell@xxxxxxxxxx>
Date: Wed, 25 Oct 2000 11:10:07 +0200 (MET DST)
Hi!

> > # 1. Schedule based on Class C destinations: select squid server
> > ipchains -A input -d 0.0.0.0/0.0.3.0 80 -p TCP -m 1
> > ipchains -A input -d 0.0.1.0/0.0.3.0 80 -p TCP -m 2
> > ipchains -A input -d 0.0.2.0/0.0.3.0 80 -p TCP -m 3
> > ipchains -A input -d 0.0.3.0/0.0.3.0 80 -p TCP -m 4

Intresting. What will happen, if one cache is down, or comes up again,
or if another is added for performance reasons? You'll have to use
the netmask 0.0.4.0 if one is added or 0.0.2.0 if one is removed.
How many IP-addresses will be re-assigned to a new cache with this
change? AFAIK nearly all, since every cache won't receive every
third, but every fourth address.
So, if changes are made, you'll experience very bad cache hits.

This is not the case with consistent hashing. Only the theoretical
minimum quantity of addresses are reassigned.
 
> > # 2. Split the incoming traffic
> > # 3. Route the packets to the squid servers
> 
> While I haven't tried this (or Thomas' code), this leaves the question
> of weighting completely unanswered.  The hash based scheduler written by
> Thomas also doesn't have weighting...but it should be a relatively
> simple matter to add it.  I don't see that simple routing lends itself
> very well to the kind of flexibility that a hash based scheduler can. 
> But I may be wrong.

You're right. The weighting will be implemented today.

Next question is hot spots -- frequently demanded addresses.
At first, I was thinking the problem isn't very big, but
tests with real workloads showed different results.
I found a good solution for that, too, and it will be implemented
this year.

Next: WE need tunneling. The squid is configured as a transparent 
proxy and will answer directly to the client, what improves the
speed dramatically. 
Can you route through a tunnel with your solution? I don't think so.
If this is possible - tell me. Would be a nice chapter in mt thesis.

> >         Yes, it is simple even without using LVS :) You can even
> > create netfilter module for 2.4 to mark the packets in different
> > way (hashes, etc). Then it is a plain routing.

Please don't tell me, that the work was for nothing :-)
Can we implement tunneling with a netfilter module?
 

Thomas



<Prev in Thread] Current Thread [Next in Thread>