ctl_isc_lun_sync: Received conflicting HA LUN

Karli Sjöberg karli at inparadise.se
Tue Apr 24 15:45:28 UTC 2018



Mikhail Zakharov <zmey20000 at yahoo.com> skrev: (24 april 2018 13:27:38 CEST)
>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 in that case.

Yes, Arbiter, exactly the term I was looking for:) So it would be up to the Arbiter to decide whether it really is a node problem or a network problem- a tie-breaker. Would that be feasible in your software?

/K

>
>
>> 24 апр. 2018 г., в 14:04, Karli Sjöberg <karli at inparadise.se>
>написал(а):
>> 
>>> On Tue, 2018-04-24 at 13:00 +0200, Karli Sjöberg via freebsd-fs
>wrote:
>>>> On Tue, 2018-04-24 at 12:32 +0300, Mikhail Zakharov wrote:
>>>> Hi Karli,
>>>> 
>>>> Thank you, I’m just exploring the storage abilities of my preferred
>>>> OS - FreeBSD. 
>>>> 
>>>> 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 “quorum” on the same space where data
>>>> volume
>>>> is located. 
>>> 
>>> Yes, of course. But there´s nothing you from having three nodes
>> 
>> 's/nothing you/nothing stopping you/'
>> 
>>> connected to the same partition and being able to make more accurate
>>> choices on when to take over?
>>> 
>>> 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?
>>> 
>>> /K
>>> 
>>>> 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’s stamps, it
>>>> performs failover procedure. It’s quite a questionable, rude way, I
>>>> can agree, and that’s why I always write a warning to use the BeaST
>>>> for testing only purposes. 
>>>> 
>>>> Best regards,
>>>> Mike
>>>> 
>>>>> 24 апр. 2018 г., в 9:09, Karli Sjöberg <karli at inparadise.se>
>>>>> написал(а):
>>>>> 
>>>>>>> On Mon, 2018-04-23 at 13:11 -0400, Mike Tancsa wrote:
>>>>>>> On 4/23/2018 12:59 PM, Mikhail Zakharov wrote:
>>>>>>> 
>>>>>>> Hello Mike,
>>>>>>> 
>>>>>>> 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’m on vacation right now.
>>>>> 
>>>>> [snip]
>>>>> 
>>>>> I read your articles on CTL HA, BQ and BeaST, and just wanted to
>>>>> say
>>>>> they are amazing, good job!
>>>>> 
>>>>> One thing I´m 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?
>>>>> 
>>>>> /K

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.


More information about the freebsd-fs mailing list