Illumos:OpenSolaris社区的继承者

翻译：曾怀东/朱翊然

在2010年8月，存储供应商 Nexenta Systems宣布了一项免费的OpenSolaris发行项目：illumos。Illmuos的最终目标包括两个方面：一是使用开源代码取代所有仍在OpenSolaris使用的专有代码，二是围绕之前的OpenSolaris代码库建立一个独立的社区。现在已经过去了将近10个月，Nexenta Systems于5月20日在Amsterdam召开了Nexenta European User Conference并展示了Illumos的计划和Nexenta的产品。现在正是关注Illumos进展情况的好时机。

源代码

Illumos的代码库正在形成或将要形成一组发行项目，包括来自Nexenta的存储应用，来自Joyent的云计算平台以及通用的OpenIndiana（这是OpenSolaris发行精神的继承者）。他最初的目标之一是用开源的组件取代OpenSolaris代码库中仅存的部分二进制代码组件。现在，Illumos仍然保留着部分二进制代码的组件，例如NFS lock manager，IKE deamon（Internet Key Exchange， IPsec的一部分），一些支持的库，以及一些驱动，但是据Garrett D’Amors（Nexenta系统的开发主管）所说，Illumos的开发者正在致力于解决这些问题。而且，去年编译Illumos仍依赖于Sun Sutdio编译器，Illumos现在使用GCC构建（build），尽管这还需要更多的测试。

Illumos已经从一些硬件厂商（Areca，4Front）那里获得了贡献的代码。根据D'Amore所说，还有来自于主机总线适配器和网卡供应商贡献的一些代码正在等待合并。而且，Intel和LSI成为了Nexenta的技术合作伙伴以及主要的赞助商，这意味着Nexenta获得了这些公司的规范和工程方面的支持。D'Amore还说到，很快会得到这两家厂商的代码贡献。值得注意的是与Illumos/Nexenta关系并不很好的AMD和Nvidia的缺席。但是，在D'Amore自己博客的评论中，他解释到：这些合作关系或是非合作关系不会一成不变：“我很高兴和其他厂商维持良好的关系，无论是NVDIA或是AMD。只是在此刻，这三家公司中只有Intel向illumos或Nexenta伸出了橄榄枝。”

成长的烦恼

目前，有一些针对Illumos运作方式的批评。因为对“思维狭隘，ZFS中心独裁以及大教堂式的开发模式”不满，Stamos Tolias已经开始呼吁创建分支。显然他开始筹措资金并准备在11月份将自己的分支项目公开。项目的领导来自于Athens大学，经费支持来自于某欧洲研究基金，并拥有EADS作为合作伙伴。Totlias并没有回应本小编的问题进行澄清。

Tolias批评Illumos的部分矛头直接指向D'Amore，后者在自己的博客上进行了申辩：

D'Amore进一步解释到，Illumos没有处于Nexenta的绝对控制之下：

D'Amore正在与Software Freedom Law Center合作，准备为Illumos创立一个法律实体，让这个法律实体成为一个独立的组织完全独立于Nexenta。所以，目前在某种程度上，Illumos的发展确实不够开放和独立，但是Nexenta一直在努力为一个真正的属于社区的Illumos进行着铺垫。

Nexenta

Nexenta建立在Illumos的基础之上，造成了两面性的影响：一方面是一个开源的GNU/Solaris操作系统（2009年是版本2），Nexenta Core Platform (NCP)，另一方面是一个商业存储解决方案，NexentaStor。后者是基于ZFS的存储解决方案，通常是由系统集成商和增值经销商（VARs）购买作为带有认证的硬件的整体解决方案的一部分，认证的硬件大多数来自于LSI，Quanta，Dell，Supermicro, 和 Intel这些厂商。

Nexenta的关键卖点是他自己声称的“"Open Storage”：因为NexentaStor使用者能够简单迁移到其他操作系统支持（同一版本或是新版本）的ZFS上，例如Solaris, FreeBSD 等等，他们可以不用担心厂商对他们数据的 Lock-in。相比之下，大存储厂商使用专有的磁盘格式，它们的解决方案紧密结合自己的硬件。使用Nexenta，用户甚至可以自己选择需要购买的硬件。

