[ClusterLabs] dovecot RA

[Dimitri Maziuk]

Hi all,

next question: I'm on centos 7 and there's no more /etc/init.d/. With lennartware spreading, is there a coherent plan to deal
with former LSB agents?

Specifically, should I roll my own RA for dovecot or is there one in the
works somewhere?

TIA,
-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Informing RAs about recovery: failed resource recovery, or any start-stop cycle?

[Andrew Beekhof]

On Wed, Jun 8, 2016 at 10:29 AM, Andrew Beekhof  wrote:
> On Wed, Jun 8, 2016 at 12:11 AM, Adam Spiers  wrote:
>> Ken Gaillot  wrote:
>>> On 06/06/2016 05:45 PM, Adam Spiers wrote:
>>> > Adam Spiers  wrote:
>>> >> Andrew Beekhof  wrote:
>>> >>> On Tue, Jun 7, 2016 at 8:29 AM, Adam Spiers  wrote:
>>>  Ken Gaillot  wrote:
>>> > My main question is how useful would it actually be in the proposed 
>>> > use
>>> > cases. Considering the possibility that the expected start might never
>>> > happen (or fail), can an RA really do anything different if
>>> > start_expected=true?
>>> 
>>>  That's the wrong question :-)
>>> 
>>> > If the use case is there, I have no problem with
>>> > adding it, but I want to make sure it's worthwhile.
>>> 
>>>  The use case which started this whole thread is for
>>>  start_expected=false, not start_expected=true.
>>> >>>
>>> >>> Isn't this just two sides of the same coin?
>>> >>> If you're not doing the same thing for both cases, then you're just
>>> >>> reversing the order of the clauses.
>>> >>
>>> >> No, because the stated concern about unreliable expectations
>>> >> ("Considering the possibility that the expected start might never
>>> >> happen (or fail)") was regarding start_expected=true, and that's the
>>> >> side of the coin we don't care about, so it doesn't matter if it's
>>> >> unreliable.
>>> >
>>> > BTW, if the expected start happens but fails, then Pacemaker will just
>>> > keep repeating until migration-threshold is hit, at which point it
>>> > will call the RA 'stop' action finally with start_expected=false.
>>> > So that's of no concern.
>>>
>>> To clarify, that's configurable, via start-failure-is-fatal and on-fail
>>
>> Sure.
>>
>>> > Maybe your point was that if the expected start never happens (so
>>> > never even gets a chance to fail), we still want to do a nova
>>> > service-disable?
>>>
>>> That is a good question, which might mean it should be done on every
>>> stop -- or could that cause problems (besides delays)?
>>
>> No, the whole point of adding this feature is to avoid a
>> service-disable on every stop, and instead only do it on the final
>> stop.  If there are corner cases where we never reach the final stop,
>> that's not a disaster because nova will eventually figure it out and
>> do the right thing when the server-agent connection times out.
>>
>>> Another aspect of this is that the proposed feature could only look at a
>>> single transition. What if stop is called with start_expected=false, but
>>> then Pacemaker is able to start the service on the same node in the next
>>> transition immediately afterward? Would having called service-disable
>>> cause problems for that start?
>>
>> We would also need to ensure that service-enable is called on start
>> when necessary.  Perhaps we could track the enable/disable state in a
>> local temporary file, and if the file indicates that we've previously
>> done service-disable, we know to run service-enable on start.  This
>> would avoid calling service-enable on every single start.
>
> feels like an over-optimization
> in fact, the whole thing feels like that if i'm honest.

Today the stars aligned :-)

   http://xkcd.com/1691/

