云计算的魅力在于用户只要有身份证和信用卡就可以开始使用，但这也是问题所在。这么简单的服务势必会给毫无准备的IT部门带来许多挑战。之前我们已经多次碰到过这个现象：某项技术易于采用的优点到头来却变成了意料之外的管理难题，比如虚拟化技术导致虚拟机散乱，智能电话带来新的安全风险，即时通讯引发公司治理方面的问题。

作者旨在向IT经理们介绍如何最大限度地发挥云计算的优点，包括使用简单、灵活和较低成本；同时最大限度地减小风险。这篇实用指南包括了许可、管理工具、带宽、安全和架构等方面的内容。

本文表明我们仍处于云计算的早期阶段，这意味着，相关工具和技术还在不断完善中。比方说，经过长达两年的测试后，亚马逊网络服务公司的弹性计算云（Elastic Compute Cloud）服务在去年底才推向市场；监测、管理和负载平衡等企业级功能仍在其规划当中。同样，谷歌应用引擎（App Engine）属于预览版本。微软的Azure云服务也属于预览版本，目前只有Windows开发人员可以使用有限的功能，其他早期采用者无法使用。

不过现在可以开始规划了，你既可以实际感受这种新的IT交付模式（包括了解各种故障和缺陷），又可以比其他在考虑独自利用云服务的公司同事超前一步。

一、管理篇

牢牢控制云计算

管理云计算服务的工具形形色色，既可以使用简单的仪表板，让你在几分钟内就能创建虚拟软件栈；也有能够处理各种配置和管理任务的企业级平台。云计算使用越广泛，就越需要那些高端工具。

亚马逊、谷歌及其他云服务提供商提供了帮助客户入手的基本工具。比方说，谷歌应用引擎的管理控制台可以显示流量大小、带宽、CPU利用率以及谷歌托管应用程序的出错率，这些数据可以帮助你深入研究日志文件，并获得其他详细数据，还可以用它来控制管理权限、管理应用程序的升级。

然而，应用引擎仍属于“预览”版本；这意味着，随着需求越来越高，这些工具将无力满足要求。谷歌的产品经理Pete Koomen承认：“我们还缺少一部分功能。”

我们看到，云服务提供商、新兴公司和系统管理厂商都在竞相为客户提供功能更齐全的工具，以管理云环境中的资源。亚马逊表示，它会“很快”为弹性计算云服务推出新的管理控制台和云监测功能。亚马逊已经在提供一些基本功能，比如使用命令行界面创建亚马逊机器映像（Amazon Machine Images）的功能。管理控制台让用户可以配置及管理EC2资源，而监测功能将包含EC2实例和 “可用区域”（availability zones）方面的实时度量――可用区域是客户为了确保冗余和最高可用性而选择的亚马逊基础架构中的一部分。亚马逊还计划在2009年提供负载均衡和自动扩展功能。

专门从事云管理的公司是另一个选择。RightScale公司的托管服务平台包括管理仪表板、数据库和网站管理、批处理、多服务器部署功能以及自动扩展功能。提供基本功能的开发版本可免费使用，但大多数IT部门会需要RightScale的另外三个版本（网站版、网格版和高级版），这些版本的起价为每月500美元，外加2500美元的一次性费用。

RightScale创办于2007年，以管理亚马逊网络服务起家；如今扩大了业务范围，可以管理其他公共云服务，包括FlexiScale和GoGrid的云服务。RightScale还为加州大学圣巴巴拉分校的Eucalyptus公共云提供了一个平台， 把面向云计算的开源Eucalyptus软件部署在集群服务器上。它实际上是一个研究测试项目，但目的是通过RightScale的仪表板，能够管理公共云和基于Eucalyptus的专有云。

与Web应用程序一样简单

在管理Web应用程序和基础架构方面有过经验的IT部门会发现，云计算有着相似之处。Hyperic公司首席执行官Javier Soltero说：“如果你能管理Web应用程序，就能管理云应用程序。”该公司有一个版本的Web应用程序监测软件正在亚马逊网络服务中运行。

