Re: clustering with RHEL

[email protected] wrote on 04/21/2007 01:30:59 AM:

>
>                                                Hi!

>
> We´re running RHEL 4 and 5  clustering since some years now, and
> would like to use evms in clustering. Since RHEL is supporting
> multi-node clustering, I´m not sure how to use evms. Also, we would
> obviously not want to install Linux-HA to be able to use the
> clustering features.
>  Steve mentioned the: "admin_mode" is set to "yes" in the "csm"
> > section of /etc/evms.conf, which is not recommended since it can be
very
> > dangerous)
>
> In what way would that be dangerous to use? We´re experienced
> cluster admins. Would that help us in any way?
>
>  We´re  using clustering both with multinode failover, and with multinode
GFS.
>
>  So, questions here are: How can we configure shared cluster
> containers(for GFS clustering) without installing Linux-HA?
> And: How can we get a multinode failover?
>
>               Best regards from/Med vänliga hälsningar från
>
>                                 Johan Kragsterman
>
>                               http://www.capvert.se
>

Hello, Johan.

EVMS currently only has support for the Linux-HA and IBM's RSCT cluster
mangers.  And is has support for the OGFS and OCFS2 distributed file
systems.  EVMS does not yet have support for GFS.

EVMS's clustering support gets you two main functions.
1) Coordinated disk configuration changes between the nodes in the cluster.
2) The ability to switch EVMS's focus from the local machine to another
machine in the cluster.

Since you are experienced cluster administrators, you should be able to
coordinate disk configuration changes between the nodes by hand.

Here is a brief explanation of basic clustering concepts in EVMS.

The Cluster Segment Manger (CSM) essentially gives you software fencing for
shared storage.  It can mark a disk as "private" (accessible by only one
node in the cluster) or "shared" (accessible by all nodes in the cluster).
EVMS cannot automatically detect which disks are shared between the nodes
in the cluster.  You manually add the CSM to what you know to be the shared
disks.

The CSM needs to be able to communicate with the clustering software so
that it can determine the current node's name and whether it is a member of
the current cluster membership.  It needs to know the node's name so that
it can determine if a disk with the CSM assigned to it should be visible to
the current node.  (The CSM stores the private/shared status and the owning
node's name, if private, in the CSM metadata placed on the disk.)  A disk
that is private for the local node or shared can be seen by the local node;
a disk that is private to another node cannot be seen on the current node.
In addition, if the local node is not part of the current membership, then
CSM will not let the disk be seen since EVMS will not be able to coordinate
any disk configuration changes between the nodes.  EVMS uses the clustering
software to communicate between the nodes in a cluster.  If a node is not a
member of the cluster, EVMS will not be able to communicate with other
nodes in the cluster and therefore cannot communicate any changes to the
configuration of shared storage between the nodes in the cluster.  (EVMS
will always let you make changes to local disks, i.e., disks that do not
have the CSM assigned to them.)

The admin mode of the CSM tells it to remove all the checks for cluster
membership and for private disk ownership.  With "admin_mode" set to "yes"
the CSM will make visible all disks that have the CSM assigned to them.  It
is to be used only to fix-up the disk configuration by hand when something
goes terribly wrong with the configuration.  You can imagine why admin mode
is dangerous.  If the node is not a member of a cluster, changes to the
shared storage will not be communicated with the other nodes in the
cluster.  If changes are made to a disk is marked "shared" by the CSM,
those changes could cause problems if another node is currently using the
shared disk.  If a the ownership of a private disk is changed from one node
to another, the ownership change will not be communicated.  The node that
previously owned the disk will not be told to no longer make the disk
visible; the node that now owns the disk will not be told to make the disk
visible.  Also, since admin mode makes all CSM disks visible, it allows you
to make changes to private disks that are not owned by the current node.
That, too can cause problems if the disk is in use by the other node.

The issues in managing shared storage are not simple, as you know.  I hope
this little write-up helps.  Send another post to the mailing list if you
have more questions or need more details.

Steve D.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Evms-devel mailing list
[email protected]
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel