Adrian Cole 发布 JClouds 1.0

近日， JClouds 1.0 发布了，其创建者 Adrian Cole 说到，JClouds 的目标旨在提供一个公共接口以管理众多厂商、提供商、框架及 API（从 IaaS 到 PaaS ）中的计算机节点和存储节点。

JClouds 支持全世界 30 个不同的提供商。开发者与运维人员可以通过下游工具如 Apache Whirr （运行云服务，如 Hadoop、HBase、elasticsearch 及 Voldemort 等）或 Pallet （用于提供、配置及管理云计算资源的库）来使用 JClouds，也可以直接通过 API 和 Ant task 将其当作库来使用。

InfoQ 有幸采访到了 JClouds 的创建者及云互操作和运维领域的社区领导者 Adrian Cole 一探究竟。

InfoQ：JClouds 1.0 增加了哪些主要特性？

JClouds 1.0.0 增加了不少新特性，恕我无法一一列举，但我要重点介绍以下内容： 在可用性方面，David Santiago 与 Mattias Holmqvist 完全重写了 BlobStore 与 Compute Clojure API 以更加适合于语言。Tim Peierls 则修订了 BlobStore 的 Java API 以增强其直观度。

由于 JClouds 可以嵌入到管理与应用平台当中，因此模块化就变得愈发重要了。幸好，Gustavo Morozowski 与 Ioannis Canellos 付出了巨大的努力来包装 OSGi bundle 和 Karaf 集成：OSGi 支持是我们最早的问题之一！

我们还为超级用户提供了大量的特性。比如说，Tibor Kiss 将 BlobStore 提升到了 Petabyte 级别，并在 NGS 平台中测试和打磨产品的内部构件。

Jeremy Whitlock 领导了 ProviderMetadata 首个版本的开发工作，你可以使用它查询可用的云及详细信息，如控制台 URL、友好的名字等等。Cloudsoft 就通过这类详细信息执行范围内的部署规则，美国之外的用户也很喜欢这一点。

对于安全，我们提供了一个很棒的名为 AdminAccess 的工具，它会锁住节点并为你创建一个个性化用户，只需一步即可搞定。

对于很多人来说，重要的是我们所提供的连续带宽支持： Grid Dynamics 与 GigaSpaces 为流行的 OpenStack Nova 平台提供了支持，我们还增加了不少新的云服务，有澳大利亚的 Ninefold（XEN 与 VMWare 托管）和英国的 Stratogen（VMWare 托管）。

InfoQ：在去年 12 月 23 日 InfoQ 的采访中，你提到 JClouds 可能会与 libvirt 合作，这样用户就可以使用 JClouds 进行可视化控制了？这件事有什么进展么？

没太多进展。从某种程度上来说，我们依赖于云控制者，比如 OpenStack Nova 和 vCloud。另一个选择就是我们最近与 Twitter 协作开发的 byon（Bring your own node）。你可以通过 BYON 使用 yaml 语法赋予 JClouds 一个文件或是 Web URL，其中包含有机器的详细信息。这是对我们尚不支持的平台的一个很好的解决方案。

InfoQ：JClouds 支持哪些 Cloud API 呢（vCloud、Amazon EC2 抑或其他）？

JClouds 支持 EMC Atmos 、 OpenStack Swift 、 Eucalyptus Walrus（S3 clone）的存储设施、Amazon S3 的衍生，甚至是磁盘上的文件。对于计算机一边，我们支持 vCloud（由 VMWare 创建）、 ElasticStack、Eucalyptus（开源的 Amazon EC2 clone）、 Deltacloud（与 JClouds 有些重叠）、Amazon EC2 的众多衍生以及 byon 格式。

Cole 继续介绍 JClouds 的特性路线图。最近人们对于 PaaS 抽象的呼声越来越高，因此对其的支持也在路线图中体现了出来。对于 JClouds 来说，专注于 PaaS 还是最近才兴起的，之前主要专注于 IaaS 抽象。对 PaaS 的支持主要包括与 Google App Engine 和 CloudBees Run@Cloud 的合作。

