云计算讨论

一、云计算的概念 

云计算的概念是近年来一些大型互联网应用供应商，如：google, Amazon等最早提出来的。他们的出发点是采用大量的、中低端的计算机组成大规模的处理群集，用来提供强大的互联网应用平台。 

事实上，采用大量中低端的计算机构成大规模计算平台，这是若干年前的“超级计算机”的概念。 当年研究的问题只要集中在这些计算节点之间的通信和协调，以及大规模计算任务如何分解成大量可并行任务并分配部署到计算节点中。随着互联网和应用的发展， 今天，我们可以站在互联网应用的角度来看待当年超级计算机的架构能够给我们带来什么。 

当今，一些主要的、知名的互联网应用公司，他们的计算机系统架构是什么样的？他们与传统的金融、电信、政府的系统是一样的吗？ 

传统的电信、金融、政府、企业，他们的IT架构通常包括：集中式的数据库服务器（一般是双机 的高端小型机服务器）、应用服务器（也是高端的小型机，常常多于一台，配置成群集）、前置机（类似于应用服务器，常常提供字符终端的应用），剩下的就是前 端客户机了。因此，主机房一般就是几台大型的服务器，系统管理员围着它转。传统行业服务器所运行的软件也基本上是商业软件，开源的软件比重极小，这关键是 需要得到厂商的支持，减轻自身的维护压力。他们为什么会如此规划？因为主要的应用系统的负载是可预测的，系统的建设是“计划经济”的，一般由企业的计划部 门规划，然后招标、由IT部门和厂商负责实施。 

而对于互联网公司来说，一切都在永不停滞的发展中，他们的发展是“市场经济”指导的。起初， 公司和应用创建的时候，用户量比较小，也没什么收入，属于“烧钱”的阶段。此时，他们的IT架构也不太可能是大型高端的服务器，一般是PC服务器，而且软 件也多是开源的为主（除了成本的因素，公司的成员多为主人翁也是重要的原因）。随着应用的扩展和公司的成长，他们自然地就会通过增加PC服务器的数量来实 现系统的扩展性。今天，我们会看到这些大型的互联网应用公司，他们的IT架构是PC服务器的群集，并以开源软件为主。在这样的应用成为一种模式以后，这些 著名的公司便开始倡导这样的系统架构，把它从支持特定的应用，转而成为面向通用计算的一种模式，这就是云计算的由来。 

即便是传统的应用系统环境下，以往的小型机服务器的可扩展性在实际的应用周期中也显得很尴 尬：在初次采购的时候，如果不是满配，原本想给未来的扩充留有余地。在系统平台飞速发展的今天，到时候，常常是要么硬件早已升级，同样的钱可以买更好的； 要么旧的型号已经不生产，想扩充的费用比买新的还贵。而如果一开始就满配，则失去了所有“可扩充”的好处。所以，未来的系统扩充，必然是横向的扩充，必须 考虑的是不同机器、不同型号之间的扩充。 

随着“软件即服务”的思想的兴起（目前的几个著名的互联网公司是积极的倡导者），软件服务的 提供者所面临的，实际上是处理能力的快速增长和不确定性。单一的传统服务器的构建思路显得并不适合。可自由伸缩，具有强大扩展能力的架构成为主流。这里涉 及到的技术概念则包括虚拟化（让操作系统“漂浮”在具体的硬件上），以及将大量的计算资源组成高度可塑的、随意扩展的“云”。把这种“云”发展成新的计算 模式。 

二、云计算的几个要素 

在此，我们讨论云计算的一些关键要素，并请大家补充：

 1、超级计算机架构

大量的计算机通过互联网组成“云”，每个计算机作为一个计算节点。组成“云”的计算机，它们 的硬件平台和操作系统并不要求完全一样。不过，目前为了实现和管理上的方便，可以理解成每个计算节点都运行Linux。如果某些非Linux的机器要加入 “云”，它们可以运行类似VM Ware的软件，在其上安装Linux。 

