Support: 1-800-961-4454
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
  • Jonathan Bradshaw

    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)

    • Nicolas Keller

      Jonathan,

      You are correct – the Private interface still needs firewalling

      -nicolas

  • http://irondog.org Brennan

    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

    • http://adrianotto.com Adrian Otto

      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

  • duplabe

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

    • Nicolas Keller

      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

      • duplabe

        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.”

        • John

          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.

          • John

            I’ll take that back.

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

  • Adriaan Peeters

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

    • John

      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.

  • http://pulseenergy.com Chuck Clark

    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,

Racker Powered
©2014 Rackspace, US Inc.