常用的存储可以分为DAS、NAS和SAN三类
常见的存储类型有文件存储、块存储和对象存储
常用的存储设备包括:单机存储、商业存储和分布式存储。
分布式存储是一种数据存储技术,通过网络使用企业中每台机器上的磁盘空间,并将这些分散的存储资源构建为一个虚拟的存储设备,数据分散存储在企业的各个角落。
常见的分布式存储包括:Ceph、GlusterFS、TFS、FAstDFS等
在分布式存储系统中,将数据分为数据和元数据。元数据就是文件的属性信息(文件名、权限、大小、时间戳等),当客户端将产生的数据写入到分布式存储系统中的时候,,会有一个服务(Name node)提供文件元数据路由的功能,即告诉客户端去哪个服务器请求文件内容,然后再由数据存储节点(Data node)提供数据的读写请求及数据的高可用
ceph官网:https://ceph.io/en/
ceph官方文档:https://docs.ceph.com/en/quincy/
Ceph是一个开源的分布式存储系统,同时支持对象存储、块设备、文件系统。
Ceph支持EB(1EB=1,000,000,000GB)级别的数据存储,ceph把每一个待管理的的数据流(文件等数据)切分为一到多个固定大小的对象数据,并以其为原子单位完成数据的读写。
ceph的优势:
高性能
高可用性
高可扩展性
特性丰富
如上边两张图所示,在ceph存储系统中,最底层是rados存储集群,然后上面是逻辑划分的pool和PG。再上层是librados,相当于rados集群的API接口。
ceph提供三种存储方式:radosgw(对象存储)、rbd(块存储)、cephfs(文件系统存储)。其中radosgw和rbd是基于librados实现的,cephfs则是直接在rados集群上实现的。用户可以通过不同的方式调用这三种存储接口存取数据,当然也可以直接通过librado存取数据。
但不论以哪种方式存取数据都需要指定pool,数据会映射到pool的pg上。
一个rados集群由monitor、manager、osd和mds这四类节点组成,其中mds是可选的,当使用cephfs接口时需要部署mds节点,用来存储文件元数据。
1. moitor节点
用来运行ceph-mon进程,维护集群状态映射(maintainers maps of the cluster state),比如ceph集群中存储池数量、PG数量以及存储池和PG的映射关系等。包括monitor map、manager map、osd map、mds map和crush map,这些映射map是ceph 守护程序相互协调所需的关键集群状态,此外monitor还负责管理守护程序和客户端之间的身份验证(cephx)。通常需要至少3个monitor节点来实现高可用。
2. manager节点
用于运行ceph-mgr进程,ceph-mgr负责跟踪运行时指标和ceph集群的当前状态,包括存储利用率,当前性能指标和系统负载。ceph-mgr还托管基于python的模块来管理和公开ceph集群信息,包括基于WEB的ceph仪表盘和REST API。通常需要至少两个manager节点来实现高可用。
3. OSD节点
用于运行ceph-osd进程,用来存储数据,正常情况下,操作系统上的一个磁盘就是一个osd守护程序,osd用于处理集群数据复制、恢复、重均衡等,并通过检查其它osd守护程序的心跳来向监视器和管理器提供一些监视信息。 通常需要至少3个osd节点才能实现数据高可用。
4. mds节点
配和cephfs接口使用,用来存储文件元数据
首先说明一下pool和PG
Pool:存储池,用于组织PG,存储池的大小取决于底层的存储空间
PG(Placement group):逻辑归置组,PG用来对object进行组织和位置映射,object属于PG,PG属于pool。pool和PG都是抽象的逻辑概念
ceph集群部署完成后,要先创建存储池才能向ceph写入数据,创建存储池时需要指定PG数量。
客户端向ceph存储文件的过程具体如下:
第一步,文件到object的映射
将File切分为固定大小的对象(默认4M),计算出每个对象的oid,oid=(ino + ono)
ino:inode number,文件的元数据序列号,可以理解为File的唯一Id
ono:File切分产生的某个object的序列号
oid:每个切分出来的object的唯一id,由ino和ono组合得到
第二步,object到PG的映射
在file映射到object之后,就需要将每个object映射到pg,计算公式如下
hash(oid) & mask -> pg-id
mask=存储池pg数量-1
首先对oid进行hash计算得到一个值,然后将这个值与mask进行按位与运算的到pgid
第三步,PG到OSD的映射
通过CRUSH算法将pgid带入其中,计算得到n个osd。这n个osd共同负责存储维护这个个PG中的所有object数据
crush(pgid) -> (osd1, osd2, ...)
第四步,client与主osd通信写入数据
第五步,主osd将数据同步给备份osd,等待备份osd返回确认消息
第六步,所有备份osd确认写入完成后,主osd返回确认消息给客户端
在ceph中,对象的元数据以key-value的形式存在,在rados中有两种实现:xattrs和omap。
ceph可选后端支持多种存储引擎,比如filestore、bluestore、memstore等。早期主要使用filestore,但由于filestore存在一些问题(对ssd设备支持不够好,写放大等),所以目前主要使用bluestore。
ceph早期使用filestore+leveldb组合来保存数据和元数据,leveldb是一个持久化存储的KV系统,和Redis这种内存型的KV系统不同,level是将大部分数据存储在磁盘上,但是需要将磁盘上的空间格式化为文件系统。
Filestore将数据保存在与Posix兼容的文件系统(例如xfs,btrfs,ext4)。在Ceph后端使用传统的Linux文件系统虽然提供了一些好处,但也有代价,如性能、对象属性与磁盘本地文件系统属性匹配存在限制等。
由于leveldb依然需要磁盘文件系统的支持,后期facebook对其进行改进产生了rocksdb。
使用bluestore时,会在osd中划分出一部分空间,格式化为BlueF文件系统用于保存rocksdb中的元数据信息,并实现元数据的高可用。
Bluestore的最大特点是构建在裸磁盘设备之上,并且对诸如SSD等设备做了很多优化工作。它拥有以下优势:
RocksDB通过中间层BlueRocksEnv访问文件系统接口。这个文件系统就是BlueFS,它与传统的Linux文件系统是不同的,它不是VFS下的通用文件系统,而是一个用户态的逻辑。BlueFs通过函数接口(API,非POSIX)的方式为BlueRocksEnv提供类似文件系统的能力。
Bluestore的逻辑架构如上图所示,其中各模块的作用如下:
Bluestore的设计考虑了Filestore中存在的一些问题,抛弃了传统的文件系统直接管理裸磁盘设备,缩短了IO路径,同时采用ROW方式,避免日志双写问题,在性能上有了极大提高。
CRUSH是指Controllers replication under scalable hashing,可控的、可复制的、可伸缩的一致性hash算法
Ceph使用Crush算法来存放和管理数据,它是Ceph的智能能数据分发机制。Ceph使用Crush算法来准确计算数据应该被保存到哪里,以及从哪里读取数据。和存储元数据不同的是,Crush按需计算出元数据,因此它就消除了对中心式的服务器/网关的需求,它使得Ceph客户端能够计算出元数据,该过程也称为Crush查找,然后直接和OSD通信。