SmartOS——与众不同的虚拟化技术

上次详细介绍了基于Joyent技术的风起亚洲（Fengqi.Asia）公共云。那些对Amazon EC2有兴趣，但又因为EC2未进入中国而烦恼的用户们，不妨考虑用用这个风起亚洲公共云。其实 Joyent 本身也是以Amazon EC2的最佳替代品的身份加以宣传，不过不可否认，EC2有其他公共云暂时无法匹敌的市场份额。

引言：SmartOS与ILLUMOS

这次谈谈风起亚洲最引以为傲的 SmartOS 系统（风起亚洲公共云也提供CentOS、Ubuntu、Windows等操作系统，但性能最好的还是SmartOS）。严格来说，SmartOS 并非Solaris，但也保留了一些Solaris的特性。所以说 SmartOS 和 Linux 是有一定区别的，这个学习需要一点时间，但是值得你去付出，因为 SmartOS 中很多杀手级特性都是 Linux 不具备的。

SmarOS 是基于 Illumos 核心（注：第一个字母是i，后面两个才是l），之后大牛们还将KVM移植了进去。而 Illumos 基于 OpenSolaris 项目的（已不复存在）。实际上，Oracle 收购 Sun 后，对 OpenSolaris 态度很冷淡，毫无兴趣，关闭源码。大多数Sun最优秀的工程师转投入 Illumos 旗下。现在他们大多数都在 Joyent 和 Nexenta。具体的故事我就不详述了，有兴趣的可以看看这两篇文章：

• 从 Solaris 到 illumos – 关于技术权力抗争、开源以及梦想的故事：http://dbanotes.net/opensource/Solaris_Illumos.html
• KVM on illumos：http://dtrace.org/blogs/bmc/2011/08/15/kvm-on-illumos/
  

Illumos 提供了一个通用内核和一些基础的系统工具。基于 illumos 的发行版软件都有一些很赞的体验，这里提几个让人印象深刻，最具创新的distributions（参考链接）：

• OpenIndiana 那些有 Solaris 或 OpenSolarisis 背景的人可能比较熟悉这个东东。OpenIndiana 项目的目标是继续开发和发行 OpenSolaris。该项目隶属于 Illumos 基金会。由于 Oracle 宣布不再发行 OpenSolaris ，该项目被建立以为 OpenSolaris 继续其更新。
• Nexenta CP 即Nexenta Community Platform，现在成为 Illumos 旗下的一款产品，改名叫 illumian 了，何去何从可以参考此链接。现在只能看到 NexentaStor 了，它是Nexenta 公司推出的基于 OpenSolaris OS 和 ZFS 等技术的一个 NAS 软件解决方案。如果你熟悉 Linux，尤其是 Debian 或 Ubuntu，那就会很快上手。ZFS文件系统（Zettabyte File System）是 NexentaStor 的亮点，它是一种基于 Solaris 的128位的文件系统，强健可靠、可伸缩、易于管理，突出了对数据完整性的保护。我之后还会专门写文章介绍 ZFS，不过网上也已经有很多类似的文章了。
  
• SmartOS 是由 Joyent 提供的 community distro，可以认为是 SmartDataCenter 商业化产品的一部分。这次就要专门谈谈它及其独特的虚拟化技术。

其实illumos还出了一些很好的书，这些书现在网上都有电子版，链接是：http://illumos.org/books/ ，详细介绍附在文章末尾。

回过头来，继续说说SmartOS。风起亚洲采用Joyent技术基于底层硬件和操作系统之上为客户提供一个坚实的基础云平台。

Joyent SmartOS与SmartMachine、SmartDataCenter以及物理机紧密集成，在各个层面保证云平台的安全性。与其他的云服务供应商不同，风起亚洲的虚拟资源驻留在SmartOS中，而不是在虚拟机本身。这种包容性的虚拟化架构避免了Web应用层和操作系统之间接口的潜在漏洞。在网络层，Joyent的SmartDataCenter支持动态的虚拟局域网（vLAN），使客户在任何时候都可以有效隔离云平台上的不同用户。风起亚洲和Joyent的安全保障架构图如下所示：

