<div dir="ltr"><div>Fencing is done using fence_scsi. <br></div><div>Config details are as follows:</div><div> Resource: scsi (class=stonith type=fence_scsi)<br>  Attributes: devices=/dev/mapper/mpatha pcmk_host_list="node1 node2" pcmk_monitor_action=metadata pcmk_reboot_action=off<br>  Meta Attrs: provides=unfencing<br>  Operations: monitor interval=60s (scsi-monitor-interval-60s)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 15, 2021 at 7:17 AM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> shivraj dongawe <<a href="mailto:shivraj198@gmail.com" target="_blank">shivraj198@gmail.com</a>> schrieb am 14.02.2021 um 12:03 in<br>
Nachricht<br>
<<a href="mailto:CALpaHO--3ERfwST70mBL-Wm9g6yH3YtD-wDA1r_CKnbrsxu4Sg@mail.gmail.com" target="_blank">CALpaHO--3ERfwST70mBL-Wm9g6yH3YtD-wDA1r_CKnbrsxu4Sg@mail.gmail.com</a>>:<br>
> We are running a two node cluster on Ubuntu 20.04 LTS. Cluster related<br>
> package version details are as<br>
> follows: pacemaker/focal-updates,focal-security 2.0.3-3ubuntu4.1 amd64<br>
> pacemaker/focal 2.0.3-3ubuntu3 amd64<br>
> corosync/focal 3.0.3-2ubuntu2 amd64<br>
> pcs/focal 0.10.4-3 all<br>
> fence-agents/focal 4.5.2-1 amd64<br>
> gfs2-utils/focal 3.2.0-3 amd64<br>
> dlm-controld/focal 4.0.9-1build1 amd64<br>
> lvm2-lockd/focal 2.03.07-1ubuntu1 amd64<br>
> <br>
> Cluster configuration details:<br>
> 1. Cluster is having a shared storage mounted through gfs2 filesystem with<br>
> the help of dlm and lvmlockd.<br>
> 2. Corosync is configured to use knet for transport.<br>
> 3. Fencing is configured using fence_scsi on the shared storage which is<br>
> being used for gfs2 filesystem<br>
> 4. Two main resources configured are cluster/virtual ip and postgresql-12,<br>
> postgresql-12 is configured as a systemd resource.<br>
> We had done failover testing(rebooting/shutting down of a node, link<br>
> failure) of the cluster and had observed that resources were getting<br>
> migrated properly on the active node.<br>
> <br>
> Recently we came across an issue which has occurred repeatedly in span of<br>
> two days.<br>
> Details are below:<br>
> 1. Out of memory killer is getting invoked on active node and it starts<br>
> killing processes.<br>
> Sample is as follows:<br>
> postgres invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE),<br>
> order=0, oom_score_adj=0<br>
> 2. At one instance it started with killing of pacemaker and on another with<br>
> postgresql. It does not stop with the killing of a single process it goes<br>
> on killing others(more concerning is killing of cluster related processes)<br>
> as well. We have observed that swap space on that node is 2 GB against RAM<br>
> of 96 GB and are in the process of increasing swap space to see if this<br>
> resolves this issue. Postgres is configured with shared_buffers value of 32<br>
> GB(which is way less than 96 GB).<br>
> We are not yet sure which process is eating up that much memory suddenly.<br>
> 3. As a result of killing processes on node1, node2 is trying to fence<br>
> node1 and thereby initiating stopping of cluster resources on node1.<br>
<br>
How is fencing being done?<br>
<br>
> 4. At this point we go in a stage where it is assumed that node1 is down<br>
> and application resources, cluster IP and postgresql are being started on<br>
> node2.<br>
> 5. Postgresql on node 2 fails to start in 60 sec(start operation timeout)<br>
> and is declared as failed. During the start operation of postgres, we have<br>
> found many messages related to failure of fencing and other resources such<br>
> as dlm and vg waiting for fencing to complete.<br>
> Details of syslog messages of node2 during this event are attached in file.<br>
> 6. After this point we are in a state where node1 and node2 both go in<br>
> fenced state and resources are unrecoverable(all resources on both nodes).<br>
> <br>
> Now my question is out of memory issue of node1 can be taken care by<br>
> increasing swap and finding out the process responsible for such huge<br>
> memory usage and taking necessary actions to minimize that memory usage,<br>
> but the other issue that remains unclear is why cluster is not shifted to<br>
> node2 cleanly and become unrecoverable.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div>