>
> why are we trying to optimise the projected performance impact when
> the system is in terrible shape already?
>
>>
>>> > Yes that would be nice, but this proposal was never intended to
>>> > address that.  I guess we'd need an entirely different mechanism in
>>> > Pacemaker for that.  But let's not allow perfection to become the
>>> > enemy of the good ;-)
>>>
>>> The ultimate concern is that this will encourage people to write RAs
>>> that leave services in a dangerous state after stop is called.
>>
>> I don't see why it would.
>
> Previous experience suggests it definitely will.
>
> People will do exactly what you're thinking but with something important.
> They'll see it behaves as they expect in best-case testing and never
> think about the corner cases.
> Then they'll start thinking about optimising their start operations,
> write some "optimistic" state recording code and break those too.
>
> Imagine a bug in your state recording code (maybe you forget to handle
> a missing state file after reboot) that means the 'enable' does't get
> run.  The service is up, but nova will never use it.
>
>> The new feature will be obscure enough that
>> noone would be able to use it without reading the corresponding
>> documentation first anyway.
>
> I like your optimism.
>
>>
>>> I think with naming and documenting it properly, I'm fine to provide the
>>> option, but I'm on the fence. Beekhof needs a little more convincing :-)
>>
>> Can you provide an example of a potential real-world situation where
>> an RA author would end up accidentally abusing the feature?
>
> You want a real-world 

Re: [ClusterLabs] Informing RAs about recovery: failed resource recovery, or any start-stop cycle?

[Andrew Beekhof]

On Wed, Jun 8, 2016 at 12:11 AM, Adam Spiers  wrote:
> Ken Gaillot  wrote:
>> On 06/06/2016 05:45 PM, Adam Spiers wrote:
>> > Adam Spiers  wrote:
>> >> Andrew Beekhof  wrote:
>> >>> On Tue, Jun 7, 2016 at 8:29 AM, Adam Spiers  wrote:
>>  Ken Gaillot  wrote:
>> > My main question is how useful would it actually be in the proposed use
>> > cases. Considering the possibility that the expected start might never
>> > happen (or fail), can an RA really do anything different if
>> > start_expected=true?
>> 
>>  That's the wrong question :-)
>> 
>> > If the use case is there, I have no problem with
>> > adding it, but I want to make sure it's worthwhile.
>> 
>>  The use case which started this whole thread is for
>>  start_expected=false, not start_expected=true.
>> >>>
>> >>> Isn't this just two sides of the same coin?
>> >>> If you're not doing the same thing for both cases, then you're just
>> >>> reversing the order of the clauses.
>> >>
>> >> No, because the stated concern about unreliable expectations
>> >> ("Considering the possibility that the expected start might never
>> >> happen (or fail)") was regarding start_expected=true, and that's the
>> >> side of the coin we don't care about, so it doesn't matter if it's
>> >> unreliable.
>> >
>> > BTW, if the expected start happens but fails, then Pacemaker will just
>> > keep repeating until migration-threshold is hit, at which point it
>> > will call the RA 'stop' action finally with start_expected=false.
>> > So that's of no concern.
>>
>> To clarify, that's configurable, via start-failure-is-fatal and on-fail
>
> Sure.
>
>> > Maybe your point was that if the expected start never happens (so
>> > never even gets a chance to fail), we still want to do a nova
>> > service-disable?
>>
>> That is a good question, which might mean it should be done on every
>> stop -- or could that cause problems (besides delays)?
>
> No, the whole point of adding this feature is to avoid a
> service-disable on every stop, and instead only do it on the final
> stop.  If there are corner cases where we never reach the final stop,
> that's not a disaster because nova will eventually figure it out and
> do the right thing when the server-agent connection times out.
>
>> Another aspect of this is that the proposed feature could only look at a
>> single transition. What if stop is called with start_expected=false, but
>> then Pacemaker is able to start the service on the same node in the next
>> transition immediately afterward? Would having called service-disable
>> cause problems for that start?
>
> We would also need to ensure that service-enable is called on start
> when necessary.  Perhaps we could track the enable/disable state in a
> local temporary file, and if the file indicates that we've previously
> done service-disable, we know to run service-enable on start.  This
> would avoid calling service-enable on every single start.

feels like an over-optimization
in fact, the whole thing feels like that if i'm honest.

why are we trying to optimise the projected performance impact when
the system is in terrible shape already?

>
>> > Yes that would be nice, but this proposal was never intended to
>> > address that.  I guess we'd need an entirely different mechanism in
>> > Pacemaker for that.  But let's not allow perfection to become the
>> > enemy of the good ;-)
>>
>> The ultimate concern is that this will encourage people to write RAs
>> that leave services in a dangerous state after stop is called.
>
> I don't see why it would.

