The last two sections of this chapter have briefly introduced operating-system- level virtualisation to the reader and the challenges faced while building a platform for VNF deployment, illustrating how network infrastructures and datacentres can leverage containerisation technologies to design and deploy more scalable and robust systemss.
In light of the advantages offered, it is very compelling to inspect and study how lightweight virtualisation solutions can be adapted while constructing an NFV infrastructure as a concrete alternative to traditional techniques, e.g. hypervisors and virtual machines; this section will discuss in depth this is- sue, bringing some experimental data to justify the effort.
2.7.1
Potential benefits of containers and NFV
Container ecosystems (like Docker and such) have the potential to address some of the challenges that virtualisation poses when used together with NFV [16], such as the aforementioned performance and efficiency costs [17], the potential deployment slowdown issues caused by very large software images, and networking I/O overhead:
• As previously explained, applications in containers run on the host OS without any hardware indirection; thus, they can run more efficiently than their VM-based counterparts in many cases [18];
• A container does not ship a whole OS image, because it shares the same underlying kernel and system with its host. This leads images taking much less disk space than comparable VMs, allowing an higher appli- cation density on a host [19] and significantly decreasing time to de- ploy and migrate. Research is also being made towards live migration of stateful containers [20];
2.7. Container technologies and NFV 49 • The novel packaging system provided by Docker and similar technolo- gies can remove some of the variability in hosting requirements that a VNF may express, by shipping pre-packaged, full configured envi- ronments. Projects like the Open Container Initiative (OCI) [13] aim to standardize container formats, and make them even more platform ag- nostic.
Technology Time (ms) Mem (MiB) Size (MiB) Xen VM 6500 112 913 KVM VM 2988 32 913 Docker Container 1711 3.8 61
TABLE2.1: Performance comparisons [15]
As seen in the example presented by table 2.1, containers have much lower startup times and an overall inferior footprint on the system, thanks to their significantly lighter usage of system resources.
Network I/O advantages are less clear: containers are typically used to provide isolation for services that communicate using one or more network sockets bound to a port on the host; thus, it is critical to assess how much network virtualisation impacts them.
The inbound and outbount traffic towards and from the container is han- dled by the host’s network stack, using a software switch (such as the Linux bridge), that may add additional performance costs compared with bare metal. While many services typically deployed in containers are not bounded by network performance, most use cases for NFV have strict requirements for network throughput and delay; also, common techniques to improve net- work I/O performance such as Generic Receive Offload (GRO) and TCP Seg- mentation Offload (TSO) may not be appropriate for NFV, since some VNFs
(like L2 bridges, NAT, ...) need to work directly at data link level, inspecting Ethernet frames instead of TCP/UDP segments.
FIGURE2.6: Latency of different virtualisation technologies [16]
Several studies show that containers have the potential to reduce net- work latency when compared with a virtual machine running an off-the-shelf server operating system [16] [15] [14], but this is not without a few draw- backs.
2.7.2
Conclusions
In light of the benchmarks above and of further research data, it is possi- ble to summarise how containers and VM satisfy the requirement delineated before [15]:
• A container can spin up much faster than a VM, thus providing more service agility and elasticity;
2.7. Container technologies and NFV 51 • A container shares resources with their host, and thus has inherently less memory requirements than an equivalent VM: this is cause by the need of having a separate OS instance for each one of the guest;
• Hypervisors generally offer better security and isolation for their guest, compared with operating-system-level virtualisation; sharing resources with the host also means exposing them to the guest, increasing po- tential number of issues in case vulnerabilities are discovered. These technologies are also much older, and so they have been tested more thoughtfully for bugs and vulnerabilities; containers are relatively new, and as such still have a number of open issues. Use of kernel security modules like SELinux or AppArmor may help mitigate some of these concerns, offering the required features for a secure VNF deployment. This can also be integrated with resource quota techniques, to provide at least some of the resource guarantees necessary to a VNF deploy- ment;
• Both virtual machines and containers have largely supported, open- source and fully-featured management frameworks, so this is not an issue;
• Both containers and standard VMs can run any application a general- purpose OS can run. Containers are inherently restricted to be of the same type than their host OS, but this is generally non an issue.
These technologies have therefore both strengths and different usage sce- narios, depending on which security, isolation, performance and compati- bility criteria are required by the NFV operator. For instance, an operator may choose an hypervisor-based solution if isolation and multi-tenancy are mandatory requirements; if instead ease of application deployment is pre- ferred, it may lean towards the benefits offered by containers.
Hybrid solutions, where containers are run within VMs, are also pos- sible; a single VM may host several containers, offering at least full isola- tion from the host. For instance, Microsoft proposes an alternative solution to normal Windows containers, that allows a single instance to run with its own stripped-down kernel, using the Hyper-V hypervisor [21]. This provides full isolation to the container, while offering better performances than a full fledged virtual machine.