Re: [ClusterLabs] Two-Node Failover IP-Address and Gateway

On Mon, Jan 22, 2018 at 10:09 PM, brainheadz wrote: > Hello Andrei, > > yes this fixes the issue. But is there a way to automate this process > without a manual intervention? > Normally adding and removing this constraint is manual process by design. Do you mean this

Re: [ClusterLabs] Two-Node Failover IP-Address and Gateway

Hello Andrei, yes this fixes the issue. But is there a way to automate this process without a manual intervention? Node1 fails. Node2 takes over the vip_bad and ipsrcaddr. Node1 is back online. vip_bad and ipsrcaddr are moved back to Node1. Node2 sets the correct default_gw and it's own

Re: [ClusterLabs] Two-Node Failover IP-Address and Gateway

22.01.2018 20:54, brainheadz пишет: > Hello, > > I've got 2 public IP's and 2 Hosts. > > Each IP is assigned to one host. The interfaces are not configured by the > system, I am using pacemaker to do this. > > fw-managed-01: 100.200.123.166/29 > fw-managed-02: 100.200.123.165/29 > > gateway:

[ClusterLabs] Two-Node Failover IP-Address and Gateway

Hello, I've got 2 public IP's and 2 Hosts. Each IP is assigned to one host. The interfaces are not configured by the system, I am using pacemaker to do this. fw-managed-01: 100.200.123.166/29 fw-managed-02: 100.200.123.165/29 gateway: 100.200.123.161 I am trying to get some form of

Re: [ClusterLabs] pengine bug? Recovery after monitor failure: Restart of DRBD does not restart Filesystem -- unless explicit order start before promote on DRBD

On Fri, Jan 19, 2018 at 04:52:40PM -0600, Ken Gaillot wrote: > Your constraints are: > > place IP then place drbd instance(s) with it > start IP then start drbd instance(s) > > place drbd master then place fs with it > promote drbd master then start fs > > I'm guessing you meant to

Re: [ClusterLabs] Antw: Clone resource active only if all nodes are active

On Mon, 2018-01-22 at 14:18 +0100, Ulrich Windl wrote: > Did you try  meta clone-node-min=3? clone-min does not affect the clone it's configured on, but rather anything ordered relative to it via a constraint. It's for the case where a resource needs a certain number of instances running before

Re: [ClusterLabs] Antw: Clone resource active only if all nodes are active

On 01/22/2018 02:55 PM, alu...@poczta.onet.pl wrote: > Unfortunately meta clone-min introduced since 1.1.14 but I am using > 1.1.12. > > Is there any other options to have such type of resource? If not I > have to updatepacemaker software. Other possibility coming to my mind would be 3 primitives

Re: [ClusterLabs] Antw: Clone resource active only if all nodes are active

Unfortunately meta clone-min introduced since 1.1.14 but I am using 1.1.12. Is there any other options to have such type of resource? If not I have to updatepacemaker software. On 22.01.2018 14:18, Ulrich Windl wrote: > Did you try meta clone-node-min=3? > > "alu...@poczta.onet.pl"

[ClusterLabs] Antw: Clone resource active only if all nodes are active

Did you try meta clone-node-min=3? >>> "alu...@poczta.onet.pl" schrieb am 22.01.2018 um >>> 13:29 in Nachricht <844fdf99-1680-3ed8-6afc-8b3e2ddea...@poczta.onet.pl>: > I need to create configuration when one resource is active on all nodes > and is only active when all

[ClusterLabs] Clusterstack Dependency on SBD with systemd

Hi! Wanted to pick up where we dropped the issue before Christmas. Observations as a result of a startup-timeout issue led to the awareness that the way we are starting SBD together with the rest of the Clusterstack doesn't handle SBD startup-issues properly. SBD is integrated in the

Re: [ClusterLabs] “pcs --debug” does not work

On 01/22/2018 01:06 PM, Tomas Jelinek wrote: > Dne 22.1.2018 v 11:01 Klaus Wenninger napsal(a): >> On 01/22/2018 10:46 AM, Tomas Jelinek wrote: >>> Hello, >>> >>> the --debug option is supposed to be used as an additional option for >>> a pcs command, for example: >>> >>> pcs status --debug >>>

[ClusterLabs] Clone resource active only if all nodes are active

I need to create configuration when one resource is active on all nodes and is only active when all nodes are active. It should has the same priority on all nodes. The major target is to have my service started when all nodes are active and to have my service stopped in "degraded" state. I tried

Re: [ClusterLabs] “pcs --debug” does not work

Dne 22.1.2018 v 11:01 Klaus Wenninger napsal(a): On 01/22/2018 10:46 AM, Tomas Jelinek wrote: Hello, the --debug option is supposed to be used as an additional option for a pcs command, for example: pcs status --debug pcs --debug resource create dummy ocf:pacemaker:Dummy It writes what a

Re: [ClusterLabs] [IMPORTANT] Fatal, yet rare issue verging on libqb's design flaw and/or it's use corosync around daemon-forking

It was discovered that corosync exposes itself for a self-crash under rare circumstance whereby corosync executable is run when there is already a daemon instance around (does not apply to corosync serving without any backgrounding, i.e. launched with "-f" switch). Such a circumstance can be

Re: [ClusterLabs] “pcs --debug” does not work

On 01/22/2018 10:46 AM, Tomas Jelinek wrote: > Hello, > > the --debug option is supposed to be used as an additional option for > a pcs command, for example: > > pcs status --debug > pcs --debug resource create dummy ocf:pacemaker:Dummy > > It writes what a command is doing in the background -

Re: [ClusterLabs] “pcs --debug” does not work

Hello, the --debug option is supposed to be used as an additional option for a pcs command, for example: pcs status --debug pcs --debug resource create dummy ocf:pacemaker:Dummy It writes what a command is doing in the background - running other commands, communicating over network.

[ClusterLabs] “pcs --debug” does not work

Hello, The help of "pcs --debug" says " Print all network traffic and external commands run." But when I run the "pcs --debug", it still print the help information. How to trigger it to print the network traffic? Thanks Steven [root@db3 ~]# pcs --debug Usage: pcs [-f file] [-h] [commands]...

[ClusterLabs] [IMPORTANT] Fatal, yet rare issue verging on libqb's design flaw and/or it's use corosync around daemon-forking

It was discovered that corosync exposes itself for a self-crash under rare circumstance whereby corosync executable is run when there is already a daemon instance around (does not apply to corosync serving without any backgrounding, i.e. launched with "-f" switch). Such a circumstance can be