[ovirt-devel] Sanlock fencing reservations

[David Teigland]

On Wed, Apr 30, 2014 at 01:27:47PM -0400, Nir Soffer wrote:
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>, nsoffer at redhat.com
> > Cc: devel at ovirt.org, "David Teigland" <teigland at redhat.com>
> > Sent: Wednesday, April 16, 2014 10:33:39 AM
> > Subject: Re: Sanlock fencing reservations
> > 
> > On Wed, Feb 26, 2014 at 11:14:33AM -0500, Saggi Mizrahi wrote:
> > > I've recently been introduced to the this feature and I was wondering is
> > > this really
> > > the correct way to go for solving this particular problem.
> > > 
> > > My main issue is with making two unrelated flow dependent.
> > > By pushing this into the existing sanlock data structures you limit
> > > yourself
> > > in the future from changing either to optimize or even solve problems for a
> > > single use case.
> > > 
> > > Having an independent daemon to perform this task will give more room as to
> > > how to implement the feature.
> > 
> > Saggi, are you thinking about something similar to fence_sanlockd
> > http://linux.die.net/man/8/fence_sanlockd and its client fence_sanlock?
> > 
> > Using them, instead of reimplementing parts of them within Vdsm, seem
> > reasonable in first glance.
> > 
> > However
> > http://www.ovirt.org/Features/Sanlock_Fencing#Why_not_use_fence_sanlockd.3F
> > claim that it wastes 2G of storage and requires explicit master domain
> > upgrade.
> > 
> > Nir, could you explain why so much space is required by sanlockd? Can it
> > be configured to use smaller area?
> 
> According to fence_sanlock manual, each host get a resource on the shared
> storage. Each sanlock resource is 1MB (sector size * max hosts). So to serve
> 2000 hosts we need 2G.
> 
> We can use less space if we want to support smaller number of hosts, but 
> we need a new domain format that include a new volume for the fencing.

Initially, I also suggested a design similar to fence_sanlock, which I
described in the last two paragraphs of this email:

https://lists.fedorahosted.org/pipermail/sanlock-devel/2014-February/000433.html

One of the fundamental features of that design is that loss of storage
causes a host to be reset/fenced, which is precisely what we want and
require for fence_sanlock.

However, this is *not* the behavior that vdsm/rhev want, as described by
Nir in the last two paragraphs in this email:

https://lists.fedorahosted.org/pipermail/sanlock-devel/2014-March/000436.html

This is a fundamental difference in goals and makes a fence_sanlock-like
approach unsuitable for this feature.

Dave