SmartOS简单可以解释为：“illumos-derived OS that is the foundation of both Joyentʼs public cloud and SmartDataCenter product”。 既然作为是illumos的衍生产品，那么它具备几个上篇《风起亚洲（Fengqi.Asia）公共云详细介绍》里提到过的关键特性：

• ZFS —— 企业级的写时复制（copy-on-write）文件系统，可提供诸如constant time snapshots，writable clones，built-in compression，checksumming，volume management 等众多功能。
• DTrace: 用来在生产和试验性生产系统上找出系统瓶颈的工具，可以以对核心（kernel）和应用程序（user application）进行动态跟踪并且对系统运行不构成任何危险。支持原位（in situ）的数据聚合，用户级评估测量等。
• 基于操作系统的虚拟化（Zones）：完整的安全的虚拟操作系统实例，提供给多租户硬件级的性能。
• 网络虚拟化（Crossbow）：虚拟NIC架构，方便对网络带宽管理和资源控制。这里有论文链接。
• KVM：Joyent技术专家已经将KVM移植到SmartOS中，支持硬件虚拟化，并加强了以上四项特性，具体可以参见此链接
  

接下来，主要讲这么几部分有关虚拟化内容，主要内容来源于此链接。对于需要详细了解虚拟化技术的技术人员来说，蒋清野老师的文章《虚拟化、云计算、开放源代码及其他》、弯曲评论的《从半空看虚拟化》VMWare发表的白皮书《Understanding Full Virtualization, Paravirtualization, and Hardware Assist》都是很好的参考资料。

• 虚拟化：SmartOS如何与众不同

• 未虚拟化的计算机
• 客户机-服务器环境中的虚拟化
• 主机虚拟化（Hosted Virtualization）
• 裸金属硬件虚拟化（Bare-Metal Hardware Virtualization）
• 半虚拟化（Paravirtualization）
• 操作系统虚拟化（Operating System Virtualization）

• Joyent SmartMachines 是基于 Solaris Zones

• KVM 和 Joyent 虚拟机

虚拟化：SmartOS如何与众不同

未虚拟化的计算机

这是一个基本的电脑结构示意图，比如我们一般用的台式机或者笔记本电脑。最下面一层显示了系统的硬件资源：CPU，内存，存储和网卡。

操作系统直接运行在硬件层之上，操作系统层又分为两个部分：

• 核心层（kernel）：在系统众多资源和程序（运行在用户级）之间管理这些系统资源和通信
• 用户层（userland）：运行用户应用程序和软件库的软件层

需要指出的是，尽管这个图显示所有的应用程序都是同样的“尺寸”，但是某些应用程序会比其他程序需要更多的资源，而且一个应用程序所使用资源也会根据运行情况而变化。操作系统会根据系统的资源情况来管理（调度）程序们的需求。

客户机-服务器环境中的虚拟化

数据中心通常是一个服务器上运行一个应用程序，主要是有以下原因：

• 专用应用程序的需求：很多应用程序被认证只能在某一特定版本的操作系统下，加一些特定的补丁版本才能运行。它们也许还需要一个专有的软件栈（某一版本和某一补丁等）或特定的配置。这需要此程序不能和其他程序共享系统环境。
• 应用程序冲突：原因类似，某些程序之间相互不兼容。
• 资源竞争：如果共享同一台机器的话，某些对资源利用率很高的应用程序会“排挤”其他应用程序。
• 安全性：隔离可以阻止因程序相互之间的妥协而产生对系统的攻击。
• 灾难恢复：某个应用程序的崩溃不会影响到其他程序的正常运行。
• 可维护性：你可以升级或重启系统，而不会影响到其他程序或系统。
• 业务需要：很多企业的IT项目都会包括某一专用的程序。因预算和管理等缘故，每个项目都需要有它们自己的服务器和应用程序。

这种一个程序一个服务器的模式在20世纪80年代到90年代都运行得不错，特别是当某个程序对服务器的资源利用率很高的时候。但是，莫尔定律意味着更多的高性能服务器很快就会利用率很低，一般来说在8%到15%之间。显然，这是对设备，设施、电力和IT管理资源等低效率的使用。虚拟化正是为此而来的解决方案。

主机虚拟化（Hosted Virtualization）

