Mark Wadham wrote:
> I might just create a new network for the real servers, seems much easier ;)
>
> Thanks
>
> Mark
<off-topic rant>
But why? I don't know what it is but it seems like many people make life
harder for themselves, create more config work and make their LVS setup higher
load by using NAT rather than DR. In an open hosting env where you can't
control routing, I can see it. But if it is a 10.* set up why not DR?
It is basically 4 steps:
1) Add an alias to the director:
# ifconfig eth0:1 10.128.1.70 netmask 255.255.255.0
2) Add the VIP to the real servers:
# ifconfig lo:1 10.128.1.70 255.255.255.255
3) Do some arp voodoo (this part I am never sure what is the "right" thing for
2.6.20+ kernels... not sure if Debian is near this for kernel version either.)
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
4) Add the VIP/Reals to the running ipvs config:
ipvsadm -A -t 10.128.1.70:80 -s wlc
ipvsadm -a -t 10.128.1.70:80 -r 10.128.1.67:80 -g
ipvsadm -a -t 10.128.1.70:80 -r 10.128.1.61:80 -g
5) [Optional] Download ipvsman http://sourceforge.net/projects/ipvsman/
to make life dreamy.
Sorry to be a broken record (and sorry if this doesn't apply to your
situation), but I think that people are missing out on the ease of deployment,
beauty, elegance, speed and low resource usage of ipvs that beats everything
except http://www.resonate.com/ Central Dispatch (which is a very nicely
crafted ipvs-type system for Solaris and other platforms) because they skip
over DR and go to straight to NAT and start changing routing and forwarding
and firewall marks and iptables, etc.
The only thing that I think some people need that DR can't do, is change ports
- I do this on the firewall for external clients and with port forwarding for
internal clients.
BTW, if machine count is an issue, we have high usage sites that run with the
directors on Xen domUs (and others with the directors on dom0s).
</off-topic rant>
|