HybridCluster provides exceptional density by using OS level virtualisation to provide secure lightweight containers within which applications and sites are run. This type of virtualisation is particularly suited to shared-hosting environments because of the lower overheads in memory and I/O performance compared to full system virtualisers.
However, if high density is used across a cluster of machines it’s vital to combine this with automatic live migration of sites across the cluster otherwise a single site under high load can cause all the sites on that machine to stop working – potentially impacting hundreds of customers, not just the one whose site has suddenly become popular.
HybridCluster achieves this by continuously monitoring the load and state of the applications and services running across the cluster and it can detect the resource usage of a particular site. Often the most critical parameter is the amount of disk I/O that a particular site is using and typically HybridCluster will use this as a determining factor in triggering the scaling process.
At the point at which the management layer determines that a site will be allowed to scale up and consume additional resources on the machine, the system will ensure that the state of sites to be moved is synchronised to other machines in the cluster. This replication and synchronisation process uses the same techniques as the HA feature.
While the synchronisation process is completing (typically less than 60 seconds), the AwesomeProxy layer will buffer requests to the sites that are being moved. Once synchronisation has completed, AwesomeProxy will allow these requests to flow to the site on their new machines in the cluster. This frees up resources on the first machine and allows the site under heavy load to scale up.
The control and management layer which detects the high load and triggers the scaling process is also the key element that measures the load to enable charging of the end customer to take place.
This auto-scaling mechanism also measures the load generated by each of the applications in the cluster, so that customers with busy applications can automatically be burst-billed based on “Hybrid Compute Units” — which customers can rebrand as their own PaaS/cloud scalable billing unit.