It has become evident that traditional network architecture. Storage-Defined Networking

Transcription

1 S T O R A G E Storae-Defined Networkin A detailed look at SDN and its best practices. It has become evident that traditional network architecture desins are poorly suited to meet the needs of today s dynamic enterprises, advanced applications and mobile workforces. It is a realization that has forced operators of enterprise networks, both lare and small, to seek out alternative methodoloies to desin, build and deploy their network infrastructure.

2 With that in mind, Software Defined Networkin (SDN) has become the heir apparent for networkin architectures by incorporatin the ideoloies of aility, adaptability, as well as scalability into the networkin platform. What s more, SDNs achieve those lofty ideals by separatin the control and data planes into a centrally manaed virtual entity. While benefits abound, there is still much confusion around what SDN is and isn t, especially with networkin vendors addin to the confusion by creatin their own definitions of what an SDN actually consists of. From an industry perspective, an SDN is defined as a platform that provides network infrastructure / connectivity that has the control and data planes decoupled, while network intellience and network state are loically centralized, and the underlyin network infrastructure is abstracted from the applications. That abstraction, when combined with the tenets of virtualization, aility and manaement can create an environment where enterprises ain unprecedented prorammability, automation, and network control, enablin them to build hihly scalable, flexible networks that readily adapt to chanin business needs. In essence, an SDN should provide: Centralized manaement and control of networkin devices from multiple vendors Improved automation and manaement usin common APIs that abstract the underlyin networkin details from the composition and provisionin of systems and applications Increased and rapid innovation, delivered by the ability to add new network capabilities and services without needin to confiure individual devices or wait for vendor uprades The ability to proram SDNs usin a common prorammin environment that can be leveraed by operators, enterprises, independent software vendors, and users, which ives all parties new opportunities to drive revenue and differentiation Increased network reliability and security as a result of centralized and auto- STORAGE 2

3 mated manaement of network devices, uniform policy enforcement and fewer confiuration errors More ranular network control with the ability to apply comprehensive and wide-ranin policies at the session, user, device, and application levels An improved end-user experience, created by an application s ability to exploit centralized network state information to instantly adapt network behavior to user needs. Simply put, an SDN should become the basis for a dynamic and flexible network architecture that protects existin investments while future-proofin the network. Thanks to SDNs, the static networks of today can evolve into an extensible service delivery platform capable of respondin rapidly to chanin business, end-user, and market needs. The Ideoloies of Software Defined Networks: The basic ideoloy behind an SDN amounts to deliverin network infrastructure in an aile fashion that leveraes existin hardware, while reducin the need to rip and replace networkin components to achieve flexibility and scale. However, reachin networkin nirvana requires more than understandin the basic ideoloies of SDNs. Those lookin to leverae SDNs will also have to embrace the technoloy by understandin what it can and cannot do, while also raspin how SDN technoloy will transform their existin environments a process that usually starts with understandin the differences between traditional technoloies and SDN. An In-depth Explanation of SDN: An SDN consists of several interrelated elements, all of which are driven by policy, prorammin and a standardized framework to deliver networkin resources in an adaptable, scalable fashion. SDNs incorporate planes of operation, where specific functions are abstracted from network operations. For example, the manaement plane contains system administration, code manaement, user interfaces (SSH, HTTP, API), as well as los and other manaement centric elements. STORAGE 3

4 The control plane administers virtual device operations, providin the instructions used by virtualized hardware to direct packets, perform switchin and routin operations, and also report operational data back to the manaement plane. The data plane functions as the enine of the virtualized device, movin packets throuh the device usin instructions provided by the control plane to determine the appropriate output ports. In the past, traditional networkin infrastructure devices tied all three planes directly to the physical device hardware, forcin the devices to interact usin the control planes to share information usin protocols such as OSPF or Spannin Tree a situation that created inherent limitations based upon both implemented hardware and software. The major difference between SDN and traditional networkin amounts to how controller-based networkin is executed. With an SDN, a centralized controller (often combined with the manaement plane) has a complete end-to-end view of the entire network, meanin that all the knowlede of network paths and device capabilities resides in a sinle application. As a result, the SDN s control plane can calculate paths based on both source and destination addresses, readily usin different network paths for different traffic types and react quickly to chanin networkin conditions. In addition to deliverin these features, the SDN s controller serves as a sinle point of confiuration, allowin full prorammability of the entire network from a sinle location. That results in the ability to automate network operations, which then becomes one of the most valuable aspects of an SDN. Of course, there is much more to SDN than the separation of planes of operation. SDN also incorporates hypervisor connectivity, where a hypervisor hosts several VMs (virtual machines) and those VMs are able to communicate throuh the network usin SDN defined virtual switches, eschewin the limitations of physical networkin hardware. What s more, new tunnelin protocols allow for the creation of overlay networks, where the networkin is abstracted from the physical network and confiured in the virtual switch. Those new protocols, such as VXLAN and NVGRE are able to encapsulate the data inside an IP packet, so that information can traverse the physical network, yet still allow VMs on different subnets to STORAGE 4

