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

[Andrei Borzenkov]

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.

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).


> 
>>
>> 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/
>>