From owner-freebsd-fs@freebsd.org Tue Apr 24 11:41:49 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3584DF914F0 for ; Tue, 24 Apr 2018 11:41:49 +0000 (UTC) (envelope-from zmey20000@yahoo.com) Received: from sonic305-47.consmr.mail.ne1.yahoo.com (sonic305-47.consmr.mail.ne1.yahoo.com [66.163.185.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB5C46C2B4 for ; Tue, 24 Apr 2018 11:41:48 +0000 (UTC) (envelope-from zmey20000@yahoo.com) X-YMail-OSG: y_Ci1_YVM1k7RWheLZRLJ_8BL6GaxXz.JKsWvjsPcJJctNfXKLCV3fu_roYTLGP kNdwlsBeWYfiBjLRUFf4tw1a3xdOGinbXTDHdz9LlRMg6ilaQmPHGGYIQUbdac85X72Lu.lGkl9t 3GCC_KVxceJVBjZMyOPniOu58GluhCYAhBXVoqyWggbKk8WnuzpC7i.zR5yZlStvbi_S1FfmQx1a B6M2mShtCmm5oE9_Iv07zhtMXVN5pLIA509bOQvyiBx8tBB5jQ1NktZ1ncqJwIxlIgZJwOoge9ws Juxxb11jIaRM9Q.wo2LqBRvZe3KGHWIVRS1.qWKurcMwN5.kcBxmpRf0m4kZ6S7UVTjfuLcp3_Tt vRz5g7mLhZ7p5ErhF4Y7SnIo1vqUTD35PJ6qPkBkqcxt6jftbb2Zm67OaMMHI563ruQL1lNEBkqu A3j18VfEXBnisMkVxg7w_2wtv9U537IT4kBqCwvZfC_8Oemg.m.o2389m_lpfBeyu0AkfkmHeuH4 BaXqxerolNW0ivRSBjEBInU8qmRq28Co8XAVmeoG_4x7O0_cA7.uWIibbwDpRfHt18WTcr8_XwAx p9olip2.1Yndd0JCwuKVTt0Az Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Apr 2018 11:41:47 +0000 Received: from athe-hcsd-peer.customers.otenet.gr (EHLO [192.168.130.11]) ([195.167.103.234]) by smtp425.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1c83dc9916ea31e6b245869d552b8206; Tue, 24 Apr 2018 11:27:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: ctl_isc_lun_sync: Received conflicting HA LUN From: Mikhail Zakharov X-Mailer: iPad Mail (15E216) In-Reply-To: <1524567842.9560.66.camel@inparadise.se> Date: Tue, 24 Apr 2018 14:27:38 +0300 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <56E4773F-4EAD-47EB-A803-38BFCD8C63F8@yahoo.com> References: <4cb4aa83-bd49-0c20-4e41-c11c682b0570@sentex.net> <1e1e7cd5-0797-c168-fbce-a36edc6a432e@sentex.net> <1524550160.1130.6.camel@inparadise.se> <615DFFBB-239A-4350-B961-FD10D0C9A8DD@yahoo.com> <1524567621.9560.65.camel@inparadise.se> <1524567842.9560.66.camel@inparadise.se> To: karli@inparadise.se X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 11:41:49 -0000 Ah, and unfortunately CTL HA is two-node cluster, as I remember, there is no= possibility to add the third one. So the third node is an external arbiter i= n that case. > 24 =D0=B0=D0=BF=D1=80. 2018 =D0=B3., =D0=B2 14:04, Karli Sj=C3=B6berg =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 >> On Tue, 2018-04-24 at 13:00 +0200, Karli Sj=C3=B6berg via freebsd-fs wrot= e: >>> On Tue, 2018-04-24 at 12:32 +0300, Mikhail Zakharov wrote: >>> Hi Karli, >>>=20 >>> Thank you, I=E2=80=99m just exploring the storage abilities of my prefer= red >>> OS - FreeBSD.=20 >>>=20 >>> Three nodes are preferable to choose the quorum for sure, but my >>> idea >>> was not to establish contacts between nodes. Instead of it, BQ uses >>> a >>> small partition for the =E2=80=9Cquorum=E2=80=9D on the same space where= data >>> volume >>> is located.=20 >>=20 >> Yes, of course. But there=C2=B4s nothing you from having three nodes >=20 > 's/nothing you/nothing stopping you/' >=20 >> connected to the same partition and being able to make more accurate >> choices on when to take over? >>=20 >> If one node stops updating stamps, take over. If two nodes stops >> updating, then the problem is likely network-related and _must not_ >> take over to avoid split brain. Something like that? >>=20 >> /K >>=20 >>> And if a node looses access to the quorum it means, it looses >>> access >>> to the data volume too. Now, BQ runs on both nodes and both BQ >>> instances write stamps to the quorum partition. If for any reason >>> BQ >>> on one node detects, the other node stops updating it=E2=80=99s stamps, i= t >>> performs failover procedure. It=E2=80=99s quite a questionable, rude way= , I >>> can agree, and that=E2=80=99s why I always write a warning to use the Be= aST >>> for testing only purposes.=20 >>>=20 >>> Best regards, >>> Mike >>>=20 >>>> 24 =D0=B0=D0=BF=D1=80. 2018 =D0=B3., =D0=B2 9:09, Karli Sj=C3=B6berg >>>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>>=20 >>>>>> On Mon, 2018-04-23 at 13:11 -0400, Mike Tancsa wrote: >>>>>> On 4/23/2018 12:59 PM, Mikhail Zakharov wrote: >>>>>>=20 >>>>>> Hello Mike, >>>>>>=20 >>>>>> Thank you for your interest to my paper. I appreciate it very >>>>>> much! >>>>>> Your error may be a consequence of the initial HA >>>>>> misconfiguration. >>>>>> What is in your /boot/loader.conf? Although the described >>>>>> config is >>>>>> quite simple, I can recheck the instruction in my paper in a >>>>>> couple >>>>>> of weeks only, unfortunately I=E2=80=99m on vacation right now. >>>>=20 >>>> [snip] >>>>=20 >>>> I read your articles on CTL HA, BQ and BeaST, and just wanted to >>>> say >>>> they are amazing, good job! >>>>=20 >>>> One thing I=C2=B4m wondering about though is if you can claim HA with >>>> just >>>> two nodes, usually you need at least three, where the third is a >>>> tie- >>>> breaker. Otherwise with your current setup, both systems may >>>> loose >>>> contact with each other while both still being powered on, >>>> leading >>>> to >>>> potential split brain situations. What are your thoughts about >>>> that? >>>>=20 >>>> /K