Yes, well, for the LVS-TUN, seems that almost noone has recomended or tried
that way, but i've heard it's slow, well not as slow as the NAT method
that's the third one and the most lame.. so it's better to ask the hosting
company to move that server into the same node as the other two and problem
solved..
So you've made some points very clear then
>And the loopback device ;) And solving the arp problem before bringing
>up the lo is important.
Always use the virtual addres as the main ip for the domains binded
and the last but not the least for LVS-DR always use the same network (not
routed) for your mini-cluster
Checked and ready to go !
What can i say Léon you have been really helpful and i've really learned a
lot from this, i hope the comunity too.
Now i will move on on building the actual cluster , http, https, nfs (i
don't know actually how to use static file mirroring so i'm thinking of
using nfs to share..but i guess when a server will be to busy serving files,
nfs will be down too) , mysql and ...that's it i think..
Thank you again!
L.S. Keijser-2 wrote:
>
> On Thu, 2009-10-22 at 21:40 -0700, partysoft wrote:
>> oh the Kerner version is :
>> Linux linux.local 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009
>> x86_64
>> x86_64 x86_64 GNU/Linux
>
> I wanted to know in case things weren't working, but this is a recent
> enough kernel to allow arp_ignore/arp_announce
>
>> Still one problem remains which i haven't put so much accent on the
>> previous
>> mail ..
>> the 2 ip's from the 2 different C class nets..
>>
>>
>> >> virtual=XX.XX.XX.236:80 (Virtual IP configured on the director)
>> >> fallback=127.0.0.1:80
>> >> real=XX.XX.XX.235:80 gate
>> >> real=XX.XX.YY.163:80 gate
>>
>> >Where does the YYY.YYY.YYY.235 come from? Assuming X != Y, this will
>> >never work as the two realservers are in different subnets
>>
>> actually i have the first real server is in the same C class as the LVS
>> server
>> so they are (i'm just gonna put some numbers to the X and Y to make it
>> more
>> clear)
>> 10.1.238.236 (LVS Virtual IP configured on the director), 10.1.238.235
>> (Real
>> server)
>>
>> and the other real server, is the same hosting company i presume and it
>> has
>> 10.1.239.163 so not the same C class...So i don't know if this is posible
>> to
>> include an ip like that...
>
> No it's not. At least not with LVS-DR. The director needs to be able to
> reach the realservers. In the HOWTO (more precisely here:
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html ) it
> says:
>
> "LVS-DR setup and testing is the same as LVS-Tun except that all
> machines within the LVS-DR (ie the director and realservers) must be on
> the same segment (be able to arp each other). This means that there must
> be no forwarding devices between them i.e. they are using the same piece
> of transport layer hardware ("wire"), eg RJ-45, coax, fibre (there can
> be hub(s) or switch(es) in this mix). Communication within the LVS is by
> link-layer, using MAC addresses rather than IP's."
>
>
>> I've tried anyway....
>
> Try all you want, you're not going to succeed. There's probably a router
> somewhere that will stop your efforts.
>
>> What i've tried to do is configure the eth1:0 like this:
>>
>> eth0:1 Link encap:Ethernet HWaddr 00:24:1D:72:61:AB
>> inet addr:10.1.238.236 Bcast:10.1.255.255 Mask:255.255.0.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Interrupt:233 Base address:0x2000
>>
>> So it will include the B class as well..
>>
>> On the RealServer i did like you said ( y renounced to sysctl -p ) :
>>
>> # solve the 'ARP problem'
>> echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
>> echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
>> echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
>> echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
>> /sbin/ifconfig lo:0 XX.XX.XX.236 netmask 255.255.255.255 up
>>
>> but, when i do an arping XX.XX.XX.236 i get as a response total different
>> MAC address then the actual one 00:24:1D:72:61:AB
>
> That's probably from a router who basically says "Send the packets to me
> and i'll make sure they get to the realserver".
>
>> And indeed if i try from the realserver that's on the same C class the
>> x.235
>> one, i get imediatly the same
>> 00:24:1D:72:61:AB mac address as the eth1:0 has. amazing :) didn't knew i
>> could do that
>>
>> by the way i guess on the realservers i don't need to install the lvs
>> pachages to have the kernel modules installed for lvs, just the arp trick
>> and that's it..
>
> And the loopback device ;) And solving the arp problem before bringing
> up the lo is important.
>
>
>> So again...like a stupid linux rookie that i am , stuck with this
>> thing...but i'm sure the answer it's between the lines...
>
> You could look at LVS-TUN (see the HOWTO) because AFAIK this is
> basically LVS-DR but with the added benefit that you will be able to
> bypass routers by encapsulating the packet. I have no experience with
> that though.
>
> --
> Léon
>
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
--
View this message in context:
http://www.nabble.com/LdirectorD-LVS-and-CentOS-Fedora-RedHat-tp26004219p26030303.html
Sent from the LVS mailing list archive at Nabble.com.
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|