Building Clustered Linux Systems (Hewlett-Packard Professional Books (Paperback))

Performance Tuning for Linux(R) Servers

High Performance MySQL

Servers

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

Format: Paperback
Author: Karl Kopper
ReleaseDate: 01 May, 2005
Publisher: No Starch Press
Rating:

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

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 comprehensable.

For the details found inside it is very compact which makes it easily 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. .

very well conceived and written book!
And part of liking something is getting greedy+opinionated+political about it. 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.
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 .

One stop guide to building a Linux Cluster
One aspect of Linux that has been explored recently is its enablement that is gives users that wish to build a clustered environment. The sheer number of books published in the recent years that cover the Linux Operation System is simply staggering. Using free software and commodity hardware many organizations small to large, and even end-users such as myself, have been able to build a cluster or a Grid using Linux very cheaply. This book by Karl Koppers shows the readers a step-by-step guide of how to go about building an enterprise grade Linux cluster environment. The author depicts each step one by one for the reader and demonstrates what each step does and why "we do what do we".

The following steps required for building a cluster are explored in detail in this book:
*Understanding of the underlying Linux routing (NetFilter and basic packet routing)
*Understanding of SystemImager program, and how it can help you in building a large cluster
*Learning of to apply configuration changes to your cluster efficiently
*Learn to build a Linux Virtual Server Network Address Translation fro your cluster, and learn why you need such capability
*Learn how to manage failures in your cluster including software and hardware failures
*Learn how to manage and monitor your cluster from a single point using a Web-based GUI
*Learn how to apply software patches and updates to your cluster
*Administrator user accounts and remote login including password-less login via SSH
*Learn how to install a cluster print server
*Learn how to install a batch-job scheduling system on your cluster

As you can see, there are lots covered in this book. Some of the basics of the underlying Linux system and Kernel gets the reader off on a good start, and starts the foundation upon which the rest of your cluster can be built.

Unlike any other book that claims to cover this topic, Karl has added a number of chapters on the understanding (he calls them theory of . . . ) of the concept and why things are done the way they are instead of just telling the reader what to do. These chapters can be skipped, obviously, but I found them to be extremely useful because it gives me a deeper knowledge of the topic at hand makes me understand the topic better. The whole point of the book is to enable someone, by simply going thru the book chapter by chapter, to build a medium to a large size cluster. A how-to guide that is packed with the appropriate software packages discussed in the text.
My favorite topics in this book must the central administration of the cluster via Ganglia, and High-Availability configuration chapters. These two, monitoring and reliability, are key difficult areas which the author covers in detail.

The combination of the book and the accompanying CD-ROM packed with software packages make this book a great buy. I have built my own cluster, but I am re-doing my environment by going thru this book chapter-by-chapter. I highly recommend this book to anyone involved or interested in building or maintaining Linux Clusters.


.