[Linux-cluster] Interfacing csnap to cluster stack
David Teigland
teigland at redhat.com
Fri Oct 8 03:56:24 UTC 2004
On Thu, Oct 07, 2004 at 03:35:47PM -0400, Daniel Phillips wrote:
> The executive summary of your post is "my pristine, perfect service
> manager is for symmetric systems only and keep yer steenking
> client-server mitts away from it."
Cute characterization, but false. To quote the relevant point:
"- I think it's possible that a client-server-based csnap system could be
managed by SM (directly) if made to look and operate more symmetrically.
This would eliminate RM from the picture."
I reiterated this in the next point and have said it before. In fact, I
think this sort of design, if done properly, could be quite nice. I'm not
lobbying for one particular way of solving this problem, though.
> > the server is by definition a single point of failure (something
> > absent from symmetric systems.)
>
> No. The csnap server is not a single point of failure any more than a
> DLM lock master is. So either it is not a single point of failure, or
> single points of failure are not absent from your gdlm, choose your
> poison.
Yes, the csnap server /is/ a SPOF if there is no way to start a
replacement server. Replacing a server and solving the SPOF problem was,
incidentally, the actual point I was trying to make.
A DLM lock master is also a SPOF if there is no way to replace the master.
By definition, the DLM solves this problem internally. This seems
irrelevant, though.
> > A prime example is NFS. RM is able to monitor an NFS server and start
> > it on another machine if it fails. NFS is probably the model you
> > should follow if your system is asymmetric and you want to use RM.
>
> NFS is an awful model. It keeps almost all its state on the clients,
> and it tries to inhale the entire recovery model into itself, with no
> help from infrastructure.
The point was about how you could use RM. The issue is how RM is designed
to help you and how it's not; it has nothing to do with NFS itself.
--
Dave Teigland <teigland at redhat.com>
More information about the Linux-cluster
mailing list