|
Hello Julian,
Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 2 Jul 2002, Roberto Nibali wrote:
>
> > Again, Julian, it is not compulsory. You can choose to have or
> > not have this feature at compilation time. I can also write a
> > text about the security implications so people selecting this
> > feature are aware of the problems. Since I use LVS a bit in a
> > different framework as other people, this patch has helped me
> > fulfilling highly important SLA's with customers which in turn
> > (if the feature wouldn't have been present) would have chosen
> > a commercial, proprietary solution.
>
> I believe, it is not more than marketing trick, at least
> for Layer 4 balancers. You know, we should always build setups
> not ignoring the security :)
My dear friend, Julian, there is the academic world and the
business world. They tend to differ a lot sometimes. I know that
I haven't created the best of all worlds but it renders managers
reading stupid magazines about commercial load balancers extremely
happy. Those are also the managers that call me if they see a
load imbalance of 5 connections on a persistency setup while
having a 2000 conns/s burst. And that's why I accepted that it
will not be incorporated into the core LVS. Because the core LVS
is an academic project which I'm very happy about.
[In the business world the LVS would have started with a design
phase of the GUI and a possible evaluation of the language we
would use for it :)]
You know me, I never ignore the security part. That's also why
I vote against having a load balancer exposed directly to the
Internet without decent countermeasures. But this is the nice
diversity that emerges from people working in different projects.
Both our ideologies can coexist, I know of OS where this isn't
the case ;).
> > > We can search the solution also in running agents in the real
> > > servers that can really tell us how hurt these connections, may
> >
> > You're dead even before they get to send you that information :)
>
> If such big attack reaches LVS then the threshold patch will
> hold the servers down for long time. We hope on QoS Ingress to
> avoid such bad things to happen but it is too late: the counters
> are increased.
?? Why? I thought an ingress qdisc would be before the LVS hook
regarding the stack. I'm confused as to why the counters would
already be increased. And I was also referring to your idea about
the RS giving feedback about their status. Maybe I think I know
what you're referring to. The ingress policy of course does only
work on outgoing connections, never on incoming ones. If I'm right
then yes, you would be right.
> Hm. As we know it is hard to define specific QoS rules
> for the real servers. Why not to create this threshold for the
> whole virtual service, something like drop_packet but per-service
> and controlled dynamically (setsockopt, as always). In theory,
Why per service?
> WLC should keep the connections equally loaded (according to the
> weight). WLC guarantees that an overloaded server is not used (much).
> It looks too pedantic to define hard limits for real servers.
But it works extremely well in practice. It's a matter of fine
tuning. Honestly I don't think people put up ten different kinds
of nodes as RS where you have different CPU/network scalability.
I think that a typical setup is n-Nodes with the same strenght.
Now of course there is the issue of different request processing
times but that's not so dynamic as you wish it to be.
> If we have too many connections to one virtual service we apply
> a drop rate (or may be something like RED in the QoS world). If
> we want the effect of the threshold patch, we stop to accept new
> connections if the conns exceed the threshold. IMO, instead of
The problem with the dynamic approach is, that you'll always
have a huge congestion reaction latency. That means, that if
we reach the potential threshold and the director realizes it,
the burst could already be over. If it is a long burst, then
my static threshold is just fine. Due to marketing reasons
randomly dropping packets is not really feasable but this
shouldn't stop you from implementing it :)
> maintaining permanent thresholds for the real servers we can
> allow the user space to maintain dynamic thresholds for the
> virtual service. We can even put the estimators in the game, they
> already know the history of each service for the last seconds.
Neat, but maybe complex. The time to compute an effective new
ip_vs_dest according to your proposal could be high unless you
find a simple algorithm.
> But we need something simple, useful for different cases.
Oh, here we are: Simple, sounds good!
> If we play with the virtual service then we don't need to touch
> the schedulers about thresholds. The only case where one
> real server can accept relatively huge number of connections
> is when persistence is used. This is the only place where I
Agreed.
> see the per-RS thresholds useful. The only danger is not to drop
> traffic which can be in fact served. It looks like we are trying
That's my concern. And if you take the drop_packet approach
this could happen unless you don't call drop_packet for quiesced
services. This might work.
> to implement something which is missing in QoS Ingress (drop_packet
> is another example, so may be it is going to die). And this is only
> the director's point of view: we see the impact by only analyzing
> the packet rates while the real servers have different view.
Here it comes again. I should really sit down and write a packet/byte
scheduler with history function. So we could analyse different
anomaly behaviors in networks and their impacts on LVS scheduling.
> Of course, it is nearly the same for plain web traffic.
Agreed.
> Also, long time ago we talked about new scheduler playing
> with the estimators. Can we implement something about it? It
> should work for traffic sensitive applications, eg. ftp.
Ask Alexandre, he's currently hacking on some mathematical scheme
based on neural networks. Two people (students) once joined the
discussion about this and proposed to do studies but I've not heared
back from them.
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
