<div dir="ltr">> <span style="font-size:12.8px">I think stickiness will do what you want here. Set a stickiness higher</span><br style="font-size:12.8px"><span style="font-size:12.8px">> than the original node's preference, and the resource will want to stay</span><br style="font-size:12.8px"><span style="font-size:12.8px">> where it is.</span><div><span style="font-size:12.8px"><br></span><div><span style="font-size:12.8px">Not sure I understand this. Stickiness will ensure that resources don't move back when original node comes back up, isn't it?</span></div></div><div><span style="font-size:12.8px">But in my case, I want the newly standby node to become the backup node for all other nodes. i.e. it should now be able to run all my resource groups albeit with a lower score. How do I achieve that? </span></div><div><span style="font-size:12.8px">Also can you answer, how to get the values of node that goes active and the node that goes down inside the OCF agent? Do I need to use notification or some simpler alternative is available?</span></div><div><span style="font-size:12.8px">Thanks.</span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 9:30 PM, Ken Gaillot <span dir="ltr"><<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/08/2016 06:55 AM, Nikhil Utane wrote:<br>
> Would like to validate my final config.<br>
><br>
> As I mentioned earlier, I will be having (upto) 5 active servers and 1<br>
> standby server.<br>
> The standby server should take up the role of active that went down. Each<br>
> active has some unique configuration that needs to be preserved.<br>
><br>
> 1) So I will create total 5 groups. Each group has a "heartbeat::IPaddr2<br>
> resource (for virtual IP) and my custom resource.<br>
> 2) The virtual IP needs to be read inside my custom OCF agent, so I will<br>
> make use of attribute reference and point to the value of IPaddr2 inside my<br>
> custom resource to avoid duplication.<br>
> 3) I will then configure location constraint to run the group resource on 5<br>
> active nodes with higher score and lesser score on standby.<br>
> For e.g.<br>
> Group Node Score<br>
> ---------------------------------------------<br>
> MyGroup1 node1 500<br>
> MyGroup1 node6 0<br>
><br>
> MyGroup2 node2 500<br>
> MyGroup2 node6 0<br>
> ..<br>
> MyGroup5 node5 500<br>
> MyGroup5 node6 0<br>
><br>
> 4) Now if say node1 were to go down, then stop action on node1 will first<br>
> get called. Haven't decided if I need to do anything specific here.<br>
<br>
</div></div>To clarify, if node1 goes down intentionally (e.g. standby or stop),<br>
then all resources on it will be stopped first. But if node1 becomes<br>
unavailable (e.g. crash or communication outage), it will get fenced.<br>
<span class=""><br>
> 5) But when the start action of node 6 gets called, then using crm command<br>
> line interface, I will modify the above config to swap node 1 and node 6.<br>
> i.e.<br>
> MyGroup1 node6 500<br>
> MyGroup1 node1 0<br>
><br>
> MyGroup2 node2 500<br>
> MyGroup2 node1 0<br>
><br>
> 6) To do the above, I need the newly active and newly standby node names to<br>
> be passed to my start action. What's the best way to get this information<br>
> inside my OCF agent?<br>
<br>
</span>Modifying the configuration from within an agent is dangerous -- too<br>
much potential for feedback loops between pacemaker and the agent.<br>
<br>
I think stickiness will do what you want here. Set a stickiness higher<br>
than the original node's preference, and the resource will want to stay<br>
where it is.<br>
<span class=""><br>
> 7) Apart from node name, there will be other information which I plan to<br>
> pass by making use of node attributes. What's the best way to get this<br>
> information inside my OCF agent? Use crm command to query?<br>
<br>
</span>Any of the command-line interfaces for doing so should be fine, but I'd<br>
recommend using one of the lower-level tools (crm_attribute or<br>
attrd_updater) so you don't have a dependency on a higher-level tool<br>
that may not always be installed.<br>
<div class="HOEnZb"><div class="h5"><br>
> Thank You.<br>
><br>
> On Tue, Dec 22, 2015 at 9:44 PM, Nikhil Utane <<a href="mailto:nikhil.subscribed@gmail.com">nikhil.subscribed@gmail.com</a>><br>
> wrote:<br>
><br>
>> Thanks to you Ken for giving all the pointers.<br>
>> Yes, I can use service start/stop which should be a lot simpler. Thanks<br>
>> again. :)<br>
>><br>
>> On Tue, Dec 22, 2015 at 9:29 PM, Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br>
>><br>
>>> On 12/22/2015 12:17 AM, Nikhil Utane wrote:<br>
>>>> I have prepared a write-up explaining my requirements and current<br>
>>> solution<br>
>>>> that I am proposing based on my understanding so far.<br>
>>>> Kindly let me know if what I am proposing is good or there is a better<br>
>>> way<br>
>>>> to achieve the same.<br>
>>>><br>
>>>><br>
>>> <a href="https://drive.google.com/file/d/0B0zPvL-Tp-JSTEJpcUFTanhsNzQ/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/d/0B0zPvL-Tp-JSTEJpcUFTanhsNzQ/view?usp=sharing</a><br>
>>>><br>
>>>> Let me know if you face any issue in accessing the above link. Thanks.<br>
>>><br>
>>> This looks great. Very well thought-out.<br>
>>><br>
>>> One comment:<br>
>>><br>
>>> "8. In the event of any failover, the standby node will get notified<br>
>>> through an event and it will execute a script that will read the<br>
>>> configuration specific to the node that went down (again using<br>
>>> crm_attribute) and become active."<br>
>>><br>
>>> It may not be necessary to use the notifications for this. Pacemaker<br>
>>> will call your resource agent with the "start" action on the standby<br>
>>> node, after ensuring it is stopped on the previous node. Hopefully the<br>
>>> resource agent's start action has (or can have, with configuration<br>
>>> options) all the information you need.<br>
>>><br>
>>> If you do end up needing notifications, be aware that the feature will<br>
>>> be disabled by default in the 1.1.14 release, because changes in syntax<br>
>>> are expected in further development. You can define a compile-time<br>
>>> constant to enable them.<br>
>>><br>
>>><br>
><br>
<br>
</div></div></blockquote></div><br></div>