Previous experience suggests it definitely will.

People will do exactly what you're thinking but with something important.
They'll see it behaves as they expect in best-case testing and never
think about the corner cases.
Then they'll start thinking about optimising their start operations,
write some "optimistic" state recording code and break those too.

Imagine a bug in your state recording code (maybe you forget to handle
a missing state file after reboot) that means the 'enable' does't get
run.  The service is up, but nova will never use it.

> The new feature will be obscure enough that
> noone would be able to use it without reading the corresponding
> documentation first anyway.

I like your optimism.

>
>> I think with naming and documenting it properly, I'm fine to provide the
>> option, but I'm on the fence. Beekhof needs a little more convincing :-)
>
> Can you provide an example of a potential real-world situation where
> an RA author would end up accidentally abusing the feature?

You want a real-world example of how someone could accidentally
mis-using a feature that doesn't exist yet?

Um... if we knew all the weird and wonderful ways people break our
code we'd be able to build a better mouse trap.

>
> Thanks a lot for your continued attention on this!
>
> Adam
>
> 

Re: [ClusterLabs] how to "switch on" cLVM ?

[Ferenc Wágner]

"Lentes, Bernd"  writes:

> - On Jun 7, 2016, at 3:53 PM, Ferenc Wágner wf...@niif.hu wrote:
>
>> "Lentes, Bernd"  writes:
>> 
>>> Ok. Does DLM takes care that a LV just can be used on one host ?
>> 
>> No.  Even plain LVM uses locks to serialize access to its metadata
>> (avoid concurrent writes corrupting it).  These locks are provided by
>> the host kernel (locking_type=1).  DLM extends the locking concept to a
>> full cluster from a single host, which is exactly what cLVM needs.  This
>> is activated by locking_type=3.
>
> So DLM and cLVM just takes care that the metadata is consistent.
> None of them controls any access to the LV itself ?

cLVM contols activation as well (besides metadata consistency), but does
not control access to activated LVs, which are cluster-unaware
device-mapper devices, just like under plain LVM.

>>> cLVM just takes care that the naming is the same on all nodes, right?
>> 
>> More than that.  As above, it keeps the LVM metadata consistent amongst
>> the members of the cluster.  It can also activate LVs on all members
>> ("global" activation), or ensure that an LV is active on a single member
>> only ("exclusive" activation).
>> 
> Later on it's possible that some vm's run on host 1 and some on host 2. 
> Does
> clvm needs to be a ressource managed by the cluster manager?
>> 
>> The clvm daemon can be handled as a cloned cluster resource, but it
>> isn't necessary.  It requires corosync (or some other membership/
>> communication layer) and DLM to work.  DLM can be configured to do its
>> own fencing or to use that of Pacemaker (if present).
>> 
> If i use a fs inside the lv, a "normal" fs like ext3 is sufficient, i 
> think. But
> it has to be a cluster ressource, right ?
>> 
>> If your filesystem is a plain cluster resource, then your resource
>> manager will ensure that it isn't mounted on more than one node, and
>> everything should be all right.
>> 
>> Same with VMs on LVs: assuming no LV is used by two VMs (which would
>> bring back the previous problem on another level) and your VMs are
>> non-clone cluster resources, your resource manager will ensure that each
>> LV is used by a single VM only (on whichever host), and everything
>> should be all right, even though your LVs are active on all hosts (which
>> makes live migration possible, if your resource agent supports that).
>
> Does the LV need to be a ressource (if i don't have a FS) ?

No.  (If you use cLVM.  If you don't use cLVM, then your VGs must be
resources, otherwise nothing guarrantees the consistency of their
metadata.)

> From what i understand from what you say the LV's are active on all
> hosts, and the ressource manager controls that a VM is just running on
> one host, so the LV is just used by one host. Right ? So it has not to
> be a ressource.

Right.  (The LVs must be active on all hosts to enable free live
migration.  There might be other solutions, because the LVs receive I/O
on one host only at any given time, but then you have to persuade your
hypervisor that the block device it wants will really be available once
migration is complete.)
-- 
Feri

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] how to "switch on" cLVM ?