另一个专注领域就是限流与伸缩了。现在有些提供商的节点数超过 100 就会出现一些问题。JClouds 正致力于实现一些附加的内建策略，这样你就可以请求更大的资源池了。

Cole 说他们正致力于负载平衡与虚拟化支持，不久之后就可与大家见面了。虚拟化支持包括可选择的启动源、ISO 挂载、 PXE 、构建自己的镜像以及从其他机器克隆镜像等。虚拟化支持将会支持私有云。

InfoQ：JClouds 与 Jets3t、typica、Deltacloud 及 Dasein 相比如何呢？能否谈谈质量、性能、范围以及成熟度等方面呢？

JClouds 与其他产品之间最根本的差别在于我们在元数据的等值问题上花费了大量的时间。这是非常有帮助的，因为你可以直接公开需求了，比如说我在爱尔兰需要一台 Ubuntu 10.04 服务器。这种事情是很难处理的，但我们会不遗余力地做到更好。 来自 Jets3t（Amazon S3 focused API）的 James（Murty）开发了一套很可靠的库，与来自 Typica 的 David 一样（Amazon EC2 及其他的 Amazon services focused API 能够处理如 Eucalyptus 这样的克隆）。他们在 JClouds 的开发过程中分享了其经验，尤其是 James，他是一名敬业的开发者，数月以来都在孜孜不倦地努力工作。jets3t 与 typica 都是成熟的库，他们都比 JClouds 年长。也就是说，他们并没有关注于便携性，因此你没法将其与 JClouds 互换。一般而言，我们在追赶 Amazon 特性的同时，jets3t 与 typica 已经完成了这一切。在与 jets3t 进行性能比较时，我们的性能会更好。当然了，测试是我们自己编写的，呵呵。

Dasein 与 JClouds 非常接近。他们差不多是同时开始的，事实上，它使用了 JClouds 组件实现了相当一部分云提供者。也就是说，Dasein 有几个提供者是 JClouds 所不支持的，反之亦然。Dasein 关注于单服务器操作，而 JClouds 则关注于机器群的引导。Dasein 最酷的地方在于它公开了大量的规则，如防火墙规则等，而我们目前尚未做到这一点（Adrian Cole 也是一名 Dasein 提交者）。

Cole 又说到 Deltacloud 拥有非常“漂亮的 REST API”。Deltacloud 关注于 API 的便携性，而 JClouds 则关注于以便携的方式执行用例的方式。Deltacloud 能够探测到定制机器的各种方式。你可以通过 JClouds 提供启动脚本，其他的细节问题都由 JClouds 帮你处理好了。因此 JClouds 能与 Deltacloud 集成也就没什么奇怪的了。

InfoQ：JClouds 支持 Eucalyptus 么？ 你对 Eucalyptus 有何评价？

是的，JClouds 支持 Eucalyptus。我对 Eucalyptus 的评价是积极的。他们具有我们所说的兼容性问题，并且正致力于解决这些问题。

Eucalyptus 是个流行的开源 Amazon EC2、S3，它用于私有云计算。

InfoQ：如果我开始自己的私有云，那么 JClouds 将会支持哪个呢？现在是什么，将来又是什么呢？

如果你指的是 on-prem 计算云，那么你可以使用 Eucalyptus、OpenStack 或是 vCloud 1.0。简而言之，我们还将支持 cloud.com CloudStack 2.2.8，它是非常成熟且健壮的产品，基于商业与 GPL 许可。到今年底，我们将会支持 vCloud 1.5，甚至还有可能支持 OpenShift Power。现在还有其他一些云控制者，如 OpenNebula 和 Abiquo，如果需要我们也将提供对其的支持。

InfoQ：在过去的 3 个月中，JClouds 取得了哪些不俗的成绩（开发、架构增强等）？

