云计算

某门课程的Open Topic，我的话题是关于云计算的，读了一篇技术报告 Above the Clouds: A Berkeley View of Cloud Computing。

这是 UCB 的 RAD(Reliable Adaptive Distributed) 实验室花了六个月时间 brainstorm 总结出来的 paper，介绍了云计算的概念、现状及未来展望。以下内容主要来自于我上交的文档，做了一些修改，欢迎大家指正。

虽然现在对云计算这个概念的炒作大于实际研究，以至于很多人听到云计算这个名词就想到忽悠，但这里面还是很多东西需要好好考虑和设计的。云计算和以前的 cluster computing 等概念虽有相同之处，区别也有不少，它涉及了经济学、虚拟化技术、安全等诸多领域的内容。

何谓云计算？

云计算包含两方面内容，一是在网络上提供的为计算服务的应用，例如以前被称为 SaaS(Software as a Service) 的那一类应用；二是提供这些服务的在数据中心的硬件和系统软件，这部分也就是我们通常所称呼为「云」的东西。

云计算平台的优势

云计算带来了三个新颖的观点：

1. 提供了看起来没有上限的可用计算资源，用户不需要提前考虑设备的需求量；

2. 免去了云计算用户的前期投入，使得公司可以从一个规模较小的硬件资源起家，并根据自己的需要增加资源；

3. 细粒度的计费手段，例如按每小时使用处理器数或者每天使用的存储空间计算，并在暂时不需要机器和存储空间时即时减免费用。

云计算资源拥有很好的弹性，以 Amazon EC2 为例，用户可以在几分钟内完成硬件资源的添加或者减少操作，这在传统的应用程序部署中是很难做到的。文中提到了 Facebook 上的一个应用 Animoto，这个应用的资源需求在三天内从 50 台服务器上升到了 3500 台服务器。在传统的部署情景中，这样的需求是很难通过预先准备好硬件来满足的。另外还有一个问题，当资源需求下降时，传统方式部署的服务器资源就被闲置了，而通过云计算部署的资源则灵活很多，例如一个网站到了深夜访问量下降，此时就可以通过减少占用的计算资源从而降低支出。

现在的云计算平台提供了不同粒度的 API。Amazon EC2 是一个底层的极端，它提供了类似物理硬件的接口，用户可以几乎控制从内核开始的整个软件栈。通过虚拟技术提供的 CPU、块设备、IP 级别的连通技术使得开发人员几乎可以做任何事情。高度的灵活性带来的是可控性的损失，在自动伸缩性 (automatic scalability) 和容错转移 (failover) 方面，服务商就力不从心了。而 Google AppEngine 则提供了比较高层的 API，主要面向传统的 web 应用，在牺牲灵活性之后能很好的实现自动伸缩和转移，并对用户完全透明。而微软的 Azure 则介于这两者之间，提供了接近 CLR 字节码的接口，用户可以通过 .Net 的一系列语言和类库实现自己的应用程序。

不同的平台有不同的适用范围，不可能有一方压倒性的胜过另一方，这个问题就像 Ruby 和 C 语言孰优孰劣一样。

当前问题及解决方案

1. 服务的有效性

即如何保证服务总是可以访问，考虑到服务提供商可能倒闭等情况

文中提出的方法是不同的公司能提供独立的软件栈，以保证某一个服务无法使用后能及时切换到另一个。但这个实现似乎会有不少阻力，至少现在的云计算服务平台各自的 API 都还大相径庭，要在不同的平台间转移应用不怎么可行。

服务有效性的另一个问题是 DDoS 攻击，云计算的弹性机制可以很好的化解这个问题。作者算了一笔账，从黑市租借 50 万个攻击机器人攻击一个 EC2 的实例会使得受害者遭受额外的每小时 460 美刀的支出，但由于租借这些机器人需要 1.5 万美刀的资金，要使得受害者的损失大于攻击者的支出，这样的攻击需要持续 32 小时，对于攻击者来说得不偿失。

2. 数据被锁定

数据被锁在服务提供商的数据平台中，客户无法很简单的把数据从一个站点转移到另一个。这也是 Stallman 反对云计算的一个重要原因，客户可能因为数据锁在云计算平台中而不得不接收服务提供商的价格提升等要求。

文中提到的一个解决方案就是统一平台的 API，使得数据能在不同的服务提供商之间转移。我觉得这个方案也不现实，就像有了 GAppEngine 后，应该不会有另一家服务商提供类似的 Python 或者 Java 的 API 支持了吧？

不过也许可以有一个第三方的库把不同的服务商的 API 再做一层抽象，让应用程序来使用这些平台无关的 API，就像是 OpenCL/Streamware 之于 GPU。

3. 数据机密性

这个问题我想不算难点，可信计算已经是研究的热门之一了，而用户自己也可以将机密数据加密后再保存到云中。而虚拟机监控器层也能提供相应的保障，例如CHAOS 和 VMware 的 OverShadow 可以保护在不可信的操作系统中应用程序运行的安全性，这样即使攻击者能利用操作系统层的漏洞，也无法对操作系统上面的受保护的应用程序进行攻击。

4. 数据传输瓶颈

用户的数据要传输到云里面，消耗的时间和带宽都很高，怎么办呢？

一个简单和实用的方案就是直接通过快递公司邮递硬盘，几 TB 的数据不到一天就能传到数据中心了。

另一个手段是尽可能地把数据保留在云中。我觉得广义的来说这也是一种 locality 的优化吧，但是这样就又要考虑到前面提到的数据锁定的问题了。

此外，降低网络传输的费用也是一个研究方向，据估计三分之二的网络带宽费用都是用在高端的路由器上，而另外的三分之一才是用在传输介质中。如何减少路由器的耗费是一个需要深入研究的问题，另外如何更有效的设计云里面的网络的拓扑结构也值得探讨。

5. 性能的不稳定

我觉得相对其他问题，这个问题应该算是很难解决的了。由于客户使用的虚拟机往往和其他虚拟机共享了云中的硬件资源，在共用 I/O 设备的时候表现性能会有较大的起伏。

提高性能稳定性的最直接的途径自然是提高体系结构和操作系统虚拟中断及 I/O 通道时的效率了。另外文中还考虑了使用闪存来降低 I/O 干扰的可能，不过我认为闪存随机写的性能很差，代替硬盘后的性能未必会好，尤其在多个虚拟机同时访问的情况下，稳定性就很难说了。

另外，在调度虚拟机的时候，还要采用 Gang Schedule，即对于一些必须几个线程同时运行的程序，要保证这些虚拟机能被同时调度运行。

6. 文章还提到了另外 5 个障碍。

包括存储设备的可伸缩性，如何快速伸缩、大规模分布式系统中的bug问题，这可以通过开发相应的可伸缩存储系统、算法以及分布式调试器解决。另外还有声誉共享（一个客户的恶意行为被其他网站记录，可能影响到同一台物理机上的另一个无辜的客户），软件协议等问题。这些应该都不是难点，而软件协议方面，微软也已经推出 Windows Server 和 Windows SQL Server 的到期支付 (pay as you go)的协议。