之前Nexenta的用户空间部分（除了kernel外）是基于Ubuntu的，但Nexenta 4（计划在2011年底发行）将基于Debian 6("Squeeze")。Nexenta工程师们做这个决定的原因是：Debian更容易移植，而Ubuntu有太多使用特定Linux特性的补丁这造成将用户空间部分移植到Illumos核心更困难。Nexenta 3仍会基于OpenSolaris内核，Nexenta 4将成为第一个基于Illumos的Nexenta产品。因此，既有OpenSolaris内核到Illumos内核的切换，也有从Ubuntu用户空间到Debian用户空间的变化，Nexenta 4 的确是一个很大的变化。

但是，现在仍然有很多的“FUD”在ZFS和合作者之间蔓延。去年，存储厂商NetApp向他的竞争者Coraid发送了一封威胁的信件，结果Coraid决定停止代售其ZFS存储设备（基于NexentaStor的）。在甲骨文和NetApp之间也有诉讼，该诉讼不得不处理NetApp对ZFS违反专利权以及NetApp使用来自于Sun公司的具体技术的权利的申诉。甲骨文和NetApp解决了他们的纠纷，但是他们和解协议的细节并没有公开。

Nexenta 以及其他在自己操作系统中使用ZFS的公司肯定不用担心和甲骨文公司的官司：ZFS代码的CDDL授权允许其使用任何甲骨文可能拥有专利的代码。但是NetAPP或者其他组织仍然能够因为ZFS代码对他们专利权的侵犯控告Nexenta，尽管从今年开始Nextenta成为了Open Invention Network (OIN)的一部分。在Nexenta的欧洲用户大会主题演讲上，首席执行官Evan Powell明确表示他认为这个成员身份是为了应对潜在的NetApp专利侵权诉讼：“如果NetApp要起诉我们，我们可以通过由OIN共享的Novell的UNIX专利起诉他们。”

StormOS

2011年1月，Nexenta还聘请了Andrew Stormont，他是StormOS——一个基于Xfce桌面系统的Nexenta核心平台衍生品——的开发者。这个桌面操作系统面向那些喜欢类似于Nexenta提供的ZFS/apt combo服务，但是不想安装桌面包的人群（因为Nexenta并非针对于桌面型用户）。目前，Stormont作为一个软件工程师，主要在为即将上线的Nexenta 4打包软件，但他最近也提交了Illumos补丁。

作为他在Nexenta Systems工作的一部分，Stormont一周中有一天是在做StormOS的工作，而且他在Nexenta大部分的工作，StormOS最终也能从中受益。但是从StormOS项目启动开始，它始终更像一部独角戏。StormOS的下一个版本——StormOS Flash——将基于NCP4以及一些来源于Debian 7的一些组件（比如X.Org和Xfce的更新包）。其中一项新的特性将是一个在文件管理器中整合ZFS快照的Xfce图形界面，类似于OpenSolaris中GNOME的时间滑块功能。

Stormont正在考虑的一个更具实验意义的特征是FatELF：在单独的二进制文件上支持32位和64位架构。Illumos内核已经具备在32或者64位的硬件模式下自动启动的能力，所以内核中的二进制文件就能够自动的运行于正确的模式。

在一次接受电子邮件采访中，Stormont解释了FatELF可以给StormOS带来哪些好处:

其他公司

Nexenta不是唯一支持Illumos的公司。Joyent是另外一个大的贡献者，它聘请了像Bryan Cantrill 和 Brendan Gregg那样的Solaris核心人员。Joyent已经发布一个存有他们的一些补丁的git仓库到Illumos树上。John Sonnenschein在他的的树公告中写道：

一些补丁是Joyent特有的，但另外一些的用途更普遍些。大部分的补丁为区域功能的增强（操作系统级别的虚拟化），以及DTrace（Solaris动态追踪框架）的改进位在云中提供更好的分析。许多这样的改变可能会在不久的将来找到它们的用武之地，虽然现在有实际的问题：Illumos 使用Mercurial 而Joyent使用Git。

另外一个代码贡献者是数据库公司 Delphix,该公司雇用Adam Leventhal，他曾经从事于RAID-Z工作(一种冗余模式，类似于RAID 5，使用ZFS)，也是DTrace的共同发明人。Delphix似乎更愿意保持其参与的安静性，因为它们还没有公布任何关于他们的贡献，但是粗略的看他们在Illumos仓库中的提交，表明他们肯定参与其中了。因此，虽然Nexenta Systems仍旧是主要的贡献者，但也有一些其他的公司已经参与其中。

Google Summer of Code

