|
On Mon, 1 Oct 2001, Serge Sozonoff wrote:
> Adrian,
>
> >That is LVS-DR. If you use it you have all chances that none of
> the
> >above-mentioned problems occur. Just read the howto to avoid
> the ARP problem
> > (or use static ARP on the director).
>
> OK, so lets say it is LVS-DR (I have read about LVS-DR in the
> FAQ) how would I meet the following criteria:
>
> 1. A box could be added to the farm without having to solve the
> ARP problem. (no special config needed)
use static ARP. ugly and less flexible, but solves the problem.
> 2. The real servers do not need to have the VIP address bound to
> their interface (this would solve the ARP problem)
yes they need for LVS-DR. They don't for LVS-NAT
> 3. The Linux Director would need to rewrite the IP header (some
> form of NAT) to change the Real Server IP to the Virtual Server IP
> before the
> packet was returned to the client. (this is the only way point
> 2. could work, right?)
For LVS-DR the VIP address has to be present on all real servers and no packet
rewriting occurs. You need to solve the ARP problem somehow (static ARP or
other)
For LVS-NAT the VIPs don't need to be present on each RS, but paket rewrinting
occurs.
You have to choose between the two.
> In other words, I am still trying to resolve the problem in my
> previous diagram, but I have removed the requirement of
> if being LVS-NAT :-)
Or use multi-port ethernet cards and transform the LVS director in a switch.
You add individual routers for each real server (that will be connected using
a cross-over cable directly to a director "port"). This really kills the ARP
problem, but is obviously expensive if you have more than 3 real servers
(4-port fast-ethernet cards are really expensive).
> Could the solution be made up of some sort of LVS-DR/LVS-NAT
> hybrid?
I don't think so. It is either-or.
Radu-Adrian Feurdean
mailto: raf @ chez.com
--------------------------------------------------------------------------
"PL/1 belongs more to the problem set than to the solution set" (Dijkstra)
|
