I assume you know how to use pingd and pingd in a location constraint and are familiar with HAv2 and CRM/pacemaker in general.
In the test setup the cluster nodes (node1, node2) have two network interfaces and are both connected to two different networks (net1, net2). The cluster is running resources, which are only accessed on one network each (res1 on net1, res2 on net2).
Say both resources are running on node1 and the network card for net1 on node1 dies (or whatever - say you cannot reach net1 from node1 anymore). Then you surely want res1 to move to node2, but you do not necessarily want to move res2, too.
So what you need is two attributes, one for each network, that reflect the node's connectivity to the networks.
With heartbeat versions <=2.1.2, pingd claimed to be able to run multiple instances and set a different attribute from each instance, but in fact it could not, because only one instance was allowed to register with the cluster.
Of course you could make pingd ping nodes on different networks, but that did not necessarily reflect the connectivity to one specific network.
What you can do with pingd (heartbeat versions >=2.1.3) is to start multiple pingd instances, let them ping a different set of nodes (the set should reasonably be on the particular network) and have the instances set different attributes each. This way you can constraint your resource with the connectivity to a specific network.
cd /usr/lib/heartbeat cp pingd pingdnet1 cp pingd pingdnet2
... # IPs in net1 ping a.a.a.a ping b.b.b.b ping c.c.c.c # IPs in net2 ping x.x.x.x ping y.y.y.y ping z.z.z.z # apiauth directives apiauth pingdnet1 gid=root uid=root apiauth pingdnet2 gid=root uid=root # respawn directives respawn root /usr/lib/heartbeat/pingdnet1 -a pingdnet1 -m 100 -d 5s -p /var/run/pingdnet1.pid -h a.a.a.a -h b.b.b.b -h c.c.c.c respawn root /usr/lib/heartbeat/pingdnet2 -a pingdnet2 -m 100 -d 5s -p /var/run/pingdnet2.pid -h x.x.x.x -h y.y.y.y -h z.z.z.z ...
This will set the attributes "pingdnet1" and "pingdnet2" according to the number of hosts reachable times the multiplier (100 in this example).
And here's an example of how to use the pingdnet1 attribute in a resource location constraint:
<constraints> <rsc_location id="res1-net1-connected" rsc="res1"> <rule id="res1-net1-connected-rule" score_attribute="pingdnet1"> <expression id="res1-net1-connected-rule-1" attribute="pingdnet1" operation="defined"/> </rule> </rsc_location> <rsc_location id="res2-net2-connected" rsc="res2"> <rule id="res2-net2-connected-rule" score_attribute="pingdnet2"> <expression id="res2-net2-connected-rule-1" attribute="pingdnet2" operation="defined"/> </rule> </rsc_location> </constraints>
Of course there's other attributes (like resource_stickiness) that come to play when you want to move a resource according to network connectivity, but that's not part of this howto.