3

If I were to upgrade an amazon instance, I'd create a snapshot of the image and create the new instance from this image and then upgrade that instance.

My question(s) is related to mongodb and the best way upgrade from a m1.large to a m3.large instance - basically m3's are cheaper and more powerful than the old m1's.

I currently have mongodb running on the m1.large instance backed by 3 EBS Volumes for storage, journalling and logs (essentially the mongodb image config from the MarketPlace).

When i've gone through to setup the new m3.large instance, I noticed that it's not EBS Optimized.

Working with mongodb and the current config, I assume for optimal performance, it's desirable to go the EBS Optimized route - if that's the case, the best upgrade path is to go for m3.xlarge? Would I hit a big performance penalty if I went with a m3.large?

And lastly....after taking a snapshot of an image (specifically an image backed with EBS Volumes), does the new image take that same config setup? I.E The new image will be backed by the same volumes?

I know I can stop and start the current instance, but I want to minimise any downtime.

Any help appreciated!

Michael
  • 43
  • 1
  • 3

1 Answers1

5

Firstly, you don't need to create an entire new instance, snap the EBS volumes of the old one, and attach the copies. If you're doing this to try to avoid service interruption, what happens when you switch the EIP from the old to the new instance? Yep - service interruption.

Just stop the m1, reset it to m3, and start. There will be an outage, of course, but you'll be back in less than 5 minutes and you've saved yourself a chunk of work replicating volumes.

As for EBS Optimised - do you really need that? Do you understand what it means, and what the consequences of NOT having it on the new instance are? If the answers to both are YES, then of course pick an m3 (or larger) instance type that supports it. If NO, research until you know what the feature gives you and whether you actually need it (you pay more with it active - don't spend more than you actually need to).

Eight-Bit Guru
  • 9,756
  • 2
  • 48
  • 62
  • "Just stop the m1, reset it to m3, and start" .. how to do that ? – Subham Tripathi Jan 13 '15 at 05:49
  • 1
    @SubhamTripathi After stopping the instance, go to Actions -> Instance Settings in the AWS console, there is an option there "Change Instance Type". After that start the instance again. – Yahya Jul 11 '16 at 12:17
  • @Eight-Bit Guru, wouldn't stopping and restarting the instance result in loss of data stored on the RAM? Creating a new AMI would not result in any data loss? Right? – Yahya Jul 11 '16 at 12:28
  • 2
    @Yahya, stopping an instance is like pulling the plug on your PC - data in RAM vanishes. Creating an AMI from a running instance can be done, but it can be unsafe (since the storage is not imaged as a hard 'point-in-time' snapshot so changes to the filesystem whilst the AMI is being created may result in a compromised image) and anyway does not include data in RAM. In other words, there is no way to preserve RAM state across 'stop/restart' or 'bundle-image' operations. – Eight-Bit Guru Jul 11 '16 at 12:50
  • Thanks @Eight-BitGuru, I found my answer here : http://stackoverflow.com/a/15939842/1882331. Since, my root volumes are EBS based, I can follow the stop/restart way of changing the instance type. – Yahya Jul 11 '16 at 12:58