1 分布式存储概述：

1.1 存储分类：

单机存储：

单机存储性能始终有限

SCSI/IDE/SATA//SAS/USB/PCI-E/SSD/M.2 NVME 协议(提升性能)

网络存储(带文件系统)：

考虑到数据的高可用我们不得不考虑网络存储

NFS

Samba

NAS (Network Attached Storage：网络附属存储)

SAN:SAN（Storage Area Network，存储区域网络)

1.1.1 存储考虑:

单机:

单机存储的磁盘空间问题、IO 问题、扩容问题、高可用问题:

商业:

商业解决方案-EMC、NetAPP、戴尔、华为、浪潮

分布式存储:

(软件定义的存储 Software Defined Storage SDS):

https://www.vmware.com/cn/products/software-defined-storage.html

分布式存储：Ceph,TFS,FastDFS,MogileFS,MooseFS,GlusterFS

ceph 支持对象、文件、块 这三种存储方式：

对象存储：就类似于阿里云上的 oss 对象存储，对象存储可以被多个服务通过 API 的方法进行访问

文件存储：类似于 NFS 一样，可以被多个服务器同时挂载，一般用于 web 服务、如 nginx + java 服务来实现数据的共享，java 服务提供数据的写入、nginx 复杂读取数据，这种情况就可以使用文件存储

块存储：一般提供给 K8S 中的有状态服务来使用，如：数据库主从、ZooKeeper 集群 等等，块存储是一对一的，一般是一个存储被一个服务挂载

ceph 的这三种存储类型可以同时开启，或者只开其中的一个或者两个存储功能也可以

ceph 同时支持横向扩容

块存储：需要格式化成操作系统支持的文件系统，将文件直接保存到磁盘上，块存储的兼容性较好，可以兼容各种操作系统(使用较少)。

文件存储：提供数据存储的接口，是由操作系统针对块存储的应用，即由操作系统提供存储 接口，应用程序通过调用操作系统将文件保存到块存储进行持久化。

对象存储：也称为基于对象的存储，其中的文件被拆分成多个部分并散布在多个存储服务器，在对象存储中，数据会被分解为称为“对象”的离散单元(也就是将一个存储文件拆分为多个若干个小份存储资源)，并保存在单个存储库中，而不是作为文件夹中的文件或服务器上的块来保存，对象存储需要一个简单的 HTTP 应用编程接口 (API)，以供大多数客户端（各种语言）使用。

阿里网站(结束对象存储)：https://www.aliyun.com/product/oss

红帽网站(介绍什么是块存储和文件存储)：https://www.redhat.com/zh/topics/data-storage/file-block-object-storage

1.1.2 有状态集群数据读写特性:

数据分为读数据和写数据，读可以在任何一个节点读，但是写只能写在特定的节点，如 Redis 的 master、zookeeper 的 leader、MySQL 的 master 等场景。

这种服务是有角色概念的，角色不能随意更换，谁是主的就只能一直是主节点，所以这种场景在数据进行读取的时候就分为读数据和写数据，谁读谁写也是有规定的。只能在 master 写入、如果在 slave 节点写入的话就会导致数据的不一致。

对于 K8S 来跑这些服务就得结合存储来实现有状态服务的数据持久化。如：Ceph 的块存储只给一个服务去使用，哪怕这个服务在 K8S 里面他的主机宕了，这个服务被调度到别的节点上了，这时候 Ceph 的块存储就会一直跟着容器去走，哪怕这个容器被重建了 Ceph 也会保证数据的稳定性而不会丢失。可以逐渐恢复数据

1.2 分布式存储数据特性：

数据分为数据本身和元数据：

元数据即是文件的属性信息(文件名、权限(属主、属组)、大小、时间戳等)，在分布式存储中当客户端或者应用程序产生的客户端数据被写入到分布式存储系统的时候，会有一个服务(Name Node)提供文件元数据的路由功能，即告诉应用程序去哪个服务器去请求文件内容，然后再有(Data Node)提供数据的读写请求及数据的高可用功能。

1.2.1 Ceph 是如何实现高可用

如上图中的 NameNode 是放置元数据的信息，这个元数据是告诉我们的存储客户端也就是我们需要存储功能的应用程序，它应该去那个服务器请求文件类，这时候 NameNode 会告诉客户端 APP ，我的这个数据文件在某个服务器上也就是(DataNode)，然后再由 DataNode(存储节点) 去提供数据的读写以及数据的高可用的问题

对于 Ceph 是如何实现数据高可用的：

Ceph 会将数据写成 3 份(如上图)，这种方式叫做 3 副本集（副本池）一主两备是 Ceph 默认的机制通过这种机制来保证数据的高可用，而且两 salve 是跨主机的不能放到同一个宿主机上，当然我们的副本集可以动态调整。

