[ClusterLabs] Antw: [EXT] Re: Help: Cluster resource relocating to rebooted node automatically
Ben .T.George
bentech4you at gmail.com
Thu Feb 11 04:43:16 EST 2021
HI
yes, it got fixed. And thanks for your time to respond on this matter.
Regards,
Ben
On Thu, Feb 11, 2021 at 12:36 PM Reid Wahl <nwahl at redhat.com> wrote:
>
>
> On Thu, Feb 11, 2021 at 1:35 AM Reid Wahl <nwahl at redhat.com> wrote:
>
>>
>>
>> On Thu, Feb 11, 2021 at 12:35 AM Ulrich Windl <
>> Ulrich.Windl at rz.uni-regensburg.de> wrote:
>>
>>> >>> "Ben .T.George" <bentech4you at gmail.com> schrieb am 10.02.2021 um
>>> 16:14 in
>>> Nachricht
>>> <CA+C_GOUmkREd9HrzKOHmV4r_Q6tdsyrjk8N9SS1LWVALdTh76A at mail.gmail.com>:
>>> > HI
>>> >
>>> > thanks for the Help and i have done "pcs resource clear" and tried the
>>> same
>>> > method again, now the resource is not going back.
>>>
>>
>> To be perfectly clear, did you run `pcs resource clear ems_eg`? That's
>> the full command line to remove the cli-prefer-ems_rg constraint.
>>
>
> I'm sorry. I had misread your message -- I thought you were saying the
> issue was still occurring. I'm glad it's fixed now :)
>
> >
>>> > One more thing I noticed is that my service was from systemd and I have
>>> > created a custom systemd.service file.
>>> >
>>> > If i freeze the resource group, start and stop the service my using
>>> > systemctl, is happening immediately
>>> >
>>> > When I reboot the active node, the cluster is trying to stop the
>>> service,
>>> > it is taking around 1 minutes to stop the service. and at the same
>>> time if
>>> > i check the vm console, the shutdown of the vm process is stuck for
>>> some
>>> > time for stopping high availability services.
>>>
>>> To give any advice on that we need details, typically logs.
>>>
>>
>> +1. Generally, a snippet from /var/log/pacemaker/pacemaker.log (on
>> pacemaker version 2) or /var/log/cluster/corosync.log (on pacemaker version
>> 1) is ideal. In some cases, system logs (e.g., /var/log/messages or
>> journalctl output) can also be helpful.
>>
>>>
>>> >
>>> > Sorry for asking this, i am very new to this cluster
>>> >
>>> > Regards,
>>> > Ben
>>> >
>>> > Is this the expected behaviour?
>>> >
>>> > On Wed, Feb 10, 2021 at 8:53 PM Ken Gaillot <kgaillot at redhat.com>
>>> wrote:
>>> >
>>> >> On Wed, 2021-02-10 at 17:21 +0300, Ben .T.George wrote:
>>> >> > HI
>>> >> >
>>> >> > I have created PCS based 2 node cluster on centos 7 almost
>>> >> > everything is working fine,
>>> >> >
>>> >> > My client machine is on vmware and when I reboot the active node,
>>> the
>>> >> > service group is relocating to the passive node and the resources
>>> are
>>> >> > starting fine(one IP and application).
>>> >> >
>>> >> > But whenever the other node reboots and joins back to the cluster,
>>> >> > the resources are moved back to that node.
>>> >> >
>>> >> > please find below config :
>>> >> > --------------------------------------------
>>> >> > Cluster Name: EMS
>>> >> > Corosync Nodes:
>>> >> > zkwemsapp01.example.com zkwemsapp02.example.com
>>> >> > Pacemaker Nodes:
>>> >> > zkwemsapp01.example.com zkwemsapp02.example.com
>>> >> >
>>> >> > Resources:
>>> >> > Group: ems_rg
>>> >> > Resource: ems_vip (class=ocf provider=heartbeat type=IPaddr2)
>>> >> > Attributes: cidr_netmask=24 ip=10.96.11.39
>>> >> > Meta Attrs: resource-stickiness=1
>>> >> > Operations: monitor interval=30s (ems_vip-monitor-interval-30s)
>>> >> > start interval=0s timeout=20s
>>> (ems_vip-start-interval-
>>> >> > 0s)
>>> >> > stop interval=0s timeout=20s (ems_vip-stop-interval-
>>> >> > 0s)
>>> >> > Resource: ems_app (class=systemd type=ems-app)
>>> >> > Meta Attrs: resource-stickiness=1
>>> >> > Operations: monitor interval=60 timeout=100 (ems_app-monitor-
>>> >> > interval-60)
>>> >> > start interval=0s timeout=100
>>> (ems_app-start-interval-
>>> >> > 0s)
>>> >> > stop interval=0s timeout=100 (ems_app-stop-interval-
>>> >> > 0s)
>>> >> >
>>> >> > Stonith Devices:
>>> >> > Resource: ems_vmware_fence (class=stonith type=fence_vmware_soap)
>>> >> > Attributes: ip=10.151.37.110 password=!CM4!!6j7yiApFT
>>> >> > pcmk_host_map=zkwemsapp01.example.com:
>>> ZKWEMSAPP01;zkwemsapp02.example
>>> >> > .com:ZKWEMSAPP02 ssl_insecure=1 username=mtc_tabs\redhat.fadmin
>>> >> > Operations: monitor interval=60s (ems_vmware_fence-monitor-
>>> >> > interval-60s)
>>> >> > Fencing Levels:
>>> >> > Target: zkwemsapp01.example.com
>>> >> > Level 1 - ems_vmware_fence
>>> >> > Target: zkwemsapp02.example.com
>>> >> > Level 1 - ems_vmware_fence
>>> >> >
>>> >> > Location Constraints:
>>> >> > Resource: ems_rg
>>> >> > Enabled on: zkwemsapp01.example.com (score:INFINITY) (role:
>>> >> > Started) (id:cli-prefer-ems_rg)
>>> >>
>>> >> The above constraint says to prefer that node whenever it is
>>> available.
>>> >> The id starting with "cli-" means that it was added by a command-line
>>> >> tool (most likely "pcs resource move"). When you "move" a resource,
>>> >> you're actually telling the cluster to prefer a specific node, and it
>>> >> remembers that preference until you tell it otherwise. You can remove
>>> >> the preference with "pcs resource clear" (or equivalently crm_resource
>>> >> --clear).
>>> >>
>>> >> I see your resources have resource-stickiness=1. That is how much
>>> >> preference an active resource has for the node that it is currently
>>> on.
>>> >> You can also see the above constraint has a score of INFINITY. If the
>>> >> scores were set such that the stickiness was higher than the
>>> >> constraint, then the stickiness would win and the resource would stay
>>> >> put.
>>> >>
>>> >> > Ordering Constraints:
>>> >> > Colocation Constraints:
>>> >> > Ticket Constraints:
>>> >> >
>>> >> > Alerts:
>>> >> > No alerts defined
>>> >> >
>>> >> > Resources Defaults:
>>> >> > resource-stickiness=1000
>>> >> > Operations Defaults:
>>> >> > No defaults set
>>> >> >
>>> >> > Cluster Properties:
>>> >> > cluster-infrastructure: corosync
>>> >> > cluster-name: EMS
>>> >> > dc-version: 2.0.2-3.el8-744a30d655
>>> >> > have-watchdog: false
>>> >> > last-lrm-refresh: 1612951127
>>> >> > symmetric-cluster: true
>>> >> >
>>> >> > Quorum:
>>> >> > Options:
>>> >> >
>>> >> > --------------------------
>>> >> >
>>> >> > Regards,
>>> >> > Ben
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Manage your subscription:
>>> >> > https://lists.clusterlabs.org/mailman/listinfo/users
>>> >> >
>>> >> > ClusterLabs home: https://www.clusterlabs.org/
>>> >> --
>>> >> Ken Gaillot <kgaillot at redhat.com>
>>> >>
>>> >>
>>>
>>>
>>>
>>> _______________________________________________
>>> Manage your subscription:
>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>
>>> ClusterLabs home: https://www.clusterlabs.org/
>>>
>>>
>>
>> --
>> Regards,
>>
>> Reid Wahl, RHCA
>> Senior Software Maintenance Engineer, Red Hat
>> CEE - Platform Support Delivery - ClusterHA
>>
>
>
> --
> Regards,
>
> Reid Wahl, RHCA
> Senior Software Maintenance Engineer, Red Hat
> CEE - Platform Support Delivery - ClusterHA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20210211/3624ef31/attachment-0001.htm>
More information about the Users
mailing list