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< > > > > arvidj...@gmail.com> wrote: On Fri, Feb 19, 2021 at 2:44 PM > > > > Strahil Nikolov <hunter86...@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 <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/