[ClusterLabs] Antw: [EXT] Colocation per site ?

Ken Gaillot kgaillot at redhat.com
Tue Mar 30 10:42:56 EDT 2021


On Tue, 2021-03-30 at 08:01 +0300, Andrei Borzenkov wrote:
> On 29.03.2021 20:12, Ken Gaillot wrote:
> > On Sun, 2021-03-28 at 09:20 +0300, Andrei Borzenkov wrote:
> > > On 28.03.2021 07:16, Strahil Nikolov wrote:
> > > > I didn't mean DC as a designated coordinator, but as a physical
> > > > Datecenter location.
> > > > Last time I checked, the node attributes for all nodes seemed
> > > > the
> > > > same.I will verify that tomorrow (Monday).
> > > > 
> > > 
> > > Yes, I was probably mistaken. It is different with scale-out,
> > > agent
> > > puts
> > > information in global property section of CIB.
> > > 
> > > Ideally we'd need expression that says "on node where site
> > > attribute
> > > is
> > > the same as on node where clone master is active" but I guess
> > > there
> > > is
> > > no way to express it in pacemaker.
> > 
> > Yep, colocation by node attribute (combined with colocation with
> > promoted role)
> > 
> > https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacemaker_Explained/index.html#_colocation_properties
> > 
> 
> 
> Sorry, I must be daft but I do not see how it helps.
> 
> There are two sets of nodes. One set has property site=A, another set
> -
> site=B. This can be assumed to be static in this case and never
> changing.
> 
> There is a set of resources that must run on each node of either site
> A
> or site B. Which site depends on where some other resource (in this
> case
> clone master) is currently active.
> 
> Colocation does not work, this will force everything on the same node
> where master is active and that is not what we want.

Nope, you can colocate by node attribute instead of node.

Colocating by node attribute says "put this resource on a node that has
the same value of this node attribute as the node running this other
resource". So if site is the node attribute, colocating A with B by
site means that A has to run on a node that has the same value for site
as wherever B is.

Simple colocation by node is actually implemented internally as
colocation by node attribute where the attribute is the node name.

> Location constraints do not work because required value of "site" is
> not
> known in advance and rules can only use static values to compare node
> attributes (i.e. value is either literal, or is taken from resource
> parameter or from resource meta-attribute).

For colocation by attribute, what is static in the configuration is the
name of the attribute -- the cluster dynamically compares the values.


> > > I do not see any easy way to implement it without essentially
> > > duplicating SAPHanaTopology. There are some attributes that are
> > > defined
> > > but never set so far, you may try to open service request to
> > > implement
> > > consistent attribute for all nodes on current primary site.
> > > 
> > > ...
> > > 
> > > Hmm ... agent sets (at least, should set) hana_${SID}_vhost
> > > attribute
> > > for each node and this attribute must be unique and different
> > > between
> > > two sites. May be worth to look into it.
> > > 
> > > 
> > > > Best Regards,Strahil Nikolov
> > > >  
> > > >  
> > > >   On Fri, Feb 19, 2021 at 16:51, Andrei Borzenkov<
> > > > arvidjaar at gmail.com> wrote:   On Fri, Feb 19, 2021 at 2:44 PM
> > > > Strahil Nikolov <hunter86_bg at yahoo.com> wrote:
> > > > > 
> > > > > 
> > > > > > Do you have a fixed relation between node >pairs and VIPs?
> > > > > > I.e.
> > > > > > must
> > > > > > A/D always get VIP1, B/E - VIP2 etc?
> > > > > 
> > > > > I have to verify it again, but generally speaking - yes ,
> > > > > VIP1 is
> > > > > always on nodeA/D (master), VIP2 on nodeB/E (worker1) , etc.
> > > > > 
> > > > > I guess I can set negative constraints (-inf) -> VIP1 on node
> > > > > B/E
> > > > > + nodeC/F, but the stuff with the 'same DC as master' is the
> > > > > tricky part.
> > > > > 
> > > > 
> > > > I am not sure I understand what DC has to do with it. You have
> > > > two
> > > > scale-out SAP HANA instances, one is primary, another is
> > > > secondary.
> > > > If
> > > > I understand correctly your requirements, your backup
> > > > application
> > > > needs to contact the primary instance which may failover to
> > > > another
> > > > site. You must be using some resource agent for it, to manage
> > > > failover. The only one I am aware of is SAPHanaSR-ScaleOut. It
> > > > already
> > > > sets different node properties for primary and secondary sites.
> > > > Just
> > > > use them. If you use something else, just look at what
> > > > attributes
> > > > your
> > > > RA sets. Otherwise you will be essentially duplicating your RA
> > > > functionality because you will somehow need to find out which
> > > > site
> > > > is
> > > > currently primary.
> > > > 
> > > > There is no guarantee that pacemaker DC wil be on the same site
> > > > as
> > > > SAP
> > > > HANA primary system.
> > > >   
> > > > 
> > > 
> > > _______________________________________________
> > > Manage your subscription:
> > > https://lists.clusterlabs.org/mailman/listinfo/users
> > > 
> > > ClusterLabs home: https://www.clusterlabs.org/
> > > 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
> 
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list