>Because Asterisk at cityA is bound to a floating IP address, which is held
>onone of the three machines in cityA. I can't run Asterisk on all
>threemachines there because only one of them has the IP address.
That's not true. You can use a cloned IP resource with 'globally-unique=true'
which
On Friday 06 August 2021 at 15:12:57, Andrei Borzenkov wrote:
> On Fri, Aug 6, 2021 at 3:42 PM Antony Stone wrote:
> > On Friday 06 August 2021 at 14:14:09, Andrei Borzenkov wrote:
> > >
> > > If connectivity between (any two) sites is lost you may end up with
> > > one of A or B going out of
On Fri, Aug 6, 2021 at 3:42 PM Antony Stone
wrote:
>
> On Friday 06 August 2021 at 14:14:09, Andrei Borzenkov wrote:
>
> > On Thu, Aug 5, 2021 at 3:44 PM Antony Stone wrote:
> > >
> > > For anyone interested in the detail of how to do this (without needing
> > > booth), here is my cluster.conf
On Friday 06 August 2021 at 14:14:09, Andrei Borzenkov wrote:
> On Thu, Aug 5, 2021 at 3:44 PM Antony Stone wrote:
> >
> > For anyone interested in the detail of how to do this (without needing
> > booth), here is my cluster.conf file, as in "crm configure load replace
> > cluster.conf":
> >
>
On Thu, Aug 5, 2021 at 3:44 PM Antony Stone
wrote:
>
> On Thursday 05 August 2021 at 10:51:37, Antony Stone wrote:
>
> > On Thursday 05 August 2021 at 07:48:37, Ulrich Windl wrote:
> > >
> > > Have you ever tried to find out why this happens? (Talking about logs)
> >
> > Not in detail, no, but
On Thursday 05 August 2021 at 15:44:18, Ulrich Windl wrote:
> Hi!
>
> Nice to hear. What could be "interesting" is how stable the WAN-type of
> corosync communication works.
Well, between cityA and cityB it should be pretty good, because these are two
data centres on opposite sides of England
On Thursday 05 August 2021 at 10:51:37, Antony Stone wrote:
> On Thursday 05 August 2021 at 07:48:37, Ulrich Windl wrote:
> >
> > Have you ever tried to find out why this happens? (Talking about logs)
>
> Not in detail, no, but just in case there's a chance of getting this
> working as
On 03/08/2021 10:40, Antony Stone wrote:
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
On Tue, Aug 3, 2021 at 11:40 AM Antony Stone
wrote:
>
> 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
On Tue, Aug 3, 2021 at 10:41 AM Antony Stone
wrote:
> 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
Hi
You probably want to look at booth and tickets for a geo-clustering solution.
On August 3, 2021 11:40:54 AM Antony Stone
wrote:
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
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
>
>
Here is the example I had promised:
pcs node attribute server1 city=LApcs node attribute server2 city=NY
# Don't run on any node that is not in LApcs constraint location DummyRes1 rule
score=-INFINITY city ne LA
#Don't run on any node that is not in NYpcs constraint location DummyRes2 rule
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.
Best Regards,Strahil Nikolov
On Mon, May 10, 2021 at 15:52, Antony Stone
wrote: On
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
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,
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
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
18 matches
Mail list logo
