From: Jacek Konieczny <jajcus@jajcus.net>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Why do lvcreate with clvmd insist on VG being available on all nodes?
Date: Thu, 15 Nov 2012 11:08:53 +0100 [thread overview]
Message-ID: <20121115100852.GA19632@jajo.eggsoft> (raw)
In-Reply-To: <50A4B14F.5050700@gmail.com>
On Thu, Nov 15, 2012 at 10:09:35AM +0100, Zdenek Kabelac wrote:
> > work properly, as I would expect (make the volume available/unavailable
> > on the node). But an attempt to create a new volume:
> >
> > lvcreate -n new_volume -L 1M shared_vg
> >
> > fails with:
> >
> > Error locking on node 1: Volume group for uuid not found: Hlk5NeaVF0qhDF20RBq61EZaIj5yyUJgGyMo5AQcLfZpJS0DZUcgj7QMd3QPWICL
> >
>
>
> Haven't really tried to understand what are you trying to achieve,
> but if you want to have node being activated only on one cluster node,
> you may easily use lvcreate -aey option.
>
> If you are using default clustered operation - it's not surprising,
> the operation is refused if other nodes are not responding.
Hmmm didn't though about the initial activation. In fact, I don't need
that volume activated as soon as it is created. You are right, I should
try 'lvcreate -aey' or 'lvcreate -an'.
My stupid mistake, indeed.
'lvcreate -an -Z n' and 'lvcreate -aey' do work in such case.
Though, LVM have some problems with tracking the exclusive activations
later…
> > Indeed, the VG is not available at the standby node at that moment. But,
> > as it is not available there, I see no point in locking it there.
>
> Well - you would need to write your own type of locking with support
> of 'standby' currently clvmd doesn't work with such state (and it's not
> quite clear to me how it actually should even work).
> So far either node is in cluster or is fenced.
I will try to make this work somehow… I don't think a node in standby
(or when one of the VGs is not available there) should be quite
different that one fenced.
> > When clvmd is stopped on the inactive node and 'clvmd -S' has been run
> > on the active node, then both 'lvchange' and 'lvcreate' work as
> > expected, but that doesn't look like a graceful switch-over. And another
> > 'clvmd -S' stopped clvmd all together (this seems like a bug to me)
> >
> > And one more thing bothers me… my system would be very scalable to many
> > nodes, where only two share active storage (when using DRBD). But this
> > won't work if LVM would refuse some operations when any VG is not
> > available on all nodes.
>
> Obviously using clustered VG in non-clustered environment isn't smart plan.
> What you could do - is to disable clustering support on VG
Clusters do not have to be symmetrical. Cluster when different nodes
have a bit different set of resources available are still clusters.
I do need clustering locking – in case a volume group is available on
a few nodes it must not be possible to more than one node use any of the
logical volumes there.
> Note - you may always go around any locking problem with the above config
> option - just do not report then problems with broken disk content and badly
> activated volumes on cluster nodes.
I am aware of the risks. That is why I do use clvmd. I don't quite
understand some of the clvmd behaviour and I wrote here to know if there
are some other risks taken into account by clvmd that I am not aware of.
It seem I still need some work and learning to make it work properly.
Greets,
Jacek
next prev parent reply other threads:[~2012-11-15 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 15:16 [linux-lvm] Why do lvcreate with clvmd insist on VG being available on all nodes? Jacek Konieczny
2012-11-15 9:09 ` Zdenek Kabelac
2012-11-15 10:08 ` Jacek Konieczny [this message]
2012-11-15 11:01 ` Zdenek Kabelac
2012-11-15 13:30 ` Jacek Konieczny
2012-11-15 16:40 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121115100852.GA19632@jajo.eggsoft \
--to=jajcus@jajcus.net \
--cc=linux-lvm@redhat.com \
--cc=zdenek.kabelac@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).