Unikernels meet NFV
Unikernels – and particularly how suitable they are for NFV orchestration – was the topic of one 2015 research project here at Ericsson Research, Silicon Valley. We built a lightweight NFV PoC consisting of a network slice orchestrator, and designed a novel shared memory circuit based method for packet forwarding between VNFs (Virtual Network Function).
Our solution provides very good results in terms of server boot up time, service chaining complexity and memory footprint.
Here we’d like to share some details of how and why. You will also find a video demonstrating the NFV PoC.
Unikernel based NFV architecture
Our main motivation was to come up with a new kind of NFV architecture – without traditional pre-orchestrated, large VNF VMs, and not requiring complicated Service Function Chain (SFC) logic in the virtual switch controlled by an SDN controller. In addition, we wanted to preserve the security provided by hypervisor compared to container based VNFs, and to be able to scale up and down network slices in real time.
We built our NFV PoC, shown in Figure 1, using Xen hypervisor and MirageOS unikernel technology.
Figure 1 Unikernel NFV architecture
Our PoC consists of a network slice orchestrator called “Lightning”, that is created per network slice. This entity is a unikernel running in the hypervisor OS as a process, in order to access both global Irmin subscriber datastore and local XenStore configuration database. The Lightning module can create network slices based on subscriber policies stored in Irmin.
We also designed a novel shared memory circuit based method for packet forwarding between VNFs like NAT, FW and DHCP server. This allows us to move packets without requiring pre-programmed network switching between the VNFs.
Our results show VNF boot up times around tens of milliseconds for typical VNF types such as DHCP server, NAT and FW. Our approach enables service chaining between VNFs without complex rule sets in the virtual switches. In addition, the resource requirement for the VNFs could be kept to a minimum and only a single vCPU and few tens of MB of memory was required per service.
To learn more, watch this video demonstrating our concept.
The world premier of our lightweight NFV PoC was in January, 2016, at the 14th annual Southern California Linux Expo (SCALE 14x) in Pasadena, California. Our presentation was part of a cloud innovation workshop on Unikernels, organized by Xen. where most of the Unikernel community had gathered to showcase their technologies.
Unikernels are maturing from research projects to become a viable production environments. Evidence of this is highlighted in the announcement from Docker about acquiring “Unikernel Systems” startup earlier this year. At the DockerCon last year, these two companies already showed how Docker frontend tools could be used to deploy Unikernels instead of Linux containers. Unikernels will surely play a role in the near future in the deployment of microservices in cloud environments. For this reason, we are continuing with our research and development activities focusing on our lightweight NFV framework and also exploring new ways to leverage the features it provides in different networking use cases such as 5G and IoT networking.
Cloud Software Evolution; from SOA and microservices to Unikernel based nano-services
Cloud software engineering has reinvented itself by moving from Virtual Machine (VM) based Service-Oriented Architectures (SOA) to Linux container based microservice architectures. Containers provide a more flexible deployment model than conventional VMs while at the same time, consuming less HW resources than VMs. One unique design concept for microservices is share-as-little-as-possible (when SOA’s principal design concept is share-as-much-as-possible). Such design concept enables microservice software to be architected from independent and interchangeable components that are easy to scale up and down together with demand.
However, container based microservice architectures do not follow the microservice concept throughout the design. Particularly the microservices share installation images, a full host kernel and OS libraries and binaries. This leaves the container based microservice architecture open for vulnerabilities that are found in the host OS or kernel. In addition, the host system can be vulnerable to the software deployed into the containers. Figure 2 shows the difference between the fully virtualized SOA and container based microservice architecture. Security provided by hypervisor in the VM architecture is lost in a Linux container architecture as the containers are executed within the same host OS.
To address these issues with VM and container based cloud frameworks research community has been working on completely new way of architecting cloud software. This new software concept is called “library OS” or “Unikernel”. Unikernels compile the runtime OS from libraries that are linked together with the microservice software as shown in Figure 2. The statically linked unikernels are executed on top of a hypervisor such as Xen or KVM. Table 1 shows the different unikernel projects listed today at unikernel.org website. There are many different flavors of unikernel runtime systems that can be run on variety of hypervisors. Developers can choose a unikernel format that best suits each intended application, or mix and match technologies.
Using a hypervisor provides full VM isolation between the different Unikernel VMs and the host OS. Since all unnecessary code can be left out of the unikernel image, their image size is much smaller (tens of megabytes) and their attack surface is significantly reduced compared to existing virtualization technologies. In addition, they boot much faster (< 1 second) than containers or VMs. Unikernel concept provides a completely different way of designing cloud software for applications such as Network Function Virtualization (NFV) that require rapid scaling up and down based on utilization.
Ericsson Research, Silicon Valley.
Ericsson, Silicon Valley.
Ericsson Research, Silicon Valley.