RightScale Blog

Cloud Management Blog
Cloud Management Blog

RightScale for Amazon EC2 Elastic IP Address & Availability Zones

The cloud is accelerating past terrestrial hosting!

Today, Amazon unveiled some major upgrades to its service: Elastic IP addresses, Availability Zones, and selectable kernels. The first two are particularly important because they not only eliminate one of the remaining deficiencies of the service, but provide better functionality than what is currently available in common hosting services. RightScale supports the new features concurrently with Amazon's launch. Not only that, but we've added the new features to the free developer edition as well, which means that RightScale is hands-down the easiest way to experiment with the new Amazon EC2 features. Here's a quick review of what's available now through RightScale:

Create "Static IPs" on EC2 with Amazon's Elastic IPs

The Elastic IPs provide persistent IP addresses that can be assigned to instances. Many people have been asking us for "static IPs" - this is it. Through the RightScale interface you can allocate a static IP and give it a nickname, say "web server 1." When you launch your web server instance, you can then associate the IP with the instance once you have everything configured and running, and shortly, packets sent to that IP address get routed to the new instance.

If you then launch a fresh instance for an upgrade of your website, you can bring the new instance up separately from your production site, and set up the new version of your site and test it thoroughly. When you're happy with everything, you can reassign the IP address from the old instance to the new one, and within seconds your users will be accessing the new version of the site. (For a more in-depth description, see an earlier blog post.)

Should there be a problem, you can always reassign the IP back to the old instance while you fix the problem. This, by the way, is the power of cloud computing: you don't upgrade your server in place, you grab a new one, and you leave the old one running until you're sure the new one is stable and ready for production.

The Elastic IPs also provide a solution for numerous other situations where a fixed IP address is required. One example is when interfacing with third-party services such as data feeds where it is impractical to change the destination IP address of the feed whenever there is an instance change. Now, using an Elastic IP, the external feed can be configured once and for all. Another example is SMTP (email) traffic, which pretty much requires a static IP address. For inbound SMTP traffic the static IP address ensures that mailers around the world can safely deliver the traffic across instance changes. For outbound SMTP traffic the static IP ensures that spam filters don't discard the email because the IP is listed as dynamic or because of a prior user that sent out spam.

Better Fault Tolerance with Availability Zones

Availability Zones are a terrific new feature that gives you control over the fault tolerance of your server deployment. Each Availability Zone is a data center or a portion of a data center engineered such that the probability that more than one zone fails at a time is extremely small. Basically, if you have two servers in two different zones then they will not go down at the same time, barring a major catastrophe of regional extent. So power going out and generators failing, or a data center fire, or border router screwup will not affect multiple Availability Zones.

Users can use Availability Zones to engineer their deployments for an amazing degree of reliability. The most typical usage we foresee is to place the master database with all the app servers into one zone, and the slave (replica) database in a different zone. Should the primary zone fail, it's straightforward to promote the slave to master and relaunch the app servers in the same zone. (For a more in-depth example, see the earlier blog post.) Of course we will automate that in RightScale so our users don't have to worry about promoting these databases manually.

What's really exciting is that the combination of Elastic IPs and Availability Zones brings cloud computing to a different level. In the above example, when the app servers get relaunched in a new zone, EC2 allows the Elastic IPs that were associated with the app servers to be reassigned from the old servers in the failed zone to the new ones. So now traffic doesn't just get routed to new instances, it actually gets routed to a different data center. From the outside this may seem straightforward, but in reality the degree of engineering that is necessary to support this type of technical feature is staggering. Even if you had servers in multiple co-location facilities it is not easy to make the colos independent of one another. If they are close by physically they may well share regional Internet routes. Or worse, your own basic setup may introduce dependencies, for example at the DNS level, where one colo going down has impact on DNS used by the other colo. Being able to then move IP addresses from one colo to another one without residual dependencies requires sophisticated network engineering. With Amazon and RightScale, it's now just a drop-down menu away.

Support for Multiple Linux Kernels

The selectable kernels feature introduced by Amazon allows users to choose from more than the single Linux kernel that has been available thus far. It's one more step towards making EC2 a more flexible platform and keeping up with the Linux evolution.

