<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1st February 2002), see www.w3.org">
<!-- this stylesheet will later on be added by lfparser automatically: -->
<style type="text/css">
<!--
pre { font-family:monospace,Courier }
pre.code { font-family:monospace,Courier;background-color:#aedbe8; }
p.code { width:80%; alignment:center; background-color:#aedbe8;
border-style:none; border-width:medium; border-color:#aedbe8;
padding:0.1cm ; text-align:left }
-->
</style>
<title></title>
</head>
<body>
<h1>Book review: The Linux Enterprise Cluster</h1>
<h4>ArticleCategory:</h4>
SystemAdministration
<h4>AuthorImage:[Here we need a little image from you]</h4>
<img src="../../common/images/white.gif" alt="[Photo of the Author]" width="100" height="100">
<h4>TranslationInfo:[Author + translation history. mailto: or
http://homepage]</h4>
<p>original in en <a href=
"nospam:tom.uijldert(at)linuxfocus.org">Tom Uijldert</a></p>
<h4>AboutTheAuthor:[A small biography about the author]</h4>
<p>Tom is a member of the Dutch linuxfocus team and he has been
wrestling with clusters ever since Digital came up with the
idea.</p>
<h4>Abstract:</h4>
"The Linux Enterprise Cluster" is published by No Starch (<a
href="http://nostarch.com/">http://nostarch.com/</a>). ISBN:
1-59327-036-4. Author: Karl Kopper.
<h4>ArticleIllustration:</h4>
<img src="../../common/images2/article385.gif" alt="Linux Enterprise Cluster" hspace="10" width="157" height="207">
<h4>ArticleBody:</h4>
<h2>Clustering</h2>
<p><em>The art of having a couple of commodity computer systems
behave as one</em>.</p>
<p>This, in essence, is what clustering is all about.<br>
So why would you want to do that?</p>
<p>Well, 2 possible reasons here:</p>
<ol>
<li>
<dl>
<dd>You don't have enough processing power (nor enough
money to get it), so you combine some cheap boxes to get
the power just the same.</dd>
</dl>
</li>
<li>
<dl>
<dd style="margin-bottom: 0.5cm">There's some critical
programs running on your system and you <em>really</em>
can't afford to have system downtime (time is money).
Hence, you devise a configuration whereby a commodity
computer (or part thereof) may fail but the system as a
whole stays up (high availability).</dd>
</dl>
</li>
</ol>
<p>The first issue is in the realm of universities and R&D
departments. They never have enough funds but they
<strong>do</strong> need the processing power. Projects like <a
href="http://www.beowulf.org/">beowulf</a> or <a href=
"http://pareto.uab.es/mcreel/ParallelKnoppix/">ParallelKnoppix</a>
take care of these.</p>
<p>The second issue is more in the realm of companies (or
<em>enterprises</em>). Funding is usually not a problem but
system downtime <em>is</em>.<br>
Imagine having your development department of 60-odd people
waiting on the system to become available again. Or an office
of dozens of administrative staff,
waiting for the database to come up again. System downtime can
thus become very expensive and that's where this book comes
in.</p>
<p>The book focuses on building <em>enterprise class</em>
clusters -which is synonym for highly available- that will keep
on going.<br>
In many ways, this is a very unforgiving book. Don't expect any
airy-fairy talk on the theories behind clustering or high
availability. This book gets right down to business: build the
damned thing and do your maintenance on it.</p>
<p>So if you're looking for some abstract, high-level
introduction into highly available systems, stop right here and
go look somewhere else. You will not find it here.</p>
<p>If, however, you have the boss breathing down your neck
right now screaming: “The system is down again and it is
costing me a fortune! What the hell am I paying you
for!?” then this is the book you'll need.<br>
So read on, for some more details.</p>
<h2>History</h2>
<p>Legend has it that the computer company <dfn>HP</dfn>
(formerly known as <dfn>Compaq</dfn>, formerly known as
<dfn>Digital Equipment Corporation</dfn>, “what's in a
name?”) could not, in those days of mini- and mainframe
computers, come up with a processor
rivaling the power of the IBM mainframe
processors. Hence they came up with the idea of clustering
their minicomputers so that they could offer customers
something that rivaled the
mainframe-bids.</p>
<p>I doubt whether they ever persuaded an IBM customer with
this scheme but they <em>did</em> find something else. That if
a minicomputer crashed or went down, the others would still
function. The worst that could happen was that a user would
have to login again because he was attached to the crashing
computer. A highly available system was born.</p>
<p>Now I'm not sure how much of this is true and/or urban
legend, but it's a nice story so I'll stick with it until a
better story comes along.</p>
<p>Clustering is a specialised and complex matter. This is
proven by the fact that no commercial Unix-vendor has -until
now- come up with a clustering-solution that could rival the
(Open)VMS solution (yes, not even the Unix systems of Digital
itself were up to par with the VMS clusters). And now the open
source community has a stab at it.</p>
<h2>The book</h2>
<p>Has a bit of an odd build-up. You would expect it to start
with a general description of what the goal is, some background
and theory and then gradually moving down to the bits-and-bytes
stuff.<br>
Not this book. This one states: “We're going to build us
a cluster, and this is the recipe:...”. And so part one
starts with some Linux basics like compiling kernels,
installing packages and basic network configuration, that
you'll need to master before a next building step is taken.</p>
<p>That next step essentially contains more basics, but now
focused on packages and configurations that deal with high
availability. Included here are subjects like system cloning,
the heartbeat package and <tt>stonith</tt>-devices.</p>
<p>Part 3 then combines all these basics to implement highly
available clusters using load-balancing. And here, finally,
everything comes together, with some added cluster-theory as
well (we're by now almost 200 pages into the book already).</p>
<p>The final part deals with how to keep a cluster running. How
to administer maintenance and monitor it's performance.</p>
<p>So, like I said, a bit of an odd build-up but then again,
who said you need to read a book sequentially, front to
back?</p>
<h2>The verdict</h2>
<p>If anything, this is a <strong>practical</strong> book.<br>
I can see a battered copy of it, always lying around in the
server room. Battered, because it is so frequently referenced
by the sysadmins in maintaining their clusters. Like a cookbook
indeed.</p>
<p>This practicality can for instance be seen in the
substantial part (4) that is devoted to cluster maintenance and
monitoring. Where many a book would stop once a
cluster-configuration has been built, this book does not forget
that all-important phase that follows after implementation.</p>
<p>Another indication is the tremendous amount of notes,
footnotes, tips and tricks that this book is littered with.<br>
What about a gem like (page 322): “<cite>You can write a
script that calls another script, but just be sure to pass the
exit status of the child script back as the exit status of the
main script or SNMPD will not see it</cite>”.<br>
You can only come up with these kind of notes once you have
experienced them yourself and bumped your head on them
before.<br>
And this book <em>oozes</em> that kind of blood, sweat and
tears. I can well imagine the author, for months hacking away
at installing and configuring new systems, finding out what
problems there are, trying to solve them or come up with other
alternatives. All the while meticulously making notes of every
glitch or problem he encounters.</p>
<p>And finally, definitive proof was given just a few days ago,
after reading the book, when I could help a
colleague with a problem by pointing to some
excerpts from the book.</p>
<h2>In conclusion</h2>
<p>The practicality of this book is also one of its weaknesses.
It will not age well. A lot will need to be rewritten in 2 -3
years due to ongoing developments in the open source community,
configuration changes etc.<br>
Then again, you don't buy a book only to use it years from
now.</p>
<p>In addition, the book contains a
handful of appendices and a complementary CD-ROM
with more on downloading, troubleshooting, configuring,
packages and scripts, enough for you to experiment with
clustering to your hearts content.<br>
What I would <em>really</em> like though (hint hint) is for the
author, after this landmark work, to take the book and
knowledge gained a step further and come up with a complete
distribution. Something like <em>EnterpriseKnoppix</em>,
containing all the goodies needed to make a highly available
cluster.</p>
</body>
</html>