libos 介绍

libos 介绍

libos 背景

最早的库操作系统(Library OS,LibOS)基于外内核架构,目的是验证在用户空间管理系统资源的可行性和高性能性.但是,由于外内核还停留在研究上,实际应用中仍以宏内核和混合内核为主,因此LibOS一开始并没有引起学术界和产业界的过多关注.伴随云计算的快速发展和物联网的兴起,为了构建安全高效的Unikernel云服务和物联网微服务,LibOS成为了新的研究热点.

Unikernel 简介

『Unikernel』的概念在早在20世纪90年代的时候就已经有雏形了，它是一类特殊操作系统的通称，有点像我们现在所说的『容器』或者『Container』，是个概念层面的东西。最早的Unikernel操作系统原型是Exokernel和Nemesis，之后相对比较出名的有Xen社区主导的MirageOS、前Kvm开发者主导的OSv、以及由NetBSD公司开源的Rump Kernels。

Unikernel的前身是libOS。这个概念源于当时嵌入式操作系统架构的一次研究性的尝试，它将操作系统应用于各种硬件设备的驱动进行抽象，形成了各种不同的可替换的library，这与Linux系统最初的发展有些相似。然而这些创造者们走了一条与Linux内核不同的发展路线，他们没有将驱动与系统代码进行进一步的封装和整合而形成『内核』，更没有使用诸如『内核态』与『用户态』的划分，而是让使用系统的使用者和开发者直接与驱动通信，只需要在编译时候引入适当的的library，便能构建出快速适应不同的硬件设施的应用服务。

随着libOS的发展，出现了许多各立门户的操作系统分支，这些系统通常都只会具备有用于特定硬件的专属驱动，由于开发者自身的喜好和偏向性，各系统对不同硬件的支持差异较大。而同一时期诞生的以Unix和Linux为代表的另一操作系统门派，凭借着更好的易用性和统一性逐渐占领了主导地位，这个门派也就是现在大家所熟悉的大而全的系统内核，多用户，多任务，加上严格的内核与用户分界的操作系统风格（要是当年胜出的是libOS，整个计算机行业的发展路线也许就完全不一样啦）。

值得庆幸的是，在libOS并未完全没落之前还发生了一件事情，那就是虚拟化技术的兴起。随着虚拟化的广泛应用，一些libOS系统也开始提供用于虚拟化基础设施的library驱动。正在libOS逐渐势弱之际，当时的虚拟机化新秀Xen发布了一个独立的社区操作系统项目：MirageOS。这个项目是一个基于libOS理念设计的开源操作系统，但它比其他的libOS系统更进一步之处是，索性直接抛弃了所有物理硬件的驱动支持，专心一致做虚拟化，而将硬件的差异统统交给虚拟化平台去完成。同时，MirageOS借着Xen虚拟化的广泛应用，打出了所谓『Cloud Operating Systems』的大旗（因为MirageOS也就只能运行在虚拟化的云平台上），并将同一时期诞生的这类libOS操作系统都统称为『Unikernel』。

在 MirageOS 之后，Unikernel 的叫法就被沿用下来了。此后还陆续诞生过许多基于这种设计理念的操作系统，例如：ClickOS、Clive、HaLVM、LING、Rump Kernels 和 OSv 等。

另外，在远古时代，计算机只是用来辅助计算的工具，计算机上跑的是一些特定的计算任务，给定一些输入，得到一些输出，这个过程非常朴素。操作系统的诞生来自于共享硬件的需求。当几个人希望同时使用一台硬件设备、或者一个人希望同时运行多个计算任务的时候，就需要一个更高权限的管理员来统筹调度，按照一定的规则来给每一个 task 分配资源。

如果一台设备上只是运行少数几个 tasks，那么只需要一个简单的管理员进行 brute-force 的资源分配就可以了，这甚至可以通过人工管理员手动来完成。然而随着硬件能力的迅速发展，一台设备上只运行少数几个 tasks 变得非常不划算，对 tasks 数量 scalability 的需求急剧增长，这时候就不能再使用简单的方式进行资源分配了，对操作系统的需求应运而生。操作系统中的 kernel 就是资源的管理员。

对操作系统的研究与讨论中诞生了虚拟化这个概念。虚拟化极大地简化了资源分配的过程，于是有了 The art of operating system is the art of virtualization 这种说法。市面上也出现了各种各样、各具特色的操作系统。针对不同需求，有时候需要选择不同的操作系统。

随着硬件能力的进一步发展，类似的 pattern 又一次出现。对于一个计算能力强大的服务器而言，在其上只跑一个操作系统显得十分浪费，于是诞生了各种 hypervisor，使得一个机器上可以跑多个操作系统。在这个时代，人们可以租到云服务器，拥有一个自己的操作系统，在其上 host 各种服务，与成百上千个用户共享同一套底层的硬件。

随着时代进一步发展，人们发现用云服务器非常的不方便：性能上限太低，下限太高。上限太低使得服务器无法很好地处理爆发式的大规模请求；下限太高使得闲置的服务器也需要收取不菲的费用。这时候出现了 serverless 的概念，用户提供自己希望运行的函数，在它每次需要执行的时候，开启一个 container ，执行完成后就将 container 删除。这样没有请求时就不会被收取费用，而有爆发请求时也可以很好地处理。Linux 提供了 LXC 技术来使得不同的 container share 同一个 kernel，然而 share kernel 必然带来安全隐患，因此目前大部分厂商的架构里，每个 container 都有一个自己的 kernel，从这个角度而言，一个 container 更像是一个 VM。

