Re: [Linux-ha-dev] quorum status

[Andrew Beekhof]

Check corosync.conf, I'm guessing pcs enabled two node mode.

 On 29 Jan 2015, at 5:21 pm, Yan, Xiaoping (NSN - CN/Hangzhou) 
 xiaoping@nsn.com wrote:
 
 Hi,
 
 I used this command: 
 pcs cluster stop rhel1
 
 I think both is shutdown.
 
 
 Br, Rip
 
 
 -Original Message-
 From: ext Andrew Beekhof [mailto:and...@beekhof.net] 
 Sent: Thursday, January 29, 2015 1:51 PM
 To: Yan, Xiaoping (NSN - CN/Hangzhou)
 Cc: Linux-HA-Dev@lists.linux-ha.org
 Subject: Re: quorum status
 
 Did you shut down pacemaker or corosync or both?
 
 On 29 Jan 2015, at 4:18 pm, Yan, Xiaoping (NSN - CN/Hangzhou) 
 xiaoping@nsn.com wrote:
 
 Hi,
 
 Any suggestion please?
 
 Br, Rip
 _
 From: Yan, Xiaoping (NSN - CN/Hangzhou) 
 Sent: Wednesday, January 28, 2015 4:04 PM
 To: Linux-HA-Dev@lists.linux-ha.org
 Subject: quorum status
 
 
 Hi experts:
 
 I’m making 2 node (rhel1 and rhel2) Linux cluster following 
 Pacemaker-1.1-Clusters_from_Scratch-en-US
 After I shutdown one of the node (pcs cluster stop rhel1) , the other 
 partition still have quorum.
 While according to document, chapter 5.3.1 ,it should be partition without 
 quorum. (A cluster is said to have quorum when total_nodes2*active_nodes)
 What could be the problem?
 Thank you.
 
 [root@rhel2 ~]# pcs status
 Cluster name: mycluster
 Last updated: Wed Jan 28 10:49:46 2015
 Last change: Wed Jan 28 10:07:10 2015 via cibadmin on rhel1
 Stack: corosync
 Current DC: rhel2 (2) - partition with quorum
 Version: 1.1.10-29.el7-368c726
 2 Nodes configured
 1 Resources configured
 
 
 Online: [ rhel2 ]
 OFFLINE: [ rhel1 ]
 
 Full list of resources:
 
 ClusterIP  (ocf::heartbeat:IPaddr2):   Started rhel2
 
 PCSD Status:
  rhel1: Unable to authenticate
  rhel2: Unable to authenticate
 
 Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
 [root@rhel2 ~]# pcs status corosync
 
 Membership information
 --
Nodeid  Votes Name
 2  1 rhel2 (local)
 
 
 Br, Rip
 

___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[Linux-HA] Antw: Re: Antw: Re: Antw: Re: SLES11 SP3: warning: crm_find_peer: Node 'h01' and 'h01' share the same cluster nodeid: 739512321

[Ulrich Windl]

 Lars Marowsky-Bree l...@suse.com schrieb am 28.01.2015 um 17:03 in
Nachricht
20150128160342.gg1...@suse.de:
 On 2015-01-28T16:44:34, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de
wrote:
 
  address actually is 172.20.16.5.
  But I see another node ID of 739512325 (hex 2C141005) which is 
 44.20.16.5. 
  That seems revered compared to the above, and the 0x2c doesn't fit 
 anywhere.
  
  It does. The highbit was stripped.
 
 So the logic is If the hight-bit is not stripped, the ID is the reversed
IP 
 address; if the hight bit is stripped, it's the non-reversed IP address 
 (without the high bit)? Doesn't it cause problems with an IPv4 class A 
 address? Now when is the high-bit stripped?
 
 Hrm. There was a bug (bnc#806634) relating to how the high bit was
 stripped, and that was fixed for SP3.
 
 Were these nodes by chance upgraded from SP2 (with not all updates
 applied) directly to SP3?

Two of the three nodes were actually updated from SP1 via SP2 to SP3, and the
third node was installed with SP3. AFAIR there was no configuration change
since SP1.

 
 Was the corosync.conf option clear_node_high_bit changed?

# grep -i high /etc/corosync/corosync.conf
clear_node_high_bit:new

Could this cause our problem?

Regards,
Ulrich

 
 
 Regards,
 Lars
 
 -- 
 Architect Storage/HA
 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip

 Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
 Experience is the name everyone gives to their mistakes. -- Oscar Wilde
 
 ___
 Linux-HA mailing list
 Linux-HA@lists.linux-ha.org 
 http://lists.linux-ha.org/mailman/listinfo/linux-ha 
 See also: http://linux-ha.org/ReportingProblems 



___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems