Editor: This is a guest post by Igor Seletskiy, CloudLinux Founder & CEO. CloudLinux is an OS designed specifically for shared hosting providers. They use the Passenger application server and they employ an interesting containerization technology called LVE, which takes on containers in a different way than Docker, Virtuozzo and LXC.

Lately, Docker is quickly gaining popularity. Container technology is one of the hottest trends in the tech market today, and most of us have heard of Virtuozzo or LXC containers. While LVE has been a prominent player in the hosting world, most people outside of this space haven’t heard much about this technology.

LVE stands for Lightweight Virtual Environments, a proprietary technology from CloudLinux. It is used to achieve resource isolation in multi-tenant applications. It uses the same cgroups mechanism on the kernel level, but in a different way.

Virtuozzo/LXC

Virtuozzo and LXC see a container as virtual server. It is still a server, with its own init and glibc, and a full stack of applications you might need. You would typically SSH into it afterward, and treat it as any other server. Cgroups are used to limit CPU/Memory for all processes within that virtual server. This type of containers have lower overhead as compared to hypervisor virtualization. However, the overhead is still quite high.

Docker vs Virtuozzo/LXC

Docker, on the other hand, thinks of containers as single applications, doing just one thing. By using a clever layering approach for filesystems, it is able to achieve increased density when running multiple copies of the same application, compared to running the same applications inside VZ/LXC containers. Because each container does one thing and one thing only, it is much easier to secure and maintain.

LVE

As I mentioned, LVE stands for Lightweight Virtual Environments, and is used to achieve resource isolation in multi-tenant applications. It is similar to the above container technologies. It uses the same cgroups mechanism on the kernel level, but in a different way. It contains a single tenant within the applications running on the server. It is widely used in shared hosting environments where you have a typical LAMP stack, but with hundreds or even thousands of users on the single server - each with their own website and all residing on a single Apache and MySQL server.

Shared hosting has been around for a long time, and powers a tremendous number of websites. Typically, shared hosting providers split a single server between hundreds of users, which allows them to offer website hosting at very low prices (often below $5/month). One of the main issues hosting providers have is “bad neighbor effect”. This is when a single customer, maliciously or not, uses up all the CPU or memory available on the server, causing slow downs or complete downtime for all other websites on the server. LVE prevents such issues. While rlimits would provide some control, they don’t work in the majority of cases. Far too often, they prevent things from running that should, but do not limit things that should be stopped.

LVE is a combination of cgroups that control the amount of CPU, IO, memory, and processes available in each user’s environment. It works as combination of kernel module, Apache module, MySQL plugin, and PAM plugin. Any Apache request (static, PHP, CGI, Python, Ruby) is handled per usual. Yet, it is “placed” in the LVE corresponding to the user on the fly, often multiple times per second.

Unlike Docker, Virtuozzo and LXC, which operate on the process level, LVE is able to operate on the thread level. This allows multithreaded servers such as Apache (with its 'worker' MPM) to take advantage of LVE without having to run a separate instance per LVE user. LVE's switching overhead is tiny: changing the LVE context thousands of times per second is not a problem.

The same takes place with MySQL queries: we put a MySQL thread used to serve the user’s query into LVE for that user. Once the SQL request is finished, the MySQL thread is released from that LVE. PAM is used to put SSH sessions and cron jobs for the end user into the same LVE as well.

As a result, each user has a corresponding LVE containing all the processes and threads used by the end user: controlled CPU, IO, and memory cgroups. This gives admins total control of the amount of resources each user receives.

The result is very low overhead from cgroups, yet much higher stability overall. Resource spikes initiated by individual tenants on the system are completely removed, and when you have thousands of tenants (and no way to control them), such spikes are common.

Conclusion

LVE vs Docker and Virtuozzo/LXC

LVE is quite different from Docker and Virtuozzo/LXC containers precisely because of its use cases. It has the highest density of the three solutions, but it is applicable only to specific use cases where multi-tenancy and resource isolations are needed within the individual application.

LVE was integrated into the Passenger application server supplied as part of CloudLinux OS, and allows hosting providers that offer Python and Ruby hosting on top of CloudLinux OS to limit resources of each individual user without having to run separate instances of initd, MySQL, and Apache for each customer.

About Igor and CloudLinux

CloudLinux is on a mission to make Linux secure, stable, and profitable, and Igor is at the helm of this undertaking. He is an accomplished technology guru and an innovator focusing on Linux, kernel development, and the hosting industry. Prior to founding CloudLinux, Igor pioneered the multi-server control panel H-Sphere and brought to market FreeVPS, a container-based virtualization product; CP+, a simple, single server control panel; WebShell; and SiteStudio.

Editor: Thank you very much Igor for contributing this blog post!