从运行环境来看云计算的特征

   转:http://labs.chinamobile.com/mblog/107231_26645

 

   突然发现，很多公司一夜之间变戏法似的迅速的推出了自己基于云的业务系统:比如存储云，或者基于云环境的数据仓库等。似乎凡是冠以云的名义的系统便更有技术含量，能狠狠的吹嘘一番，赚足眼球。但是什么才叫真正的云呢，它和传统的集群系统有何差别呢？因为云的定义目前可谓是众说纷纭，未有定论——从而任你如何标榜大概都无可厚非。

    的确如此，估计谁也不能给出云的准确、唯一的定义。原来大家能达到共识的是——云作为一种商业服务模式，客户可在线按需购买其服务（平台服务，存储服务，其他软件服务等）；可近来很多公司又打出私有云的旗号，宣称可以让企业自己部署供自己内部使用的云，这便又推翻了按照商业模式给出的云定义。

    得了，具体商业上如何定义云我们暂且回避不论了，这里把注意力仅仅集中到云的实现架构特征上来，尝试探讨一下目前云系统和传统分布系统、集群系统的异同，从而了解云技术基础架构的某些特质，进一步谈谈将现有系统移植到云上需要注意的地方。 

1 "云"运行环境和传统集群系统运行环境之异同 

    我在另一篇文章中提到过，云计算的基础架构发轫于（其实就是）分布存储，并行计算，网格计算等老技术。这些技术的共同点显而易见：都是为了满足海量数据和海量结算，而利用计算机集群这种横向扩展方法将数据分布或者计算任务分布到多台机器上，达到协作完成任务的目的。

    要说到云和传统集群的区别除了商务上的服务方式创新外，最大的特点是其运行环境有别于传统集群！当前云计算初衷的运行环境被认为是廉价普通PC服务器，而且往往是异构机器——其存储部件多是SATA硬盘，而非高级磁盘阵列；使用的处理器也不会是numa体系的多核，而多是使用smp体系多核。简而言之， “云”并非代指高级运行环境，而恰恰相反它暗示着在“弱环境”（暂且叫它弱环境吧）中运行的服务。相对而言，传统的集群系统——如并行数据库等设计的运行环境很多是在专业服务器上完成，而且是同构的一批机器。请别忽视这种看似简单的区别，其实正是这种区别决定了云计算架构设计的很多策略。

    下来我们具体来分析一下，弱环境中集群系统设计要考虑的一些问题。如果你想将原来的某个系统（如以前在专有硬件上运行的）移植到云环境中运行，那么你首先需要很清楚得知道弱环境下需要解决那些问题。
 
2、“弱环境”中的集群设计需考虑的问题。
        
    “弱环境”首先要考虑的是廉价机器的异常故障情况要远多于专有硬件平台，所以集群系统设计必须充分考虑到机器异常情况。其次，还需要考虑异构环境的速度不匹配问题，这对并行任务执行影响不小。

    我们具体来看：

    1、对于集群中的存储由于没有专门的磁盘阵列（一般都支持RAID），而且由于系统可靠性不高，因此往往设计上需要使用软件方式实现多副本存储，已提高数据的安全性（当然也起到了负载均衡作用）。比如当前云环境中比较流行的GFS文件系统，dynamo存储系统都是如此。

    2、对于集群数据计算（比如并行数据库）等，需要尽可能的将任务划分，且要中间结果持续化，以避免某个处理节点故障后，由于没有中间数据，而不得不把整个计算任务重头再做——在专有环境下，节点故障率要低很多，因此各个节点之间常使用pipeline等形式传送中间结果，不会将中间结果落地，这样做无疑性能更高，但是如果遇到处理节点故障则需要从头翻工—— 当前云计算中hadoop的map/reduce任务便是这种设计，map的中间结果落地。

    3、对于异构机器来说——即便采用虚拟化技术，由于调度等原因，同一宿主机上的各同配置虚拟机执行性能也有不小的差别——所以云中各任务执行速度差异显著，因此往往需要跟踪发现执行缓慢的任务，以便把任务调度到更快节点上重新做，或者进行任务迁移等。目前Hadoop已经实现了此种特性，可见其充分考虑了异构集群执行能力差异问题。而我们知道很多设计在同构机器上运行的并行数据库，并不会重调度或任务迁移，因此当到云这种异构环境运行时，任务的最终执行会被最慢的那个拖累，造成整个任务执行性能下滑。

    4、弱环境中的程序设计更合适于对等网，也就是说集群中没有特殊节点，都是对等的，比如DHT架构的存储网。这种无单点的集群结构，对故障容忍度更高。当然这个不是绝对的，hadoop，bigtable等云服务属于master/salve结构，系统中存在master单点，因此部署时最好对单点进行HA考虑，比如多部署几个做热备。

    5、弱环境最大的优点是成本优势，设备便宜、通用，因此实现横向扩展很经济。运行于云的集群最好能充分利用这种扩展成本优势，将系统设计成易于动态扩展的高可用性系统（可用性设计要有好的故障转移机制，这里不多讲）。如何设计易于扩展系统呢，目前最普遍的方式莫过于share-nothing架构。这种结构不同于分层架构,它需要将请求接受、处理和存储等都处于一个节点内完成（不一定是一个物理机器，可以只是一个虚拟运行容器），这样以来各个点之间被解偶，不相互依赖，因此可以很容易的进行线性扩容。Dynamo系统，teradata并行数据库等都属于这种架构。 

