Network Automation with NFV on OpenStack

As NFV (network function virtualization) becomes trendy more network vendors are working on a solution of how to take their existing investment in network products and make them NFV enabled. The target is that eventually everything will run as virtual software components on commoditized hardware.
To this end, I actually decided to test this out with a real-world scenario.  In this two-part series, I’d like to present a YouTube-like solution, basically an elastic scale out/scale in video streaming solution that is NFV enabled.
The purpose of using a software LB in this experiment is to show a scenario where I take network components, a software load balancer in this example, and make them NFV enabled. Actually this is true for many network functions and in general to IT services, let’s call them virtual functions, VF.
<!–

Beyond simple automation – OpenStack orchestration to the max. Test drive Cloudify.     Go

–>

White Paper: NFV from ETSI to MANO to YANG. Get it today.     Go

Moreover, I wanted to demonstrate elasticity, through auto scaling rules. More about this later. For the orchestration part, dependencies and auto-scaling I used Cloudify.
The Challenge
Typically network components requires substantial code changes to turn them into an NFV service running on a cloud. The big challenge in NFV is how to take an existing network function and without code changes, put it on a cloud, e.g. OpenStack cloud.  Each component was built to run in a legacy environment, while not taking into account virtualization and cloud requirements.  Fore example, many components are monolithic and not built with right extensions to support cloud multi-tenant environments and post-deployment needs – auto-scaling, self-healing, and actionable monitoring-based KPIs. What’s more, each cloud has its own requirements in terms of network, compute and storage definitions, which complicates this even further.  And then add the fact that you’d like all of this to be cloud agnostic – have the freedom to run your app with its NFV components on any cloud you choose – and this becomes near impossible.
Moreover a cloud requires additional capabilities like:

1. Automatic deployment
2. Orchestration
3. Monitoring
4. Self healing
5. Auto scaling

Nowadays, if you don’t automate you don’t exist. Eventually everything will be automated and orchestrated, IT services, applications and network services. There are basic automation tools like Chef and Puppet. They mainly provide installation and configuration on a per node basis, but they don’t orchestrate dependencies between nodes, e.g. node A needs to start before node B, node B registers itself in Node A. In the example I’ll present in my next post, the Tomcat depends on the virtual load-balncer( vLB) service being available.
Orchestration is mandatory and actually it covers points 2-5 above. In addition to dependencies, how do you monitor your system, application and NFV services? How do you know if a component fails and needs to be restarted? How do you gather all this information? How do you apply active rules to the collected information?
Stay tuned for my next post where I’ll actually present how to do this in action, in the order of the challenges.
In the auto-deployment phase I connected video streamer software and ran it in a Tomcat web container, along with a virtual load balancer for my network components.  I then used an orchestrator to take care of all of the network definitions. Then came the metric definition for best monitoring results. And then in a chaos monkey fashion I tested to see how my system auto-scales on demand.
In part 2 I’ll dive into the bits and bytes and how you can play around with this yourself.