这样的构思还不仅仅是为了各个节点的操作系统统一，云计算的概念，至少从今天看来，在平台的 角度上，它的野心还没有大到打算提供一个跨硬件平台的、运行在互联网络上的、将各个节点的CPU当成SMP的、共享各节点物理内存的，单一的操作系统。因 此，云计算在很长的一段时间内，它的基础平台是多个拥有自身操作系统的节点。在这个基础上，云计算环境需要有能力将某个软件模块或数据从一个节点移到另一 个，这虽然可以通过操作系统的命令在应用软件的层面完成；但不排除在软件复杂的情况下需要整个操作系统的迁移。这样，参与云计算的各个节点，它们最好是运 行在虚拟化平台上的操作系统，整个操作系统能够在虚拟化平台的支持下方便地装载、卸载和搬迁。为此，一些文献中会频繁地提到Xen系统和VM Ware等平台。 

从系统的水平扩展的角度看，云计算环境将由很多个网络上的服务器构成，其中大部分是现有的系统资源；这样，企图提供一个单一的操作系统，横跨海量的网络服务器环境也是不现实的。由独立的操作系统提供基础，通过虚拟化手段提供平台，目前是最合适的方案。 

2、运行的软件

目前，云计算的特点是大量开源软件的使用：构建云计算中心，并不需要一开始就拘泥于商业软件，开源软件社区对云计算的态度更加积极，而且文化理念也更相近。因此，软件的使用要专注于提供什么功能、解决什么问题。开源软件作为首选，在项目成熟以后，对应考虑商业软件。 

3、大规模并行处理

在云计算环境中，如何将一个应用软件根据需要布署到不同的节点上，如何将应用软件根据需要在 节点之间迁移，以及对于每一个物理的节点如何在虚拟化的基础上跑多个操作系统，这些都是被广泛讨论的话题（总是局限于讨论这个话题的厂商，它们往往没有其 它方面的解决方案），但它还不是云计算最核心的问题。云计算在技术上需要解决的核心问题之一，就是要利用云计算环境中的多个物理节点提供大规模的并行处 理。一个传统的应用软件，如何能够利用云计算提供的多节点、分布式的计算环境？ 

由于云计算的底层是多个独立的操作系统，对于这个问题，我们需要从数据的管理、数据库系统、应用软件、网络服务等几个层面分别讨论。 

4、云计算中的文件系统

文件系统是数据管理的基础层面之一，从根本上来讲，讨论数据管理应该从更低的层面，如：物理 卷和逻辑卷的层面开始。可以设想：云计算的基础环境会包括一个分布式的存储管理，也就是物理的存储由各个节点所管理的存储构成，但是提供用户一个统一的物 理卷/逻辑卷，用户可以在上面建立数据库设备或者文件系统。不过，从现实的发展来看，云计算的概念是从应用发展而来，一开始，我们讨论的层面就是文件系统 了。至于未来会不会有分布式的存储系统，还要看发展。 

从文件系统的层面看，在云计算环境中，一个分布式的文件系统将提供以下的功能： 

1）多节点的存储管理

需要有能力在多个节点上占用一片存储区域。在每个节点上，可以是一个大文件，或者多个大文件的形式。这同时取决于操作系统，如果操作系统是32位的，理论上单个文件的大小不超过2GB。这样，一个节点上的存储区域可能要采用多个大文件组成。 

这片存储区域需要由专门的服务软件管理，这个软件应该运行在本地节点上。这个软件加上所管理的存储就构成了一个存储节点。 

2）分布式文件系统/服务节点

多个存储节点构成了云计算环境中分布式文件系统的基础。分布式文件系统需要给用户提供创建文 件、读写文件、操作文件属性等传统文件系统所应该具备的功能。这些功能由另一个软件模块完成，这个软件模块就是分布式文件系统的服务节点模块，我们在此可 简称它为服务节点。服务节点提供的功能是综合性的： 

它可以将用户所要创建的文件拆成很多碎片，分别存储在多个不同的存储节点上。在此需要考虑的问题包括： 

分片的策略：将用户的数据文件根据分片策略分成很多份，具体实现的方式可以有若干途径。是人 工指定、还是自动规则？与数据的内容是否相关？在这个层面上，系统不应该考虑数据的内容，分片的策略应该是纯物理层面的，系统将根据文件块的划分（块的大 小由文件系统管理层决定），通过文件的块号进行散列是最有可能的解决方案。不过，这个解决方案还应该考虑到连续块的读取（提前读）的一些问题。 

