|
Kyle Sparger wrote:
>
> > the client sends a connect request to the VIP:port on the director which
> > is forwarded to the real-server, where the connect request is accepted.
>
> Right, in this case, the director must have the IP address on the local
> machine.
>
> In the case I was describing, the director would in fact be a gateway.
> The upstream router would send the packet to the appropriate VIP, through
> the director. The director would intercept it enroute, and rewrite the
> frame/header and then push it back to one of the real servers.
>
> It's like NAT, except rather than doing an address translation from
> non-routable network to routable network, it's doing an address
> translation to send it to one of the real servers.
>
> A scenario:
>
> Director:
> RIP: 207.218.81.133
>
> Real Server 1:
> VIP: 10.0.0.52
> RIP: 207.218.81.134
>
> Real Server 2:
> VIP: 10.0.0.52
> RIP: 207.218.81.135
>
> border-gw1 (a theoretical router):
> # /sbin/route add -host 10.0.0.52 gw 207.218.81.134
>
> Client sends a packet to 10.0.0.52. It comes over the Internet through
> border-gw1. border-gw1 checks its routing table, and finds the next
> gateway is 207.218.81.134.
>
> Director receives packet, and checks its routing/ipvsadm tables, and
> realizes it needs to send this request to a real server. It rewrites the
> ethernet frame (we're using DR here), and forwards it on to Real Server 1.
>
> Real Server 1 receives the packet, and responds normally.
> -----------------------------
I like it. Can't see anything wrong with it off the top of my head.
> The key difference in this scenario is that the director does NOT have the
> IP address installed; rather it is a router that knows how to get to the
> IP address.
>
> The difference in performance would probably be negligible, or maybe
> worse. I don't know. That's not something I'm concerned with just yet.
rewriting is slow and CPU intensive for the director. However you're only
rewriting in one direction unlike VS-NAT. However this may not be a problem
if there are other advantages.
> The reason that this might be advantageous is that if it acts as if it
> walks and talks like a router, then we can do things with it routers
> already do, and take advantage of existing infrastructure/protocols/code.
>
> Rather than having to write our own failover and load balancing code for
> the directors themselves, perfect it, etc, we can just use a proven
> routing protocol (like BGP) that already has all that built in.
If there are 2 directors (one running and one on standbye), how will BGP
know that the running one has failed and switch over to the other?
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
|
