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