Re: [load balancing] Cascading switches off of a Foundry switch

From: Nimesh Vakharia (nvakhariIZZATgenx.net)
Date: Thu Feb 22 2001 - 13:36:11 EST

  • Next message: Alex Samonte: "Re: [load balancing] software vs appliances."

    On Tue, 20 Feb 2001, Alex Samonte wrote:

    > In bandwidth no, in pps it's close to the same.
    > Barring retransmits, I did not take fragmentation into account, but that
    > actually hurts the model because it's more packets in.
    >
    > For just the L4 stuff, the major work that the LB is doing is the
    > memory lookups, and packet rewrites.
    >
    > With DSR you only see the incoming PPS, not the outgoing PPS. The
    > SIZE of the request doesn't matter. With L4, the LB is not looking
    > at the payload.
    >
            I don't know how u'r calculating fragmentation would cause more
    packets in than out but typically http client requests are less than 1k. I
    guess if u really want to talk about it we can take it offlist.
            Agreed that LB is not looking at the payload BUT it caputures it,
    it copies it into memory, rewrites the packet header. Copies it out to the
    outbound buffer and then sends the packet back to the client. DSR u'r not
    doing this for outbound packets. Typically in any HTTP serving environment
    your inbound traffic is usually 1/10th or 1/15th of your outbound
    traffic. ie your pushing 3M inbound, server responses will be around
    30-40M outbound. You are eliminating 30-40M of traffic going through your
    LB.

    > > In a non DSR u'd be flooding the server iron buffers with traffic that has
    > > nothing to do with LB. Put in various different heavy IP flows and there
    > > you have it. SI becomes a bottleneck. Also even Gig speeds from a design
    > > perspective can be a bottleneck. You are not restricted to a server farm <
    > > 10 servers (10*100Mbps=1G). Mutltiple VIP's/Multiple farms behind the
    > > same SI scenario
    >
    > In general you don't have any servers except streaming servers spitting
    > out 100mb each. If you do it's poor design. Which is why I wanted
    > to move away from a bandwidth view to a pps view. It's much more relevant
    > to DSR.

            It was an example to give you a better idea. Point was you always
    "over subscribe" your Gig link and can easily saturate it.

    >
    > > Overall I've nothing against any setup, but DSR seems to be a
    > > good option and not something u should be afraid off. Think I convinced
    > > you try using DSR in your next setup? :P
    >
    > DSR was a patch when there was a performance bottleneck in the LB. It allowed
    > me to scale further when there were no other options. Now there are options.
    > Let's also give an example (not to slam on alteon) of this in the past.
    > There was a time when Alteons were limited to 32K conns. It took them
    > a little over a year to up that to 64K conns just by changing signed to
    > unsigned.
    > The drawback of DSR, plus the fact I have other options doesn't lead me
    > to want to use DSR. It's an option i'm well aware of. And in certain
    > situations, it does make more sense. But those are few and far inbetween.

       Well, I'll be happy as long as you don't rule it out of your book
    and be optimistic about it :).

    Nimesh.
             
            



    This archive was generated by hypermail 2b30 : Thu Feb 22 2001 - 13:26:59 EST