Difference between revisions of "Usage Scenarios"

From Linux-VServer

Jump to: navigation, search
 
(+{{Languages|Usage Scenarios}})
 
(17 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 +
{{Languages|Usage Scenarios}}
 +
 
For many people, virtual server may look like a great toy: Very high geekness factor. It looks cool, but probably not for everyone. '''Wrong!'''
 
For many people, virtual server may look like a great toy: Very high geekness factor. It looks cool, but probably not for everyone. '''Wrong!'''
  
−
== Usage scenarios ==
+
The primary goal of this project is to create virtual servers sharing the same machine. A virtual server operates like a normal Linux server. It runs normal services such as ssh, mail, web and database servers.
  
−
=== Consolidation and Seperation ===
+
== Consolidation and Separation ==
  
−
As the hardware evolves, it is tempting to put more and more tasks on a server. Linux can handle it. Linux is reliable and so on. At some point, you end up with so much stuff and so many people fiddling in the same box that you worry about updating things.
+
As the hardware evolves, it is tempting to put more and more tasks on a server. Though Linux could reliably handle it, at some point, you will end up with too much stuff and people fiddling in the same box that you worry about updating things. Additionally, separating different or similar services which otherwise would interfere with each other, either because they are poorly designed or because they are simply incapable of peaceful coexistence for whatever reason, may often be complex or even impossible.
  
−
Vservers address this. The same box runs multiple vservers and each one does the job it is supposed to do. If you need to upgrade to php5 for a given project you do so and only tha project is affected.
+
The Linux-VServer project addresses this issue. The same box is able to run multiple virtual servers and each one does the job it is supposed to do. If you need to upgrade to PHP 5 for a given project, you can do so, and only that one project is affected.
  
−
Also, you can give the root password of a vserver to one administrator and he will be able to perform updates, restart services and so on without having to know about every other project hosted on a server.
+
Also, you can give the root password of a virtual server to an administrator for that virtual server and he/she will be able to perform updates, restart services and so on without having to know about every other project hosted on the same server. This allows a clever provider to sell Virtual Private Servers, which uses less resources than other virtualization techniques, which in turn allows to put more units on a single machine.  
  
−
=== Resource Independance ===
+
The list of providers doing so is relatively long, and so this is rightfully considered the main area of application. See [[VServer Hosting]] for a (probably incomplete) list of companies providing Virtual Private Servers based on the Linux-VServer technology.
  
−
Since vservers are only guests on the hardware they are using, they are not aware of the specifics: They do not contain disk configurations, kernels or network configurations.
+
== Enhancing Security ==
  
−
Once you have found that a project is using more resource than expected, you can move it to another box without having to fiddle here and there. A vserver is just a directory inside the host server. You tar it and copy it to another box and restart it there.
+
While it can be interesting to run several virtual servers in one box, there is one concept potentially more generally useful. Imagine a physical server running a single virtual server. The goal is isolate the main environment from any service, any network. You boot in the main environment, start very few services and then continue in the virtual server.
  
−
An administrator can move vservers around without his users knowing what he does.
+
The service in the main environment would be:
  
−
=== Experimenting and Upgrading ===
+
* Unreachable from the network.
 +
* Able to log messages from the virtual server in a secure way. The virtual server would be unable to change/erase the logs. Even a cracked virtual server would not be able to edit the log.
 +
* Able to run intrusion detection facilities, potentially spying the state of the virtual server without being accessible or noticed. For example, tripwire could run there and it would be impossible to circumvent its operation or trick it.
  
−
You have this typical problem. You intend to upgrade a site either with new package (new PHP5) or new features (new version of the Web applications). After having tested all this on the development machine, you are ready to update the production server. Having some experience you do it properly
+
Another option is to put the firewall in a virtual server, and pull in the DMZ, containing each service in a separate VPS. On proper configuration, this setup can reduce the number of required machines drastically, without impacting performance.
  
−
* First a good backup of the server
+
== Resource Independence ==
−
* Then you perform all the upgrades and install the new applications
+
−
* Fire: the new server is online and kicking.
+
−
* 2 hours later, you realise that something does not work as expected.
+
−
* To make it worse, it works fine on the development machine.
+
−
* Now it is 2 am and this has to work by 8am. Hum.
+
  
−
We have all experienced this. Another solution to this problem would be to install the new production server on new hardware, but this is not as easy, as you have to clone the first server (most people are not confortable doing this) or you do not have the hardware.
+
Since virtual servers are only guests on the hardware they are using, they are not aware of the specifics: they do not contain disk configurations, kernels or network configurations.
  
−
Using vserver, all this is very easy
+
One key feature of a virtual server is the independence from the actual hardware. Most hardware issues are irrelevant for a virtual server installation.
  
−
* You stop the production vserver
+
The main server acts as a host and takes care of all the details. The virtual server is just a client and ignores all the details. As such, the client can be moved to another physical server with very few manipulations.
−
* You clone it (Cloning a vserver takes 1 minute unless it has a lot of data).
+
−
* You perform the upgrades in the new vserver and give it life.
+
  
−
Later you find it does not work as expected and you can't immediately fix it.
+
For example, to move the virtual server from one physical computer to another, it sufficient to do the following:
  
−
* You turn off the new vserver and assign it a new IP number.
+
* shutdown the running server
−
* You start both the old and new. Now the old is still online and you can fiddle with the new (on a different IP address) to fix the problem.
+
* copy it over to the other machine
 +
* copy the configuration
 +
* start the virtual server on the new machine
  
−
=== Development  and Testing ===
+
No adjustments to user setup, password database or hardware configuration are required, as long as both machines are binary compatible.
  
−
You are working on a new project. At this point you have no idea of the resources it will need (load). In general, you have a meeting and make a decision about the new hardware. But in this case we have no idea. So instead, we put the new project on a vserver on the first available linux box, including the workstation of the developer. And we develop. Once the thing is ready, we clone the vserver on some production server and give it a go.
+
Thus, once you have found that a project is using more resource than expected, you can easily move it to another box without tinkering around in hardware configuration files. A virtual server is just a directory on the filesystem of host system.
  
−
Later once we know how popular the new service is, we can move it again to a more powerful server, as needed, without any fiddling (moving accounts, installing packages, and so on)
+
== Fail-over Scenarios ==
  
−
As a good example, Herbert has 33 vservers on his notebook allowing him to test various projects and various distributions from rh6.2 to FC3 and Debian.
+
Pushing the limit a little further, replication technology could be used to keep an up-to-the-minute copy of the filesystem of a running virtual server. This would permit a very fast [[fail-over]] if the running server goes offline for whatever reason.  
  
−
=== Distribution Independence ===
+
All the known methods to accomplish this, starting with network replication via rsync, or drbd, via network devices, or shared disk arrays, to distributed filesystems, can be utilized to reduce the down-time and improve overall efficiency.
  
−
We are often talking about our preferred distribution. Should we use FC, Debian or something else ? Should we give a spin to the latest and greatest ?
+
== Experimenting and Upgrading ==
  
−
With vservers, the choice of a distribution is less important. When you select a distribution, you expect it will do the following
+
If you intend to upgrade a system to get new features or security updates, you probably first test the new packages on the development machine, before you are ready to update the production server. Having some experience you do it properly:
 +
 
 +
* Doing a backup of the server
 +
* Perform all the upgrades and install the new applications
 +
 
 +
Two hours later you realise that something does not work as expected. To make it worse, it works fine on the development machine. We have all experienced this.
 +
 
 +
Another solution to this problem would be to install the new production server on new hardware, but this is not as easy, as you have to clone the first server (most people are not comfortable doing this) or you do not have the hardware.
 +
 
 +
Using virtual servers, all this is very easy:
 +
 
 +
* Stop the virtual server in production
 +
* Make a copy of the virtual server
 +
* Perform the upgrades in the new virtual server
 +
 
 +
To get back to our example above, two hours later you realise that something does not work as expected and you cannot immediately fix it.
 +
 
 +
Again, using virtual servers, the (temporary) solution to this problem is very easy:
 +
 
 +
* Stop the new virtual server and assign it a new IP address
 +
* Start both the old and new virtual server
 +
 
 +
Now the old one is still online and you can track down the issues on your new virtual server using a different IP address, fix the problem and reassign the old IP address to the new virtual server.
 +
 
 +
 
 +
 
 +
== Distribution Independence ==
 +
 
 +
People are often talking about their preferred distribution. Should one use Fedora, Debian or something else? Should one give a spin to the latest and greatest distribution just for the sake of it?
 +
 
 +
With virtual servers, the choice of a distribution is less important. When you select a distribution, you expect it will do the following:
  
 
* Good hardware support/detection
 
* Good hardware support/detection
Line 62: Line 91:
 
* Reliable packages
 
* Reliable packages
  
−
The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. But they have flaws. For example, a distribution - say XXX - is great but is not delivering the latest and greatest PHP. Now because you have decided to use XXX for some projects, it does not prevent you from using XXY for other projects. So instead of moving to XXY for everything, you move to it as you see fit, project per project.
+
The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. Still each one has its peculiarities and probably flaws. For example, one distribution is doing a great job on security but is not delivering the latest and greatest PHP. Now because you have decided to use this distribution for some projects, using virtual servers does not prevent you from using another distribution for other projects or even a second virtual server for existing projects.
  
 
== Other considerations ==
 
== Other considerations ==
  
−
* '''Virtual Private Servers are running on the same kernel as the host:''' Unlike other VM solutions, vservers don't require additional memory or processing power.
+
* '''Virtual Private Servers are running on the same kernel as the host:''' Unlike other VM solutions, Linux-VServer does not require additional memory or processing power, in fact it may even reduce used memory due to the fact that multiple virtual servers may share the same files.
  
−
* '''There are no special daemons running:''' A vserver running crond, sshd, httpd and sendmail uses the same resources as a normal Linux server running these services.  
+
* '''There are no special daemons running:''' A VPS running crond, sshd, httpd and sendmail uses the same resources as a normal Linux server running these services.
  
−
* '''No pre-allocated disk space needed:''' Vservers generally share the disk space with the host, so there is no need to pre-allocate disk space for each vserver only to find out later that your disk is full, yet each vserver is only using of tiny portion of their allocated space.  
+
* '''No pre-allocated disk space needed:''' A VPS generally shares the disk space with the host system, so there is no need to pre-allocate disk space for each virtual server to find out later that your disk is full, yet each VPS is using only a tiny portion of their allocated space.
  
−
* '''Resource sharing:''' Since vservers can share binaries and libraries without interfering, a second vserver generally cost 40-100 megs of disk space only. Most of this space is a copy of the packaging database.  
+
* '''Resource sharing:''' Since virtual servers can share binaries and libraries without interfering, a second VPS generally costs about 40-100MB of disk space only. Most of this space is a copy of the packaging database.
  
−
* '''Independent updates:''' Vservers are updated independently even if they share binaries with other vservers.
+
* '''32-/64-bit independence:''' You can easily run a 32-bit distribution inside a VPS on a 64-bit host system, but faster, sometimes a lot.
−
 
+
−
* '''32-/64-bit independence:''' 32-bit distribution vservers run normally on a 64-bit linux host, but faster, sometimes a lot.  
+
  
 
* '''Admin tools work inside a vserver as usual''': A vserver feels like a real server from within and can be used in the same ways.
 
* '''Admin tools work inside a vserver as usual''': A vserver feels like a real server from within and can be used in the same ways.
−
 
−
* '''A cracked vserver can't reach the host server:''' The host server may be used to safely investigate the cracked server (and fix it), something almost impossible with a typical linux installation.
 
  
 
== See Also ==
 
== See Also ==
  
 
* [[Overview]]
 
* [[Overview]]
 +
 +
[[Category:Documentation]]
 +
[[Category:Community]]
 +
[[Category:Categories]]

Latest revision as of 22:56, 21 October 2011

English •  Deutsch •  español •  français • 


For many people, virtual server may look like a great toy: Very high geekness factor. It looks cool, but probably not for everyone. Wrong!

The primary goal of this project is to create virtual servers sharing the same machine. A virtual server operates like a normal Linux server. It runs normal services such as ssh, mail, web and database servers.

Contents

[edit] Consolidation and Separation

As the hardware evolves, it is tempting to put more and more tasks on a server. Though Linux could reliably handle it, at some point, you will end up with too much stuff and people fiddling in the same box that you worry about updating things. Additionally, separating different or similar services which otherwise would interfere with each other, either because they are poorly designed or because they are simply incapable of peaceful coexistence for whatever reason, may often be complex or even impossible.

The Linux-VServer project addresses this issue. The same box is able to run multiple virtual servers and each one does the job it is supposed to do. If you need to upgrade to PHP 5 for a given project, you can do so, and only that one project is affected.

Also, you can give the root password of a virtual server to an administrator for that virtual server and he/she will be able to perform updates, restart services and so on without having to know about every other project hosted on the same server. This allows a clever provider to sell Virtual Private Servers, which uses less resources than other virtualization techniques, which in turn allows to put more units on a single machine.

The list of providers doing so is relatively long, and so this is rightfully considered the main area of application. See VServer Hosting for a (probably incomplete) list of companies providing Virtual Private Servers based on the Linux-VServer technology.

[edit] Enhancing Security

While it can be interesting to run several virtual servers in one box, there is one concept potentially more generally useful. Imagine a physical server running a single virtual server. The goal is isolate the main environment from any service, any network. You boot in the main environment, start very few services and then continue in the virtual server.

The service in the main environment would be:

  • Unreachable from the network.
  • Able to log messages from the virtual server in a secure way. The virtual server would be unable to change/erase the logs. Even a cracked virtual server would not be able to edit the log.
  • Able to run intrusion detection facilities, potentially spying the state of the virtual server without being accessible or noticed. For example, tripwire could run there and it would be impossible to circumvent its operation or trick it.

Another option is to put the firewall in a virtual server, and pull in the DMZ, containing each service in a separate VPS. On proper configuration, this setup can reduce the number of required machines drastically, without impacting performance.

[edit] Resource Independence

Since virtual servers are only guests on the hardware they are using, they are not aware of the specifics: they do not contain disk configurations, kernels or network configurations.

One key feature of a virtual server is the independence from the actual hardware. Most hardware issues are irrelevant for a virtual server installation.

The main server acts as a host and takes care of all the details. The virtual server is just a client and ignores all the details. As such, the client can be moved to another physical server with very few manipulations.

For example, to move the virtual server from one physical computer to another, it sufficient to do the following:

  • shutdown the running server
  • copy it over to the other machine
  • copy the configuration
  • start the virtual server on the new machine

No adjustments to user setup, password database or hardware configuration are required, as long as both machines are binary compatible.

Thus, once you have found that a project is using more resource than expected, you can easily move it to another box without tinkering around in hardware configuration files. A virtual server is just a directory on the filesystem of host system.

[edit] Fail-over Scenarios

Pushing the limit a little further, replication technology could be used to keep an up-to-the-minute copy of the filesystem of a running virtual server. This would permit a very fast fail-over if the running server goes offline for whatever reason.

All the known methods to accomplish this, starting with network replication via rsync, or drbd, via network devices, or shared disk arrays, to distributed filesystems, can be utilized to reduce the down-time and improve overall efficiency.

[edit] Experimenting and Upgrading

If you intend to upgrade a system to get new features or security updates, you probably first test the new packages on the development machine, before you are ready to update the production server. Having some experience you do it properly:

  • Doing a backup of the server
  • Perform all the upgrades and install the new applications

Two hours later you realise that something does not work as expected. To make it worse, it works fine on the development machine. We have all experienced this.

Another solution to this problem would be to install the new production server on new hardware, but this is not as easy, as you have to clone the first server (most people are not comfortable doing this) or you do not have the hardware.

Using virtual servers, all this is very easy:

  • Stop the virtual server in production
  • Make a copy of the virtual server
  • Perform the upgrades in the new virtual server

To get back to our example above, two hours later you realise that something does not work as expected and you cannot immediately fix it.

Again, using virtual servers, the (temporary) solution to this problem is very easy:

  • Stop the new virtual server and assign it a new IP address
  • Start both the old and new virtual server

Now the old one is still online and you can track down the issues on your new virtual server using a different IP address, fix the problem and reassign the old IP address to the new virtual server.


[edit] Distribution Independence

People are often talking about their preferred distribution. Should one use Fedora, Debian or something else? Should one give a spin to the latest and greatest distribution just for the sake of it?

With virtual servers, the choice of a distribution is less important. When you select a distribution, you expect it will do the following:

  • Good hardware support/detection
  • Good package technology/updates
  • Good package selection
  • Reliable packages

The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. Still each one has its peculiarities and probably flaws. For example, one distribution is doing a great job on security but is not delivering the latest and greatest PHP. Now because you have decided to use this distribution for some projects, using virtual servers does not prevent you from using another distribution for other projects or even a second virtual server for existing projects.

[edit] Other considerations

  • Virtual Private Servers are running on the same kernel as the host: Unlike other VM solutions, Linux-VServer does not require additional memory or processing power, in fact it may even reduce used memory due to the fact that multiple virtual servers may share the same files.
  • There are no special daemons running: A VPS running crond, sshd, httpd and sendmail uses the same resources as a normal Linux server running these services.
  • No pre-allocated disk space needed: A VPS generally shares the disk space with the host system, so there is no need to pre-allocate disk space for each virtual server to find out later that your disk is full, yet each VPS is using only a tiny portion of their allocated space.
  • Resource sharing: Since virtual servers can share binaries and libraries without interfering, a second VPS generally costs about 40-100MB of disk space only. Most of this space is a copy of the packaging database.
  • 32-/64-bit independence: You can easily run a 32-bit distribution inside a VPS on a 64-bit host system, but faster, sometimes a lot.
  • Admin tools work inside a vserver as usual: A vserver feels like a real server from within and can be used in the same ways.

[edit] See Also

Retrieved from "http://linux-vserver.org/index.php?title=Usage_Scenarios&oldid=5070"
Personal tools