From: Rafael Micó Miranda <rmicmirregs@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-Devel] Submitting two new resource plugins to the project
Date: Wed, 10 Jun 2009 16:57:25 +0200 [thread overview]
Message-ID: <1244645846.6770.2.camel@mecatol> (raw)
In-Reply-To: <1244473114.7104.10.camel@mecatol>
El lun, 08-06-2009 a las 16:58 +0200, Rafael Mic? Miranda escribi?:
> Hi,
>
> I have developed a couple of resources for Linux-Cluster (CMAN
> +rgmanager) which try to fix some needs I see in Linux-Cluster when
> compared with other cluster solution (concretely, Linux-HA a.k.a.
> Heartbeat). I am a Linux-HA user and I think this two functionalities
> could be useful in Linux-Cluster.
>
> I would like to give them (both resources) to the community to make them
> be into the project, and maybe after testing/quality testing or so be
> included into the RedHat Enterprise Linux packages of Linux-Cluster, so
> RedHat will give support for them and include them into the
> system-config-cluster tool to have a GUI that can configure this
> resources and handle their information.
>
> I'll give you some details of both resources:
>
> 1.- ping-group: tries to bring to Linux-Cluster the Ping Group
> functionality of Linux-HA.
>
> For those who don't know Ping Group, the idea is the following: its a
> NODE functionality (not a service or a resource) that checks IP
> communications with a list of given client nodes. When failed, Ping
> Group will move all services running in the affected node to other nodes
> that have proved that keep their communications right, so the service is
> provided to the clients even if there is a network problem that affects
> only a node of your cluster but the cluster itself wont realize about
> it.
>
> I have developed ping-group as a resource to be used into a service of
> your cluster, so in the resource arguments you can specify a list of
> clients that service should take note on. There is one thing that could
> be improved: ping-group will mark the service as failed even if the
> other nodes of the cluster would fail too due to lack of communications
> with the clients (for example, all clients are powered off). In this
> situation the service will go on migrating from one node to another
> according to your service failover policy and finally the service will
> be stopped. Maybe some ideas could be useful to improve this behaviour.
>
>
> 2.- lvm-cluster: tries to bring to Linux-Cluster an exclusive shared
> storage option, using features of LVM2. I got accustomed to this kind of
> volumes when working with Linux-Ha + EVMS solution (using Cluster
> Segment Manager plug-in).
>
> When defining a new LVM2 volume four your cluster, you can set it as
> cluster-disabled (the volume will behave as a local volume even if it is
> on shared storage) or as cluster-enabled (the LVM volume can be
> activated on many different cluster nodes at the same time).
>
> Of course, if the filesystem placed into the LVM volume is not a
> clustered filesystem (GFS2) a cluster-enabled volume allows a bad
> administrator mount a no-clustered filesystem (EXT3) in more than one
> node of the cluster which may produce filesystem corruption. This is
> because the LVM "open flag" of the filesystem is not propagated through
> all the members of the cluster, so there is no knowledge of the state of
> the filesystem and this situations can happen.
>
> This can be fixed with some of the options of LVM, specifically the
> "enable exclusively flag". This flag, when used over a cluster-enabled
> volume, will allow the VolumeGroup to be imported by all the nodes of
> the cluster but the LogicalVolumes into the VolumeGroup can only be
> activated by a single node. So, only one node of your cluster will have
> the LogicalVolume device (for example /dev/VolGrp01/LogVol01) and the
> problem explained above cannot happen. This is not about propagating the
> "open flag" through the nodes, this is about making the LogicalVolume be
> in only one node.
>
> I have developed lvm-cluster as a resource to be used into a service of
> your cluster. In the arguments you an specify the name of the
> VolumeGroup and the LogicalVolume to handle.
>
>
>
> So, I would like to receive the instructions to submit this two
> resources to the project to improve them, test them and find any bugs
> that could still be in the code. I have made some testing but of course
> they need much more to allow them be put into the main project.
>
> Sincerely yours,
I received not even a simple reply, no one will help me?
Thanks in advance,
--
Rafael Mic? Miranda
next prev parent reply other threads:[~2009-06-10 14:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 14:58 [Cluster-devel] [Linux-Cluster] Submitting two new resource plugins to the project Rafael Micó Miranda
2009-06-10 14:57 ` Rafael Micó Miranda [this message]
2009-06-10 16:57 ` [Cluster-Devel] " Fabio M. Di Nitto
2009-06-10 21:42 ` Rafael Micó Miranda
2009-06-11 6:01 ` Fabio M. Di Nitto
2009-06-11 14:02 ` Rafael Micó Miranda
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=1244645846.6770.2.camel@mecatol \
--to=rmicmirregs@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