云计算[刘鹏][电子教案]-2 Google云计算原理精选.ppt

超过50个GFS集群 每个集群包含数千个存储节点 管理着PB(1015Byte)级的数据 巨型、廉价、稳定的数据中心 * 简单的，就是最好的！ * GFS有什么问题吗？ * 欢迎访问 中国云计算网站 欢迎使用 《云计算》教材 电子工业出版社 刘鹏 主编 本讲到此结束 * * 　　1、“技术触发期(Technology Trigger)”：新技术产生之初，被业界和媒体广泛关注，曝光率直线上升； 　　2、“期望膨胀期(Peak of Inflated Expectations)”：概念炒做达到顶峰，媒体对新技术产生了大量不切实际的期望； 　　3、“幻觉幻灭期(Trough of Disillusionment)”：泡沫破灭，媒体态度骤变，从原先的新技术支持者变成声讨者，概念逐渐被人淡忘； 　　4、“启蒙复苏期(Slope of Enlightenment)”：虽然该技术已经很少被曝光，但在并未在业界完全消失，不少企业在慢慢推动该技术走向成熟，技术本身的优势和局限也逐渐为人所了解； 　　5、“生产力成熟期(Plateau of Productivity)”：已经达到成熟期的新技术找到了自己的市场定位，虽然不像原先媒体期望的那样具有颠覆性，但却实实在在地改变着人们的生活。 * * * * GFS：安全 云计算I3安全问题，身份、基础设施、信息（隐私） * “浏览器＝操作系统” * * Google在线文档 * Google地图 * Google邮件 * Google日历 * Google Wave 信息分享、协作、发布平台 * 隶属于PaaS的Google云计算 属于部署在云端的应用执行环境 支持Python和Java两种语言 通过SDK提供Google的各种服务，如图形、MAIL和数据存储等 用户可快速、廉价（可免费使用限定的流量和存储）地部署自己开发的应用（如创新的网站、游戏等） * 应用场景特点 应用（功能实现）在云端 存储在云端 计算在云端 * Google云计算平台技术架构 文件存储，Google Distributed File System，GFS 并行数据处理MapReduce 分布式锁Chubby 结构化数据表BigTable Google云计算应用 MapReduce BigTable GFS Chubby * 分布式文件系统GFS Google Distributed File System * 什么是文件系统？ FAT, FAT32, NTFS, EXT, …… 用于持久地存储数据的系统 通常覆盖在底层的物理存储介质上 硬盘、CD、磁带等 数据组织的基本单元：文件 具有文件名（1.txt） 通常支持层次化嵌套（目录结构） * 文件路径 文件与目录的结合，用于定位文件 绝对路径，/home/aaron/foo.txt 相对路径，docs/someFile.doc 规范路径 定位文件的最短绝对路径 /home/aaron/foo.txt, /home/../home/aaron/./foo.txt 所有规范路径的集合构成了文件系统的目录结构 * 文件系统的存储内容 主要内容：用户的实际数据 元数据：驱动器元数据与文件元数据 * 文件分块存储 * 文件系统设计的考虑因素 最小存储单元 较小可减少浪费空间，较大则可提高文件顺序读取速度（随机访问呢？） 文件系统的设计目标是提高访问速度还是提高使用率？ 文件系统的安全性 多用户环境下的文件安全 读/写权限分配 文件附带访问控制列表（ACL） 文件系统缓存 提高文件系统读写效率 * Google需要一个支持海量存储的文件系统 购置昂贵的分布式文件系统与硬件？ 是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？ * 为什么不使用当时现存的文件系统？ Google所面临的问题与众不同 不同的工作负载，不同的设计优先级（廉价、不可靠的硬件） 需要设计与Google应用和负载相符的文件系统 * 硬件出错是正常而非异常 系统应当由大量廉价、易损的硬件组成 必须保持文件系统整体的可靠性 主要负载是流数据读写 主要用于程序处理批量数据，而非与用户的交互或随机读写 数据写主要是“追加写”，“插入写”非常少 需要存储大尺寸的文件 存储的文件尺寸可能是GB或TB量级，而且应当能支持存储成千上万的大尺寸文件 * 将文件划分为若干块（Chunk）存储 每个块固定大小（64M） 通过冗余来提高可靠性 每个数据块至少在3个数据块服务器上冗余 数据块损坏概率？ 通过单个master来协调数据访问、元数据存储 结构简单，容易保持元数据一致性 无缓存 Why? * 单一Master, 若干ChunkServer 1、文件存储方式 2、数据读写流程 GFS的架构有什么问