Our next generation network is basically built with mostly virtual network functions. These are services that ViaSat has migrated from custom/purpose built hardware to a virtual platform. One key component for construction of virtual networks is orchestration. It ties the deployment of the virtual network functions with the rest of the network using the network controller service that I wrote about in my last blog.
There are a lot of open source orchestration tools out there. ViaSat started with some: Heat/OpenStack. Most of the open source components did not fit our needs at that time. Very soon we realized that this piece needs to be built in-house.
The top things we needed from an orchestrator were:
- Ability to orchestrate real time applications – Most of our VNFs (Virtual Network Functions) have real time needs. They drive a satellite after all.
- Ability to create a network with real and virtual network functions – We are retrofitting a running network. Like changing tires on a race car while it is being driven.
- Ability to do hybrid clouds – We use public and private cloud-based functions.
- Ability to build services once and deploy everywhere.
- Scale services in and out.
We started with an orchestrator that we built for our labs and extended to support the service provider use cases.
The orchestrator is designed to sit in the public cloud and have agents that sit either in the tenant’s public or private cloud connect back to it. That way the tenant’s data is under their control all the time while still leveraging a Software as a Service orchestrator.
The basic block of Venom is the service template. Expert users can create templates representing complex networks comprising of real and virtual devices and configure them. Other users can take these templates and instantiate isolated instances of it in private or public clouds.
An end to end service can be comprised of several templates networked together in a hierarchical or serial fashion.
To handle Physical devices, users create proxy functions in Venom. The proxy functions are translated to real devices once they are instantiated.
Some of the benefits of designing things using these templates are:
- The same template can be used in the continuous integration cycle all the way from development to test to deployment – this reduces bugs drastically.
- People can share hardware in their own isolated labs with different topologies.
- The same topology can be instantiated in different locations and across cloud boundaries.
- We can have an “app-store” model where people publish tested microservice-based clusters. Other people can use these to create more complex services easily.
In the next post I will talk about monitoring in a virtual network environment. It is very interesting and hasn’t been solved completely.
This is the third article in our series on Network Virtualization. Please check out Pawan’s previous articles:
Virtual Service Provider Networks
Building Blocks: Dynamic Service Chaining