|
I've implemented both a mid-size LVS cluster (with 20 machines) and also a
smaller cluster with a Cisco 11800. We tried Foundry but LVS worked
better and was more configurable.
It seems to me that the real benefit of the Cisco is wire-speed
NAT. If a response from a real server does not come in x secs, the Cisco
tears that request and send another request to other active, real
servers. The client is not involved.
In the case of LVS in DR mode this re-requesting of a failed HTTP request
will have to be handled by the client's TCP/IP since LVS is not involved
in the returning stream (or the user may have to hit refresh).
If my understanding is mistaken please let me know.
-Suresh
On Mon, 16 Jul 2001, Alexandre CASSEN wrote:
> Hi,
>
> CISCO localdirector has stalled since they have bought Arrowpoint. So the
> CISCO CSS (Content Smart Switch) is the localdirector replacent. The main
> difference is that localdirector were an embended PC running a
> loadbalancinf software on 2 NIC, now with CSS they use native ASICs to
> loadbalance trafic. The cost of this bow is around US$12,000.
>
> I use CISCO CSS and LVS in production, I prefer LVS because you can
> manipulate it as you like and script some nice features (CSS has also an
> embended scripting language but it is not as extensible as unix scripting
> or C progy). Another thinks is that CSS only work in NAT environnement this
> is why they are using expensive ASICs to handle stream.
>
> Anyway the best choice to your loadbalance architecture will be parasited
> by ignorance displaying on linux & LVS. Decision maker often say "I prefer
> CISCO because it is our routing constructor partner, and I can access
> technical support, ...." blablabla it is the best choice, ...., blablabla,
> ... :))) People thinking that really display there ignorance ! If you have
> a budget limitation LVS, this is often a good arguments for descision
> maker. Otherwise I recommand you creating a sample demo loadbalancing
> architecture using LVS. That kind of approach show LVS in action, and you
> will be in front of all the nice LVS features ! Then you just take a CSS or
> foundry product for testing and set the same architecture... It will show
> you the black box limitations.
>
> An other aguments is that LVS handle security checks directly builded in so
> you can specify many stack parameters that you will not be able with black
> box.
>
> Another problems is the support ! It is a wrong problem since all people in
> this mailing list are very active and answer efficiently to every non
> documented problems. When you post directly in mailing list you are
> confronted with all the end user of LVS and with the coders that can answer
> more efficiently than any constructor hot line. Do not forgive that
> contructors often put unqualified person to the hotline to teach them their
> products functionnalities, so you are very limited some time by this first
> hotline level !.
>
> Another things is that to setup LVS you do not need to be a linux or LVS
> expert at all ! The HOWTO describe all the steps needed to setup a nice LVS
> topology.
>
>
> Best Regards,
> Alexandre
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