尽管发布还不到一年，Illumos 已经在Google Summer of Code (GSoC) 2011上作为指导组织者的身份出现。他们已经接受了两个 Illumos GSoC项目：Harshit Jain将更新Illumos，为了能引导GRUB 2，并支持用GUID分区表（GPT）从硬盘启动，该项目由D'Amore指导；而Shashank Karkare在Joyent's John Sonnenschein的管理下，将用C重写一些Perl系统组件(如intrd和kstat)。后者的目标是为Illumos消除Perl运行时的依赖。

此外，Nexenta还资助三名未进入GSoC的学生。例如，Andrey Sokolov将在没有区域（zone）的情况下做支持Illumos 上的linux二进制文件的工作（商标（branded）区域是在虚拟环境中在Solaris上运行linux二进制文件的一种方法），Bayard Bell将从事IKEv2守护进程的工作去代替IKE，Viktor Ikonnikov会位服务配置工具svccfg写一个GUI的前端。对于GSoC以及Illumos学生的未来版本，Illumos已经有了大量的项目设想的清单。

ZFS工作组

另一个在Illumos 保护伞下的令人关注的发展是ZFS工作组，虽然它有点低调。这个小组由Delphix 和 Garrett D'Amore的Adam Leventhal and Matthew Ahrens (他曾工作于Sun/Oracle 的ZFS)在几个月前成立的，Ahrens是该组的组长。小组的目标是通过协调工作和交换思想促进ZFS社区的合作。特别是，创办人担忧ZFS会分裂成各种不同的支持文件系统的操作系统的子社区。

ZFS工作小组包括来自Illumos/OpenIndiana, Mac OS X（最有可能Don Brady开发ZFS支持他的公司Ten's Complement），FreeBSD(或许是移植ZFS的Pawel Dawidek)，Linux, 和Solaris的开发人员. 按照D'Amore的说法, Oracle也在小组中占有一席之地。该工作组的活动不是公开的，部分成员不希望自己的成员身份公开，但是会定期的发表讨论的结果。

ZFS工作组的第一个结果是feature flags proposal。在公告中，Matthew Ahrens写道：

该工作组的第一个产品是ZFS 磁盘版本化方法的设计，在没有进一步明确的协同信息的情况下，此设计将允许分布式的开发ZFS磁盘格式变化。这种方法消除了两个开发人员都分配版本号31去表示他们自己功能的问题。这种“特征标签”版本化允许未知版本被识别，而且在许多情况下，即使在未知的磁盘特征的情况下，ZFS池或者文件系统可以是只读的。我的建议涵盖了SPA/zpool, ZPL/zfs, 发送流，以及分配压缩和校验标识符（枚举值）的版本化。

正如Ahrens所说，这个特征标签功能是必要的，因为与只有Oracle/Sun开发ZFS的时候相比，当前ZFS的开发正处于一种更分布式的方法。在ZFS v28之后，Oracle已经停止发布它的源代码，而Illumos，FreeBSD以及其他支持ZFS的操作系统不希望等到Oracle发布Solaris 11后的再一次代码公开，所以开发继续进行。因为特征标签，Oracle外的开发人员可以在不破坏互操作性的情况下添加新的压缩算法或者新的RAID变体：大多数情况下系统应该仍然能够在只读模式下访问ZFS池或者文件系统，如果它拥有未知特征。特征标签将在今年夏天应用，并且并入Illumos中。

结论

Illumos显然在向前发展，虽然这样做会让一部分人沮丧。Illumos的开发商大多数使用大教堂式的开发模式，而一些Illumos社区的vocal成员更喜欢完全开放的开发——就像linux正在使用的开发模型一样。对于fork和关于ZFS工作组封闭性质的批评是这些情绪的产生的后果。

然而，这些批评忘记了OpenSolaris的发展模式更加的封闭。虽然Sun发布了Solaris系统的大多数的代码，而且称OpenSolaris“开放源码”，实际并没有一个真正的OpenSolaris社区：它总是过于依赖Sun和后来的Oracle，这两家公司并没有努力去围绕他们“开放源码”的项目创建一个独立的社区。目前Oracle对于Solaris 11的开发模式是完全封闭的。

因此，虽然Illumos尚未完全开放Solaris代码库，并且还没有许多OpenSolaris的人梦寐以求的充满活力的社区，事情正在朝着正确的方向。它再也不是一个Nexenta独享的项目，它会有一个独立的Illumos基金会，而且这个项目已经吸引了一些大硬件厂商的支持。现在只是等待基于Illumos的Nexenta的发布和第一个稳定的基于Illumos的OpenIndiana的发布，让这个项目蓬勃发展起来，并重新获得那些在Oracle封闭的时候离开OpenSolaris社区的人的兴趣。