RightScale Blog

Cloud Management Blog
Cloud Management Blog

DNS, Elastic IPs (EIP) and How Things Fit When Upgrading a Server

Amazon's new Elastic IP (EIP) addresses allow users to allocate an IP address and assign it to an instance of their choice. What's really cool is that each IP address can be reassigned to a different instance when needed. For example, if the first one failed or if a new one is supposed to take its place.

Before going into an example, let's review how the Elastic IPs work:

  • You can allocate up to 5 Elastic IP addresses per account (default).
  • Each EIP can be assigned to one instance, in which case it replaces the normal dynamic IP address. Remember, by default, each instance starts with a dynamic IP address.
  • Each instance can have only a single external IP address. It starts out with the default dynamic IP address which can be swapped out for an EIP at any time. If the EIP is deassigned (or assigned to a different instance) then a fresh dynamic IP is allocated for the instance. The limitation of designating a single IP at a time is due to the way NAT (Network Address Translation) works. Remember that each instance has an internal IP address and an external (public) one, which is translated to the internal one. If two external IPs were translated to the same internal IP then inbound packets would arrive fine, but sorting out outgoing packets (i.e. determining which external IP address to assign to outgoing packets) would be very difficult. Hence, the limitation of a single external IP address per instance at any given point in time.
  • EIPs are free while they are assigned to an instance, but they cost $0.01/hr if they are not assigned. The reason for this charge is due to the fact that the number of IP addresses worldwide is very limited. Perhaps in theory, this charge will help prevent users from hogging unused IP addresses that could be dynamically allocated to other users. Yet, in a weird way there is no additional cost to Amazon for an assigned static IP as opposed to a dynamic IP because while an EIP is assigned to an instance it actually frees-up a dynamic IP.
  • Assigning or reassigning an IP to an instance takes a couple of minutes, which is longer than I would have hoped for, but I can imagine that many network devices need to be updated in the infrastructure to make it all happen.

Let's look at a simple example of an application server running Apache and a PHP app, talking to a back-end MySQL database server and how Elastic IPs can improve the process of updating the site. First we allocate an Elastic IP. Suppose we get 172.168.5.6 assigned. Then we set up the DNS in our preferred outsourced DNS service and map our website name to the IP address, e.g. www.rightscale.com -> 172.168.5.6. Having done that, we can launch our web server and database server. Once the web server boots and we have the website running, we assign it the EIP and can soon thereafter point our browser to www.rightscale.com. Here's how this looks:

Elastic IP address on EC2

Now suppose we want to update from our current production release of the website (we called it rel2 in the diagram) to rel3. The power of the cloud is that we don't need to touch our existing web server and risk causing damage during the upgrade process. Instead we launch a second web server (shown in the diagram below as www_rel3) and install the new release on it. We can point a different DNS entry, such as test.rightscale.com, at the default dynamic IP provided for the instance by EC2 and test the site to make sure everything works properly.

Elastic IP address with additional test server

Once we're confident in the new test version, we simply reassign the EIP 172.168.5.6 to the www_rel3 instance and shortly thereafter all users accessing the site are now receiving data packets from the new release. Remember, as long as the www_rel2 is available, you can easily swap back and forth between www_rel2 and www_rel3 until you are completely satisfied with the new site. And when you're ready, you can terminate the old www_rel2 instance. See diagram below.

Elastic IP address switch to new server

Amazon did a nice job in creating something much more powerful than simply adding "static IPs" to their offering. It is giving us dynamically remappable IP addresses that fit well into the overall cloud computing paradigm that we can use to manage servers better than with traditional hosting solutions.

The RightScale dashboard supports the new Elastic IPs, so all the operations described above are easy to initiate and monitor, even when using the free editions of the RightScale Dashboard. We are now in the process of updating our ServerTemplates so our customers can take full advantage of not only the Elastic IPs but also the new Availability Zones.

Comments

