Up until the cloud computing has started to emerge, when the applications that were developed needed a scale it usually required larger hardware.
So, the solution was to use a more powerful hardware:
- more CPUs,
- more RAM or
- more disk space (depending on the requirements of the application).
And this was and is still called vertical scaling.
But then a problem arises: there were situations when the system reaches the maximum supported number of CPUs, RAM or disk and once that happens, there is no way to scale more.
Nowadays, with the cloud computing, and the applications deployed to the cloud there is another approach. Rather than switching to larger servers, more servers are obtained and identically configured services are installed on each one of them.
Therefore, the scaling is among groups of functionally identical services (for example, compute nodes or nova-api nodes), that communicate on a message bus.
This approach means that your application is running on multiple servers and if you add a load balancer in the cloud, the application will be able to handle much larger number of requests. This is called horizontal scaling.
Now, when the application is running on multiple instances, the load balancer will be the entry point to clients. It will accept all requests and internally dispatch them to the actual servers.
The benefit of this type of scaling is that the limit with hardware insufficiency is moved, because servers can be added behind the load balancer until compute resources are run out of in the cloud. But even then, there is always the option to add more hardware to the cloud and push the limit even further.
Vertical scaling works like “computer upgrade”, so the application will work faster and without problems after the “upgrade”.
On the other side, the horizontal scaling requires the application to be carefully designed so that it is synchronized on all instances in the cloud.
An example can be application that writes data to disk files. When one instance on application request updates some file on disk, all the other instances should do the same, or will become outdated. So, data files that change may need to be replicated to all the instances, or else the load balancer could be configured to send a given client always to the same instance, so that the client specific files are always accessible.
While Horizontal scaling gives you more freedom to grow, it is not a practical solution for all types of applications.
Cloud orchestration and Heat – the OpenStack component
Horizontal Scaling with Resource Groups
The most basic approach to horizontal scaling with Heat is based on a resource type called OS::Heat::ResourceGroup.
This resource wraps a standard resource definition and creates multiple identical copies of it.
When an application in the cloud gets busier at some times over another more resources at those times are needed, but without having to take the stack offline and make a new one. So the scaling needs to be done dynamically. The Heat component has stack-update command that lets make changes to the stack on a schedule.
With the AutoScalingGroup, another resource type in Heat, which in many ways is similar to ResourceGroup, resource can be configured to apply scaling changes on certain events, triggered by Ceilometer or by a custom monitoring agent. With this resource, can be created scaling policy rules that alter the size of the server pool based on CPU usage or any other variable that can be monitored.
Horizontal Scaling and Databases
Scaling applications that read and write data is harder. Database applications, like MySQL, have their own storage, no matter whether it’s on the instance that it runs or external.
No matter how many copies of the MySQL nested template are made, there still would be a problem with the storage since if they all have separate storage they should be synchronized for write operation, or if they all have point to the the same storage, a bottleneck will be created that will limit the scaling.
Database replication is a tough problem to solve, and not all database servers have a solution for it.
These issues with horizontal scaling are not exclusive of databases. In reality, any process that writes data to disk, even regular files, is potentially harder to scale due to the need to replicate writes to all the servers in the pool.
VapourApps Private Cloud uses OpenStack which is designed to be horizontally scalable.:
- Virtualization engine – OpenStack on KVM
- Predefined virtual servers based on Debian
- Orchestration and management web dashboard, a customized Horizon dashboard.
The owner of the tenant or the IT administrator, can manage his virtual servers, users, groups and monitor the status of the used application from a single dashboard.
Download and try VapourApps 1.0 Beta