3 移植到云环境需要做的工作   
         
3.1 移植专有集群系统 

    这节我们谈谈假如把一个已有的集群系统移植到云环境，可能要做哪些工作。我们假定移植目的地是Amazon的EC2平台上，需要移植的系统假定是teradata这种并行数据库。

    第一： 硬件需要软件化 --- amazon提供的EC2平台是使用虚拟化技术按需提供的虚拟机，你可在这些虚拟机上安装各种软件（预先制作好其虚拟机镜像），但是并未允许你将特殊硬件引入其环境。而teradata并行数据库中，联接各计算点的数据总线（bynet）采用的是硬件设备，如果需要移植到EC2中则需要将其软件化——利用软件实现这种数据总线。

    第二：teradata的数据存储是利用磁盘阵列完成，而云环境并没有这种磁盘阵列。所以这时需要找到替代方法。最直接就是采用Amazon的EBS服务 ——挂载外部存储磁盘到EC2系统上，这样可做软RAID方案来代替磁盘阵列。（这里可能会有一个小问题，就是teredata架构里VPROC单元的故障转移策略是：当某个vproc发生故障后，另一太机器上的vproc会接替其处理请求，这就要求它能访问故障点对应的虚拟盘。而amazon目前EBS 服务，不允许一个虚拟盘同时挂载到多个实例上。而teradata的故障转移机制需要多个vproc挂载同一个或一组虚拟盘上。不过这个问题不大，似乎 amazon正在解决）。

    第三：将PE处理点和VPROC处理点等都做为EC2的实例进行部署即可。比如每个PE部署在一个EC2虚拟机上，而VPROC也部署在不同的虚拟机上。

    当完成以上步骤后，便可以将类似teradata这种并行数据库集群移植到Amazon提供的公共云中进行服务。当然如果要提供更可靠和高效的服务，那么上一节提到的那些弱环境集群设计要求都应该充分考虑。 

3.2 移植web app服务

    如果要移植的是互联网程序则相对容易许多，一般可采用如下步骤进行

    1、将静态网页，图片等内容可存入S3系统。

    2、将应用程序和web server等安装到EC2的实例上。这里如果处理量大则需要部署成集群。这是自然也需要考虑到云中的虚拟机故障，也就是要设计故障转移策略等。不过部署在Amazon 云中有一个很大好处，你可以选择跨地区部署服务器，以提高容错性。比如在美国和中国都进行部署，则将风险分散。

    3、将数据存储层移植到AWS云中。如果使用的是关系数据库（mysql、postgress）等，就需要利用EBS服务来做后台存储体，将关系数据库服务程序安装到EC2实例中。同样道理你也必须自己设计数据冗余机制，以便防止某点故障时数据不丢，且可进行不间断服务。但是如果你更激进一些，采用AWS提供的SimpleDB这种多维映射表代替关系数据库，那么所有的冗余设计都交给了SimpleDB——而 SimpleDB则有良好的扩展性，性能和可用性。但它没有关系数据库那种关联查询等操作，因此如果你想使用它，那么你的web app程序设计就要避免关联查询（关于SimpleDB的特性请去google吧）。 

    总结：云计算是不是未来趋势现在来讲还维持尚早，但无可否定它的确带来了许多新奇、精彩的系统，如hadoop、hive、S3、simpleDB 。但从技术角度讲仍然未有实质性变革，而更多是各种已有技术的取舍和组合。本文仅做抛砖引玉，希望能结识热衷云计算技术的朋友，一同交流提高。