云创存储-任军远_cStor超低功耗云存储系统.ppt

* * * * * * * * * * * * * * * * * * * * * * * * 支持master节点双机镜像 控制流与数据流的分离 Cache机制 支持POSIX接口 支持加入节点动态扩展 支持节点损失实时自适应容错 核心技术 使用主备双节点方式解决单节点故障问题 主备切换时间短，且无数据丢失 数据访问不间断，而且性能不受影响 支持master节点双机镜像 解决了master节点的性能瓶颈问题 控制流与数据流的分离 master节点在内存中保存metadata Chunkserver节点利用本身的文件系统提供的 cache Client 节点缓存metadata Cache机制 客户无需学习专门的API接口 可应用在Linux和Windows等各种平台下 支持POSIX接口 可以任意加入节点（包括硬盘）以扩展容量 采用负载均衡策略重新分布数据 支持加入节点动态扩展 1:1 容错技术 1:2 容错技术 高顽存容错技术 支持节点损失实时自适应容错 cStor云存储界面 cStor的性能 cStor性能 在某数据中心已经成功应用2年，期间未出现系统故障，节点故障均自动屏蔽。 另外还用于数字地球、视频监控、视频点播等领域。 cStor云存储的应用 基于cStor的云分发系统 基于cStor的云处理系统 HBase Map- Reduce ZooKeeper NameNode DataNodes HMaster RegionServer HDFS Hive/Pig JobTracker TaskTracker 自研的超低功耗云存储硬件节点，功耗仅约为10W（不含硬盘），支持16块硬盘，容量达到32TB以上。 在1个标准的42U机架上集成总容量高达1024TB。 下一代cStor云存储硬件说明 超低功耗云存储节点 EMC Atmos云存储 名称 单机架最大容量 是否支持POSIX接口 能耗 易用性 应用适用性 是否支持对文件进行修改 是否可以单独出售云存储产品 是否支持N+M分布式容错 大小文件 cStor 1024T 支持 5-10W主板承载16个硬盘 免学习 有配置选项，适用于各类Windows、Linux 应用 支持 可以 支持 对大小文件都支持的比较好 GFS 不确定 否 200W左右 需学习API 需要修改应用 只支持在文件尾追加 只卖云存储服务，不卖产品 不支持 对小文件支持的比较差 cStor与GFS的比较 谢谢！ * Enter Title of Presentation Here Google Confidential * * * * * * * * * * * * * 任军远 cStor超低功耗云存储系统 Google文件系统(GFS) Google48% MSN19% Yahoo33% 客户端 客户端 客户端 互为备份 管理节点 GFS主节点 GFS主节点 C0 C1 C2 C5 数据结点1 C0 C2 C5 数据结点N C1 C5 数据结点2 … 客户端 客户端 客户端 客户端 客户端 客户端 C1 Google需要一个支持海量存储的文件系统 购置昂贵的分布式文件系统与硬件？ Google设计GFS的动机 是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？ 硬件出错是正常而非异常 系统应当由大量廉价、易损的硬件组成 必须保持文件系统整体的可靠性 主要负载是流数据读写 主要用于程序处理批量数据，而非与用户的交互或随机读写 数据写主要是“追加写”，“插入写”非常少 需要存储大尺寸的文件 存储的文件尺寸可能是GB或TB量级，而且应当能支持存储成千上万的大尺寸文件 GFS的假设与目标 将文件划分为若干块（Chunk）存储 每个块固定大小（64M） 通过冗余来提高可靠性 每个数据块至少在3个数据块服务器上冗余 数据块损坏概率？ 通过单个master来协调数据访问、元数据存储 结构简单，容易保持元数据一致性 无缓存 Why? GFS的设计思路 单一Master, 若干ChunkServer GFS的架构 1、文件存储方式 2、数据读写流程 分布式系统设计告诉我们： 这是单点故障 这是性能瓶颈 GFS的解决办法 单点故障问题 单一Master问题 采用多个（如3个）影子Master节点进行热备，一旦主节点损坏，立刻选举一个新的主节点服务 GFS的解决办法 性能瓶颈问题 单一Master问题 尽可能减少数据存取中Master的参与程度 不使用Master读取数据，仅用于保存元数据 客户端缓存元数据 采用大尺寸的数据块（64M