2

I've just started trying out Amazon's EC2 service for running an asp.net web app which uses a SQL Server 2005 Express database. I have some questions about how to configure and operate it best for reliability, and I'm hoping to tap into some collective wisdom here as this is my first foray into EC2.

Here's how I have it configured currently:

OS: Windows 2003 SQL Server Express 2005

Web content stored on an EBS Volume (E Drive) Database Data stored on an EBS Volume (E Drive) Database backups to "C Drive" and then copied off to S3. Elastic IP Address attached to the production instance.

Now when I make a change to the OS configuration, I make a new AMI using the bundle feature. Unfortunately, I found that this results in significant downtime. While the bundle is created and the new instance is started. It seems that when I'm ready to make a new AMI, I should:

  1. Start up a new temporary instance.
  2. Detach the EBS volume from the production instance.
  3. Detach the IP Address from the production instance.
  4. Attach the IP Address to the temporary instance.
  5. Attach the EBS volume to the temporary instance.
  6. Create an AMI from the production instance.
  7. After the production instance restarts, reverse the attach/detach steps to put it back in production.

Is this the right order of events to prevent any chance to corrupt the EBS volume? Will the EBS volume become corrupt if I detach it while a database Write is taking place? Should I snapshot the EBS volume of the production instance and attach it to the temporary instance instead? Or could taking a snapshot of the EBS volume while it's in use cause corruption? Any suggestions to improve the reliability and operations?

Improve this question

1 Answer 1

Reset to default
2

It depends pretty on the types of changes you are making and how you have your AMI setup.

Assuming that you are just making changes to the OS, and your AMI doesn't auto-mount your EBS volumes...

  1. Start a second instance of your AMI
  2. Apply your changes to the second instance and bundle.
  3. Once the bundle is complete, terminate the 2nd instance.
  4. Register your new bundle and start an instance of it.

At this point your should have an updated instance running and just need to transfer the IP Address and EBS volumes to your new instance. Probably the easiest way is to do a clean shutdown of your 1st windows instance, and once complete just attach the IP and EBS volumes to the new instance. Personally, I prefer to do the following... just in case the 2nd instance doesn't work out and I want to go back to the first instance...

  1. Shutdown the IIS and Database Services on the 1st instance. (And any other applications/services accessing the EBS volumes)
  2. Take a snapshot of the EBS volume
  3. Cleanly detach the EBS volume from the first instance. (http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1841)
  4. Attach the EBS volume and IP address to the 2nd instance.
  5. Startup IIS and the database server on the 2nd instance and do a smoke test

Since you are doing all the updates on a second instance of your ami, you don't have downtime during the bundling procedure. You are also free to do the updates any time, even during the business day since you aren't touching your production instance. The only downtime you have is when you transfer the EBS volume and IP to the new instance. The other nice thing is that if the updates or anything about the new instance don't work out, you can fall back to using the original instance.

Also, one more thing... you can certainly cause problems by forcing a detach to a database when a write is taking place. Be careful with your EBS volumes and with your backups and snapshots. EBS is great, but it can still fail.

Improve this answer

You must log in to answer this question.