精品IT課件GOOGLE云计算原理之分布式文件系统GFS.pptVIP

GFS有什么问题吗？ * 欢迎使用 《云计算》教材 电子工业出版社 刘鹏 主编 本讲到此结束 * * * GFS：安全 云计算I3安全问题，身份、基础设施、信息（隐私） * * 电子工业出版社 刘鹏主编《云计算》教材配套课件2 分布式文件系统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的架构有什么问题吗？ * 分布式系统设计告诉我们： 这是单点故障 这是性能瓶颈 GFS的解决办法 单点故障问题 采用多个（如3个）影子Master节点进行热备，一旦主节点损坏，立刻选举一个新的主节点服务 * GFS的解决办法 性能瓶颈问题 尽可能减少数据存取中Master的参与程度 不使用Master读取数据，仅用于保存元数据 客户端缓存元数据 采用大尺寸的数据块（64M） 数据修改顺序交由Primary Chunk Server完成 Simple, and good enough! * 存储元数据 文件系统目录管理与加锁 与ChunkServer进行周期性通信 发送指令，搜集状态，跟踪数据块的完好性 数据块创建、复制及负载均衡 对ChunkServer的空间使用和访问速度进行负载均衡，平滑数据存储和访问请求的负载 对数据块进行复制、分散到ChunkServer上 一旦数据块冗余数小于最低数，就发起复制操作 * 垃圾回收 在日志中记录删除操作，并将文件改名隐藏 缓慢地回收隐藏文件 与传统文件删除相比更简单、更安全 陈旧数据块删除 探测陈旧的数据块，并删除 * 采用中心服务器模式 可以方便地增加Chunk Server Master掌握系统内所有Chunk Server的情况，方便进行负载均衡 不存在元数据的一致性问题 * 不缓存数据 GFS的文件操作大部分是流式读写，不存在大量的重复读写，使用Cache对性能提高不大 Chunk Server上的数据存取使用本地文件系统，如果某个Chunk读取频繁，文件系统具有Cache 从可行性看，Cache与实际数据的一致性维护也极其复杂 ? * 在用户态下实现 直接利用Chunk Server的文件系统存取Chunk，实现简单 用户态应用调试较为简单，利于开发 用户态的GFS不会影响Chunk Server的稳定性 提供专用的访问接口 未提供标准的POSIX访问接口 降低GFS的实现复杂度 * GFS的容错机制 Chunk Server容错 每个Chunk有多个存储副本（