如果这个 APP 客户端写入了一个 File 文件，会往 DataNode1 写一份，比如这里 DataNode1 是我们的存储集群主节点 OSD(OSD 是 Ceph 里面存储数据的一个磁盘服务)，当数据写入到 DataNode1 节点之后，再由 DataNode1 节点往另外两个节点(2,3)进行同步，并且这个 File 文件会被拆分(如客户端写入的数据是 12M Ceph 默认拆分数据为每一份 4M 一个 OSD 放置一份)放置到不同的 Ceph 集群上所有节点放一份。而且数据在 Ceph 集群中是实时写入，也就是说master 节点接收到数据的那一刻就会将数据写入到 slave 节点，直到 Ceph 集群所有的节点数据同步完成才会告诉客户端数据写完了，如果 slave 节点数据没有写完是不会告诉客户端的，Ceph 就是通过这种方式来实现数据的高可用

这个时候无论 Ceph 集群中那个服务器宕机了都不会影响数据的可用性，如果说 node2 和 node3 宕了会出现 node1 主节点的数据没有问题，但是 slave 的数据丢了一个，但是并不会影响 APP 的读写，这个时候 APP 就会再 master 节点上进行读写操作(Ceph 的读写都是在主节点的 DSO)。

搭建 Ceph 注意事项：

如果是主节点宕机了，node2 和 node3 会进行接管，会通过选举机制选举出来一个新的 master，而且由于数据是通过网络实时同步，并不会出现数据不同步的问题

所以在搭建 Ceph 的时候网卡的选择很重要，一般在 Ceph 集群中都是使用多网卡，其中一块网卡就是提供给 Ceph 集群用来同步数据的，一般 Ceph 推荐使用万兆网卡

但是走单块网卡也不是不行，就是怕如果用户的访问量很高，出现了数据同步延迟的问题

2 Ceph 基础

Ceph 是一个开源的分布式存储系统，同时支持对象存储、块设备、文件系统

ceph 是一个对象(object)式存储系统，它把每一个待管理的数据流(文件等数据)切分为一到多个固定大小(默认 4 兆)的对象数据，并以其为原子单元(原子是构成元素的最小单元)完成数据的读写。

对象数据的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的对象存储系统。 librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php/go等编程语言客户端。

2.1 Ceph 发展史

Ceph 项目起源于 于 2003 年在加州大学圣克鲁兹分校攻读博士期间的研究课题（Lustre 环 境中的可扩展问题）.

Lustre 是一种平行分布式文件系统,早在 1999 年，由皮特·布拉姆(Peter Braam)创建的集 群文件系统公司(Cluster File Systems Inc)开始研发,并于 2003 年发布 Lustre 1.0 版本. 

2007 年 Sage Weil(塞奇·威尔)毕业后，Sage Weil 继续全职从事 Ceph 工作，2010 年 3 月 19 日，Linus Torvalds 将 Ceph 客户端合并到 2010 年 5 月 16 日发布的 Linux 内核版本2.6.34,2012 年 Sage Weil 创建了 Inktank Storage 用于为 Ceph 提供专业服务和支持,2014 年 4 月 Redhat 以 1.75 亿美元收购 inktank 公司并开源.

2.2 Ceph 的设计思想

Ceph 的设计旨在实现以下目标： 
每一组件皆可扩展 
无单点故障 
基于软件(而非专用设备)并且开源(无供应商锁定) 
在现有的廉价硬件上运行 尽可能自动管理，减少用户干预

2.3 Ceph 的版本历史

Ceph 的第一个版本是 0.1,发布日期为 2008 年 1 月,多年来 ceph 的版本号一直采用递归更 新的方式没变,直到 2015 年 4 月 0.94.1(Hammer 的第一个修正版)发布后,为了避免 0.99(以及 0.100 或 1.00),后期的命名方式发生了改变:

• x.0.z – 开发版（给早期测试者和勇士们）

• x.1.z – 候选版（用于测试集群、高手们）

• x.2.z – 稳定、修正版（给用户们）

x 将从 9 算起，它代表 Infernalis(首字母 I 是英文单词中的第九个字母),这样我们第九个发布周期的第一个开发版就是 9.0.0,后续的开发版依次是 9.0.0->9.0.1->9.0.2 等,测试版本就是 9.1.0->9.1.1->9.1.2,稳定版本就是 9.2.0->9.2.1->9.2.2

到 2017 年底，Ceph 项目都采取每年发布两个稳定版本的做法,从 Jewel 版到 Nautilus 之前，Ceph 经历过一段时间的每间隔 9 个月发布一个新版本,Nautilus 版本开始改为每年春季 3 月 份发布一个稳定版本,并提供长达 26 个月左右的后期版本更新.