[Linux-cluster] Interfacing csnap to cluster stack

[Daniel Phillips]

On Friday 08 October 2004 18:46, Lon Hohberger wrote:
> On Fri, 2004-10-08 at 17:25 -0400, Daniel Phillips wrote:
> > Why would you want to introduce new rules about cluster topology
> > instead of fixing the code?
>
> It doesn't introduce a hard rule, it will still work, and it's very,
> very simple.
>
> The only rule it introduces is something like this: "For equivalent
> csnap server performance from all nodes, set your cluster up with
> equivalent performing nodes and connections."

But that's a pain.  Why should you have to care whether your nodes are 
all matched in performance and your topology is completely regular, 
just to work around badly written code?

> Again, it was an answer to your question about how to make the
> single- cluster-lock model work.

Sure,, I'll take that answer as "by sucking more" ;-)

> > > Your clients still work, and the csnap server is available,
> > > albeit at a potentially degraded state.
> >
> > Well...
>
> Out of curiosity, in the configuration above, how much of an actual
> performance bottleneck do you expect to incur, given that (I think)
> the csnap writes are synchronous?

Probably not all that horrible, but you're supposed to extrapolate from 
that and realize that arbitrarily horrible corner cases are possible.  
Random control systems are just a bad idea in general.

> > [1] At cluster bring-up time.  The resource manager has to be able
> > to operate without reading files during failover.
>
> Existing CRMs will not do this, at least, not the ones I've looked
> at. lrmd (new linux-ha stuff) and heartbeat (older) and rgmanager all
> fork/ exec scripts on the local file system to control resources and
> applications, implying that none will work with csnap server.
>
> D'oh! :(

This problem is not specific to the csnap server, it's a problem for 
anything that lies in the failover path and wants resource management.
You could say that this problem is specific to servers, because they 
tend to attract a lot of network and disk traffic to themselves.

You could go on to say "but if the writeout path didn't have any servers 
in it, I wouldn't have to do any resource managemen!"  That's correct 
except it's a lot easier to get some acceptable form of resource 
management working than to distribute the on-disk data structures 
involved.

I think the biggest part of this problem is just defining what's needed.  
How hard could it be to implement?

Oh, is the resource manager to be distributed, or will it be a 
server? ;-)

Regards,

Daniel