[Pacemaker] How to ensure that a resource is only running at one place?

[Kevin Stevenard]

Hello All,

I would like to know what is the easiest way to ensure that a resource
(especially an lsb resource) is running only at one place?
Because by default on my asymmetric cluster I saw that the op monitor action
is only executed on the node where the resource is currently running, and
when a user start manually (not through the crm) the same resource on
another node pacemaker won't see it because it is not executing the op
monitor on all nodes that are potentially able to run the resource.

Here is the relevant part of my configuration with 4 nodes, an asymmetric
configuration, 1 resource named ExtractProcess with 2 possible host on which
it can run (hostA and hostB through location rule loc-ExtractProcess)

node hostA
node hostB
node hostC
node hostD
primitive ExtractProcess lsb:ExtractProcess \
        op monitor on-fail="restart" interval="20" \
        meta migration-threshold="10" failure-timeout="30s"
multiple-active="stop_start" target-role="Started"
location loc-ExtractProcess ExtractProcess \
        rule $id="loc-ExtractProcess-rule" 100: #uname eq hostA or #uname eq
hostB
property $id="cib-bootstrap-options" \
        expected-quorum-votes="4" \
        stonith-enabled="false" \
        dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87" \
        no-quorum-policy="ignore" \
        cluster-recheck-interval="20s" \
        cluster-infrastructure="openais" \
        start-failure-is-fatal="false" \
        symmetric-cluster="false" \
        is-managed-default="true"
rsc_defaults $id="rsc-options" \
        target-role="started" \
        resource-stickiness="100"

Am I obliged to write my own RA with a master/slave or primary/secondary
knowledge to be sure that the resource is active only at one place at a
time?

Thank you in advance for your feedback :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110524/1c95af4d/attachment-0002.html>