在主机虚拟化模式中，hypervisor（管理程序）运行在操作系统层之上，用于仿真模拟（emulate）真正的硬件资源，来创建和管理一或多个虚拟机。
（其实，硬件虚拟化可以分为：全虚拟化和基于主机的虚拟化。全虚拟化不需要修改主机操作系统。它依赖于二进制翻译来陷入和虚拟化一些敏感、不可虚拟化的指令的执行。客户操作系统和它们的应用由非临界和临界指令构成。在基于主机的系统中，主机操作系统和客户操作系统同时存在，虚拟化软件层处于两者之间。）

因为hypervisor在宿主OS（Host OS）之上，而hypervisor之上是客户OS（Guest OS），所以这种叫做“主机虚拟化（hosted virtualization）”。（注：注意英文单词便能理解，中文的翻译不太准确）这种也被认为是“应用程序级虚拟化（application-level virtualization）”，因为hypervisor在Host OS上运行应用程序。

主机虚拟化用来整合服务器资源，使得多台服务器能在一台物理机上实现，并能保持相互的独立性（isolation）。任何运行在虚拟机上的Guest OS会认为它自己就是运行在独立的，真的计算机，但实际上它是在访问一组有限的硬件资源（由系统管理员设定）。

操作系统也会被认为是个管家（“supervisor”），所以我们用术语“hypervisor”来表示管理这些管家的管理人。Hypervisor 在运行时（runtime）通过“二进制翻译”（binary translation）来修改操作系统，操作系统调用硬件时就被陷入（intercepted / “trapped”）或重定向（redirected）。由于引入了非常耗时的二进制翻译，主机虚拟化的性能可能并不理想。特别对I/O密集型应用更是一个大的挑战。二进制翻译通过利用代码缓存存储已经翻译过的热指令来改进性能，但却增加了内存的消耗。

主机虚拟化引入了一些其他基础设施管理的优点：

• 负载均衡（Load balancing）
• 备份，迁移，克隆（Backups, migration, cloning）
• 灾难恢复（Disaster recovery）

这种虚拟化方式提高了资源利用率，但是还是有很大的不足：

• 为了能在物理硬件上工作，一个应用程序需要穿过两个操作系统和两套硬件
• 其中一套硬件是“被模拟的硬件”：软件程序表现得像硬件，实际却大大慢过真正的硬件。

裸金属硬件虚拟化（Bare-Metal Hardware Virtualization）

裸金属虚拟化解决了一部分 hypervisor 和 Host OS 带来的问题。Host OS 被剥离，剩下VMM（Virtual Machine Monitor）来运行hypervisor。为了此目的，VMM经过优化，hypervisor嵌入其中（最开始说到的操作系统中的userland级也被剥离，只剩虚拟化厂商的一些工具软件）。当然裸金属虚拟化也有缺点：

• 仍然使用的是硬件仿真（hardware emulation），即性能还是比较低。
• hypervisor也许有它自己的硬件驱动，你不能确定这些是否和标准的操作系统一样容易获得。

半虚拟化（Paravirtualization）

半虚拟化类似于裸金属虚拟化，但它移除了虚拟机硬件仿真（对比上面两图即能发现区别）

hypervisor直接与“特权Guest OS”（privileged guest OS）沟通，来访问下层的硬件。hypervisor管理操作系统们就像操作系统管理应用程序们那样：允许一个操作系统访问下层的硬件资源，同时阻止其他操作系统在同一时间访问同一资源。但是，为了达到此目的，操作系统必须经过修改以让它运行在一个“为操作系统们服务的操作系统”（OS for OSes）上面。这种情形的硬件虚拟化，操作系统是被“愚弄”（在runtime经过binary translation）以以致于它认为它是直接运行在硬件之上，就象最初设计操作系统时那样。

特权Guest OS与硬件资源（驱动）沟通访问：

• 硬件驱动驻留在privileged guest OS中
• privileged guest OS直接访问硬件驱动，而Guest OS通过privileged guest OS来访问硬件驱动。Guest OS是使用共享内存（即内存可被两个不同的应用程序访问）来做到，从而可提高性能。

好处在于：

