LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: HTTP issue part 2

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: HTTP issue part 2
From: "Matthew Story" <matthewstory@xxxxxxxxx>
Date: Wed, 30 Aug 2006 22:22:51 -0500
I had considered trying the LVS-TUN as a solution, thank you for
suggesting it and reminding me of it.  It worked well, and was
surprisingly simple to set up.  I understand from the documentation
that there is no performance difference between the two, and I was
able to retain the high throughput setup that drew me to the DR setup
in the first place.  Thank you everyone for your help.

On 8/30/06, Todd Lyons <tlyons@xxxxxxxxxx> wrote:
On Wed, Aug 30, 2006 at 01:22:43PM -0500, Matthew Story wrote:

>3. My first instict at this point is to make sure that forewarding is
>set up properly, checked my sysctl.conf file and sure enough:
>net.ipv4.ip_forward = 1

Not needed for LVS-DR.  The packets aren't forwarded through the network
stack, they are rewritten by the lvs system.

>is set properly.  I checked the sysctl.conf on the real server too,
>and everything apears to be in order, but that isn't the concern yet
>as when I firewalled that server it should have timed out regardless
>of the sysctl settings.

Show us the relevant sysctl.conf settings on the real servers.

>Given all that does anyone have any thoughts?  Have a similar error
>they've championed?

Show us the output on one of the real servers of 'ifconfig lo:0'.  Does
it look like this?

CentOS43[root@webmail1 ~]# ifconfig lo:0
lo:0      Link encap:Local Loopback
          inet addr:64.14.201.34  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

Notice the /32 netmask.

>>virtual=64.34.209.34:80
>>        fallback=127.0.0.1:80
>>        real=64.34.174.215:80 gate
>>        real=64.34.180.165:80 gate
>>        service=http
>>        request="/update/index.html"
>>        receive="Test Page"
>>        scheduler=rr
>>        #persistent=600
>>        protocol=tcp
>>        checktype=negotiate
>>
>>As you can see both of the webservers are on different subnets than
>>each other, and also on a different subnet than both of the
>>ultramonkey directors, though the director boxes are on the same
>>subnet (170) and share a common default gateway.

There is your problem.  In LVS-DR, you cannot have the real servers on
different networks than the director.  To do this, you need to use
LVS-TUN.

This is from the LVS Howto, section 7 on LVS-DR:
  ...all machines within the LVS-DR (ie the director and realservers)
  must be able to arp each other. This means that they have to be on the
  same network without any forwarding devices between them.

This is from the LVS Howto, section 7 on LVS-Tun:
  Unlike LVS-DR, with LVS-Tun the realservers can be on a network remote
  from the director...
--
Regards...              Todd
when you shoot yourself in the foot, just because you are so neurally
broken that the signal takes years to register in your brain, it does
not mean that your foot does not have a hole in it.      --Randy Bush
Linux kernel 2.6.12-18mdksmp   7 users,  load average: 0.22, 0.22, 0.33
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users



--
regards,
matt

<Prev in Thread] Current Thread [Next in Thread>