|
Hi Suresh,
It seems to me that the real benefit of the Cisco is wire-speed
NAT.
Considering the wire-speed, for a standard use (10-20 realservers) it is
not really needed if you are using a limited Internet bandwidth (2-5
MBits/s). I agree that ASICs works faster but in most case it is not
needed. For example a commercial person (from Alteon) told me : "yes...
blablabla, our hardware solution is better because NAT is done directly
into silicium..." so I answer him, : "whoooo :) but our corporate Internet
Bandwidth is around 4 MBits/s so gigabit interface just to loadbalance a
server pool is really not needed..." So in conclusion IMHO wire-speed is
much more a commercial argument than technical, sometime it is really need
for big ISP/ASP architecture, but most of the time this is only a luxe.
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.
This can be done with failover program, performing checks to realservers.
So the failover prog inform LVS framework of the realserver health. For the
moment I do not know prog that do that for LVS. I am working on that point
in keepalived defining SLA on realservers. It will be added into the next
release (basically, this SLA will define a dynamic weighted LVS realserver
pool : for exemple, if a server response time is down the SLA predifined
value, the prog will modify dynamically the weight for that server).
=> So NAT with LVS running a failover framework will work great (must take
care that the overhead generated by healthchecks will not degrade the LVS
kernel framework).
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).
Agree, but you can prevent from this with a health check framework... we
can find a way to handle that point.
Best regards,
Alexandre
|
