One of the most common scaling paradigm during the 2000s was that of creating several virtual machines, create design packs for installing standard softwares like Oracle, MySQL, ZooKeeper, Solr etc. and manage the lifecycle of these components through a browser. The "virtualization" technology at the core of this strategy creates several VMs (Virtual Machines) on a single powerful machine so that its resources are shared by each of these VMs. To scale horizontally then, one just keeps on adding more hardware and keeps on spinning more VMs on them.
The above solution works well till the number of VMs is in thousands.
When the count of VMs goes beyond that, the cost of hardware becomes really high and so is its maintenance.
Besides, the cost of spinning a VMs is high and can take several minutes.
So if a service is designed to be elastic such that it adds machines based on demand, then it could
take quite sometime to add those VMs during high demand and could cause the website to appear slow while
new VMs provisioning is in progress.
Google faced this problem in the 2005 and its engineers came out with Control Groups (also called as cgroups or Process Containers) in 2007. CGroups is a feature in Linux kernel that limits and isolates the resource usage of a group of processes. With such isolation, processes in one group cannot affect those in the other. And since a limit is enforced on each group, processes in a single group cannot consume all the resources of a given machine unless explicitly so configured.
Control Groups vs VMs
Running an isolated group of processes is much less intensive than running a full blown VM.This becomes evident when you realize that unlike a VM, CGroups does not try to emulate the hardware layer for some OS running on them.
- A VM provides a virtual hardware-like API layer to the OS that runs on it.
Since the VM does not know what will run on it, it has to provide all the APIs of the hardware layer.
This is wasteful since the application running on it may use only a handful of those APIs
- The emulation of all these APIs adds time to the VM bring-up as well.
- Eventually, a VM has to interact with the underlying hardware for accessing memory, network etc.
So, the emulation API has a redirection that passes these commands to the underlying hardware.
This redirection consumes some time, however little.
- As seen in #1, since a VM is heavy, lot of hardware resources are wasted in trying to provide a common environment to all programs.
Imagine spinning a full-linux VM for an application whose only job is to do some number crunching or to deal with storage.
CGroups are free from the above problems and they can achieve better resource utilization by isolating their groups from each other. Hence CGroups are faster to bring up, faster for the processes that run in them (as the processes interact directly with the underlying hardware) and more groups can be run on a machine than VMs.
Downside of CGroups is that it runs only on Linux. So if you have to run them on Windows, you first need to install a VM running Linux and then install CGroups on the same.
Namespace Isolation
Namespace isolation is a feature in which groups of processes remain unaware of other groups' presence on the same machine. It was released in 2008.
Enter Docker
Docker makes use of CGroups and namespace isolation and allows creation of Docker images
A docker image is a collection of processes that are run in isolation by cgroups.
Roughly speaking, CGroups with Docker is equivalent to VirtualBox and Docker image is equivalent to the VM.
Just that Docker/CGroups does not provide a hardware-like API layer to any OS running on it.
It just makes sure that groups do not interfere with each other and stay within their allocated limits.
References:
- Containers' white-paper by Parallels
- CGroups at Wikipedia
- An in-depth explanation of linux namespaces
- LinuxContainers.org
Read full article from Docker - PrismoSkills
No comments:
Post a Comment