任军远

Email: horizon_2008_888@126.com http://www.cStor.cn

cStor超低功耗云存储系统

Google 文件系统 (GFS)

Google48%

MSN19%

Yahoo33%

客户端

客户端客户端互为

备份

管理节点

GFS主节点

GFS主节点

C0 C1

C2C5

数据结点 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）

数据修改顺序交由 Primary Chunk Server完成

Simple, and good enough!

存储元数据 文件系统目录管理与加锁 与 ChunkServer 进行周期性通信

发送指令，搜集状态，跟踪数据块的完好性 数据块创建、复制及负载均衡

对 ChunkServer的空间使用和访问速度进行负载均衡 对数据块进行复制、分散到 ChunkServer上 一旦数据块冗余数小于最低数，就发起复制操作 平滑数据存储和访问请求的负载

Master节点的任务

垃圾回收 在日志中记录删除操作，并将文件改名隐藏 缓慢地回收隐藏文件 与传统文件删除相比更简单、更安全

陈旧数据块删除 探测陈旧的数据块，并删除

Master节点的任务

采用中心服务器模式 可以方便地增加 Chunk Server Master掌握系统内所有 Chunk Server的情况，方便进行负载均衡

不存在元数据的一致性问题

GFS架构的特点

不缓存数据 GFS的文件操作大部分是流式读写，不存在大量的重复读写，使用 Cache对性能提高不大

Chunk Server上的数据存取使用本地文件系统，如果某个 Chunk读取频繁，文件系统具有 Cache

从可行性看， Cache与实际数据的一致性维护也极其复杂

GFS架构的特点

在用户态下实现 直接利用 Chunk Server的文件系统存取 Chunk，实现简单

用户态应用调试较为简单，利于开发 用户态的 GFS不会影响 Chunk Server的稳定性

提供专用的访问接口 未提供标准的 POSIX访问接口 降低 GFS的实现复杂度

GFS架构的特点

GFS 的容错机制 Chunk Server容错

每个 Chunk有多个存储副本（通常是 3 个），分别存储于不通的服务器上

每个 Chunk 又划分为若干 Block （ 64KB），每个Block对应一个 32bit的校验码，保证数据正确（若某个Block 错误，则转移至其他 Chunk 副本）

GFS的容错方法

GFS 的容错机制 Master容错

三类元数据：命名空间（目录结构）、 Chunk与文件名的映射以及 Chunk 副本的位置信息

前两类通过日志提供容错， Chunk 副本信息存储于Chunk Server ， Master 出现故障时可恢复

GFS的容错方法

超过 50 个 GFS集群 每个集群包含数千个存储节点 管理着 PB(1015Byte)级的数据

GFS 在 Google中的部署

巨型、廉价、稳定的数据中心巨型、廉价、稳定的数据中心

cStor 云存储硬件架构

cStor 云存储软件架构

cStor 云存储硬件

Master Server ( 管理服务器 ) 管理整个文件系统，存储各文件的元数据信息，调度各数据存储服务器

Data Server ( 数据存储服务器 ) 存储文件数据，接受管理服务器的调度，为客户端提供数据传输

Client ( 客户端 ) 从管理服务器上获取修改元数据信息，并向数据服务器读写数据

cStor 云存储软件架构

支持 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/PigJobTracker 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的比较

谢谢！