<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: trebuchet ms,sans-serif; font-size: 10pt; color: #000000'>Andrew,<br><br>Snipped off the old stuff as this is getting quite large for those that read via mobile devices ;-)<br><br>To answer your question - no not that I am aware of. Maybe someone else on the list with a better option will speak up.<br><br>However if your really only looking to make sure the node running the resources is able to ping at least one of the IP's but don't actually care if it can't ping both IP's (are they connected via the same network infrastructure?) then I have a solution which is how I utilize ping. I want to make sure the node running resources has connectivity to the client network. I don't care if it can't ping both IP (I use 2) since they are connected via the same infrastructure; only if the node can't ping both IP's do I assume the node is isolated and move resource off of it to the other. I also have the requirement to never move a resource that's running unless absolutely necessary hence I only move if isolated - ymmv for your use case. If what I said seems like it would be good enough for you this is the location statement I would recommend:<br><br>location loc_run_on_most_connected g_vm \<br> rule $id="loc_run_on_connected-rule" -inf: not_defined pingd or pingd lte 0<br><br>This will make sure your resources can't run on a node that doesn't have a pingd value of at least 1 - if a node loses ping to both/all IP's then resources migrate. Since it doesn't use the value of pingd as a score it doesn't give preference between 1000 or 2000 for your case and therefore no movement from loss of one ping destination.<br><br>HTH<br><br><div><span name="x"></span>
<style>/* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><font size="2">Jake</font></p>
</div>
<span name="x"></span><br></div><hr id="zwchr"><div style="color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Andrew Martin" <amartin@xes-inc.com><br><b>To: </b>"Jake Smith" <jsmith@argotec.com><br><b>Cc: </b>"The Pacemaker cluster resource manager" <pacemaker@oss.clusterlabs.org><br><b>Sent: </b>Monday, August 27, 2012 4:44:51 PM<br><b>Subject: </b>Re: [Pacemaker] Loss of ocf:pacemaker:ping target forces resources to restart?<br><br><style>p { margin: 0; }</style><div style="font-family: Times New Roman; font-size: 12pt; color: rgb(0, 0, 0);">Hi Jake,<div><br></div><div>Thank you for the detailed analysis of this problem. The original reason I was utilizing ocf:pacemaker:ping was to ensure that the node with the best network connectivity (network connectivity being judged by the ability to communicate with 192.168.0.128 and 192.168.0.129) would be the one running the resources. However, it is possible that that either of these IPs could be down for maintenance or a hardware failure, and the cluster should not be affected by this. It seems that a synchronous ping check from all of the nodes would ensure this behavior without this unfortunate side-effect. </div><div><br></div><div>Is there another way to achieve the same network connectivity check instead of using ocf:pacemaker:ping? I know the other *ping* resource agents are deprecated.</div><div><br></div><div>Thanks,</div><div><br></div><div>Andrew<br><br></div></div></div></div></body></html>