对于文件大小固定或者有明确预期的文件，是否可能安排到一个存储节点，或指定的几个存储节点上？以便未来在高层次逻辑层面提供访问范围的界定。 

冗余的策略：在云计算环境中，应该支持这样的功能：如果有80%的存储节点是有效的，数据就 能够保证正确访问，这种情况类似于raid5的功能，在冗余的策略环境下，分片的策略是否会受冗余算法的影响？与此同时，在云计算环境下，由于参与的服务 器节点数量众多，冗余算法在很多情况下不必追求过分的精细，同一个数据单元，有可能存在多个备份，冗余的系数可能大于2。 

- 服务节点保存了分布式文件系统的管理字典，它记载了各个文件的位置以及分片的情况。

- 服务节点在得到用户的文件访问请求的时候，首先将根据文件指针的位置、分布式文件的管理字典，找出涉及本次访问的存储节点。服务节点只和涉及本次访问的存储节点通信。

- 了解整个环境下各个存储节点的空间占用情况，以便安排未来的分片布署策略。提供文件系统整体管理的各种参数。 

3）分布式文件系统/存储节点

由于存储节点本身采用的当地的文件系统，高速缓存的问题不用过分考虑。但是，在服务节点上， 由于每次文件访问涉及到与多个存储节点的通信，为此有可能需要实现一个“高速缓存”的机制，将经常访问的文件数据块在本地内存中留映像。不过，这个机制需 要考虑多个服务节点的情况，任何数据块的修改都需要直接在存储节点上体现（数据块失效的管理）。 

4）分布式文件系统/管理字典

一个分布式的文件系统可以存在多个服务节点，这样就可以避免单一服务节点可能造成的访问瓶 颈。但同时，各个服务节点之间需要保持各自的管理字典的内容同步。这个管理字典是否可以存放在某个存储节点上（各服务节点共享访问）？如何提高分布式文件 系统的管理字典同步的效率，是一个值得讨论的话题。 

5）数据访问封锁问题

数据访问封锁是一个需要考虑的问题：任何一个文件会有多人访问，他们可能会有互斥操作的需 求，这就涉及到了封锁。文件的封锁一般有两个级别，一是文件级的，一个是文件内部区域级的。如果只有一个服务节点的话，这个文件的封锁机制则可以在服务节 点软件中实现。而如今有多个服务节点同时存在，则文件的封锁机制需要在存储节点上实现。存储节点的实现方式可以考虑分布式的，每个存储节点只负责自身管理 的数据（文件）上的封锁。尽管如此，我们会发现，任何一次文件数据的封锁都会导致服务节点与存储节点的网络通信，这在操作密集型的应用中可能会是性能的障 碍。 

因此，我们可以注意到，目前的分布式文件系统在互联网的应用中多为查询密集型的；而且这些查询往往是可以借助索引直接定位的事务性查询，而不是覆盖整个文件的扫描式查询。 

