I currently have a t1.micro (free) instance running in aws, with Windows 2008 R2. I was taking a trial, getting a grasp of how to work with amazon aws service with this instance.
Now, I want to migrate it to a higher config instance say m1.large.
While I was trying to create AMI of the instance, it said that the instance is going to be rebooted, What data will I loose if the instance is rebooted ? Will the applications installed (MySql, Crystal Reports and some other apps) be deleted ?
How to migrate it without loosing any data.
Thanks
If you have a standard t1.micro with a 8 GB root volume, nothing should be lost. You would only loose data if you use Instance Storage, but you are probably not using it, unless you added it yourself.
If you really don't want to take any risk, you can select the "No Reboot" option when creating an AMI. Then try launching a new, larger instance from that AMI (while leaving the other instance running) and see for yourself.
Related
When creating an AMI image from an existing EC2 instance, does it require the restart of the existing instance?
I make a copy of the instance, and subsequently the server went down because it turned off a process monitor which led to downtime, but I can't remember if it was because I rebooted the system (I can't remember if I rebooted it), or if it was because I made a copy of the image.
There's option to enable No reboot during create AMI
When creating an AMI image from an existing EC2 instance, does it require the restart of the existing instance
to answer this yes, when ami is being created aws the instance for ensuring data integrity.
doc says this "Amazon EC2 powers down the instance before creating the AMI to ensure that everything on the instance is stopped and in a consistent state during the creation process."
you can override this behaviour by enabling no reboot while creating ami.
No reboot – This option is not selected by default. Amazon EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the AMI, and then reboots the instance. Select No reboot to avoid having your instance shut down.
refer 6 point of this https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html.
also whenever you are unsure about anything just follow the docs of that service, it will be define in one way or the another.
According to the AWS documentation "any data stored in the RAM of the host computer or the instance store volumes of the host computer is gone." Does this mean that the web application I installed on my EC2 instance will be deleted if I stop running my instance?
I apologize for the naive question. I am new to this and worried I might make a mistake.
An Amazon EC2 instance is just like a normal computer. If you turn it off, anything in RAM is lost. Also, if you reboot either computer, the contents of RAM is lost (well, more like 'forgotten', but effectively the same).
Just like your home computer, if you reboot or stop/start an EC2 instance, it boots up again. Whatever software you have installed on the computer is still there. However, applications you were running will only start if you have configured a startup script to run the app again.
Typically, when software such as a web server is installed on a computer, it is configured to automatically start again when the computer is turned on/rebooted in future.
Elastic Block Store (EBS) disk volumes act just like a disk in a normal computer. If an EC2 instance is stopped and later started again, the contents of the disk is still there, unchanged.
Bottom line: It's just like a home computer. Don't panic.
Adding to John's answer, as long as you do not use an Instance Store volume, to store your web application, you are good to go.
The data in an instance store persists only during the lifetime of its
associated instance. If an instance reboots (intentionally or
unintentionally), data in the instance store persists. However, data
in the instance store is lost under the following circumstances:
The underlying disk drive fails
The instance stops
The instance terminates
If however you are using an EBS volume, these conditions do not apply and you are free to start and stop your instance any number of times you want.
Yes unless you have EBS volume attached to EC2. If you are using an EBS-backed instance, you can stop and restart that instance without affecting the data stored in the attached volume
We have created an instance (m4.large) where we installed Windows Server 2012 r2. It is currently used as a terminal server for SAP business one software with license Remote Desktop Service per device (CAL). We made a mistake in choosing the instance type for it is recommended to use m4.xlarge for terminal servers. We would like to upgrade our instance type to resolve memory requirement issue.
We are new to AWS and would like to seek advise on what would be our best approach. Is it safe to directly upgrade the instance? We have no concerns of downtime for now.
We are also considering in making a snapshot first then launch it on an new and upgraded instance. We would like to ask if RDS licenses will also be migrated?
Thanks you for your kind replies.
You can change instance type anytime, but the instance must be stopped. If you are not concerned with some minutes of downtime just stop the instance, change the instance type and start the instance. Taking a snapshot as a backup before and frequently is a good precaution.
This change will have no impact on RDS, as that is a separate service.
One way would be simply to stop instance and upgrade it.
Warning
When you stop an instance, the data on any instance store volumes is
erased. Therefore, if you have any data on instance store volumes that
you want to keep, be sure to back it up to persistent storage.
Any Amazon EBS volumes remain attached to the instance, and their data
persists.
Any data stored in the RAM of the host computer or the instance store
volumes of the host computer is gone.
Another Way if you want minimal Downtime is you can create an AMI of it and Spin up new instance with Instance type and size what ever you desire and assign the domain or Elastic IP of current instance to new one and terminate old instance.
Also Regarding The RDS Licensing Please Mention what you mean by upgrading , but there will an outage when you apply for instance upgrade or License is Modified.
Also Upgrading EC2 Instance has no affect on Existing RDS as both are different services.
For Reference on Ms SQL DB , Please read these AWS Documentation:
Modifying a DB Instance Running the Microsoft SQL Server Database Engine
Microsoft SQL Server on Amazon RDS
As m4.large is EBS backed instance. so the loss of data is not a concern in the above question. Just select->right click-> stop the instance and change the instance type to m4.xlarge by right click->instance settings->instance type.
Also for your second question RDS is a separate service, so it won't get affected.
I have a php/mysql website that I want to deploy on AWS. Ultimately, I'm going to want auto-scaling (but don't need it right away).
I'm looking at an EBS based AMI. I see that by default the "Root Device Volume" is deleted when an instance "terminates". I realize I can also attach other EBS devices/drives to an instance (that will persist after termination) but I'm going to save most user content in S3 so I dont think that's necessary. I'm not sure how often I'll start/stop vs when i would ever want to terminate. So that's a bit confusing.
I'm mostly confused with where changes to the system get saved. Say I run a YUM install or update. Does that get saved in the "root device volume"? If i stop/start the instance, the changes should be there? What about if I setup cron jobs?
How about if I upload files? I understand to an extent that it depends where I put the files and if I attached a second EBS. Say I just put them in the root folder "/" (unadvised, but for simplicity sake). I guess that they are technically saved in the "root device volume"? If I start/stop the instance, they should still be there?
However, if I terminate an instance, then those changes/uploads are lost. But if I set the "root device volume" to not delete on termination, then I can launch a new instance with the changes there?
In terms of auto-scaling. Someone said to leave the "root device volume" to default delete so that when new instances are spun up/shut down, they don't leave behind zombie EBS volumes that are no longer needed (and would require manual clean-up)?
Would something like this work: ?
Setup S3 bucket (for shared image uploads)
Setup Amazon RDS / mysql
Setup DynamoDB (for sharing php sessions)
Launch EBS-backed AMI (leave as default to delete "root device volume" on
termination). Make system updates using yum/etc. Upload via sftp
PHP/HTML/JS/CSS files (ex: /var/www/html). Validate site can save
images to S3, share sessions via DynamoDB, access mysql via RDS.
Make/clone your own AMI image from your currently running/configured
one. Save it with a name that indicates site version/date/etc.
Setup auto-scaling to launch the image created in #5
I'm mostly concerned with how to save my configuration so that 1) changes are saved in-case i ever need to terminate an instance (before using autoscale) and 2) that auto-scaling will have access to the changes when I'm ready for it. I also don't want something like the same cron-job running on all auto-scaling instances.
I guess I'm confused with "does creating my own AMI image in #4" basically replace the "saving EBS root device volume" on termination? I can't wrap my head around the image part of things vs the storage part of things.
I get even more confused when I read about people talking about if you use "Amazon Linux" then the way they deploy updates every 6 months makes it difficult to use because you are forced to use new versions of software. How does that affect my custom AMI (with my uploaded code)? Can I just keep running yum updates on my custom AMI (for security patches) and ignore any changes to amazon's standard AMIs? When does the yum approach put me at risk for being out-of-date?
I know there are a host of things I'm not covering (dns/static IPs/scaling metrics/etc). That instead of uploading files then creating an AMI image, some people have their machine set to pull files from git on startup (i dont mind my more manual approach for now). Or that i could technically put the php/html/css/js on S3 too.
Sorry for all of the random questions. I know my question might not even be totally clear, but I'm just looking for confirmation/advice in-general. There are so many concepts to tie-together.
Thanks and sorry for the long post!
Yes, if you install packages, upload files, set up cron jobs, etc. and then stop the EBS-based instance, everything will still be there when you restart it.
Consequently, if you create an AMI from that instance and then use it for your autoscaling group, all the instances of the autoscaling group will run the cron jobs.
Your steps look good. As you are creating an AMI, your changes will be saved in that AMI. If the instance is terminated, it can be recreated via the AMI. The modifications made on that instance since the AMI creation will not be saved though. You need to create an AMI or take a snapshot of the EBS volume if you want a backup.
If you make a change and want to apply it to all the instances in the autoscaling group, you need to create a new AMI and apply it to your autoscaling group.
Concerning the cron jobs, I guess you have 2 options:
Have 1 instance that is not part of the autoscaling group running them (and disable the cron jobs before creating the AMI for the autoscaling group)
Do something smart so only one instance of the autoscaling group runs them. Here is the first page I hit on Google: https://gist.github.com/kixorz/5209217 (not tested)
Yes, creating your own AMI image basically replaces the "saving EBS root device volume" on termination.
An EBS boot AMI is an EBS snapshot of the EBS root volume plus some
metadata like the architecture, kernel, AMI name, description, block
device mappings, and more.
(From: AWS Difference between a snapshot and AMI)
Yes, you can automatically run yum security updates. To be completely identical to the latest Amazon Linux AMI, you should run all yum updates (not only security). But I wouldn't run those automatically.
Let me know if I forgot to answer some of your questions or if some points are still unclear.
So the whole purpose of me moving my mobile app from shared server to Amazon Web Services is so that I can hopefully start out with minimal storage space and cpu usage and expand as I need to without any app downtime. In other words, in my app all I am doing is calling some php scripts that then store data to a MySql db and upload / save some data files to disk. Is it possible to expand without having to create a whole new instance that has more CPU / Storage / Ram capabilities and then having to migrate all my php scripts over to the new instance? I'm new to AWS so I'm hoping to learn.
Stop the running instance and change the instance type and start it back.
Update:
Here's the screenshot on how to upgrade your instance:
You can create an image of your current instance called an AMI (requires reboot of your instance). Then you can create a new instance of any size using that AMI (so you won't have to migrate anything).
You can eliminate downtime by having both your new instance and your original instance running simultaneously, switch your Elastic IPs (if you have any) and take the original server offline.
The only downtime will be a minute or 2 while your machine reboots from the AMI creation.
Documentation: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html
Note: This is all assuming that your database is somewhere else (like in an RDS instance) that is not installed on your EC2 instance. If it is (or you save files and other stateful information on the webserver), then I suggest following Mar Cejas's advice and just take the server down and start it back up as a different size.