Research Computing offers hosted virtualized servers for groups requiring dedicated systems. Virtualization helps avoid the cost of investment in dedicated hardware where raw horsepower or highly computational usage is not a concern. This document aims to outline our offerings and the levels of support offered on the various tiers.
|1||Fully monitored, RC is responsible for service availability and proper functioning of the base VM. No sudo/root access. NFS mounts allowed.||FAS RC|
|2||RC provisions requested OS, end-user has limited privileged access (example: May have sudo to restart webserver). NFS mounts allowed.||FAS RC & Customer (limited)|
|3||RC provisions "bare metal" with requested OS, hands off to requester who has administrative control. No NFS mounts allowed, as a result. RC is responsible for proper functioning and health of the KVM infrastructure. End-user is responsible for all other maintenance including software and administration of services.||Customer|
A common request is for a VM to host a website. In general, web hosting requests should be referred to the Harvard Web Publishing (HWP) group who manage OpenScholar as well as provide static site hosting for operationally valid projects. In certain cases, usually where access to data stored on FASRC filesystems is required, we do provide VMs for serving web applications. Please contact us if your needs cannot be met by HWP or a cloud host.
Please be aware that our VM offerings are not suitable for high-traffic, high-availability sites or for sites which require large, constant bandwidth. If your project will serve large audiences and require 24/7/365 uptime, you may wish to consider a hosting provider who can offer that level of site reliability.
The VM infrastructure is a shared and finite resource. Our base configuration is meant to address most VM needs and, while we can adjust, there are upper limits beyond which a discussion about dedicated hardware may be in order. This base configuration size allows us to plan for capacity while offering the best standard support possible. As configurations drift away from this standard default, they require more time and effort to support when something goes wrong. Please bear that in mind when requesting a VM.
Virtual Machines are suitable for many applications and usage models, but are not suitable for use as compute nodes, database or other disk intensive services, or computational/visualization nodes.
Please contact us to discuss how best to implement those services for your lab or group. An initial live consultation with FAS Research Computing is required for every Virtual Machine prior to setup. As part of our security responsibilities, a yearly check-in is also required.
Our default offering consists of a modestly configured VM, well suited to most low-to-mid end tasks. These systems are:
- OS: CentOS 7.x
- Virtual CPUs (VCPU): 2
- RAM: 2GB
- Networking: 1x1GB static network address, public IP addresses available as requested
- Disk: 30GB (root disk, including OS)
We have found that for most tasks, these specs are suitable, and this size footprint allow us to host many VMs with efficient storage and power consumption.
VCPUS and RAM can both be extended, within reason. Research Computing staff can help you determine the best RAM and VCPU ratios. But please be aware that our VM pools by design are a shared resource, as such we do need to place limits on the maximum VM size and how much in total each group can utilize at one time.
- Max Total Allowable Size for any Single VM: 8 VCPU Cores/16GB RAM/200GB Disk
- Max Combined RAM and VCPU Per Lab for multiple VMs: 16 VCPU Cores/64GB RAM/200GB Disk
If you need a machine larger than the maximum offering, please contact us to discuss purchase of a dedicated hardware node.
For disk storage, our approach is to keep disk images as small as possible, for maximum flexibility and efficiency (the bigger they are, the harder they are to move around quickly as things change). Smaller disks also allow VM backups to happen in a timely manner. Obviously not all applications/use cases can be satisfied with a 30GB disk which includes the OS. In these cases, our preferred option is to expose network storage (many times Shared Lab/Group storage, or storage specifically provisioned for this service) for additional capacity (see Tier table above for exceptions).
Backups of VM disk images/configurations happen nightly, and up to 2 weeks of history is retained. That being said, it is much easier/effective to restore from backups of network shared storage (it is more granular; with the VM disk image, the entire disk must be restored, not simply a part/section of it), and is yet another reason we encourage small disk images with network shared storage for data.