Hyperic HQ由中央管理服务器和代理软件组成，前者通常在公司内部部署的服务器上运行，而后者驻留在Web服务器上，向中央管理服务器报告可用性、性能及其他度量数据。借助刚发布的HQ 4.0，Hyperic服务器可以配置成EC2中的亚马逊机器映像。对IT管理员而言，这意味着部署简单、订购费较低、性能更高。Hyperic HQ的功能包括自动发现软件、诊断、报警、分析和报告以及其他工具。

有人认为，对云应用程序“眼不见心不烦”，这种态度大有问题。Soltero说：“有人认为，因为你在云中部署了应用程序，所以根本不需要监测和管理，这是云计算方面的天大谎言之一。代码天生有缺陷，技术也会出问题，所以你需要监测功能。”

Kaavo公司也专门从事多个云的管理。这家新兴公司的平台支持服务器监测、云中的LAMP软件配置、负荷管理、软件审计、补丁管理、运行时配置管理、通知及报警。它已推出按需基础架构和中间件（Infrastructure and Middleware On Demand）软件的免费测试版；很快会推出普通发行版。Kaavo的优势在于其管理团队：创办人兼首席执行官Jamal Mazhar是获得Sun认证的J2EE架构师，首席技术官Shahzad Pervez以前在大公司担任过IT主管和企业架构师。

知名的系统管理软件厂商也为云环境带来了新的控制工具。IBM公司自主计算开发主管Dennis Quan表示，IBM的Tivoli部门计划把云管理功能集成到服务请求管理器（Service Request Manager）、配置管理器（Provisioning Manager）和监测（Monitoring）等产品线中。IBM还希望为客户赋予更大的“控制权”，控制把数据放在云中的系统，从而提升客户对云安全的信心，但Quan没有透露IBM在这方面会如何做到。

微软仍在开发解决云管理难题的方案。它在去年10月推出了Windows Azure操作系统及相关的Azure服务平台，但没有表明何时启用Azure云服务，不过开发人员已可以使用开发工具和基本构建模块入手。微软高级副总裁Bob Muglia在同一个月演示了代号为Atlanta的系统中心（System Center）企业管理平台，该平台将在微软的云中运行。

所有这些活动表明，众厂商在竞相为新兴的云服务开发企业级控制工具。IT管理员面临的难题是，在云服务采用突飞猛进之前，将相关工具部署到位。

二、底层架构：亚马逊、谷歌和微软平台比较

人们很容易忽视云服务背后的技术，这是一个误区。公司的技术人员必须确保云服务与本企业的基础架构相互集成。这就需要一种基础架构能够结合两者。

云计算的各部分与企业数据中心的各部分一样，同样包括诸多编程语言、操作系统、数据库、Web服务器、协议和应用编程接口（API）。关键就是确认哪些云服务真正适合自己内部的系统、应用程序和专长技能。下面比较一下亚马逊的弹性计算云、谷歌应用引擎和Windows Azure三大服务，看看哪个更适合你。

亚马逊的EC2为客户提供了种类丰富的软件选择：Windows Server、OpenSolaris和七个Linux版本；MySQL、SQL Server和Oracle 11g数据库；以及Java、JBoss和Ruby on Rails等开发环境。

谷歌的特长则在于简单易用。应用引擎让用户可以利用谷歌的自主开发数据库及其他基础架构软件；可以通过API使用缓存、镜像、邮件及其他应用服务。Python是惟一得到支持的编程语言，不过谷歌打算在将来也支持其他编程语言。

Windows Azure和Azure服务平台与微软的内部部署企业软件系列其实一脉相承。Azure包括了托管版本的SQL Server、SharePoint、Dynamics CRM和.Net服务，用Visual Studio和.Net框架开发而成。微软表示，Azure将支持开放协议（HTTP、REST、SOAP和XML）以及非微软编程语言（Eclipse、Ruby、PHP和Python）。

如果IT人员要了解云体系结构的概况，云服务提供商的网站上提供了许多详细信息。亚马逊有一份介绍云体系结构的白皮书，想尽快补上一课的人不妨看一下。

