networking ICT Application examples
Virtual machines can be provisioned in minutes while non-SDN networks require manually configuration. When users want to reshape the cloud service it is not the VM but the network that is the bottleneck, delaying delivery for days or weeks while the manual work is completed. If the aim is to spread workloads across multiple data centres for flexibility and high availability, this becomes a monumental task. The traditional network architecture is not scalable or agile enough to meet user expectations for cloud computing.
Big Virtual Switch from Big Switch Networks is a successful example of an application that runs on OpenFlow enabled networks to resolve this problem. It creates a unified network topology and automatically distributes a forwarding table for each OpenFlow-enabled physical and virtual switch. By isolating the traffic of data centre workloads into Virtual Network Segments according to programmed policies, it supports dynamic workload provisioning and multi-tenant networks on a massive scale – accommodating more than 32,000 Virtual Network Segments and more than a 1000 switches.
This is not just a one-off action, for it dynamically updates the Virtual Network Segments to reflect real-time changes in workload definitions learned from the network and through integration with third-party applications, including cloud management platforms. Each network segment can support rich network security settings, quality of service policy, and other policies.
There is no better example of SDN’s traffic engineering potential than that provided by Google in their Wan backbone spanning data centres in Europe, North America and the APAC region. The project began in 2011, before most people had even heard of OpenFlow, so Google built its own network switch from merchant silicon and open source routing stacks with OpenFlow support in order to address five main challenges: £ Big networks don’t behave predictably enough £ Failure response and performance is suboptimal £ Difficulties in configuring and operating large networks
£ Dependency on manual, error-prone operations £ In addition, Google did not have the advantage of starting from scratch as in an academic pilot project – they were needing to connect to existing networks
The aim was to optimize the WAN routing for high performance and network utilization, while being able to monitor and control network behaviour from a central point. A vendor-agnostic solution was essential, and at each site Google had multiple switch chasses allowing scalability to multi-terabit bandwidth as well as providing fault tolerance.
Although centralized control is a feature of the SDN concept, when spread over an intercontinental WAN it made more sense to have central controllers at each data centre linked into an overall traffic engineering controller. Google’s centralized traffic engineering (TE) service collects real-time use and topology data from the network and calculates bandwidth demand from the applications and services. It then computes the best traffic flow path assignments and uses the OpenFlow protocol to program those into the switches. As demand fluctuates, or unanticipated events happen in the network, the TE service re-computes and reprograms the system.
Two years on, the system has proved itself to the extent that Jim Wanderer, Google’s Director of Engineering, Platforms Networking can claim: “OpenFlow in particular, and SDN in general, are still in the early stages of development, but I can say with confidence that, even at this stage, OpenFlow has proved its value to us in optimizing traffic efficiency on an extremely large real-world WAN.”
My third example is one that too often gets overlooked, and it is the question of policy and identity management in a situation such as VDI (virtual desktop infrastructure). In place of the usual asymmetric traffic model we now have two-way traffic running between the access device and the server and we need the same identity management policies to apply to both traffic flows – even if the VDI server and the desktop are located a long distance apart. Maintaining consistent policies between, say, an office in London and a data centre in Berlin, is a significant challenge, especially when the desktop is being accessed over a range of devices from smartphones to desktop computers. Here again, a central SDN controller can keep track of users and devices at both ends and ensure that consistent authentication, admission control, authorisation etc. policies are maintained and applied across the service without provisioning on a device-by- device basis.
Conclusion
My three examples might seem petty in terms of a technology predicted to change the entire networking game, but I present them simply as examples of what is already being done and is proving of value in easing today’s key pain points. This is just a beginning, and other proprietary approaches – such as shortest path bridging traffic management – do exist but offer nothing to match the flexibility, openness and scaling potential of the SDN concept.
In just two years a lot has already
been achieved, but it is nothing to what will happen once an open standard such as OpenFlow becomes the norm and we have the market base to support that bright young breed of network application designers.
44
www.dcseurope.info I February 2014
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52