[...] About deploying upgraded code (releasing a new version for example) when you’re using cloud servers like Amazon’s EC2: “The power of the cloud is that we don’t need to touch our existing web server and risk causing damage during the upgrade process.” Just use a new server! That blows my mind :) [...]
[...] DNS, Elastic IPs (EIP) and how things fit together when upgrading a server « RightScale Blog [...]
Wow! I have been waiting for this for as long as I can remember.. Leave it to RightScale to quickly get us up and running using these services. Since we have many stores that we deliver packages to who allow us through their FW with a single static IP, we have had to have a separate server to deliver these very large packages. So they come from AWS, use our internal server as a bridge and then deliver to our distribution network, all the while dinging us with a double bandwidth charge.. with EIP, we can now deliver directly from EC2 .. I can't say how happy this makes me! here is the link for more info on EIP http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1346
[...] DNS, Elastic IPs (EIP) and how things fit together when upgrading a server « RightScale Blog [...]
Could you explain how Elastic IP's are different from the Dynamic DNS and load balancing services RightScale was already offering. Couldn't we already do this kind of remapping with those services?
Posted by Jason Horman (not verified)   Ι   March 27, 2008   Ι   08:36 AM
[...] blog post points to a useful series of new articles on EC2 by the team at RightScale: DNS and Elastic IPs and how they come in to play when upgrading a server, setting up a fault-tolerant site using the Availability Zones, and now support the new Elastic IP [...]
Jason: when a browser accesses a web page there is a two step mapping that occurs (simplifying things a bit): first it DNS resolves the hostname to an IP address, say blog.rightscale.com to 72.233.2.54, and then packets to that IP address get routed to a specific host. When talking about fail-over and load balancing, one can play with both mappings and often they work best in combination. Elastic IPs allow you to change the IP->host mapping while dynamic DNS allows you to change the hostname -> IP mapping. Changing the DNS-to-IP mapping is technically simpler in many ways (it's a simple lookup) but there are issues with propagation time to browsers and lack of control over browsers. Changing the IP-to-host mapping is technically more difficult because it affects routing tables across the internet and carries baggage such as subnets, but once the change is made the packets flow without the clients (browsers) needing to know. To come to our offering, the DNS based fail-over and load balancing we've been offering has worked extremely well in practice, but there were a number of corner cases that could have undesirable side-effects. By combining what we already have with the Elastic IPs we get a much cleaner solution.
I agree that Elastic IP is great solution from Amazon. Charging $0.01 /hr when we don't use it, I think it is too much for me. Since the deployment process may take up for days.
IP: you're complaining about a 1 cent a day charge? If you're spending days to deploy, why would you be holding onto an elastic IP? Just don't allocate it until you need it. And if the deployment process did take 10 days and if you did allocate the IP at the start, you are concerned about a two bucks plus change charge??? Maybe I overlooked the smiley at the end of your post? ;-)
I've tried this technique in practice for upgrading a server on a site with live traffic and I've found that it does not work as you describe. Using your terminology, this is what I've experienced: 1) I assign the live EIP to www_rel3 2) For 75 seconds, live traffic is still directed to www_rel2 3) Then for 75 seconds after that, requests to www.rightscale.com go NOWHERE. Users get an error saying the browser cannot be found 4) Finally, traffic started getting routed to www_rel3, as expected. The problem is part 3. I had always assumed that the switch was clean--either traffic would go to the old server or the new server, but it wouldn't get lost. Have you experienced that? How do you handle upgrades? Thanks.
Posted by ajay (not verified)   Ι   August 02, 2008   Ι   01:57 PM
err... browser = server in the comment above.
Posted by ajay (not verified)   Ι   August 02, 2008   Ι   01:58 PM
[...] been gathering data. I’m about to start doing a lot of work on EC2. I am curious about RightScale’s suggested upgrade technique, and also the criticism that appeared in the comments: Once we’re confident in the new test [...]
Suppose we get 172.168.5.6 assigned. Then we set up the DNS in our preferred outsourced DNS service and map our web site name to the IP address, e.g. www.rightscale.com -> 172.168.5.6. Having done that, we can launch our web server and database server. ____________ Allen

Post a comment