[ClusterLabs] Colocating a Virtual IP address with multiple resources

kgaillot at redhat.com kgaillot at redhat.com
Mon Jun 7 17:52:10 EDT 2021


On Mon, 2021-06-07 at 20:37 +0000, Abithan Kumarasamy wrote:
> Hello Team,
>  
> We have been recently experimenting with some resource model options
> to fulfil the following scenario. We would like to collocate a
> virtual IP resource with multiple db resources. When the virtual IP
> fails over to another node, all the dbs associated should also fail
> over to the new node. We were able to accomplish this with resource
> sets as defined in Example 6.17 in this documentation page: 
> https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html#s-resource-sets-colocation
> . However, whenever a single db fails over to the other node, the
> virtual IP address and the other dbs are not following and failing
> over to the other node. Are there any configurations that may be
> causing this undesired behaviour? We have already tried resource
> sets, colocation constraints, and ordering constraints. Are there any
> other models that we should consider to achieve this solution? Our
> current constraint model looks like this in a simplified manner.
>  
> <rsc_colocation id="vip-with-multiple-dbs" score="INFINITY" >
> <resource_set id="db-set" role=”Master”>
> <resource_ref id="db1"/> 
> <resource_ref id="db2"/>
> <resource_ref id="db3"/> 
> <resource_ref id="db4"/>
> </resource_set>
> <resource_set id="vip-set">
> <resource_ref id="primary-VIP"/>
> </resource_set>
> </rsc_colocation>

With the above configuration, the resources should fail over all
together. However the database colocations are limited to the promoted
role; any unpromoted instances can fail over without restrictions.

If you want the dbs to depend only on the IP, and not each other, add
sequential="false" to db-set.

With the exact above configuration, is the promoted role of one of the
databases failing over to a node that's not running the IP?

>  
> Thanks,
> Abithan
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list