• 非常高效——没有Host OS，没有硬件仿真（即没有 runtime binary translation of OS calls）
• 类似主机虚拟化和裸金属虚拟化，可用privileged guest OS上安装的任何设备驱动，hypervisor不包括任何设备驱动。

缺点在于：

• 需要修改Guest OS，让它意识到是运行在一个半虚拟化的环境中。
• 如果能访问源代码，这些修改是在kernel核心层，或者在操作系统上安装系统工具。

此外，随着2006年发布了支持虚拟化的CPU（Intel VT 和 AMD-V），相比其他形式的虚拟化技术，半虚拟化技术失去了它的一些优势：

• 支持虚拟化的CPU去掉了一些虚拟机必须执行的二进制翻译工作。更多的指令是直接在硬件上运行，而不需要仿真。
• 硅晶片快过硬件，所以将某些虚拟化功能搬到芯片上可以获得更好的性能。

操作系统虚拟化（Operating System Virtualization）

解决虚拟化最高效的方式是在操作系统层。好处在于：

• 非常高效——没有资源的重复。
• 一个服务器上只有一份核心层（所有其他形式的虚拟化技术，包括半虚拟化，需要每个应用程序经过多个操作系统的核心层才能运行）
• 每个区域（zone）拥有自己的用户层/userland（包括文件系统，系统类库，网络配置，单个应用程序的进程表），和自己许可的用户人数。
• 没有硬件仿真
• 利用操作系统的调度器（OS scheduler）：应用程序可以在需要时进行“爆发（burst）”，使用更多的系统资源，如同应用程序在单个（而非多个）操作系统上使用那样。应用程序并没有被虚拟机的设定给简单地限制住（即使使用半虚拟化，操作系统们也会被指派一定数量的资源，无法做到爆发，超过其指定数量）。
• 补丁和升级程序自动传播到所有的容器中，不需要管理和升级每个不同操作系统。

不足之处在于：

• 所有的操作系统环境是统一的，你无法在不同的操作系统上安装不同版本的补丁程序。不过，对于web应用程序，这并不是一个问题，因为Apache，MySQL和PHP都可以运行在Windows，Linux和SmartOS上。

Joyent SmartMachines 是基于 Solaris Zones

它们带给我们：

• CPU 资源调度
• 网络虚拟化
• 安全

Zones virtualization 是在2005年加入到Solaris 10系统中。

其实，SmartOS的虚拟化技术也就是蒋清野老师的文章《虚拟化、云计算、开放源代码及其他》中提到的“软件层面的虚拟化”——往往是指在同一个操作系统实例的基础上提供多个隔离的虚拟运行环境，也常常被称为容器技术。他在下面这段文字清晰叙述了基于软件层面/容器技术的虚拟化技术的优点。

蒋老师说到："硬件虚拟化也往往被称为重量级虚拟化，在同一宿主机上能够同时运行的虚拟机数量是相当有限的。在软件虚拟化的层面，同一宿主机上的所有虚拟机共享同一个操作系统实例，不存在由于运行多个操作系统实例所造成的性能损耗。因此，软件虚拟化也往往被称为轻量级虚拟化，在同一宿主机上能够同时运行的虚拟运行环境数量是比较宽松的。以Solaris操作系统上的Container为例，一个Solaris操作系统的实例理论上可以支持多达8000个Container（实际能够运行的Container数量取决于系统资源和负载）。与此类似，Linux操作系统上的LXC可以轻松地在同一宿主机上同时支持数量可观的虚拟运行环境。”

他还说到：“在虚拟化这个领域，国内的公司对硬件虚拟化的兴趣较大，在研发和生产环境中也大都采用硬件虚拟化技术。…… 至于在一个实际的应用场景中到底应该选择硬件虚拟化还是软件虚拟化，则应该重点考虑最终用户是否需要对操作系统的完全控制权（例如升级内核版本）。如果最终用户仅仅需要对运行环境的控制权（例如PaaS层面的各种App Engine服务），软件虚拟化可能性价比更高。对于为同一应用提供横向扩展能力的应用场景，软件虚拟化也是比较好的选择。”

KVM 和 Joyent 虚拟机（KVM and Joyent Virtual Machines）

