|
[snip]
> As far as I understand it, DR would not have a performance advantage in that
> case over NAT, because all outgoing packets of from the realservers stil
> have to pass the director/firewall.
[snip]
> I have read the (excellent!!!) HOWTO and mini-HOWTO, but they are not
> clear on this point. The potential performance problem with NAT is
> discussed, but not for DR in a configuration with a dual-interface
> directory. It is mentioned that a DR cluster will also have
> performance penalties when the return path goes through the director,
> but no comparison with NAT performance is made.
It depends on what performance you're talking about, really. Compared to
it's 'normal', asynchronous self, you do lose performance when routing
packets back through the DR director. You no longer have an async route
to the upstream. Consider the following:
---------------------------------
+ Switch +------ 1000SX -----+ Router
---------------------------------
|100TX |100TX |100TX
Director Server Server
Under normal DR, traffic follows the following path:
1. Incoming to router (Unknown)
2. Router to director (100TX / 1000SX)
3. Director to server (100TX)
4. Server to router (100TX / 1000SX)
If you go back through the director:
1. Incoming to router (Unknown)
2. Router to director (100TX / 1000SX)
3. Director to server (100TX)
4. Server to director (100TX)
5. Director to router (100TX)
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.
Now, NAT v. DR traffic path looks something like this:
DR:
1. World to router
2. Router to director
a. Director checks IP payload.
b. Select destination.
c. Mangle layer 2 frame address
d. Recalculate frame checksum
3. Director sends frame to server
4. Server handles traffic as normal.
Optionally, if server reroutes through director:
5. Server sends to director
6. Director 'routes' packet, or mangles it as in step 2.
(I'm not sure which, I'm assuming mangles --
anyone know for sure?)
NAT:
1. World to router
2. Router to director
a. Director checks IP payload.
b. Director mangles IP payload.
c. Director recalculates IP checksum.
d. Director creates new frame to send IP packet in
1. (Calculates frame checksum -- usually in
hardware)
3. Send to frame+packet to server.
4. Server replies through director.
a. Director checks IP payload
b. Director mangles IP payload
c. Director recalculates IP checksum
1. NOT IN HARDWARE.
d. Director creates new frame to send packet in
1. (Caculates frame checksum -- usually in
hardware)
5. Director sends packet to router.
DR has fewer steps, and most of it's checksumming can be done in hardware.
NAT has that step where it mangles the IP packet, so it has to do software
checksumming of that packet :) So it costs a _lot_ more CPU wise to do
NAT.
So, to answer your original question -- DR ALWAYS has a performance
advantage. NAT is more expensive. 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.
Anyhow, enough talking to hear myself talk ;)
Kyle Sparger
|
