We have discussed the emergence of the (new) software-defined data center architecture over a series of seven posts (http://www.vamsitalkstech.com/?p=1833&) over the last year. We only briefly touched on the complex topic of Software Defined Networking (SDN) – a catalyst enabling this transformation to software-defined infrastructure. The goal of this post is to define SDN while discussing pitfalls and lessons learned from working with Fortune 5000 customers.
(Image Credit – Pixabay)
The Challenge
Prior to the advent of SDN, the network architecture was inflexible and static from both a device and traffic standpoint. The control plane of each networking device (switch/router/multiplexer) was programmed into the device thus leading to a lack of a centralized control plane.
Also lacking is programmability – the control plane directed data packets using the data plane or the forwarding functionality in the device. The forwarding logic depended on various rules, tables, and policies programmed by the vendor into the said device. Other key requirements missing from the older model are visibility into the topology and the real-time performance of the network/devices themselves. In short, the network of old was a black box – too siloed to program, provision and monitor using a single programmatic interface.
Digital applications demand a high level of dynamicity and automation across the three core components – compute, network and storage. More importantly, this dynamicity needs to be programmable via APIs.
The goal of SDN is to enable network engineers and cloud architects to respond quickly and effectively to business requirements.
SDN is based on three principles, which are further explored in the SDN Architecture document[1].
- Decoupling of traffic forwarding and processing from control
- Logically centralized control
- Programmability of network services
The Architecture of SDN…
The above illustration shows that the SDN architecture is divided into the following major building blocks -the Application Layer, SDN Controller, and the Infrastructure Layer.
The SDN Controller is the main orchestrator in this architecture. It enables applications to control the infrastructure, gain visibility of the current network state, inventory and enables the creation of policies to drive network devices (e.g. switches and routers) based on application requirements. It uses standard protocols such as OpenFlow to interact with the device layer using a Southbound API. The Northbound API enables Applications to orchestrate the network via the Controller. The Controller translates application requirements into a format the Infrastructure layer can work with. The Controller architecture depicted above is a logical one – which means that not only do Controller capabilities vary based on the vendor, cost, capability etc but multiple controllers can be set up within a data center. This is typically done to achieve a high degree of fault tolerance, performance and scalability at the Control Plane level.
The Infrastructure layer or the Data plane consists of vendor supplied or whitebox devices that can be endowed with a persona (e.g a Router or a Switch or a Firewall etc) by the SDN Controller. The capabilities of this layer may vary based on vendor supplied infrastructure. The infrastructure layer enables three modes of forwarding traffic – Reactive (policy pushed into it by the Controller), Proactive (based on preset rules i.e forwarding tables published by the Controller) and Hybrid (based on a combination of the above modes).
The Application Layer is not the traditional application tier which consists of web applications, three-tier architectures or microservices etc. We will discuss these in a moment but think of them as network-aware applications that can perform a great deal of functionality in terms of packet filtering, forwarding etc. These communicate with the controller using a driver.
What advantages does SDN confer to the average Digital or Cloud Native Application?
The important thing to note is that with SDN your average application developer doesn’t need to care about the underlying network or services such as Firewalls or DNS etc any more than she did before. However, with SDN, the network is now programmable for the purposes of the IaaS/PaaS components that need to leverage it to create dynamic services. This enables the rapid rollout of new applications without long static provisioning cycles.
Let me explain with an example of OpenStack, the leading private cloud platform.
While there is some value in being able to provision VMs into an OpenStack cloud but that capability has been present for almost a decade with a hypervisor such as VMWare ESXi or KVM or Xen. Where Heat provides operators a distinct advantage is in being able to provision entire application stacks.
What Advantages Can SDN Provide…
A Datacenter network architecture based on SDN confers the following benefits –
- Configurable and programmable networks – The brains of the network (policies and flow control) are separated from the forwarding function & device interfacing. This enables the orchestration of key network functions from platforms such as OpenStack, or, Ansible or Puppet etc
- Open ecosystem based on standard APIs at both the Northbound and Southbound directions
- Centralized Operations and Administration
- Reduced Costs – a) CapEx Reduction by enabling the adoption of an open source SDN as well as enabling network services to be offered over software as opposed to expensive appliances. b) OpEx reduction by automating a range of manual tasks associated with provisioning and operating networks
- Support for a range of new age networking use cases – these include a) configuring the network dynamically to handle massive traffic from consumers e.g.mobile clients, b) support for Big Data movement across the network c) quickly provisioning network services to developers on a utility compute model etc
Drawbacks of the SDN Model…
With great power comes concomitant complexity – while the notion of programmable networks sounds like a great idea, it does deliver its own set of drawbacks.
- High need for upfront due diligence in terms of business requirements & specific needs for network agility
- For general purpose utility clouds, vendors can provide products that are overly complex leading high Capital expenditure
- Complex integration requirements with the other tiers – compute, storage and management
- More moving parts mean a higher degree of complexity in troubleshooting
- Need for SDN skillsets in the Network and SRE (Site Reliability Engineering) teams
The next post will expand on SDN with a look at the OpenFlow protocol.
References
[1] SDN Architecture Document 1.4 – Open Networking Foundation – https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR-521_SDN_Architecture_issue_1.1.pdf
1 comment
new post subscription