I have ec2 instance set up where mysql DB is mounted on separate volume.
(as detailed in http://aws.amazon.com/articles/1663 )
I want to duplicate this instance set up where my application servers on duplicated instances share the DB volume which is attached to the already running ec2 instance.(I can specify mysql ip through configuration file)
Since almost every set up except the mysql ip is identical, i'd like to create an ami from the first instance and slightly modify to create 2nd,3rd instances.
The question is, the mount information stored in the first instance will take effect when I launch the 2nd instance.
I can elaborate the question,
1. I read that a volume can not be attached to more than one ec2 instance at the same time.
2. the running instance attaches/mount an volume to itself on start up.(so it seems)
3. if I were to create an ami from first instance and use that to initiate other instances, how would auto attach/mount information(which I assume, will be stored in the ami) will affect the other instances.
Eugene,
Mounting the same device to several servers is not possible, so you better forget about this option.
The best solution is to:
Create a copy of your master instance.
Detach the created mount volume. We are going to create an image from this new instance, and you don't want the useless drive copy to be re-created every time.
Change the settings that you need to change, in order to make this server rely on the remote (master) mysql server.
Once you are satisfied with the outcome, create an image from this instance.
Good luck!
Dotan
Related
I create an instance but do not add additional storage / a volume, will a snapshot backup the instance and the changes I have made to the config or does it only backup data from the volumes?
I am making some training material and would like to do the following:
Create an instance
Create users
Make a few more config/program installation changes
At this point, I would have a "clean copy".
I then would like to take a Snapshot of the state of the instance.
fool around, possibly break stuff
Then restore the instance to the "clean copy" after the instance has been created but before I started messing around.
Is this possible with snapshots?
Let's clarify some terminology:
A Snapshot can be made of an Amazon EBS volume. This makes a backup of the specific disk volume. The snapshot can be used later to create a new EBS Volume.
Or, you can create an Amazon Machine Image (AMI) of an Amazon EC2 instance. This creates an EBS Snapshot of all associated volumes and also stores some metadata about the AMI.
You can then Launch a new Amazon EC2 instance from the AMI. This will include a copy of the disks.
If you wish to restore the instance to the "clean copy", then it is best to launch a new instance from the AMI rather than trying to 'reset' the instance to an earlier state. The instance will have a different Instance ID and a different IP address, but will otherwise be the same as the instance from which the AMI was created.
I’m running a website on an m3.2xlarge AWS ec2 instance which is EBS backed.
I want to change the instance type to m2.2xlarge instance.
This new instance already has instance storage of 850 gb hdd.
My question is: can I attach the existing EBS drive to the new m2.2xlarge instance? and boot to the website?
There are 2 possibilities
1
stop your running Instance, Detach the volume (or take a snapshot of it)
Now while launching the new Instance you can add additional volume along with your Root volume (of new Instance). Just keep in mind you cannot delete or exclude the Root volume of new Instance while Launching, its just that you can add an extra volume along with the root volume
2
Stop your running Instance
Go to actions and then Select Insatnce Setting and then click on Change Instance Type
Select your desired Type of Instance
after changing the Type of instance, you can restart the Instance
Your existing EBS will remain attached after resizing. You will not get to see instance store which comes with m2.2xlarge. This won't get add up to resized instance. This is based on the documentation here:
When you resize an instance, the resized instance usually has the same
number of instance store volumes that you specified when you launched
the original instance. If you want to add instance store volumes, you
must migrate your application to a new instance with the instance type
and instance store volumes that you need
How to replace a Amazon EC2 instance with a new instance without removing tomcat7, mysql and other setting done on the instance?
Simple:
Stop the instance.
Detach the volume(s) - if you just have one volume (the boot volume) detach that.
Take a snapshot of the volume(s) for safekeeping (not strictly necessary in this case, but no-one ever got fired for taking backups of critical systems).
Terminate the instance.
Spin-up a new instance of the desired type (must be the same platform, i.e. x86 or x64, as the original).
Wait until it's running, then stop it.
Detach its' volume and delete it.
Attach your original volumes to it (the boot volume must be /dev/sda1).
Restart the new instance and re-assign Elastic IP if appropriate.
What is the different between starting an AWS Image and Instances?
Example:
I do notice when I am running AWS image using boto, I can only stop the Image while running AWS instance using boto, I can only terminate.
Think of an EC2 instance as a single running server with CPU, memory, hard disk, networking, etc. Any changes you make to that instance affect only that instance.
Think of an AMI (Amazon Machine Image) as an exact copy of the root file system that gets copied to the hard disk when you start a new instance. The AMI is a hard disk sitting on a shelf. You make an exact copy of the hard disk on the shelf, install the new hard disk in a server, and turn the server on. You can do this for as many servers as you'd like to start without affecting the master copy.
The AMI defines the initial state of each instance. Each instance changes as it runs, but you can never change the original AMI once it has been created (other than to delete it).
There are more details that refine this conceptual model, but that's the basics.
Specific to the wording in your question:
Sometimes we say we're "starting an AMI" sometimes we say we're "starting an instance". We mean the same thing. We're really starting an instance using an AMI as the template.
We never say we're "stopping/terminating an image" or "stopping an ami" as, once started, it's really the instance that's running.
You can have one or more instances running that are derived from an image (AMI). Here is a good little tutorial, that's a bit old mind you, talking about how you can convert an Instance to an AMI ... which you can then redeploy one or many times:
http://webkist.wordpress.com/2010/03/16/creating-an-amazon-ec2-ebs-ami-from-a-running-instance/
What is an AMI: Amazon Machine Image
http://en.wikipedia.org/wiki/Amazon_Machine_Image
Technically, you can't start an AMI. You can start an instance that is derived from an AMI.
Its a pretty quick question - I have setup a pretty simple LAMP based website on EC2. I created an EBS and mounted it to the instance where I'm saving all the mysql data and other backups.
Now in order to connect to the instance - I use WINSCP and use the Elastic IP from where I can view all the data.
Now my question is - say I terminate the instance - the backup data and mysql data which resides on the EBS will still be available right. So how can I access this data.
I mean using WINSCP and the same Elastic IP, I wont be able to connect anymore as the instance is terminated - so how can access the data stored on EBS.
Sorry for the ignorant question but just starting to play with EC2
Thanks
I'm assuming you've created an EBS-backed instance and added to that (attached) a further EBS volume as a chunk of extra storage. In which case, when you terminate the instance, the boot EBS volume is released and deleted, but attached EBS storage is only released - it remains in the 'Available' state after the instance has been destroyed and its' data contents are left intact. You can then access whatever is on it by simply attaching it to another running instance.