Networking and Cloud Servers – More On The Interfaces

Filed in Cloud Industry Insights by Nicolas Keller | February 23, 2010 11:57 am

Last week, I mentioned that each and every Cloud Server[1] comes with two interfaces. In this post, I’d like to explore them.

The Public Interface

The first interface is the Public one (usually eth0 on a Linux system). This interface comes directly connected to the Internet and with one public IP address. It is also possible to request more public IP addresses (via ticket) and assign them to the interface. Having more than one IP address per public interface can be used to add multiple IP-based SSL certificates to a Cloud Server, or can be used to create virtual IP’s (more on this feature in my next post). Key fact to note about the Public interface: all traffic (incoming and outgoing) is metered and billed.

The Private Interface

In contrast, the second interface is the Private one (usually eth1 on a Linux system), which is configured with a private IP address (i.e., part of RFC 1918) and therefore not reachable from the Internet. Traffic over this interface is also unmetered, and therefore is free. Is this useful? Yes as the Private interface is connected to our “Services” network that, in addition of connectivity to Cloud Files[2], allow connectivity to any other Cloud Server Private interface. This allows building complex farms by, for example, configuring a Cloud Server as a load balancer, receiving Internet traffic over the Public interface and connecting web heads over the Private interface (see http://www.rackspacecloud.com/blog/2009/11/30/simple-load-balancing-on-cloud-servers/[3])

To summarize, there are two interfaces:
•    Public to communicate to/from the Internet
•    Private to communicate with other Cloud Servers or Cloud Files (and for free)

Furthermore and by design, we have pushed down separating the Private and Public interfaces down to the hardware layer. This means that all traffic going via the Public interfaces of Cloud Servers that are hosted on a physical machine will go via a separate Ethernet port than the one used for Private traffic. In practice, this allows protecting Private traffic from the hazards of the Internet; for example, a public DDOS will not be able to saturate inter server links, allowing a complex environment to maintain its network integrity even when under duress from an Internet attack. This separation approach also opens the door for us to start building additional network based services that will be protected from the Internet.

As I am wrapping my mind around what we are going to do next, I would love your input. Please send ideas to Nicolas.Keller_at_Rackspace.com[4]. For the first 10 ideas received, I will get marketing to send you a Rackspace Cloud t-shirt!

Endnotes:
  1. Cloud Server: http://www.rackspacecloud.com/cloud_hosting_products/servers
  2. Cloud Files: http://www.rackspacecloud.com/cloud_hosting_products/files
  3. http://www.rackspacecloud.com/blog/2009/11/30/simple-load-balancing-on-cloud-servers/: http://www.rackspacecloud.com/blog/2009/11/30/simple-load-balancing-on-cloud-servers/
  4. Nicolas.Keller_at_Rackspace.com: mailto:nicolas.keller@rackspace.com

Source URL: http://www.rackspace.com/blog/networking-and-cloud-servers-more-on-the-interfaces/