亚马逊云计算AWS介绍.ppt

EC2的基本架构 EC2应用实战 注册用户，选择支付方式 使用EC2的几个前提条件 Java Runtime Environment Amazon EC2 command-line tools PuTTY & PuTTYgen 配置工具 运行实例 简单存储服务S3 S3（Simple Store Service）的设计思路 数据一致性模型 S3的设计思路(1) S3为任意类型的文件提供临时或永久的存储服务 非传统关系数据库存储模式 ——简单、高效 ——存储、读取，非查询 S3的设计思路(2) 基本概念 ——对象：S3的基本存储单元（数据、元数据），数据类型任意 ——键：对象的唯一标识符 ——桶：存储对象的容器（不能嵌套、在S3中名称唯一、每个用户最多创建100个桶） S3的设计思路(3) 　　Jeff Barr认为，云计算是分层次和类别的，每一类公司提供的云计算的服务都不一样，亚马逊是IT基础架构云计算服务提供商。在网络互联的需求之上，直接就是亚马逊的最底层的IT基础架构AWS(Amazon Web Services)，包括计算、存储、内容分发等；在AWS的基础上，用户才可以构建自己的应用层，这些应用层包括构建数据库、应用服务器；最上一层才是应用软件。他表示，目前市场上很多云计算服务提供商所提供的服务，仅仅是不同层面的一部分解决方案。 * 完成数据迁移后，由于不需再考虑基础设施问题，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+R>N时读写总会有交集——必定最少有W＋R－N个读请求会落到被写的副本上，所以必然会读到“最后”被更新的副本数据（至于谁“最后”的判断需采用时间戳或者时钟向量等技术完成——有逻辑关系先后由时钟向量判断，否则简单的用时间戳先后判断.详情去看dynamo论文吧）。这种做法相比我们最朴素的想法——我们直观的想法一定认为如果系统要求记录冗余N份，那么每次就写入N份，而在读请求时读取任意一份可用记录即可——要更安全，也更灵活。说其更安全是指数据一致性更能被保证：比如说客户写入一条记录，该记录有三个副本在三个不同点上，但是其中一个点临时故障了，因此记录没有被写入／更新。那么在对该记录再读取时，如果取两点（R=2）则必然会读取到最少一个正确的值（临时故障点有可能在读是恢复，那么读出的值则不存在或者不是最新的；若临时故障点还未恢复，则读请求无法访问其上副本）。而使用我们传统方法可能读到发生临时故障的那点，此刻就有可能读出现错误记录（旧的或者不存在），因此可以看到加大W,R可提高系统安全性；说其更灵活则是指可通过配置N,W,R这几个参数以满足包括访问方式、速度和数据安全等迥异需求的各种场景：比如对于写多读少的操作，可将W配低，R配高；想法对于写少读多的操作，则可将W配高，R配低 * Dynamo中的每个节点就是Dynamo的一个成员，亚马逊为了使系统间数据的转发更加迅速（减少数据传送时延，增加响应速度），规定每个成员节点都要保存其他节点的路由信息。由于机器或人为的因素，系统中成员的加入或撤离时常发生。为了保证每个节点保存的都是Dynamo中最新的成员信息，所有节点每隔固定时间（1秒）就要利用一种类似于gossip