[ClusterLabs] Sub-clusters / super-clusters?

[Antony Stone]

On Monday 10 May 2021 at 16:49:07, Strahil Nikolov wrote:

> You can use  node attributes to define in which  city is each host and then
> use a location constraint to control in which city to run/not run the
> resources. I will try to provide an example tomorrow.

Thank you - that would be helpful.

I did think that a location constraint could be a way to do this, but I wasn't 
sure how to label three machines in one cluster as a "single location".

Any pointers most welcome :)

>   On Mon, May 10, 2021 at 15:52, Antony Stone wrote:
> >   On Monday 10 May 2021 at 14:41:37, Klaus Wenninger wrote:
> > On 5/10/21 2:32 PM, Antony Stone wrote:
> > > Hi.
> > > 
> > > I'm using corosync 3.0.1 and pacemaker 2.0.1, currently in the
> > > following way:
> > > 
> > > I have two separate clusters of three machines each, one in a data
> > > centre in city A, and one in a data centre in city B.
> > > 
> > > Several of the resources being managed by these clusters are based on
> > > floating IP addresses, which are tied to the data centre, therefore the
> > > resources in city A can run on any of the three machines there (alfa,
> > > bravo and charlie), but cannot run on any machine in city B (delta,
> > > echo and foxtrot).
> > > 
> > > I now have a need to create a couple of additional resources which can
> > > operate from anywhere, so I'm wondering if there is a way to configure
> > > corosync / pacemaker so that:
> > > 
> > > Machines alfa, bravo, charlie live in city A and manage resources X, Y
> > > and Z between them.
> > > 
> > > Machines delta, echo and foxtrot live in city B and manage resources U,
> > > V and W between them.
> > > 
> > > All of alpha to foxtrot are also in a "super-cluster" managing
> > > resources P and Q, so these two can be running on any of the 6
> > > machines.
> > > 
> > > 
> > > I hope the question is clear.  Is there an answer :) ?
> > 
> > Sounds like a use-case for https://github.com/ClusterLabs/booth
> 
> Interesting - hadn't come across that feature before.
> 
> Thanks - I'll look into further documentation.
> 
> If anyone else has any other suggestions I'm happy to see whether something
> else might work better for my setup.
> 
> 
> Antony.

-- 
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

                                                   Please reply to the list;
                                                         please *don't* CC me.