Cloud云计算.ppt

* * 完成数据迁移后，由于不需再考虑基础设施问题，SmugMug将公司的主要精力集中在提高服务质量上。目前SmugMug向用户提供了三种照片访问方式[35]： SmugMug以代理的身份处理用户访问请求 SmugMug对用户访问请求进行重定向 利用有关API直接对存储在S3中的数据进行访问。 在这三种访问方式中，以第一种方式访问的用户超过99%。也就是说几乎所有的用户都选择这种访问方式，这也正是SmugMug所期待的结果，因为它希望S3对于普通用户来说是透明的。SmugMug公司还引入了EC2服务，使客户可以利用EC2来完成图片的在线编辑和处理。 将基础设施部分外包给亚马逊后，SmugMug的基础架构如图 4?33所示。几乎所有的用户都是采用直接访问SmugMug的方式处理照片，实际的照片处理过程对于用户是透明的。SmugMug的系统后台则如虚线框所示。主要包括三个部分[37]：队列服务，亚马逊AWS和控制器。目前使用的AWS包括EC2和S3。而队列服务和控制器则由SmugMug提供。SmugMug并没有采用SQS而是建立了自己的队列服务,控制器每隔固定的时间就会自动决定增加还是减少EC2实例。整个SmugMug 的系统具有高度的智能型，绝大部分操作都会自动完成。这也是为什么SmugMug仅用几十人就可以完成如此巨大的工作量。 * * * * Dynamo 的冗余副本读写策略比较有趣，它定义了：N,W,R三个参数。其中N代表系统中每条记录的副本数，W代表每次记录成功写操作需要写入的副本数，R代表每次记录读请求最少需要读取的副本数。只要W+R N就可以保证数据的一致性。因为W+RN时读写总会有交集——必定最少有W＋R－N个读请求会落到被写的副本上，所以必然会读到“最后”被更新的副本数据（至于谁“最后”的判断需采用时间戳或者时钟向量等技术完成——有逻辑关系先后由时钟向量判断，否则简单的用时间戳先后判断.详情去看dynamo论文吧）。这种做法相比我们最朴素的想法——我们直观的想法一定认为如果系统要求记录冗余N份，那么每次就写入N份，而在读请求时读取任意一份可用记录即可——要更安全，也更灵活。说其更安全是指数据一致性更能被保证：比如说客户写入一条记录，该记录有三个副本在三个不同点上，但是其中一个点临时故障了，因此记录没有被写入／更新。那么在对该记录再读取时，如果取两点（R=2）则必然会读取到最少一个正确的值（临时故障点有可能在读是恢复，那么读出的值则不存在或者不是最新的；若临时故障点还未恢复，则读请求无法访问其上副本）。而使用我们传统方法可能读到发生临时故障的那点，此刻就有可能读出现错误记录（旧的或者不存在），因此可以看到加大W,R可提高系统安全性；说其更灵活则是指可通过配置N,W,R这几个参数以满足包括访问方式、速度和数据安全等迥异需求的各种场景：比如对于写多读少的操作，可将W配低，R配高；想法对于写少读多的操作，则可将W配高，R配低 * * Dynamo中的每个节点就是Dynamo的一个成员，亚马逊为了使系统间数据的转发更加迅速（减少数据传送时延，增加响应速度），规定每个成员节点都要保存其他节点的路由信息。由于机器或人为的因素，系统中成员的加入或撤离时常发生。为了保证每个节点保存的都是Dynamo中最新的成员信息，所有节点每隔固定时间（1秒）就要利用一种类似于gossip（闲聊）机制[1]的方式从其他节点中任意选择一个与之进行通信。连接成功的话双方就交换各自保存的包括存储数据情况、路由信息在内的成员信息 * * 想象一个广阔空间充满了服务器系统，所有网路连结在一起。坐在你的单一工作站，你创建一个虚拟机的形象，它定义了一个1.2 GHz主频处理器，1.7GB内存和一个160 GB的硬盘的虚拟机运行Linux，并且预装你特别用来压缩大量待处理数据的软件。你部署他对外服务，并且管理这些服务器。在将来某个时间， 你的数据挖掘操作将获得大量的数据矩阵。你指示服务实例化50部虚拟机，并释放每一个数据矩阵中。在几秒钟内， 50部1.2 GHz主频处理器都将积极处理你的的数据。他们完成后，他们的把结果存放在一个预先指定的储存点，然后消失。 灵活性：EC2允许用户对运行的实例类型、数量自行配置，还可以选择实例运行的地理位置。可以根据用户的需求随时改变实例的使用数量。 低成本：EC2使得企业不必为暂时的业务增长而购买额外的服务器等设备。EC2的服务都是按小时来收费的，而且价格相当合理。 安全性：EC2向用户提供了一整套的安全措施，包括基于密钥对机制的SSH方式访问，可配置的防火墙机制等。同时允许用户对它的应用程序进行监控。 易用性：用户可以根据亚马逊提供的模块自由构建自己的应用程序，同时EC2还会对用户的服务请求自动进行负载平衡。 容错性：