Re: Ang: Re: clustering with RHEL

[email protected] wrote on 04/23/2007 01:39:16 PM:

> 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

Hello again.

You certainly will rely on GFS to handle the coordination/locking of the
shared volume when the system is up and running.  EVMS does not handle
runtime issues; its focus is configuration.  What EVMS's clustering support
gets you is coordinated configuration changes so that all nodes in the
cluster see the configuration changes at the same time instead of having to
go to each node manually and have it discover the changes.

In your case I would recommend not using the Cluster Segment Manager since
it relies on being able to communicate with the cluster manager.  (If you
assign the CSM to a disk you will not be able to manage volumes on the disk
since the CSM will not let you see them because it can't talk to the
cluster manager.)  You would simply just be careful how you manage your
shared storage as you most likely do today.  Any physically shared disk
will appear on all nodes in the cluster.  EVMS on every node will see all
of the physically shared disks.

For disks that you truly want shared you can use EVMS to manage the disk,
but after you make any configuration changes you will want to make sure
those changes are reflected on the other nodes in the cluster.  One way to
do that is to run EVMS on the other nodes to discover the changes and then
"Save" them to activate the new device nodes.

Physically shared disks that you want to be private to a particular node
will appear on all nodes in the cluster.  EVMS on every node will discover
any volumes on the disk and create device nodes for them.  You simply don't
use the device nodes on the nodes in the cluster that don't own the disk.
You do, however, run the risk of having the device nodes available on the
nodes that don't own the disk.  Some errant software or an administrator
error could cause the disk to be accessed from a node that doesn't own the
disk.  This is no worse than your current setup.

Failover of non-shared disks without the CSM shouldn't be too difficult.
Since every node will be able to see all the non-shared disks and the
volumes on them, failover is as simple as mounting the file system on the
backup node.

The trick is what happens when the node that died comes back online.  You
don't want the node to mount the file system while it is mounted on the
backup node (unless it is a distributed file system that can handle
multiple mounts).  The clustering software should have some hooks for when
a node comes back online.  You should be able to use the hook and unmount
the file system from the backup node before the failed node comes back
online.

Hope this helps.

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