|
Graeme Fowler wrote:
> Hi Gerry
>
> On Thu, 2007-08-02 at 16:24 -0400, Gerry Reno wrote:
>
>> This is all LVS-DR and I admit I am no network expert. But I do think I
>> understand the basic concepts of how LVS functions. So here goes at some
>> basic information of my setup:
>>
>> FIREWALLS: both MASTER and BACKUP are identical:
>>
>
> OK, good. That removes that as a problem.
>
>
>> CONFIGS:
>>
> <snip>
>
>> notify_master "/etc/keepalived/manage_ip_lvs_dr del"
>> notify_backup "/etc/keepalived/manage_ip_lvs_dr add"
>> notify_fault "/etc/keepalived/manage_ip_lvs_dr add"
>>
>
> This bit I have to say I'm puzzled about. Are your directors also the
>
No. Directors and Real Servers are separate machines.
> realservers?
>
>
>> NOTIFY SCRIPT ACTIONS:
>> case del:
>> rsh ALL_RS ip addr add 192.168.1.240/32 dev lo brd + scope host
>> rsh ALL_RS echo "1" > /proc/sys/net/ipv4/conf/eth0/arp_ignore
>> rsh ALL_RS echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce
>> rsh ALL_RS route del default
>> rsh ALL_RS route add default gw 192.168.1.1
>>
>> case add:
>> ip addr add 192.168.1.240/32 dev lo brd + scope host
>>
>
> In the case you have two directors and N realservers, you *should not
> need this script*. In the case that you have two directors which are
> also realservers, you need something, but probably not this.
>
> In the case of DR, the default gateway for the directors should not need
> to change (unless I'm missing something about your topology), nor should
> it for the realservers - it doesn't appear that you have a director
> acting as gateway for the realservers, and the rsh seems to return a lot
> of errors when trying to meddle with the default gateway. That probably
> explains why they can't respond to clients.
>
While working through the HOWTO it explained that for LVS-DR you have to
handle
the ARP issue. I choose to handle it by setting the arp_ignore and
arp_announce on the
real servers and then I just used the notify functionality to perform
the settings via rsh
during state transition.
>
>> Please notice that the connection is showing to the BACKUP even though
>> the VIP/24 is on the MASTER eth0 interface. This is what I do not
>> understand. How is this possible?
>>
>
> Through the LVS Sync Daemon - the MASTER multicasts to all BACKUP state
> servers, and they put entries in their connection tables just in case
> they need to fail over.
>
Ok, understand that. Then why are there no entries showing in the MASTER
table
for these connections? If they were copied over I would think that they
would show
in both. Makes it difficult to figure out the state of the connections
currently.
>
>> Anyway, is this enough information? Please let me know what else I can
>> provide.
>>
>
> An explanation of why your directors use rsh to frob the realservers'
> network interfaces when they don't need to would be helpful, as that's
> probably the cause.
>
> Graeme
>
>
>
The error in rsh setting default gateway is syntax. It is not even
changing the gateway. I can fix that
or just remove it.
The rest of this setup is working fine except that you cannot reliably
tell where the connections are.
To me it looked like the connection was being made to the BACKUP because
the only entry that
I could see was in the BACKUP table - the MASTER was empty. But if you
are saying that the entries
shown in the BACKUP table were only copied from the MASTER why wouldn't
they be in the
MASTER table?
Gerry
|
