Editing Features
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 2: | Line 2: | ||
== OS Virtualization == | == OS Virtualization == | ||
− | From the point of view of applications and [[container]] users, each | + | From the point of view of applications and [[container]] users, each VE is an independent system. This independence is provided by a virtualization layer in the kernel of the host OS. Note that only a negligible part of the CPU resources is spent on virtualization (around 1-2%). The main features of the virtualization layer implemented in OpenVZ are the following: |
− | * A [[container]] | + | * A [[container]] looks and behaves like a regular Linux system. It has standard startup scripts; software from vendors can run inside a container without OpenVZ-specific modifications or adjustment; |
* A user can change any configuration file and install additional software; | * A user can change any configuration file and install additional software; | ||
− | * [[ | + | * [[Containers]]s are completely isolated from each other (file system, processes, Inter Process Communication (IPC), sysctl variables); |
* Processes belonging to a container are scheduled for execution on all available CPUs. Consequently, [[CT]]s are not bound to only one CPU and can use all available CPU power. | * Processes belonging to a container are scheduled for execution on all available CPUs. Consequently, [[CT]]s are not bound to only one CPU and can use all available CPU power. | ||
Line 53: | Line 53: | ||
=== User Beancounters === | === User Beancounters === | ||
− | [[User beancounters]] is a set of per-CT counters, limits, and guarantees. There is a set of about 20 parameters which are carefully chosen to cover all the aspects of CT operation, so no single | + | [[User beancounters]] is a set of per-CT counters, limits, and guarantees. There is a set of about 20 parameters which are carefully chosen to cover all the aspects of CT operation, so no single VE can abuse any resource which is limited for the whole node and thus do harm to another CTs. |
− | Resources accounted and controlled are mainly memory and various in-kernel objects such as IPC shared memory segments, network buffers etc. etc. Each resource can be seen from <code>/proc/user_beancounters</code> and has five values assiciated with it: current usage, maximum usage (for the lifetime of a container), barrier, limit, and fail counter. The meaning of barrier and limit is parameter-dependant; in short, those can be thought of as a soft limit and a hard limit. If any resource hits the limit, fail counter for it is increased, so CT administrator can see if something bad is happening by analyzing the output of <code>/proc/user_beancounters</code> in her | + | Resources accounted and controlled are mainly memory and various in-kernel objects such as IPC shared memory segments, network buffers etc. etc. Each resource can be seen from <code>/proc/user_beancounters</code> and has five values assiciated with it: current usage, maximum usage (for the lifetime of a container), barrier, limit, and fail counter. The meaning of barrier and limit is parameter-dependant; in short, those can be thought of as a soft limit and a hard limit. If any resource hits the limit, fail counter for it is increased, so CT administrator can see if something bad is happening by analyzing the output of <code>/proc/user_beancounters</code> in her VE. |
== Checkpointing and live migration == | == Checkpointing and live migration == | ||
Line 61: | Line 61: | ||
{{Main|Checkpointing and live migration}} | {{Main|Checkpointing and live migration}} | ||
− | A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. It allows to migrate a | + | A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. It allows to migrate a VE from one physical server to another without a need to shutdown/restart a container. The process is known as checkpointing: a CT is freezed and its whole state is saved to the file on disk. This file can then be transferred to another machine and a CT can be unfreezed (restored) there. The delay is about a few seconds, and it is not a downtime, just a delay. |
Since every piece of the container state, including opened network connections, is saved, from the user's perspective it looks like a delay in response: say, one database transaction takes a longer time than usual, when it continues as normal and user doesn't notice that his database is already running on the another machine. | Since every piece of the container state, including opened network connections, is saved, from the user's perspective it looks like a delay in response: say, one database transaction takes a longer time than usual, when it continues as normal and user doesn't notice that his database is already running on the another machine. | ||
− | That feature makes possible scenarios such as upgrading your server without any need to reboot it: if your database needs more memory or CPU resources, you just buy a newer better server and live migrate your container to it, then increase its limits. If you want to add more RAM to your server, you migrate all | + | That feature makes possible scenarios such as upgrading your server without any need to reboot it: if your database needs more memory or CPU resources, you just buy a newer better server and live migrate your container to it, then increase its limits. If you want to add more RAM to your server, you migrate all VEs to another one, shut it down, add memory, start it again and migrate all containers back. |
[[Category: Concepts]] | [[Category: Concepts]] | ||
[[Category: Technology]] | [[Category: Technology]] |