Assuming that you’re setting up a small instance (less than 1000 users), the most difficult hosting requirement is enough RAM. Open edX is composed of many software components, all of which use RAM even when they’re idle.
Put simply, you need 4GB of RAM. More won’t hurt. You can get away with less, but you need to fiddle around; see my post on reducing edX memory consumption for more details.
For a single machine instance, you’ve got a few options for hosting:
Amazon Web Services
A VPS
Your own hardware
Amazon Web Services (AWS)
Pros:
Extremely easy to set up (minutes)
Scales up as much as you like
Amazon’s tools make scaling extremely easy
Open edX is designed to run on AWS and automatically scale, so you’ll save a lot of effort if your instance is big enough
If you’ve got a large/busy setup you might end up saving money by scaling up/down with demand
Cons:
Expensive
Amazon will bill you for instance usage, disk space, I/O and network usage separately.
In Sep 2014 the instance costs $0.098/hour (in Sydney), but my actual running costs for an empty edX setup were around $120/month due to the extras.
Low performance disk and CPU
You have to worry about scaling issues sooner
You have to buy more hardware to compensate for your low-performance hardware
Amazon doesn’t make any guarantees about uptime. If you only have one machine and it goes down, your whole edX instance will be down until you start up a new machine.
Amazon machines used to be quite unreliable and go down every few weeks. In the last year or two they’re much better and will usually last for months at a time.
Amazon’s storage infrastructure (EBS) means that if a machine goes down, you can just start a new one; your data should remain intact.
Starting up a new machine is pretty easy, but you’ll be out for a few minutes, assuming you find out about the outage quickly.
Amazon encourage you to design your service to tolerate machine outages.
Moving an AMI to your region
The Open edX AMIs are only available in a few regions. I wanted one in Sydney. To transfer the AMI to ap-southeast-2 (Sydney):
Switch to the region that you’re going to copy the AMI from (e.g. us-east-1)
Ideally, you’d find it in the directory, go to Actions, hit Copy AMI and choose Sydney. For whatever reason, Copy AMI is disabled, so…
Create a new Micro instance in us-east-1 using the openedx AMI
Boot the instance
In the instance’s Actions menu, click Create Image
Wait a few minutes. Don’t shut down the instance yet.
In the AMIs page, the new AMI will list as ‘pending’. Wait until it’s ‘available’.
You can now shut down the new instance
In the AMIs page, now you can go to Actions->Copy AMI to Sydney.
Wait about half an hour
EBS vs. Instance Storage
EBS is unlimited, highly reliable storage. It lasts forever.
Instance Store is temporary, high-performance storage. Physically, it’s disks on the same VM server that your instance is running on. Once you shut down the instance, anything that you put in here is lost.
Obvious uses for this are /tmp and swap
A Virtual Private Server (VPS)
Pros:
Affordable
Quality hosting in the US is about USD$120/year.
In Australia, AUD$480/year.
Per-machine, performance is higher than AWS (assuming you’ve chosen a reputable VPS host that doesn’t overprovision their machines). Less machines means less maintenance.
You might get an uptime guarantee
This is probably not worth anything; your compensation if a machine fails will be an email apology, if anything
You can check reviews and uptime reports to see if your host has a good record
You could rent a managed VPS and thereby outsource some of the administration hassle
Administering a Linux VPS is trivially easy compared with Open edX, so I wouldn’t bother spending the money
Cons:
Scaling up/down with demand is your problem.
For a small enough instance (a few thousand users), you’ll fit on one machine, so this isn’t an issue
You could build your own OpenStack or CloudStack cluster, but this involves significant engineering effort; AWS probably works out cheaper once engineering cost is considered.
OpenVZ or KVM?
Roughly, OpenVZ isolates multiple users of the same hardware and kernel from each other. KVM is a virtual machine, so it will behave more like a real computer.
Both have some advantages:
OpenVZ can change RAM, disk and CPU allocations instantly
There’s no rebooting or repartitioning if you need to scale up/down
This is nice if you’re not sure how much hardware you need or you get unexpected traffic
With KVM, you need to reboot and resize the partitions by hand; downtime could be significant
KVM can use swapspace (file-based swap) or zram (compressed RAM-backed swap) to squeeze more RAM out of the same hardware
OpenVZ usually blocks you from changing the swap config; you will need to pay for more RAM if you run out
If you run out of RAM, the OOM killer will kill a process. Usually nothing bad will happen, but occasionally it’ll hit something important, like Postgres.
You can’t load kernel modules in OpenVZ, so you can’t use zram unless the host explicitly supports it (unlikely)
KVM can use LXC or OpenVZ containers within your VM
You can nest virtual machines inside your virtual machines. Confused yet?
This is really handy for running production and staging systems on the same (virtual) hardware without paying for a second VPS
My preference is KVM, but if I had more users, I’d be leaning toward OpenVZ or Amazon.
There’s some excellent discussion of different virtualisation options over here.
Your own hardware
Pros:
Cheap! A $400 desktop is plenty to get started and there are no ongoing rental fees.
Fast
You might have suitable hardware lying around already
Cons:
You need a really fast Internet connection
Any hardware failures are your problem
You need to know how to build and maintain the hardware
