On Tue, Sep 27, 2011 at 10:40 PM, Brad Johnson wrote:
> The patch alone does not give an advantage to the active node. But remember
> I said we are using an fping resource agent we wrote that varies the
> dampening based on which node it is running on and whether the score is
> rising or falling.
The patch alone does not give an advantage to the active node. But
remember I said we are using an fping resource agent we wrote that
varies the dampening based on which node it is running on and whether
the score is rising or falling. But the dampening it sets was being
over-ridden by the attr
On Mon, Sep 26, 2011 at 10:57 PM, Brad Johnson wrote:
> I agree that the patch assumes the use of "pingd" for the attribute name,
> and there may be a better way of coding that. However, I don't see how
> setting dampen=0 fixes our problem. The problem occurs when a ping node
> becomes inaccessib
I agree that the patch assumes the use of "pingd" for the attribute
name, and there may be a better way of coding that. However, I don't see
how setting dampen=0 fixes our problem. The problem occurs when a ping
node becomes inaccessible to all nodes in the cluster (it is rebooted
for example).
On Fri, Sep 23, 2011 at 9:53 PM, Brad Johnson wrote:
> Yes, but the patch only affects the pingd attribute.
Use of the name 'pingd' isnt mandatory though.
> And we do not want the
> other node to be able to challenge us to an immediate score comparison. That
> is the whole idea behind the fping
Yes, but the patch only affects the pingd attribute. And we do not want
the other node to be able to challenge us to an immediate score
comparison. That is the whole idea behind the fping OCF resource agent
we are using, to give the timing advantage to the node currently running
the resource by
On Tue, Sep 20, 2011 at 10:34 PM, Brad Johnson wrote:
> It is not necessarily the case that the outside world can't reach the
> cluster. Ours is a multi-homed device connecting to multiple WANs and LANs.
> We want the device with the best connectivity to be the active device. To
> get around the p
It is not necessarily the case that the outside world can't reach the
cluster. Ours is a multi-homed device connecting to multiple WANs and
LANs. We want the device with the best connectivity to be the active
device. To get around the problem of failovers occurring when a ping
node reboots for
On Sun, Sep 11, 2011 at 2:30 AM, Vadym Chepkov wrote:
>
> On Sep 8, 2011, at 3:40 PM, Florian Haas wrote:
>
On 09/08/11 20:59, Brad Johnson wrote:
> We have a 2 node cluster with a single resource. The resource must run
> on only a single node at one time. Using the pacemaker:ocf:ping
On 09/13/2011 10:36 PM, Brad Johnson wrote:
> Yes, the suggested approach has the problem when both nodes drop to a
> score of zero the resource can not run anywhere. I have gone back to my
> original "best connectivity" approach, but now using my own ping RA
> which uses different dampening delay
Yes, the suggested approach has the problem when both nodes drop to a
score of zero the resource can not run anywhere. I have gone back to my
original "best connectivity" approach, but now using my own ping RA
which uses different dampening delay on the active vs. standby node. On
the active no
On Sep 8, 2011, at 3:40 PM, Florian Haas wrote:
>>> On 09/08/11 20:59, Brad Johnson wrote:
We have a 2 node cluster with a single resource. The resource must run
on only a single node at one time. Using the pacemaker:ocf:ping RA we
are pinging a WAN gateway and a LAN host on each n
Thank you for your quick response. First, ideally we do want the "best
connectivity" approach. Assuming each node is connected to the ping
hosts via separate NIC's, switches, cables, etc, a failure in one of
those components will result in one node having degraded network
connectivity. But if t
>> On 09/08/11 20:59, Brad Johnson wrote:
>>> We have a 2 node cluster with a single resource. The resource must run
>>> on only a single node at one time. Using the pacemaker:ocf:ping RA we
>>> are pinging a WAN gateway and a LAN host on each node so the resource
>>> runs on the node with the grea
OK, attached is the full cibadmin -Q output.
Thanks,
Brad
On 09/08/2011 02:07 PM, Florian Haas wrote:
On 09/08/11 20:59, Brad Johnson wrote:
We have a 2 node cluster with a single resource. The resource must run
on only a single node at one time. Using the pacemaker:ocf:ping RA we
are pinging
On 09/08/11 20:59, Brad Johnson wrote:
> We have a 2 node cluster with a single resource. The resource must run
> on only a single node at one time. Using the pacemaker:ocf:ping RA we
> are pinging a WAN gateway and a LAN host on each node so the resource
> runs on the node with the greatest connec
16 matches
Mail list logo
