No subject

route on your load balancers and 192.168.6.240 should be the default
route on your real servers.

> 
> 
> 
> 
> 
> 
> 
> Horms <horms at verge.net.au>
> Sent by: ultramonkey-users-owner at ultramonkey.org
> 08/03/2005 14:06
> Please respond to ultramonkey-users
> 
>  
>         To:     caranas at lexmark.com
>         cc:     ultramonkey-users at ultramonkey.org
>         Subject:        Re: My Load balancers are not seeing each other
> 
> 
> On Wed, Aug 03, 2005 at 12:49:24PM +0800, caranas at lexmark.com wrote:
> > I'm currently using Red Hat Linux Enterprise ES 3
> > 
> > issuing the netstat -rn command on both servers:
> > 
> > balancer01
> > Kernel IP routing table
> > Destination      Gateway                Genmask Flags   MSS  Window irtt 
>  
> > Iface
> > 180.88.80.0             0.0.0.0                 255.255.255.128 U 
> >         0       0               0       eth0
> > 192.168.6.0             0.0.0.0                 255.255.255.0 U 0 0 
> >         0       eth1
> > 169.254.0.0             0.0.0.0                 255.255.0.0 U 0 
> > 0               0       eth1
> > 127.0.0.0               0.0.0.0                 255.0.0.0 U           0 
> 0 
> >         0       lo
> > 0.0.0.0                 180.88.80.2     0.0.0.0 UG 
> >        0        0               0       eth0
> > 0.0.0.0                 192.168.6.240           0.0.0.0 UG        0 0 
> >         0       eth1
> > 
> > issuing the ip route command 
> > # ip route show 0/0
> > default via 157.184.80.2 dev eth0
> > default via 192.168.6.240 dev eth1
> 
> Having two default routes is unliekly to make anything good happen.
> You probably want to get rid of the second one.
> 
> However, as you have a route for 192.168.6.0/24 on eth1, the routing
> does look correct for communication between nodes on that network.
> 
> [snip]
> 
> > 
> > For my ldirectrd.cf file:  You might notice that I have many virtual 
> > variable like 
> > virtual=180.88.80.60:80 and my fallback ip address is thesame as my real 
> 
> > ip address.  I made it like this since if I place the fallback to 
> > 127.0.0.1 my ldirectord would always go to the fallback and not the real 
> 
> > ipaddress.  So I made the real and fallback IP address thesame to force 
> > the ldirectord to use the real ipaddress.  But, in doing so I can only 
> > declare one real and one fallback at a given virtual declaraion 
> > (virtual=180.88.80.60:80) so I created two virtuals.
> 
> Ok, two things.
> 
> 1) That fallback behaviour you describe is just plain weird.
>    The setting of the fallback shouldn't effect how the
>    real servers are handled. But I suspect your configuation
>    is confusing ldirectord (as it indeed confuses me). See 2)
> 
>    The idea of a fallback is to act as a tempoary host if
>    all the real servers fail. Thus there is no point in making
>    the real server the fallback. If you are having problems,
>    the best thing to do would be to ommit the fallback all together.
> 
> 2) You have actually configured 6 virtual servers, not two.
>    And more to the point, you have a dubplicate virtual servers for 
>    180.88.80.60:80, 180.88.80.60:443 and 180.88.80.60:21. This is not
>    correct.  Ldirectord should flag it as an error, but I guess it slips 
>    through - to be honest I never thought of testing this. I'll fix that 
>    up, but in the mean time, I think what you are after is something more 
> like.
> 
> 
> Virtual Server for HTTP
> virtual=180.88.80.60:80
>         fallback=127.0.0.1:80
>         real=192.168.6.11:80 masq
>         real=192.168.6.14:80 masq
>         service=http
>         request="index.html"
>         receive="Test Page"
>         scheduler=rr
>         #persistent=600
>         protocol=tcp
>         checktype=negotiate
> 
> # Virtual Service for HTTPS
> virtual=180.88.80.60:443
>         fallback=127.0.0.1:443
>         real=192.168.6.11:443 masq
>         real=192.168.6.14:443 masq
>         service=https
>         request="index.html"
>         receive="Test Page"
>         scheduler=rr
>         #persistent=600
>         protocol=tcp
> 
> # Virtual Service for FTP
> # Note that peresistancy needs to be turned on for FTP when
> # used with LVS-TUN (ipip) or LVS-DR (gate), but not with LVS-NAT (masq).
> virtual=180.88.80.60:21
>         fallback=127.0.0.1:21
>         real=192.168.6.11:21 masq
>         real=192.168.6.14:21 masq
>         service=ftp
>         request="welcome.msg"
>         receive="Welcome"
>         login="anonymous"
>         passwd="anon at anon.anon"
>         scheduler=rr
>         #persistent=600
>         protocol=tcp
>         checktype=negotiate
> 
> 
> Please also observe that as you are using LVS-NAT (masq), the
> real servers 192.168.6.11 and 192.168.6.14 must not act
> as linux directors, and return packets for load balanced
> connections must pass through the active linux director.
> This is usually done by adding a second VIP, managed by heartbeat,
> on the private/server network to the cluster. 192.168.6.240 is
> used in the examples. And typically the real servers should
> use this address as their default gateway.
> 
> 
> 
> -- 
> Horms
> 
> 
> -- 
> Ultra Monkey - http://www.ultramonkey.org/
> To UNSUBSCRIBE, email to lisa at ultramonkey.org, with a body:
> unsubscribe ultramonkey-users your-email-address at some.domain
> where "your-email-address at some.domain" is YOUR email address.
> 
> 
> 



-- 
Horms