Well, here is my issue with that:
Sticky works just fine if it is based on source IP address - and then you
are right, sticky would send anything with the same source IP to the same
server - and then the LB needs to kill the half closed session after X
amount of time.
The problem is that for Internet traffic, source IP is not the best option.
Can you say AOL? You have hundreds of thousands of users showing up from
one of (I think) 5 mega-proxy servers - and during any one session - they
may change IP address to one of the other 5. This makes for really BAD
load-balancing.
The solution is - hate to say it - cookies. Unfortunately, cookies do not
work in a DSR mode. Why you may ask? Because in order for cookie
persistence to work, the LB must function as a TCP proxy - that way they can
actually receive the header information BEFORE sending it on. Without any
way to control the web server (read agent), the outbound packet must also go
through the LB - so the TCP sequence numbers can be re-written to match what
the client expects to see.
If you are talking about SSL, then you might be sticky using SSL session
ID's. Can you say IE v5.0? In this version of the popular (most popular)
browser, the browser terminates the SSL session ID cache every 3-8 minutes
causing a renegotiation of the SSL session ID. Again BAD load-balancing as
the client will get re-load-balanced every 3-8 minutes.
The solution here is - hate to say it - cookies behind some sort of SSL
termination device. That way, the cookie will be in clear text when the LB
gets it to make the decision. Again - traffic must go through the LB in
both directions.
That's why I asked. Although I agree with others that the whole "loop-back"
adapter thing seems a little kludgy (although, I've done worse), I used to
believe in the merit of the DSR. However, as someone else pointed out, the
throughput of the devices really isn't a bottleneck anymore - and as I
pointed out in another message, even if it IS a bottleneck, it is one which
most people just won't reach - not to mention the fact that any firewalls
they have will be much more of a bottleneck than ANY of the LB's on the
market today.
Again, just my .02. Plus I was hoping that maybe you knew of a better way
to do persistence. Cookies still have a really bad aura to them from the
public's point-of-view. On the other hand, most of the public probably
doesn't know how to turn cookies off anyway. :-)
----- Original Message -----
From: "Nimesh Vakharia" <nvakhariIZZATgenx.net>
To: <lb-lIZZATvegan.net>
Sent: Friday, February 16, 2001 8:40 PM
Subject: Re: [load balancing] Cascading switches off of a Foundry switch
>
> Sticky supposedly does the job. I've feeling it maintain state in DSR and
> watches for the final FIN exchange or Reset and finally timeouts to clear
> out the conn table. This is a Nimesh-Theory so might want to look into the
> docs...
>
> Nimesh.
>
> On Fri, 16 Feb 2001, KJ & JC Salchow wrote:
>
> > How do you handle persistent connections?
> >
> > Ken
> >
> > ----- Original Message -----
> > From: "Nimesh Vakharia" <nvakhariIZZAThotjobs.com>
> > To: <lb-lIZZATvegan.net>
> > Sent: Thursday, February 15, 2001 4:54 PM
> > Subject: Re: [load balancing] Cascading switches off of a Foundry switch
> >
> >
> > >
> > > Why don't you try impelmenting DSR(direct server return)? You will
have to
> > > make some modifications on your web/mail servers (add loopbacks) but
then
> > > you don't have to worry about the traffic flow. You should find some
docs
> > > on foundry's website.
> > > We use it for smtp/www/ftp/https LB. Once setup you don't have to
> > > look at it.
> > >
> > > Nimesh.
> > >
> > > On Thu, 15 Feb 2001, tony
> > > bourke wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > Not necessarly true... the only thing that needs to happen is that
> > > > L2 traffic flows through the load balancer at some point between the
> > > > Internet and the servers. This gives the load balancer the chance
to
> > > > re-write the packets on the way in and on the way out.
> > > >
> > > > Source NATs aren't necessary if everything is on the same subnet.
> > > >
> > > > Tony
> > > >
> > > >
> > > > On Thu, 15 Feb 2001, Gary E. Miller wrote:
> > > >
> > > > > Yo Ryan!
> > > > >
> > > > > Unless the virt hosts are DIRECTLY connected to the ServerIron
this is
> > not
> > > > > sufficient. You also need something like this:
> > > > >
> > > > > server source-ip [ip] [mask] [gw]
> > > > >
> > > > > server real ...
> > > > > source-nat
> > > > >
> > > > > RGDS
> > > > > GARY
> > > >
> >
> --------------------------------------------------------------------------
> > -
> > > > > Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
> > > > > gemIZZATrellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
> > > > >
> > > > > On Thu, 15 Feb 2001, Ryan Tucker wrote:
> > > > >
> > > > > > Date: Thu, 15 Feb 2001 16:39:34 -0500
> > > > > > From: Ryan Tucker <rtuckerIZZATnetacc.net>
> > > > > > Reply-To: lb-lIZZATvegan.net
> > > > > > To: lb-lIZZATvegan.net
> > > > > > Subject: Re: [load balancing] Cascading switches off of a
Foundry
> > switch
> > > > > >
> > > > > > We do have server real/server virts in there, but I clipped most
of
> > them
> > > > > > out for security reasons. I just realized that the example I
*did*
> > > > > > paste was from a few months ago, when I last tried to get this
to
> > work,
> > > > > > and naturally it's incorrect ;-) The pattern is pretty much the
> > same.
> > > > > >
> > > > > > server real foo1 ip
> > > > > > port smtp
> > > > > > port pop3
> > > > > > port imap4
> > > > > >
> > > > > > server real foo2
> > > > > > port smtp
> > > > > > port pop3
> > > > > > port imap4
> > > > > >
> > > > > > server virtual foo
> > > > > > port smtp
> > > > > > port pop3 sticky
> > > > > > port imap4 sticky
> > > > > > bind smtp foo1 smtp foo2 smtp
> > > > > > bind pop3 foo1 pop3 foo2 pop3
> > > > > > bind imap4 foo1 imap4 foo2 imap4
> > > > > >
> > > > > > The one problem I run into with Foundry's documentation is
> > translating
> > > > > > what I want into what the manual calls it. :-) I'm going to
rescan
> > > > > > today, tho, based off of stuff I've learned over the last few
weeks
> > > > > > (this list is a very useful resource for seeing how other people
are
> > > > > > doing stuff :-). -rt
> > > > > >
> > > > > > On Thu, 15 Feb 2001 12:46:18 -0800 (PST), "Gary E. Miller"
> > <gemIZZATrellim.com> wrote:
> > > > > > > Yo Ryan!
> > > > > > >
> > > > > > > I have been playing with serveral of these for the last few
> > months.
> > > > > > >
> > > > > > > >From what I understand, ServerIrons can load balance at the
> > > > > > > Layer 4 level (http, httpd, etc.), but not on the the Layer 2
> > level (MAC).
> > > > > > >
> > > > > > > You have no Layer 4 balancing commands at all in your config.
> > > > > > > They start with "server real .." and "server virtual ...".
> > > > > > >
> > > > > > > At the Layer 2 (MAC or switch layer) it just does spanning
tree.
> > > > > > > Spanning tree does not do any balancing. Instead it prevents
> > > > > > > loops by disabling (BLOCKING) interfaces that would cause
loops.
> > > > > > >
> > > > > > > The Foundry docs are online at www.foundrynet.com. They are a
> > > > > > > bit verbose, but they accurately lead you to working configs.
> > > > > > >
> > > > > > > RGDS
> > > > > > > GARY
> > > > > >
> >
> --------------------------------------------------------------------------
> > -
> > > > > > > Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR
97701
> > > > > > > gemIZZATrellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ryan Tucker [mailto:rtuckerIZZATnetacc.net]
> > > > > > > > Sent: Thursday, February 15, 2001 2:29 PM
> > > > > > > > To: lb-lIZZATvegan.net
> > > > > > > > Subject: [load balancing] Cascading switches off of a
Foundry
> > switch
> > > > > > > >
> > > > > > > >
> > > > > > > > Greetings...
> > > > > > > >
> > > > > > > > We have a Foundry ServerIron XL with 8 ports on it... it's
wired
> > into
> > > > > > > > the rest of our network with a spanning-tree configuration
on
> > ports 1
> > > > > > > > and 8... logically, it's off of a HP ProCurve 4000M, which
also
> > has
> > > > > > > > another ProCurve off of it, and there's a couple other
switches
> > off of
> > > > > > > > there, etc.
> > > > > > > >
> > > > > > > > Basically, what we need to do is be able to have the Foundry
> > > > > > > > load-balance traffic to servers that are not directly
plugged
> > into it...
> > > > > > > > we've tried the obvious thing (Just Doing It), and it
recognizes
> > that
> > > > > > > > the destination is up, but it doesn't let connections switch
> > over.
> > > > > > > >
> > > > > > > > Is there a config option I'm missing? :-)
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Ryan Tucker <rtuckerIZZATnetacc.net> Network
Operations
> > Manager
> > > > > > NetAccess, Inc. Phone: +1
716
> > 419-8200
> > > > > > 1159 Pittsford-Victor Road, Pittsford NY 14534
> > http://www.netacc.net/
> > > > > > "Wouldn't you rather help make history than watch it on TV?" -
Jello
> > Biafra
> > > > > >
> > > > >
> > > >
> > > > -------------- -- ---- ---- --- - - - - - -- - - - - - -
> > > > Tony Bourke tonyIZZATvegan.net
> > > >
> > > >
> > >
> > >
> >
>
>
This archive was generated by hypermail 2b30 : Sat Feb 17 2001 - 00:23:27 EST