Mark Shuttleworth在十几年前发起了Ubuntu inux项目，现在他在Canonical(一家提供Ubuntu支持服务的公司)主管战略和用户体验。他认为新一轮的服务器虚拟化浪潮与前一轮不太相同。

在他的指导下，Canonical和其他的Linux机构一样，在其发布版本中先是Xen Hypervisor，接着是KVM然后继续支持Docker，成功地赶上了虚拟化的几轮潮流。当Eucalyptus是用的可计算云控制器时该公司成为排头兵，而当业界开始支持另一个开源项目- OpenStack而且OpenStack做为Linux的首选被部署到多个公有云上时，他们也迅速地转向OpenStack。Docker及其软件容器方式完全类似于虚拟化并且让云计算服务商为之癫狂，但是让Shuttleworth兴奋的是另一种称为Linux容器 (缩写为LXC)的技术及与之相应的称为LXD的Hypervisor。LXD是由Canonical开发的一个后台进程来管理这些容器并且提供了或多或少与开源的Xen及KVM、微软的Hyper-V或者VMware的ESXi这些服务器虚拟化Hypervisor类似的功能。

Shuttlworth向The Next Platform表示：“我们相信这是十年来对Linux虚拟化最大的突破，你可以看到我们对此是多么兴奋”。

LXC容器的想法和初期的工作都是由Google完成的，容器化应用程序已经在其基础架构上运行了超过十年时间，而且据说每天会启动超过20亿的容器。Canonical和其他大约80个组织已经开始致力于LXC的商业化，因为LXC最初并不是一个对用户很友好的技术。商业化是为了让其具有常见服务器虚拟化的观感和体验，尽管它使用的是非常不同且简化的技术。

“对于容器，很多人并不了解的是我们用来配置容器的系统其实可以用很多种方法来做虚拟或者模拟”，Shuttleworth解释说”有时你希望模仿看起和Docker类似的东西，而有时你又想模拟其他的东西。就LXC而言，我们想要创建容器的途径是创建假想的主机，而不是运行操作系统的主机或者构成一个操作系统的所有进程。这与Docker所作的完全不同,虽然它们都使用相同的底层原语，但是创建了不同的的东西。LXC的宗旨是不借助硬件虚拟化来创建虚拟机“

说起Docker，它在早期是基于LXC的但是现在它有了自己的抽象层，它更像一个运行在文件系统之上的单个进程，就好比你启动了主机但并没有运行 Init和所有构成操作系统的进程而是直接运行数据库或者其他的东西，然后在一台主机上启动多个容器并把它们一起置于其中。通过LXC及其LXD守护进程，Canonical希望保持拥有一个完整Debian、CentOS、Ubuntu或其他Linux操作系统的感观。

“在LXC 1.0中，常见的情景是程序员说：“给我创建这个容器”。现在我们做法接收代码然后将其纳入LXD守护进程来管理，因此并不需要由程序员去创建每一个容器，我可以拥有上百个虚拟机并且与LXD守护进程进行通信来进行统一管理，因此我所拥有的虚拟机集群与你使用VMware ESXi hypervisor所构建的类似。把LXC打包到一个守护进程中就使得它变成了一个hypervisor。什么是ESXi?它基本上是一个操作系统，你可以通过网络跟它通信并且让它给你创建一个虚拟机。通过LXD，你可以跟一个运行LXC的主机说给我创建一个运行CentOS的新容器。这成为一个集群的导引机制。”

LXD也提供了另一个重要功能：它是运行的在两台不同物理主机上的一个软件，从而使得LXC实例能够在主机间在线地迁移。

程序员都追求简洁而且他们喜欢保持事物有序和整洁。在某种程度上，只是因为硬件虚拟化的成本很高就不得不把程序部署到多个主机上已经成了一个痛点。现在，你可以快速地在一台主机上运行多个程序而没有这些开销并且始终保持他们的原始状态和隔离。