5 communicate as if they were on the same physical network. In short, that allows connections between hypervisors to be established without any dependency on the physical network. With an SDN, virtual switches (vswitches) create tunnels that institute a mesh of connectivity to other virtual switches in the network, transitionin the physical network in to what could be thouht of as a tunnel fabric. Althouh the process of virtualization and encapsulation may be processor intensive, modern x86 servers have been shown to handle tunnel encapsulation at more than 10Gbps, with CPU consumption of only 20% on a sinle core. Another advantae offered by a vswitch comes in the form of multitenancy, a concept where multiple tenets can be hosted within the same SDN, yet have their own virtual infrastructure to keep all traffic isolated from other tenants. In the past, keepin traffic isolated from one business entity (tenant) to another required the physical separation of networkin hardware, as well as extensive manual confiuration. vswitchin technoloy uses security policies to control the VM, tunnel and other elements to enforce isolation, and reduce the possibility of confiuration errors, all thanks to the SDN concept of overlay networks. The Evolution of SDN: The concept of Software-Defined Networkin is not new, SDN arose in phases as new ideoloies were applied to the problems associated with physical networkin. SDN aruably has its roots in the turn of the century, where research was conducted into the idea of separatin the data and control planes of networkin devices. The SDN ideoloy was further advanced by the OpenFlow API and the evolution of the Network Operatin System (NOS). However, SDN has rown to be much more than the concepts set forth by Openflow API, which from a protocol standpoint defined the messain between the switch and the controller, controller to switch, as well as symmetric and asynchronous communications. OpenFlow s controller to switch messain manae the state of the switch, while symmetric messaes are sent by the controller or switch to initiate the connection or interchane of messaes, while asynchronous messaes update the control of the network events and the chanes of state switch. Furthermore, OpenFlow establishes STORAGE 5

6 two types of switches: OpenFlow-only and OpenFlow-enabled. OpenFlow-only switches use only OpenFlow protocol to process packets. However, OpenFlow-enabled switches can additionally process the packet usin traditional alorithms of switchin or routin. Recent advancements have pushed SDN beyond the basics of the OpenFlow API. For example, newer controller technoloy, such as tenant overlay capabilities, have shifted isolation from limited VLAN concepts into a more addressable, virtualized data plan that allows for confiuration on the fly, while also better enforcin security and controllin isolation. While it is debatable as to what the future holds for SDN, there are additional advancements on the horizon many driven by the forthcomin rowth of IoT (Internet of Thins) technoloies. For some, that may mean further sereation of planes from the OpenFlow ideoloy of two (control and data) to four, such as packet forwardin, flow control, network services and systems manaement. Other innovations down the road may include more robust APIs, client side applications, interated machine learnin and increased resiliency. Reardless of what the future holds, those adoptin SDN today will want to adhere to industry best practices to solve the problems of today, while future-proofin network architectures and layin the foundation for the innovations of tomorrow. SDN Best Practices: A successful implementation of SDN starts with understandin the current and future needs of the network and then plannin to address those needs. However, success pivots on another factor, the adoption of best practices. Luckily, enterprises of all shapes and sizes have worked with SDN vendors to chart what works and what does not. That has led to readily available best practices, which can be leveraed to avoid the mistakes and failures of early adopters. Althouh the intricacies of best practices may deviate from one vendor s ideoloy to another, the foundation of those best practices still provides valuable uidance for those lookin to save time, money and maximize the value offered by SDN, while also helpin to determine what products to select to ease the transition to an SDN. STORAGE 6

7 Plan for Leacy Interation Many early adopters failed to take into consideration the questions of interoperability. For example, some chose to move into the realm of SDN without verifyin how applications would be mirated and the impact an SDN would have on existin hardware, leacy hardware, as well as leacy applications. Luckily, SDN lends itself well to radual deployments, where adopters can test proof of concept as elements are transitioned over to an SDN. The ideoloy of a radual deployment proves to be a sensible approach that can smooth over many interation worries. However, adopters must also observe due dilience and inventory all existin systems, hardware and applications to create a matrix of compatibility. Think of the SDN Ecosystem The SDN controller is only a sinle piece of the SDN puzzle, yet many adopters focus all of their enery on deployin, confiurin and manain the controller, without considerin the complete network ecosystem. Here, adopters need to think in terms of the complete picture, and look to build a complete SDN solution, that brins near term benefits, as well as supportin onoin operations and future needs. Simply put, the ecosystem consists of all of the SDN planes, as well as the virtualized (abstracted) hardware and the applications that will move across the network. Remember Device Interoperability Althouh the concepts behind SDN are centered on an open architecture that supports multi-vendor environments, it proves critical to make sure that those vendors products do indeed fully support the SDN controller that has been selected. In some cases, vendors may claim interoperability with a iven platform, but have not yet certified or tested their products with that platform. A simple rule of thumb is to validate compatibility before movin into an SDN deployment. Pursue Hardware Optimization No one wants to deploy an SDN and then experience reduced performance or encounter connectivity issues. In other words, when selectin the hardware to function as the SDN controller (and associated elements), choose proven hardware that can handle demand. That may mean addin more memory to a iven server, or selectin a different server with a hiher performance CPU or even shiftin other demands placed on the server over to separate systems. The idea here is to eliminate any potential bottlenecks before deployment and to also monitor the STORAGE 7

