Ang: Re: clustering with RHEL

Steve Dobbelstein <[email protected]>
Sänt av: [email protected]
2007-04-23 18:09

 
        Till:   [email protected]
        Kopia:  [email protected], [email protected]
        Ärende: Re: [Evms-devel] 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.-------------------------------------------------------------------------


Hi, Steve!
 It seems to me, that it would be possible to use GFS to handle the access 
to shared disk. I don´t see the need for EVMS to communicate with GFS? The 
only thing EVMS have to be responsible for, is to see that it exists 
shared disk from a shared container. GFS will handle all the mechanisms 
needed for locking and unlocking. What do you think?

 Failover of non-shared disk, though, seem to more difficult to achieve.

         Rgrds Johan

-------------------------------------------------------------------------
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