Hi i had created a ubuntu cloud instance for about 8Gb.Now i require to increase the size to say 32Gb.Any idea how to proceed will be much helpful.
If you do not care about downtime, you can take a snapshot from your EBS volume and create a new volume from this, specifying a larger EBS size and attaching it to another instance. Keep in mind that you may have to enlarge your file system on it, too.
A detailed description of this can be found here.
Related
I have a golden image pipeline running without problem backed by an EBS volume, but trying to create the same for an instance store backed ami seems to always produce the same error. The issue is that the imagebuilder pipeline continuously attempts to tag a non-existent EBS volume and therefore fails;
Reason for failure:
You cannot specify tags for EBS volumes if there are no EBS volumes being created by the request.
The base image is ami-08d82c356d670cf9c which has the root device type INSTANCE-STORE, and there are no tags applied anywhere in the pipeline (not in the configuration, distribution, recipe or infrastructure). There is little documentation regarding a golden image using instance storage and any attempt to create one results in the same failure.
Does anyone have an idea on where this application of tags is taking place in the process in order to avoid it?
Thanks
Confirmed with AWS that Image Builder does not support the use of AMIs backed by instance store, as they use ec2:CreateImage which does not support it, and also requires the instance to be shut down to create an image.
I am trying the Alibaba Cloud, ECS instances and after doing some configuration I would like to persist that so that if I want to rollback the Instance after certain period I can start from the last checkpoint. What I want to understand is if Taking a SnapShot/Image on Free trial would cost me money ? or in other words if I create an image or snapshot would that be chargeable, if yes then how much would it cost to me for each snap shot or image?
Best Regards
As per the mentioned terms while creating image -
When you create an image, a snapshot will be created as well. Because
the snapshot service is now a paid service, your images will incur
snapshot fees.
When creating a custom image with Linux system, please
do not load data disk information in the /etc/fstab file. Otherwise,
you cannot launch the instance created through the image.
You can create a complete image template for the current ECS instance,
including all its disks. A new snapshot will be taken for each
instance disk and can be viewed in the snapshot list. You must wait
for the snapshots for each disk to be created before the image can be
used. Please be patient.
So yes taking snap shot or creating image has cost associated with it, how much cost is dependent on how much resources has been associated with it. Please refer to below screenshot for the reference -
As per the official documentation, snapshots service is free of charge. You can reaffirm this with the following figure of their documentation.
I couldn't find the answer on EC2 documentation. What is it for? If I launched an EBS backed instance, the root device for the instance would be an EBS volume. If I install a few tools/software on the instance, will those be installed on the root instance by default? Still I guess the question really came from the little understanding of the root device. Any detailed info on that?
Also if I need to launch another EBS backed instance, and also want to have the same copy of the tools/software installed on the earlier instance, how to do that?
EC2 instances have two types of storage -- ephemeral storage, and EBS based storage -- and each instance is given a specific amount of that disk space by default. Each instance has its own allotment of disk space that it can use which is independent of any other instances disk space that you launch. You can also add an EBS volume to your drive for additional storage, but, those volumes can only be attached to one specific host at a time.
If you had two EBS instances, and you wanted to ensure that they're both using the same tools and software, you'd need to enforce that using a configuration management tool, such as puppet, chef, or cfengine.
I agree with what Ian wrote. I would add that the "root device" in EC2 is analogous to the operating system partition in a personal computer. It is where the filesystem of your OS resides.
This is the best answer about 'root device' so far! AWS is still new. And most of the times, the answer is just 'cut and paste' straight from AWS document, which does not help much!
https://web.archive.org/web/20140601070714/https://skeddly.desk.com/customer/portal/articles/1346918-ebs-backed-versus-instance-store
This may have been added since you asked, but I believe this answers the question:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html
I have a Windows 2008 EC2 instance to which I have done some customizing on the EBS boot drive.
I started the instance as m1.small (or m1.large) and the instance storage does not appear as an additional drive.
I've read that the -b switch in the ec2-run-instances command allows you to create mappings for the ephymeral instance storage. The ec2-run-instances command creates a new instance, however, in my case, the instance already exists and therefore I start it as ec2-start-instances, which does not have a -b switch for ephymeral instance storage.
Is there any way I can get to the ephymeral instance storage that comes with an m1.small instance for my existing EBS-booted instance?
UPDATE: It seems that nowadays (Feb 2015) Windows machines mount ephymeral instance storage in the Z: drive.
I'm afraid this functionality isn't available (yet) for Amazon EC2, but it's a very good question in fact - the common answer used to refer to the explicated launch time requirement, see e.g. ec2-modify-instance-attribute:
Note
If you want to add ephemeral storage to an Amazon EBS-backed instance,
you must add the ephemeral storage at the time you launch the
instance. For more information, go to Overriding the AMI's Block
Device Mapping in the Amazon Elastic Compute Cloud User Guide, or to
Adding A Default Instance Store in the Amazon Elastic Compute Cloud
User Guide. [emphasis mine]
That hasn't been that much of an issue in the past, but given the recent introduction of 64-bit ubiquity implies a significant improvement of vertical scaling versatility (see EC2 Updates: New Medium Instance, 64-bit Ubiquity, SSH Client), this is suddenly a topic indeed - your question yields even more questions in turn:
What happens for the converse case, i.e. when I start a sufficiently large instance with lots of ephemeral storage and scale it down (and possibly up again) thereafter?
In case the initial block device mapping is retained somehow, should we always start with a large instance therefore? (I actually doubt that this is the case though.)
This question can only be addressed by the AWS team I guess, so you may want to file a support request or relay the question to the Amazon Elastic Compute Cloud forum at least.
I think what you're asking (but correct me if I'm wrong) is "how do I add additional storage to an EC2 instance?".
In which case, the answer is:
Select the Volumes panel in the AWS console and create a new volume of the size you want, making sure it's in the same Availability Zone as the instance you want to attach it to. Then select that new Volume, and click 'Attach' - select the instance you want to attach it to, and click OK.
Now log-on to the instance, and in Computer Management select the Disk Management plugin, format the new unassigned partition, and give it whatever drive letter you wish. It will then show up in Explorer as a standard Windows drive.
I spent the day experimenting with AWS for the first time. I've got an EC2 instance running and I mounted an Elastic Block Store (EBS) to keep the MySQL databases.
Does it make sense to also put my web application files on the EBS, or should I just deploy them to the normal EC2 file system?
When you say your web application files, I'm not sure what exactly you are referring to.
If you are referring to your deployed code, it probably doesn't make sense to use EBS. What you want to do is create an AMI with your prerequisites, then have a script to create an instance of that AMI and deploy your latest code. I highly recommend you automate and test this process as it's easy to forget about some setting you have to manually change somewhere.
If you are storing data files, that are modified by the running application, EBS may make sense. If this is something like user-uploaded images or similar, you will likely find that S3 gives you a much simpler model.
EBS would be good for: databases, lucene indexes, file based CMS, SVN repository, or anything similar to that.
EBS gives you persistent storage so if you EC2 instance fails the files still exist. Apparently their is increased IO performance but I would test it to be sure.
If your files are going to change frequently (like a DB does) and you don't want to keep syncing them to S3 (or somewhere else), then an EBS is a good way to go. If you make infrequent changes and you can manually (or scripted) sync the files as necessary then store them in S3. If you need to shutdown or you lose your instance for whatever reason, you can just pull them down when you start up the new instance.
This is also assuming that you care about cost. If cost is not an issue, using the EBS is less complicated.
I'm not sure if you plan on having a separate EBS for your DB and your web files but if you only plan on having one EBS and you have enough empty space on it for your web files, then again, the EBS is less complicated.
If it's performance you are worried about, as mentioned, it's best to test your particular app.
Our approach is to have a script pre-deployed on our AMI that fetches the latest and greatest version of the code from source control. That makes it very straightforward to launch new instances quickly, or update all running instances (we take them out of the load balancing rotation one at a time, run the script, and put them back in the rotation).
UPDATE:
Reading between the lines it looks like you're mounting a separate EBS volume to an instance-store backed instance. AWS recently introduced EBS backed instances that have a ton of benefits vs. the old instance-store ones. I still mount my MySQL data on a separate EBS partition, though, so that I can easily mount it to a different server if needed.
I strongly suggest an EBS backed instance with a separate EBS volume for the MySQL data.