You've heard it before, but it bears repeating: Networks are bottlenecks in the private cloud. Server and storage technologies have evolved into pooled resources that cloud administrators can spin up on the fly, but networks remain manual. To be more agile, private cloud networks must be virtualized, and software defined networking offers a cost-effective method for getting there.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"wEnterprises need to be like service providers and react as quickly as they can for internal customers. They need to enable self-service IT. The biggest roadblock to that is networking," said Ben Cherian, chief strategy officer with Midokura, a Japanese startup that is developing SDN-based network virtualization technology. "Armies of CCIEs are running around making little changes to switches and routers that have requisition times of weeks," he said. Meanwhile, in many cases cloud providers can click a button to make changes.
Essentially, SDN technology decouples and centralizes the control plane from the data-forwarding plane of individual network devices. By centralizing that control plane (usually on a server-based SDN controller), the network becomes more programmable. That leads to a more dynamic and reliable private cloud network.
"The majority of outages that we have are from someone going in and messing with configurations," said Brent Salisbury, a network architect with the University of Kentucky who has been experimenting with SDN and private cloud technology in his test and development environment. "If I can get that down to where [network changes] are programmatic and reproducible every time, that's a big value. You're taking human error out of it."
The OpenFlow protocol is the best-known means of decoupling and centralizing a network control plane, but mainstream, commercial availability of OpenFlow-friendly switches is limited. Cisco, the most widely installed switching vendor in the world, doesn't yet support the technology on most of its data center products. So, SDN vendors have taken different routes to bringing the technology to market. NEC Corporation of America, for example, makes its own switches for its OpenFlow controller. In another approach, Big Switch Networks Inc. and Nicira Networks (recently acquired by Vmware Inc.) create SDN overlays by centralizing the control planes of hypervisor-based virtual switches, then tunnelling through the physical network with protocols like VXLAN (Virtual Extensible Virtual LAN) and NVGRE (Network Virtualization using Generic Routing Encapsulation).
One company's SDN-based private cloud network
Schuberg Philis Group B.V., a Dutch IT management and consulting firm, once faced the epitome of the private cloud networking problem: The company built internal clouds with flexible pools of compute resources, but it had manually configured networks.
Hugo Prippaersengineer, Schuberg Philis Group B.V.
"We were building private clouds for a long time with virtual hosts that had a lot of flexibility, but every time we started to use the flexibility, we found that we had to call the network engineer and say, 'Hey, before we use this [cloud service], we need another [virtual local area network] or another port configured in another VLAN," said Hugo Prippaers, a mission-critical engineer at Schuberg Philis.
Now the firm is building its internal cloud based on SDN technology. The new cloud infrastructure consists of a high-speed, Layer 2 network built with Arista Networks switches and the Network Virtualization Platform (NVP) from Nicira. The company has started small, with two racks of servers topped with dual 10 Gigabit Ethernet Arista switches, which all uplink into a pair of end-of-row Arista switches.
"The only thing you need on a physical network using a Nicira solution is fast switching. Arista was the fastest switching we could find. It's a completely flat Layer 2 network with just a few VLANs in there to connect to the public Internet," Prippaers said.
The Nicira NVP technology forms an SDN overlay between the virtual switches on the hypervisor hosts in the server racks and the physical Layer 2 network. The network overlay treats the Layer 2 network as an IP backbone, tunnelling Layer 3 traffic and other network services across it. As a result, Schuberg Philis administrators can make single-click changes to the SDN overlay as they spin up cloud services without having to make any changes to the underlying physical network, Prippaers said.
"With the Nicira solution, the network guys can build an entire network infrastructure the way we want it, when we want it, without having to go to the physical devices again and again to reconfigure them. It frees up a lot of time," Prippaers said. "Our network engineers are now able to focus on the core stuff of the network, making sure interconnects are completed to perfection and that the Layer 2 switching is as fast as possible. They just worry about really important stuff rather than changing port configurations."
SDN cloud networking: Northbound APIs needed for orchestration
While SDN technology can virtualize networks and simplify network administration in a private cloud, network operations can still remain siloed from the rest of the cloud infrastructure team. To streamline operations, SDN must be integrated into cloud orchestration frameworks, experts say.
There must be more management sophistication in SDN, said Eric Hanselman, research director for networks at The 451 Group LLC. "OpenFlow is okay at a low level, but for Big Switch, NEC and Nicira, the real value is that upper-level control capability. Nobody wants to be out there firing up tons of Python [scripts] to do network control. You want it to be part of your top-level control environment ... that integration at a higher level is the real value."
The Open Networking Foundation, which governs the development of OpenFlow, recently acknowledged the need for this integration by announcing an expansion of its SDN standardization scope to focus on northbound APIs. OpenFlow is considered a southbound protocol that allows an SDN controller to communicate with and manipulate the switching infrastructure below. But northbound APIs connect the controller to applications and orchestration frameworks that sit above. For instance, a northbound API can allow a cloud orchestration system to manipulate a network through an OpenFlow controller.
"The promise of OpenFlow down the road is that the application infrastructure itself, whether the actual applications or the management environment that's launching the apps, [should] be able to dynamically control what the network looks like, how it's connected, and what capabilities and capacities are assigned to it," Hanselman said.
The ability to "decompose network resources into something that is consumable, along with compute and storage, must be done programmatically and [be] agnostic to the hardware," the University of Kentucky's Salisbury said. "We're not going to start programming static flows [in SDN]. They're worse than static routes, only a million times more granular. I think the northbound application is the only way to start integrating [SDN] into cloud orchestration."
Nicira plus OpenStack for multi-tenant private cloud networks
To solve the problem of northbound APIs in its private cloud, Schuberg Philis has integrated Nicira's technology with CloudStack, the open source cloud orchestration framework created by Citrix Systems Inc. The integration allows the company to create and manage a multi-tenant network in its private cloud. "With a cloud management system, we can create multiple tenants and every tenant has the ability to create several networks," the company's Prippaers said. "We've integrated the Nicira solution so at the moment CloudStack provides you with a network, and it [uses] an API [application programming interface] of Nicira to create a logical switch. Then, every virtual machine that gets booted into the network will be assigned a logical port and connected to the virtual switch."
Programmability with proprietary SDKs helps, but SDN is better
Network vendors have tried to offer some level of programmability for years, often through software development kits (SDKs) built on top of their operating systems. Cisco's SDN strategy, for example, includes One Platform Kit (onePK), an SDK planned for all its networking gear that will allow for programmability. Salisbury, however, doesn't want a programmable cloud network based on "proprietary APIs on proprietary software running on proprietary hardware."
"With OpenFlow, you now start to have better definition and more controllability over the forwarding plane," Salisbury said. He wants vendors like Cisco and Juniper Networks Inc. to open up their boxes completely to OpenFlow and give customers the freedom to build the networks they want. He notes that Google didn't wait around for this and built its own OpenFlow gear, including switches and controllers.
Some doubt SDN centralization concept
The industry has also been conservative with OpenFlow support because of lingering questions about the centralization of the control plane in SDN. Some vendors and network engineers question how scalable and how secure centralized control can be.
"Some vendors say we have to stay distributed because centralization will never work," Salisbury said. But a centralized, controller-based network seems to work just fine in the wireless LAN market, he noted. To Salisbury, today's network architectures are too complex to serve the needs of a private cloud environment.
"We've taken the architecture of the Internet and stuffed it into enterprise networks," Salisbury said. "We've taken this huge stack of protocols, and this huge distributed computing model, and said, 'OK, this works for hundreds of thousands of autonomous administrative domains. Let's put the same thing inside one administrative domain.' It makes it so complicated. I think [SDN is] inevitable. We're 10 years behind, and we've got the roadmap. The only question is, can we do it faster than the x86 market did?"
Five challenges in the private cloud network
Networker's guide to private cloud orchestration
Software defined networking could make Network-as-a-Service a reality
Private cloud computing over the WAN
OpenStack networking: Why should we care?