|
On Sun, Oct 02, 2005 at 01:21:43PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Sun, 2 Oct 2005, Wensong Zhang wrote:
>
> > I agree to including this one-packet feature into kernel 2.6.15+.
>
> Also, we should not sync these packets, there should be
> check in ip_vs_in before calling ip_vs_sync_conn. But ops looks
> valid only for DR/TUN setups, not for NAT, so better not to hurry
> without checking everything. Nicolas, what is the used forwarding
> method and are there any RADIUS replies?
I've also made a similar patch, so definately think a feature
like this should go in. But as Julian says, lets take it
easy and get it right.
> > In the mean while, we probably need to make a framework for
> > service-related features, so that more service related features can be
> > added and enabled/disabled. For example, for UDP-based service, we can
> > probably parse the content of payload and schedule packets according to
> > the content, which may be used for load balancing UDP-based SIP service.
>
> From some time we provide skb to all schedulers, so they can
> even reallocate and linearize skb data but we should not do it,
> there are ways for read-only access to payload.
>
> As for SIP, i'm not sure. May be it should be a scheduler
> module that has a table for hashed Call-IDs, it looks like it should
> exploit per-packet scheduling but not exactly the one-packet
> scheduling because for NAT setups the replies should be forwarded
> back.
I made some code for a customer that used the Call-ID as the key for
scheduling. Unfortunately the code was canned and I don't have a copy to
offer, but it was fairly easy to implement. I also seem to recall that
the system didn't work all that well because of the way some SIP
implementations use Call-ID, but I don't recall exactly why.
> Also, it is not possible to route replies correctly,
> _out_get can route back to client and may be that is enough but the
> per-packet scheduling has one dangerous drawback: we end up with many
> connections for one CIP:CPORT hashed in single chain. Our goal should
> be to have 5 conns if this CIP:CPORT talks to 5 real servers.
>
> So, i'm not sure how the in_get lookup can be combined
> with per-packet scheduling logic without creating many CLIENT->VS->RS
> connections. ip_vs_sync makes the problem more difficult, it does not
> tolerate multiple connections with same CIP:CPORT to VS. May be we
> can drop ops and replace it with smart per-packet scheduling that does
> not create many connections. We will always hash conns but their number
> will be reduced. User still can reduce UDP timeout to desired value.
Yeah, basically my idea is to combine one-packat scheduling,
with a scheduler that knows how to consistently map the same Call-ID
to the same real-server. That way you don't need to worry
if LVS expires the connection before the next packet comes in.
Something based on jhash() should work pretty well.
> May be there can be service flag that requests per-packet
> scheduling but with reduced number of connections. The SIP scheduler
> can request the same. This flag should be somehow propagated to
> existing connections returned from _in_get to cause scheduling and
> second conn lookup (may be out_get) that avoids duplicated connections
> between CIP:CPORT and RS - little slower but avoids creating extra
> connections.
I'm not sure why you would get duplicated connections. Perhaps I need to
look at your code more carefully. But in my mind, single-packet
scheduling just creates connections with a really short timeout. If
they happen to exist in the table when the next packet comes in, they
they get reused, but in the more likely case that they have already
expired, then an new connection is created, using a scheduling algorithm
that consistently allocates the same Call-ID to the same real-server.
--
Horms
|
