Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software

Theres plenty of information in here, but the biggest problem I had with working my way through the book is it's structure. The book presents the topics in a bottom-up way, kicking off with low-level xinetd & init configuration, and doesn't actually get down to an overview of clustering until page 196! Thats fine if you already know what you're aiming for, but for the novice looking for an overview of clustering in the Linux environment, it's almost better to read the book backwards - start with Chapter 20 (an overview of the whole environment), read through Chapters 11-13 (cluster architecture and components), and finally hit Chapters 6-8 (heartbeat) and the remaining chapters (which go into detail on the various different components).

Clusters, like many things, come in various flavors. These can be roughly stated as `high throughput', `high performance (HPC)', and `high availability'. The "Linux Enterprise Cluster" is a good read for those looking for the `high-availability' cluster flavor, for perhaps a mission-critical computing resource. There is thus more emphasis on fail-over and service request handling than, for example, MPI, exacting operation calculations, and HSI maximizing techniques typical of HPC endeavors. This is not to say this book is not applicable to the other cluster types. Could you do with a chapter on SystemImager? How about Ganglia? Rsync & SSH? Building a kernel? All this step-by-step? Awesome! I was building an HPC cluster at the time, and found this a good book for drilling into deeper cluster software infrastructure details while at the park or waiting for a class to start. It was however sparse on hardware details and proper supporting infrastructure, but no book under 10 pounds is going to cover everything so be prepared to read a lot. I did not evaluate the included CD-ROM, which is loaded with goodies, because I simply downloaded the packages from the Internet as needed.
4-stars

If you want to build any HA cluster, this book is for you. The author has the ability to write from entry level to advanced Linux admin skillsets. His recipies for HA and LVS clusters are complete and realistic. We all know there are few Linux books we read from cover to cover. This is one of them.

Karls book seems for me the perfect book for small clusters. He describes every single install and configuration aspect I could possible think of.

The book is extremly readable and described each single step and its considerations easy understandable. It does read at times a bit theoretical like it was made by a teacher, ruther than a technichian, but perhaps that is why it is so comprehensible.

For the details found inside it is very compact which makes it easy to carry it with you when you go onsite.

Whats not described in the book:

Environmental considerations like Heat, Power consumption, Budget calculations on several technologies etc.

Those are described in Roert W. Lubkes - Building clustered Linux systems.

Those 2 books compliment each other very nicely.

When you find something you really like you want to have/know more of it, not really being important if it is food, an idea or a piece of art. And part of liking something is getting greedy+opinionated+political about it.
One little thing that bothered me about this book was the constant changed of fonts from like 12 points to 8 and then 6 with a gray background. Usability anyone? But this is not something the author should be blamed for.
I am more of a software person, but IMHO here are my comments about the book. More aimed at the next version of Karl's book or in case some wants to pick up these ideas where he left them off.
Karls book was slashdotted also (go slashdot and search (underneath to he left) on 1593270364),
[...]
but I found more flame baits and slashdot'ing that attempts to talk about this excellent book intelligently:
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
._ considering the 2.4 version of the kernel? fine! But why even talking about ipchains if the whole LVS idea is based on Netfilters and who uses ipchains nowadays anyway?
._ more on power management of the primary and back severs, does heartbeat do some kind of interfacing to APMD on both?
._ have these ideas been ported for *BSD? I mean, I really find silly these "Give me Linux or give me dead" battle cries from us, OSS techies, when we should actually love the fact that we have more options as robust (if not as popular) as Linux.
._ more on the reasons why the different pieces of hardware in a cluster would fail and how to work around these issues (just the basics of it with points to more info (we sw people some times code without consideration to the fact that RAM is very expensive nowadays and using in-memory Data Structures would make HDDs give us their blessings)).
._ there are NICs with two (and 3?) connectors out there, why not using them in an LVS env.? And if there are reasons, why not mentioning them? NICs are cheap and available, PCI slots on a mobo aren't.
._ page 140; ... "the system time between the two servers should be within minutes of each other" ... why? It is vital on a cluster having all boxes accuraelky synchronized!!! This should have stressed/elaborated on.
._ more on the measurability of the whole concept of availability, the requirements/issues relating to a 99.99% uptime are very different to the ones of a 99.999% uptime, and the issues relating to it (both hw and sw).
Also, on the fact that absolute ha/uptime (100%) is just an ideal state. We should not go totally crazy about. Eventually we will have to make decisions that might affect 1 in 10,000 users and we will have to live with it (instead of taxing all 10,001 users with a less performant app). Because even if we put the effort to achieve 100% uptime, say, a cosmic ray could run through our box and change the parity of a byte running ...
._ I could not quite get why the backup server does not functionally take the role of the primary one entirely
._ page 158; more on the exceptions of filesystems regarding heartbeat configurations
._ more on the implications that using different kinds of applications have.
I wouldn't complicate firewall rules with the ftp protocol when the http can do the job as well even with the option of more/better coding through a web interface and you can safely (checking MD5SUMs, etc) stream data from point A to B. But I would like to see a more detailed handling of the HTTPS protocol. Separating an SSL cluster from the HTTP one (not doing port affinity between ports 80 and 443) I think is better, because you don't have to spend money on SSL accelerator cards for all boxes in the cluster, the access paths to back end data stores could be better optimized/controlled, for security reasons it is better to not have the same applications listening on insecure and secure ports, more accurate logs, ...
._ at least -some- figures on the performance differences between LVS-DR and LVS-NAT configurations. Didn't he recommend doing LVS-NAT as a step towards the more performant LVS-DR installation?
._ I think using software for ha performance and maintenance-wise is good to, especially since RAM is so dirt cheap and processors so powerful (hyper threading, pipelining, ...) I use several Tomcat instances 'directed' by an Apache one and it works well, letting you, within the same box, reconfigure apps without taking the app offline.
._ page 366; "Another technique to avoid a single point of failure for SQL data ..." I would just changed the word "Another" for "THE". Karl, buddy, have you started to see "clusters" everywhere? ;-) Let's do DBMS what they have been designed for? Taxing clustered systems with extra, unnecessary, care for DBMS does not make any sense, I think. Or?
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
An here comes what I think it is the lie behind the whole idea of doing packet filtering just based on the kernel's packet headers handling.
As it is rightly pointed out in the book whole organizations face the Internet through a single IP address (NAT) (I have even heard about whole countries like Saudi Arabia, ...), how would you go with these cases.
Users' session handling (inside of the HTTP application headers, not just simply the packets) in order to actually tell apart new user connections is VITAL to actually and truly do clustering.
.
Albretch