Building a Linux Cluster, Part 1: Why Bother?
- Introduction
- Defining Cluster
- Why Clusters?
- Why Linux for Clusters?
- Summary
Editor's Note: Be sure to read the other articles in this series, Building a Linux Cluster, Part 2: What's Involved? and Building a Linux Cluster, Part 3: How To Get Started.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Linux clusters have escaped. As the general popularity of the Linux operating system increases, more complex solutions built with it are becoming increasingly common in the "traditional" (more conservative) IT world. Linux computer clusters, whose provenance was originally universities and research institutions such as the U.S. National Laboratories, are showing up in increasing numbers as high-performance computing solutions within such areas as oil and gas exploration, computer-aided engineering, visualization, and software development. Linux clusters providing highly-available web, mail, and other infrastructure services are also increasingly common. If past computing history is any indicator of future trends, widespread use of Linux clusters in the mainstream IT world cannot be far behind.
But we need to ask the question, "Is mainstream IT (or my organization) ready for Linux clusters?" Building any kind of cluster solution, whether or not it's a Linux cluster, can be a difficult undertaking. Based on other complex projects, we might well remember the Man in Black from William Goldman's The Princess Bride (Ballantine Books), when he tells the princess, "Life is pain, Highness. Anyone who tells you differently is selling something." Cluster-based solutions are challenging; anyone who tells you differently is probably not tied directly to the project.
How can you make sure that a cluster experience is successful? One good way is to walk into the cluster-building project with open eyes and realistic expectations, knowing the why, what, and how of the project. Before you start, have a good reason for building the cluster (why), understand the integration of the required hardware and software components (what), and apply good design and planning practices (how) that can minimize issues with your cluster.
We must avoid what I call pile o' hardware syndrome—the mistaken belief that buying all of the necessary components for a cluster and piling them on the floor in the computer room will spontaneously and miraculously generate a functional cluster. Hope is not a strategy.