On Wed, September 17, 2008 13:08, Josh Mullis wrote: > Here is my output from iptables-save: [snipped]
Looks sane so far as I can tell (remember that I'm still struggling with my own first setup, though). You don't need the "secondary" addresses for the LVS nodes (that's the terminology from piranha-gui; one of the problems here is that there's lots of conflicting terminology being used in different tools around all this stuff). The LVS node needs two real (soporate lan, or internet) IPs and two virtual (private network for the cluster) IPs; one each outside and inside. The virtual IPs will be moved between the two LVS nodes on failover, whereas the real IPs will stay with the hardware they're assigned to. The private virtual IP must be configured in each realserver as the gateway node. My impression is that getting that wrong is both the easiest and most common way of getting packets to go in but not come out; but that impression may be specific to redhat/centos setups using piranha-gui, which you haven't mentioned using (but it's what I'm using, hence it influences what I know). Here's my ipvsadm output: sh-3.2# /sbin/ipvsadm IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP prcvmod01.employer.local wlc -> 172.17.0.4:http Masq 8 0 0 -> 172.17.0.3:http Masq 8 0 0 sh-3.2# 172.17. is the private internal lan for the cluster. .4 and .3 there are realservers, separate physical systems in my case (they'll have Xen and multiple virtual servers on them soon). 172.17.0.100 is the virtual IP for the LVS director; it gets applied to the inside IP port of the LVS node, and would be moved to the active LVS if a failover happened (I haven't gotten to redundant LVS and failover yet). prcvmod01.employer.local is the public (corporate lan) virtual IP for the service (it's 192.168.1.16). The LVS system itself has its own corporate lan IP of 192.168.1.14. The iptables look like: sh-3.2# /sbin/iptables-save # Generated by iptables-save v1.3.5 on Wed Sep 17 14:32:03 2008 *filter :INPUT ACCEPT [7375193:1143767059] :FORWARD ACCEPT [396083:75791540] :OUTPUT ACCEPT [6115668:423106080] -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A FORWARD -d 192.168.122.0/255.255.255.0 -o virbr0 -m state --state RELATED,ESTABLISHED -j\ ACCEPT -A FORWARD -s 192.168.122.0/255.255.255.0 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m physdev --physdev-in vif5.0 -j ACCEPT COMMIT # Completed on Wed Sep 17 14:32:03 2008 # Generated by iptables-save v1.3.5 on Wed Sep 17 14:32:03 2008 *nat :PREROUTING ACCEPT [1498599:131914689] :POSTROUTING ACCEPT [398187:28611428] :OUTPUT ACCEPT [409849:29413401] -A POSTROUTING -s 192.168.122.0/255.255.255.0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE COMMIT # Completed on Wed Sep 17 14:32:03 2008 The most obvious difference is just that you're running your virtual server on the same box, and I'm not. I started out trying to run it all on one box, and gave up. I think I now understand the things I gave up on, and I think it should work in just one box with my current config -- but I haven't tried it yet. I'm going to get it working in the simple case of multiple boxes first, and *then* add in the complexity of some realservers on the same hardware as the LVS director. -- David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
