我的网络会变得更快吗？

译者注：

最近Eucalyptus公司的联合创始人Graziano Obertelli连续写了几篇关于云服务的可维护性方面的博客文章。译者读后觉得很受启发，并决定花点时间将这几篇文章翻译成中文。这些博客文章的原始出处如下：

[1]  http://gobertelli.blogspot.com/2012/12/its-maintainability-stupid.html
[2]  http://gobertelli.blogspot.com/2013/01/maintainability-and-eucalyptus.html
[3]  http://gobertelli.blogspot.com/2013/01/will-my-internet-be-faster.html

最近我写了篇关于 云平台的可维护性的博客文章，又举了一个 Eucalyptus的可维护性的例子。这回我要换一个角度，通过例子说明如何粗略地进行“负载－资源”映射。

我的网络会变得更快吗？（Will my Internet be Faster?）

在侏罗纪时代，我帮助一位用户安装一个古老版本的 Eucalyptus（我想是Eucalyptus 1.4）。我们经历了一些麻烦（那时候还没有 Faststart），不过他最终能够在两台服务器上创建虚拟机实例了。然后他问我：“现在我的网络变得更快了吗？”

我想，这个问题正确地表明了云计算这个流行语正在被越来越多的人等同于解决所有IT问题的万金油。另外，它也正确地指出了我们需要充分了解底层的硬件设施才能够获得理想的性能。一个私有云能够达到和底层网络设施一样的传输速度，能够具备和底层硬件资源同样的处理能力。云计算提供了很强的灵活性，但是也有性能损失的危险 － 如果我们没有根据负载来规划硬件设施的话。

案例讨论：云存储（Case In Point: Cloud Storage）

所有的云计算资源最终都要映射成物理资源，例如CPU、内存、网络、磁盘。在这里我要着重讨论一下 云存储，一方面是因为它很重要（没有人不关心他的数据吧？），另一方面是因为历史上有很多与云存储相关的问题。值得一提的是，我们在 Eucalyptus 3.1.2中解决了由于磁盘负载过高而导致的随机性失效问题。

这篇文章里要进行的一些估算

从我上面这幅涂鸦作品中，你可以看到临时性存储是存放在计算节点（Node Controller，NC）上的，而弹性块存储（Elastic Block Storage，EBS）是由存储控制器（Storage Controller，SC）来处理的。我们很快地看一下这两者是如何使用的：

• 临时性存储：基于实例仓库（instance-store）的实例和从EBS启动（Boot from EBS，BfEBS）的实例都使用到临时性存储，不同之处在于基于实例仓库的实例还使用临时性存储来存放root分区和交换空间（swap）；
• 弹性块存储（EBS）：任何挂载到实例上的卷都使用弹性块存储，从EBS启动的实例还使用弹性块存储来存放root分区和交换空间（swap）。

资源竞争的情形：

• 临时性存储：在同一个计算节点上的实例会竞争同一个存储资源；
• 弹性块存储：在同一个可用域（availability zone，在Eucalyptus中等同于一个集群）中使用弹性块存储的实例会并竞争同一个存储控制器。

在这个例子中，我用了一个简单的 电子表格来帮我进行计算。你可以任意拷贝、修改、改进这个电子表格，不过你需要记住这只是一个学习工具而不是一个真正的资源计算器 － 为了简化计算，有太多的因素没有被包括在这个电子表格中。

在这个例子中，我使用 IOPS来衡量底层存储的速度.

不同设备的IOPS数据可能有很大的差异。如上数据只是粗略地表明IOPS性能的量级。

在接下来的例子中，我做了一个不太合理的假设 － 所有的实例都平等地访问存储资源（包括临时性存储和弹性块存储），以及它们可能在20%或者100%的时间里需要访问存储资源。需要说明的是，在20%的情况下， Oracle 会自动地对并行的磁盘访问请求进行优化（也就是说，如果同时运行少于五个实例的话，它们得到的是最快的存储性能，实例之间不存在资源竞争的情况）。

也就是说，20%代表了轻量级的应用场景，实例在大部分时间里都在发呆；而100%代表了重量级应用场景，实例可能正在进行压力测试。启动实例是一个磁盘IO密集型进程，一方面是因为Eucalyptus需要为启动实例准备磁盘映像（需要拷贝好几个个GB的文件），另一方面是因为操作系统在启动过程中需要读取磁盘。在这个电子表格中，我专门添加了一栏以显示在轻量级应用场景下启动实例的磁盘负载开销。

家庭级配置（Home setup）

一个家庭级的云试验环境通常使用基于本地存储的存储控制器。这里我们用一个 IOPS计算器来进行性能估算。在存储控制器上，我使用了两块15000转的Seagate Cheetah硬盘，做了个 RAID 0，估算得到的IOPS数据是343（为了简单起见，就算是350吧）。在节点控制器上，我使用了一块相对较快的硬盘（非SSD硬盘），假定其IOPS可以达到150。

对于一个家庭级的云试验环境来说，三个计算节点看起来是个不错的数字。我们假定每个计算节点都有足够的CPU核心以及内存，能够运行多于10个虚拟机实例（12～24个CPU核心，12～24 GB的内存应该足够了）。如果我在每个计算节点上运行一个基于实例仓库的实例、一个从EBS启动的实例、以及一个EBS卷。这个不太靠谱的计算器给出的数据如下：

