Hey Adrian -
Mostly to see the impact of additional CPUs on a write only load. The
portion of the application we're migrating from MySQL is very write
intensive. The other 8 core option was c1.xl with 7GB of RAM. I will
very likely need more than that once I add reads as some things can
benefit significantly from the row cache. I also thought that m2.4xls
would come with 4 disks instead of two.
Why did you choose four big instances rather than more smaller ones?
Agree on all points. The reason I'm keeping the cluster small now is to
more easily monitor what's going on/find where things break down.
Eventually it will be an 8+ node cluster spread across AZs as you
mentioned (and likely m2.4xls as they do seem to provide the most
value/$ for this type of system).
For $8/hr you get four m2.4xl with a total of 8 disks.
For $8.16/hr you could have twelve m1.xl with a total of 48 disks, 3x
disk space, a bit less total RAM and much more CPU
When an instance fails, you have a 25% loss of capacity with 4 or an
8% loss of capacity with 12.
I don't think it makes sense (especially on EC2) to run fewer than 6
instances, we are mostly starting at 12-15.
We can also spread the instances over three EC2 availability zones,
with RF=3 and one copy of the data in each zone.
I'm interested in hearing about your experience(s) and will continue to
share mine. Alex.