[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