|
> 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.
-----------------------------
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.
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.
I honestly believe it will work -- I think that generally, when you try to
route through a machine that has an IP address installed, the machine says
"Oh, that's me" and services the request as if it had been sent directly
to it. I was just wondering if anyone had any warnings about that
behaviour, and possibly how it works with LVS.
Kyle Sparger
|
