On Fri, Feb 5, 2010 at 11:06 AM, Jordan Schatz <[email protected]> wrote: > > Thanks for the info everyone, I am thinking strongly that we will use > EC2. I am not sure that I understand EC2, it seems a little to good to be > true. If I understand it correctly I don't need to set up a RAID, or > consciously duplicate my data, because the virtualized EBS (elastic block > storage) is already redundant, and I don't need to have a failover
The data that is stored on EBS is supposed to be redundant. I still make backups. But you don't boot from EBS. You mount EBS volumes into one or more instances. > server, since the virtualized EC2 instance will persist even if the > hardware fails. Nope. Instances do go down. An instance is just a virtual machine that got booted up from an image (called an AMI in AWS lingo) stored on disk (on AWS S3). Whatever is written to the running instance goes away when the instance is turned off or goes down, unless it you wrote it to an EBS volume. > Does all the virtualization great high latency? or other performance > problem? EBS performance is okay, but not great, particularly for databases. > It just sounds to easy... It's not. Whatever AMI you use, you can make a "backup" of whatever is in it right now, to an ami file of your own, that you store on S3 If you do that, you're basically forking your own AMI line. But if you do that, what happens when Amazon releases new kernels or their APIs? You'll have to update your AMI, which is not a trivial process. The recommended way of doing things, in my understanding, is to boot from clean AMIs, and "populate" your instances with userdata scripts (scripts that run upon instance creation) and EBS volumes. It's a different way of doing things, and you have to learn it, and understand how it works, and do it right to make it useful for you. It's not as easy as you think. And it has advantages (like if you're using other AWS services, such as the content delivery network, or the load balancing) and disadvantages like everything. Understand them and decide if they are a good fit for your use case. Roberto _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
