One of the unsung advantages of LXC and OpenVZ, is that the disk cache is unified.
Full virtualization like KVM or VMWare, require you to give each VM extra RAM for use with disk cache. For instance, if you had a typical set of processes that used 1.5GB, and you gave it 1.7GB, that would hardly be enough, as you want more than 200MB of disk cache.
Under LXC and OpenVZ, any unused RAM becomes globally available for disk caching, giving a decent performance boost and further reducing the resouce commitments per-VM.
One example: a customer had some lousy queries in their SQL, but they really needed to have a good demo of their site. We moved them to a 32GB RAM system and gave the container 8GB.
As a result, nearly the entire 20GB database (or at least the parts that were needed), got loaded into the disk cache after the first batch of queries were run. It was enough to get them over the hump (they later figured out the nasty SQL that was getting them in trouble) and they had a good demo. After that, we live-migrated back to their regular server.
I get the flexibility that gives you, but in that instance you've evidently got a 32GB machine sitting there, unused. For my money it's just as valid to move their guest to the 32GB machine, balloon up to allocate the space and allow the guest to use the extra space as disc cache as required, then balloon down afterwards and migrate off as normal.
Does anyone have any good resources on how Linux LXC compares to BSD Jails from a security perspective? I've long been a fan of BSD jails because of how simple the security model is to understand, and how secure they've been in practice. Jail has long been a killer feature for BSD and very, very good reason to use a BSD-derivative for web servers, etc. as you can run each and every service that has the potential to be compromised in its own jail to minimize the overall risk; whereas the best Linux had to offer has traditionally been a chroot'd environment, which while good, has absolutely nothing on a BSD jail.
I'd imagine that LXC has the potential to change that, though I presume it'll take some time for a) adoption to increase and b) for it to prove itself after that.
LXC is just a set of script/interface to Linux's namespaces.
Namespaces is what is actually used. There are disk namespaces, network, pid, etc. Those are not very widely tested albeit supposed to be relatively secure.
FreeBSD jail provides a all-in-one integration instead. LXC provides the glue to achieve similar integration.
There is also rsbac_jail which provides an integration more similar to what FreeBSD does.
The major issue with LXC so far has been that it's not well integrated/easy to use.
LXC is OS-level virtualization (similar to openvz and plain old chroot), which has a much lower overhead compared to full virtualization (i.e. virtualbox, kvm, xen hvm) but requires that the guest share the host's kernel. You get easier setup (untar the filesystem and tweak a few config settings) with stuff like LXC, but you obviously cannot run Windows/*BSD/whatever.
> What does this technology let me do that I can't do with stuff like virtualbox?
Fit more containers on your host :)
Share (disk and memory) resources among your containers
Make the same partition/directory/files available to a few containers at the same time without using ssh/nfs/smb/etc
VMs each have their own kernel, but containers share the host kernel. This tends to be more efficient and doesn't require you to statically allocate vCPUs and vRAM upfront when you create a container.
LXC also has an under-appreciated mode where you can run some processes (but not a full OS) in a container.
For some context, I believe many/most people doing PAAS (e.g. Heroku, DotCloud, Cloudbees, Node*) are using LXC to create slices/dynos/shards/whatever.
Correct. DotCloud started using LXC in May 2010. Before that it used OpenVZ in 2009 (http://openvz.org), and even before that it used VServer (http://linux-vserver.org) in 2008. Back then the notion of stacking 2 types of virtualization was incredibly weird and remote.
In the 2nd half of 2011 other PaaS players caught on to the wonders of container virtualization - Heroku for example started using it with their Cedar stack in April of last year.
Linux containers are a fantastic development tool and ready for production prime time. BSD has long had really good jails and having implemented this now for (development) purposes for cnx.org I can recommend them.
It's also great to partition a large machine into smaller ones. Containers are not yet completely isolated from each other, but, if you own all the containers, it's a perfectly good solution and more flexible than virtualized hardware.
If you plan on separating your app and database servers to different machines, doing so from the start may be a clever idea.
[+] [-] patrickgzill|14 years ago|reply
Full virtualization like KVM or VMWare, require you to give each VM extra RAM for use with disk cache. For instance, if you had a typical set of processes that used 1.5GB, and you gave it 1.7GB, that would hardly be enough, as you want more than 200MB of disk cache.
Under LXC and OpenVZ, any unused RAM becomes globally available for disk caching, giving a decent performance boost and further reducing the resouce commitments per-VM.
One example: a customer had some lousy queries in their SQL, but they really needed to have a good demo of their site. We moved them to a 32GB RAM system and gave the container 8GB.
As a result, nearly the entire 20GB database (or at least the parts that were needed), got loaded into the disk cache after the first batch of queries were run. It was enough to get them over the hump (they later figured out the nasty SQL that was getting them in trouble) and they had a good demo. After that, we live-migrated back to their regular server.
[+] [-] regularfry|14 years ago|reply
[+] [-] ComputerGuru|14 years ago|reply
I'd imagine that LXC has the potential to change that, though I presume it'll take some time for a) adoption to increase and b) for it to prove itself after that.
[+] [-] zobzu|14 years ago|reply
Namespaces is what is actually used. There are disk namespaces, network, pid, etc. Those are not very widely tested albeit supposed to be relatively secure.
FreeBSD jail provides a all-in-one integration instead. LXC provides the glue to achieve similar integration.
There is also rsbac_jail which provides an integration more similar to what FreeBSD does.
The major issue with LXC so far has been that it's not well integrated/easy to use.
[+] [-] Splines|14 years ago|reply
[+] [-] inportb|14 years ago|reply
> What does this technology let me do that I can't do with stuff like virtualbox?
Fit more containers on your host :)
Share (disk and memory) resources among your containers
Make the same partition/directory/files available to a few containers at the same time without using ssh/nfs/smb/etc
... and so on.
[+] [-] wmf|14 years ago|reply
LXC also has an under-appreciated mode where you can run some processes (but not a full OS) in a container.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] fizx|14 years ago|reply
[+] [-] shykes|14 years ago|reply
In the 2nd half of 2011 other PaaS players caught on to the wonders of container virtualization - Heroku for example started using it with their Cedar stack in April of last year.
[+] [-] daemon13|14 years ago|reply
- Is LXC friendly with IDS/IPS and alike?
- If I place a webserver or a database in a container - what would be the implications in terms of set-up?
- Networking? How it would interact with iptables? iptables only on host, or it is possible to set-up separate iptables in each container?
- How logging is dealt with?
- Can system user sitting in the container escalate to root?
I am looking for a solution to further harden the set of VPSs for a web site/app.
Is LXC a good fit for that? Or smth else might be a better fit?
thank you
P.S.: my CFO experience can not help me here :-(
[+] [-] zdw|14 years ago|reply
They sound quite similar in concept/execution.
[+] [-] lifeisstillgood|14 years ago|reply
[+] [-] rbanffy|14 years ago|reply
If you plan on separating your app and database servers to different machines, doing so from the start may be a clever idea.
[+] [-] lumberjack|14 years ago|reply
[+] [-] ichilton|14 years ago|reply
[+] [-] raphinou|14 years ago|reply