[Lentes, Bernd]

- On Jun 7, 2016, at 5:54 PM, Digimer li...@alteeve.ca wrote:


> DLM is just a distributed lock manager, that's it. LVM uses it to
> coordinate actions within the cluster, so what LVM does is still up to LVM.
> 
> I'm not a dev, so I might get this a little wrong, but basically it
> works like this...
> 
> You want to create an LV from a clustered VG. The dlm and clvmd daemons
> are running on all nodes. You type 'lvcreate ...' on node 1. Node 1 asks
> for a lock from DLM, DLM checks to make sure the lock your asking for
> doesn't conflict with any locks held elsewhere in the cluster and then
> it is granted.

What is locked ? The metadata (information about PV, VG, LV) ?
Or the access to the LV ?

> 
> Now the local machine creates the LV (same that no one else is going to
> work on the same bits because of the DLM lock), releases the lock and
> informs the other nodes. The other nodes update their view of the VG and
> see the new LV.
> 
> From the user's perspective, the LV they created on node 1 is instantly
> seen on the other nodes.
> 

>> 
>> But maybe i want to have some vm's running on host A and others on host B.
>> Remember: one vm per LV.
>> So i need access to the VG concurrently from both nodes, right ?
>> But if the FS from the LV is a cluster ressource, pacemaker takes care the 
>> the
>> FS is mounted just from one node.
>> I can rely it on it, right ? That's what i read often.
>> But what if i don't have a FS ? It's possible to have vm's in plain 
>> partitions,
>> which should be a performance advantage.
> 
> Clustered LVM doesn't care how an LV is used. It only cares that changes
> won't conflict (thanks to DLM) and that all nodes have the same view of
> the LVM. So deactivate, activate, grow, create, delete of PVs, VGs and
> LVs are always seen on all nodes right away.
> 
> What you do on the LVs is up to you. If boot a VM on node 1 using an LV
> as backing storage, nothing in LVM stopping you from accessing that LV
> on another node and destroying your data.

That's logical. But the VM will be a ressource so the cluster manager
takes care that only one instance of the VM is running anytime.

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen 
(komm.)
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] how to "switch on" cLVM ?

[Digimer]

On 07/06/16 07:23 AM, Lentes, Bernd wrote:
>>> Ok. Does DLM takes care that a LV just can be used on one host ?
>>> cLVM just takes care that the naming is the same on all nodes, right ?
>>
>> AFAIK DLM takes care about the LVM Locking cluster wide.
> 
> What does that mean concretely, "LVM Locking cluster wide" ?
> I read it always, but no explaination.
> Does that mean that a LV just can be accesses from one node ?
> That DLM "locks" (in the sense of "blocking the other node") the access ?
> Or does the LV has to be a cluster ressource to prevent concurrent access ?

DLM is just a distributed lock manager, that's it. LVM uses it to
coordinate actions within the cluster, so what LVM does is still up to LVM.

I'm not a dev, so I might get this a little wrong, but basically it
works like this...

You want to create an LV from a clustered VG. The dlm and clvmd daemons
are running on all nodes. You type 'lvcreate ...' on node 1. Node 1 asks
for a lock from DLM, DLM checks to make sure the lock your asking for
doesn't conflict with any locks held elsewhere in the cluster and then
it is granted.

