Hi,
On Mon, Aug 25, 2014 at 07:43:34PM +, Sutherland, Rob wrote:
Hello all,
We're in the process of implementing geo-redundancy on SLES 11 SP3 (version
0.1.0). We are seeing behavior in which site 2 in a geo-cluster decides that
the ticket has expired long before actual expiry. Here's
-Original Message-
From: Dejan Muhamedagic [mailto:deja...@fastmail.fm]
Sent: Wednesday, August 27, 2014 5:04 AM
To: pacemaker@oss.clusterlabs.org
Subject: Re: [Pacemaker] SLES 11 SP3 boothd behaviour
Hi,
On Mon, Aug 25, 2014 at 07:43:34PM +, Sutherland, Rob wrote:
Hello all
On 2014-08-27T13:31:21, Sutherland, Rob rsutherl...@broadviewnet.com wrote:
[Rob] Already done. It's unfortunate that SuSE only ships version 0.1.0.
product mode
The newer booth version has a fundamentally different algorithm and
network protocol (since it drops Paxos in favor of Raft) and
Von:Sutherland, Rob rsutherl...@broadviewnet.com
An:pacemaker@oss.clusterlabs.org pacemaker@oss.clusterlabs.org
Betreff:Re: [Pacemaker] SLES 11 SP3 boothd behaviour
All nodes in question NTP from the same time source (yes, we have run into synchronicity issues in the past).
Interestingly, increasing
, 2014 6:17 PM
To: Sutherland, Rob
Subject: Re: [Pacemaker] SLES 11 SP3 boothd behaviour
You probably already checked this, but just in case...
No experience at all with geo-redundancy, but this sounds suspiciously like it
could be a time sync problem. Have you tried something like ntpq -np on all
3
Hello all,
We're in the process of implementing geo-redundancy on SLES 11 SP3 (version
0.1.0). We are seeing behavior in which site 2 in a geo-cluster decides that
the ticket has expired long before actual expiry. Here's an example time-line:
1 - All sites (site 1, site 2 and arbitrator) agree