I have a EC2 micro instance(ubuntu) running with tomcat and apache installed .
I am confused what happens if the system crashes , or shuts down. or If i stop it.
Will i have to install and configure all the packages(tomcat,apache) again on the instance , or will the instance on restart or reboot will have all these packages in the pre-stop state?
I know micro instance uses EBS for storage. And I assume on stop it maintains the state (i.e. it is not deleted). is it?
So on restart only the IP address changes right?
Or do i need to configure the instance again.
You are pretty much spot on with all your assumptions:
All EBS backed instances retain their installation state and configuration, which under normal circumstances shouldn't ever have any parts located on the (often called ephemeral) instance store volume(s), if any (see Root Device Storage Concepts for a detailed explanation of the differences between EBS and instance store backed AMIs).
Given the Amazon EC2 Instance Type t1.micro is EBS storage only indeed, this is guaranteed in your case.
Interestingly EBS storage only also applies to the newest regular instance types m3.xlarge and m3.2xlarge btw., so AWS might be slowly moving away from instance storage eventually.
Likewise, on restart only the IP address changes, be it a default public one or an Elastic IP address, see e.g. the FAQ Do I need one Elastic IP address for every instance that I have running?:
No. You do not need an Elastic IP address for all your instances. By
default, every instance comes with a private IP address and an
internet routable public IP address. The private address is associated
exclusively with the instance and is only returned to Amazon EC2 when
the instance is stopped or terminated. The public address is
associated exclusively with the instance until it is stopped,
terminated or replaced with an Elastic IP address. [...] [emphasis mine]
Please note that EC2 instances started within an Amazon VPC slightly differ here, insofar they don't have get a default public IP address and do retain an Elastic IP address (if any) throughout a stop/start cycle.
Related
Yes, I read an article by Eric Hammond here where he mentions that the private IP would also change when restarting. A few months ago, when I first got an AWS cluster up for hadoop, I used the internal IP to configure /etc/hosts and the internal IP wouldn't change (even when the instance is stopped, i can see the internal IP).
To replicate this cluster as part of our corporate account, I created a few AMIs and used those to launch the instances. Now, the IPs are changing each time the machine is restarted.
On checking the machines that did not have the IP change, there doesn't seem to be anything special about them. They are the same simple EBS backed instances with volumes. Hmm, so what's the difference between them?
Check whether your EC2 instance is inside a VPC or not.
Instances inside VPC will retain their private IP addresses when stopped and restarted. But instances outside VPC (ie. EC2-Classic) will change their private IP address when stopped and restarted.
Unfortunately, it's not possible to move an EC2 instance from EC2-Classic to EC2-VPC. However, in many cases, you can create an AMI image of the instance and launch a new instance from the AMI inside the VPC.
I'm testing a Hadoop cluster with juju and Amazon EC2, and I would like to know how could I stop a cluster and then start it again, manteining the cluster configuration.
The problem is that after start the instances again the public addresses changes, and the juju-status command shows the machines are down.
The problem is that after start the instances again the public addresses changes
Above is true for EC2 instance. Its Public IP address changes when it is stopped and then started.
To avoid this, you have 2 options:
use Elastic IP. You can attach an EIP to you instance so that the instance will have the same IP address accross the start/stop cycles. Caveat: you can get only 5 EIPs per account.
To get rid of above limitation of 5 EIPs per account, you can setup your cluster in side a VPC where all your instances will have a private IP address and it will remain same across start/stop cycles. But you have to understand how VPC works in order to use that. Please read this.
Initially my issue was "How do I RDP into an EC2 instance without having to first find its ip address". To solve that I wrote a script that executes periodically on each instance. The script reads a particular tag value and updates the corresponding entry in Route53 with the public dns name of the instance.
This way I can always rdp into web-01.ec2.mydomain.com and be connected to the right instance.
As I continued with setting up my instances, I realized to setup mongodb replication, I will need to somehow refer to three separated instances. I cannot use the internal private ip addresses as they keep changing (or are prone to change on instance stop/start & when the dhcp lease expires).
Trying to access web-01.ec2.mydomain.com from within my EC2 instance returns the internal ip address of the instance. Which seems to be standard behaviour. Thus by mentioning the route53 cnames for my three instances, I can ensure that they can always be discovered by each other. I wouldn't be paying any extra data transfer charges, as the cnames will always resolve to internal ip. I would however be paying for all those route53 queries.
I can run my script every 30 secs or even lesser to ensure that the dns entries are as uptodate as possible.
At this point, I realized that what I have in place is very much an Elastic IP alternative. Maybe not completely, but surely for all my use cases. So I am wondering, whether to use Elastic IP or not. There is no charge involved as long as my instances are running. It does seem an easier option.
What do most people do? If someone with experience with this could reply, I would appreciate that.
Secondly, what happens in those few seconds/minutes during which the instance loses its current private ip and gets a new internal ip. Am assuming all existing connections get dropped. Does that affect the ELB health checks (A ping every 30 secs)? Am assuming if I were using an Elastic IP, the dns name would immediately resolve to the new ip, as opposed to say after my script executes. Assuming my script runs every 30 secs, will there be only 30secs of downtime, or can there possibly be more? Will an Elastic ip always perform better than my scripted solution?
According to the official AWS documentation a "private IP address is associated exclusively with the instance for its lifetime and is only returned to Amazon EC2 when the instance is stopped or terminated. In Amazon VPC, an instance retains its private IP addresses when the instance is stopped.". Therefore checking nevertheless every 30s if something changed seems inherently wrong. This leaves you with two obvious options:
Update the DNS once at/after boot time
Use an elastic IP and static DNS
Used elastic IPs don't cost you anything, and even parked ones cost only little. If your instances are mostly up, use an elastic IP. If they are mostly down, go the boot time update route. If your instance sits in a VPC, not even the boot time update is strictly needed (but in a VPC you probably have different needs and a more complex network setup anyways).
Another option that you could consider is to use a software defined datacenter solution such as Amazon VPC or Ravello Systems (disclaimer: our company).
Using such a solution will allow you to create a walled off private environment in the public cloud. Inside the environment you have full control, including your own private L2 network on which you manage IP addressing and can use e.g. statically allocated IPs. Communications with the outside (e.g. your app servers) happens via the IPs and ports that you configure.
I want to use the Amazon Web Service free micro-instance for my different projects for testing and personal purpose. But I required some static-public IP on which I can run my server.
Is that possible? From where I can buy just IP and use it with my AWS?
EC2 Elastic IP Addresses
Elastic IPs are tied to an account, not an instance.
You need to look at AWS VPC for this.
Whilst VPC is free outside of the usual instance pricing, it doesn't work with Micro instances (the cheapest ones).
When not using VPC, you're assigned IP addresses through DHCP. When the DHCP lease expires, or you restart, your IP is released back to the pool.
VPC lets you use private IP addressing, you can use it with Elastic IPs and is much easier to integrate with a physical infrastructure setup.
If you're only testing/investigating AWS and have little or no budget to use anything other than a Micro instance, I'd just suck it up and deal with the changing of IPs.
If you've got a budget that lets you use instances other than Micro, then go for VPC.
Also, if you're doing more than testing/investigating I'd recommend starting with VPC straight away as trying to migrate from a non VPC to a VPC infrastructure is a massive PITA.
For every AWS account, 5 free elastic ips are provided. You have to just allocate them to required instance. But make sure that the allocate address(newly created elastic ip) in in use, because you will billed if the Elastic ip is not in use.
Looks like they have configured ARP statically so you can only use the IP address on an instance that was bound to that instance through the EC2 management console.
I just configured one of my instances to use a static IP address other than the one assigned through the management console and rebooted the instance.
I'm still receiving ARP responses on the old address but not receiving ARP responses on the new address at all.
Unfortunately for me, I have a not responding instance (NFS File Server) stuck in a stopping state while I attempt to terminate it.
The IP Address bound to that instance cannot be re-assigned to a replacement instance so now I have to reconfigure
On the whole pricing delima: When you come to think of it, there is a limited amount of static IPs so there must some pricing (supply and demand). This pricing is two fold: 1) for upto a limited number (5 per account) you don't have to pay. 2) if you created one you need to use it if you don't you'll be billed (to prevent every user to get 5 static IPs)
Has anyone experienced your elastic IP going bananas?
I set up an elastic IP and it just went crazy so my instance was unavailable, in the end I had to terminate it...
I couldn't get hold of any logs och reports, feels very very strange...
Thanks!
An EIP (Elastic IP) address is nothing more than a reserved address which is assigned to your EC2 account, and which you can allocate to any running VM you own.
There isn't anything to 'go crazy' with an EIP, since it is an inert object - when not assigned to a VM it does nothing but cost you a tiny amount of money, and, when assigned, its' cost drops to zero and the VM switches its' default address out and assumes the EIP instead.
The IP cannot go "bananas". Look the AWS console for the public DNS of the server. Try connecting using that instead of the elastic IP. If connecting using that fails then it is the instance itself that is that problem.
If that works, then how long did you leave between attaching the IP and trying to connect (i.e. what are the timescales on this problem)?