本周，Canonical发布了首次包括LXD hypervisor的LXC 2.0 beta版本。在本月将要发布的Ubuntu Server 15.10的更新中就包括这两个组件，而Canonical也通过统一步骤把LXC 2.0反推入Ubuntu Server 14.04 LTS(LTS是Long Term Support的缩写)的服务器版本。LTS版本每两年发布一次而且具有五年的支持生命期。由于它的稳定性有保证，所以70%的客户都在生产环境中运行 Ubuntu服务器的LTS版本。据Shuttleworth说，包含LXD hypervisor的LXC 2.0生产级别版本将在明年亮相，根据命名方案的建议可能就在二月或者三月最迟到4月就与新的企业级版本 – Ubuntu Server 16.04 LTS一同发布。负责Ubuntu产品和战略的Dustin Kirklan对TheNext Platform说，从下一个LTS版本开始，在每一个Ubuntu Server中就会缺省安装LXC和LXD组件，这样每个主机都可以运行几十到几百个容器 –IBM在最大的使用POWER处理器的服务器上甚至可以运行数千个容器。

相比于依靠硬件虚拟化的常规虚拟机，LXC容器具有两个巨大的优势：一台主机上可以打包的容器数量和这些容器的启动速度。尽管为了在一台硬件上用不同的容器运行不同的Linux需要一些额外的工作，但是由于LXC其实就是用Linux运行Linux，所以不需要虚拟什么。

“这在性能方面前进了一步，而在密度方面的改进则是巨大的”，Shuttleworth无不得意地说：“而这对于低延迟、实时型的应用程序具有显著的改善。在云计算环境中这类事情都变得容易处理了，当然过去他们可不是这样。如果你的云平台运行了LXC，很快高性能计算可以搞定了、云计算平台上的实时计算也可以搞定了，而且如果你是一个需要低传输延迟的电信运营商的话，那么NFV(网络功能虚拟化)也可以搞定了。在这些需要巨大资金投入的领域，人们真的希望使用云计算和虚拟化，而LXC使其成为可能。这是非常令人振奋的”

Shuttleworth说LXC容器在密度方面可以达到诸如EXSi、Xen或KVM这类使用虚拟机的hypervisor的14倍，而且 LXC和LXD组合在开销方面却只占基于硬件虚拟化的Hypervisor的20%不到。对于空闲的负载而言，VM和LXC容器就和大多数VM和物理主机所作的一样大部分时间在等待。对于繁忙的VM而言，LXC容器则能够提供明显要好得多的I/O吞吐量和更低的延迟。因此，对于空闲的主机你专注于整合，而对于繁忙的主机你专注于吞吐量和延迟。而且由于Hypervisor和VM的特定开销可以释放出来用于实际工作，所以你可以得到大约20%的性能提升。

现在已经开始对LXC及LXD组合进行基准测试。在上周东京召开的OpenStack峰会上，Canonical LXD开发团队的Tycho Andersen展示了一些在虚拟化环境中的测试基准，其中一个是使用Hadoop TeraSort测试而另一个是对Cassandra NoSQL数据存储的压力测试。这两个测试中，主机运行的是在峰会期间发布的最新OpenStack “Liberty”云控制器和同样刚发布的Ubuntu 15.10. 15.10，它既有KVM也有LXD hypervisor和各自的虚拟机和容器。这些服务器配备了24核和48GB内存，一个控制器负责管理OpenStack而其他三台用作基本的计算节点。

在TeraSort测试开始的时候，在三台主机上LXC和KVM的表现基本一致，但是当OpenStack/Hadoop集群中的主机数量随着数据集的规模增长后，两种不同的虚拟化手段在性能方面的差异开始显现。

你可以看到LXC/LXD同KVM在延迟和吞吐量上的差异是非常明显的。

爱立信研究院和阿尔托大学发表了一篇很有意思的论文，它表明主机在运行LXD和Docker时比运行Xen和KVM能节省更多的能耗，你可以点击这里查看。在CPU和内存的基准测试结果中，随着更多的VM或者容器加到主机上，服务器的功率随之消耗上升而且两者之间的差距并不明显，但是当他们处理网络流量时，Docker和LXC在完成相同的工作时要少消耗10%的能耗。

由于容器的轻便特性，使得LXC容器毫无意外地用于很多云计算平台，而且极有可能成为未来基础架构云的基础 – 至少是那些只运行Linux的云基础架构平台，因为LXC不能运行在数据中心中的另一种重要操作系统 – Windows server上。但尽管如此，大多数重要的新软件是在Linux之上开发的 – Hadoop、Spark、NoSQL数据库、多种文件系统等等，所以这不会受限于人们所构建的平台的特定部分。

