EBS for storing databases vs. website files
Asked Answered
R

4

12

I spent the day experimenting with AWS for the first time. I've got an EC2 instance running and I mounted an Elastic Block Store (EBS) to keep the MySQL databases.

Does it make sense to also put my web application files on the EBS, or should I just deploy them to the normal EC2 file system?

Ragman answered 15/3, 2009 at 3:35 Comment(3)
Noone knows your requirements except you. Maybe you should elborate...Illona
Voted back up because it's a perfectly legitimate question.Breastbone
As Kevin Peterson points out in his answer, it would be very relevant to know if you meant deployed code or data files.Buggy
B
7

When you say your web application files, I'm not sure what exactly you are referring to.

If you are referring to your deployed code, it probably doesn't make sense to use EBS. What you want to do is create an AMI with your prerequisites, then have a script to create an instance of that AMI and deploy your latest code. I highly recommend you automate and test this process as it's easy to forget about some setting you have to manually change somewhere.

If you are storing data files, that are modified by the running application, EBS may make sense. If this is something like user-uploaded images or similar, you will likely find that S3 gives you a much simpler model.

EBS would be good for: databases, lucene indexes, file based CMS, SVN repository, or anything similar to that.

Breastbone answered 27/6, 2009 at 7:56 Comment(1)
+1, this is the clearest answer here. Also, if OP happens to be wondering about speed of EBS versus instance storage, he should check this: serverfault.com/questions/111594/…Buggy
P
2

EBS gives you persistent storage so if you EC2 instance fails the files still exist. Apparently their is increased IO performance but I would test it to be sure.

Per answered 16/3, 2009 at 2:28 Comment(0)
M
2

If your files are going to change frequently (like a DB does) and you don't want to keep syncing them to S3 (or somewhere else), then an EBS is a good way to go. If you make infrequent changes and you can manually (or scripted) sync the files as necessary then store them in S3. If you need to shutdown or you lose your instance for whatever reason, you can just pull them down when you start up the new instance. This is also assuming that you care about cost. If cost is not an issue, using the EBS is less complicated. I'm not sure if you plan on having a separate EBS for your DB and your web files but if you only plan on having one EBS and you have enough empty space on it for your web files, then again, the EBS is less complicated. If it's performance you are worried about, as mentioned, it's best to test your particular app.

Morphology answered 29/4, 2009 at 15:16 Comment(0)
U
1

Our approach is to have a script pre-deployed on our AMI that fetches the latest and greatest version of the code from source control. That makes it very straightforward to launch new instances quickly, or update all running instances (we take them out of the load balancing rotation one at a time, run the script, and put them back in the rotation).

UPDATE:

Reading between the lines it looks like you're mounting a separate EBS volume to an instance-store backed instance. AWS recently introduced EBS backed instances that have a ton of benefits vs. the old instance-store ones. I still mount my MySQL data on a separate EBS partition, though, so that I can easily mount it to a different server if needed.

I strongly suggest an EBS backed instance with a separate EBS volume for the MySQL data.

Ungual answered 20/7, 2009 at 5:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.