操作系统虚拟化可很好的满足支持SmarOS的应用程序的运行。但是我们很多现有的程序只能运行在Windows或Linux之上，比如针对Windows，Active Directory，Windows的视频解码等。那我们该如何处理它们呢？基于Joyent技术的风起亚洲（Fengqi.Asia）公共云使用了主机虚拟化来提供解决方案。

如果你还记得的话，你应该知道如果没有了Host OS，那么你将失去它提供的任何有价值的功能特性。VMware的解决方案是将这些放到了设备驱动中，所以驱动程序可以将这些功能嵌入到hypervisor，bare-metal 硬件虚拟化，丰富其内涵。

上图的QEMU （有些人称为“Quick Emulator”）提供了硬件仿真，它是一个VMM（virtual machine monitor，虚拟机监控程序）。它并不是一个严格意义上的hypervisor层。每个QEMU是独立的——每个Guest OS有一个QEMU对应，而不是一个QEMU支撑多个VM。因为这里它将VM和VMM结合到了一起。

KVM（Kernel Virtual Machine）利用CPU虚拟化扩展技术提高系统性能，没有大量二进制翻译（硬件仿真）。QEMU也可以脱离KVM运行，但需要做二进制翻译，所以性能会比加上KVM要来的低。

至于有人在质疑移植KVM到SmartOS中是否会影响许可证的相关冲突问题。我想这下面一段话，也许能解答你的疑问。（原始链接：http://lwn.net/Articles/459754/）

The license

Of course some questions arose about thelicense: Joyent has copied the GPL-ed KVM code from Linux, while theillumos kernel uses the CDDL (Common Development and DistributionLicense). However, according to Cantrill this doesn't pose any problems. Onhis blog he answersa question from a reader about the issue:

OurKVM port remains GPL and its own work (and lives in its own repo) - theillumos kernel is CDDL but is in no way a derived work of our KVMport.

And on Hacker News he clarifies that theirKVM port doesn't use the hooks that Linux KVM has into the Linux kernel(which are marked as EXPORT_SYMBOL_GPL in the Linux kernel):"Actually, our port does not use these hooks –there were zero mods to the illumos kernel to support KVM per se."So, although there seem to be some questions about the legality of theKVM module in illumos, the developers are fairly confident that theproblems don't apply because the illumos kernel (CDDL-licensed) is not aderived work of the illumos KVM module (GPL-licensed).

介绍完SmartOS及其软件层面的虚拟化技术，我们再回到公共云平台上来。
其实基于Joyent的风起亚洲（Fengqi.Asia）公共云支持的操作系统不只是SmartOS，其支持的OS列表有：

CentOS ，Debian FreeBSD，Joyent SmartOS，openSUSE，Red Hat ，EnterpriseSolaris，
Ubuntu，Windows Server Enterprise ，Windows Server HPC ，Windows Server Standard 等

支持的硬件有：

Arista ，Cisco ，Dell ，Force10，HP， IBM， Intel ，Juniper ，Oracle 等

支持的语言有：

C / C++ ，Erlang ，Haskell ，Java ，JavaScript ，Lua ，Node.js ，PHP ，Python ，Ruby 等

支持的Web服务器/容器：

Abyss，Apache ，HTTP， Tomcat ，GlassFish，IIS ，JBoss ，
Jigsaw ，Klone ，Lighttpd ，Mongrel ，nginx ，WebLogic ，WebSphere 等

支持的数据库：

Cassandra ，CouchDB ，Hadoop ，HBase ，Hypertable ，
MongoDB ，MySQL ，Oracle ，Percona ，PostgreSQL ，Riak 等
（附上Riak在 Joyent 平台上的性能测试报告，http://joyent.com/blog/riak-smartmachine-benchmark-the-technical-details）

结束：SmartOS资料汇总及相关链接

由于SmartOS包含的资料很多，除了SmartOS Wiki 或使用Google等搜索引擎外，我们再介绍几个渠道来学习。

1. SmartOS 搜索引擎

SmartOS给出了一个Google自定义搜索引擎（http://smartos.org/search/），可以搜索以下域名下的所有信息：