有意思的是正如那句俗话“吃自家的狗食”所言，现在Canonical也在用LXC容器部署他们的Ubuntu OpenStack。这使得管理员能够分步地升级OpenStack或者把部分负载从硬件上移走来发挥硬件的性能。Shuttleworth说，在一个典型的小规模OpenStack云中你可以用八台管理节点来运行管理平台的所有组件，而且你希望以一式三份的方式来运行它，这样即使有你失去了一个节点，还能通过另外两个来保持高可用。这就需要32台物理服务器。通过把这些组件打包到LXC容器并通过LXD hypervisor进行管理，这些管理平台的大部分组件都可以打包到同一个物理服务器上从而缩减了OpenStack管理平台的物理服务器规模却不会牺牲性能和可用性。

“程序员都追求简洁而且他们喜欢保持事物有序和整洁。“Shuttleworth解释道，”在某种程度上，只是因为硬件虚拟化的成本很高就不得不把程序部署到多个主机上已经成了一个痛点。现在，你可以立刻在一台主机上运行多个程序而没有这些开销并且始终保持他们的原生态和隔离。很开心的是可以看到当LXD出现时是如何改变了他们的行为。它在感觉上很像一个虚拟机但是却更加轻量”

谈起LXC，Shuttleworth告诉我们”红帽很难忽视我们而且他们最终把LXC加到了RHEL 7当中“，而Kirklan说尽管Canonical做了很多努力使得KVM管理工具libvirt支持LXC，但是libvirt的维护者还是专注于 KVM虚拟机而非容器。”所以他认为这事儿有点棘手。而Shuttleworth说：”红帽一直以来想试图把容器的想法曲解为轻量级的VM，因为他们在 KVM投入了大量的资金，而这就扭曲了他们的世界观”

推动LXC和LXD普及的关键因素是这样的一个事实，即企业(超大规模的)和高性能计算(HPC – High Performance Computing)中心里的大量负载都是运行在Linux之上，而且这些组织希望在迁移基础架构的时候能够保留这些应用程序。恰恰是这个需求使得 VMware成为企业数据中心领域60亿美元的巨头。

作为一个例证，Shuttleworth说Canonical已经与Intel和其他一些不具名的HPC中心在LXC容器基础上利用LXD hypervisor以近乎裸机的性能来测试以前的仿真和建模代码。”想一想这是怎样的场景。现在一个超级计算机运行着管理员最喜欢的操作系统，而科学家们能够获得裸机的性能同时还可以访问他们最熟悉的操作环境。这一切都得益于虚拟化而且两者获得了所期望的东西而没有任何物理主机虚拟化带来的困惑。

私有云先行，而后公有云

LXC和LXD都不需要使用OpenStack云控制器，但是在数据中心里这三者将极有可能要在一起配合。 Shuttleworth说根据OpenStack社区的最新统计，Ubuntu server支撑着全世界一半以上已安装的OpenStack云而且它也占据了最大的OpenStack集群中百分之六十五的份额。Canonical的 Ubuntu OpenStack发行版本已经被沃尔玛、AT&T、Verizon、NTT、彭博社及德国电信所采用 – 都是成功的大单。此外，上周在东京的OpenStack峰会上，Shuttleworth补充说他看到没有一个在Ubuntu上运行OpenStack的企业客户对LXD不感兴趣，因为其经济性和密度实在是太棒了。

总体而言，这些都是私有云的成功案例。Shuttleworth认为长期目标是使公有云服务商把LXC和LXD作为其基础架构和平台服务的基础，但是要实现这个目标大多数公有云服务商可能要等到X86、Power及ARM服务器拥有虚拟化专用电路来为LXC和LXD提供与KVM、Xen或者 Hyper-V等同的硬件安全(当然，这和平台有关)。当前，Linux社区能够为LXC容器提供Linux内核内的安全防护，但是这对于云服务提供商而言是不够的。至于这些功能合适会加入到至强、Opteron、Power和ARM芯片中还不得而知，而且Shuttleworth也没有透漏 Canonical的硬件合作伙伴的路线图。

本文作者：李毅

来源：51CTO