Subject: Re: [vserver] Pros and Cons of 32/64bit guests on 64bit host
From: Ed W <lists@wildgooses.com>
Date: Fri, 22 Aug 2008 14:49:34 +0100


> If I have 4 virtual machines running on the same box simultaneously I
> need 4 times the resources calculated on each virtual machine running
> on its own box.  

*ish*...

I have a small box here running as the office server which has 10-20 
vserver instances on because instead of the old server which had Apache 
+ Mysql + Samba, etc in the new setup I have a vserver doing samba, 
another doing apache, another doing mysql, etc.  This is running idle on 
a quad Intel thing with 4G ram (couple hundred quid or so)

The nice thing is that now if I want to shift mysql to a new machine I 
just migrate the vserver instance across and change the IP.  If I want a 
new website then I can clone the apache instance and have both sites 
running physically separated from each other.  etc


> It sounds wonderful hundreds of guests running on one powerful PC. 
> I'll run them as daemons.
>   

Exactly - so it's so lightweight you can almost run every service in 
it's own vserver.  This is great for testing upgrades because you can 
clone the vserver, run the upgrade, see if anything broke and then 
upgrade the live instance!  Cool!

> I have following 2 thoughts to consider.
>
> 1)
> If the PC is down because of hardware failure then hundreds of server
> will be down.  It needs a well established replication and load
> balancing.
>   

Sure - But equally it's only one physical bit of hardware to maintain 
now - keep an identical spare running with some way to clone the hard 
disks and you already have a pretty robust installation which is likely 
to be down less than 100 individual machines

There are some hot replication strategies to keep a duplicate set of 
hardware going, eg drbd , or a SAN.  Alternatively you can accept some 
lost data and use async strategies such as a snapshot every XX minutes 
(use LVM to assist with this).

One tip is that I keep the OS separate from the vserver data (eg apache 
OS instance separate from /var/www data).  This makes it easy to clone 
the data on one schedule and the OS on another schedule

I can't stress how simple vservers make backups!  You have one small 
100-200MB or so host OS which is generic and clean, then you have a 
bunch of vserver instances which are basically directories that you can 
just backup using tar.  Incredibly easy to shuffle them around, boot 
them on a new physical server, clone them to test config changes, etc!

> 2)
> It needs a range of fixed/public IP address serving hundreds of server
> on the Virtual box.  I'm investing whether there will be a way to
> overcome this difficulty.  Each server has its own hostname and domain.
>  If hundreds of domain pointing to one fixed/public IP address is there
> a device able routing them to respective server.  I have been posting
> this question on Vyatta forum without response.  Are there any
> suggestions?  TIA
>   

Well there is no problem with lots of IP addresses - vserver handles 
that for you.  In the office here I just pick an unused address and boot 
the vserver using that - the rest of the subnet can see it fine

If your problem is RIPE not wanting to waste loads of IPs on you then 
use some form of NAT to hide machines behind fewer IPs

A common strategy is to put ALL vservers on a private 10.x.y.z subnet 
and then use the host to apply NAT to expose only the exact ports and 
services that you want to see on the internet.  This also makes for an 
extremely secure setup


Good luck

Ed W