然而站在这个角度回头看 kernel 最初的 motivation 就会发现奇怪的地方：如果一个 container 的整个生命周期都只为一个 task 甚至一个函数服务，那么 why do we ever need a kernel in the first place ？答案是我们实际上不需要 kernel ，至少不需要一个完整的 kernel 。但是 modern software 从开发到部署整个过程都高度依赖目前世界上已有的软件抽象（或者叫：“环境”），回到远古时代的软件编写模式并不现实。那么有没有一个解决方案，让我们既可以 host 目前 kernel 上可以 host 的 applications ，又可以抛弃掉 kernel 中那些不必要的部分呢？ 这个问题的答案就是 Unikernel。

一个 Unikernel 包含一个 application 以及运行这个 application 所需要的自上而下的所有环境，包括标准库、协议栈、设备驱动等等。舍弃了不需要的部分使得 Unikernel 的 image size 更小，运行速度更快。比如一个基于 UDP 协议的服务器就不需要一套 Linux 中完整的网络协议栈。

Unikernel 试图解决的：删除应用与硬件中间臃肿的部分。让最“精简”的操作系统运行你的代码。

libos 主要特点

Unikernel是通过使用专门的库操作系统来构建的单地址空间机器镜像。开发者通过选择栈模块和一系列最小依赖库来运行应用，而这些栈和库对应于操作系统中运行应用所必需的依赖。

这些库负责应用和配置代码编译，构建成封闭的、固定用途的镜像（即 Unikernel）可以直接在虚拟机管理程序hypervisor或硬件上运行，不需要类似Linux或Windows的操作系统介于其中。

---- 维基百科：Unikernel

Unikernel 试图抹去现代操作系统带来的一些复杂性。因为“通用”的操作系统（就像任何 Linux 和 Windows 的发行版），通常会伴随着带来一些对你的应用来说并不需要的驱动、依赖包、服务、等等，但这些对每一个操作系统来说某种程度上又是必需的。

甚至是在 Linux 内核的核心模块都并不是需要每一次都完全加载。像USB 驱动这类东西在虚拟化的“云”环境被认为是无用的，但仍然会被包含在内核中。

libos 与其他系统的对比

一些宏内核的问题

• 虚拟化环境中内核和应用程序的切换可能是多余的，因为由 hypervisor 来进行隔离，会导致性能下降。
• 在单应用 domain 中多地址空间没有用。
• 对于 RPC 类型的服务器，线程是没有必要的，单进程, run-to-completion event loop 可以得到一个好的性能。
• 对于基于 UDP 的性能应用中，许多 OS 网络栈是不需要的：app 可以仅仅使用驱动 API，就像 DPDK 做的一样。
• 直接访问 NVMe 存储可以不需要文件描述符、VFS 层和文件系统。
• 内存分配器对于应用程序性能有巨大的影响，通用分配器对于很多应用程序不是最佳的选择。如果应用程序可以选择不同的内存分配器将十分完美。

Unikernel对比通用的操作系统例如Linux有许多优势：

• 安全性的提升：只运行操作系统的核心，废弃掉那些可能是干扰源的视频和USB驱动。
• 占用很小空间：想象一下能够抹去95%内核的大小，因为你的应用不需要那些。
• 定制的实现：深谙应用并且把内核精简调整到你想要的部分。
• 快速精准的运行Unikernel实例（就像运行一个Docker实例一样），启动时间少于1s。

ArceOS 相比 Unikraft 的优势

• 使用 Rust 编写，具有现代化包管理（crate），条件编译和引用更简单。
• 可以更为轻松扩展模块，例如 hypervisor 可以和 ArceOS 使用相同模块。
• 原生支持异步，可以在内核重写 tokio runtime 进行调度。

libos 安全性

• 只运行操作系统核心，极大的减少了可攻击的面积；
• 每个系统都是定制用途，所用核心库不同增加了攻击者利用漏洞的成本；
• 编译后的二进制代码没有像 Linux 操作系统的 syscall 等标准接口，增加了被攻击的难度；

libos 发展

• 2016年1月21日，应用容器引擎 Docker 宣布收购了英国的 unikernel 实现初创企业 Unikernel System。

• 随着技术的发展以及国家自主可控的政策，金融行业对于技术本身的关注度也越来越高，从oracle到mysql，从小型机到x86服务器，从vmware到openstack，这些技术路线都意味着金融行业的IT技术能力的强化和完善，掌握开源技术，自定义软件也成为了金融IT界的常态。根据GitStats的统计，在linux kernel 4.1版本发布时，linux项目目前已经有了19509218行代码，这样的代码量和操作系统本身的难度对于金融IT提出了挑战。Unikernel技术对于内核的精简以及模块的提取为金融IT创造了良好的摆脱操作系统厂商绑定，完成技术转型，实现操作系统级别优化和深入的机会，我们对其保持持续关注和继续跟进研究状态。

• Unikernel 相比于虚拟机有着更小的启动内核，更快的启动速度，相比于Docker，有着更好的隔离性，更小的内核态库。其网络通过tap设备连接到宿主机，可以对接现在各种SDN方案，其存储方案还需要更深入的研究。

• 目前已有的类似系统

  • rumpkernel 基于驱动程序组件的 Rumprun 统一内核提供了一种在 Xen 上以统一内核的形式运行现有 POSIX 应用程序的方法。

  • Unikraft 通过使您能够从根本上定制和构建自定义操作系统 / 内核、释放一流的性能、安全原语和效率节约，为下一代云原生应用程序提供动力。

  • NanoVMs 比容器快 10-20 倍，兼容 linux 的 API，可以直接运行linux的程序，主要针对云端部署

  • MirageOS基于OCaml语言并且让unikernels运行在Xen hypervisor上。

目前的主要应用场景

• 虚拟化部署
• 云端部署

参考文档

到底什么是 Unikernel？

谈谈Unikernel

Unikernel 学习笔记

Unikernel初体验

On rump kernels and the Rumprun unikernel