Re: [lvs-users] ldirectord feature patch - add abilility to signal system maintenance

2009-05-26 Thread Christian Balzer
Hello Simon, On Tue, 26 May 2009 16:27:45 +1000 Simon Horman wrote: > On Fri, May 22, 2009 at 06:08:18PM +0900, Christian Balzer wrote: > > > > Hello, > > > > One more thing I just noticed (must be part of the newer kernel since I > > never saw it before is that it states this in the kernel log

Re: [lvs-users] Real Servers receive nothing

2009-05-26 Thread poiuytrez
I have inverstigated deeper with filtering only the port 80. Packets now go to The request is going to the real server, then go back to the load balancer but never go back to the workstation. No output on eth0 to go out... (only 10.8.8.111 > 10.8.8.85) Do I have to add a route or something like

Re: [lvs-users] Real Servers receive nothing

2009-05-26 Thread poiuytrez
I have tried the tcp dump but it gives to much info, I don't really understand it, but it does not seems to have any http request. Here is a screen shoot at time of the request. The workstation that tries to retrive the page is 10.8.8.111. http://www.nabble.com/file/p23734830/screen.jpg Thank yo

[lvs-users] List connections on server backup

2009-05-26 Thread Leandro Ferreira
Hello, We having a problem where we use two servers as balancers LVS, one master and other backup. However, my backup LVS server yet received connections list. In the doc i saw a question about this and the answer was that he could not list these connections. (http://www.austintek.com/LVS/LVS-HOW

Re: [lvs-users] ldirectord: failed check doesn't remove a machine from the pool

2009-05-26 Thread Daniel Lemay
Hi Graeme, I found that it was not because OK is an HTTP keyword that the check was not working, but because OK is a substring of BR*OK*EN. Daniel Daniel Lemay wrote: > Hi Graeme, > > You were correct. It is now working. > > Thank you > > Daniel > > Graeme Fowler wrote: >> On Mon, 2009-05-25 at

Re: [lvs-users] ldirectord: same port number used with NAT and Direct Routing + monitoring = problem

2009-05-26 Thread Daniel Lemay
Hi Simon, apt-get install ldirectord ii ldirectord 1.2.5-3 Monitors virtual services provided by LVS Simon Horman wrote: > Hi Daniel, > > This looks like a bug in ldirectord whereby it thinks > 192.168.58.56:/Route and 192.168.58.55:/Masq are the same > thing and is using the same data s

Re: [lvs-users] cluster setup

2009-05-26 Thread Graeme Fowler
On Tue, 2009-05-26 at 20:11 +0530, Kaushal Shriyan wrote: > Thanks for the quick reply. is my setup correct ? or am i missing something > ?. I don't know; your question is not related to LVS itself but to Heartbeat, which has its own support mailing list. You'll find it here: http://lists.linux-h

Re: [lvs-users] cluster setup

2009-05-26 Thread Kaushal Shriyan
On Mon, May 25, 2009 at 10:38 PM, Graeme Fowler wrote: > On Mon, 2009-05-25 at 20:49 +0530, Kaushal Shriyan wrote: > > I have heartbeat 2.99 and ldirectord running on mthost04 and mthost03. > when > > i stop apache on either of mthost05/02 it works as expected. when i stop > > primary node (mthos

Re: [lvs-users] Real Servers receive nothing

2009-05-26 Thread Thomas Pedoussaut
poiuytrez wrote: > Hello, > > Ok, but the packets does not seems to go to the realservers. There is no log > entry in apache. So the gateway is not the main problem. > > IP 101 is your friend. I mean, SYN packets probably reach the RS, but because the ACK arrive out of context on the client, the

Re: [lvs-users] Real Servers receive nothing

2009-05-26 Thread poiuytrez
Hello, Ok, but the packets does not seems to go to the realservers. There is no log entry in apache. So the gateway is not the main problem. Thank you. Graeme Fowler wrote: > > On Tue, 2009-05-26 at 14:04 +0800, Guillaume Charhon wrote: >> It does not work and I don't have any ideas how to de

Re: [lvs-users] Real Servers receive nothing

2009-05-26 Thread Graeme Fowler
On Tue, 2009-05-26 at 14:04 +0800, Guillaume Charhon wrote: > It does not work and I don't have any ideas how to debug that. The default gateway for the realservers should be 10.8.10.1. If the netmask for everything is 255.255.255.0 (/24) then they'll have no idea how to route back to 10.8.8.85.