Comments

[...] has also posted some tutorials on how to use the new features, including how to set up a fault-tolerant site. Written by: Mike | [...]
THAT WAS FAST. Did you guys know this was coming in advance?
PJ, I can't go into specifics, but I can say that we didn't spend much time sleeping the last 24 hours :-).
[...] new elastic ip feature changes the way you upgrade a production site: If you then launch a fresh instance for an upgrade of your web site, you can [...]
[...] RightScale supports the new Amazon EC2 Elastic IP addresses and availability zones [...]
"From the outside this may seem straightforward, but in reality the degree of engineering that is necessary to support this type of technical feature is quite staggering. Even if you had servers in multiple co-location facilities it is not easy to make the colos independent of one another. If they are close-by physically they may well share regional internet routes." You're right, rerouting individual IPs at the carrier/transit level to different geographic locations would be an amazing feat. Too bad Amazon's not doing that. You can only remap IPs to zones within a single region... "Elastic IPs are only remappable to instances in the same region. Currently, Amazon EC2 exposes only a single region, so your Elastic IPs can be mapped to any of your availability zones." -Brent@AWS http://developer.amazonwebservices.com/connect/thread.jspa?messageID=84376 The limitation implies that there is some kind of regional routing core infrastructure that could take down all your zones in that region if it suffered an outage. I expect all their really doing when you remap an IP is updating NAT tables somewhere. Useful? Yes. Staggering network engineering? No.
Posted by CBass (not verified)   Ι   March 28, 2008   Ι   11:16 AM
CBAss: you have a very good point, but I think you're oversimplifying also. I'll double-check with the Amazon folks, but as far as I know the "core routing infrastructure" is fault-tolerant within a region. If you look carefully at the NAT done by Amazon, it's stateless. This means that packets can come in & out multiple entry points. So if one availability zone goes down, there is some interesting stuff happening such that packets for your IPs can enter through other transit points into the region and go to a server in a different zone than previously. Even without the routing challenges, it's actually not so easy to keep such regional routing infrastructure failure isolated. It's pretty easy to set-up, but on a daily basis it's so easy to slip in innocent looking changes that compromise the isolation. At least that has been my experience as well as that of others. Thanks for the comment!
[...] Blog bookmarks 03/29/2008 RightScale supports the new Amazon EC2 Elastic IP addresses and availability zones « RightScale Blo... [...]
Uhh, does this mean you have a new public CentOS5 image you that supports this because the current one I'm using craps out with the new ec2 tools and won't launch with the latest 64bit kernel (--kernel aki-9800e5f1).
Posted by Ian (not verified)   Ι   March 31, 2008   Ι   12:58 PM
Did I overlook this? RightImage CentOS5_0_X86_64_V2_0 with the newness? Wish request: Make your dashboard wap friendly for Blackberry's and you'll rule.
Posted by Ian (not verified)   Ι   March 31, 2008   Ι   01:04 PM
I second Ian, any chance that you will be releasing the scripts to build rightimages from scratch based on the new AKI's?
Ian, we have not dealt with the new kernels in terms of images, we're still testing stuff. We'll make the scripts available as soon as we have something. The new tools should install automatically at boot time, so I'm not sure what the problem is. We focused on adding the support to the RightScale Dashboard (web site) so you can launch servers with the new features.
[...] Elastic IPs, which have now been around for a few months, completely solve the problem of not having a static IP address. Having been an avid follower of the latest AWS developments, it was the announcement of Elastic IPs in particular that started me thinking about moving my hosting to EC2. [...]
Sudi, you are correct that you're getting a lot of internet bandwidth potential with each EC2 instance. The pipes between EC2 and the net are very fat, so you can easily burst up to the full capability of each instance without prior arrangements.
How is data ( user files) moved ? I have seen some blistering download rates from Ashburn Va to Denver at approx 11M/s. Is the traffic moved through the Net or some other method ? Any assistance is greatly appreciated.
Posted by Sudi (not verified)   Ι   July 22, 2009   Ι   08:31 PM

Post a comment