6,534
edits
Changes
io bandwidth limit is avail in openvz
* Namespaces
* Resource management
* Checkpointing/ live migration
== Namespaces ==
A namespace is an abstract environment created to hold a feature to limit the scope logical grouping of somethingunique identifiers or symbols (i.e. Here, names). An identifier defined in a namespace is associated with that namespace. The same identifier can be independently defined in multiple namespaces are used as containers building blocks. A simple care An example of a namespace is chroota directory on a file system. This allows two files with the same name to be stored on the same device as long as they are stored in different directories.
For OpenVZ, Linux kernel namespaces are used as containers building blocks. As an example of namespace usage, let's take a look at chroot.
[[Image:Chroot.png|right|400px]]
=== Chroot ===
Traditional UNIX <code>chroot()</code> system call is used to change the root of the file system of a calling process to a particular directory. That way it limits the scope of file system for the process, so it can only see and access a limited sub tree of files and directories.
Chroot is still used for application isolation(although, unlike container, it does not provide full isolation — an application can escape from chroot under certain circumstances). Chroot is also used by containers, so a container filesystem is just a directory on the host. Consequences are: * there is no need for a separate block device, hard drive partition or filesystem-in-a-file setup.* host system administrator can see all the containers' files* containers backup/restore is trivial* mass deployment is easy === Other namespaces === OpenVZ builds on a chroot idea and expands it to everything else that applications have. In other words, every API that kernel provides to applications is “namespaced”, making sure every container have its own isolated subset of a resource. Examples include: * '''File system namespace''': this one is <code>chroot()</code> itself, making sure containers can not see each other's files. * '''Process ID namespace''': this is so that every container processes has its own unique process IDs, and the first process inside a container has a PID of 1 (it is usually <code>/sbin/init</code> process which actually relies on its PID to be 1). For every process in container, its PID in container is different from the one at host. Containers can only see their own processes, and they can't see (or access in any way, like sending signals) processes in other containers. * '''IPC namespace''': this is so that every container has its own System V IPC (Inter-Process Communication) shared memory segments, semaphores, and messages. For example, <code>ipcs</code> output is different in every container. * '''Networking namespace''': this is so that every container has its own network devices, IP addresses, routing rules, firewall (iptables) rules, network caches and so on. See more details below at [[#Networking]]. * '''<code>/proc</code> and <code>/sys</code> namespaces''': this is so that every container to have its own representation of <code>/proc</code> and <code>/sys</code> — special filesystems used to export some kernel information to applications. In a nutshell, those are subsets of what a physical Linux host system have. * '''UTS namespace''': this is so that every container can have its own hostname. * and so on. Note that memory and CPU need not be namespaced: existing virtual memory and multitask mechanisms address this. [[Image:CTs.svg|400px|right]]=== Single kernel approach === To put it simply, a container is a sum of all its namespaces. Therefore, there is only one single OS kernel running, on top of it there are multiple isolated containers, sharing that single kernel. Single kernel approach is much more light-weight than traditional VM-style virtualization (for more differences between CT and VM, see [[../Containers vs VMs/]]). The consequences of having only one kernel are: # A container can only run the same OS as the host, i.e. Linux in case of OpenVZ. Nevertheless, multiple different Linux distributions can be used in different containers. For example, RHEL4, RHEL5, RHEL6, Fedora 14 and Ubuntu 10.10 can run inside different containers on the same host system (running ftpd e.g. Gentoo).# Waiving the need to run multiple OS kernels leads to '''higher density''' of containers (compared to VMs). Practically that means that a few hundreds of typical containers can be started on a conventional notebook.# Software stack that lies in between the hardware and an end-user application is as thin as in usual non-virtualized system (see the image), this means native performance of containers and no virtualization overhead (compared to VMs). See more at [[#Performance and density]] below. == Resource management == Due to a single kernel model used, there is one single entity which controls all of the resources: the kernel.All the containers share the same set of resources: CPU, memory, disk and network. All theseresources needs to be controlled on a per-container basis, for the containers to notstep on each other's toes. All such resources are accounted for and controlled by the kernel. It is important to understand that resources are not pre-allocated, they are just limited. That means:* all the resources can be changed dynamically (run-time);* if a resource is not used, it is available for other containers, which makes resource overcommitting easy. === CPU === Kernel CPU scheduler is modified to be containers-aware. When it's time for a context switch, scheduler selects a process to give a CPU time slice to. A traditional scheduler just chooses one among all the runnable tasks in the system. OpenVZ scheduler implements two-level schema: it chooses a container first, then it chooses a chroot task inside the container. That way, all the containers get a fair share of CPU resources (with no regard to number of processes inside each container). The following CPU scheduler settings are available per container: * '''CPU units''': a proportional "weight" of a container. The more units a container has, the more CPU it will get. Assuming we have 2 containers with equal CPU units, when both containers want CPU time (e.g. by running busy loops), each one will get 50%. In case we will double CPU units of one container, it will have two times more CPU (i.e. 66%, while another will take 33%). Note however that if other containers are idle, a single container can have as much as 100% of available CPU time. * '''CPU limit''': a hard limit on a share of CPU time. For example, if we set it to 50%, a container will not be able to use more than 50% of CPU time even if CPU will be idle otherwise. By default, this limit is not set, i.e. a single container can have as much as 100% of available CPU time. * '''CPU mask''': tells the kernel the exact CPUs that can be used to run this container on. This can also be used as a CPU limiting factor, and helps performance on a non-uniform memory (NUMA) systems. * '''VCPU affinity''': tells the kernel a maximum number of CPUs a container can use. The difference from the previous option is you are not able to specify the exact CPUs, only the number of those, and then the kernel dynamically assigns / adjusts CPUs between containers based on current load. === Disk === * '''Disk space'''. In a default setup, all containers reside on the same hard drive partition (since a container is just a subdirectory). OpenVZ introduces a per-container disk space limit to control disk usage. So, to increase the disk space available to a container, one just needs to increase that limit -- dynamically, on the fly, without a need to resize a partition or a filesystem. * '''Disk I/O priority'''. Containers compete for I/O operations, and can affect each other if they use the same disk drive. OpenVZ introduces a per-container I/O priority, which can be used to e.g. decrease the "bad guy" I/O rate in order to avoid not trash the other containers. * '''Disk I/O bandwidth'''. I/O bandwidth (in bytes per second) can be limited per-container. === Memory === All the containers share the same physical memory and swap space, and other similar resources like a potential security breachpage cache. All that memory is managed by a single kernel, thus making memory distribution model very elastic — if memory is not used by one container, it can be used by another.
[[Image:CT-networking.png|right]]== File system = Networking ===
== OpenVZ host system scope == Route-based (venet) ====
The major features of this setup are:* '''FIXME link Host system acts as a bridge'''* '''High configurability''': container administrator can setup all the networking.* '''Ability to resource management whitepaper goes hereuse broadcasts/multicasts'''.* '''DHCP''' and dynamic IP addresses are possible* Broadcasting have negative performance impact (it is delivered separately to each CT)
== Networking (routed/bridged) == Real network device in a container ====
=== Performance and density ===* Live migrationSee [[Performance]]* Density: {{FIXME|add graphs}}
=== Limitations ===
From the point of view of a container owner, it looks and feels like a real system. Nevertheless, it is important to understand what are container limitations:
* Container is constrained by limits set by host system administrator. That includes usage of CPU, memory, disk space and bandwidth, network bandwidth etc.t * Container OpenVZ container only runs Linux (Windows or FreeBSD is not an option), although different distributions is not an issuerun perfectly .
* Container can't boot/use its own kernel (it uses host system kernel).
* Container can't load its own kernel modules (it uses host system kernel modules).
* Container By default, container can't set system time. Such permission should be explicitly granted by host system administrator. * By default, unless explicitly configured container does not have direct access to do so hardware such as hard drive, network card, or a PCI device. Such access can be granted by host system administrator if needed. === OpenVZ host system scope === From the host system, all containers processes are visible, and all the container files are accessible (say under <code>/vz/root/$CTID</code>). Host system administrator can set containers' parameters, access all containers files, send signals to run containers processes etc. Containers mass-management is easy with some shell scripting and commands like <code>ntpdexec</code> in and <code>enter</code>. For example, to add a CT).user jack to all running containers the following command can be used: