On Fri, Jul 1, 2011 at 11:23 PM, Whit Blauvelt <w...@transpect.com> wrote: > On Fri, Jul 01, 2011 at 11:45:22AM +1000, Andrew Beekhof wrote: > >> Being a generic cluster manager, rather than purpose-built for a specific >> app like a filesystem or database, we don't get involved with things like >> data replication or anything else that requires an understanding of the >> services we're managing. This puts a natural limit on the kinds of >> scenarios we can be involved in. >> >> I guess you could say that we aim for "fits-most". But its a free world, >> people are entitled to build/deploy whatever solution they like. > > Thanks for the clarifications. I do appreciate all the discussion following > my initial question. It helps a lot with the overview. > > Here's my admittedly naive concern. In aiming to be "fits-most" Pacemaker > has become something very complex.
Most of the complexity actually comes with supporting >2 nodes. I've written more coherently on the topic previously: http://theclusterguy.clusterlabs.org/post/178680309/configuring-heartbeat-v1-was-so-simple But without doubt Pacemaker is more complex than a purpose built solution. The question, which only you can answer, is whether its going to be "cheaper" to build and maintain a custom solution or to use something off the shelf (all-be-it with a non-trivial learning curve). Btw. have you read Clusters from Scratch? It's at http://www.clusterlabs.org/doc/ and is probably the closest to the type of book you mention below unless you read German. Oh, there is also http://oss.clusterlabs.org/pipermail/pacemaker/2010-February/005179.html which can be purchased in paper form. -- Andrew > It may well look simpler from the inside, > but from the outside it's not just the complexity of the Pacemaker system > itself, but the difficulty making sense of the scattered documentation. > There is no book on it. There's no online equivalent of a book on it. There > are some wonderful diagrams of it on a meta level, and some very low-level > docs generated from the source, and some specific examples which are pretty > much only useful if one of them coincides with the desired deployment. In > our case none of them do. > > Now, as a sysadmin, I damn well better understand the deployment of my HA > scheme. It has to be something I can handle when it goes wrong at 4 a.m., > and there's no time to make coffee. I can arrive at that by one of two ways: > deploy something developed and proved elsewhere that has good reference > material, or develop something myself to the specific purpose and make sure > I document it well as I go. Yeah, I could never build something with the > scope of Pacemaker. But for a narrowly-defined, specific purpose it's within > the reach of even the moderately skilled, providing that concepts and logic > are clear. > > Or - this all being components - I might take for instance Corosync and use > it without Pacemaker. That's why I asked the initial question about the > feasibility of doing so. In a year or two, if someone publishes a good book > or two on Pacemaker, in classic O'Reilly style, we might do well to throw > out whatever I currently deploy and do the next version with Pacemaker - or > more likely Pacemaker plus specific bits of what I presently build. > > I'm sure Pacemaker is beautiful. But without better reference materials the > beauty is hidden. I'm sure if we hired someone intimate with the project as > a consultant we could get a sterling deployment. But that still wouldn't > solve the "4 a.m. with no time to brew coffee" dilemma. Also, the scale of > our project is on the small side, so it would be hard to justify a > consultant's cost. On the other hand, if that consultant would write the > book, we'll be first in line to buy a copy. > > Best, > Whit > > _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
