终于有人把Ceph分布式存储讲清楚了!
Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并随后贡献给开源社区。在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。但是在2014年OpenStack火爆的时候、Ceph并不被很多人所接受。当时Ceph并不稳定(Ceph发布的第四个版本 Dumpling v0.67),而且架构新颖,复杂,当时人们对Ceph在生产落地如何保障数据的安全,数据的一致性存在怀疑。
随着OpenStack的快速发展,给Ceph的发展注入了强心剂,越来越多的人使用Ceph作为OpenStack的底层共享存储,Ceph在中国的社区也蓬勃发展起来。近两年OpenStack火爆度不及当年,借助于云原生尤其是Kubernetes技术的发展,作为底层存储的基石,Ceph再次发力,为Kubernets有状态化业务提供了存储机制的实现。
存储发展史
企业中使用存储按照其功能,使用场景,一直在持续发展和迭代,大体上可以分为四个阶段:
•DAS:Direct Attached Storage,即直连存储,第一代存储系统,通过SCSI总线扩展至一个外部的存储,磁带整列,作为服务器扩展的一部分;
•NAS:Network Attached Storage,即网络附加存储,通过网络协议如NFS远程获取后端文件服务器共享的存储空间,将文件存储单独分离出来;
•SAN:Storage Area Network,即存储区域网络,分为IP-SAN和FC-SAN,即通过TCP/IP协议和FC(Fiber Channel)光纤协议连接到存储服务器;
•Object Storage:即对象存储,随着大数据的发展,越来越多的图片,视频,音频静态文件存储需求,动仄PB以上的存储空间,需无限扩展。
存储的发展,根据不同的阶段诞生了不同的存储解决方案,每一种存储都有它当时的历史诞生的环境以及应用场景,解决的问题和优缺点。
区别如下:
DAS 直连存储服务器使用 SCSI 或 FC 协议连接到存储阵列、通过 SCSI 总线和 FC 光纤协议类型进行数据传输;例如一块有空间大小的裸磁盘:/dev/sdb。DAS存储虽然组网简单、成本低廉但是可扩展性有限、无法多主机实现共享、目前已经很少使用了。
NAS网络存储服务器使用TCP网络协议连接至文件共享存储、常见的有NFS、CIFS协议等;通过网络的方式映射存储中的一个目录到目标主机,如/data。NAS网络存储使用简单,通过IP协议实现互相访问,多台主机可以同时共享同一个存储。但是NAS网络存储的性能有限,可靠性不是很高。
SAN存储区域网络服务器使用一个存储区域网络IP或FC连接到存储阵列、常见的SAN协议类型有IP-SAN和FC-SAN。SAN存储区域网络的性能非常好、可扩展性强;但是成本特别高、尤其是FC存储网络:因为需要用到HBA卡、FC交换机和支持FC接口的存储。
Object Storage对象存储通过网络使用API访问一个无限扩展的分布式存储系统、兼容于S3风格、原生PUT/GET等协议类型。表现形式就是可以无限使用存储空间,通过PUT/GET无限上传和下载。可扩展性极强、使用简单,但是只使用于静态不可编辑文件,无法为服务器提供块级别存储。
综上、企业中不同场景使用的存储,使用表现形式无非是这三种:磁盘(块存储设备),挂载至目录像本地文件一样使用(文件共享存储),通过API向存储系统中上传PUT和下载GET文件(对象存储)。
什么是Ceph?
接下来我们要讲讲Ceph,那么到底什么是Ceph呢?Ceph能够提供企业中三种常见的存储需求:块存储、文件存储和对象存储,正如Ceph官方所定义的一样“Ceph uniquely delivers object, block, and file storage in one unified system.”,Ceph在一个统一的存储系统中同时提供了对象存储、块存储和文件存储,即Ceph是一个统一存储,能够将企业企业中的三种存储需求统一汇总到一个存储系统中,并提供分布式、横向扩展,高度可靠性的存储系统,Ceph存储提供的三大存储接口:
上图详见官方文档:http://docs.ceph.org.cn/
1、CEPH OBJECT STORE对象存储,包含功能,特性如下:
•RESTful Interface RESTful风格接口;
•S3- and Swift-compliant APIs 提供兼容于S3和Swfit风格API;
•S3-style subdomains S3风格的目录风格;
•Unified S3/Swift namespace 统一扁平的S3/Swift命名空间,即所有的对象存放在同一个平面上;
•User management 提供用户管理认证接入;
•Usage tracking 使用情况追踪;
•Striped objects 对象切割,将一个大文件切割为多个小文件(objects);
•Cloud solution integration 云计算解决方案即成,可以与Swfit对象存储即成;
•Multi-site deployment 多站点部署,保障可靠性;
•Multi-site replication 多站点复制,提供容灾方案。
2、CEPH BLOCK DEVICE块存储,包含功能,特性如下:
•Thin-provisioned 瘦分配,即先分配特定存储大小,随着使用实际使用空间的增长而占用存储空间,避免空间占用;
•Images up to 16 exabytes 耽搁景象最大能支持16EB;
•Configurable striping 可配置的切片,默认是4M;
•In-memory caching 内存缓存;
•Snapshots 支持快照,将当时某个状态记录下载;
•Copy-on-write cloning Copy-on-write克隆复制功能,即制作某个镜像实现快速克隆,子镜像依赖于母镜像;
•Kernel driver support 内核驱动支持,即rbd内核模块;
•KVM/libvirt support 支持KVM/libvirt,实现与云平台如openstack,cloudstack集成的基础;
•Back-end for cloud solutions 云计算多后端解决方案,即为openstack,kubernetes提供后端存储;
•Incremental backup 增量备份;
•Disaster recovery (multisite asynchronous replication) 灾难恢复,通过多站点异步复制,实现数据镜像拷贝。
3、CEPH FILE SYSTEM文件存储,包含功能,特性如下:
•POSIX-compliant semantics POSIX风格接口;
•Separates metadata from data 元数据metadata和数据data分开存储;
•Dynamic rebalancing 动态数据均衡;
•Subdirectory snapshots 子目录快照;
•Configurable striping 可配置切割大小;
•Kernel driver support 内核驱动支持,即CephFS;
•FUSE support 支持FUSE风格;
•NFS/CIFS deployable 支持NFS/CIFS形式部署;
•Use with Hadoop (replace HDFS) 可支持与Hadoop继承,替换HDFS存储。
通俗点讲:Ceph提供了三种存储接口:块存储RBD,对象存储RGW和文件存储CephFS,每种存储都有其相应的功能和特性。
Ceph存储架构
Ceph 独一无二地用统一的系统提供了对象、块、和文件存储功能,它可靠性高、管理简便、并且是自由软件。Ceph 的强大足以改变贵公司的 IT 基础架构、和管理海量数据的能力。Ceph 可提供极大的伸缩性——供成千用户访问 PB 乃至 EB 级的数据。Ceph 节点以普通硬件和智能守护进程作为支撑点, Ceph 存储集群组织起了大量节点,它们之间靠相互通讯来复制数据、并动态地重分布数据。
什么是Ceph分布式存储?
接下来,我们先来看一下Ceph的存储架构,了解Ceph的分布式架构,功能组件和涉及相关概念。Ceph分布式集群是建立在RADOS算法之上的,RADOS是一个可扩展性,高可靠的存储服务算法,是Ceph的实现的基础。Ceph有两个重要的组件组成:Ceph Monitors(Ceph监视器)和Ceph OSDs(Ceph OSD 守护进程)。
其中Ceph Monitor作为集群中的控制中心,拥有整个集群的状态信息,各个组件如OSDs将自己的状态信息报告给Ceph Monitor这个总司令,由此可以可知,Ceph Monitor这个总司令肩负起整个集群协调工作;同时Ceph Monitor还负责将集群的指挥工作,将集群的状态同步给客户端,客户端根据Ceph Monitor发送的集群状态信息可以获取到集群的状态,当集群状态有变化如OSD增加或故障时,Ceph Monitor会负责更新集群状态并下发给客户端。Ceph Monitor的重要不言而喻,为了保障集群的可用性,需要部署高可用,一般需要部署2n+1个节点,如3个或5个Ceph Monitor节点。
什么是集群的状态呢?Ceph Monitor中保存的集群状态根据其功能角色的不同,分为以下几个map状态表:
•Monitor Maps,集群Ceph Monitor集群的节点状态,通过ceph mon dump可以获取;
•OSD Maps,集群数据存储节点的状态表,记录集群中OSD状态变化,通过ceph osd dump可以获取;
•PGs Maps,PGs即placement group,表示在OSD中的分布式方式,通过ceph pg dump可以获取;
•Crush Maps,Crush包含资源池pool在存储中的映射路径方式,即数据是如何分布的;
•MDS Maps,CephFS依赖的MDS管理组件,可通过ceph mds dump获取,用于追踪MDS状态。
除了Ceph Monitor之外,还有一个重要的组件是OSD,集群中通常有多个OSD组成,OSD即Object Storage Daemon,负责Ceph集群中真正数据存储的功能,也就是我们的数据最终都会写入到OSD中。除了Monitor之外,根据Ceph提供的不同功能,还有其他组件,包括:
•Ceph Monitors(ceph-mon);
•Ceph OSDs(ceph-osd);
•Ceph MDS(ceph-mds),用于提供CephFS文件存储,提供文件存储所需元数据管理;
•Ceph RGW(ceph-rgw),用于提供Ceph对象存储网关,提供存储网关接入;
•Ceph Manager(ceph-mgr),提供集群状态监控和性能监控。
注:Ceph Monitor监视器维护着集群运行图的主副本。一个监视器集群确保了当某个监视器失效时的高可用性。存储集群客户端向 Ceph Monitor 监视器索取集群运行图的最新副本。而Ceph OSD 守护进程检查自身状态、以及其它 OSD 的状态,并报告给监视器们。存储集群的客户端和各个 Ceph OSD 守护进程使用 CRUSH 算法高效地计算数据位置,而不是依赖于一个中心化的查询表。它的高级功能包括:基于 librados的原生存储接口、和多种基于 librados 的服务接口。
Ceph数据的存储
了解完Ceph的架构后,我们先来了解一下Ceph的读写流程,期间会涉及到CRUSH,PGs等这些概念,我们从一个最基本的的概念入手:Ceph中一切皆对象,不管是RBD块存储接口,RGW对象存储接口还是文件存储CephFS接口,其存储如到Ceph中的数据均可以看作是一个对象,一个文件需要切割为多个对象(object),然后将object存储到OSD中,如下图:
file
注:Ceph 存储集群从 Ceph 客户端接收数据——不管是来自 Ceph 块设备、 Ceph 对象存储、 Ceph 文件系统、还是基于 librados 的自定义实现——并存储为对象。每个对象是文件系统中的一个文件,它们存储在对象存储设备上。由 Ceph OSD 守护进程处理存储设备上的读/写操作。
那么,这些切割后的object怎么选择到对应的OSD存储节点呢,这需要依赖于Ceph的智能调度算法CRUSH,通过CRUSH算法将object调度到合适的OSD节点上,不管是客户端还是OSD,均使用CRUSH算法来计算object在集群中OSD的位置信息,同时保障object的副本能落到合适的OSD节点上,关于CRUSH算法的实现比较复杂,详情可以参考:CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data。
Ceph OSD 在扁平的命名空间内把所有数据存储为对象(也就是没有目录层次)。对象包含一个标识符、二进制数据、和由名字/值对组成的元数据,元数据语义完全取决于 Ceph 客户端。例如, CephFS 用元数据存储文件属性,如文件所有者、创建日期、最后修改日期等等。
file
object调度到OSD节点上,如果一个文件发生了变动或OSD出现了异常,以一个100G的文件为例,每个object默认为4M,将会切割为25600个object,如果Ceph集群需要正对每个object都进行调度的话,可想而知,在一个大规模集群中,crush的调度将会变得异常的繁重。因此,Ceph引入了另外一个概念PG,PG是Place Group即放置组,可以简单理解为一个装载object的容器,object将映射到PG中,PG最终会调度到某个具体的OSD上,因此CRUSH由object调度转为PG的调度,而PG的数量是相对固定的,因此集群分布时调度相对没有那么繁重,同时,当某个OSD异常时,CRUSH调度算法只需将其上的PG调度至其他OSD上(而不是将其上的object进行调度)。Ceph的整个数据调度写入流程如下图:
file
•一个文件将会切割为多个object(如1G文件每个object为4M将切割为256个),每个object会由一个由innode(ino)和object编号(ono)组成oid,即object id,oid是真个集群唯一,唯一标识object对象;
•针对object id做hash并做取模运算,从而获取到pgid,即place group id,通过hash+mask获取到PGs ID,PG是存储object的容器;
•Ceph通过CRUSH算法,将pgid进行运算,找到当前集群最适合存储PG的OSD节点,如osd1和osd2(假设为2个副本);
•PG的数据最终写入到OSD节点,完成数据的写入过程,当然这里会涉及到多副本,一份数据写多副本。
好了,现在我们对Ceph有了基本认识了。后面我们讲继续了解Ceph伸缩性和高可用性;动态集群管理;纠删编码;缓存分级等内容。当然、我们也会具体了解到如纠删编码中关于读出和写入编码块,被中断的完全写等更细的内容。
更多文章和资料 ↓↓↓
阿里云K8s实战手册 K8s
阿里云CDN排坑指南 CDN
ECS运维指南 ECS
DevOps实践手册 DevOps
Hadoop大数据实战手册 Hadoop