[SAC] Virtual Machine Policy

Alex Mandel tech_dev at wildintellect.com
Tue May 4 14:16:29 EDT 2010


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


More information about the Sac mailing list