[ClusterLabs] Two node cluster goes into split brain scenario during CPU intensive tasks

Somanath Jeeva somanath.jeeva at ericsson.com
Tue Jun 25 07:06:38 EDT 2019


I have not configured fencing in our setup . However I would like to know if the split brain can be avoided when high CPU occurs. 


With Regards
Somanath Thilak J

-----Original Message-----
From: Ken Gaillot <kgaillot at redhat.com> 
Sent: Monday, June 24, 2019 20:28
To: Cluster Labs - All topics related to open-source clustering welcomed <users at clusterlabs.org>; Somanath Jeeva <somanath.jeeva at ericsson.com>
Subject: Re: [ClusterLabs] Two node cluster goes into split brain scenario during CPU intensive tasks

On Mon, 2019-06-24 at 08:52 +0200, Jan Friesse wrote:
> Somanath,
> 
> > Hi All,
> > 
> > I have a two node cluster with multicast (udp) transport . The 
> > multicast IP used in 224.1.1.1 .
> 
> Would you mind to give a try to UDPU (unicast)? For two node cluster 
> there is going to be no difference in terms of speed/throughput.
> 
> > 
> > Whenever there is a CPU intensive task the pcs cluster goes into 
> > split brain scenario and doesn't recover automatically . We have to

In addition to others' comments: if fencing is enabled, split brain should not be possible. Automatic recovery should work as long as fencing succeeds. With fencing disabled, split brain with no automatic recovery can definitely happen.

> > do a manual restart of services to bring both nodes online again. 
> 
> Before the nodes goes into split brain , the corosync log shows ,
> > 
> > May 24 15:10:02 server1 corosync[4745]:  [TOTEM ] Retransmit List:
> > 7c 7e
> > May 24 15:10:02 server1 corosync[4745]:  [TOTEM ] Retransmit List:
> > 7c 7e
> > May 24 15:10:02 server1 corosync[4745]:  [TOTEM ] Retransmit List:
> > 7c 7e
> > May 24 15:10:02 server1 corosync[4745]:  [TOTEM ] Retransmit List:
> > 7c 7e
> > May 24 15:10:02 server1 corosync[4745]:  [TOTEM ] Retransmit List:
> > 7c 7e
> 
> This is usually happening when:
> - multicast is somehow rate-limited on switch side (configuration/bad 
> switch implementation/...)
> - MTU of network is smaller than 1500 bytes and fragmentation is not 
> allowed -> try reduce totem.netmtu
> 
> Regards,
>    Honza
> 
> 
> > May 24 15:51:42 server1 corosync[4745]:  [TOTEM ] A processor 
> > failed, forming new configuration.
> > May 24 16:41:42 server1 corosync[4745]:  [TOTEM ] A new membership
> > (10.241.31.12:29276) was formed. Members left: 1 May 24 16:41:42 
> > server1 corosync[4745]:  [TOTEM ] Failed to receive the leave 
> > message. failed: 1
> > 
> > Is there any way we can overcome this or this may be due to any 
> > multicast issues in the network side.
> > 
> > With Regards
> > Somanath Thilak J
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Manage your subscription:
> > https://protect2.fireeye.com/url?k=cf120bda-9398df1b-cf124b41-863d9b
> > cb726f-716d821bbcb5bd46&q=1&u=https%3A%2F%2Flists.clusterlabs.org%2F
> > mailman%2Flistinfo%2Fusers
> > 
> > ClusterLabs home: 
> > https://protect2.fireeye.com/url?k=eb2ec5bb-b7a4117a-eb2e8520-863d9b
> > cb726f-b47e1043056350cb&q=1&u=https%3A%2F%2Fwww.clusterlabs.org%2F
> > 
> 
> _______________________________________________
> Manage your subscription:
> https://protect2.fireeye.com/url?k=99a652fd-c52c863c-99a61266-863d9bcb
> 726f-72abff69ac96d9a3&q=1&u=https%3A%2F%2Flists.clusterlabs.org%2Fmail
> man%2Flistinfo%2Fusers
> 
> ClusterLabs home: 
> https://protect2.fireeye.com/url?k=d77f0141-8bf5d580-d77f41da-863d9bcb
> 726f-0762985c29a467ea&q=1&u=https%3A%2F%2Fwww.clusterlabs.org%2F
--
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list