Editing Use cases
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 1: | Line 1: | ||
+ | {{stub}} | ||
− | + | OpenVZ has a number of unique features that can be effectively used in the following scenarios: | |
− | |||
− | |||
− | == | + | == Improved security == |
− | + | Consider a Linux server used to serve mail, web site, and DNS. There are at least three different applications listening to and handling network requests, and any of them can contain security holes. Using OpenVZ, a server can be divided into three [[container]]s, one for each application. Thus, if the DNS server is compromised, the other applications will still be left intact due to complete isolation between containers. | |
− | |||
− | |||
− | |||
− | the | ||
− | |||
− | |||
− | |||
− | |||
− | == | + | == Server consolidation == |
+ | |||
+ | Having a separate physical server for each application is generally a good approach, it increases availability and improves security. However, separate servers lead to increased costs of hardware and collocation, and modern hardware is often underutilized in this scenario. | ||
+ | |||
+ | With OpenVZ, you can enjoy the benefits of dedicated server without such drawbacks. Create a container for each application and use the existing hardware more efficiently. This approach can be deployed totally transparently to users using OpenVZ. | ||
− | + | == Development and testing == | |
− | |||
− | |||
− | |||
− | |||
− | + | Developers often need access to several different Linux distributions to develop an application. Testing also needs to be performed on various software configurations. Therefore, testing and development groups often require a lot of hardware. | |
− | + | Alternatively, using OpenVZ developers and QAs can create multiple partitions with different Linux distributions and configurations residing on one physical server. Each container can have its own set of packages, system libraries, configuration files. You can do snapshots and rollbacks. | |
− | |||
− | |||
== Hosting == | == Hosting == | ||
Line 37: | Line 26: | ||
* Much easier to administer | * Much easier to administer | ||
− | == | + | == Educational == |
− | + | With OpenVZ, a separate container can be created for every student. Thus, each student gets their own root account and can do everything on their own server, e.g. experiment with firewall configuration rules (iptables). | |
− | + | == Easy maintenance == | |
− | |||
− | |||
+ | Consider a Linux server used to serve a bunch of services. You will have downtime for each service during OS update or setup failover cluster for each service to decrease downtime. Using OpenVZ, a server can be divided into several [[container]]s, one for each service. With [[Checkpointing and live migration|live migration]] available for [[container]]s you can migrate your services to another service and return them back after upgrading server. | ||
== See also == | == See also == | ||
* [[Success stories]] | * [[Success stories]] | ||
− |