我在一个环境当中,有不少不少的服务器,服务器上也有它本身不少的硬盘,我经过软件的形式把若干服务器都收集起来,部署成一个软件,在这个逻辑的软件里能够同时看到我若干服务器的磁盘的空间,这个逻辑的软件对外就像是一个总体同样,这个总体叫storage spool,用户呢有一天想用这个空间了,用户直接去对应这个存储池提供的接口,这用的话,用户保存一个文件,实际上保存在若干个服务器里,文件会随机存到第一个服务器的第一块硬盘里,下一次就可能存到第二个服务器的第三块硬盘里。它会把文件进行打散,分红不一样的小块,每块存放的位置多是不一样的服务器上的不一样硬盘里。算法
分布式存储还能够对文件进行安全备份,我这个文件存在后端的服务器里,能够保存多份,多份叫副本也能够叫镜像。就是说对我打散的每块文件作一个镜像在保存在不一样服务器上的不一样硬盘里,这样,若是后端有服务器宕掉了,个人文件仍是完整的。ceph就能够作到这么一种功能。编程
Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体如今能够提供文件系统、块存储和对象存储,分布式体如今能够动态扩展。在国内一些公司的云环境中,一般会采用 ceph 做为openstack 的惟一后端存储来提升数据转发效率。
Ceph项目最先起源于Sage就读博士期间的工做(最先的成果于2004年发表),并随后贡献给开源社区。在通过了数年的发展以后,目前已获得众多云计算厂商的支持并被普遍应用。RedHat及OpenStack均可与Ceph整合以支持虚拟机镜像的后端存储。后端
官网:https://ceph.com/安全
官方文档:http://docs.ceph.com/docs/master/#服务器
高性能:
a.摒弃了传统的集中式存储元数据寻址的方案,采用CRUSH算法,数据分布均衡,并行度高。
b.考虑了容灾域的隔离,可以实现各种负载的副本放置规则,例如跨机房、机架、感知等。
c.可以支持上千个存储节点的规模,支持TB到PB级的数据。网络
高可用性:
a.副本数能够灵活控制。(就是说让副本保存份数能够多份,在正常的生产环境是保存3副本)
b.支持故障域分隔,数据强一致性。
c.多种故障场景自动进行修复自愈。
d.没有单点故障,自动管理。(假如说我这个文件设置的是3副本,若是后端服务器坏掉,副本数不够3,它会自动补充至3副本)架构
高可扩展性:
a.去中心化。
b.扩展灵活。
c.随着节点增长而线性增加。编程语言
特性丰富:
a. 支持三种存储接口:块存储(我获得的是硬盘)、文件存储(目录)、对象存储(有可能给你对接的是一个挂载的目录,可是后端怎么去存的,它会把数据打散,采用键值对形式存储)。
b.支持自定义接口,支持多种语言驱动。分布式
Ceph能够提供对象存储、块设备存储和文件系统服务,其对象存储能够对接网盘(owncloud)应用业务等;其块设备存储能够对接(IaaS),当前主流的IaaS运平台软件,如:OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。性能
Ceph是一个高性能、可扩容的分布式存储系统,它提供三大功能:
对象存储(RADOSGW):提供RESTful接口,也提供多种编程语言绑定。兼容S3(是AWS里的对象存储)、Swift(是openstack里的对象存储);
块存储(RDB):由RBD提供,能够直接做为磁盘挂载,内置了容灾机制;
文件系统(CephFS):提供POSIX兼容的网络文件系统CephFS,专一于高性能、大容量存储;
什么是块存储/对象存储/文件系统存储?
1.对象存储:
也就是一般意义的键值存储,其接口就是简单的GET、PUT、DEL 和其余扩展,表明主要有 Swift 、S3 以及 Gluster 等;
2.块存储:
这种接口一般以 QEMU Driver 或者 Kernel Module 的方式存在,这种接口须要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口,如 Sheepdog,AWS 的 EBS,青云的云硬盘和阿里云的盘古系统,还有 Ceph 的 RBD(RBD是Ceph面向块存储的接口)。在常见的存储中 DAS、SAN 提供的也是块存储;
3.文件系统存储:
一般意义是支持 POSIX 接口,它跟传统的文件系统如 Ext4 是一个类型的,但区别在于分布式存储提供了并行化的能力,如 Ceph 的 CephFS (CephFS是Ceph面向文件存储的接口),可是有时候又会把 GlusterFS ,HDFS 这种非POSIX接口的类文件存储接口纳入此类。固然 NFS、NAS也是属于文件系统存储;
(1)Monitors(管理服务):监视器,维护集群状态的多种映射,同时提供认证和日志记录服务,包括有关monitor 节点端到端的信息,其中包括 Ceph 集群ID,监控主机名和IP以及端口。而且存储当前版本信息以及最新更改信息,经过 "ceph mon dump"查看 monitor map。
(2)MDS(Metadata Server):Ceph 元数据,主要保存的是Ceph文件系统的元数据。注意:ceph的块存储和ceph对象存储都不须要MDS。
(3)OSD:即对象存储守护程序,可是它并不是针对对象存储。是物理磁盘驱动器,将数据以对象的形式存储到集群中的每一个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回(Backfilling)、再平衡。完成存储数据的工做绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候,建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测,检测结果汇报给Monitor
(4)RADOS:Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中,全部数据都以对象的形式存储,而且不管什么数据类型,RADOS对象存储都将负责保存这些对象。RADOS层能够确保数据始终保持一致。
(5)librados:librados库,为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。
(6)RADOSGW:网关接口,提供对象存储服务。它使用librgw和librados来实现容许应用程序与Ceph对象存储创建链接。而且提供S3 和 Swift 兼容的RESTful API接口。
(7)RBD:块设备,它可以自动精简配置并可调整大小,并且将数据分散存储在多个OSD上。
(8)CephFS:Ceph文件系统,与POSIX兼容的文件系统,基于librados封装原生接口。
首先用户把一个文件放到ceph集群后,先把文件进行分割,分割为等大小的小块,小块叫object,让后这些小块跟据必定算法跟规律,算法是哈希算法,放置到PG组里,就是归置组,而后再把归置组放到OSD里面。
不管使用哪一种存储方式(对象、块、文件系统),存储的数据都会被切分红Objects。Objects size大小能够由管理员调整,一般为2M或4M。每一个对象都会有一个惟一的OID,由ino与ono生成,虽然这些名词看上去很复杂,其实至关简单。
ino:便是文件的File ID,用于在全局惟一标识每个文件
ono:则是分片的编号
好比:一个文件FileID为A,它被切成了两个对象,一个对象编号0,另外一个编号1,那么这两个文件的oid则为A0与A1。
File —— 此处的file就是用户须要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言,这个file也就对应于应用中的“对象”,也就是用户直接操做的“对象”。
Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是,object的最大size由RADOS限定(一般为2MB或4MB),以便实现底层存储的组织管理。所以,当上层应用向RADOS存入size很大的file时,须要将file切分红统一大小的一系列object(最后一个的大小能够不一样)进行存储。为避免混淆,在本文中将尽可能避免使用中文的“对象”这一名词,而直接使用file或object进行说明。
PG(Placement Group)—— 顾名思义,PG的用途是对object的存储进行组织和位置映射。具体而言,一个PG负责组织若干个object(能够为数千个甚至更多),但一个object只能被映射到一个PG中,即,PG和object之间是“一对多”映射关系。同时,一个PG会被映射到n个OSD上,而每一个OSD上都会承载大量的PG,即,PG和OSD之间是“多对多”映射关系。在实践当中,n至少为2,若是用于生产环境,则至少为3。一个OSD上的PG则可达到数百个。事实上,PG数量的设置牵扯到数据分布的均匀性问题。关于这一点,下文还将有所展开。
OSD —— 即object storage device,前文已经详细介绍,此处再也不展开。惟一须要说明的是,OSD的数量事实上也关系到系统的数据分布均匀性,所以其数量不该太少。在实践当中,至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优点。
基于上述定义,即可以对寻址流程进行解释了。具体而言, Ceph中的寻址至少要经历如下三次映射:
(1)File -> object映射
(2)Object -> PG映射,hash(oid) & mask -> pgid
(3)PG -> OSD映射,CRUSH算法
CRUSH,Controlled Replication Under Scalable Hashing,它表示数据存储的分布式选择算法, ceph 的高性能/高可用就是采用这种算法实现。CRUSH 算法取代了在元数据表中为每一个客户端请求进行查找,它经过计算系统中数据应该被写入或读出的位置。CRUSH可以感知基础架构,可以理解基础设施各个部件之间的关系。并CRUSH保存数据的多个副本,这样即便一个故障域的几个组件都出现故障,数据依然可用。CRUSH 算是使得 ceph 实现了自我管理和自我修复。
RADOS 分布式存储相较于传统分布式存储的优点在于:
1. 将文件映射到object后,利用Cluster Map 经过CRUSH 计算而不是查找表方式定位文件数据存储到存储设备的具体位置。优化了传统文件到块的映射和Block MAp的管理。
2. RADOS充分利用OSD的智能特色,将部分任务受权给OSD,最大程度地实现可扩展
(1)正常IO流程图:
步骤:
1. client 建立cluster handler。
2. client 读取配置文件。
3. client 链接上monitor,获取集群map信息。
4. client 读写io 根据crshmap 算法请求对应的主osd数据节点。
5. 主osd数据节点同时写入另外两个副本节点数据。
6. 等待主节点以及另外两个副本节点写完数据状态。
7. 主节点及副本节点写入状态都成功后,返回给client,io写入完成。
(2)新主IO流程图:
说明:若是新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 因为 OSD1 上未建立 PG , 不存在数据,那么 PG 上的 I/O 没法进行,怎样工做的呢?
新主IO流程步骤:
1. client链接monitor获取集群map信息。
2. 同时新主osd1因为没有pg数据会主动上报monitor告知让osd2临时接替为主。
3. 临时主osd2会把数据全量同步给新主osd1。
4. client IO读写直接链接临时主osd2进行读写。
5. osd2收到读写io,同时写入另外两副本节点。
6. 等待osd2以及另外两副本写入成功。
7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。
8. 若是osd1数据同步完毕,临时主osd2会交出主角色。
9. osd1成为主节点,osd2变成副本。
pool:是ceph存储数据时的逻辑分区,它起到namespace的做用。每一个pool包含必定数量(可配置) 的PG。PG里的对象被映射到不一样的Object上。pool是分布到整个集群的。 pool能够作故障隔离域,根据不一样的用户场景不统一进行隔离。