未加星标

Unikernels不适合生产环境

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

最近,我犯了个错误, 不小心问了下大家要不要聊聊为什么unikernels不适合生产环境 。结果大家的响应非常热烈:大家是否觉得unikernels方向就是不对的并且在寻找支持这一点的细节,或者你是unikernel的支持者并且想要知道反对它的理由到底是什么,大家确实想要了解反对在生产环境使用unikernel的原因是什么。

那么,unikernel有什么问题呢?让我们先看看定义: unikernel 是一种应用程序,完全运行在微处理器的特权模式下。(实际的术语可能有些许不同;在x86上称为运行在Ring 0下。)也就是说,在unikernel里,完全没有传统意义上的应用程序;相反,应用程序的功能被放到了操作系统内核里。(“没有OS”的理念有些误导;并不是说真的没有操作系统――而是“全都是OS”。)在我们讨论这么做的问题之前,值得花时间首先探讨unikernel出现的初衷――当然并不仅仅是因为它很小……

在操作系统内核里实现功能的主要原因是为了性能:避免跨用户-内核的界线做上下文的切换,可以让需要跨这个界线作切换的操作变得更快。在unikernel的场景里,这种说法其实很模棱两可:在现代平台运行时的复杂度和现代微处理器的性能之间,通常来说,应用程序并非最主要受限于用户-内核上下文的切换。这种说法也进一步被事实打败,因为unikernel严重依赖于硬件虚拟化来实现所谓的多租户。 正如我在之前的博文里详细阐述的 ,硬件层的虚拟化对性能影响巨大:将实际能够看到硬件的系统(也就是,hypervisor)和实际看到应用的系统(guest操作系统)隔离开,这样的硬件利用率(比如,DRAM,NIC,CPU,I/O)造成的效率损失,不管花多少努力都无法挽回。但是,在性能上太较劲并不值得;这里我只是认为unikernel的性能优势其实是可以被强有力地反驳的。

unikernel支持者的另一个理由是unikernel“更加安全”,但是这种说法的事实依据并不清晰。没错,unikernel通常运行更少的软件(因此攻击面更小)――但是并没有什么unikernel准则明确规定软件一定会更少。是的,unikernel通常运行的是新的或者不同的软件(因此没有 OpenSSL漏洞 )但是这种不大众则安全的论调适用于运行任何新的,深奥的系统。这样的安全观点似乎正在越过unikernel非常依赖的保护边界:由底层hypervisor提供的guest OS间的保护边界。hypervisor的漏洞肯定是存在的;我们不能一边认为linux内核的漏洞是无声的威胁,一边认为hypervisor的漏洞完全不存在。相反,剥夺了应用程序开发人员的用户保护边界,其实违背了 最小特权的原则 :应用程序里的任何漏洞都会重复地源自unikernel。在基于容器的部署世界里,这会带来烦人的问题――神秘的管理――并且更加严重(冒着更高的危险)。最好的情况下,unikernel是 安全威胁者 ,而最坏的情况下,则是安全的噩梦之源。

unikernel支持者的最后一个理由是它们很小――但是再次注意,unikernel的任何东西都并不是严格意义上的很小!对于我个人来说,我曾经在 小内核 和 大内核 里都做过内核实现;你确实可以拥有很精简的系统,并不需要使用unikernel这样的东西!(我个人是 Alpine Linux 的超级粉丝,它是支撑Linux应用程序以及/或者Docker容器的非常精简的用户域层。)要说unikernel没有太多代码,我只能说这看上去只是因为它还在发展初期,而并不是因为它从设计上就注定了没有太多代码。但是,仅仅通过代码来衡量unikernel的规模并不正确,并且这里unikernel的支持者忽略了大型系统的细节:因为unikernel作为guest操作系统运行,由hypervisor分配给guest的DRAM会作为整体被消耗――即使应用本身并不使用DRAM。因为内存耗尽仍然是一种最有害的应用程序故障模式(特别是在动态环境里),在这种需求里内存大小仍然被设计得过于精致和复杂了,常常无缘由的翻倍或者溢出。在unikernel模式里,任何这样的溢出其实就意味着丢失――其他任何东西都无法再使用它,因为hypervisor完全不知道这段内存实际被使用了。(这点和容器形成了鲜明对比,容器里应用程序没有使用的内存可以被其他容器,或者系统本身使用。)因此再次强调,当考虑到整体系统后,unikernel的这种说法就变得不那么一样了(如果不是完全反对的话)。

综上,有一些选择unikernel的原因:可能为了性能,一点安全上的威胁,以及软件崩溃列表。正如这些原因那样吓人,这是unikernel的好消息的终结。从这里往下的都是坏消息了:得到这些优点所需要花费的代价不小,而且这样的系统很脆弱。

