[Pacemaker] quorum disk

[Andrew Beekhof]

On Mon, Feb 8, 2010 at 4:59 PM, jimbob palmer <jimbobpalmer at gmail.com> wrote:
> 2010/2/8 Andrew Beekhof <andrew at beekhof.net>:
>> On Mon, Feb 8, 2010 at 4:36 PM, jimbob palmer <jimbobpalmer at gmail.com> wrote:
>>>>>> I've searched the mailing lists for qdisk, quorum disk and quorum
>>>>>> partition but found nothing.
>>>>>>
>>>>>> How can I configure a two node cluster to use
>>>>>
>>>>> a quorum disk so that the node that can see the disk will keep resources?
>>>>
>>>> We dont have support for qdisk.
>>>> Check out no-quorum-policy instead.
>>>
>>> I can't find much documentation for no-quorum-policy. I need the
>>> cluster to keep working in case the connections between the two
>>> datacenters are cut. It should be impossible (or very nearly
>>> impossible) for both sides to have the clustered resource up. This is
>>> for a drbd+nfs+ip setup.
>>>
>>> no-quorum-policy doesn't seem to help with the split brain situation does it?
>>
>> No, but I can't imagine qdisk does either.
>> Do you at least have fencing?
>
> Fencing wouldn't give me an advantage because the physical path to the
> second datacenter is not separate for networking and san. In the event
> of a cut, the primary site needs to win.

Yeah, but define "primary" and how is the other node supposed to know that?
If there's no comms (and therefor no SAN access), then there is simply
not enough information to make the correct decision (and even if it
could, there'd be no way to ensure the other side was unable to access
its storage).

At best, no-quorum-policy=freeze might be a viable alternative.

>
>>>> Alternatively, you could create a scsi-reservation resource and
>>>> colocate your other resources with that (aka. a resource driven
>>>> cluster)
>
> This sounds good, so all resources have a parent resource which has
> the ability to get a scsi reservation?

right

>
> Where can I find out about this? I can see a resource called
> scsi2reservation but it mentions an out-of-distro package called
> scsires. It would be good if I could use sg_persist instead.
>
> Am I going in the right direction?

I think so, but to-date I'm not aware of anyone that really went far
down this path.

>>>
>>> Is this like ocfs2? Each node locks a journal, and if it can't lock
>>> the journal its kernel panics?
>>
>> No, it just prevents the resources that depend on the scsi lock from
>> running if it can't get the lock .
>>
>>> Leaving the cluster would be better
>>> here. Where can I read about this?
>>
>> This is a good start on the concept:
>>   http://devresources.linux-foundation.org/dev/clusters/docs/ResourceDrivenClusters.pdf
>
> Thanks for this. Any more configuration-related documentation you can
> throw at me would be good :)

No such thing I'm afraid.  No-one's documented this.
But in theory, once you get a functional reservation resource you just
need so colocation constraints (and those are documented).