Containers-based systems (e.g., Docker, LXC, cgroups) and virtual machines (VMWare, Xen) both seek to bring the benefits of virtualization to the data center and developer workflow. They have considerable overlap in benefits. Although both do some kind of virtualization to enable better utilization of physical hardware, there are also some key differences. Containers do virtualization at the OS kernel-level. Hence isolation is limited to what the kernel can enforce. Containers do a lot of sharing of layers of file systems, courtesy of AuFS, which potentially makes better use of disk space and image space than virtual machines which commit the entire contents of a VM's disk to the disk image.
Perhaps one of the biggest differences is the matter of migration. Unlike virtual machines, containers do not save memory state when stopped. This is one of the key points of Docker's explanation of containers: although file system state is preserved, memory state is not. Hence, one cannot resume a container in the same sense as one would a virtual machine. This also means that when migrating containers, the best one can hope for is to be able to stop a container on machine A, migrate to machine B, and restart that container on machine B. The container will have to restart the app from the file system state. This isn't all that bad of course. If the app in question syncs with disk frequently enough and supports restarts from inconsistent disk states, the difference is merely a matter of time to recovery. But this depends on app support for recovery. In contrast, virtual machines can be suspended, inclusive of memory state. The VM image can then be migrated and resumed from the exact point where it left off without missing a beat. Of course, in practice, it did miss a few beats because of the raw time in takes to migrate the larger images of VMs (relative to containers) and to resume.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.