|
Kyle Sparger wrote:
>
> Okay, so with the second option, you lose the higher return throughput,
> since in the first, your limit is 100 times the number of real servers, to
> a maximum of 100MBit; on the second, it's 100, since that's all the
> director can handle.
I presume what you're saying here is that if you have 100 real-servers, each
with their own connection to the internet, and you are using some service where
the packets from the real-servers are large and the reply packets from
the client are small (eg an ACK) as you would have with ftp, or http where the
hits are large enough), you can get 100x throughput with VS-DR
whereas with VS-NAT, the director would become the bottleneck.
This piece of information was passed around a lot in the early days of LVS
as one of the advantages of VS-DR. However bench testing (see my performance
tests on the Documents page) shows that you
don't get this advantage with VS-DR. The assumption that is wrong is
that small packets take a shorter time to transmit, than do packets
of MTU size. It turns out that (at least with Linux)
that all packets take the same amount of time to transmit. The 100Mbps
throughput only occurs when all packets are MTU size. If each packet
has a payload of 1byte, then the max throughput is 100Mpbs * 1/1500.
The consequence of this is that the zero bandwidth ACKs from the
client are taking up as much ethernet capacity as does the 100Mbps
of packets being sent from the real-server.
1 real-server will take up all the bandwidth of a VS-DR
director. The difference between a VS-DR director and a VS-NAT director
is that the VS-DR director will have a low load average, while the
VS-NAT director will have a high load average.
I like this next bit about VS-NAT being layer-3 aware. I've put it into
the next version of the HOWTO.
> But, it also has the potential for
> 'feature' advantages, though, since it's layer 3 aware.
>
> For example, NAT can 'see' if a real server responds to a packet it's been
> sent or not, since it's watching all of the traffic anyway. And if it
> doesn't respond within a certain period of time, it can automatically
> route that packet to another server. AFAIK, LVS doesn't support this
> right now, but, NAT would be the more likely candidate to support it in
> the future, as NAT understands all of the IP layer concepts, and DR
> doesn't necessarily.
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