Now the local machine creates the LV (same that no one else is going to
work on the same bits because of the DLM lock), releases the lock and
informs the other nodes. The other nodes update their view of the VG and
see the new LV.

>From the user's perspective, the LV they created on node 1 is instantly
seen on the other nodes.

> Later on it's possible that some vm's run on host 1 and some on host 2. 
> Does
> clvm needs to be a ressource managed by the cluster manager ?

 Yes, you can live-migrate as well. I do this all the time, except I use
 DRBD instead of a SAN and RHEL instead of SUSE, but those are trivial
 differences in this case.

> If i use a fs inside the lv, a "normal" fs like ext3 is sufficient, i 
> think. But
> it has to be a cluster ressource, right ?

 You can format a clustered LV with a cluster unaware filesystem just
 fine. However, the FS is not made magically cluster aware... If you
 mount it on two nodes, you will almost certainly corrupt the FS quickly.
 If you want to mount an LV on two+ nodes at once, you need a
 cluster-aware file system, life GFS2.
>>>
>>> No. Pacemaker takes care that the FS is just mounted on one node.
>>> So it should not be a problem ?
>>
>> If you want to be sure to mount an LV on just one Node, you have to activate 
>> the
>> VG exclusively on one node. You have to configure the ressource for the VG
>> accordingly. Otherwise it's possible to activate and mount an LV on several
>> nodes at the same time, even with a non Cluster FS, e.g. ext4, which would 
>> end
>> up in corrupted FS, most likely. (as mentioned above allready).
> 
> But maybe i want to have some vm's running on host A and others on host B.
> Remember: one vm per LV.
> So i need access to the VG concurrently from both nodes, right ?
> But if the FS from the LV is a cluster ressource, pacemaker takes care the 
> the FS is mounted just from one node.
> I can rely it on it, right ? That's what i read often.
> But what if i don't have a FS ? It's possible to have vm's in plain 
> partitions, which should be a performance advantage.

Clustered LVM doesn't care how an LV is used. It only cares that changes
won't conflict (thanks to DLM) and that all nodes have the same view of
the LVM. So deactivate, activate, grow, create, delete of PVs, VGs and
LVs are always seen on all nodes right away.

What you do on the LVs is up to you. If boot a VM on node 1 using an LV
as backing storage, nothing in LVM stopping you from accessing that LV
on another node and destroying your data.

For that, you need pacemaker or something else smart enough and cluster
aware to prevent uncoordinated access. So if you create a standard FS,
you configure pacemaker to ensure it's only mounted on one node at a
time (and use fencing!). If you do use a cluster-aware FS, like GFS2,
then it's perfectly fine to mount the LV on multiple drives (which is
why LVM doesn't get in your way).


-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Informing RAs about recovery: failed resource recovery, or any start-stop cycle?

[Adam Spiers]

