Monday, October 28, 2013

Software Defined Networking Within the Adapter

Today cloud servers can host many Virtual Machines (VMs). When you add to that an advanced 10Gb Ethernet adapter, the adapter can become an in-server layer-2 network switch between all the hosted VMs on that server.  This enables two VMs on the same server to pass traffic between them using traditional network interface techniques without ever actually going out to a physical network. This technique is known as intra-VM switching.  A second interesting new performance feature is one called hypervisor bypass that enables the VMs to access the network via virtual functions (VFs) without involving the hypervisor after the connection is established. While both of these features can dramatically improve performance they also create new challenges. One of these is that by not having traffic going through a real network switch it short circuits some of the latest developments in Software Defined Networking (SDN). If you haven't read much on SDN lately, it's all the buzz in networking, and Bruce Tolley's presentation "SDN: Science Project or Promised Land for the Networking Industry" frames the topic well. In these slides he states that Dell'Oro forecasts the impact of SDN on the switch market going from $498M in 2013 to $2,200M by 2017.

Why might all this be important? Here is one example from a patent (#8,352,953) issued to IBM earlier this year for an application titled "Dynamically Provisioned Virtual Machines." Four years ago IBM proposed a framework for software running on the network switch to keep track of how chatty all the VMs are on each node connected to a switch then to use this information to move the busiest VMs to least busy compute nodes. Pretty clever huh. With intra-VM switching though the network switch isn't aware of any of the VM to VM traffic being passed within that server node so the switch never sees a full picture of what's really going on.  Imagine  if you will a classroom full of students. Suppose the students in this class were texting each other with their questions and answers, and that the teacher was only aware of questions asked of her.  If the traffic between students was high, and the teacher only had a few students raise their hand with questions then the teacher might come to some very wrong conclusions. So how can we fix this situation?  

Turns out Solarflare's adapters have technology to address this. The first is Open Flow 1.0 control support. In a project with NEC, Solarflare provided an open API to create an Open Flow controller that enables an open flow mesh which includes the hypervisor resident vswitch. Furthermore Open Flow 1.0 control support enables Solarflare to place a layer-2 overlay onto a layer-3 network to enable VM migration across the datacenter while preserving all the network links to the VM.

More on this topic soon in "SDN Within the Adapter Revisited"

No comments:

Post a Comment