[SAC] Virtual Machine Policy

Committees SAC mailing list
1

So in our original discussions we hadn't really planned on making
independent Virtual Machines for each project. The general idea had been
that a few heavily impacted projects would get their own and everyone
else would be grouped into generic Project VMs. There actually had been
no plans to move any of the sites on xblade10, and low priority on
xblade14 projects.

So the question now arises about best resource allocation and management
strategy.

I see 2 scenarios:
1. a VM per project, resources will need to be kept low to make sure we
have a enough space and at least 1 SAC member has to be in the know
about what's going on that VM.

2. 2 Projects VMs, one with Php and one without (single thread vs multi
threaded apache), and split projects amongst the 2. This might be a
better use of shared resources/efficiency.

*Should we pool all mediawiki needs onto the Wiki Vm?

My estimation is that we should have between 8-11 VMs on each of the new
servers at most. After that we'll start running out of cpu and ram.

In addition I think we should come up with a standard backup policy.
For example, anything you put into /backup on your vm will get backed up
on a schedule, please try to compress large files before transfer.

Long term it also sounded like telascience is moving towards VM
implementation so that we can easily migrate whole instances when
needed, or keep standby copies ready.

I plan to put in a VM creation request in the next couple of days with
QGIS, GRASS, and Webextra, if we can come to some agreement and specs
other VMs can be created at the same time.

Thanks,
Alex

2

On 05/04/2010 11:16 AM, Alex Mandel wrote:

I see 2 scenarios:
1. a VM per project, resources will need to be kept low to make sure we
have a enough space and at least 1 SAC member has to be in the know
about what's going on that VM.

2. 2 Projects VMs, one with Php and one without (single thread vs multi
threaded apache), and split projects amongst the 2. This might be a
better use of shared resources/efficiency.

I don't know enough about VMs resource sharing issues, but can certainly see the benefit of #1 - have a VM per project. Then projects have fullest amount of freedom.

I think all OSGeo projects should have space on OSGeo managed hardware - thereby porting all primary websites from xblades is important to me. Not only do projects want/need stable infrastructure, but it looks bad for OSGeo too if they fail - we tell sponsors that we provide infrastructure support, but when several sites are down for a week then we failed at a major objective. I'm not blaming telascience, just saying that critical sites should be on OSGeo machines so a larger team can manage them. Leave the really cool stuff on the blades though :slight_smile:

*Should we pool all mediawiki needs onto the Wiki Vm?

Worked well so far.

I plan to put in a VM creation request in the next couple of days with
QGIS, GRASS, and Webextra, if we can come to some agreement and specs
other VMs can be created at the same time.

Did you already put in one for the main web VM?

Tyler