家庭级的云试验环境，在虚拟机数量较少的情况下，在最坏情形下存储性能也相当于一块5400转硬盘。

这个家庭级的云试验环境看起来还不错嘛。就算是在各个实例中对所有的磁盘进行 iozone测试（最坏情形），我们也能够得到相当于单块5400转硬盘的性能。 接下来我们增加一点负载，在每个计算节点上运行四个基于实例仓库的实例、四个从EBS启动的实例、以及两个EBS卷。这时候我们得到如下数据：

家庭级的云试验环境，在虚拟机数量较多的情况下，在最坏情形下存储性能可能跟软盘差不多。

这回就有点意思了。如果各个实例的磁盘负载不大的话（最优情形），我们可以得到类似于7200转硬盘的性能。但是，如果各个实例的磁盘负载很高的话，磁盘IO的性能就跟侏罗纪时代的软盘差不多了。哼哼！

企业级配置（A More Enterprisy setup）

根据上面的数据，在大型的云计算环境中，显然需要考虑使用基于SAN存储的存储控制器。在这个例子中，我使用了一套 Dell Equallogic存储设备，将其存储性能配置为5000个IOPS。此外，我们将计算节点的数量增加到10个。

我们还是从较轻的负载开始。在每个计算节点上运行一个基于实例仓库的实例、一个从EBS启动的实例、以及一个EBS卷。（和家庭级云试验环境是一样的，但是现在我们一共有20个正在运行的虚拟机实例了。）

配备了SAN存储设备的企业级云试验环境，在虚拟机数量较少情况下，所有的数据看起来都很好。

这个结果看起来非常好。EBS存储性能在最坏情形下还能够达到250 IOPS，在最优情形下甚至能够达到1250 IOPS。临时性存储的性能与家庭级云实验环境相比没有发生什么变化，在最坏情形下还能够达到75 IOPS，相当于一块5400转硬盘（也就是常见的3.5寸台式机所配备的硬盘）的性能。

接下来我们增加一点负载，在每个计算节点上运行四个基于实例仓库的实例、四个从EBS启动的实例、以及四个EBS卷。这时候我们得到如下数据：

配备了SAN存储设备的企业级云试验环境，在虚拟机数量较多情况下，在最坏情形下EBS存储性能相当于一块5400转硬盘。

临时性存储的表现还是不够理想，就跟我们在家庭级云实验环境所看到的一样 － 现在每块本地硬盘上要承载8 个虚拟机实例（从EBS启动的实例也需要访问本地硬盘，在这个简化计算中所有的磁盘是使用情况是一样的）。EBS的性能有了大幅度的降低，在最坏的情形下与一块5400转硬盘相当。虽然所有的实例还有足够的IOPS来访问存储设备，但是这时候云管理员应该考虑增加一个可用域（集群）了。

快照（Snapshots）

上面的例子没有考虑到制作快照对存储性能的影响。快照使得我们可以对卷进行备份，并将数据从一个可用域转移到另一个可用域（在一个可用域中制作的快照，可以作为母本在任何可用域中创建新的卷）。快照被存储在Walrus上，也就是说每次我们创建快照的时候，我们从存储控制器（SC）上将一个卷的完整拷贝保存在Walrus上。如果在一个云上频繁地制作快照，可以想像存储控制器、Walrus、还有网络的性能都会受到很大的影响。

期望值（Expectations）

可以认为，上面例子中的数据反映的都是特定应用场景下的最佳性能。在这些分析中我们忽略了网络性能、来自其他进程的磁盘访问等等众多因素。譬如说，Eucalyptus缺省地使用实例仓库来提供交换空间（swap），而大部分Linux发行版都会在安装的时候创建一个swap分区（在Eucalyptus中，从EBS启动的实例可能大部分都需要swap）。因此，这些虚拟机实例在内存不够用的时候都会往相应的磁盘上写数据，从而造成额外的负载。

在这些模拟分析中，我们假定虚拟机实例的负载是相互独立的，并且假定它们之间有一个协作机制使得整个云试验环境的整体磁盘访问达到了最佳情形。在一个生产环境中，创建虚拟机、销毁虚拟机、创建EBS卷、创建快照的时间和顺序基本上是无法预测的，这些都会对存储（包括临时性存储和弹性块存储）造成额外的负载。

在我前段时间发表的关于可维护性的博客文章里面提到，对负载进行采样能够帮助你对云服务进行测试和性能调优，使其能够满足最终用户的要求。

让网络快起来（Making Internet Faster）

在上面的估算中，我们没有考虑任何来自软件因素的性能影响（例如Eucalyptus各个组件本身也是消耗资源的）。事实上，Eucalyptus各个组件对物理资源的需求是在不断降低的。譬如说，在Eucalyptus 3.0以前，计算节点直接地拷贝多个GB的磁盘影像文件，现在我们使用device mapper来减少磁盘访问请求。此外，配置有SAN存储插件的存储控制器增加了一个称为DASManager的模块（DAS是Direct Attached Storage的缩写，指的是直接挂载到宿主机上的存储资源，例如一块磁盘或者一个分区），使得我们能够绕过文件系统对卷进行操作。

和以前的版本相比较，Eucalyptus 3有了很大的性能提升，但是我们还有很大的优化空间，譬如使用分布式文件系统和 软件定义网络（Software Defined Network，SDN）。的确，目前Eucalyptus还不能够让网络快起来，但是我们正在往这个方向努力。