|
Hi all
I've "thread forked" this to separate the no closed "Performance issues with
LVS-NAT" thread into the issue which seems to be have been "problem du jour"
for a few people this week, namely realservers attempting to access the VIP as
a client.
This is more of a thought experiment, so please bear with me if it sounds
rambling and incompetent...
1. DNS spoofery / hosts files
This will obviously work, but it doesn't really result in the realservers
acting as clients of the director in any way, shape or form. It's a bodge -
probably a successful bodge up to a site-specific number of hostnames, but a
bodge nonetheless.
2. Jacob Rief's method
Namely the method whereby Linux servers use iptables to DNAT the outbound
requests to the VIP to point to themselves.
This is great, as long as you only have one cluster of services and they're
all available on the entire cluster. The moment you walk off to having
multiple clusters behind multiple VIPs, using multiple ports it becomes
difficult to manage (and likely would lose resilience if the mapping points to
other servers in the cluster). It also means that the realservers are then
doing work which should, ideally, be done by the director.
And if the realservers are not Linux servers (or something with an equally
flexible packet mangling system) it isn't possible.
3. Policy routing using iproute2 in conjunction with iptables/netfilter
...just doesn't seem to work, for reasons outlined previously in the other
thread.
4. "Internal" VIPs.
This one just came to me so please feel free to try it, I'm away from my
development lab and it might prove to be a complete lemon anyway!
Here's the idea: on the director, for every "external" VIP configuration which
faces the clients (say VIP1) another VIP - iVIP1 - is also configured with
identical realservers but attached to the _internal_ interface. The principle
difference is that this VIP uses LVS-DR, because - for obvious reasons - the
realservers can respond directly to each other.
The only complicated bit is setting up a netfilter rule to do DNAT as the
packets arrive - trap all packets destined for VIP1 and DNAT them to iVIP1.
Ensure iVIP1 is a loopback alias on your realservers as per normal DR
configuration, and in theory at least the realservers should then be able to
talk to each other as clients of a VIP.
If this makes no sense whatsoever, feel free to blow it away but be nice in
doing so :)
It's a theory, at least. I'll test it over the weekend if I get chance.
Graeme
|
