Book Image

CentOS High Performance

By : Gabriel Cánepa
Book Image

CentOS High Performance

By: Gabriel Cánepa

Overview of this book

CentOS is the enterprise level Linux OS, which is 100% binary compatible to Red Hat Enterprise Linux (RHEL). It acts as a free alternative to RedHat's commercial Linux offering, with only a change in the branding. A high performance cluster consists in a group of computers that work together as one set parallel, hence minimizing or eliminating the downtime of critical services and enhancing the performance of the application. Starting with the basic principles of clustering, you will learn the necessary steps to install a cluster with two CentOS 7 servers. We will then set up and configure the basic required network infrastructure and clustering services. Further, you will learn how to take a proactive approach to the split-brain issue by configuring the failover and fencing of the cluster as a whole and the quorum of each node individually. Further, we will be setting up HAC and HPC clusters as a web server and a database server. You will also master the art of monitoring performance and availability, identifying bottlenecks, and exploring troubleshooting techniques. At the end of the book, you’ll review performance-tuning techniques for the recently installed cluster, test performance using a payload simulation, and learn the necessary skills to ensure that the systems, and the corresponding resources and services, are being utilized to their best capacity.
Table of Contents (13 chapters)
CentOS High Performance
About the Author
About the Reviewers

Split-brain – preparing to avoid inconsistencies

Up to this point, we have considered a few essential concepts in clustering, leading to the following not completely fictitious scenario—what happens if a cluster is formed by nodes that are located in separate networks and the communication link between them goes down? The same applies when the nodes are in the same network and the link goes down as well. That is, none of the nodes have actually gone offline, but each appears to the other as unavailable. The default behavior would be that each node assumes that the other is down and continues serving whatever resources or applications the cluster was previously running.

So far, so good! Now, let's say the network link comes back online but both nodes still think they are the main cluster member. That is where data corruption—at the worst—or inconsistency—at the best—occur. This is caused by possible changes made to data on either side without having been replicated to the other end.

This is...