--===============1232626780==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-ZBwlFYP70P4kjhIKvEDU"


--=-ZBwlFYP70P4kjhIKvEDU
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

thanks for the answer! I added little comments in-line too.

[sorry for this top post]
After I wrote the mail last day, I started implementing my ideas. I used
lvm.sh as a base, but after some changed I discovered more and more
corner cases and issues so in the end it changed quite a lot.

I'll write a new mail attaching this new script. I did some tests with
various scenarios. For example: All Machines that lost the same PVs;
only one machine that lost PVs; removing an LVs, removing the whole VG
etc... But to be sure that there aren't problem I have to do more and
more tests and also try to document them.

Thanks!
Bye!

On Wed, 2007-10-03 at 09:57 -0500, Jonathan Brassow wrote:
> Great stuff!  Much of what you are describing I've thought about in =20
> the past, but just haven't had the cycles to work on.  You can see in =20
> the script itself, the comments at the top mention the desire to =20
> operate on the VG level.  You can also see a couple vg_* functions =20
> that simply return error right now, but were intended to be filled in.
>=20
> Comments in-line.
>=20
> On Sep 28, 2007, at 11:14 AM, Simone Gotti wrote:
>=20
> > Hi,
> >
> > Trying to use a non cluster vg in redhat cluster I noticed that =20
> > lvm.sh,
> > to avoid metadata corruption, is forcing the need of only one lv =20
> > per vg.
> >
> > I was thinking that other clusters don't have this limitation as they
> > let you just use a vg only on one node at a time (and also on one
> > service group at a time).
> >
> > To test if this was possible with lvm2 I made little changes to lvm.sh
> > (just variables renames, use of vgchange instead of lvchange for tag
> > adding) and using the same changes needed to /etc/lvm/lvm.conf
> > (volume_list =3D [ "rootvgname", "@my_hostname" ]) looks like this idea
> > was working.
> >
> > I can activate the vg and all of its volume only on the node with =20
> > the vg
> > tagged with its hostname and the start on the other nodes is refused.
> >
> > Now, will this idea be accepted? If so these are a list of possible
> > needed changes and other ideas:
> >
> > *) Make <parameter name=3D"vg_name" required=3D"1"> also unique=3D"1" o=
r
> > better primary=3D"1" and remove the parameter "name" as only one servic=
e
> > can use a vg.
>=20
> Sounds reasonable.  Be careful when using those parameters though, =20
> they often result in cryptic error messages that are tough to =20
> follow.  I do checks in lvm.sh where possible to be able to give the =20
> user more information on what went wrong.
My idea was that a VG can be owned by a single service. The check you
added in lvm.sh forced to a single LV in the VG, but one was able anyway
to use multiple lvm.sh with the same vg_name in different services
leading to problems anyway. Probably I missed something... :D

>=20
> >
> > *) What vg_status should do?
> > a) Monitor all the LVs
> > 	or
> > b) Check only the VG and use ANOTHER resource agent for every lv =20
> > used by
> > the cluster? So I can create/remove/modify lvs on that vg that aren't
> > under rgmanager control without any error reported by the status
> > functions of the lvm.sh agent.
> > Also other clusters distinguish between vg and lv and they have 2
> > different agents for them.
>=20
> This is were things get difficult.  It would be ok to modify lvs on =20
> that vg as long as it's on the same machine that has ownership.  Tags =20
> should prevent otherwise, so should be ok.
>=20
> User would have to be careful (or barriers would have to prevent) =20
> users from assigning different LVs in the same VG to different =20
> services.  Otherwise, if a service fails (application level) and must =20
> be moved to a different machine, we would have to find a way to move =20
> all services associated with the VG to the next machine.  I think =20
> there are ways to mandate this (that service A stick with service B), =20
> but we would have to have a way to enforce it.
>=20
> > Creating two new agents will also leave the actual lvm.sh without
> > changes and keep backward compatibility for who is already using it.
> >
> > Something like this (lets call lvm_vg and lvm_lv respectively the =20
> > agents
> > for the vg and the lv):
> >
> > <service name=3D"foo">
> >   <lvm_vg vgname=3D"vg01">
> >      <lvm_lv lvname=3D"lv01/>
> >      <lvm_lv lvname=3D"lv01/>
> >      <script .... />
> >   </lvm_vg>
> > </service>
>=20
> I'd have to be convinced of this...  I'd hate to see two 'lvm_lv's =20
> that refer to the same VG in different services... or would lvm_lv =20
> somehow require a parent lvm_vg, and make lvm_vg have a 'unique=3D1'?  =20
> In any case, we are forced to move an entire VG at a time, so I'm not =20
> sure it would make sense to break it up.
I thinked about the same problem so for now I tried implementing it in a
unique script.

>=20
> > *) Another problem that is present just now is that lvm should be
> > changed to avoid any operation on a non activable vg or lv. In these
> > days you cannot be able to start a vg/lv as its not tagged with the
> > hostname but you can remove/resize it without any problem. :D
>=20
> Yes, tags need to be tightened-up.  You should never be able to alter =20
> metadata of LVM from a machine that does not have permission.
That's what I was hoping. Good to know is in program to be implemented.

>=20
> Another improvement I'd like to see is automatic VG ownership.  =20
> Basically, tighten-up the tagging as stated above and add a unique =20
> machine specific tag to new VGs by default.  (For clusters, this tag =20
> could be the cluster name.)  This does a number of things, but =20
> primarily:
> 1) restricts access to the machine (or cluster) that created the VG.
> - now if you move a hard drive to a different machine, it won't =20
> conflict with the other hard drives there (which might cause =20
> confusion over which device is the actual root volume).
> 2) simplifies HA LVM (lvm.sh + rgmanager)
> - there would no longer be a need to edit lvm.conf to add the machine =20
> name, etc...
> One of the questions surrounding this is how do you generate the =20
> unique id and when?  You would probably need it upon installation...
This looks a great idea! (also if I cannot understand well how this
should be implemented :D )
>=20
> There are many kinds of fault scenarios.  Thinking through each one =20
> of them will be important when trying to implement a by-VG model vs a =20
> by-LV model.  I usually stumble across an issue that gives me pause =20
> before hastily adding a new feature, but I would welcome further =20
> thought/code.
>=20
>   brassow
>=20
--=20
Simone Gotti

--=-ZBwlFYP70P4kjhIKvEDU
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHBBVJl0ZU7uYHW3kRAuK7AJoDGpckgMpLfrUUe+0tJHhAX1gAYACcCb2u
LdbKJQsuZ5w09aV2tIcJmXw=
=CqiB
-----END PGP SIGNATURE-----

--=-ZBwlFYP70P4kjhIKvEDU--


--===============1232626780==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster
--===============1232626780==--