For those who visit here often know I'm a bit of an SDN purist , maybe even a Revolutionary. But this article, it stemmed from several recent conversations on how the network will EVOLVE over time. This pertains to data center only, so it's more relevant to the topic of *Empowering* the Software Defined Data Center (SDDC). It was also meant to be a high level quick start guide regarding these trends. For more details, I've written other posts and there are definitely a lot of others out there too.
Here it goes.
Network Virtualization & Software Defined Networks
As an infrastructure and IT professional, you are probably overwhelmed with the amount of information and hype right now regarding topics such as OpenFlow and Software Defined Networking (SDN). Rest assured you are not alone. My goal is to simplify this messaging, review what can be done in the world of software and virtual networking today to meet the demands of Cloud, but will also lay the foundation for the next generation network.
Here it goes.
Network Virtualization & Software Defined Networks
As an infrastructure and IT professional, you are probably overwhelmed with the amount of information and hype right now regarding topics such as OpenFlow and Software Defined Networking (SDN). Rest assured you are not alone. My goal is to simplify this messaging, review what can be done in the world of software and virtual networking today to meet the demands of Cloud, but will also lay the foundation for the next generation network.
OpenFlow & SDN Primer
While OpenFlow has been around since 2007, it is just recently within the past 24 months that there has been a lot of buzz about it in the market due to industry events such as Interop and Cisco LIVE as well as acquisitions such as the one of VMware acquiring Nicira. And of course, this blog.
The definition of Software Defined Networking (SDN) is ever evolving. However, in the most traditional sense, it is the de-coupling of the control plane from the data plane on network devices such as physical and virtual switches. Rather than running the control plane that consists of protocols such as Spanning Tree, OSPF, and BGP on each individual network device as we’ve always done, these types of services and functions would be extracted from each device and centralized on a server. This server is what is called a SDN controller. OpenFlow is one protocol that can be used by the SDN controller to manipulate the forwarding plane of the network device.
While OpenFlow has been around since 2007, it is just recently within the past 24 months that there has been a lot of buzz about it in the market due to industry events such as Interop and Cisco LIVE as well as acquisitions such as the one of VMware acquiring Nicira. And of course, this blog.
The definition of Software Defined Networking (SDN) is ever evolving. However, in the most traditional sense, it is the de-coupling of the control plane from the data plane on network devices such as physical and virtual switches. Rather than running the control plane that consists of protocols such as Spanning Tree, OSPF, and BGP on each individual network device as we’ve always done, these types of services and functions would be extracted from each device and centralized on a server. This server is what is called a SDN controller. OpenFlow is one protocol that can be used by the SDN controller to manipulate the forwarding plane of the network device.
Why SDN?
With an understanding of SDN as the separation of the control and data planes from a technical perspective, why would you ever want to deploy this type of technology? This is the harder question to answer, so we really need to look at a few problems that are trying to be solved by SDN.
Operational Simplicity – Many network operators are still using CLI to manages 10s, 100s, and even thousands of network devices. By centralizing the control plane, there will be the possibility to use the SDN controller as the focal point of network administration and centralized brain of the network.
Ephemeral State – This is something that isn’t thought too much about today or we just deal with the complexity of managing configurations for temporary requirements. By being able to integrate a SDN with 3rd party applications and tools, ephemeral state can be achieved by reacting as needed to the application requirements at that specific point in time.
Software Innovation – Today, hardware and software are tightly coupled together. This delays new features to be deployed across product platforms. While some functions may always perform better in hardware, the majority can be deployed as needed in software without the need for specialized hardware given a SDN system further increasing the innovation and the pace at which features can be deployed.
Network Flexibility/Programmability – SDN architectures allow for a network abstraction layer to be created across the physical network. This allows virtual, but yet flexible networks to be created on demand and as needed throughout data center environments. We can enable flow based forwarding. Being able to insert on demand advanced networking services (L4-7) becomes possible – the network becomes agile.
Since we briefly described Software Defined Networking, we’ll now look at one of the industry’s mega trends, Cloud, and see how both Cloud and SDN are related to one another from a networking perspective.
Virtual & Cloud Workloads
It is understood that server and storage virtualization have become the norm. We know that virtualization significantly increases system utilization, reduces time for deployment, provides fault tolerance to systems, and has empowered server administrators to manage many more servers than they have in the past by offering a management model that is operationally simple and effective. There has also been direct impact on business continuity planning through the use of virtualization technologies by offering techniques to perform workload mobility.
With an understanding of SDN as the separation of the control and data planes from a technical perspective, why would you ever want to deploy this type of technology? This is the harder question to answer, so we really need to look at a few problems that are trying to be solved by SDN.
Operational Simplicity – Many network operators are still using CLI to manages 10s, 100s, and even thousands of network devices. By centralizing the control plane, there will be the possibility to use the SDN controller as the focal point of network administration and centralized brain of the network.
Ephemeral State – This is something that isn’t thought too much about today or we just deal with the complexity of managing configurations for temporary requirements. By being able to integrate a SDN with 3rd party applications and tools, ephemeral state can be achieved by reacting as needed to the application requirements at that specific point in time.
Software Innovation – Today, hardware and software are tightly coupled together. This delays new features to be deployed across product platforms. While some functions may always perform better in hardware, the majority can be deployed as needed in software without the need for specialized hardware given a SDN system further increasing the innovation and the pace at which features can be deployed.
Network Flexibility/Programmability – SDN architectures allow for a network abstraction layer to be created across the physical network. This allows virtual, but yet flexible networks to be created on demand and as needed throughout data center environments. We can enable flow based forwarding. Being able to insert on demand advanced networking services (L4-7) becomes possible – the network becomes agile.
Since we briefly described Software Defined Networking, we’ll now look at one of the industry’s mega trends, Cloud, and see how both Cloud and SDN are related to one another from a networking perspective.
Virtual & Cloud Workloads
It is understood that server and storage virtualization have become the norm. We know that virtualization significantly increases system utilization, reduces time for deployment, provides fault tolerance to systems, and has empowered server administrators to manage many more servers than they have in the past by offering a management model that is operationally simple and effective. There has also been direct impact on business continuity planning through the use of virtualization technologies by offering techniques to perform workload mobility.
But, what about the network?
Because of the demands of server virtualization, the network is becoming more inflexible and is unable to meet the demands of cloud workloads. Let’s examine why in a bit more detail.
Workload Mobility – server admins have demanded Layer 2 connectivity everywhere, within a data center and between data centers, to allow for workload mobility. This simply does not scale.
Operationally Complex – the network is still largely configured using the CLI and each network service commonly has its own management platform. We see 100s to 1000s of VMs managed smoothly with no strain, but have not similar trends on the network side.
Network Flexibility – how do you build secure, isolated L2/L3 networks and be able to insert L4-L7 services anywhere in the cloud when you need them?
In addition, traffic patterns in the data center are changing significantly. We are now seeing reduced north/south or client to server traffic and increased workloads that remain in the data center, i.e. east/west or server to server traffic.
It is because of these limitations and change in traffic patterns, the network cannot be an afterthought to a Cloud Architecture. The network needs to be architected in conjunction with the Cloud. We need Cloud Ready Networks to meet the demands of the workloads being placed in the cloud.
Cloud Ready Networks
Cloud Ready Networks should meet the current requirements of the Cloud today, but also serve as a platform to enable to new network services simply and easily in the future based on the principles of Software Defined Networking (SDN). Cloud Ready Networks should also be integrated, if possible, to the tools being used to orchestrate the compute and storage layers of the cloud.
How do you build a Cloud Ready Network?
Before attempting to build and deploy a Cloud Ready Network, many questions need to be asked that are often overlooked with the network being an afterthought. This will require interaction between the network and systems teams.
A sample of these questions are:
1. What hypervisor technology is being deployed?
2. What management and orchestration tools are being deployed to manage the virtual systems environment?
3. How many physical and virtual servers will there be?
4. Will there be physical servers (bare metal) system requirements?
5. Will the Cloud be deployed as a private cloud or private cloud with cloud bursting?
6. Will it be a mult-tenant cloud?
7. Will any systems be located at a cloud service provider (CSP) such as AWS, Rackspace, Terremark?
a. If so, what network services are provided by the CSP? Get details.
8. Is inter-cloud connectivity required between sites, e.g. Private to Private or public to private?
9. Are active/active data centers a requirement? Dig into applications in more detail.
10. What type of network segmentation and security will be required in the cloud?
11. How many total network segments will be required?
12. What types of users will be accessing data in the Cloud and from where?
13. What network services should be offered in the Cloud, i.e. routing, firewall, VPN, IPS, load balancing, etc.?
14. What are the traffic patterns of the current systems today? If you don’t know, get them.
15. Does the network need to be fully hypervisor-agnostic including L2-L7 services?
After examining the questions and answers to the questions above, you’ll need to take a deeper dive into the design and architecture of the Cloud Ready Network because the network for the cloud and inter-cloud connectivity will likely be different than what you’re experienced with.
This strategy is based around analyzing the impact of software enabling the network in data center, virtual, and cloud environments. Software enabling the network means that rather than deploy large boxes or choke points, with firewall as an example, policy is distributed in software and enforced at the edge whenever possible. When the majority of traffic in the data center was coming from end user clients, it was easy to insert a FW at the edge, but when you have an increasing number of systems within the data center communicating at extremely high transmission rates that also need to be secured, the strategy needs to be re-examined and architected for the future.
By software enabling the network, you will see real benefits in the overall network – The Cloud Ready Network. These include:
1. Inherently take advantage of software
a. Lifecycle management of hardware is removed
b. Costs related to space, power, and cooling are reduced
c. Snapshots, rollback, etc. are now possible
2. Enhanced Network Provisioning
a. Reduce number of network administration points
b. Leverage existing in house system provisioning tools
c. Leverage platform APIs for system deployment and management
3. Increased Workload mobility
a. Distributed virtual networks
b. Network overlays
i. Can also yield simpler physical network fabrics
c. Expand boundary for workloads
4. Increased Flexibility
a. Enforce policies nearest the edge
b. Insertion of L1-L7 services where needed
c. Enable efficient and optimal traffic patterns
d. Offer inter-cloud and cloud to branch connectivity
Deploying software based network services is doing much more than placing a network function on a VM as you can begin to see. There begins to be overlap with SDN and how we build software enabled Cloud Ready Networks that can be deployed today. This is critical to understand because the focus should not simply be about deploying SDN for the sake of SDN, but rather be about removing the current limitations of the network, and then making the network much more flexible to meet the future demands of the applications. This can only happen via software and virtual networking. If this is done properly, you may realize that at the end, a software defined network has been deployed.
Note: Physical networks are still needed. Cables and swiches and maybe even some other specailzed hardware do not go away.
Jason Edelman
Twitter: @jedelman8
Post Updated: 11/27/12
RSS Feed
