Unikernel调研


  • BCLinux Developers

    一、 介绍

    Unikernel是通过使用专门的库操作系统来构建的单地址空间系统镜像。开发者根据上层应用运行需求,选择其最小的依赖库,并将应用及其依赖库编译制作成满足特定用途的镜像,这个镜像可以直接运行在物理或者虚拟环境中,不需要类似Linux或Windows的操作系统介于其中。

    通用的操作系统(如Linux和Windows的各种发行版),通常会伴随着带来一些对应用来说并不需要的驱动、依赖包、服务等等。譬如USB驱动这类东西在虚拟化的云环境其实是无用的,但在内核运行时仍然会去将它加载进来。这些多余的内容既增加软件运行的负担,又额外消耗了非必须的资源。

    Unikernel试图抹去现代操作系统带来的一些复杂性,删除应用与硬件中间臃肿的部分,让最“精简”的操作系统运行你的代码。

    二、原理分析

    在通常的操作系统中,系统的内核与用户的应用程序之间是有明确分界的,在Windows或是Linux中都有清晰的内核态用户态定义,并通过系统调用的方式进行数据交换。这样做的目的是将操作系统与硬件打交道的功能与上层应用隔离,从而屏蔽其底层的差异性和复杂性。而在Unikernel的操作系统中是没有这种差别的,所有程序与底层的核心驱动都运行在同一地址空间,不存在运行时状态上下文切换的额外开销。其实Unikernel并没有专门的内核概念,而是将每个应用程序在编译时可以直接指定引入特定的驱动和核心library,相当于每个程序都是自带操作系统,而且是单独定制裁剪的操作系统。

    通过Unikernel系统方式构建出来的应用程序都是可以独立发布和直接运行在虚拟化平台上的,由于Unkernel系统原生不考虑多用户和多任务的复杂场景,因此可以做得十分精巧。一个应用服务就是一个操作系统,从而形成规模极大的操作系统集群。

    从下图可以看到虚拟化、容器和Unikernel的不同:
    0_1498373138886_20160506085020008.jpg

    传统容器技术中,所有的容器运行在同一个VM,共享同一个内核,通过内核提供的资源隔离技术(命名空间,cgroup等),实现容器的隔离。这种方式下由于内核是单一共享的,如果某一容器导致内核故障或者内核本身存在安全漏洞,则会影响到其他容器甚至HOST主机的正常运行(例如,利用内核的“脏牛””漏洞,在容器环境中就可绕过系统的安全策略,获取宿主机的root权限。这样就可以任意查看、修改甚至删除宿主机中的文件,从而对宿主机和其他容器造成安全隐患)。

    于是,有了第二种资源隔离方法。一个容器对应一个VM,每个VM都有单独的内核。不过由于容器中运行的业务单一,所以可以对这个内核做高度的精简,这样内核的启动开销可以小到忽略不计。这种方式,相比第一种提高了资源的隔离性,但是由于每个容器都需加载单独的内核,增加了系统的开销和资源占用率。Intel当前主推的ClearContainer技术就属于这个范畴。

    Unikernel与前面的不同之处在于,它启动的内核不是通用的内核,而是经过特殊定制化,针对运行业务的特定的内核。相比第二种方式,Unikernel的资源开销更小,而且由于所有进程运行在同一地址空间,不存在CPU优先级切换的额外开销,性能会有更大的提升。

    三、构建方法

    从头开始写Unikernel的代价太大,为此诞生了很多库操作系统。基于这些libOS,可以大大简化构建Unikernel的时间。库操作系统本质上都是一系列标准化的驱动和库,这样我们就不需要重复发明像TCP栈、持久存储层等这类东西。

    当前主流的库操作系统有:

    1. MirageOS

    MirageOS是一种库操作系统,可为各种云计算和移动平台上构建安全,高性能网络应用程序的单一内核。 MirageOS使用OCaml语言,现在有超过100个MirageOS库。

    2. Rump Kernels

    Rump Kernels提供了免费、可重复使用、组件化、内核质量的驱动程序,比如文件系统、POSIX系统调用、PCI设备驱动程序以及TCP/IP和SCSI协议堆栈。Rumprun Unikernel是一种随时可投入到生产环境的技术,它只有几千行代码,外加Rump Kernel组件,支持POSIX化的软件直接在原始硬件和云虚拟机管理程序(比如KVM和Xen)上运行。

    3. OSv

    OSv是一种为云设计的开源操作系统。它是从头开始全新设计的,旨在实现轻松部署和管理,性能很出众。
    OSv减少了传统操作系统带来的内存和处理器开销。调度很轻盈,应用程序和内核协同运行,内存池共享。OSv提供了无与伦比的短延迟和稳定性能,这减少了操作系统实例的大小和数量,直接节省了资本开支。
    语言运行时环境、操作系统和虚拟机管理程序都提供了保护和抽象机制。OSv简化了操作系统,从而尽量减少了这几层的冗余。

    4. ClickOS

    这是一种极简、定制的虚拟化操作系统,旨在运行基于Click的中间设备(middlebox)。
    网络功能虚拟化(NFV)潮流有望将中间设备处理从基于硬件的设备向在廉价的大众化硬件(比如配备万兆网卡的x86服务器)上运行的软件转变。ClickOS正是为实现这个目的而开发的一种高性能虚拟化软件中间设备平台。它包括在MiniOS(一种源自Xen的极简操作系统)上运行的Click模块化路由器软件,另外对网络输入/输出进行了优化,以便为几乎所有大小的数据包提供万兆吞吐率。这些虚拟机很小巧(6MB),启动速度快(大约30毫秒),增加的延迟很短(45微秒)。构建操作系统映像需要工具链(toolchain),而工具堆栈(toolstack)可以在数毫秒内启动虚拟机。

    5. Clive

    Clive是一个适用于分布式和云计算环境的操作系统,用GO语言编写。

    四、优缺点分析

    Unikernel对比通用操作系统有很多优势:

    1. 更安全

    一方面,Unikernel只运行操作系统的核心,抛掉那些可能是漏洞来源的视频、USB驱动、系统进程极大的减小了可攻击的面积。
    另一方面,对于Unikernel而言,每一个操作系统都是定制用途的,其中包含的核心库均不相同,即使某个服务构建的操作系统由于特定软件问题而遭到入侵,同样的入侵手段在其他的服务中往往不能生效。这无形中增加了攻击者利用系统漏洞的成本。

    2. 高性能

    Unikernel消除了运行时内核态与用户态切换的过程。Unikernel的核心驱动与应用程序是同时打包构建的,其内存是单地址空间(single address space),不区分系统内核区域和应用服务区域,因此不论是在启动速度还是在程序执行效率上都远高于通用的服务器操作系统。通常一个Unikernel系统的启动时间都在几十毫秒左右。

    3. 低资源占用

    Unikernel抹去了现代操作系统由于软件层级抽象而导致的复杂性。越是通用的操作系统(比如Linux或Windows)包含了越多对特定的应用而言并不必要的服务、驱动、依赖包等。譬如USB驱动这类东西在虚拟化的云环境其实是无用的,但在内核运行时仍然会去将它加载进来。这些多余的内容既增加软件运行的负担,又额外消耗了非必须的资源。

    4. 小体积,易部署

    Unikernel的镜像体积大概只有传统内核镜像的4%,而且Unikernel系统一旦编译完整就不可改变,想要对其中的内容进行重新定制的唯一办法就是修改源码然后重新编译。这种软件实施方式有点像使用一次性产品,即安装一次,不做修改,用过即扔。这种方式可以保障软件部署的一致性,提高运维效率和降低管理的复杂性。

    当然,Unikernel也存在一些问题,其中最大的问题在于“Unikernel是完全不可调试的”。 在Unikernel这种模式下,启动之后直接进入到应用程序中,出问题之后唯一的解法就是重启。
    另外,对Unikernel可以提高系统“安全性”业界也有不同声音。有安全专家认为运行内容少不能证明更安全,虽然Unikernel减少了系统攻击面,但是它也缺失了通用操作系统内建的大量安全机制,包括特权隔离、保护ring、强制访问控制、审计等。

    五、业务场景分析

    Unikernel与嵌入式操作系统非常相似,构建的镜像可以运行在虚拟化和物理环境中。不过由于Unikernel在编译时需要指定特定的驱动程序,所以制作的镜像在物理环境中不具备通用性。虚拟化技术向上层提供了统一的硬件层,屏蔽了底层物理硬件的差异,Unikernel主要还是应用在虚拟化环境中。

    Unikernel社区还不够成熟,尤其是生态方面,缺乏简单易用的工具,缺乏配套的生态工具。前面提到了一些构建Unikernel的库操作系统,但是这些库操作系统或多或少都有一些限制,不太方便使用。例如MirageOS有个很重要的特点是,它要求应用程序必须用Ocaml语言编写。这样它的编译器才能追踪代码依赖,寻找对应的library。当前主流的开源中间件,都是用C语言编写,难道需要将这些软件用Ocaml语言重写?

    六、参考

    1. https://en.wikipedia.org/wiki/Unikernel
    2. http://dockone.io/article/987
    3. http://dockone.io/article/855

登录后回复
 

与 BC-LINUX 的连接断开,我们正在尝试重连,请耐心等待