Ken Gaillot  wrote:
> On 06/06/2016 05:45 PM, Adam Spiers wrote:
> > Adam Spiers  wrote:
> >> Andrew Beekhof  wrote:
> >>> On Tue, Jun 7, 2016 at 8:29 AM, Adam Spiers  wrote:
>  Ken Gaillot  wrote:
> > My main question is how useful would it actually be in the proposed use
> > cases. Considering the possibility that the expected start might never
> > happen (or fail), can an RA really do anything different if
> > start_expected=true?
> 
>  That's the wrong question :-)
> 
> > If the use case is there, I have no problem with
> > adding it, but I want to make sure it's worthwhile.
> 
>  The use case which started this whole thread is for
>  start_expected=false, not start_expected=true.
> >>>
> >>> Isn't this just two sides of the same coin?
> >>> If you're not doing the same thing for both cases, then you're just
> >>> reversing the order of the clauses.
> >>
> >> No, because the stated concern about unreliable expectations
> >> ("Considering the possibility that the expected start might never
> >> happen (or fail)") was regarding start_expected=true, and that's the
> >> side of the coin we don't care about, so it doesn't matter if it's
> >> unreliable.
> > 
> > BTW, if the expected start happens but fails, then Pacemaker will just
> > keep repeating until migration-threshold is hit, at which point it
> > will call the RA 'stop' action finally with start_expected=false.
> > So that's of no concern.
> 
> To clarify, that's configurable, via start-failure-is-fatal and on-fail

Sure.

> > Maybe your point was that if the expected start never happens (so
> > never even gets a chance to fail), we still want to do a nova
> > service-disable?
> 
> That is a good question, which might mean it should be done on every
> stop -- or could that cause problems (besides delays)?

No, the whole point of adding this feature is to avoid a
service-disable on every stop, and instead only do it on the final
stop.  If there are corner cases where we never reach the final stop,
that's not a disaster because nova will eventually figure it out and
do the right thing when the server-agent connection times out.

> Another aspect of this is that the proposed feature could only look at a
> single transition. What if stop is called with start_expected=false, but
> then Pacemaker is able to start the service on the same node in the next
> transition immediately afterward? Would having called service-disable
> cause problems for that start?

We would also need to ensure that service-enable is called on start
when necessary.  Perhaps we could track the enable/disable state in a
local temporary file, and if the file indicates that we've previously
done service-disable, we know to run service-enable on start.  This
would avoid calling service-enable on every single start.

> > Yes that would be nice, but this proposal was never intended to
> > address that.  I guess we'd need an entirely different mechanism in
> > Pacemaker for that.  But let's not allow perfection to become the
> > enemy of the good ;-)
> 
> The ultimate concern is that this will encourage people to write RAs
> that leave services in a dangerous state after stop is called.

I don't see why it would.  The new feature will be obscure enough that
noone would be able to use it without reading the corresponding
documentation first anyway.

> I think with naming and documenting it properly, I'm fine to provide the
> option, but I'm on the fence. Beekhof needs a little more convincing :-)

Can you provide an example of a potential real-world situation where
an RA author would end up accidentally abusing the feature?

Thanks a lot for your continued attention on this!

Adam

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] how to "switch on" cLVM ?

[Ferenc Wágner]

"Lentes, Bernd"  writes:

> Ok. Does DLM takes care that a LV just can be used on one host ?

No.  Even plain LVM uses locks to serialize access to its metadata
(avoid concurrent writes corrupting it).  These locks are provided by
the host kernel (locking_type=1).  DLM extends the locking concept to a
full cluster from a single host, which is exactly what cLVM needs.  This
is activated by locking_type=3.

> cLVM just takes care that the naming is the same on all nodes, right?

More than that.  As above, it keeps the LVM metadata consistent amongst
the members of the cluster.  It can also activate LVs on all members
("global" activation), or ensure that an LV is active on a single member
only ("exclusive" activation).

>>> Later on it's possible that some vm's run on host 1 and some on host 2. Does
>>> clvm needs to be a ressource managed by the cluster manager?

The clvm daemon can be handled as a cloned cluster resource, but it
isn't necessary.  It requires corosync (or some other membership/
communication layer) and DLM to work.  DLM can be configured to do its
own fencing or to use that of Pacemaker (if present).

>>> If i use a fs inside the lv, a "normal" fs like ext3 is sufficient, i 
>>> think. But
>>> it has to be a cluster ressource, right ?

If your filesystem is a plain cluster resource, then your resource
manager will ensure that it isn't mounted on more than one node, and
everything should be all right.

Same with VMs on LVs: assuming no LV is used by two VMs (which would
bring back the previous problem on another level) and your VMs are
non-clone cluster resources, your resource manager will ensure that each
LV is used by a single VM only (on whichever host), and everything
should be all right, even though your LVs are active on all hosts (which
makes live migration possible, if your resource agent supports that).
-- 
Feri

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] how to "switch on" cLVM ?

[Lentes, Bernd]