在此，我们需要研究一下现有的软件产品中是采用什么策略。在分布式的文件系统产品上，我们可以认为google file system是一个C语言的分布式文件系统版本；而今天大家经常提起的hadoop (http://hadoop.apache.org/core/)是Java的分布式文件系统版本。 

6）服务的接口和软件架构

分布式文件系统的访问和操作都需要通过服务节点给出的API来完成。目前看到的一些分布式文件系统，如：Hadoop，都是提供了自己的Java API让用户来使用。 

未来是否应该将服务节点提供的API与所在的操作系统连接到一起（如：重新连接Linux操 作系统），让分布式文件系统成为操作系统自身文件系统的一部分（或者通过mount装载上去）？这样的话，就扫清了在分布式文件系统上安装数据库或其它复 杂应用的障碍。不过，在云计算倡导的虚拟化环境下，这种与宿主操作系统密切联系的方案也不一定是最被推崇并被广泛使用的。同样的问题包括：未来是否有必要 提供逻辑卷层面的分布式存储管理？这样，运行数据库系统能否更容易一些？ 

服务节点和存储节点都是软件模块，可以运行在同一个物理节点上，也可以在不同的节点上。 

7）动态扩充存储或服务节点

对于分布式文件系统更进一步的技术问题是：对于一个已经在运行的分布式文件系统如何动态扩充 节点？分片的策略是否能够中途改变？如果其中的文件持续扩大，需要怎样的调整？分布式文件系统需要为此提供什么样的功能是最合适的（并不是提供的功能越多 越好，还要看实现的效率和代价，设计思路是否合理？同样的功能是否能够通过几个不同层面的功能组合而成？）？ 

除了分布式文件系统，在多服务器的环境中还可以考虑GPFS的应用。相对于GPFS，NFS是网络文件共享，A机共享出的FS可以被B机挂载，GPFS可以统一管理这些FS，把他们融合成一个大的FS，而且可以实现一个FS被多个主机共享。 

总体看来，在分布式文件系统的实现中，文件访问的并发封锁是代价最大的。往往可能由于封锁机 制的实现，导致系统性能的重创。如果分布式文件系统主要面向读取的应用，系统的设计就会简单很多，效率也就不成问题。为此，我们需要深入研究一下目前市场 上的主流产品，如：google file system和hadoop是如何实现封锁机制的。它们是否也是面向读取应用的？从具体的应用来看，google的搜索引擎、hadoop实现的纽约时报 历史查询，都是面向读取应用的，对文件系统的操作和封锁几乎没有要求。 

此外，如果云计算环境中的多台服务器都将自身的文件系统以NFS的形式提供出来，同时，包括GPFS的使用，会对云计算的文件管理起到什么作用？是否有一些要求不高的应用可以采用这样的方式？ 

5、云计算中的数据库

关系数据库是应用系统的核心，作为数据管理核心的数据库系统在云计算环境下会是什么样子呢？当然，核心的出发点就是要让关系数据库能够充分利用云计算的分布式多节点，并能提供高效率的查询和操作。 

1）数据库设备的分布式环境

数据库的数据管理设备需要能建立在分布式文件系统上。目前的数据库产品，数据设备一般有两种 可以选择，裸设备（逻辑卷）或文件。如果是选择文件系统的话，理论上是可以采用分布式文件系统的。但是，我们注意到，现有的分布式文件系统需要通过专用的 API（由服务节点提供；目前的“分布式文件系统”并没有重新连接服务节点所在的操作系统核心，把自己变成操作系统自身文件系统的一部分）才能访问；因 此，数据库系统必须指明能够采用某种分布式文件系统才可以。也就是说，数据库的底层数据管理部分需要是在这个分布式文件系统上开发的才可以。 

MySQL据说可以将数据管理设备建立在Hadoop上，而其它商业数据库产品，如：Oracle, DB2, MS SQL等，还没有相关报道。 

仅仅将数据库设备建立在分布式文件系统上对于云计算下的数据库还远远不够，就分布式文件系统充当数据库设备本身，需要解决如下问题： 

- 一个数据库设备在分布式文件系统中可能被划分成很多碎片，分散在多个存储节点 上。这在很多情况下并不是我们想要的：数据库的设备往往是固定大小的文件；除了少数情况下需要直接扩展设备空间，大多数情况下数据库的扩展通过增加设备完 成；这样，我们有时更倾向于将这些数据分散到固定（指定）的节点上，包括冗余节点也在一个指定的范围内。这样做的目的是为了提高访问的效率，同时也为高层 次的逻辑分片提供优化布署策略的可能。

- 从技术角度讲，分布式文件系统对于数据封锁（互斥访问）的实现代价是比较大 的。频繁的封锁最好尽量避免。这在文件系统的应用中可以通过应用来控制，但在数据库系统中，就无能为力了，只能由数据库服务器决定。因此，采用分布式文件 系统作为数据设备的数据库系统，应该提供一些开关、或配置参数，能够允许用户在特殊的时候关闭数据库内部的数据封锁机制，在只读环境或离散事务环境下提供 更高的访问性能。 

从另一个角度看，数据库系统的设备本身就是可以分散在多个地方的，例如：一个数据库可以建立 在多个逻辑设备上，只要这些设备可以被数据库服务器访问。这样，如果云计算环境中的存储不是每个服务器的内置硬盘，而是网络上的IP存储，就可以被某个服 务器上的数据库当作数据库的设备来管理。为此，在未来的云计算环境中，IP存储设备可以成为云计算的存储节点，而传统计算机的节点可以充当计算(CPU) 节点。如果云计算环境中的硬盘大都是各个服务器的内置硬盘，则可以考虑在软件上实现一个IP存储的服务。这跟实现分布式文件系统的存储节点有些相像，其中 区别可以留作技术问题探讨。 

2）多服务器结构

完成了上述的工作，只是数据库在云计算环境中的第一步，它只实现了一个数据库服务器将“云” 作为一个存储设备。数据库服务器可能成为访问瓶颈，为此，我们必须引入多服务器的结构。多服务器的结构首先是对称多服务器结构，即每个节点的数据库服务器 提供相同的功能和服务，用户通过任何一个节点的数据库服务器都可以访问和操作所有的数据。 

一个普通的数据库服务器并不能不作修改直接配置成这样的环境。主要的技术区别在于数据的封 锁，在对称多服务器的结构下，每个数据库服务器对数据封锁的管理就不能局限在本服务器内部，而是需要与其它数据库服务器统一协调。在这种情况下，分布式文 件系统服务节点提供的数据封锁接口就相当于传统群集环境中的DLM（分布式共享锁管理器），数据库服务器的数据封锁机制需要在这个层面上开发。 

与此同时，在遇到某个数据库服务器失效的情况下，整个数据库服务器群还需要有一个监控机制，能够统一地、及时地清除失效服务器所设置的数据封锁，回滚相关事务，让其它数据库服务器继续运行下去。

此外，在对称多数据库服务器环境中，数据库的事务/逻辑日志是每个服务器维护自己的，还是需要统一的共享一个，也是需要探讨的问题。 

从这个角度看，目前Oracle RAC的群集服务器结构，在原理上是最接近的。其它数据库服务器需要怎样的修改，是一个非常值得探讨的问题。MySQL目前好像还没有这个功能。 

多服务器的问题涉及复杂的技术实现，其中的拦路虎就是多服务器下的访问封锁互斥的实现。很多厂商基于性能的考虑没有去走这条技术路线。在云计算环境下，对称多服务器的架构对于数据库来说是一定需要的吗？是否实现，或者是否有其它的路可以走？ 

3）大规模并行处理

实现了上述的对称多数据库服务器的结构，还不能解决查询的大规模并行处理。对称多服务器的结 构，最能够发挥作用的是面对大数量用户的事务性访问。而对于一个或数量不多的复杂的大规模查询，对称多服务器的结构是起不到什么作用的。在这里，我们需要 实现一个非共享策略的，多数据库并行服务器。其体系架构类似于DB2 ESE或NCR的Teradata。 

这样的数据库服务器基于数据分片的原理，每个参与并行服务器的数据库节点负责管理其中一个分 片，各分片之间是不相交的。在并行服务器群集中，有一个数据库节点作为协调节点，负责接收用户的请求，并根据数据分片字典将查询请求分解、传达给其它数据 库节点。在未来的设计中，协调节点应该可以有多个，以避免单点的瓶颈。 

在目前的市场上，DB2和Teradata虽然可以支持这样的结构，但其底层并不能支持分布 式文件系统，还不能支持前面的两个结构。而且，它们的协调节点也只有一个。单纯非共享的并行数据库结构与云计算是吻合的，我们当然可以试图把数据分得很 细，使它们适合于分配到单个服务器节点上，而避免使用分布式文件系统作为数据库设备。但是它缺少多个协调节点的功能，这样就无法避免单点瓶颈的问题。一旦 引入多个协调节点，我们遇到的问题似乎与对称多服务器的情况又一样了。 

在云计算环境中，如何提供一个数据库平台，能够支持全部这三个特性；这样的数据库平台可称之为真正的云计算环境数据库。目前，我们的研究重点可以放在MySQL上，这是一个开源的产品，它会有更多的潜力进行扩展。 

可以看出，在云计算环境中，现有数据库系统遇到的挑战是最大的。能够满足上面全部三项功能的商业化产品还没有，而且即便朝着这个方向努力，技术、性能的代价也非常大。为此，我们需要思考折衷的办法，充分利用云计算的结构特点，同时又适应数据库系统的技术现状。 

数据库在大规模应用中，可以分几个应用的情况来讨论： 

1）大数据量

纯粹的大数据量对于数据库系统来说并不可怕，解决的方法无非是将数据分片，存储在多个物理的 设备上。现有的数据库产品都提供这个功能。在云计算环境中，唯一不同的地方就是可能没有特定的存储设备（云计算环境的存储思路，与传统SAN和NAS是对 立的，它不强调大规模的专用存储设备，而是利用个服务器自身的内置存储；目前来看，这些内置存储费用应该更低，但长远是否这样还不好说），需要我们把各个 服务器内置的硬盘整合起来。 

如果不采用多服务器的数据库（非共享多服务器、大规模并行处理）的话（多服务器，非共享的并行处理属于更高一层，不应该纯粹为了数据容量考虑），就需要让一个数据库服务器能够看到这些存储资源。具体的办法有以下三个： 

一、把各个服务器模拟成IP存储节点。这是一个很有趣的话题；目的是想让这些存储的访问效率高于文件系统。需要研究的是：当前市场上的NAS，IPSAN能够符合这样的要求吗？需要从性能、价格、市场背景等方面去考虑。 

二、可以让每个服务器把自身的文件系统NFS共享出来，在数据库服务器上看到这些共享的文件系统，把数据库设备建立到它们上面。至于可靠性的问题，可以通过数据库自身的设备镜像的方法来解决。 

三、上述的工作也可以采用GPFS来实现，将数据库设备建立在GPFS上。在此，需要考虑GPFS与NFS的区别。从根本上讲，有NFS就足够了，是否引入GPFS要看访问的效率，而不是GPFS的管理和集成能力（多个设备的集成问题，数据库自己能够解决）。 

2）大查询访问量

大的查询访问量需要用到非共享的大规模并行处理，将数据划分成分片，布署到多个服务器上，并最终组成一个数据库。目前的解决方案，跟数据仓库完全一样，对于复杂的查询没有问题，但在访问人数众多的时候，弱点在于协调节点只有一个，容易形成访问的瓶颈。 

这种情况，给分布式文件系统的解决方案留下了很大的空间。分布式文件系统可以有很多服务节点，但它的查询能力又有限。具体的应用需要考虑这两种模式的组合。 

3）大交易访问量

大交易量的应用采用文件系统不适合，大多数情况下只能采用数据库。而这个时候，对称多服务器 由于封锁机制的代价，效果也不看好。目前的情况下只能通过应用的划分来解决大规模的处理量。在交易的请求中就获得一个id，这个id可以决定通过哪个服务 器来接收。各服务器之间的主交易数据是非共享的，只有控制、管理信息是共享的。 

6、云计算中的应用服务器

目前，应用服务器指的是EJB服务器，传统的事务处理服务器和CORBA服务器虽然属于类似 的范畴，但我们在面向未来的应用时，解决了EJB服务器，也就解决了大部分的问题。目前市场上的EJB应用服务器本身都是可以支持群集环境的。它们之间有 些还可以提供内存的映像来支持故障会话接管和容错。况且，由于应用服务器并不负责数据存储，遇到服务器失效，重启一个会话也都是可接受的。群集的负载分担 也很容易实现。

因此，应用服务器载运计算环境中，分布式并行、容错的问题很容易实现；需要做的事情就是应用的动态布署、迁移等。 

7、云计算中的Web服务器

Web服务器与应用服务器的情况相同，它们也是天生具备在云端生存的基因。多服务器均衡负载、故障的接替（其实Web服务器不需要接替，只要有存活的服务器，用户请求就会转过去）非常容易实现。 

8、云计算的接入层

云计算，作为一个信息系统服务架构，需要有面向使用者的介入层。这层的主要任务是避免单点的瓶颈，以及提供安全访问的管理和控制。 

从均衡负载来看，可以有硬件平台的参与，如F5；也可以通过软件的方法，如：LVS。同时， 在云计算环境中也会考虑到系统安全的问题，但这个问题并非最关键的问题，可以交给专业的公司去解决。目前，IBM提供的cloud是企业的，在防火墙里面 的；其他公司提供的cloud是在互联网上的。 

9、云的管理和动态布署

上面，我们探讨了云计算的基本要素。在这个层面上，我们需要对一片“云”进行配置和管理。这 虽然可以是手工的工作，但是，当我们面对一片“云”的时候，必须借助工具一节省体力。在上述的各个环节基本明确以后，我们发现，云计算环境中软件、数据的 布署和迁移占据了很大的工作量。

在“云”的管理和动态布署中，我们会关心一下的话题： 

1）系统参数、云计算环境的状况

了解、报告“云”的状况：各个机器（服务器）、配置、状态，等等；通过一个统一、集成化的平台来管理、监控整个云计算环境。 

2）应用软件的布署和迁移

把各种软件组件布署到希望的云节点上。这里根据不同类型的软件，方式方法个不相同：

- 文件系统建立、文件创建

- 数据库安装、配置

- 软件安装、拷贝、配置

- EJB的布署、JSP的布署，应用服务器配置

- Web Server的配置 

在此，工具的作用在于不需要让用户自己运行ftp上传，telnet远程操作，等传统的工作；所有软件的安装、配置、布署等工作，都通过工具完成。 

3）数据的部署和迁移

- 文件系统的迁移

- 数据的迁移 

这里，可能包括数据库存储、设备、甚至包括分片的重新规划。可能涉及到分布式文件系统的安装、配置、更改。NFS和GPFS的各种配置。 

4）操作系统（包括应用）的迁移

由于云计算环境中大量使用了虚拟化技术，这样，在很多应用需要迁移的情况下，但应用与操作系统联系密切，我们就可以通过迁移整个操作系统来完成这个任务。 

目前IBM提供的Tivoli Provasion模块，就是在云计算环境下用作管理和布署的工具。不过，从上面的讨论中我们可以看到，这样的工具非常依赖软件的发展，而且自身一定在不断地发展变化中。 

三、云计算与网格计算的对照 

云计算和网格计算在采用分布式多服务器的架构上是很类似的。但他们的出发点和最终的应用有很大的不同： 

1、  网格计算主要是为了利用网络上庞大的空闲计算资源，把它们用于某个专用的任务，而且往往是一次性（离散）的；云计算则是有目的的使用分布式处理环境提供一个应用系统平台。一般不会有组织专门为网格计算采购并建立服务器群，但有人会为建立云计算中心采购服务器群； 

2、  网格计算一般只解决一个问题，每个参与的节点所做的事情（流程）是一样的，只是每个节点针对自己的数据集，全部节点的结果汇总就是问题的结果。在云计算中，不同的节点是分工的，它们要提供的是一个应用系统的平台，而不是解决一个单一的程序问题。 

四、云计算在技术和业务上的一些疑问 

1、特定的应用还是通用架构

云计算起源于特定的应用，它是否适合并能够发展成通用的平台？Cloud computing将成为通用的计算模式还是仅成为特殊应用的一种架构？ 

目前，在云计算领域的探讨，所列举的应用模式多为互联网应用；而且以文件系统的数据管理为 主，查询也多为事务性的定位查询。这样，人们不禁要问，云计算的环境适合所有应用吗？传统的应用要做怎样的修改和扩充才能运行在云端？从前面的讨论来看， 数据库系统的技术复杂度最大。 

2、系统的租用与云计算的关系？

Amazon提供的硬盘存储和系统使用，可以算作云计算吗？IBM的VLP（Virtual loan program）与Amazon的服务是类似的吗？它提供的用户界面是什么样的？通过一个工具操纵，还是直接给ftp和telnet？

http://aws.amazon.com提供网上用户存储、操作系统的应用，对客户的价值怎样？必须专业人士使用吗？ 

3、布署管理在整个概念中的比重

目前在无锡的项目中，技术的重点似乎放在了软件的布署和管理，以及强调单一服务器的虚拟化 —— 把一个服务器的计算能力划分成多份，供多个用户使用，而没有提及一个用户的需求大于单一服务器能力的情况（似乎解决不了多服务器并行处理的情况）。 

4、合适的商业模式

云计算模式作为类似NewYorkTimes, Google等网站自身的平台看来没有问题；但是如果类似无锡高新科技园作为平台租用的模式，在商业模式上似乎有问题。 

五、传统的应用如何改造成云计算的应用？ 

将传统的应用系统改造成能够运行在云计算环境中的系统，这在未来是一个有潜力的技术咨询服务。要探讨这个问题，我们需要从云计算的系统和应用的几个主要的层面入手： 

1、分布式文件系统 

2、数据库服务器 

3、应用软件、应用服务器 

4、Web服务器 

5、系统接入 

6、软件的配置、布署、迁移和管理