在过去 3 个月中，OSGi 取得了积极的进展。能够在离线的情况下连接到云资源，或是在应用运行时对其进行升级是我们重点考虑的问题。类似于典型的数据中心运维，云也可以步入维护阶段，这样你可能需要进行动态调整。OSGi 与其他的模块化系统是解决这个问题的关键所在，我们向 OSGi 迈进的第一步对于我们和我们的用户来说都是至关重要的。 另一个重大进展是 Tibor Kiss 对数据传输的优化。我们已经实现了 EC2 集群节点与 S3 之间超过 300MB/s 的写速率，这使得云中 Petabyte 级别的传输成为可能。Andrew Phillips 还实现了 TweetStore 示例，它会在 Google App Engine 中将 twitter 更新传输到 BlobStores（这要归功于 twitter4j）。他又对此更进一步，现在可以同时部署到 CloudBees Run@Cloud PaaS 上。我们现在准备将 IaaS 与 PaaS 整合起来，希望能向其他人提供一些有用的工具。

InfoQ：如果有人使用 Google App Engine 而不是 EC2、Rackspace、Azure 或是内部私有云，那么你对此有何看法呢？

现在 PaaS 有多种选择，因此无论选择 GAE、Azure 还是其他都是有原因的。 PaaS 或是 IaaS 是个费用、服务层或是与需求一致性的决定。如果现有的 PaaS 能够满足你的需求，那么用就好了。你需要为此付出费用。如果你寻找托管的 PaaS，那么请关注数据层。你需要清楚如何导入 / 导出工作、规则、历史以及维护窗口。

我对自己运行 PaaS 总是非常小心。他们通常是由很多层构成的，比如 Rabbit MQ、CouchDB、Nginx、 Nagios 等。如果你想使用自己的 PaaS，那么你应该搞清楚其依赖来确保你可以对其提供支持，或是知道从哪里获得支持。此外，请对单服务器的快速起步 PaaS 或是 IaaS 示例持怀疑态度。在现实情况下，多服务器的部署通常都是困难的，涉及到手工或是文档中并未写明的过程。这些问题使得托管服务更具吸引力。

如果你需要一次性加载上百个节点，那么你需要使用 EC2。我发现 Rackspace 在小范围情况下的表现与其他提供者一样。我认为在哪个公共云提供者上进行部署的决定主要在于业务价值上。比如说，从性能上考虑你想选择哪一个。他们是否部署在云 X 上，如果是，那么在哪个地区呢？哪个云能够满足你想使用的区域呢？哪些技术伙伴具有云 X 的经验？On-prem 是个有效的决定，如果你在基础设施上有经验，那么它就极具价值了。今年还有不少产品会有助于 on-prem 云的实现。

InfoQ：哪一个 IaaS 提供者最易于上手（集成）？哪一个 Bug 最多？

最易于上手的提供者是那些运行着 ElasticStack 的提供者。他们几乎不会出现问题，在各个提供者之间能够保持一致性，从编程的角度来看也是非常简单的。 要说哪个 Bug 最多还真不好轻易下结论。我这里不会指名道姓。我想说的是，那些编写自己的云控制器，并且过去没有编写过具有核心竞争力的产品的公司更容易出问题。

InfoQ：能否谈谈 Amazon BeanStalk？你打算围绕着 Amazon 抽取出更多的 API 么，比如 Amazon Simple Notification Service、Elastic Load Balancing 和 Auto-Scaling 等。

BeanStalk 很有趣儿，当 Amazon 启动或停止时会产生严重的影响。我觉得这对于那些与 BeanStalk 竞争的 ISV 是个警告信号。也就是说它是个非常简单的服务，无需配置管理，因此它真正造成的影响很有限。对于其他的 AWS 服务来说，我们已经在 JClouds 提供了 Elastic Load Balancing 支持（比如 OpenShift Flex）。其他的 API 就有待更多的人来验证了，我们尚未对其提供支持。

JClouds 1.0 的发布令人印象深刻，同时 JClouds 的特性在不断发展当中，其目标也日趋明朗。

查看英文原文： Adrian Cole Announces JClouds 1.0 Release