分布式存储
那年你转身离去的背影，像是我见过最大的一场风雨。
存储根据其类型可分为块存储对象存储和文件存储在主流的分布式存储技术中HDFS/GPFS/GFS属于文件存储Swift属于对象存储而Ceph可支持块存储对象存储和文件存储故称为统一存储
Ceph最早起源于Sage就读博士期间的工作成果于2004年发表并随后贡献给开源社区经过多年的发展之后已得到众多云计算和存储厂商的支持成为应用最广泛的开源分布式存储平台
Ceph根据场景可分为对象存储块设备存储和文件存储Ceph相比其它分布式存储技术其优势点在于它不单是存储同时还充分利用了存储节点上的计算能力在存储每一个数据时都会通过计算得出该数据存储的位置尽量将数据分布均衡同时由于采用了CRUSHHASH等算法使得它不存在传统的单点故障且随着规模的扩大性能并不会受到影响
1.Ceph的主要架构
Ceph的最底层是RADOS（分布式对象存储系统）它具有可靠智能分布式等特性实现高可靠高可拓展高性能高自动化等功能并最终存储用户数据RADOS系统主要由两部分组成分别是OSD和Monitor
RADOS之上是LIBRADOSLIBRADOS是一个库它允许应用程序通过访问该库来与RADOS系统进行交互支持多种编程语言比如CC++Python等
基于LIBRADOS层开发的有三种接口分别是RADOSGWlibrbd和MDS
RADOSGW是一套基于当前流行的RESTFUL协议的网关支持对象存储兼容S3和Swift
librbd提供分布式的块存储设备接口支持块存储
MDS提供兼容POSIX的文件系统支持文件存储
2.Ceph的功能模块
Ceph的核心组件包括Client客户端MON监控服务MDS元数据服务OSD存储服务各组件功能如下
Client客户端负责存储协议的接入节点负载均衡
MON监控服务负责监控整个集群维护集群的健康状态维护展示集群状态的各种图表如OSD MapMonitor MapPG Map和CRUSH Map
MDS元数据服务负责保存文件系统的元数据管理目录结构
OSD存储服务主要功能是存储数据复制数据平衡数据恢复数据以及与其它OSD间进行心跳检查等一般情况下一块硬盘对应一个OSD
3.Ceph的资源划分
Ceph采用crush算法在大规模集群下实现数据的快速准确存放同时能够在硬件故障或扩展硬件设备时做到尽可能小的数据迁移其原理如下
当用户要将数据存储到Ceph集群时数据先被分割成多个object每个object一个object id大小可设置默认是4MB）object是Ceph存储的最小存储单元
由于object的数量很多为了有效减少了Object到OSD的索引表降低元数据的复杂度使得写入和读取更加灵活引入了pgPlacement Group PG用来管理object每个object通过Hash映射到某个pg中一个pg可以包含多个object
Pg再通过CRUSH计算映射到osd中如果是三副本的则每个pg都会映射到三个osd保证了数据的冗余
4.Ceph的数据写入
Ceph数据的写入流程
1 数据通过负载均衡获得节点动态IP地址
2 通过块文件对象协议将文件传输到节点上
3 数据被分割成4M对象并取得对象ID
4 对象ID通过HASH算法被分配到不同的PG
5 不同的PG通过CRUSH算法被分配到不同的OSD
5.Ceph的特点
Ceph支持对象存储块存储和文件存储服务故 称为统一存储
采用CRUSH算法数据分布均衡并行度高不需要维护固定的元数据结构
数据具有强一致确保所有副本写入完成才返回确认适合读多写少场景
去中心化MDS之间地位相同无固定的中心节点
Ceph存在一些缺点
去中心化的分布式解决方案需要提前做好规划设计对技术团队的要求能力比较高
Ceph扩容时由于其数据分布均衡的特性会导致整个存储系统性能的下降
GFS是google的分布式文件存储系统是专为存储海量搜索数据而设计的2003年提出是闭源的分布式文件系统适用于大量的顺序读取和顺序追加如大文件的读写注重大文件的持续稳定带宽而不是单次读写的延迟
1.GFS的主要架构
GFS 架构比较简单一个 GFS 集群一般由一个 master 多个 chunkserver 和多个 clients 组成
在 GFS 中所有文件被切分成若干个 chunk每个 chunk 拥有唯一不变的标识（在 chunk 创建时由 master 负责分配）所有 chunk 都实际存储在 chunkserver 的磁盘上
为了容灾每个 chunk 都会被复制到多个 chunkserve
2.GFS的功能模块
GFS client客户端为应用提供API与POSIX API类似同时缓存从GFS master读取的元数据chunk信息
GFS master元数据服务器管理所有文件系统的元数据包括命令空间（目录层级）访问控制信息文件到chunk的映射关系chunk的位置等同时 master 还管理系统范围内的各种活动包括chunk 创建复制数据迁移垃圾回收等
GFS chunksever存储节点用于所有 chunk的存储一个文件被分割为多个大小固定的chunk（默认64M）每个chunk有全局唯一的chunk ID
3.GFS的写入流程
1 Client 向 master 询问要修改的 chunk在哪个 chunkserver上以及 该chunk 其他副本的位置信息
2 Master 将Primarysecondary的相关信息返回给 client
3 Client 将数据推送给 primary 和 secondary
4 当所有副本都确认收到数据后client 发送写请求给 primaryprimary 给不同 client 的操作分配序号保证操作顺序执行
5 Primary 把写请求发送到 secondarysecondary 按照 primary 分配的序号顺序执行所有操作
6 当 Secondary 执行完后回复 primary 执行结果
7 Primary 回复 client 执行结果
由上述可见GFS在进行写数据时有如下特点
GFS在数据读写时数据流与控制流是分开的并通过租约机制在跨多个副本的数据写入中, 保障顺序一致性
Master将chunk租约发放给其中一个副本这个副本称为主副本由主副本确定chunk的写入顺序次副本则遵守这个顺序这样就保障了全局顺序一致性
Master返回客户端主副本和次副本的位置信息客户端缓存这些信息以备将来使用只有当主副本所在chunkserver不可用或返回租约过期了客户端才需要再次联系Master
GFS采用链式推送以最大化利用每个机器的网络带宽避免网络瓶颈和高延迟连接最小化推送延迟
GFS使用TCP流式传输数据以最小化延迟
4.GFS特点
适合大文件场景的应用特别是针对GB级别的大文件适用于数据访问延时不敏感的搜索类业务
中心化架构只有1个master处于active状态
缓存和预取通过在client端缓存元数据尽量减少与master的交互通过文件的预读取来提升并发性能
高可靠性master需要持久化的数据会通过操作日志与checkpoint的方式存放多份故障后master会自动切换重启
HDFS（Hadoop Distributed File System）是一个适合运行在通用硬件commodity hardware上的分布式文件系统是Hadoop的核心子项目是基于流数据模式访问和处理超大文件的需求而开发的该系统仿效了谷歌文件系统GFS是GFS的一个简化和开源版本
1.HDFS的主要架构
HDFS Client（客户端）从NameNode获取文件的位置信息再从DataNode读取或者写入数据此外client在数据存储时负责文件的分割
NameNode（元数据节点）管理名称空间数据块（Block）映射信息配置副本策略处理客户端读写请求
DataNode（存储节点）负责执行实际的读写操作存储实际的数据块,同一个数据块会被存储在多个DataNode上
Secondary NameNode定期合并元数据推送给NameNode在紧急情况下可辅助NameNode的HA恢复
2.HDFS的特点（vs GFS）
分块更大每个数据块默认128MB
不支持并发同一时刻只允许一个写入者或追加者
过程一致性,写入数据的传输顺序与最终写入顺序一致
Master HA2.X版本支持两个NameNode（分别处于Active和Standby状态）故障切换时间一般几十秒到数分钟
3.HDFS适合的应用场景
适用于大文件大数据处理处理数据达到 GBTB甚至PB级别的数据
适合流式文件访问一次写入多次读取
文件一旦写入不能修改只能追加
4.HDFS不适合的场景
低延时数据访问
小文件存储
并发写入文件随机修改
Swift 最初是由Rackspace公司开发的分布式对象存储服务 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一为其 Nova 子项目提供虚机镜像存储服务
1.Swift的主要架构
Swift 采用完全对称面向资源的分布式系统架构设计所有组件都可扩展避免因单点失效而影响整个系统的可用性
Swift 组件包括
代理服务（Proxy Server）对外提供对象服务 API转发请求至相应的账户容器或对象服务
认证服务（Authentication Server）验证用户的身份信息并获得一个访问令牌（Token）
缓存服务（Cache Server）缓存令牌账户和容器信息但不会缓存对象本身的数据
账户服务（Account Server）提供账户元数据和统计信息并维护所含容器列表的服务
容器服务（Container Server）提供容器元数据和统计信息并维护所含对象列表的服务
对象服务（Object Server）提供对象元数据和内容服务每个对象会以文件存储在文件系统中
复制服务（Replicator）检测本地副本和远程副本是否一致采用推式（Push）更新远程副本
更新服务（Updater）对象内容的更新
审计服务（Auditor）检查对象容器和账户的完整性如果发现错误文件将被隔离
账户清理服务（Account Reaper）移除被标记为删除的账户删除其所包含的所有容器和对象
2.Swift的数据模型
Swift的数据模型采用层次结构共设三层Account/Container/Object（即账户/容器/对象每层节点数均没有限制可以任意扩展数据模型如下
3.一致性散列函数
Swift是基于一致性散列技术通过计算将对象均匀分布到虚拟空间的虚拟节点上在增加或删除节点时可大大减少需移动的数据量
为便于高效的移位操作虚拟空间大小通常采用 2 n通过独特的数据结构 Ring（环）再将虚拟节点映射到实际的物理存储设备上完成寻址过程如下图所示
散列空间4 个字节（32为）虚拟节点数最大为232如将散列结果右移 m 位可产生 232-m个虚拟节点（如上图中所示当m=29 时可产生 8 个虚拟节点）
4.环的数据结构
Swift为账户容器和对象分别定义了的环
环是为了将虚拟节点（分区）映射到一组物理存储设备上并提供一定的冗余度而设计的环的数据信息包括存储设备列表和设备信息分区到设备的映射关系计算分区号的位移（即上图中的m）
账户容器和对象的寻址过程（以对象的寻址过程为例）
1 以对象的层次结构 account/container/object 作为键采用 MD5 散列算法得到一个散列值
2 对该散列值的前 4 个字节进行右移操作（右移m位）得到分区索引号
3 在分区到设备映射表里按照分区索引号查找该对象所在分区对应的所有物理设备编号如下图
5.Swift的一致性设计
Swift 采用 Quorum 仲裁协议
定义N数据的副本总数W写操作被确认接受的副本数量R读操作的副本数量
强一致性R+W>N 就能保证对副本的读写操作会产生交集从而保证可以读取到最新版本
弱一致性R+W<=N读写操作的副本集合可能不产生交集此时就可能会读到脏数据
Swift 默认配置是N=3W=2R=2即每个对象会存在 3 个副本至少需要更新 2 个副本才算写成功如果读到的2个数据存在不一致则通过检测和复制协议来完成数据同步
如R=1就可能会读到脏数据此时通过牺牲一定的一致性可提高读取速度（而一致性可以通过后台的方式完成同步从而保证数据的最终一致性）
Quorum 协议示例如下所示
6.Swift特点
原生的对象存储不支持实时的文件读写编辑功能
完全对称架构无主节点无单点故障易于大规模扩展性能容量线性增长
数据实现最终一致性不需要所有副本写入即可返回读取数据时需要进行数据副本的校验
是OpenStack的子项目之一适合云环境的部署
Swift的对象存储与Ceph提供的对象存储区别客户端在访问对象存储系统服务时Swift要求客户端必须访问Swift网关才能获得数据而Ceph可以在每个存储节点上的OSD（对象存储设备）获取数据信息 在数据一致性方面Swift的数据是最终一致而Ceph是始终跨集群强一致性）
Lustre是基于Linux平台的开源集群（并行）文件系统最早在1999年由皮特•布拉姆创建的集群文件系统公司（Cluster File Systems Inc.）开始研发后由HPIntelCluster File System和美国能源部联合开发2003年正式开源主要用于HPC超算领域
1Lustre的主要架构
Lustre组件包括
管理服务器MGS存放集群中所有Lustre文件系统的配置信息Lustre客户通过联系MGS获取信息可以与MDS共享存储空间
元数据服务器MDS: 管理存储在MDT中的元数据使存储在一个或多个MDT中的元数据可供Lustre客户端使用每个MDS可管理一个或多个MDT
元数据目标MDT: MDS用于存储元数据例如文件名目录权限和文件布局一个MDT可用于多个MDS但一次只能有一个MDS访问
对象存储服务器OSS为一个或多个本地OST提供文件I / O服务和网络请求处理, 通常OSS服务于两个到八个OST
对象存储目标OST用户文件数据存储在一个或多个对象中每个对象位于单独OST中
Lustre客户端运行Lustre客户端软件的计算节点可挂载Lustre文件系统客户端软件包括一个管理客户端MGC一个元数据客户端MDC和多个对象存储客户端OSC每个OSC对应于文件系统中的一个OST
逻辑对象卷LOV通过聚合OSC以提供对所有OST的透明访问逻辑元数据卷LMV通过聚合MDC提供一种对所有MDT透明的访问
2Lustre特点
支持数万个客户端系统支持PB级存储容量单个文件最大支持320TB容量
支持RDMA网络大文件读写分片优化多个OSS能获得更高的聚合带宽
缺少副本机制存在单点故障如果一个客户端或节点发生故障存储在该节点上的数据在重新启动前将不可访问
适用高性能计算HPC领域适用于大文件连续读写
几种主流分布式存储技术的特点比较如下
此外根据分布式存储系统的设计理念其软件和硬件解耦分布式存储的许多功能包括可靠性和性能增强都由软件提供因此大家往往会认为底层硬件已不再重要但事实往往并非如此我们在进行分布式存储系统集成时除考虑选用合适的分布式存储技术以外还需考虑底层硬件的兼容性一般而言分布式存储系统的产品有三种形态软硬件一体机硬件OEM和软件+标准硬件大家在选择时需根据产品的成熟度风险规避运维要求等结合自身的技术力量等选择合适的产品形态