你的设计蓝图应当考虑到云服务可能由多家厂商提供，所以要想好该如何确保互操作性和应用集成。云计算新兴公司Elastra的高级软件架构师Stuart Charlton建议采用REST和Atom联合格式（Atom Syndication Format）作为全球云体系架构中的底层规范。他表示，联合身份管理方面的标准也很重要。

IBM公司自主计算开发主管Dennis Quan表示，面向服务的架构（SOA）已经让通过“符合标准的方式”连接云服务成为可能。下一步关键是把服务从一个云迁移到另一个云。Quan表示，完成这项功能的规范仍处在开发初期。

三、数据保护篇

重视安全

开发人员喜欢“云计算部署后不用去管”的功能；公司希望通过云计算降低基础架构成本；用户则喜欢新的功能能够更迅速地推出。

然而，负责信息安全的人员在为如何把应用程序和数据安全地转移到云中而挠头。

IT界孜孜以求的一个目标就是整合身份管理技术和流程；而云计算可能让这个目标晚十年才能实现。

许多公司可能会把目录服务验证扩展到内部环境以外，以处理云中的应用程序、甚至系统；但如果第三方系统的安全受到危及，这种做法会导致验证系统岌岌可危。公司也许可以实施一种新的解决方案，让云基础架构管理与现有的基础架构管理相互独立。但缺点是，必须集成多个身份和访问管理系统。还有一种办法是及时回去、单独管理云，但这缺乏吸引力。

幸好，有些云服务提供商正在竭力解决这个问题。谷歌提供了这项功能：把Google Apps与目前实施的单点登录技术结合起来，从而加强安全、简化管理。一家知名互联网公司部署了边缘验证服务器，让云系统通过轻型目录访问协议（LDAP）进行验证。另一家公司则扩展了基于Web的验证协议，通过Web服务来进行验证；验证通过，即可访问其内部的系统。

数据丢失与备份

数据存储在哪里？谁可以访问？数据安全吗？这些都是重大问题，因为没有几家云服务提供商在处理敏感数据方面证明一向很可靠，许多软件即服务（SaaS）提供商除外。如果数据保存在共享存储系统上，要料到可能面临风险。其实，即使我们放在自己公司内部的数据也面临风险。需要把衡量内部数据效益与风险的同一套措施用于衡量云，然后确定哪些数据可以放到云上、并如何保护。这就需要知道及核实提供商采用的标准以及改动标准的灵活性有多大。

企业使用亚马逊的弹性计算云等服务时，可以在虚拟实例中运行的操作系统、应用程序或数据库管理系统里面采用数据加密。其他服务（如应用托管服务）提供商在开发应用程序时需要更全面的考虑，确保已包括加密等安全措施。

不管自己的数据在哪里，公司都应当防范数据丢失。亚马逊知道计算机会出故障，所以它劝告公司要借助冗余和备份措施作好防范故障的规划。有些云服务提供商提供备份服务或者导出数据的方法，那样公司可以自己备份数据，另一些提供商要求客户使用自定义或第三方的应用程序。

因此，我们不妨牢记下面这些关键因素：

——备份如何进行？有些云服务提供商进行备份，不过更有可能是你想自己进行备份。亚马逊EC2的许多客户还使用亚马逊的简单存储服务（Simple Storage Service，S3）或弹性块存储（Elastic Block Storage）用于存储备份文件。

——备份经得住测试吗？如果服务无法使用，你能访问备份数据吗？

——备份数据将放在哪里？它也许放在云存储系统上、由提供商来托管，或者转到你自己的基础架构。不管怎样，你还是要知道备份数据在存储和传输中，数据得到了怎样的保护。

管理与监测

许多公司的信息安全团队平时经常监测安全漏洞邮件列表、给系统打补丁、改写代码以解决缺陷。在云中，他们相信提供商事先至少对一些方面进行了调查。很少有提供商让客户可以核实自己采取的安全做法，不过有些提供商变得更愿意配合。公司在使用Joyent或亚马逊的EC3等云系统时，可以在操作系统、数据库和应用程序等层面采取安全措施，但他们仍依赖各自的提供商确保网络、存储和虚拟基础架构的安全性。

