Support: 1-800-961-4454
Sales Chat
1-800-961-2888

Networking and Cloud Servers – More On The Interfaces

12

Last week, I mentioned that each and every Cloud Server 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, 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/)

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. For the first 10 ideas received, I will get marketing to send you a Rackspace Cloud t-shirt!

About the Author

This is a post written and contributed by Nicolas Keller.


More
12 Comments

You might want to elaborate on the private interface should also be firewalled by your cloud server since it is not private to your account, i.e. someone else with a cloud server could connect to that interface (please correct me if I am wrong)

avatar Jonathan Bradshaw on February 23, 2010 | Reply

Jonathan,

You are correct – the Private interface still needs firewalling

-nicolas

avatar Nicolas Keller on February 23, 2010

Does this mean that, using existing, deployable apps such as mysql proxy will make my cloud hosted site scale better? We just switched http://irondog.org over to a rackspace cloud hosting account, hoping to get past database connection errors caused by trying to scale a large wordpress site. We’ve already got gzip compression and caching enabled, but the wall we are hitting is the number of database conenctions (why we shifted to cloud).

I gather a couple of the rackspace cloud guys are working on cassandra as a scalability solutions, but our traffic spike is NOW. This blog post makes it sounds like multiple cloud hosting accounts + load balancing is the way to go. Do you think this solution would work for a site that is getting 100K pageviews / 15K visitors per day?

Keep growing the open cloud! –
brennan

avatar Brennan on February 23, 2010 | Reply

Brennan,

In general mysql proxy does not help you break scalability boundaries. Because it buffers its query results before relaying them back to the client it actually increases the average query duration which drives up the number of concurrent queries. More concurrency means even more pressure on the mysql server, which means lower performance because of reduced overall throughput.

To answer your question in general, the answer is yes. You do get better performance from a proxy arrangement on Cloud Servers because you are splitting the data flow across two separate ethernet ports. Running it on one of our competitor’s solutions where there is only one physical interface does not work well if you’re shoveling a whole lot of data around.

Solving your individual concern is beyond the scope of comments on this blog post, but I’d be happy to reach you through email and offer you some guidance. We can make a new post that tells the story about what the problem was and how we solved it as a future entry on the blog.

Adrian

avatar Adrian Otto [Racker] on February 24, 2010

When my webapp on cloud server upload something to cloud files with python api is there any option to use private interface?

avatar duplabe on February 25, 2010 | Reply

Definitely, here is the trick:
Prepending ’snet-’ to the X-Storage-Url returned during the initial authentication request via the API will direct all requests to the Private interface. Example: If the auth request return is “X-Storage-Url: https://storage4.clouddrive.com/v1/MossoCloudFS_ee33dbcb-578e-4cd9-b54a-8c6c898e63cd”, then sending requests to “https://snet-storage4.clouddrive.com/v1/MossoCloudFS_ee33dbcb-578e-4cd9-b54a-8c6c898e63cd” will allow for all Cloud server to Cloud Files communications to use the private interface (and bandwidth will be free)

Makes sense?

-nicolas

avatar Nicolas Keller on February 25, 2010

It is simple then I thought: the connection class’ init method accepts a servicenet argument: “Setting the argument servicenet to True will make use of Rackspace servicenet network.”

avatar duplabe on February 26, 2010

Tried that. It does not work.

I get the following error:

This website is temporarily unavailable. Please check back later.
Unfortunately there were no suitable nodes available to serve this request.

avatar John on March 17, 2010

I’ll take that back.

It works. However the error does occur when connecting from cloudsites. Cloudservers seem to work fine!

avatar John on March 17, 2010

Please also elaborate a bit on how to connect to Cloud Files using the private interface. Does the API automatically use the private ip?

avatar Adriaan Peeters on March 17, 2010 | Reply

I have the same issue. Apparently Rackspace has no solution as of yet. I’m using the cloud files API (http://github.com/rackspace/php-cloudfiles/tree) from cloud server and I’m unable to connect with unmetered bandwidth.

Seems like it’s a hard thing to implement on the cloudfiles end.

avatar John on March 17, 2010

It would be great if I am a customer of the Managed Rackspace Server division if I could leverage Cloud Servers without having to worry about metering data sent into and out of the cloud. We would like to fire up a few Cloud Server instances to run analytics on the data we collect but it would all come in over the public IP. Is there any plans in the future to get easy and free transfer of data between the Cloud and the Managed offering?

thanks,

avatar Chuck Clark on March 17, 2010 | Reply

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.