|
Hello Lars, Wensong and other scheduler researchers,
>> Not sure but I see some bad things: even if we use netlink
>>for such purposes may be we have to enqueue the packets and to dequeue
>>them after the user space has some time to get the decision. The
Is this an overhead problem you think? I only see the problem in the
queuing/dequeuing via netlink that we somehow have to stop the packet
for a while and reorder the stack queue like it is done in various QoS
modules.
> It cause my headache while writing content-based scheduler for ktcpvs
> inside the kernel, because it is complicated to specify this kinds of
> rules inside the kernel.
Our company recently 'aquired' a new guy from California which was
working on implementation of huge (>US 500'000$) hardware loadbalancers.
They claim to have an own scripting like language for content-based
scheduler for Layer7 additionally to normal health checks in Layer 4.
And the cool thing is, that they did part of their hardware programming
in with the Linux kernel (heavy modifications). But to get to the point,
he was referring to scheduling algorithms you mention below and which
already have been discussed here a lot. I don't know who, if anyone, is
working/studying about such dynamic-feedback weight adaption (dfwa)
schedulers and what the most important feedback algorithms are. But I
can certainly ask him what parameters they used for their scheduler. I
had a very long talk about load balancing with him and he's very
valuable input from industry.
The problem is, that in future we might get really big projects for load
balancing and there you have to provide every single detail of your load
balancer. And one thing implementation managers like to see is QoS,
service assurance and proper defined SLA's. We can do QoS with LVS if
you know how :). My threshold patch and the implemented TCP defense
strategies can assure service assurance to a certain extent but we have
no means to provide SLA support. I mean that we can't assure the company
putting their e-commerce project into a datacenter, that we only let
their servers saturate to 80%, so server maintainance costs for that
company drop to a minimum. To do this we need a dfwa scheduler and QoS
to reduce the stream. Of course a dfwa scheduler, as the name implies,
needs some time to be adjusted but at least we could start writing
professional SLA's for customers.
> It will be better if we write content-based scheduler for ktcpvs in
> user-space. IMHO, it might be not necessary to write user-space scheduler
> for IPVS, because it doesn't parse the content of packets.
Has anyone done speed/overhead tests with ktcpvs? Another thing I wanted
to mention is, that for static unencrypted content, like for example a
'GET /index.html' we certainly don't need a Layer7 to do content based
scheduling. Thanks to the match selector of the iproute2 framework we
can match and mark byte patterns in a stream and load balance the fwmark
based services. This is how IDS systems work. No need to do this in
Layer7. The only thing we need is a tool that converts static
unencrypted content to a byte pattern that can be matched in the TCP
stream. For dynamic content based scheduling we need a possibility to
fallback to ktcpvs. Any chance of them working together?
> Dynamic-feedback weight-adaption algorithm will give the scheduler more
> information about the server status, it is simple and fast, and can make
> servers well balanced too. :)
I don't recall all the discussions over the years on this list about the
parameters needed to provide useful information but I'm more than happy
to have another long talk with this guy in our company. He might
certainly be able to give us valuable information about the
implementation details of such dynamical schedulers.
Best regards,
Roberto Nibali, ratz
|