尽管云服务用户并不控制实际的打补丁和漏洞监测工作，但他们仍有责任管理自己的风险。所以他们要评估哪些资产需要保护、如何防护这些资产，包括在云基础架构上添加安全措施。即使那样，支付卡行业（PCI）标准等行业法规仍可能会让人措手不及，因为PCI委员会方面没有明确规定如何对云服务提供商进行分类。这可能意味着，不同审计人员对待云服务提供商的标准会略有不同。

云服务客户必须要求保证自己可监测谁在访问自己的数据。如果公司要求提供详细的审计跟踪记录，应当采用数据加密；或者只把所处理数据不是特别敏感的应用程序交给云服务提供商。

这个方面可能会迅速得到改进。谷歌近期表示，Google Apps的安全流程已通过了SAS 70 Type II审计标准。预计会听到更多的提供商宣称自己的安全标准，因为安全仍是导致公司不敢把应用程序转移到云中的一大障碍因素。

当然，内部信息安全团队不应该坐等提供商来加强安全。从桌面应用程序到服务器托管的各个应用领域，云计算都会变得越来越诱人。需要更高安全级别的应用程序，比如与《健康保险可携性及责任性法案》（HIPAA）或PCI相关的应用程序，可能在云中更难得到保证，因而放在公司内部比较妥当。社区应用程序和内容网站比较适合放在云中。公司的技术团队必须确定把什么数据放在云中不会有问题，但他们也要明白：云最终会是整个基础架构的一部分；还得要自己弄清楚如何把企业系统与云基础架构安全连接起来。

四、网络篇

一家地区银行在试用成功后决定全面使用Salesforce.com服务，但却没有考虑到以后需要更多的带宽。当员工们的互联网连接突然变得慢腾腾时，这家银行为所犯的这个错误付出了代价。

网上传输的数据急剧增长，预示着没有投资于更多带宽的公司会面临带宽危机。但带宽不是惟一潜在的网络问题。数据传输距离长会带来延迟问题；而互联网的稳定性不确定，加上服务提供商的数据中心充满未知因素，更是带来了可靠性问题。

公司只要升级带宽就能缓解其中一些问题。一家医疗公司就把带宽增加了五倍，将后端批事务处理转移到亚马逊网络服务。幸好，带宽价格在不断下跌，但公司仍需要认真规划。

一些技术有助于评估分析流量，比如Packeteer公司的PacketShaper；大多数防火墙厂商允许客户免费试用30天的报告服务，这种服务可以告诉公司使用了多少带宽。网络集成商GreenPages的首席技术官Mike Healey表示，云服务提供商的带宽要求往往不可靠或很难弄到，所以公司至少应当一方面基于试用数据来评估带宽要求。Healey表示，为了准备好应对高峰需求，公司应当规划确保足够带宽，以便自己的带宽利用率平均不超过75%。

冗余的重要性完全不亚于额外带宽。没有作好故障切换方面的规划“是我们见到客户经常犯下的最大错误，”Healey说。多家电信公司在大多数大城市提供最后一英里的互联网接入服务。

另外，即使公司升级了带宽，如果云服务提供商最近的那个数据中心远在千里之外，可能也会出现性能减弱的问题。思科首席技术官办公室的技术主管Glenn Dasmalchi说：“人们只谈论连接和吞吐量，但延迟也很要紧，即使在云中也是如此，因为你面对的是分布式环境，客户们需要彼此联系。”

有些应用程序要求高性能、低延迟，比如用于计算市场风险或把组件结合到组合式应用程序的应用程序。亚马逊在全球各地不但组建数据中心，还组建内容分发网络，一方面就是由于这个原因，之前Akamai或Limelight提供了类似的缓存服务。因此你不妨问问提供商他们是如何减少延迟的。

如果公司需要更高效的带宽用于云计算，还可以使用负载平衡器。一家软件新兴公司把其大部分基础架构：存储、计算和开发环境转移到了云中，并且投资于10条50Mbps Verizon光纤服务（FiOS）线路，使用一个Radware负载平衡器把带宽聚合成一条相当于500Mbps的线路。由于即将出现广域网优化标准以及云环境和内部部署环境之间的数据密集型通信，Dasmalchi预计广域网优化也会在加速云计算提供商、互联网服务提供商（ISP）和云计算用户之间的流量方面起到作用。

