Slashdot Mirror
Linux Clustering
Bookman emphasizes a central piece of wisdom that no system administrator should ignore: redundancy. In the case of high availability clusters, parts redundancy is the name of the game, but one should not forget the human component; no administrator should be caught with only a cell phone -- keep a pager just in case. However, in a post-modern turn that might seem brilliant if it were applied in a work of fiction rather than a technical book, the author seems to apply the concept of redundancy to the text itself.
That the book began not as a book but rather as a collection of talks or presentations, or some other smaller format, is evidenced by the repetition of information between chapters and sections. Such nearly poetic repetitions also occurs within sentences and paragraphs (e.g. "nightly backups each night" on page 25).
An editor never looked at Linux Clustering; the book had two "technical reviewers" but their contributions seemingly didn't include fixing mangled syntax and strained style. On page 14 in the second paragraph a large segment of a sentence from the previous page is pasted into another sentence, resulting in a nonsensical block of text. The number of hyphenation, syntax, word choice, and subject-verb agreement errors is atrocious and makes the book difficult to read.
Some of the misinformation in the text appears to be unintentional (but ignorance is no excuse for a UNIX systems administrator); some is due to the fact that the author deals only with old (2.2) kernels (though the book came out 18 months after the 2.4 kernel release), old versions of journaling filesystems, and old distributions; and yet other misinformation is the result of misplaced attempts at humor (such as stating that GNU stands for the Gateway Naming Utility; one can only hope that this was intended to be funny). Other jokes often misfire, but do point to the intended audience (consider, for example, the section heading "Space: The Final Frontier").
In the Introduction, the author indicates that the book should be read by "Linux enthusiasts and users who want to get a Linux cluster up and running with the least amount of fuss." The organization of the book will not, however, aid this enterprise, for there is little "how to" information provided, but rather a great deal of background information on compiling kernels, various types of journaling file systems, and RedHat's Kickstart (perhaps inappropriate considering that the book specifically states that basic information will not be covered). Another section or two deal with basic networking and security. Various types of clusters are discussed, as are a few of the types of clustering software (e.g. Condor and Mosix) available.
The book, however, is clearly intended for administrators of clustering systems; a special emphasis is high-availability and load-balancing clusters. Parallel computing and the types of applications end users would wish to run receive far too little discussion.
Almost all technical books regurgitate the contents of freely available FAQs and HOWTOs to some degree, yet the good ones summarize the relevant points, make dry documentation more accessible, and give the reader some new insights. Because Bookman's Linux Clustering suffers from heinous spelling, grammar, and style errors; deals primarily with outdated software; contributes little new to the discussion; and doesn't speak to non-admins, I can only recommend that those interested in Linux clustering stick to online FAQs and HOWTOs.
You can purchase the Linux Clustering: Building and Maintaining Linux Clusters from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
In my mind, this is simple -- I have never read a worse O'Reilly book than Building Linux Clusters. There is a reason that ORA pulled this book out of print after only 6 months, and haven't even bothered to try to fix it and reprint a new edition. It was basically a commercial for the company the author ran, it read as if it hadn't been edited (spelling and grammar mistakes everywhere, included pictures were of the wrong thing that the text referred to), and the code included was so buggy it wouldn't work at all without a lot of fixing.
This was the first book on Linux Clustering I read, and I was hugely disappointed
Redundancyis the key our are missing here. If one cpu goes down ina cluster, the performance starts to suffer, but you are still up. If you one really beastly CPU goes down, you are down. That is the point o cluster. So while it may be "more" expensive, you are paying for the uptime.
Great Linux Site
I have to add that 'Apache: The Definitive Guide (Second Edition)' was pretty horrible as well. Like the MySQL book, it was heavy on re-hashing available information and light on useful information like a dash of theory or a hint of how the authors used it to solve a particular problem.
And I hate it when O'Reilly comes out with a bad book, because generally their books are great.
that book is very poorly written. Beowulf Cluster Computing with Linux is a much better book.
Here are the books I've found most helpful on MySQL (and using MySQL with other things):
MySQL- Paul DuBois
MySQL and Perl for the Web- Paul DuBois
PHP & MySQL- Welling & Thompson
Thoughts on stocks, markets and trading
It depends on why you are using the clustering, I use NT clusters at work all the time to increase reliability of the system. It doesn't help performance one bit in my situation (and isn't meant to) but if one node of the cluster goes down all the services start up on the other node and there is next to no downtime.
"You can now flame me, I am full of love,"
There *ARE* some good New Riders books - it's just that they tend to deal with digital art:
"Digital Texturing and Painting"
"Digital Lighting & Rendering"
New Rider's focus is more on the artist / animator / illustrator side of things - and at that they excel (the above two are those I'm most familar with, and they are excellent).
I'm sure they'll gradually improve their hardcore technical books, but it's stupid to dismiss "all" their books as being bad. Just like O'Reilly has a reputation in some circles for being overly dry and out of date - *some* people find their books useful.
O'Reilly's Linux Hacks has one of the best explanations I've seen for setting up mysql replication. Load balancing and failover area are topics in their own right, but the Linux High Availability HOWTO is a good place to start. In general, the ibiblio site has been a helpful source.
http://tinyurl.com/4ny52
The newer edition, Managing and Using MySQL goes a long way to correcting the sins of the first book. I haven't read these others to compare directly, but I find the new edition a lot more clear and useful than its precursor.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
What kind of beastly machine goes down because of a single bad cpu? Only Intel based machines and none of those are all that beastly anyways. Big Iron does not go down to a single cpu failure. Where clusters rule is when you can chunk datasets into the ram space of a cheap rackmount box (2-4GB) and you have low enough interprocess communications that using comodity ethernet won't totally pooch your performance. If you meet those two requirements then the incredibly low cost per MIPS of x86 hardware will make it basically a no-brainer to go with a cluster.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I think the best thing to do would be download some of the open source tools that are out there and build a small one.
Some of the more popular that are used in the bio-sciences are.
http://www.platform.com/ (demo only, but most powerful)
http://www.openpbs.com/ (open source)
http://gridengine.sunsource.net/ (open source)
All these run on linux.
jpc
Bollocks,
/. but here goes.
granularity, I'm tired of explaining this on
There are two main typesd of cluster, High Performance and High Availability.
HPC tries to increase the power of the cluster by spreading jobs out over the whole cluster. HPC breaks the work down into blocks and farms this block out to the nodes. In the worst case a single node failure could cause the whole cluster to fail.
HAC tries to increase the uptime of the cluster by running the same job on more than one node. If a node fails then the job on the mirror node takes over. It's worth noting that no Linux cluster has 100% HA.
If a single node is going to fail 5% of the time what is the up time of a 100 node cluster?
I work in the commercial not the scietific world. HPCs bore me. HACs could be a god send.
Imagine if you will a cluster that automatically deals with node addition/subtraction. I have 1,000 users connected to this cluster using Xterms. I need more power, add more nodes. If any nodes fail the user never loses anyuptime as their work is switched to a mirrored node or nodes.
Centralised computing rocks.
I wrote up a paper for my employer a while ago about most of those topics. The sad truth is that a comprehensive guide is not available, and most of the solutions are proprietary. However, there are a few bright lights.
Eddie: Load Balancing Software
http://eddie.sourceforge.net/
Linux Virtual Server Project: Clustering Tools
http://www.linuxvirtualserver.org/
OpenAFS: Efficient Distributed Storage
http://www.openafs.org/
Load-balancing and failover are tough nuts. You can do some stupid things like Round Robin DNS or Rotary NAT, but to be actual balancing, you need a balancer box. You can either make your own (using proprietary software or the stuff above) or buy a piece of hardware to do the job for you. I've heard Cisco makes some good ones.
NAS units usually operate using CIFS, AFP, or NFS, all of which are pretty lame options for a modern cluster. SANs are pretty cool, but you need some big-ass hardware to support them. Personally, I'm working on an OpenAFS cluster, which is pretty easy if you look into the capabilites of the software. Coda is another option of which I'm not using because it doesn't play as well with Windows.
As for clustering MySQL: If you read the Slashdot interview log they had a couple days ago, you'd see that the setup here is a master writer that replicates to a couple of reader databases. This is about as effective as it gets with MySQL. If you need higher power, I've read that commercial versions of Postgres support clustering/synchronization. More powerful than that and you're into Oracle territory.
I own maybe 30 O'Reilly Titles and "MySQL and mSQL" is easily the worst one of the bunch. Here's my take as to why.
I came from an Oracle background (i.e. already understood SQL, relational databases, etc.) and I was interested in 2 things; how to administer a MySQL database and how to do simple access from PHP/Perl.
Now go and pick that book and try and find that information. The description of the MySQL security model is muddled and confusing. No good details on how to do backup and restore. The examples for using PHP/Perl are horrible. The book has several chapters of filler.
A year or two later I bought the New Riders title mentioned in the writeup. It is a massive improvement over "MySQL and mSQL" - read them side by side and you'll see.
One thing that book taught me - just because it is a publisher you trust, don't assume the book will be good. Read it or read a review first!
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
(Shameless plug)
Head over to LinuxNetworx now for a LinuxBIOS-ready Evolocity II cluster!
Note: I'm not an employee of LinuxNetworx, but they still kick ass.
the june issue is entirely clustering.