Performance, security and reliability are critical to the successful operation of web services. Of all the design patterns used to mitigate and handle these aspects, among the most proven is clustering. Clusters are generally composed of a mesh of nodes, such as a network of computers or a set of services that have reached a consensus.
Clusters can be deployed to help in the following scenarios:
Also know as failover clusters, this is useful when you require that your applications have as little downtime as possible. This usually requires a “heartbeat” signal between nodes, used to determine the health of nodes and applications running on the nodes. Should nodes/applications fail, this is indicated through the heartbeat, or lack of, and allows the necessary “failover” action to be performed, ie. migrating to another node.
These are useful for applications which require high performance. Rather than dedicating a single computer to the task, several smaller computers (nodes) can be clustered together. To increase performance all that is required is for new nodes to be added into the cluster. As a result of this, clustering for high performance has found high use in modelling and simulations, particularly in the scientific community. HPCC (High-Performance Computing Cluster) and Hadoop are just two frameworks which can be used to implement this.
Load balancing allows for workloads to be shared across the nodes within the cluster, managed by a load balancer. Incoming traffic is directed to the load balancer, which then directs the traffic to one of its nodes.
These scenarios all have this set of 5 best practices in common:
1. Scope out cluster capacity
How you architect your cluster will determine the number of clients, connections and workloads it can handle. Pushing live with too high a ceiling will waste resources for little benefit, and too little will prematurely impact cluster operations. Scalability is a key benefit to clustering; use it.
2. Deploying clustering file systems
In most cases it would be desirable for each node to use the same data. There are many different ways of implementing this, eg. DRDB (Distributed Replicated Block Device) on Linux replicates the data between the nodes of the cluster. It helps mitigate inconsistencies, and allows for high availability in the event one server goes down.
3. Building on consistency
Deploying clusters with composable, ephemeral resources ensures an outage of a node can be mitigated by immediately replacing it with a new resource. By keeping a manifest of resources defined in a tool, CM tools (eg. Ansible, Chef, etc.) can be used to automatically deploy, expand and maintain clusters.
4. Comprehensive monitoring and testing
This is a regularly overlooked aspect. Upon discovering a fault, a well designed cluster will fail out impacted services or servers automatically, or with a minimal amount of engineer intervention. For example, database clusters will often sync transactions across a cluster, allowing a target host to be promoted to master should the original master fail a monitoring test.
5. Leveraging different regions and high availability
A strength of the Infrastructure as a Service cloud model is the ease with which servers can be deployed to different regions. A global cluster ensures higher levels of redundancy, such as a separate DR or “disaster recovery” zone, as well as allowing for optimal experiences for clients in those regions.