Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux Virtual Server: Users

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

 

 

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded


daniel.lemay at ec

May 25, 2009, 11:30 AM

Post #1 of 3 (804 views)
Permalink
[lvs-users] ldirectord: same port number used with NAT and Direct Routing + monitoring = problem

Hi,

Here are some specs:

os: Debian GNU/Linux 4.0 (etch)
ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
ldirectord version 1.77.2.51


General observations:

a) In each case, an external (masq) and internal (route) virtual
service is configured on the same port (7777)
b) When no health check is done on the internal service, all is
working correctly (see case #1)
c) When a health check is added on the internal service, ipvsadm
give a strange result (see case #2)
d) I have no control on how the Oracle stack is configured. I have
asked the person responsible for the Oracle stack if we can use a port
other than 7777 for
the internal load balancing, but she insists that we can't
(possibly because she don't know how to configure the stack in this case).

Here is (a part) my ldirectord config. for 2 use cases:

1) This case is working correctly (no health check on the internal service)
-------------------------------------------------------------------------------------------------

# external service
virtual=x.x.x.x:7777
real=192.168.58.55:7777 masq
real=192.168.58.56:7777 masq
scheduler=rr
protocol=tcp
service=http
checkport=7778
request="/cmctest.html"
receive="WORKING"

# internal service
virtual=192.168.58.4:7777
real=192.168.58.55:7777 gate
real=192.168.58.56:7777 gate
scheduler=rr
protocol=tcp

TCP x.x.x.x:7777 rr
-> 192.168.58.56:7777 Masq 1 0 0
-> 192.168.58.55:7777 Masq 0 0 0

TCP 192.168.58.4:7777 rr
-> 192.168.58.55:7777 Route 1 0 0
-> 192.168.58.56:7777 Route 1 0 0


2) This case give a strange result (health check on the internal service)
---------------------------------------------------------------------------------------------

# external service
virtual=x.x.x.x:7777
real=192.168.58.55:7777 masq
real=192.168.58.56:7777 masq
scheduler=rr
protocol=tcp
service=http
checkport=7778
request="/cmctest.html"
receive="WORKING"

# internal service
virtual=192.168.58.4:7777
real=192.168.58.55:7777 gate
real=192.168.58.56:7777 gate
scheduler=rr
protocol=tcp
service=http
checkport=7778
request="/cmctest.html"
receive="WORKING"

TCP x.x.x.x:7777 rr
-> 192.168.58.56:7777 *Route* 1 0 0
-> 192.168.58.55:7777 *Masq * 0 0 0

TCP 192.168.58.4:7777 rr
-> 192.168.58.55:7777 *Masq* 0 0 0
-> 192.168.58.56:7777 *Route* 1 0 0

How can we explain the strange "coupling" with Route and Masq?

Any idea? Thanks.
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


horms at verge

May 25, 2009, 5:10 PM

Post #2 of 3 (748 views)
Permalink
Re: [lvs-users] ldirectord: same port number used with NAT and Direct Routing + monitoring = problem [In reply to]

On Mon, May 25, 2009 at 06:30:27PM +0000, Daniel Lemay wrote:
> Hi,
>
> Here are some specs:
>
> os: Debian GNU/Linux 4.0 (etch)
> ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
> ldirectord version 1.77.2.51

[snip]

> TCP x.x.x.x:7777 rr
> -> 192.168.58.56:7777 *Route* 1 0 0
> -> 192.168.58.55:7777 *Masq * 0 0 0
>
> TCP 192.168.58.4:7777 rr
> -> 192.168.58.55:7777 *Masq* 0 0 0
> -> 192.168.58.56:7777 *Route* 1 0 0
>
> How can we explain the strange "coupling" with Route and Masq?

Hi Daniel,

This looks like a bug in ldirectord whereby it thinks
192.168.58.56:7777/Route and 192.168.58.55:7777/Masq are the same
thing and is using the same data structure to handle them internally.
I'll look into this.

Could you let me know how you installed ldirectord.
Was it using the Debian ldirectord package for etch, if so, which version?


_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


daniel.lemay at ec

May 26, 2009, 7:59 AM

Post #3 of 3 (743 views)
Permalink
Re: [lvs-users] ldirectord: same port number used with NAT and Direct Routing + monitoring = problem [In reply to]

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:7777/Route and 192.168.58.55:7777/Masq are the same
> thing and is using the same data structure to handle them internally.
> I'll look into this.
>
> Could you let me know how you installed ldirectord.
> Was it using the Debian ldirectord package for etch, if so, which version?
>
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
> Send requests to lvs-users-request [at] LinuxVirtualServer
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.