• dtrace.org
• github.com/illumos
• github.com/joyent
• help.joyent.com (Joyent docs & support)
• http://illumos.org/man man pages
• illumos.org
• illumos.org/books (man pages and other technical docs)
• illumos.org/issues (illumos bugs)
• joyent.com
• nodejs.org
• perkin.org.uk
• smartos.org
• wiki.illumos.org illumos wiki
• wiki.joyent.com (Joyent docs & support)
• wiki.smartos.org 
• zfsday.com

2. SmartOS 相关视频及PPT

Deirdré Straughan 是 SmartOS 的 Community Architect，LinkedIn链接是：http://www.linkedin.com/in/deirdrestraughan

她的博客链接里列出了几乎所有的SmartOS及相关组件/技术的培训视频：http://www.beginningwithi.com/2013/01/22/whole-lotta-videos/

总共有531个视频，有的很久了，都是youtube的视频，有兴趣的就供参考吧。（作者原话：This is not all the videos I’ve made to date (for both work and fun), but … it’s 531 of them, some as old as 10 years (recovered from various sources).）

附送一个Bryan Cantrill （VP）做的有关 SmartOS 的 PPT ： http://wiki.smartos.org/download/attachments/753667/smartos-modernOS.pdf

3. SmartOS 沟通渠道

Email：

最好的沟通方式便是订阅SmartOS社区的邮件列表：SmartOS Mailing List  目前就一个，从用户帮助到开发等都有，提供了很多信息。

如果想要更多信息，Illumos 提供了大量的 mailing lists 。

IRC：

所有的IRC沟通都通过 Freenode 有如下几个频道：

• #smartos – 只谈 SmartOS.
  
• #joyent – 你能看到很多有关 SmartOS 的交流，也有Joyent 的公有/私有云讨论。技术范儿的适合在这里闲逛。
• #illumos – SmartOS 是基于 Illumos (much like Debian is a Linux-based distribution) 的发行版。这里可以获得很多有关Illumos的帮助。

Twitter：

• 搜索 SmartOS ，便能获得许多相关信息
• @DeirdreS  @ki4otk

开发 / Bug & Issue Tracking / Feature Requests：

• joyent/smartos-live 也许是 SmartOS 开发的集中地。Github bug tracker 是为SmartOS最好的提交bug和feature request 的地方。

4. illumos 相关书籍

Dynamic Tracing Guide

DTrace is a comprehensive dynamic tracing framework for the illumos Operating System. DTrace provides a powerful infrastructure to permit administrators, developers, and service personnel to concisely answer arbitrary questions about the behavior of the operating system and user programs. The illumos Dynamic Tracing Guide describes how to use DTrace to observe, debug, and tune system behavior. This book also includes a complete reference for bundled DTrace observability tools and the D programming language.

Modular Debugger Guide

The Modular Debugger (MDB) is a highly extensible, general purpose debugging tool for the illumos Operating System. The Modular Debugger Guide describes how to use MDB to debug complex software systems, with a particular emphasis on the facilities available for debugging the illumos kernel and associated device drivers and modules. It also includes a complete reference for and discussion of the MDB language syntax, debugger features, and MDB Module Programming API.
Writing Device Drivers

Writing Device Drivers

Writing Device Drivers provides information on developing drivers for character-oriented devices, block-oriented devices, network devices, SCSI target and HBA devices, and USB devices for the illumos Operating System (illumos). This book discusses how to develop multithreaded reentrant device drivers for all architectures that conform to the illumos DDI/DKI (Device Driver Interface, Driver-Kernel Interface). A common driver programming approach is described that enables drivers to be written without concern for platform-specific issues such as endianness and data ordering.

Additional topics include hardening illumos drivers; power management; driver autoconfiguration; programmed I/O; Direct Memory Access (DMA); device context management; compilation, installation, and testing drivers; debugging drivers; and porting illumos drivers to a 64-bit environment.
Memory and Thread Placement Optimization Developer's Guide

The Memory and Thread Placement Optimization Developer's Guide

The Memory and Thread Placement Optimization Developer's Guide provides information on locality groups and the technologies that are available to optimize the use of computing resources in the illumos operating system.

最后，如果有任何问题，欢迎与我联系：michaelcxw(AT)gmail.com