Chapter 20: The Linux Cluster Environment

In this chapter, I'll provide a high-level review of the material presented in this book and a proposal for a new type of computing environment that is based on parallel processing and hardware redundancy using free software.

Before I begin, I should point out that I do not expect anyone who reads this book to have the opportunity to build a data center for a large organization from scratch. Large organizations already have data centers, and even small organizations that grow big enough to need a data center will have a legacy of information technology decisions that influence the development and design of their first data center. You will, therefore, probably not have free dominion over every design decision that lets you build the ideal data center or enterprise computing environment, no matter what your situation is. In this chapter, however, I would like to ask the question: "What would the ideal data center look like if you could build it?" My answer is based on my practical experience building the cluster I've described in this book. As you'll see in this chapter, I believe the three foundations of the ideal data center are free software, low-cost commodity hardware, and a highly available Linux Enterprise Cluster.

The Linux Enterprise Cluster

Let's start with the cluster. Remember that all cluster nodes run the same application programs (they offer the same services to the client computers). Console access to these nodes is made possible by a keyboard video mouse (KVM) device, as shown in Figure 20-1.

Figure 20-1: Figure of a ten-node cluster with a KVM device

The black box shown connected to the first two servers is a Stonith device that allows the primary LVS Director to reset the power to backup LVS Director. This hardware configuration is required as part of the Heartbeat package (a typical Stonith configuration will require two Stonith devices). Two computers act as a primary and backup load balancer and run the Heartbeat daemon. The ldirectord daemon runs on the primary LVS load balancer and removes nodes from the cluster when they fail. If the primary LVS load balancer crashes, Heartbeat running on the backup LVS load balancer starts the ldirectord daemon and begins load balancing the incoming requests from the client computers.

The telnetd and sshd daemons are also shown in Figure 20-1. Like the Apache daemon, they run on all cluster nodes to allow client computers to access the cluster. What about the business applications running inside the cluster? In the next section, I'll examine applications that run in the ideal data center on a cluster more closely.

Applications Running on the Cluster

The cluster runs objects that are the business tier of N-Tier applications. The term N-Tier applications refers to a conceptual model for breaking up an application program into layers in order to separate the application's functional components into basic categories that must exist for an application to do its job properly. The three most fundamental tiers in the N-Tier application model are the data, business, and presentation tiers. Briefly, the data tier is where the database server resides, the business tier is where the objects that define business rules reside, and the presentation tier is simply the user interface to the application (the user interface to the other tiers). So to refine the statement that this paragraph started with, I should say that an enterprise cluster is where business tier objects run in parallel. This is the same thing as saying that copies of the business tier object-oriented programs will run inside the cluster on all of the cluster nodes.

In a Linux Enterprise Cluster like business tier objects run in parallel; however, they do not know of each other's existence. Applications running inside the cluster, therefore, do not need to communicate with each other and objects that remain inside the cluster never need to be serialized. Shared data and stateful information about user sessions is stored in a session database outside the cluster. If a cluster node crashes, the load balancer reassigns user sessions to a new node, but the user sessions are persistent because the business tier objects running inside the cluster use the unique session ID as the key into the session database.