[ClusterLabs] Antw: [EXT] Re: Sub‑clusters / super‑clusters?

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Tue Aug 3 05:01:14 EDT 2021


>>> Antony Stone <Antony.Stone at ha.open.source.it> schrieb am 03.08.2021 um
10:40 in
Nachricht <202108031040.28312.Antony.Stone at ha.open.source.it>:
> On Tuesday 11 May 2021 at 12:56:01, Strahil Nikolov wrote:
> 
>> Here is the example I had promised:
>>
>> pcs node attribute server1 city=LA
>> pcs node attribute server2 city=NY
>>
>> # Don't run on any node that is not in LA
>> pcs constraint location DummyRes1 rule score=‑INFINITY city ne LA
>> 
>> #Don't run on any node that is not in NY
>> pcs constraint location DummyRes2 rule score=‑INFINITY city ne NY

Hi!

Out of curiosity: Could one write a rule that demands that a resource
migration should (not) happen within the same city?
("should" means "perferably when there are alternatives")

Regards,
Ulrich



>>
>> The idea is that if you add a node and you forget to specify the attribute
>> with the name 'city' , DummyRes1 & DummyRes2 won't be started on it.
>> 
>> For resources that do not have a constraint based on the city ‑> they will
>> run everywhere unless you specify a colocation constraint between the
>> resources.
> 
> Excellent ‑ thanks.  I happen to use crmsh rather than pcs, but I've adapted

> the above and got it working.
> 
> Unfortunately, there is a problem.
> 
> My current setup is:
> 
> One 3‑machine cluster in city A running a bunch of resources between them, 
> the 
> most important of which for this discussion is Asterisk telephony.
> 
> One 3‑machine cluster in city B doing exactly the same thing.
> 
> The two clusters have no knowledge of each other.
> 
> I have high‑availability routing between my clusters and my upstream 
> telephony 
> provider, such that a call can be handled by Cluster A or Cluster B, and if

> one is unavailable, the call gets routed to the other.
> 
> Thus, a total failure of Cluster A means I still get phone calls, via 
> Cluster 
> B.
> 
> 
> To implement the above "one resource which can run anywhere, but only a 
> single 
> instance", I joined together clusters A and B, and placed the corresponding

> location constraints on the resources I want only at A and the ones I want 
> only at B.  I then added the resource with no location constraint, and it 
> runs 
> anywhere, just once.
> 
> So far, so good.
> 
> 
> The problem is:
> 
> With the two independent clusters, if two machines in city A fail, then 
> Cluster A fails completely (no quorum), and Cluster B continues working.  
> That 
> means I still get phone calls.
> 
> With the new setup, if two machines in city A fail, then _both_ clusters 
> stop 
> working and I have no functional resources anywhere.
> 
> 
> So, my question now is:
> 
> How can I have a 3‑machine Cluster A running local resources, and a
3‑machine 
> Cluster B running local resources, plus one resource running on either 
> Cluster 
> A or Cluster B, but without a failure of one cluster causing _everything_ to

> 
> stop?

Kind of stupid idea:
Set up an IP address on the cluster that runs your special resource
(colocation) and make the other cluster monitor that IP address: If the IP is
down for some time, launch your resource locally.
Probably you want two different  IP adresses in each cluster.
The other question is: How harmful is it if both clusters run the resource for
a short time?

Basically you need a kind of "cross-cluster semaphore" that keeps the state
whether your resource is running somewhere.

Regards,
Ulrich

> 
> 
> Thanks,
> 
> 
> Antony.
> 
> ‑‑ 
> One tequila, two tequila, three tequila, floor.
> 
>                                                    Please reply to the
list;
>                                                          please *don't* CC 
> me.
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/ 





More information about the Users mailing list