This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - Weighing the pros and cons of data center SDN: Read more in this section
- Examining the benefits of data center SDN technology
- How software-defined networking changes infrastructure
- Reasons to adopt SDN in the data center
Explore other sections in this guide:
- 1. - To outsource or not to outsource IT? What makes the most business sense?
- 2. - Does converged infrastructure fit in your data center business plan?
- 4. - How virtualization techniques can streamline data centers and businesses
This article can also be found in the Premium Editorial Download "Modern Infrastructure: Software-defined networking (SDN) may face obstacles in data center adoption."
Download it now to read this article plus other related content.
Software-defined networking is all the rage these days, but is it right for your data center?
SDN chatter is seemingly everywhere, offering the promise of a virtual network infrastructure that can be provisioned as easily as setting up a new virtual server. But real-world SDNs are hard to find outside of a few marquee customers who have dedicated lots of operational resources to set them up and manage them. Let’s look at their history, where things stand today, some of the bigger obstacles to SDNs and how you can begin to plan for them in your own environment.
SDN isn’t a new idea by any stretch. SDN is a form of network virtualization, and indeed, we have had various forms of network virtualization for more than a decade.
However, SDN is distinct from networking virtualization, and vice versa, wrote Martin Casado, CTO and Bruce Davie, chief service provider architect, both of Nicira Networks.
“It is quite possible to have [a] network virtualization solution that doesn’t use SDN, and to use SDN to build a network that has no virtualized properties,” they blogged this spring. Nicira was acquired by VMware in July.
Source: Open Networking Summit blog
A good working definition of SDN is that it’s the separation of the data and control functions of today’s routers and other Layer 2 networking infrastructure, with a well-defined programming interface between the two. In contrast, most of today’s routers and other networking gear mix the two functions, making it hard to adjust network infrastructure as we add tens or hundreds of virtual machines (VMs) to our enterprise data centers.
Separating the data and control planes has big implications for network design, wrote John Strassner, Group CTO for the Software Labs of Huawei’s American Research Center, on the SDN Central blog. When control plane and data plane functions can be on different hardware, “this in turn enables both to match the implementation requirements to the best combination of hardware and software available,” wrote Strassner. “This would enable pools of resources to offer different types of controllers and forwarding elements—some smarter, some dumber, some simple building blocks in order for smart designers to build their own, application-specific controllers.”
How SDN Helps
Done right, SDN can address several common challenges of modern data center networks. One is that as virtual servers proliferate, provisioning the rest of the network infrastructure—such as connections, routers, firewalls and the like—still takes a long time.
“People have forgotten that it used to take two months to provision a server, and now it takes less than two hours or even minutes. But it still takes two weeks to provision a network, and that isn’t tolerable,” said Joe Skorupa, a Gartner analyst.
Network scalability isn’t keeping up with its storage and computing counterparts. One solution used to be setting up virtual LANs to handle the virtual server collections. “That was a good first step, but no longer,” said Eric Hanselman, an analyst with the 451 Group. “Network utilization levels have become a stumbling block now in data centers.” That’s because VLAN connections are complex and don’t scale easily.
“Most people can’t keep up with the networking changes needed when they add lots of VMs,” said Hanselman. “Getting network automation to work at the same scale as exists in compute and storage has been a challenge.”
“The problem is that today’s networks are bigger and growing faster and [are] harder to manage,” says Dennis Brouwer, senior vice president for network products and marketing for the enterprise markets group at CenturyLink, a managed IT infrastructure provider with thousands of VMs around the world across multiple data centers. The firm is currently evaluating SDN for use in both its WAN and inside its data centers.
The second related issue is how to gain programmatic control over how these networks are set up and torn down as the number of VMs waxes and wanes. SDN technology could enable that by providing APIs so that programs can control the underlying network infrastructure. SDN may also pave the way for enterprises to adopt hybrid clouds, providing management and security while organizations mix on-premise data centers with third-party providers and partner networks.
Inventing and Standardizing SDN
The origins of the modern SDN came about through a series of efforts centered around two computer science professors, Nick McKeown at Stanford and Berkeley’s Scott Shenker, along with several grad students, including Nicira’s Casado. The project was called Ethane and began more than 15 years ago to try to improve network security with a new series of flow-based protocols.
One of the first SDN efforts was the specification of a new networking protocol called OpenFlow. Backed by Stanford and other university researchers, the protocol has received wide support from Facebook and Google, both of which use it today to run their networks and data centers.
Google in particular uses OpenFlow to significant effect, said analyst Hanselman. “Google has been using OpenFlow for the better part of several years on its own operations,” he said. “They have built their own physical routing infrastructure with OpenFlow…shifting the number of network interconnects between data centers to make capacity shifts as loads change during the day.”
The OpenFlow protocol version 1.0 was specified in December 2009, and versions 1.1 and 1.2 were released in February 2011 and February 2012, respectively. Last year, the Open
Networking Foundation (ONF) formed and took over responsibility for the standardization process.
Having ONF in this role is both a blessing and a potential curse for SDN. The upside is being able to conduct public interoperability demonstrations, such as the one at Interop in May 2012.
But having ONF lead the OpenFlow project brings up bad déjà vu in some circles. In January 2012, Gartner issued a report on the project that compared OpenFlow’s progress with that of Asynchronous Transfer Mode (ATM) in the mid-1990s.
That ATM technology seemed like a potential game-changer, offering new protocols and technology leaders. But the related ATM forum didn’t encourage interoperability and adoption as it was designed to. “Entrenched vendors complicated the specifications and delayed completion of the standard for years, effectively killing the threat to their existing Ethernet/IP business,” according to the Gartner report. “We expect similar gamesmanship to be attempted within the Open Networking Foundation. However, this time the outcome could be different.”
The reason that OpenFlow might avoid this fate is that the ONF board of directors includes network customers such as the people who run the big data centers of Microsoft and Google, while the ATM Forum’s board was mostly equipment providers. As the Gartner report continues, the ONF board “possess significant in-house technical and financial resources and are aligned in their desire to lower their network equipment costs.” Whether OpenFlow can deliver on that promise remains to be seen, but [the ONF is] moving quickly.
CenturyLink’s Brouwer, for one, is wary. “The challenge is that every tech vendor says they will support a standard but they end up adding proprietary extensions to the standard,” he said. “Time will tell whether OpenFlow will pan out. Lots of vendors have expressed their support and promised future products using it. But you have to get it in the lab and see what the limitations will be,” he said.
SDN in the Wild
Whether you believe OpenFlow will succeed or not, there are numerous SDN vendors selling actual products today—traditional infrastructure vendors and newcomers alike.
CohesiveFT, for example, is using SDN in its VNS3 product to tackle a challenge that enterprises face when migrating to the cloud: managing secure connections and keeping control over the data.
“CohesiveFT gives us the control and security we need to comply with our customers’ rigorous privacy and industry concerns,” said Kevin Hurd, director at Assimil8, a business analytics and financial reporting company that uses VNS3 to manage and connect their SDNs to customers, partners and internal data centers. “The data-in-motion encryption ensures that we maintain highly segmented and secure overlay networks.”
For example, Hurd said Assimil8 can better manage their Internet Protocol Security tunnels and use VNS3’s REST APIs to create very flexible networks that combine firewalls, routers and switches using software. The idea is to handle not just the company-owned network infrastructure, but also the virtual networks that are created to connect to customers and partners outside the enterprise domain.
Another vendor with an early offering is Vyatta, which sells virtual firewalls that use the OpenFlow protocol. Several customers have used the Vyatta firewalls to connect on-premises Cisco-based firewalls with the Amazon cloud infrastructure, as reported by SearchCloudSecurity.com (see figure on page TK for more).
Then there’s SDN industry darling Nicira, whose Network Virtualization Platform was used by Calligo, a cloud provider located in the U.K. Channel Islands, to connect two distinct data centers and have them appear as one virtual entity. Clearly, having better ways to connect to the cloud is catching on almost as fast as cloud computing itself.
SDN Faces Obstacles Galore
But don’t get too excited about SDN just yet. It’s still far out on the horizon for most IT organizations.A recent InformationWeek survey of 250 IT professionals showed that about 70% of respondents won’t begin testing SDN for at least a year.
That is probably because first and foremost, this is a complex problem with no quick fixes. “Making network capacity available on demand in an application delivery environment is several magnitudes more complex than making compute or storage infrastructure available on demand,” wrote Gartner analysts Gregor Petri and Akshay Sharma in another January 2012 report.
Second, for the near-term, it will be simpler and probably cheaper to add network capacity than to reconfigure networks to handle SDN. “Just like with city planning of commuter traffic, adding overall capacity may in many cases be easier and more cost-effective than granularly allocating capacity to specific loads,” said Petri and Sharma. “But in some cases, cloud computing needs the equivalents of road pricing and carpool lanes to keep (enterprise) operations moving.”
Then there is the politics of it all. Cisco and Juniper could just drag their heels, or spin SDN as something they have always had in their product lines. “One reason that SDN isn’t being deployed widely is because it is a big threat to the established box/router vendors like Cisco and Juniper,” says Matt Wolpin, a marketing communications manager of Vyatta, “and it is such a fundamental change in networking design.”
Nicira is probably not a real threat to Cisco right now, given the latter’s size of their market share and the number of initiatives they have to support virtual networks, including integrating their Nexus switches with multiple hypervisors. And it could happen that OpenFlow would be subsumed into general network management software in a few years anyway.
Laying the Groundwork for an SDN Future
So given all the SDN hype, what should you actually do for your own situation? It really depends on where you are now with virtualization and cloud deployments, and where you will be going.
You should first look at your VM portfolio and how it will expand over the next two to three years. If you don’t have anything in hybrid clouds or intend to connect to any of your customer or partner networks, then you are probably safe with the status quo.
But if you do have servers in somebody’s cloud, you should start looking at what the traditional networking vendors can offer you in the way of connecting on-premise and cloud data centers, and whether their promised upgrades can handle the kinds of networks that you will need to service these configurations.
Second, you should look at your own VLAN strategy and see how much more room you will have to scale it up. “Most enterprises have traffic steering and optimization to shift network priority from overnight backup and replication before load kicks up again in the morning,” said 451 Group’s Hanselman. But you could be running out of gas with that plan as the amount of data that traverses your infrastructure puts a strain on managing your VLANs.
And finally, start thinking out of the box, advised William Koss, vice president at Plexxi, an enterprise networking startup. SDN isn’t only about separating data from control functions. It also means designing entirely new network infrastructures from the ground up.
That means starting with some big questions. “What is possible if I designed the network differently? What is possible if I threw out two decades of design assumptions and principles? What is possible if I started with the premise that the network can do only one of two functions: connect and disconnect?” Koss wrote in his blog. SDN “is an opportunity to ask if I threw all the crap in my network in the trash and started over, what would we build, how would we architect the network and how would it work?”
Clearly, some kind of SDN is here to stay and will only increase in popularity over time. And it may get you thinking about better ways to build your future network infrastructure, too.