- On Jun 7, 2016, at 12:28 PM, Sven Moeller smoel...@nichthelfer.de wrote:

> Hi,
> 
> 
> Am Dienstag, 07. Juni 2016 11:42 CEST, "Lentes, Bernd"
>  schrieb:
> 
>> 
>> 
>> - On Jun 6, 2016, at 8:17 PM, Digimer li...@alteeve.ca wrote:
>> 

>> 
>> Ok. Does DLM takes care that a LV just can be used on one host ?
>> cLVM just takes care that the naming is the same on all nodes, right ?
> 
> AFAIK DLM takes care about the LVM Locking cluster wide.

What does that mean concretely, "LVM Locking cluster wide" ?
I read it always, but no explaination.
Does that mean that a LV just can be accesses from one node ?
That DLM "locks" (in the sense of "blocking the other node") the access ?
Or does the LV has to be a cluster ressource to prevent concurrent access ?


>> 
>> >> Later on it's possible that some vm's run on host 1 and some on host 2. 
>> >> Does
>> >> clvm needs to be a ressource managed by the cluster manager ?
>> > 
>> > Yes, you can live-migrate as well. I do this all the time, except I use
>> > DRBD instead of a SAN and RHEL instead of SUSE, but those are trivial
>> > differences in this case.
>> > 
>> >> If i use a fs inside the lv, a "normal" fs like ext3 is sufficient, i 
>> >> think. But
>> >> it has to be a cluster ressource, right ?
>> > 
>> > You can format a clustered LV with a cluster unaware filesystem just
>> > fine. However, the FS is not made magically cluster aware... If you
>> > mount it on two nodes, you will almost certainly corrupt the FS quickly.
>> > If you want to mount an LV on two+ nodes at once, you need a
>> > cluster-aware file system, life GFS2.
>> 
>> No. Pacemaker takes care that the FS is just mounted on one node.
>> So it should not be a problem ?
> 
> If you want to be sure to mount an LV on just one Node, you have to activate 
> the
> VG exclusively on one node. You have to configure the ressource for the VG
> accordingly. Otherwise it's possible to activate and mount an LV on several
> nodes at the same time, even with a non Cluster FS, e.g. ext4, which would end
> up in corrupted FS, most likely. (as mentioned above allready).

But maybe i want to have some vm's running on host A and others on host B.
Remember: one vm per LV.
So i need access to the VG concurrently from both nodes, right ?
But if the FS from the LV is a cluster ressource, pacemaker takes care the the 
FS is mounted just from one node.
I can rely it on it, right ? That's what i read often.
But what if i don't have a FS ? It's possible to have vm's in plain partitions, 
which should be a performance advantage.


Bernd

 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen 
(komm.)
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

[ClusterLabs] gfs2-utils 3.1.9 released

[Andrew Price]

Hi all,

I am happy to announce the 3.1.9 release of gfs2-utils. This release 
includes the following notable changes:


  * fsck.gfs2 now uses less memory
  * Improvements and fixes to fsck.gfs2's xattr and resource group checking
  * mkfs.gfs2 reports progress so that you can tell it's still alive 
during a long mkfs

  * mkfs.gfs2's -t option now accepts a longer cluster name and fs name
  * A udev helper script is now installed to suspend the device on 
withdraw, preventing hangs

  * Support for the de_rahead and de_cookie dirent fields has been added
  * gfs2_edit savemeta performance improvements
  * The glocktop utility has been added to help analyze locking-related 
performance problems

  * The mkfs.gfs2(8) man page has been overhauled
  * The rgrplbv and loccookie mount options have been added to the 
gfs2(5) man page

  * Fixes for out-of-tree builds and testing
  * Various other fixes, cleanups and enhancements

See below for a complete list of changes.

The source tarball is available from:

   https://fedorahosted.org/released/gfs2-utils/gfs2-utils-3.1.9.tar.gz

Please report bugs against the gfs2-utils component of Fedora rawhide:


https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=gfs2-utils=rawhide

