我眼中的云计算2-计算资源

        随着云承载的业务在增长，云的规模也在不断膨胀，但批逐次增加的硬件存在着性能差别（摩尔定律还在生效中），单位功耗下硬件的计算能力不断提高（此处仅关注CPU本身的性能以及CPU与内存系统的带宽，简单看Nehalem架构与Sandy Bridge架构同频CPU的几个对比测试：SuperPI/wPrime 32/Memory，幅度从5%到70%不等，最大的是i7的内存写入性能差异，前文提过的超线程技术在多核性能测试中的影响较大）。

        

        

        

        如果能把计算能力量化，那么硬件即使变化，用户也可以清楚新申请的计算能力与当前使用的是否一致，在负载均衡时能更好的分发最终用户的请求，服务器硬件厂商一直以来都会提供spec测试数据，云服务商为什麽不提供类似的参考数据来量化计算能力呢？相信云服务商自己在选择硬件时，一定会考虑性价比。Amazon把它定义为Compute Unit，但没找到具体的数据（了解的兄弟请留言）；国内的两个云服务则有所不同，阿里云还好，给出了CPU的主频Xeon2.26G，型号未知，而盛大云只有1core/2core/4core信息，连明明白白消费都做不到。

         

         

        广告中云服务优势之一是扩容方便，比如在用户的系统负荷达到峰值的时候，为了保证用户体验和系统的稳定，热扩容自动进行，增加资源以加大系统的处理能力，但国内的云提供商暂时支持动态扩容。扩容有两个方向：垂直扩容和水平扩容，静态扩容由用户主动发起完成，没有太多可讨论的，主要琢磨一下动态扩容。
         先看垂直热扩容，云主机收费的三个资源参数：CPU/内存/硬盘；
         1.CPU资源，难度最大，但是CPU的增加可以对虚拟机实例的性能产生直接影响；CPU的动态增加需要虚拟平台和虚拟机实例上所运行操作系统的双重支持，而且CPU的增加还可能导致宿主机器的变更，计算能力有可能发生变化。
         2.内存资源，难度中等，目前已经可以支持热增加，但需要应用软件的支持，如果类似于JVM通过文件配置的方式，进程内存的增加只能通过重启生效，那么弹性扩容也无法自动应用，但也可以通过增加调度模块，监控内存变化来启用使用多JVM进程；

         3.硬盘资源，难度最低，容量的增加可以立刻生效，当存储空间达到阈值的时候，只要增加空间就能够立刻应用，但是磁道在盘片的物理位置影响着读写速度。

         再来看水平热扩容，增加虚拟机实例的方式，如果由用户预先配置好可用的虚拟机实例，当使用中的的虚拟机实例总负荷超过预设阈值一定时间的情况下，云提供商动态启用预配置完成的虚拟机加入计算集群，但负载均衡的分发器需要动态添加新的虚拟机实例信息；在系统负荷降低后，云提供商能够自行关闭相应的虚拟机实例。(Amazon EC2实现了虚拟机实例级的自动扩容)

        最后有个邪恶的想法，云提供商会不会偷用户的计算资源呢？一台物理机的CPU/内存/硬盘资源应该不会刚好完全分配给用户，那么预留出的这部分相信也会执行云提供商自己的计算任务，这部分资源如何利用最大化呢？起码云存储还需要少部分CPU的计算能力。又回到了最开始，貌似只有量化的计算资源，才好相对精确的控制子任务的分配，控制任务的总耗时最小。