A while back I wrote an article describing a way to move the root EBS volume from one running instance to another. I pitched this as a way to replace the hardware for your instance in the event of failures.
Since then, I have come to the realization that there is a much simpler method to move your instance to new hardware, and I have been using this new method for months when I run into issues that I suspect might be attributed to underlying hardware issues.
This method is so simple, that I am almost embarrassed about having written the previous article, but I’ll point out below at least one benefit that still exists with the more complicated approach.
I now use this process as the second step—after a simple reboot—when I am experiencing odd problems like not being able to connect to a long running EC2 instance. (The zeroth step is to start running and setting up a replacement instance in the event that steps one and two do not produce the desired results.)
Here goes…
Method
To move your EBS boot instance to new hardware on EC2:
Stop the EC2 instance
ec2-stop-instances $instanceidStart the EC2 instance
ec2-start-instances $instanceid(optional) If you had an Elastic IP address associated with the instance, re-associate it:
ec2-associate-address --instance $instanceid $ipaddress
It’s that simple. In my experience I almost always get new hardware for my instance by performing these steps. But…
Caveats
Some things to consider when using this approach:
Make sure you “stop” the instance and not “terminate” it. Terminating an instance generally loses all disk based information.
This will only work with EBS boot instances. S3 based instances cannot be stopped.
Stopping an EBS boot instance preserves files on attached EBS volumes, but all information on ephemeral instance-store disks will be lost (e.g.,
/mnt).There may be a small chance that you will get the exact same hardware after starting the instance again. If the internal IP address before and after are the same or if you continue observing what you sincerely believe is a host system issue, you may want to run the process again.
There will be a short outage while your instance is stopped and started. In my experience this lasts roughly about the same time as it takes for a normal system to boot up.
There is a risk that after stopping the instance, you will not be able to start it again because that availability zone no longer has open instances of that type.
I ran into this last issue recently when I stopped an m2.4xlarge instance in a us-east-1 availability zone. Upon attempting to start the instance, I received the error that instances of that type were not currently available in that zone. I ended up having to start a replacement instance from scratch in another us-east-1 availability zone which worked out fine, but I would have preferred to keep my instances closer to each other. Eventually instances freed up and I moved the server back to its home zone.
If I had used the more complicated approach to move the root EBS volume to a new instance I would have made sure that there was an instance of the right type available before stopping the original instance.
Follow Eric Hammond on Twitter
This method works well.
What would be even more useful is an easy way to move an instance to a new availabiity zone..
Any ideas?
skrewler: Sure: Create an EBS boot AMI from the old instance and start a new instance of that AMI in the new availability zone. It's basically two commands or API calls, plus copying your data volumes and associating Elastic IP addresses.
What I would be interested in - how exactly do you determine that there is a hardware issue?
tillk:
Excellent question and the answer shows how cool EC2 is. When you suspect that there might be a problem with a standard "owned" server, you want to make sure before you purchase replacement parts or replacement systems that you're not wasting money and that the cause isn't really just a software issue.
With EC2 as this article demonstrates, you can easily switch hardware with no serious monetary investment, so it can be nearly a knee jerk reaction when you don't know what the problem is. If moving to new hardware doesn't fix the issue, then you can put in the harder investment of tracking down what might be causing the problem in the software or system configuration.
I generally switch to new hardware if a long running instance suddenly becomes unresponsive and a reboot does not fix it, or if it suddenly starts spewing out odd looking system errors in the syslog that seem to be related to something going wrong at a low level.
Great blog Eric!
As far as I see your old process does not really guarantee that you will find an instance in the requested availability zone. Since your last step (6) involves re-starting the new instance, even if there was one available in step 2 it may no longer be available.
To really guarantee a zone, you need to pay for a reserved instance.
Also your old method requires a run and a start, so you will be charged for 1 additional hour compared to the simpler method.
-tom
tom: Though the other article's method does not guarantee you will get a new instance, I suppose you could get the new instance before stopping the old one just in case the old one still has some life left in it. Perhaps I'm just grasping at straws for why it wasn't a complete waste of writing.
Eric loved the blog post, its really of great use.
The method also seems to be easier one. Just wondering will there any chances Accidental Termination of EC2 Instances from this??
[COMPLETELY UNRELATED AND SUSPICIOUSLY SPAMMY LOOKING LINK DELETED]
cochran1010:
stop/start should not terminate the instance. That said, you should always be prepared to recover from an accidental termination or instance.
There are rare times when I've stopped an instance and then not been able to start it for a bit because that instance type was not immediately available in the desired availability zone. I needed to run my instance as a different type for a while or to start a new instance in a different availability zone.
I have an Windows 2008 EBS instance, but need to change the security group to use VPC. Ordinarily, it is not possible to change the assigned security group. It has to be assigned when the instance is launched. Could I use your earlier instructions to create a new instance using my valuable ebd volume and assign a new security group?
sjgreenbaum:
I haven't run any Windows instances on EC2 so don't know how they differ. One thing you should be aware of is that you can change the rules of a security group that is already assigned to an instance even though you can't add new security groups.
Whats important here is that EBS Volumes are bound to hardware even if the instance is stopped.
If you have a degraded instance, make absolutely sure to also make snapshots of all attached EBS volumes and recreate them.
Else you could not only run into an unresponsive instance, but also permanently loose data, which even a snapshot can no longer help. (FS crash anyone ...)
We had the case that we had an instance failure and degraded hardware, started a new instance with the same volume and the new instance had errors and starting / stopping seemed not to help. Then it worked finally and then the Filesystem crashed permanently with memory errors.
From this I presume that an instance is still run "near" its Volume, which might be a degraded region within an availability zone.
Because we just got a stable working instance again when we used a new volume created from a snapshot.
Hope that helps.
Best Regards,
Fabian
Fabian:
I have fixed many problems by simply stopping and starting an instance without replacing EBS volumes. In my experience EBS volumes almost never have issues. However, it is good to point out that there are other things to try like replacing EBS volumes if you continue to have issues.
Taking snapshots of your EBS volumes is recommended both on a regular basis and before attempting to do anything unusual with the instance (like stop/start).