Problem 1: The single IP endpoint. We can't change the client software stack on a dominant piece of deployed software like ESX. Scalability and performance have to be solved in a way that supports legacy protocols. IP-based storage protocols like NFS bake in an assumption that the server lives at a single IP address. In the past, people have built special-purpose hardware to terminate and proxy NFS connections in order to cache or load-balance requests, but SDN allows us to go further.
The NFS server implementation in our system includes what is effectively a distributed TCP stack. When a new NFS connection is opened to the single configured IP address, an OpenFlow exception allows us to assign that connection to a lightly loaded node in our system. As the system runs, our stack is free to migrate that connection, interacting with the switch to redirect the flow across storage resources. As a result, we are able to offer the full width of connectivity through the switch as a path between storage clients and storage resources. This approach is similar to proposals to use OpenFlow as the basis of load balancing, with the difference that it is the application itself that is driving the placement and migration of connections in response to its own understanding of how those connections can best be served.
This decoupling of client connections from a specific storage controller at the end of the wire solves an immediate scalability problem that until now has needed either interface changes on the client (NFSv4 delegation or PNFS) or complex administration (carefully splitting a namespace across several controllers). It also allows us to treat stored data as a completely fluid resource: as client connections can be moved in response to load and access pattern, so can the underlying data. As a result, OpenFlow provides the flexibility to dynamically adapt and scale the system over time.
Problem 2: High-performance multitenant isolation. I worked with one of my co-founders, Keir Fraser, to develop the Xen virtual machine monitor when we were graduate students at the University of Cambridge. When we were working on Xen, we spent a lot of time focused on the fact that a hypervisor really had a single job: isolated sharing. The hypervisor needed to take a server that was over-resourced for any single application and allow it to be safely shared among many concurrent tenants.
SDN is extending this isolated sharing for virtual machines out to the network. It's allowing the isolated sharing of network resources, as well as entire distributed systems of VMs to be provisioned and managed as a unit. In this regard, the VMs involved are actually just a resource above the virtual network that connects them. By the same measure, storage resources and data itself can be another such isolated resource.