云计算在带来一些新的网络难题的同时，也能解决其他网络难题。对转移到云中的应用程序而言，网络管理员有望减少改动内部网络体系架构方面的工作量，因为他们只要确保连接至云服务提供商的数据中心就可以了。

虽然潜在的云服务客户让自己的网络准备好使用这种服务，但也要向云服务提供商询问其网络：谁提供回程链路？连接是否冗余？数据中心建在哪里？Healey说：“最好，你能够看看提供商的网络设计框架。”虽然云服务提供商有义务构建合格的网络，但客户也有必要进行一番准备工作，确保网络稳定可靠。

五、服务合同篇

认真洽谈

说到合同条款，购买云服务与购买套装软件很不一样。如果是最基本的云计算，只要在网上填几张表格，几乎谁都可以订购及使用服务。不过，大多数公司会希望看到一些针对自己要求的比较正规的许可证协议，这时候情况会变得复杂起来。

提供商在云服务和SaaS许可证方面通常采用两种方法：按人数收费或按使用量收费。比方说，微软Exchange在线版的收费标准是每个用户每月10美元。其他提供商按交易的事务量或按交换的数据量收费。亚马逊S3存储服务收费标准是，每存储1GB数据收费12至15美分，在美国每传送1GB数据收费10至17美分。有些提供商结合使用了上述两种方法。

尽管扩展性是云计算的主要优点之一，但公司应当了解这方面有什么限制。Aria Systems为云服务提供商提供计费服务，该公司的首席执行官 Ed Sullivan表示，服务提供商常常根据他们认为的客户支付能力，对最高服务级别加以限制。如果是小公司，可能会限制客户每个月只能使用1万美元的服务。

对于SaaS，提供商们越来越多地销售捆绑服务，包括从基本到高端的各个版本。微软销售Exchange在线版费用较低的“无电脑工作者”（deskless worker）版本，客户可以使用Outlook Web Access的基本版，无法使用Outlook客户软件。还有免费版的Google Apps以及提供一些商业保障的高级版。

与任何技术一样，公司购买的SaaS和云计算服务量越大，在合同和价格方面可能得到的优惠就越多。比方说，如果顾客按照微软企业协议（Enterprise Agreement）批量购买服务，微软提供折扣。如果客户使用更多的S3和EC3，亚马逊会少收费。随着云计算更加流行起来，公司开始下更大的单子，提供商们必须在价格方面体现出灵活性。

明确责任

SaaS和云计算在安全、正常运行时间、性能和稳定性等方面具有一定的不确定性。如果是套装软件，公司内部的IT人员可以自行处理问题。律师Robert Scott为设计许可证条款的提供商和洽谈云服务合同的公司客户同时提供服务；他表示，在云中，公司只能依靠服务提供商来尽量降低风险，这需要在合同中有所明确。

Scott表示，标准条款往往很少涉及与风险有关的许多重要方面。比方说，如果服务出现了危及财务数据的安全问题，按照美国州或联邦法律，提供商可能需要通知客户，否则会吃官司。Scott问道：“那谁为此买单呢？”

云服务洽谈非常像外包协议洽谈，在仔细阅读许可证条款时要想到另一方。公司应确保合同条文明确如果决定不继续使用服务、无力支付费用，或者提供商突然关门大吉时，如何要回数据。客户需要知道如何从服务提供商处获得数据；一旦可以访问数据，如何使用数据。

服务级别协议的复杂和限制

服务级别协议相当于另一块拼图。如果服务停用时间占了当月的一定比例――按服务提供商响应客户的数据请求来衡量，那么大多数云服务提供商会退回一部分费用。凯捷咨询公司的IT产品营销全球主管Warren Ross表示，如果谈妥的服务级别协议要求比较高，这意味着费用不菲，因为如果附以专门的服务级别协议，服务成本变得比较高。