unikernel缺点的第一条就是应用程序本身的机制。当操作系统界线被移除时,同时可能也移除了应用程序的和真实世界的网络或者持久化存储交互的接口――但是我们并不是真的不需要这样的接口了!一些unikernel(比如 OSv 和 Rumprun )采用的方案是实现一种“类似POSIX”的接口来最小化对应用程序的破坏。好消息:应用程序能工作了!坏消息:我提到我们 需要迁移了 吗?这里可是期望应用程序是“类似POSIX的”,不会扩展老旧的方式,比如 创建一个进程 :在unikernel里 没有进程 ,因此如果你的应用程序依赖于这种(普遍存在40年之久的)机制的话,你基本上就玩完了。(或者 更糟糕 )

如果这种方案不那么常见,在语言特定的unikernel,比如 MirageOS 里,事情则更为糟糕,MirageOS深度嵌入了特定语言的运行时。一方面,仅仅允许以类型安全的语言作实现掩盖了unikernel实际上的可靠性问题。另一方面,祈祷你需要的所有东西都在OCaml里吧!

所以说要想让你的应用工作可能会遇到这些问题,但是假设已经解决了所有这些问题:要么对于你的应用程序(或者平台)来说,unikernel暴露的POSIX接口已经足够了,或者已经用OCaml或者 Erlang 或者 Haskell 等完成了编写。你的应用程序能够运行在unikernel里,这时你会遇到unikernel的最大问题,这导致它完全不适合生产环境――并且当你想在实际生产环境上部署东西时,这个原因(至少对我来说)是unikernel的致命问题:unikernel完全不可调试。这里没有进程,因此当然没有 ps ,没有 htop ,没有 strace ――但是甚至也没有 netstat ,没有 tcpdump ,没有 ping !仅仅有一些陈年旧工具。当然也没有 DTrace 或者 MDB 。从调试的角度看,说它比较原始都太客气了:这不是旧石器时代――这是寒武纪。作为职业生涯都花在开发生产环境系统以及调试这些系统的工具的我来说,无法否定调试生产系统的必要性,unikernel支持者的严重隐患是:都缺乏运维的同理心。生产环境问题只要简单弄弄就能解决――在服务出错时重启就好了。这样的态度――即使仅仅是暗示了这样的想法――都能激怒那些曾经负责过运维系统的人。(你得认为我是局外人, 听听我在DockerCon 2015上的演讲,在我强调需要调试系统而不仅仅是重启后的欢呼声 )。如果不得不说的话,这样的态度很让人恼火,因为它是错误的:如果一个生产应用程序因为看上去不严重的问题比如 侦听失败 而开始出现故障,重启应用程序可能会错过最坏情况下重现问题的条件(也就是在高负载下),从而完全无法分析出该问题的根本原因(不足够的backlog)。

那么,有人能在unikernel里实现生产环境所需的调试工具么?两个字:不能:调试工具普遍要跨越用户-内核界线,并且在利用命令行提供的ad hoc查询时最为高效。提供这样功能的机构已经被以减重的名义故意移出了unikernel;任何提供足够精妙的可以用在生产环境里的调试工具的unikernel都会违背它自己的教条。unikernel不适合生产环境不仅仅是因为其实现,而且因为其构想本身:在生产环境上出错的时候完全无法理解出错的原因――即使通过它们自己的断言都不行,它们永远都不可能在此有所改进。

到这里,我确实发现unikernel支持者的一个共同之处:我同意容器变革要求一种比在虚拟硬件上运行的共享的Linux guest OS更为精简,更加安全并且更为高效的运行时――在Joyent,我们过去几年的关注点就是使用SmartOS和 Triton 来提供这样的运行时。同时我也看到unikernel支持者的一个共同的问题,我们的方案从本质上和unikernel是不同的:我们放弃了在多租户层上运行安全容器的想法,而是使用了已经保证了安全的 zones ,并且向其上添加了 原生执行Linux二进制文件的能力 。也就是说,我们选择利用操作系统的优势而不是否认它的存在,给Linux和Docker带来不仅仅是安全的容器,而且带来更多的优势,比如 ZFS , Crossbow 和DTrace。这也是最后要强调的地方:我们对生产环境的关注反应在我们所做的所有事情上,但是特别体现在 为调试生产系统所提供的大量工具 上――通过给Linux容器带来这些工具, Triton已经支持了我们之前认为不可能的生产环境上的调试 !

在适当的时候,我认为unikernel是最有效的,但是它却导致了消极结果:它们将主要用于演示对于生产系统来说不切实际的方案。因此,它们将加入 事务性内存 和 M-N调度模型 的阵营,成为没有未来的系统软件,终将在现实的考验下消亡。但是你并不一定要听我的:正如我的tweet里所说,无法调试的生产系统就是对他们的惩罚――并且仅仅惩罚他们自己,而不会影响我们!

原文链接: Unikernels are unfit for production (翻译:崔婧雯 )

===========================

译者介绍

崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

分页:12
转载请注明
本文标题:Unikernels不适合生产环境
本站链接:http://www.codesec.net/view/481088.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(37)