分类： 服务器与存储
2008-12-18 15:48:20
为了测试这些云计算服务，我试用了几天，还部署了几个网站。我在四家云计算服务提供商开设了帐户，配置了几个虚拟服务器，几小时后就可以让网页动起来。我们选择四家提供商并非恪守极其严谨的标准，因为有许多新的服务在冒出来；我选择了向项知名服务以及几项新的服务。
让人吃惊的第一件事就是，这些服务其实有很大相同。虽然Web主机托管的许多方面相当标准化，但“云计算”的定义大不一样。亚马逊的弹性计算云（EC2）为你提供了完整的Linux机，享有根访问权；还让你有机会运行想要运行的任何应用程序。谷歌的应用引擎（App Engine）也让你可以运行想要运行的任何程序――只要你指定程序用于功能有限的Python语言环境，并且使用谷歌的数据库。
这些服务提供的指导程度大不一样，而且针对不同的层面。如果这种帮助很实际、也满足你的需要，这些服务似乎可以让你如愿以偿。不然，你只想把它叫作“枷锁计算”，而不是云计算。每项特性和功能通过让你无法使用有些参数选项来简化工作负担，这样就只好使用一组例行程序，你可能但未必喜欢。
用了几小时后，裹在云计算外面的虚幻光环开始渐渐褪去；很显然，云计算几乎与共享服务器没什么区别。没错，一旦有需要，这些服务让你可以从云计算环境获取更多的CPU周期，可是它们解决不了最深层的问题，这些问题使得应用程序很难轻松扩展。许多真正的挑战在于架构层面，单单用更多的服务器周期来“灭火”解决不了设计中的根本性错误。
我在测试结束后发现，云计算似乎是让人激动的方案，大有发展潜力；不过它们与传统的Web共享主机托管相比绝不是稳操胜券。云计算让一些工作更简单了，不过似乎仍是在不断完善的试验品。
亚马逊的弹性计算云
亚马逊是最先向普通大众推出云计算产品的公司之一，它仍然拥有最复杂、最先进的一套方案。如果你需要CPU周期，就可以使用弹性计算云（EC2）来启动虚拟机。如果你需要存储数据，可以把容量多达5GB的对象存放在亚马逊的简单存储服务（S3）。亚马逊还在S3上面构建了一个有限的数据库，不过我没有进行测试，因为它仍在封闭测试当中。最后一点是，你的机器可借助传递消息的应用编程接口（API）：简单队列服务（SQS）来进行彼此联系。
所有这些服务都向Web开放，并且可以作为Web服务来访问。有一个简单数据库（SimpleDB）的演示版，它其实就是一堆HTML代码在你的浏览器里面运行，同时又能查询远程脑萍扑慊肪场１嘈吹奈牡的谌菹枋担?锹硌纷龅搅巳娩?兰把∮醚∠畋冉先菀住?/p>
不过这种容易也是相对的，因为不管你做什么事，几乎都需要命令行。亚马逊开发了一套出色的工具，这些工具拥有复杂的安全选项，以便向云计算环境的一群机器发出订购指令，但它们都是在命令行界面上运行的。我发现自己经常从说明文档把命令剪切粘贴过来，因为一不小心就会出现误操作，比如输错一些证书的文件名。
Unix用户在这种环境下会得心应手，因为供你随意支配的虚拟机都是各种版本的Linux发行版，就像Fedora Core 4那样。你随手创建一个虚拟机后，就能安装自己的软件，创建自定义实例；如果云计算环境还有可用空间，可以比较迅速地装入这个实例。
很难进一步详细介绍这里讨论的所有云计算服务，而要介绍亚马逊是最困难的，因为它拥有最全面的解决方案。亚马逊完全致力于云计算模式，它在重新考虑如何设计这些系统、开发一些创新的工具。
谷歌的应用引擎
谷歌的应用引擎（App Engine）与亚马逊的服务截然相反。虽然你可以获得亚马逊上的根特权，却无法使用谷歌的应用引擎把文件写入到你自己的目录。实际上，你有没有自己的目录都不清楚，不过你可能没有目录。谷歌去掉了Python环境的文件写入特性，大概是为了避免安全漏洞起见。如果你想保存数据，必须使用谷歌的数据库。
这种种限制带来的结果未必是桩坏事。谷歌对Web应用程序作了精简处理，只剩下一系列核心特性，并且为开发Web应用程序提供了相当好的框架。我只用几百行Python代码，就编写出了一个简单的应用程序（从谷歌的说明文档把代码剪切粘贴过来），前后用了不到一个小时。谷歌还提供了一些不错的工具，可用来对你自己机器上的应用程序进行调试。
把这个应用程序部署到云计算环境原本只需要几秒钟，但由于谷歌非要我提供手机号码、等测试手机号码的文本消息返回，所以一来二去延误了时间。我重试之后，好几个小时都没有收到返回消息，于是换成了朋友的手机号码，总算激活了自己的帐户。
谷歌坚持要求把你的应用引擎帐户与你的手机和Gmail帐户联系起来，我不知道为什么要这样。大概是为了方便查明网络诈骗犯、垃圾邮件发送者、域欺骗者、网络钓鱼者及其他骗子的下落，但这样一来感觉有点缓慢。
最适合使用应用引擎的将是用户群，或者极可能是单个的开发人员，他们希望在用户和数据库之间编写薄薄的一层Python代码。API适合处理这项任务。将来，谷歌可能会添加更多的特性，用于后台处理以及轻量级存储等其他服务；不过眼下，这项服务的主要强项就是这些。
GoGrid
GoGrid自称是“世界上第一个多服务器控制面板”。GoGrid的服务在功能上与亚马逊的EC2没什么不同，但使用“控制面板”这个老术语似乎比“云”这个较新潮的词语更准确地描述了其实质。你可以启动及关闭负载均衡软件，就像Plesk和cPanel这些比较老的工具让你可以添加及删减服务那样。
虽然GoGrid提供了与亚马逊的EC2同样的许多服务，但基于Web的控制面板用起来要比EC2命令行简单得多。你只要点击鼠标；不需要剪切粘贴什么东西，因为小小的弹出方框就能为你指路，比如列出可用的IP地址。这个系统界面直观，只要几分钟就能完成网络构建。界面左边的简单分类账可以跟踪各项成本，有助于管理预算。
GoGrid还有种类更丰富、可随时使用的操作系统镜像文件（image）。有一批常见的CentOS/Fedora以及常用的LAMP镜像文件。如果你需要Windows，就能获得随带IIS 6.0的Windows Server 2003；但微软SQL Server需要另外付费才能获得。还有Ruby on Rails、PostgreSQL和Facebook应用服务器的镜像文件。这样一来，启动过程要简单一点。
尽管GoGrid提供了与亚马逊的EC2同样的许多特性，但它并不提供更多类似云计算的服务，无法像SimpleDB那样以一种共享方式来存储信息。这样一来，服务器的启动及关闭来得困难一点。服务的启动注释（startup note）指出，想不再为服务器破费，惟一的办法就是把它删除。而这意味着就会丢失服务器上面的所有数据。
目前没有什么简单的办法来构建自定义镜像文件，不过说明文档上声称GoGrid在研究一种方法，可以把任何运行中的服务器转变成稍后可以重启的镜像文件。如果你希望根据流量的增减能够相应扩大或者缩小网络规模，就得自行开发一些工具以便添加及删减这些服务器。
AppNexus
如果你喜欢云计算这个概念，但无法肯定自己要不要丢弃Unix、计时任务及其他工具这些传统而可靠的环境，那么AppNexus正是旨在提高一点透明度的服务。这家公司采用了大型的工业级服务器集群，拥有最出色的负载分担工具和存储设备；它还想出了一种办法让你可以小批量购买其服务。AppNexus提供了许多命令行抽象工具，让你可以启动及关闭服务器；不过它们还让你可以深入分析文件系统。
AppNexus云计算服务的主要功能类似亚马逊的EC2。你可以通过命令行登录进去，启动Linux发行版的镜像文件。AppNexus声称它可以从亚马逊的EC2等其他来源重新构建镜像文件，只要用更能知道在虚拟环境下运行的版本来取代内核。然后，只要在命令行上输入几个键，即可创建负载均衡软件。
在云计算领域有一个悬而未决的问题，抽象层出现在何处？也就是说，机器之间的厚厚墙壁在何处变得模糊起来、一切开始有点像是在云中？亚马逊的SimpleDB把存储隐藏在软件这堵墙壁后面，让你可以通过调用某个Web服务来访问。AppNexus工作在比较低的层面：把一批Isilon IQ X-Series存储集群构建到云计算环境中。
这样你可以选择仅仅安装存储系统、共享服务器集群之间的数据――如果你觉得这很简单的话。你可以使用真实的文件名作为密钥，而不是使用抽象密钥。集群会处理其余工作。
一种更好的办法就是使用AppNexus所说的内容分发网络（CDN）。存储集群里面建有自己的一套HTTP服务器，你可以从自己的文件开始自动提供静态数据。只要把文件写入到/cdn目录，文件就可以使用了。AppNexus会把这个存储云分布到多个数据中心，那样就比较容易从最近的那个数据中心来提供静态数据了。
条款内容
想让人彻底抓狂吗？有一个办法就是让他去读这些云计算服务的条款。起草传统托管合同的人可能会觉得数据应当是这样：驻留在某个地区的某台服务器上，而服务器放在某人拥有的某个设备上；可是到了云计算环境，结果就很难料了。问题的关键是，数据不是局限在某一个设备、某一幢大楼、甚至某一个国家。
有些服务协议的内容非常具体、清楚。比方说，GoGrid为六大洲的用户明确规定了时延、抖动和数据包丢失等标准值方面的数字阈值。如果云计算服务没有达到这些阈值，GoGrid承诺会返回100倍于丢失服务的服务点数。
其他条款内容则是有意含糊。亚马逊声称有权“以任何原因”、而且“随时”注销用户的帐户，你可能会觉得这非常霸道；不过这家公司也谨慎地保留了绝不会“无缘无故”注册用户帐户的权利。
谷歌的条款内容似乎显得比较宽松，声称只有用户违反了协议条款或者做了什么违法的事情，它才会注销帐户。不过谷歌确实保留了“预审、评审、标注、过滤、修改、拒绝或者删除服务当中任何或者所有内容”的权利。用户确实很被动：一旦谷歌改动了条款，你想想继续使用服务，只能接受修改后的条款。
如果你认为：要是服务器在一个地方、用户在另一个地方，很难从法律规定中理清头绪，那么如果你的虚拟服务器可能在包括的多个数据中心分布在世界各地的云计算环境里面迁移，更难搞清楚结果了。比方说，亚马逊的条款禁止你发布“种族、性、宗教、国籍、残障、性取向或者年龄等方面存在歧视”的内容。似乎是亚马逊担心云计算环境的一部分可能分布在禁止这些内容的地区。
揭开云计算的面纱
法律方面的担忧只是不太确定的细节当中的一部分。最大的困难之一还在于解读云计算的本质。虽然基本上可以这么说：云计算服务是组建机器网络的一种非常灵活的方法，但它们远远谈不上完美。要是服务器或者硬盘正在操作当中出现崩溃，会发生什么后果？这常常跟普通的服务器停机后出现的结果一样：你的数据可能消失，不过也可能不会消失。
来自亚马逊EC2的机器上的实例看上去就与平常的机器无异，因为你在拨开云雾后会发现，这其实是在芯片上运行的另一个版本的Linux，芯片可能会说8080机器码，还可以把数据写入到旋转磁盘上。如果你把什么东西写入到Unix文件系统的普通文件，云计算环境就起不到保护作用。一旦机器崩溃，里面的内容就会消失。如果你发现流量较低、就关闭服务器来节省部分费用，那也没戏。这意味着你其实无法向上或者向下扩展，而且缺乏明智的迁移数据计划。
换句话说，MySQL在云计算环境中运行如同在普通服务器上运行。除非你启动了好几个实例，并且彼此镜像复制，否则上面的所有数据都很容易丢失。尽管云计算具有独特魅力，还是摆脱不了这个基本规则。
如果你希望出现崩溃后仍能得以幸免，就一定要把数据放在云计算环境中的数据存储区（data store）。这些是很不错的服务，不过费用也不便宜。我有位朋友过去把磁盘上的数据备份到了亚马逊的S3上，后来每个月开始收到200美元以上的账单。于是他赶紧买来了一只移动硬盘，放在桌上。
因为服务级别比较高，费用自然比较高昂。亚马逊希望人们能够信任数据存储区，而这意味着提供让银行能够满意的服务级别。共享服务器之间的数据需要时间、认真编写代码。谷歌提醒用户把数据写入到其数据存储区要小心，因为这可能需要破费。如果你喜欢保留大批的日志文件、以防不测，那么把它们保存在云计算环境中所需的费用可能要比保存在普通公文柜中高得多。只可惜，谷歌不提供普通公文柜。
比较难搞清楚的一个细节就是如何弄明白价格。比方说，GoGrid老爱称其基于英特尔至强处理器的服务器功能要比竞争对手来得强大。谷歌甚至本身不出售服务器时间，而是根据CPU兆周期向用户收费。亚马逊的EC2既使用普通大小的机器；也使用更庞大的机器，价格自然要贵一点。如果服务器成本变低，这些公司常常也会调低服务费。不过如果提供的服务实际费用要高于当初预料的，它们也会提高服务费。这种复杂情况会让用户困惑好久，因为很难知道最后哪些因素会影响成本。Sun公司的服务器设备可能无法向上及向下扩展，但费用不会随着网站上的每次访问而变化。
孰优孰劣
试用了这些系统后，我想弄清楚这些云计算服务最适合哪些应用、最不适合哪些应用。最适合的应用之一也许就是像演唱会这些周末活动的某种预订系统。虽然在任何时间段都会有少量负载，但高峰流量常常会出现在每周五的下午，这时候人们可能认识到周末还没有安排什么活动。云计算能够启动更多的服务器以处理这种需求，所以非常适合这种应用。服务可能还会事先接受实际预订、出售门票，这项服务就需要共享数据存储区提供的服务具有比较高的质量。
最不适合的应用也许就是RedSoxYankeesTrashTalk.com或者上面在打口水仗的任何网站。虽然比赛前后流量可能会出现小高峰，但诸如此类的网站其流量会越来越大，哪怕是在非赛季的深夜。
此外，也没有理由需要花钱购买高质量的存储服务，因为我确信许多人对自己在网上的垃圾留言并不在乎，没必要保存下来。
当然，这些例子并不完美，但没有一个是云计算。几周下来通过构建一些机器，另外听到用过云计算服务的人的想法后，我产生了各种各样的问题：这些云计算环境会大得足以处理周末网络大堵塞吗？云计算开发团队能不能找到一种办法，提供对低级数据操作员和高级数据操作员来说价格都很适中的简单方案？他们会找到衡量计算时间的一种有效尺度标准吗？也许只有生活在天空上的人才知道上述这些问题的答案。
