|
Graeme Fowler wrote:
> On Thu, 2007-08-02 at 17:10 -0400, Gerry Reno wrote:
>
>> No. Directors and Real Servers are separate machines.
>>
>
> Right, got that, In that case once the realservers are setup, just leave
> them alone. Their config is the same regardless of the active director.
>
>
>> 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.
>>
>
> It's not necessary. If the realservers are configured to not ARP for the
> VIP when the master director is MASTER, then they remain the same when
> the backup switches in. No need to change anything *at all*.
>
>
>> 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.
>>
>
> The current MASTER director will see the FIN/ACK and RST packets from
> the client, and thus remove the connection from its' templates. Just in
> case the director falls over during the period the client transitions
> from ESTABLISHED to FIN_WAIT or RST state, the connection remains on the
> backup director for several seconds (60, I think, but I'd have to read
> the code) to make stateful failover a working reality. If you do the
> following on both directors:
>
> watch -d -n1 -- ipvsadm -Lnc
>
> then you can watch in near real-time what the pair of them are doing, in
> terms of connections.
>
>
>> The error in rsh setting default gateway is syntax. It is not even
>> changing the gateway. I can fix that or just remove it.
>>
>
> Switch it off. It's not necessary, not at all, and is confusing the
> issue no end!
>
>
>> The rest of this setup is working fine except that you cannot reliably
>> tell where the connections are.
>>
>
> They're on the MASTER director. They're wherever the VIP lives at any
> given time; they *cannot* be anywhere else. Remember, however, that an
> HTTP connection is relatively short-lived - a client fetches a page, and
> *blink* oh, you missed it.
>
>
>> 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?
>>
>
> Because the client has ended the TCP connection. Remember: *blink*.
>
So they would not even be shown as InActConn, right?
> If you remove your rsh commands (just to overstate it, they're not
> needed) then things become a *lot* simpler.
>
I have not tested but will the arp_ignore and arp_announce changes on
the real servers survive a reboot or will they go back to the original
settings?
> It's entirely plausible, by the way, that your upstream router just
> plain doesn't respond to GARP and continues trying to send to the
> defunct director. If that's the case, change your transition script to
> send an ICMP echo from the VIP to the router when the director becomes
> MASTER. That will force the router to update its' ARP cache, and keep
> the convergence times to a minimum.
>
Is there an easy way to test my upstream router for GARP? It is 5 year
old GbE.
> Graeme
>
>
>
|
