分布式存储Ceph
分布式存储Ceph
一、存储分类
本地存储：ext3\ext4\xfs，不能在网络上用
网络存储
网络文件系统：共享文件系统
nfs网络文件系统：通过网络共享资源，用户访问服务器文件系统，它可以将远程的磁盘挂载到本地，当本地的磁盘使用。
分布式网络文件系统：hdfs\glusterfs
共享裸设备
块存储 cinder ceph(块存储 对象存储 网络文件系统-分布式)
SAN(存储区域)
分布式：集群
分布式存储分类
Hadoop HDFS(大数据分布式文件系统)
HDFS(Hadoop Distributed File System)是一个分布式文件系统，是hadoop中的存储组件，是一个高度容错性的系统，能提供高吞吐量的数据访问，适合大规模数据集上的应用。
优点
高容错：自动保存多个副本，副本丢失自动恢复
良好的数据访问机制：一次写入，多次读取，保证数据一致性。
适合大数据文件存储，扩展能力强。
缺点
低延迟数据访问：难以应付毫秒级以下的应用
海量小文件存取会占用大量内存
一个文件只能有一个写入者，仅支持追加。
OpenStack的对象存储Swift
OpenStack是开源云计算项目的子项目之一，Swift的目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群，是python开发的。
特点
各存储节点完全对等，是对称的系统架构。
开发者通过一个RESTful HTTP API与对象存储系统相互作用。
无单点故障：Swift的元数据存储是完全均匀随机分布的，与对象文件存储一样，元数据也会存储多份，没有一个角色是单点的。
在不影响性能的情况下，集群通过增加外部节点进行扩展。
无限的可扩展性：存储容量的无线可扩展性，Swift性能（如Qps、吞吐量等）可线性提升，扩充只需要简单地新增机器，系统自动完成数据迁移，使各存储节点重新达到平衡状态。
极高数据的持久性
用途
图片、文档
长期保存的日志文件
存储媒体的照片、音乐、视频等
视频监控文档的存储
总结：Swift适合用来存储大量的、长期的、需要备份的对象
公有云对象存储
公有云大多都只有对象存储，例如谷歌云存储使一个快速、具有可扩展性和高可用性的对象存储。
Amazon类似产品就是S3 : http://aws.amazon.com/s3;
微软类似的产品Azure Bolb
阿里类似的有OSS
二、ceph介绍
1.1 ceph是什么
Ceph是一个统一的、分布式的存储系统，设计初衷是变成一个可避免单点故障的分布式文件系统，提供较好的性能、可靠性和可扩展性。通过网络将数据分散存储在多台独立的设备上。
统一的：支持多种存储的应用形式，如块存储、文件存储、对象存储。
块级：block块，又称之为物理块，是操作系统读写硬盘的单位，一个逻辑块对应一个物理块
文件级：逻辑文件---切分---》多个逻辑文件块---》物理块block---->扇区
1、块存储：存储设备共享给客户端的是一块裸盘，那么该存储设备提供的就是块存储
主要是将裸磁盘空间映射给主机使用，类似于SAN存储，使用场景主要是文件存储，日志存储，虚拟化镜像文件等。
特点：客户端可定制性强，可以自己制作文件系统，然后挂载使用，或者直接可以把操作系统安装在块存存储，主要用于vm的本地硬盘
优点：通过Raid(磁盘阵列)与LVM等手段对数据提供了保护，多块廉价的硬盘组合起来提高容量，多块磁盘组合出来的逻辑盘提升读写效率。
缺点：采用SAN架构组网时，光纤交换机造价成本高，主机之间无法共享数据。
应用场景：Docker容器、虚拟机磁盘存储分配，日志存储，文件存储
2、文件存储：为了解决数据共享，并且保持一致，存储设备中分出一块空间，然后制作文件系统，然后在存储设备中完成挂载，再共享给客户端。
典型代表：FTP 、NFS 为了克服块存储无法共享的问题，所以有了文件存储，在服务器上架设FTP与NFS服务就是文件存储。
特点： 客户端定制性差，不能自己制作文件系统，问价系统在存储设备中制作好的，客户端使用的就是一个文件夹
文件的检索与存储过程都是在存储设备完成，意味着随着客户端数目的增多存储设备的压力就会越大，所以文件存储会限制集群的扩展规模。
优点：造价低，可共享
缺点：读写速度低，传输速度慢。
使用场景：日志存储，有目录的文件存储，使用与中小规模集群
3、对象存储：为了解决多服务器之间共享数据，并且保证一致，没有文件系统的概念，数据的存储分为两部分元数据+内容，客户端通过url地址的方式提交元数据与内容。
具备块存储的读写高速和文件存储的共享等特性并且通过 Restful API 访问，通常适合图片、流媒体存储。
为什么需要对象存储
一个文件包含了一些属性（metadata，元数据，例如文件大小，修改时间，存储路径等）以及内容，简称数据。
对象存储是将元数据独立了出来，控制节点叫元数据服务器NameNode（服务器+对象存储管理软件），主要负责存储对象的属性（主要是对象的数据被打散存放到那几
台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储数据的文件部分，当用户访问对象时，先去访问元数据服务器，元数据服务器
只负责反馈对象存储在那些OSD，假设反馈文件A 存储在B\C\D三台osd，那么用户会再次访问这3台OSD服务器去读取数据。
这时候由于时3台osd同时对外传输数据，所有传输速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过这种方式实现了读写快的目的。
另一方面对象存储有专门的文件系统，所有OSD对外又相当于服务器，那么就不存在文件共享方面的问题，故对象存储很好的结合了快存储与文件存储的优点。
特点：没有文件检索的压力，服务器不会随着客户端数目的增多压力成倍增大
优点：具备块存储的高速读写，具备文件存储的共享等特性。
使用场景（适合存储变动较少的文件）：图片存储，视频存储。
Ceph同时提供对象存储、块存储和文件存储三种功能，满足不同应用需求
分布式：
传统集群架构，集群规模增大，mysql数据库的集群规模必然也随之增大，这完全就是集中式的思想带来的弊端。
ceph内部集群的数据共享完全是通过算法算出来，根本不需要数据库这个组件。
ceph缺点：耗费CPU
任何集群追求的三大特点：
1、性能
2、可靠性：没有单点故障
3、可扩展性，未来可以理论上无限扩展集群规模
1.2ceph特性
高性能：数据分布平衡
a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。
高可用性：没有单点故障，多数据副本，自动管理，自动修复
a. 副本数可以灵活控制。
b. 支持故障域分隔，数据强一致性。
c. 多种故障场景自动进行修复自愈。
d. 没有单点故障，自动管理。
高可扩展性：使用普通的x86服务器，支持10-1000台服务器，支持TB到EB级的扩展
a. 去中心化。
b. 扩展灵活。
c. 随着节点增加而线性增长。
特性丰富
a. 支持三种存储接口：块存储、文件存储、对象存储。
b. 支持自定义接口，支持多种语言驱动。
1.3 ceph架构
rados：基础存储系（Reliable，Autonomic，Distributed Object Store，可靠的，自动化的，分布式对象存储），所有存储在Ceph系统中的用户数据事实上最终都由这一层来存储，Ceph的高可靠性、高扩展 性、高自动化特性本质上也是这一层所提供的。
ceph集群称之为rados，ceph集群相当于网络版的raid01
ceph集群的子集群：
osd daemon集群：是一个套接字应用程序，唯一对应一块数据盘（数据盘的组成可以是一块机械硬盘+一块固态盘的两个分区）
基础库librados:这一层是对rados进行抽象和封装，并向上层提供API，以便直接基于rados(而不是整个ceph)进行应用开发，rados是一个对象存储系统，因此，librados实现的API也只是针对对象存储功能 的。Libradio 是RADOS提供库，因为 RADOS 是协议，很难直接访问，因此上层的 RBD、RGW和CephFS都是通过libradios访问的，目前提供 PHP、Ruby、Java、Python、C 和 C++的支持。
高层应用接口：在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层应用接口
radosgw:对象网关接口（对象存储）
rbd：块存储
cephfs：文件存储系统
1.3 Ceph的核心组件
Osd ： 用于集群中所有数据与对象的存储，处理集群数据的复制、恢复、回填、再均衡，并向其他osd守护进程发送心跳，然后向mon提供一些监控信息，当ceph存储集群设定数据有量个副本时（一 共存两份），则至少需要两个OSD守护进程，即两个OSD节点。集群才能达到activate+clean（可用）状态。
扩展：对象存储（Object-base Storage）是一种新的网络存储架构。基于对象的存储技术的设备就是对象存储设备（Object-base Storage Device）简称OSD，总体来讲综合了NAS和SAN的优点。SAN存储 设备通过光纤连接，而NAS存储设备通过TCP/IP连接。对象存储同时具有SAN的高速访问和NAS的分布式数据共享优势，提供了具有高性能高可靠性、跨平台以及安全的数据共享的存储体系结构。
1.4 Ceph工作原理
1.4.1Cephs数据的存储过程
无论使用哪种存储方式（对象、块、挂载），存储的数据都会被切分成对象（Object）,Object size大小可以由管理员调整，通常为2M或4M，每个对象有一个唯一的oid，由ino与ono生成，ino即文件id，ono即分片编号，但是对象不会直接存储到OSD中，因为对象的size很小，在一个大规模的集群中可能有几百到几千万个对象，这么多对象光遍历寻址速度都很慢，并且如果将对象直接通过某种固定映射的哈希算法映射到OSD上，当这个OSD损坏了，对象无法自动迁移到其他OSD上面（因为映射函数不允许），为解决这个问题，ceph引入了归置组的概念，即PG。
1、ceph是一种伪数据平衡，是通过算法达到的
object---hash算法--->PG---crush算法--->osd daemon
2、ceph适用于海量文件，或者单个文件容量大
object和PG是多对一的，一个osd damon肯定不能属于一个PG组，因为ceph是PG组为单位来分配数据的，如果一个osd daemon只属于一个PG组，那么该osd daemon将只能收这一个PG组发来的数据，如果该PG组没有被hash算法算到，那么就不会收到数据，于是该osd daemon就被闲置了，所以一个osd应该属于多个pg组，到底应该属于多少个呢？
官方建议：如果ceph集群很长一段时间不会拓展，一个osd daem
on属于100个pg组，否则一般建议osd daemon属于200个pg组。
ceph的逻辑单位：
1、pool(存储池)：
在创建存储池时需要指定pg个数，来创建pg，创建pg需要用到crush算法，crush决定了pg与osd daemon之间的对应关系，所以说，在客户端往ceph中写入数据之前，pg与osd daemon的对应关系是已经确定的，虽然是确定的，但是pg与osd daemon的对应关系是动态的
2、pg（归置组）是分配数据的最小单位，一个pg内包含多个osd daemon
primary osd
replication osd
rados存储完毕后，为客户端提供存储服务，需要
1、创建存储池pool，存储池中包含100个PG ceph osd pool create rbdtest 100 2、设置pool池的副本数，即一个pg包含多少个osd daemon,往某一个pg中存的数据会在其包含的osd中都保存一份
ceph osd pool set rbdtest size 3
3、在存储rbdtest中创建一个镜像给客 户端用，一个image用的是存储池中的pg(并非指定的pg，
而是只要是存在与pool中的pg都可能会用到)，相当于一个配额。
rbd create rbdtest --size 10000 egon #image名为egon,大小为10000M
1.5 RADOS的子集群
ceph的底层是Rados，而RADOS由多个子集群构成
1、若干个数据盘：一个Ceph存储节点可以有一个或多个数据盘，每个数据盘上部署有特定的文件系统，比如xfs、ext4或者btrfs，可以是一个分区当一个disk，可以是一个raid当一个disk，也可以是一整块盘当一个disk，但依据经验，一整块盘当一个disk效率更稳定。
2、OSD(Object Storage Device)集群：一个做好文件系统的disk由一个OSD Daemon管理，主要负责
1、负责控制数据盘文件的读写操作，与Client通信完成各种数据对象操作等。
2、负责数据的拷贝和恢复
3、每个osd守护进程监视自己的状态，以及pg组内的其他osd的状态，并且报告给Monitor
在一个服务器上，一个数据盘对应一个osd daemon，而一个服务器上可以有多个数据块，所以一台服务器就hi运行多个OSD daemon，该服务器称之为OSD节点。一个CEPH集群中有n个OSD节点，综合算下来，OSD集群由一定数目的（从几十到几万个）OSD Daemon组成。
3、MON（Monitor）集群（整个集群的大管家）：
1、监控全局状态--》cluster map
1、osd daemon map
2、monitor map
3、pg map
4、crush map
2、负责管理集群内部状态（osd daemon挂掉，数据恢复等操作）
3、负责授权。
客户端在访问时会先通过monitor验证操作权限
客户端需根monitor要到cluster map
ps monitor节点的个数=2*n+1,最少三个的奇数个，一个也可以但是不应该有单点故障
1、为何monitor节点个数应该为奇数个：因为monitor节点同步数据用的是paxos算法（分布式强一致算法），这个算法规定至少有3个节点。
2、可以挂掉几个monitor节点？不能超过半数挂掉
3、monitor进程与osd daemon能否在同一个物理节点上？可以但是不好，但是这是一种集中式的思想。
，
1.6 rados的网络结构
ceph存储池pool
ceph的pool有四大属性
1、所以性和访问权限
2、对象副本数目，默认pool池中的一个pg只包含两个osd daemon，即一份数据交给pg后会存下两个副本，生产环境推荐设置为3个副本
3、PG数目、PG是pool的存储单位，pool的存储空间由pg组成
4、CRUSH规则集合
创建存储池时，要设置的两个东西
1、pg数目，决定了数据的均匀性
创建pool时需要确定PG的数目，在pool被创建后也可以调整该数字，但是增加池中的PG数是影响ceph集群的重大事件之一，生成环境中应该避免那么做，因为pool中的pg数量会影响到
（1）数据的均匀分布性：CRUSH算法会伪随机地保证PG被选中来存放客户端的数据，它还会尽可能地保证所有PG均匀分布在所有OSD上，即ceph是伪数据平衡，如果只有一个PG，一个PG里副本数为3，那么只有一块PG被用到。
（2）资源消耗：PG作为一个逻辑实体，它需要消耗一定的资源，包括内存、CPU和带宽、太多PG会消耗很多资源
（3）清理时间：ceph的清理工作是以PG为单位的，如果一个PG内的数据太多，则其清理时间会很长。
（4）数据的持久性：pool中的PG个数应该随着osd daemon的增多而增多，这样crush算法可以将pg与osd的对应关系尽量均匀一些，降低同一个osd属于很多很多pg的几率，如果一个osd真的属于很多很多pg，这有可能会很糟糕。
osd deamon上的pg数目
1、不能过小，过小则数据不均匀
2、不能过大，过大则一个osd daemon挂掉影响范围会很广，这会增大数据丢失的风险。
这个数目应该刚刚好，我们无法决定，是算法决定的，但是我们可以决定送给算法的参数，该参数指的是存储池内所包含的PG数量，只要把该数目设置合理，算法自然会保证数据均匀。
计算公式：
Target PGs per osd:打算让一个osd daemon归属于多少个PG(官网建议100个或200)
OSD#:osd daemon的总数
%Data:该存储池空间占ceph总可用空间的百分比。
Size:存储池中的副本数
如果小于5个OSD daemon，建议将pool中的pg数设为128
如果是5到10个OSD daemon，建议将pool中的pg数设为512
如果是10到50个OSD daemon，建议将pool中的pg数设为4096
如果是50个osd daemon以上，再用这个公式算,官网上可以直接算
ceph osd pool create 存储名 pg_num
1.7Ceph的存储方式
Radosgw：Ceph对象网关
Ceph对象网关是一个对象存储接口，建立在该对象之上，librados为应用程序提供了通往Ceph存储集群的RESTful网关，ceph对象存储支持两个接口：
与S3兼容，为对象存储功能提供与Amazon S3 RESTful API的大部分子集兼容的接口
兼容Swift,通过与OpenStack Swift API的大部分子集兼容的接口，为对象存储功能提供支持。
ceph对象存储使用Ceph对象网关守护进程（radosgw）,它用于与ceph存储群集进行交互的HTTP服务器，由于它提供与OpenStack Swift和Amazon S3兼容接口，因此ceph对象网关具有其自己的用户管理，Ceph对象网关可以将数据存储在用于存储来自Ceph文件系统客户端或Ceph块设备客户端的数据同一ceph存储群集中，S3和Swift API共享一个公共的名称空间，因此您可以使用一个API编写数据，而使用另一个API检索数据。
ceph文件系统
ceph文件系统（CephFS）是个POSIX兼容的文件系统，它使用Ceph存储集群来存储数据。Ceph文件系统与Ceph块设备，同时提供S3和Swift API的Ceph对象存储、或者原生库（librados）都使用着相同的Ceph存储集群系统。
ceph块存储
块是一个字节序列（例如，一个512字节的数据块），基于块的存储接口是最常见的存储方法，他们基于旋转介质，像硬盘、CD、软盘，无处不在的块设备接口使虚拟块设备成为与Ceph这样的海量存储系统交互的理想之选。
ceph块设备是精简配置的，大小可调且将数据条带化存储到集群内的多个OSD，Ceph块设备利用RADOS的多种能力，如快照、复制和一致性，ceph的RADOS块设备（RBD）使用内核模块或者librbd库与OSD交互。
存储引擎
hammer:
存储引擎filestore：osd daemon——》xfs文件系统——》磁盘
luminous:
存储引擎bluestore：osd daemon----》裸磁盘
通常的做法如下：为何要这么做
osd daeomon --LVM--》裸磁盘
如果ceph集群即将用满了应该怎么扩容，如何扩容？
方案一：
osd daemon----》裸磁盘下的扩容方式
新增一块磁盘，用一个osd daemon管理它，但问题是，新增一个osd daemon，ceph会在该osd daemon上创建一个PG ，说白了就是把该osd daemon划分到一些pg组里，但但凡一块osd daemon被分配到了pg里，会发生数据迁移。
线上环境：pg数能不动就不动
方案二：
osd daeomon --LVM--》裸磁盘 下的扩容方式
从vg组里划分更多的空间给LVM，不必新增osd daemon
总结：如果集群考虑考虑到日后要扩容，那么推荐使用方案，daeomon --LVM--》裸磁盘 下的扩容方式。
