|
> hmm, trying to remember your original post - I think you
> said you could watch the IPs being moved one by one, it was
> so slow. So ospfd, which I assume takes upto 90sec(?) to
> change over would be compatible with the timescale of your
> dynamic routing. If you changed everything over in 5 secs,
> then ospfd would be left in the dust?
During a failover while tailing the messages file, you could watch each
successive ip addr and send_arp (IPaddr2). Consequently, when a failover
would happen, all ips would be brought down on the former master almost
instantaneously and slooowly come back up on the backup, now master
director. It seemed to me that the issue was being caused by the time it
took to actually execute the scripts in the haresorces file, as using ip
addr and send_arp directly gave time results that were very quick on these
same systems.
> > These days, it just seems better to go with what has been
> > working rather than to redesign the whole system.
> ie you're happy to stay with ospfd?
Well, it seemed like overkill to me when I was originally designing the
system, however the dictates of the net admin overrode my input. Now we're
operating with an acceptable failover time so I'm inclined to stay with
ospfd.
> > We could probably be just as well off without the ospfd
> > part of the picture however, it's working now and true to
> > specification so it's pretty easy for us to troubleshoot.
>
> it's now working with or without ospfd?
It's now working while running ospfd on the directors(always running
regardless of director state) with keepalived managing the lvs and failover
on the directors.
Initial tests of the new keepalived systems are resulting in 15sec or less
failover times independent of the number of IP addresses.
> where is ospfd running, both directors and the routers?
On both directors and our routers.
|