Salesforce.com等大多数提供商在服务级别协议中不包括计划停机，所以如果提供商告诉你这是计划停机，就拿不到退款。SaaS计费与测量新兴公司eVapt的首席执行官Divakar Jandhyala表示，由于往往存在相当长的计划停机时间，所以服务级别协议的价值就打折扣了。

尽管如此，服务级别协议变得更过硬，有些情况下变得更复杂，就像当初Web托管服务进入主流那样。微软的Exchange托管过滤（Exchange Hosted Filtering）服务就有五种服务级别协议：分别针对正常运行时间、反垃圾邮件效果、反病毒效果、延迟和性能。

微软为Exchange在线版和SharePoint在线版提供了多档次服务级别协议。最基本的是承诺99.9%可用性的服务级别协议；如果未达到这个要求，客户每个月可以拿到25%的返额。如果低于99%，客户可拿到50%的返额。要是出现严重停用或病毒爆发，客户可以拿到当月的全额退款。但是许多公司在洽谈服务级别协议时希望将来不用拿退款。如果一家零售商的网站在销售高峰期无法使用，拿到当月费用5%的退款又有什么用呢？

云计算许可证的其他内容应当包括书面确认服务提供商会满足法规要求、保护知识财产。

购买云服务的许可证比使用套装软件既简单，又复杂。云服务购买很方便，许多还附带标准的服务级别协议，提供了相当高的保护级别。但为了确保风险和责任的所有方面都兼顾到，就要随时运用那些洽谈技巧，还得备着律师的电话号码。

提防被厂商锁定

IT人士都很熟悉本公司被专有的编程语言、信息存储方式及其他技术牢牢束缚所带来的后果。

如果存在开放标准，多少可以减少将来迁移成本高、难度大的可能性。但要是几乎没有标准――目前的云计算就是这样，万一有必要换提供商，切换成本就会相当大。

数据是最让人担心的问题之一。内部部署系统对于应用程序如何保存数据、保存在哪里有更大的控制权。而对于基于云的系统，特别是“交钥匙”解决方案，数据模式都是针对特定解决方案的。因为可以从某个云下载数据，所以数据是否会很容易迁移到竞争对手的平台上呢，这是个问题。

源代码可能是另一个问题，尤其是对云中的平台而言。对于实际代码和云中开发的任何表单，是否可以在其他地方重复使用？还是需要改写？Sun的Project Caroline首次亮相时，人们对它期待的功能之一就是可以运行Java代码的可扩展云。虽然没有提到数据保存在哪里，但Java的优点之一就是移植性――不但能移植到内部部署解决方案，还能移植到其他环境，比如在亚马逊弹性计算云中运行的Java应用服务器。

如果使用虚拟化技术，就会出现另一种可能的厂商锁定。如果你的“系统”得到虚拟化的支持，就要认识到不是所有虚拟化技术天生都一样，这点很重要。

许多提供商主张使用虚拟机结合内部部署计算与云计算。比方说，在本地对服务器进行虚拟化处理，然后把它们迁移到云中。但目标云支持你选择的虚拟化技术吗？在这个领域，标准的匮乏已造就了像rPath这些帮助不同平台消除差异的专业公司。

本文要点：文章通过云计算的１、管理篇；２、底层架构：亚马逊、谷歌和微软平台比较；３、数据保护篇；４、网络篇；５、服务合同篇；这五点，旨在向IT经理们介绍如何最大限度地发挥云计算的优点，包括使用简单、灵活和较低成本；同时最大限度地减小风险。这篇实用指南包括了许可、管理工具、带宽、安全和架构等方面的内容。本文表明我们仍处于云计算的早期阶段，这意味着，相关工具和技术还在不断完善中。比方说，经过长达两年的测试后，亚马逊网络服务公司的弹性计算云（Elastic Compute Cloud）服务在去年底才推向市场；监测、管理和负载平衡等企业级功能仍在其规划当中。同样，谷歌应用引擎（App Engine）属于预览版本。微软的Azure云服务也属于预览版本，目前只有Windows开发人员可以使用有限的功能，其他早期采用者无法使用。