8 demands placed on components to make sure they are optimized for service and are not approachin over-utilization. Don t Foret Capacity Plannin The SDN controller functions as the central processin point of SDN operations. Understandin and measurin the loads placed on a controller allows adopters to aue loads and how those loads can differ based upon demands. Those differin loads, created by traffic volume, active rules, directed devices, controlled flows, and other functions will become a critical metric for evaluatin SDN solutions, and ultimately help adopters to deploy the riht-sized solutions for their environments. Plan for Failure In its most basic form, an SDN controller can be housed on a sinle physical device, in a sinle location. However, critical network operations demand a failsafe environment. So in essence, it is critical for adopters to think about deployin multiple controllers and what the requirements of failover are. Administrators should think about the implications of hot service activations and updates, pre-activation confirmations and confiuration rollbacks, as well as redundancy, failover, hot swaps, disaster recovery and any other element that impacts business continuity. Address Usability and Manaeability The Best SDN controller in the world may prove useless if it is difficult, use and manae. Naturally, adoptin an SDN results in a symbiotic relationship with network manaement. Adopters should look at SDN controllers from a network administrator s point of view, where ease of use, reliability, manaement tools, reportin and data collection often outweihs raw performance. What s more, once deployed, the SDN platform should also prove to be easy to operate, maintain, scale, uprade and dianose. Otherwise, failure can creep into the SDN, and prove to be difficult to remediate. Look for Proactive Support Althouh those adoptin SDN would love to think of SDN as a set and foret concept, nothin could be further from the truth. Networks are no loner static entities than can be defined once and then forotten about. Chanes in scale, applications, operations and many other elements have caused networks to become very fluid in operation a situation that actually was the catalyst for the creation of SDN tech- STORAGE 8

9 noloy. That said, support may very well be the key to success. In other words, when workin with SDN technoloy, make sure support resources are readily available to desin, manae, and most importantly, troubleshoot the SDN. The Value of SDN: Value can be a nebulous concept, especially with SDNs. Value is often determined on the concept of ROI (Return on Investment), yet in the world of SDN, return can be a difficult thin to pin down. Achievin a financial arument that promotes SDN adoption may not be as difficult as it sounds, thanks to the benefits derived from adoptin an SDN. Measurin those benefits can provide the fodder to arner budet approvals and the resources to move ahead. Core benefits offered include: Service provisionin speed and aility: SDN network provisionin proves to be fast and easy, and often requires little work, thanks to the ability to just create VM instances to create a new network resource. Network flexibility and holistic manaement: SDNs create an environment where network experimentation without impact can be accomplished. That means desiners can leap over the limits imposed by SNMP and experiment freely with new network confiurations without bein hamstrun by their consequences. Improved ranular security: SDNs offer fine-rained security for apps, endpoints and BYOD devices, which cannot be accomplished on a physical, traditional network. What s more, that security can be driven by centralized policies that enforce controls and offer insiht into operations. Reduced OPEX and Increased Efficiency: It is difficult to calculate the exact cost savins of SDNs, since adoption may simply shift OPEX costs over to controllers and software. However, many adopters have claimed lower hardware costs as a bi advantae, and many also have experienced reduced OPEX costs, thanks to improved network manaement efficiency. Introduction of virtual network services and lowered CAPEX: While lare data centers seem to reap the biest benefits from SDNs, there are still STORAGE 9

10 plenty of savins to be found even in the smallest of networks, which can realize sinificant savins from makin better use of existin hardware and by lessenin dependencies on proprietary hardware and dedicated appliances. Conclusions: SDN has become a compellin solution for businesses of any size and offers sinificant benefits that can be realized from the outset. Adopters are findin that SDNs help to simplify operations by automatin and centralizin network manaement tasks. Also, SDNs make the networks more responsive to dynamic business and institutional needs by couplin applications with network control. What s more, SDN provides aility, simply because adopters can quickly customize network behavior for emerent business needs. A capability that proves very important for businesses experiencin the increasin velocity of application development, driven by business needs that require the deployment of technoloies that allow scale on-demand and can automatically respond to rapidly chanin demands. SDNs can brin all sorts of new opportunities to those operatin enterprise networks. However, one should not blindly traverse the path to SDN deployment. There are some recommendations that should help to smooth bumps on the path and speed adoption: Oranizations should develop a stratey that leveraes network prorammability to accomplish the oal of reducin OPEX, yet still provide hih-quality user fidelity, even when multiple traffic types compete for bandwidth. Use a phased approach to validate the value of SDN and reduce the risk associated with a lare-scale deployment. Conductin small-scale, proofof-concept pilots can reduce adoption problems and prove the value of the technoloy. Perform due dilience before selectin an SDN controller and validate elements such as support, compatibility, scale, usability and capabilities. STORAGE 10