[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Interfacing csnap to cluster stack

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]