On Fri, 5 Aug 2011, Caleb Anthony wrote: > At my organization, we are doing something very similar to > this, but we are going from LVS-TUN to LVS-DR to Real > Server using firewall marks: > > Client --> LVS-TUN --> LVS-DR --> Real Server --> Back to the Client. > > This configuration forced us to configure LVS in a strange > way. We basically needed a dedicated "remote delivery > address" as we called it. > > Incoming traffic that is destined for the Real Server is > firewall marked. The LVS-TUN server then forwards the > traffic to the LVS-DR server using a dedicated address > just for this communication.
I don't understand this. Can you give IPs (and/or fwmark)? > That server, de-capsualtes it, and then forwards it to the > Real Server, which then replies to the Client. . . > What we're really accomplishing here is if a request comes > into a data center, but another one of our data centers is > closer to the client who made the request, we redirect > that traffic to the other data center. you have a director with a geographic scheduler? > Requests are small, but replies are large, the packet size doesn't make any difference. A packet of 1 byte or the whole MTU takes just as long to assemble and transmit. We didn't understand this in the early days of LVS and the misconception might still be in the HOWTO. I thought I'd fixed this up. Anyhow the work that shows that packet size is irrelevant is here http://www.linuxvirtualserver.org/Joseph.Mack/performance/single_realserver_performance.html Joe -- Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot) net - azimuthal equidistant map generator at http://www.wm7d.net/azproj.shtml Homepage http://www.austintek.com/ It's GNU/Linux! _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
