Topology of ultramonkey...
"liran tal" <[email protected]> Wed, 22 Nov 2006 16:37:46 +0200
| Newsgroups | gmane.linux.highavailability.ultramonkey |
|---|---|
| Message-ID | <[email protected]> |
Hey guys, I'm trying to setup ultramonkey (basically just load balancing currently, no heartbeat required, so I guess we're talking about ldirectord only...) in a somewhat different topology as shown in the website: the vip load balancer: host lb1 has ip addresses: 192.168.0.20 on eth0 and 192.168.0.105 on eth0:0 (.105 is the vip) the default gateway for lb1 is 192.168.0.5 which is a linux-based router with 2 nics. (by the way, a quick question: to which ip does the hostname lb1 suppose to resolve to? to 192.168.0.105 the vip?) the router: 1 nic for WAN interface is 192.168.0.0/24 1 nic for LAN interface is 10.107.0.0/24 the real server (running apache for the sake of experiement): has ip address 10.107.0.163 on eth0 has default gw of 192.168.0.5 which is the router. the topology used is lvs/dr as you can see. the problems i've encountered: 1. when the real server DOESN'T have an alias interface of say eth0:0 with ip address 192.168.0.105/32 then there is ping communication between lb1 and the real server and i see on the logs that ldirectord adds the real server with weight 1 as it detects it is alive although when trying to access 192.168.0.105 from the WAN network (from the 192.168.0.0/24) nothing happens (i'm assuming it's because the real server doesn't have an alias interface configured with the vip address). in continuation to 1: 2. so when i configure an aliased interface of eth0:0 with ip address 192.168.0.105 and netmask 32 (255.255.255.255) there is no ping communication now between lb1 and the real server cause when i ping from lb1 to the real server i see on the real server with ethereal that the source ip of the ping is 192.168.0.105 so it doesnt reply back cause it's thinking it is replying to itself since it has that ip address on the aliased interface. by the way no action was taken regarding to arp issues... any thoughts of this issue are most welcome, thanks, liran.