Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to create a server structure for my EC2 account. The design I have chosen consists of 2 instances running in different availability zones, elastic load balancer, an auto-scaling group with cloudwatch monitoring configured and a security group defining rules for access to the instances. This setup is to support an online web application written in PHP.

I am trying to decide what is a better policy:

  1. Store MySQL DB on a separate Instance
  2. Store MySQL DB on an attached EBS volume (from what i know auto-scaling will not replicate the attached EBS volume but will generate new instances from a chosen AMI - is this view correct?)

Regards the AMI I plan to use a basic Amazon linux 64 bit AMI, and install bastille (maybe OSSEC) but I am looking to also use an encrypted file system.

  1. Are there any issues using an encrypted file system and communication between the DB and webapp i neeed to be aware of?
  2. Are there any comms issues using the encrypted filesystem on the instance housing the webapp
  3. I was going to launch a second instance or attach a second volume in the second availability zone to act as a standby for the database - I'm just looking for some suggestions about how to get the two DB's to talk - will this be a big task
  4. Regards updates for security is it best to create a recent snapshot and just relaunch and allow Amazon to install updates on launch or is the yum update mechanism a suitable alternative - is it better practice to relaunch instead of updates being installed which force a restart.
  5. I plan to create two AMI snapshots one for the app server and one for the DB each with the same security measures in place - is this a reasonable - I just figure it is a better policy than having additional applications that are unnecessary included in a AMI that I intend on using.
  6. My plan for backup is to create periodic snapshots of the webapp and DB instances (if I use an additional EBS volume instead of separate instances my understanding is that the EBS volume will persist in S3 storage in the event of an unexpected termination and I can create snapshots of the volume backup purposes).

Thanks in advance for suggestions and advice. I am new to EC2 and I may have described unnecessary overkill but I want to try implement what can be considered a best practice solution so all advice is appreciated.

share|improve this question
add comment

1 Answer 1

The database should be on a dedicated instance, where possible. This will allow you to manage that server independent of any other servers that you may have (add disk space, replace the server, etc.).

The database should also be put on a separate EBS volume from the root volume. This allows you to setup a new server and "move" the data to the new instance easily.

I wouldn't apply AutoScaling to your database. AutoScaling creates new instances from AMI images, which most certainly will be out of date with regards to your data. You can have all other instances which are launched by AutoScaling to use your single database.

You can use MySQL replication to replicate data to a slave instance in another availability zone. See http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html

The slave instances have many uses:

  • Keep it on standby in case the primary server goes down
  • Perform read-only operations on the slave to relieve the primary server's load
  • Backup the slave instead of the primary server to avoid table locks and/or other database accessibility problems
share|improve this answer
    
Hi, thanks for getting back to me, MySQL replication looks like the solution I'm after, i intend on using a separate instance for the DB. –  user123683 Jun 8 '12 at 1:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.