Regards,
Andy

Changes since version 3.1.8:

Abhi Das (2):
  fsck.gfs2: replace recent i_goal fixes with simple logic
  gfs2-utils: Fix hang on withdraw

Andreas Gruenbacher (4):
  libgfs2: Add support for dirent.de_rahead
  gfs2_edit: Include dirent.de_rahead in directory listings
  gfs2: Fix printf format errors on x86
  gfs2_edit: Add attribute printf for print_gfs2

Andrew Price (49):
  scripts: rename gfs2_wd_udev.sh to gfs2_withdraw_helper
  scripts: install the withdraw helper script
  scripts: install the withdraw udev rules script
  gfs2-utils: Add a check for the de_rahead field
  gfs2_edit savemeta: speed up is_block_in_per_node()
  fsck.gfs2: Really be quiet in quiet mode
  fsck.gfs2: Improve read ahead in pass1_process_bitmap
  libgfs2: Return the rgrp count in lgfs2_rgrps_plan()
  mkfs.gfs2: Always validate the locktable option
  gfs2-utils: Add the glocktop utility
  gfs2_edit: Don't use the global block variable in block_is_a_journal
  gfs2_edit: Don't use the global block variable in 
block_is_in_per_node

  gfs2_edit: Don't use the global block variable in block_is_jindex
  gfs2_edit: Don't use the global block variable in block_is_inum_file
  gfs2_edit: Don't use global block variable in block_is_statfs_file
  gfs2_edit: Don't use global block variable in block_is_quota_file
  gfs2_edit: Don't use global block variable in block_is_rindex
  gfs2_edit: Don't use the global block variable in block_is_per_node
  gfs2_edit: Don't use the global block variable in block_is_systemfile
  gfs2_edit: Don't use the global block variable in block_is_rgtree
  gfs2_edit: Don't use the global block variable in block_is_journals
  gfs2_edit: Only declare the block variable where needed
  gfs2_edit: Don't use the global block variable in save_block
  gfs2_edit: Don't use the global block variable in 
save_indirect_blocks

  gfs2_edit: Don't use the global block variable in save_inode_data
  gfs2_edit: Don't use the global block variable in get_gfs_struct_info
  gfs2_edit: Don't use the global block variable in save_ea_block
  gfs2_edit: Don't use the global block variable in save_allocated
  gfs2_edit: Don't use the global block variable in savemeta
  gfs2_edit: Don't use the global bh variable in display_block_type
  gfs2_edit: Don't use the global block variable in savemeta.c
  gfs2_edit: Don't export bh
  gfs2_edit: Remove block_in_mem and fix a memory leak
  libgfs2: Support the new dirent de_cookie field
  mkfs.gfs2(8) man page improvements
  glocktop: Fix a tight loop under nohup
  libgfs2: New function lgfs2_rindex_read_one()
  gfs2-utils tests: Add helper program to damage rgrps
  gfs2-utils tests: Add fsck.gfs2 rgrp/rindex repair tests
  mkfs.gfs2: Remove unnecessary externs from progress functions
  gfs2_edit: Don't hijack bh->b_data in read_master_dir
  mkfs.gfs2: Open the target device with O_EXCL
  fsck.gfs2: Fix a potential memory leak in pass3
  gfs2_edit savemeta: Fix use of uninitialized 'blk'
  gfs2-utils/po: Update translation template
  gfs2-utils: Don't build the testsuite script in srcdir
  gfs2-utils tests: Provide 'installcheck' with the path to gfs2l
  gfs2-utils tests: Remove the testsuite script in distclean
  gfs2-utils/po: Update translation template

Benjamin Marzinski (1):
  gfs2(5): add rgrplbv and loccookie info the the manpage

Bob Peterson (78):
  fsck.gfs2: Change duptree structure to have generic flags
  fsck.gfs2: Detect, fix and clone duplicate block refs within a dinode
  libgfs2: Check block range when inserting