google云计算体系架构教程.pptx

Google云计算原理;2;3;4;5 ;6;7;亚马逊IaaS应用案例：纽约时报;9;10;11; Google云计算平台技术架构 分布式文件系统 Google Distributed File System 并行数据处理 MapReduce 分布式锁 Chubby 结构化数据表 BigTable;13;14;15;16;17;GFS设计原则： 机器失效不能视为异常现象 能应付对大型/超大型文件处理 支持大量用户同时访问 GFS组成 GFS集群:一个的Master和多个ChunkServer（块服务器）组成，并可以多客户端Client访问 GFS设计要点 每个文件拆成若干个64M文件块Chunk组成 每个Chunk都由Master根据其创建时间指定Chunk Handle(64) 文件块被保存在ChunkServer本地磁盘中 缺省情况下3处热备份Chunk块文件 ;Client职责 包含文件系统的API 负责和ChunkServer和Master通信 代表应用程序进行读写操作 Client和Master进行元数据操作 Client和ChunkServer进行文件数据操作 Master职责 负责管理所有文件系统的元数据 元数据包括：命名空间，访问控制信息，文件到Chunk的映射信息等 ChunkServer职责 负责存储chunk文件块 Linux文件系统 ;20;21;采用中心服务器模式Master 可以方便地增加Chunk Server Master掌握系统内所有Chunk Server的情况，方便进行负载均衡 不存在元数据的一致性问题 不缓存数据 必要性：Client流式读取，非重复读写 可行性：Master本身管理多个Server，很复杂 ;Chunk Server容错 每个Chunk有多个存储副本（默认是3个），分别存储于不通的服务器上 每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本） Master容错 三类元数据：命名空间（目录结构）、Chunk与文件名的映射以及Chunk副本的位置信息 前两类通过日志提供容错，Chunk副本信息存储于其它Chunk Server。这样Master出现故障时可恢复 ;;25;摩尔定律正在走向终结… 单芯片容纳晶体管的增加，对制造工艺提出要求 CPU制造18nm技术，电子泄漏问题 CPU主频已达3GHz时代，难以继续提高 散热问题（发热太大，且难以驱散） 功耗太高 ;27;Google拥有海量数据，并且需要快速处理 什么是MapReduce？ ;29;30;31;32;33;34;背景 MapReduce设计初衷：由普通PC组成的集群来处理超大规模的数据，所以有效的错误保障机制是必不可少 Worker容错 Master周期性的ping每个worker Master容错 Master周期性的将Master的数据结构的写入磁盘，即检查点（checkpoint） Master数据结构包括: Map和Reduce任务的状态（空闲、工作中或完成)，以及Worker机器(非空闲任务的机器)的标识。 ;36;37;38;39;40;云计算的出现并快速发展，一方面是虚拟化技术、分布式计算等技术发展的结果， 另一方面也是互联网应用不断丰富趋势的体现。目前，虽然有Amazon、Google、IBM、Microsoft等在推，但云计算还没有一个统一的标准。 云计算平台已经为很多用户所使用， 但是云计算在行业标准、数据安全、服务质量、应用软件等方面也面临着各种问题，这些问题的解决需要技术的进一步发展。 现有的研究大多集中于云体系结构、云存储、云数据管理、虚拟化、云安全、编程模型等技术;42;主要内容（）;Google的云计算;;GFS的容错机制 Chunk Server容错 每个Chunk有多个存储副本（通常是3个），分别存储于不通的服务器上 每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本） Master容错（影子节点热备） 三类元数据：命名空间（目录结构）、Chunk与文件名的映射以及Chunk副本的位置信息 前两类通过日志提供容错，Chunk副本信息存储于Chunk Server，Master出现故障时可恢复 ;;MapReduce处理流程中各类文件的存储位置在哪里？ MapReduce的容错方法？ MapReduce的处理优化方法？ MapReduce仅能对GFS之上的文件进行处理吗？;所有步骤均可控，可灵活处理各类分布式问题;除了排序，新增两道题目 使用MapReduce实现倒排