Best practices for setting up and managing new servers

This page provides some general advice and suggestions on planning the deployment of new servers for research groups. For concrete details of TIG's server (and desktop) support and available infrastructure, see Operating Systems Support.

If you've already decided you need a new server, please read Choosing and registering a hostname and Configuring email. Otherwise, we suggest you at least skim the whole thing.

See also

TIG's statement on security...

TIG strives to ensure that our computer systems, network, software and data are secure and functioning in a way that allows the CSAIL community to be confident in the platforms and services we provide. TIG urges users to employ best practices to ensure the security of systems of theirs that live on TIG-provided platforms, such as an OpenStack or Xen instance. Confidential data should be stored in a controlled, secure environment, protected from unauthorized access. TIG is not responsible for any damage that may arise from improperly deployed or maintained systems.

Do you need your own server?

In many cases, CSAIL-wide resources provided and wholly administered by TIG may mean that you don't actually need your own server. You can run web applications (such as wikis, registration forms, and the like) on CSAIL's shared web servers — even using your own domain name like http://mygroup.csail.mit.edu/ or http://www.myproject.org/ if need be. TIG provides CSAIL-wide database servers, a mailing-list server, a mailing-list server, and many other resources. Many of these services are self-serve, and if you need something more complex or something that requires TIG's intervention you can send mail to help@csail.mit.edu and we'll be happy to help.

Cases where your group might still want your own server might include situations where you want more performance or security isolation from other groups at CSAIL (e.g., if your service is going to be extremely heavily loaded sometimes, your colleagues at CSAIL might appreciate having it on a different machine from theirs, or if your application is timing-critical, you might want it on a machine that has no other load on it), or situations where you want complete control of the machine from the hardware up (e.g., if you want to be able to load arbitrary kernels or OSes on it).

Heavy computing, where you want a large amount of CPU and RAM available to your own group without the potential of other groups using it, might be a case where it makes sense to have your own physical server(s). Do be aware, though, that CSAIL has a shared Condor cluster, which may meet your needs. (Even if you do end up buying your own servers, if the Condor model works for you you might want to join them to the CSAIL-wide condor cluster, presumably with your group's jobs getting priority on them, so that you can take advantage of spare capacity elsewhere when you need it and your colleagues can take advantage of your unused capacity when your machines would otherwise be idle. Contact us at help@csail.mit.edu if you'd like to explore that possibility.

Virtual or physical?

If you decide you need your own server, we provide a couple different ways to deploy virtual servers, so you may still not need to buy your own hardware.

Our OpenStack-based compute cluster provides a "private cloud" along the lines of Amazon EC2, but using hardware here at CSAIL (generously donated by Quanta Computer). It provides a self-service way to configure, bring up, and tear down VMs. At present it's not well suited for long-lived public-facing servers, since the contents of your virtual local disks are not preserved when you shut down the VM, but we expect that to change in the very near future (as of August 2013). We have the best support there for Ubuntu VMs, but other distros should work too, and I believe at least one brave soul has gotten Windows to work.

In addition, when necessary, we can deploy Debian research VMs on a small cluster of Xen servers. This involves much more manual intervention on our part, is limited to Debian, and is resource-constrained. We hope to move these VMs to our OpenStack infrastructure (which doesn't have those limitations) as soon as our support for persistent local-disk images there is solid, but in the meantime if you need a public-facing database or web server that needs to be isolated (administratively) from other groups' servers, this is a last-resort way we can give it to you as a VM.

Hardware

If you decide you do need your own physical server, we encourage you to consult with TIG before committing to a purchasing decision. In general, this often means people saying "We want to buy a thus-and-such to do this on" and us saying "OK, that sounds fine" (after some discussion about physical needs; see below), but we may have useful advice (e.g., that somebody else ran into problems with that particular hardware, or that if you buy this comparable machine instead we'll be in a better position to diagnose it if it breaks). And we're happy to be a sounding board for your capacity-planning thoughts.

Machine-room resources

If you decide you want to buy a physical server and you want to deploy it in one of the shared CSAIL machine rooms, you must talk to TIG first! Before your machine(s) can be deployed, we have to identify suitable rack space and make sure that sufficient power, cooling, and network drops are available for it. All new servers installed in CSAIL machine rooms must be rack-mountable. If you have a tower server, you can use it, but it will need to be in somebody's office or in your group's shared space. That means it won't have the benefit of the machine-room UPSes, it's more likely to have the power cord kicked out accidentally, and in many cases it means that somebody's stuck listening to a very noisy machine. Generally it's preferable to buy rackmount hardware.

Choosing and registering a hostname

Different groups have their own conventions for hostnames, so you'll want to talk to your colleagues about this. It makes our lives (and ultimately yours) if similarly configured machines have similar (pattern-matchable) hostnames. For instance, if you have a cluster of nine machines that do raytracing, it's easier for us (although less interesting) to call them raytrace01, raytrace02, ... raytrace09 than mercury, venus, ... pluto1. That way we can set up our configuration-management infrastructure to recognize the pattern and when you add raytrace12 it will just work without you having to coordinate with us.

It's also very helpful for us if the hostnames give us a hint who to contact if we have problems with the machine years down the road (perhaps after you've left CSAIL). So if you work with the XYZ group, it would be even better to call these machines xyz-raytrace01 ... xyz-raytrace07.

The person who initially adds a machine in WebDNS is recorded in our database, so if we need to know who to contact about a machine and we can't figure out who it belongs to, that's where we'll look. For that reason, it's very helpful if the person who initially registers a machine is the primary user, and/or if her or his supervisor is the PI of the research group who will be using the machine.

Configuring email

Unless your machine is purely managed by TIG (e.g., you don't install any software yourself, but ask us to install and configure it for you), it is important that you arrange for root email go to somebody in your group who has management responsibility for the machine. (If the machine is a CSAIL Debian or CSAIL Ubuntu machine, i.e., runs our customized CSAIL installation of the OS, root mail should also still go to TIG as well.)

On a machine running CSAIL Ubuntu (our current preferred distribution), you can do this by editing the file /etc/facter/facts.d/local.txt (creating it if it doesn't exist) and adding a line that says
root_alias=you@csail.mit.edu

The change will take effect within about half an hour.

On a machine running the legacy CSAIL Debian distribution, you can do this by editing the root: line in /etc/aliases directly. For instance, you would change it from
root: tig-server-root@csail.mit.edu
to something like
root: tig-server-root@csail.mit.edu, myaddress@csail.mit.edu

(This applies to workstations as well, although the alias to send root mail to TIG is different in that case.)

-- JaySekora - 28 Aug 2013


1 Take that, International Astronomical Union!
Topic revision: 12 Mar 2014, JasonGaudette
 

MIT Computer Science and Artificial Intelligence Laboratory

 

  • About CSAIL
  • Research
  • News + Events
  • Resources
  • People

This site is powered by Foswiki MIT: Massachusetts Institute of Technology