分布式存储概述
常用的存储可以分为DAS、NAS和SAN三类
- DAS：直接连接存储，是指通过SCSI接口或FC接口直接连接到一台计算机上，常见的就是服务器的硬盘
- NAS：网络附加存储，是指将存储设备通过标准的网络拓扑结构（比如以太网），连接到计算机上使用。例如NFS和Samba文件共享系统
- SAN：存储区域网络，目前SAN存储有两种，一是基于光纤通道的FC SAN，二是基于以太网的IP SAN，也就是iscsi
常见的存储类型有文件存储、块存储和对象存储
- 文件存储：对于需要多个主机实现数据共享的场景可以使用，例如nginx读取由多个tomcat写入的数据场景
- 块存储：块存储在使用的时候需要格式化为指定的文件系统，然后挂载使用，对操作系统兼容性较好。私有云和公有云虚拟机的磁盘就可以使用块存储
- 对象存储：适用于数据不会经常变化、删除和修改的场景。例如短视频、APP下载等可以使用对象存储
常用的存储设备包括：单机存储、商业存储和分布式存储。
分布式存储是一种数据存储技术，通过网络使用企业中每台机器上的磁盘空间，并将这些分散的存储资源构建为一个虚拟的存储设备，数据分散存储在企业的各个角落。
常见的分布式存储包括：Ceph、GlusterFS、TFS、FAstDFS等
在分布式存储系统中，将数据分为数据和元数据。元数据就是文件的属性信息（文件名、权限、大小、时间戳等），当客户端将产生的数据写入到分布式存储系统中的时候，，会有一个服务（Name node）提供文件元数据路由的功能，即告诉客户端去哪个服务器请求文件内容，然后再由数据存储节点（Data node）提供数据的读写请求及数据的高可用
ceph介绍
ceph官网：https://ceph.io/en/
ceph官方文档：https://docs.ceph.com/en/quincy/
Ceph是一个开源的分布式存储系统，同时支持对象存储、块设备、文件系统。
Ceph支持EB（1EB=1,000,000,000GB）级别的数据存储，ceph把每一个待管理的的数据流（文件等数据）切分为一到多个固定大小的对象数据，并以其为原子单位完成数据的读写。
ceph的优势：
-
高性能
- 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高
- 能够支持上前节点存储规模，支持TB到PB级别数据存储
-
高可用性
- 副本数可以灵活控制
- 支持故障域分割，强一致性
- 多种故障场景自动进行修复自愈
- 没有单点故障，自动管理
-
高可扩展性
- 去中心化，扩展灵活
-
特性丰富
- 同时支持块、对象和文件存储，支持多语言客户端
ceph架构
如上边两张图所示，在ceph存储系统中，最底层是rados存储集群，然后上面是逻辑划分的pool和PG。再上层是librados，相当于rados集群的API接口。
ceph提供三种存储方式：radosgw（对象存储）、rbd（块存储）、cephfs（文件系统存储）。其中radosgw和rbd是基于librados实现的，cephfs则是直接在rados集群上实现的。用户可以通过不同的方式调用这三种存储接口存取数据，当然也可以直接通过librado存取数据。
但不论以哪种方式存取数据都需要指定pool，数据会映射到pool的pg上。
Rados集群
一个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接口使用，用来存储文件元数据
ceph数据读写流程
首先说明一下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元数据保存方式
在ceph中，对象的元数据以key-value的形式存在，在rados中有两种实现：xattrs和omap。
- xattrs（扩展属性）：是将元数据保存在对象对应文件的扩展属性中并保存到系统磁盘上，这要求存储对象的本地文件系统（一般是xfs）支持扩展属性
- omap（object map对象映射）：是将元数据存储在本地文件系统之外的独立key-value存储系统中，在使用filestore时是leveldb，在使用bluestore时是rocksdb。
ceph可选后端支持多种存储引擎，比如filestore、bluestore、memstore等。早期主要使用filestore，但由于filestore存在一些问题（对ssd设备支持不够好，写放大等），所以目前主要使用bluestore。
filestore与leveldb
ceph早期使用filestore+leveldb组合来保存数据和元数据，leveldb是一个持久化存储的KV系统，和Redis这种内存型的KV系统不同，level是将大部分数据存储在磁盘上，但是需要将磁盘上的空间格式化为文件系统。
Filestore将数据保存在与Posix兼容的文件系统（例如xfs，btrfs，ext4）。在Ceph后端使用传统的Linux文件系统虽然提供了一些好处，但也有代价，如性能、对象属性与磁盘本地文件系统属性匹配存在限制等。
Bluestore和rocksdb
由于leveldb依然需要磁盘文件系统的支持，后期facebook对其进行改进产生了rocksdb。
使用bluestore时，会在osd中划分出一部分空间，格式化为BlueF文件系统用于保存rocksdb中的元数据信息，并实现元数据的高可用。
Bluestore的最大特点是构建在裸磁盘设备之上，并且对诸如SSD等设备做了很多优化工作。它拥有以下优势：
- 对全SSD及NVMe SSD闪存适配
- 绕过本地文件系统层，直接管理裸设备，缩短IO路径
- 严格分离元数据和数据，提高索引效率
- 使用KV索引，解决文件系统目录结构遍历效率低的问题
- 解决filestore日志双写问题
- 增加数据校验和数据压缩功能
RocksDB通过中间层BlueRocksEnv访问文件系统接口。这个文件系统就是BlueFS，它与传统的Linux文件系统是不同的，它不是VFS下的通用文件系统，而是一个用户态的逻辑。BlueFs通过函数接口（API，非POSIX）的方式为BlueRocksEnv提供类似文件系统的能力。
Bluestore的逻辑架构如上图所示，其中各模块的作用如下：
- RocksDB：Bluestore将元数据全部存放RocksDB中，这些元数据包括存储预写式日志（WAL）、对象元数据、ceph的omap数据信息以及分配器的元数据。
- BlueRocksEnv：这是RocksDB与BlueFS交互的接口；RocksDB提供了文件操作的接口EnvWrapper（Env封装器），可以通过继承实现该接口来自定义底层的读写操作，BlueRocksEnv就是继承自该EnvWrapper实现对BlueFs的读写
- BlueFS：BlueFS是Bluestore针对RocksDB开发的轻量级文件系统，用于存放RocksDB产生的.sst文件和.log文件
- BlockDevice：Bluestore抛弃了传统的ext4、xfs文件系统，使用直接管理裸盘的方式；Bluestore支持同时使用多种不同类型的设备，在逻辑上Bluestore将存储空间划分为三层：慢速（Slow）空间、高速（DB）空间、超高速（WAL）空间，不同的空间可以指定使用不同的设备类型，当然也可以使用同一块设备
Bluestore的设计考虑了Filestore中存在的一些问题，抛弃了传统的文件系统直接管理裸磁盘设备，缩短了IO路径，同时采用ROW方式，避免日志双写问题，在性能上有了极大提高。
CRUSH算法简介
CRUSH是指Controllers replication under scalable hashing，可控的、可复制的、可伸缩的一致性hash算法
Ceph使用Crush算法来存放和管理数据，它是Ceph的智能能数据分发机制。Ceph使用Crush算法来准确计算数据应该被保存到哪里，以及从哪里读取数据。和存储元数据不同的是，Crush按需计算出元数据，因此它就消除了对中心式的服务器/网关的需求，它使得Ceph客户端能够计算出元数据，该过程也称为Crush查找，然后直接和OSD通信。
