分布式存储ceph
一、ceph介绍
1.1、ceph是什么
nfs 网络存储
ceph是一个统一的、分布式的存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。
# “统一的”:意味着我们可以仅凭ceph这一套存储系统，同时提供对象存储、块存储和文件系统存储三种功能，这极大地简化了不同应用需求下的部署和运维工作。
# “分布式”:ceph实现了真正的去中心化，理论上可以无限扩展集群系统的规模
# ceph:
统一的：同时支持多种存储的应用形式
1、块存储
2、文件存储
3、对象存储
分布式：
传统集群架构：集群规模增大，mysql数据库的集群规模必然也要随之增大，这完全就是集中式思想带来的弊端 了解:
Ceph项目最早起源于Sage就读博士期间的工作(最早的成果手2004年发表)，并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。 1.2什么是块存储、文件存储、对象存储
1.21 备知识: 块级与文件级
- 1、块级
磁盘的最小读写单位为扇区，1个或多个连续的扇区组成一个block块，也叫物理块,是操作系统读写硬盘的单位
[root@admin ~]# blockdev --getbsz /dev/sda1
512 - 文件级
文件是文件系统提供的功能，单个文件可能由于一个或多个逻辑块组成，且逻辑块之间是不连续分布。逻辑块大于或等于物理块整数倍
物理块与文件系统之间的映射关系为:
逻辑文件----切分----》多个逻辑文件块----》物理块block---->扇区
# 注意:
这么多层转换，肯定是需要耗费效率的，如果操作的是对象，则可以直接省去这么多层映射关系，效率自然是高 
1.2.2 块存储、文件存储、对象存储
1.块存储
块存储:存储设备共享给客户端的是一块裸盘，那么该存储设备提供的就是块存储
特点：
1、客户端可定制性强，可以自己可以制作文件系统，然后挂载使用，或者直接把操作系统安装在块存储里
用途：
主要用于vm的本地硬盘 2. 文件存储
文件存储：为了解决多服务器之间共享数据，并且保证一致
存储设备中分出一块空间，然后制作文件系统，然后在存储设备中完成挂载，然后把文件夹共享给客户端用
特点：
1、客户端定制性差，不能自己制作文件系统，文件系统是在存储设备中制作好的，客户端使用的就是一个文件夹
2、文件检索与存储过程都是在存储设备中完成的，意味着随着客端数目的增多，存储设备的压力会越来越大，所以文件存储会限制集群的扩展规模
用途：
中小规模集群的多服务器之间共享数据，并且保证一致 3.对象存储
对象存储：为了解决多服务器之间共享数据，并且保证一致，并且没有文件系统的概念，数据的存储分为两部分：元数据+内容
客户端通过url地址的方式提交元数据与内容
特点：
1、没有文件检索的压力，服务端不会随着客端数目的增多压力成倍增大
用途： 分布式 1.3 为何要用ceph
Ceph本身确实具有较为突出的优势,晚听這求电最廉价的设备做最牛逼的存储。
其先进的核心设计思想，概括为人“无需查表，算算就好"。
# 1、高性能
a.摒球不转统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考实了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
c.能够支得上千个存储节点的规模，支持TB到PB级的数据。
# 2、高可透性
a.副本数可以灵活控制。
b.支持故障域分隔，数据强一致性。
c.多种故障场景自动进步烧豐自愈。
d.没有单点故障，自动管理。高可扩展性场丢中心化。
# 3、去中心化
b.扩展灵活。
c.随着节点增加而线性增长。
# 4、特性丰富
a.支持三种存储接口：块存储、文件存储、对象存储。
b.支持自定义接口，支持多种语言驱动。 二 ceph系统的层次结构
1.简介
自下向上，可以将Ceph系统分为四个层次:
基础存储系统RADOS(ReliableAutonomicDistributed Object Store，即可靠的、自动化的、分布式的对象存储)
基础库LIBRADOS
2.高层应用接口:包括了三个部分
1、对象存储接口:RADOS GW(RADOS Gateway)
2、块存储接口:RBD(Reliable Block Device)
3、文件存储接口:Ceph FS(Ceph File Svstem)
应用层:基于高层接口或者基础库librados开发出来的各种APP，或者主机、VM等诸多客户端
提示：rados集群是ceph的服务端，依据高层接口封装的应用则是客户端。
3.ceph四层层次结构
第一层：那些存储接口
第二层：radosge ceph对象网关 （对象存储） librdb （块存储） MDS（文件存储）
第三层：librados基础库
第四层：rados （ceph集群）
三、基础存储系统RADOS（ceph集群）
3.1引入
如果单台单块服务器在牛逼，也是有限的，我们需要考虑它的IO速度和容量。
解决方案:
纵向扩展---->不可能实现一瓶装下长江水
横向扩展---->n盘做raid,相当于一块大盘，在本机使用，但是单台机器可插硬盘的总数也是有限的，仍然会受到限制
如果能通过网络通信，那么就可以打破单台机器的限制:一堆硬盘+软件控制起来
做成硬盘的集群，相当于一个大的网络raid，这就是分布式存储，比如ceph # （横向扩展）
3.2 RADOS 特点
ceph的底层是RADOS，而RADOS由多个子集群构成
ceph内部集群的数据共享完全通过crush算法算出来，根本不需要数据库这个组件，完全式分布式的！
ceph分布式的缺点：
1、耗费cpu
任何集群追求的三大特点：
1、性能-》IO
2、可靠性：没有单点故障
3、可扩展性：未来可以理论上无限扩展集群规模
3.2 RADOS的子集群
pg 归规组
mds 文件系统提供元数据 （文件存储）
monitor 监控集群
osd 复制响应客户端请教返回具体数据的进程
mds 依赖源数据的服务
libradio 基础库
radosge ceph对象网关 （对象存储）
librdb （块存储）
osd daemon相当于套接字 # 默认4M为单位
切割的点叫objiect
# 哈希算法 crush算法
object -- > pg ---> osd daemon
# pg相当于raisdi
ceph： 伪数据平衡，哈希算法达到的
ceph： 适用于海量小文件，或者单个文件容量大（云计算才会用ceph）
object -- > pg # 哈希算法达到的
pg ---> osd daemon # crush算法
1、若干个数据盘:一个Ceph存储节点上可以有一个或者多个数据盘，每个数据盘上部署有特定的文件系统，比如xfs，ext4或者btrfs。可以是一个分区当一个disk，可以是一个raid当一个 disk，也可以是一整块盘当一个disk
#1.btrfs(B-tree 文件系统):功能强大，但耗费资源也高
btrfs是个很新的文件系统(oracel在2014年8月发布第一个稳定版)，它将会支持许多非常高大上的功能，比如透明压缩( transparent compression)，可写的cow 快照(writable oopy-on-write snapshots)、去重(deduplication)和加密(encryption) 。因此，Ceph 建议用户在非关键应用上使用该文件系统。
#2、xfs(推荐）
xfs和 btrfs 相比较ext3/4而言，在高伸缩性数据存储方面具有优势。
# 一整块盘当一个disk
2.OSD（Object Storage Device) 集群：一个OSD daemon 就是一个套接字应用程序，唯一对应一块数据盘
（数据盘的组成可以是一块机械硬盘 + 一个固态盘的两个分区）
1、负责控制数据盘上的文件读写操作，与client（客户端）通信完成各种数据对象操作等等。
2、负责数据的拷贝和恢复
3、每个OSD 守护进程监视它自己的状态 以及别的OSD的状态，并且报告给 Monitor
# 一块硬盘 一个保存元数据，一个存放日志
# 在一个服务器上，一个数据对应一个OSD Daemon，而一个服务器上可以有多块数据盘，所以仅在一台服务器上，就会运行多个OSD Daemon，该服务称之为OS D节点，一个CEPH集群中有n个OSD节点，综合算下来，OSD集群由一定数目的(从几十个到几万个)OSD Daemon组成。
3、MON(Montior)集群:MON集群由少量的、数目为奇数个的Monitor守护进程(Daemon)组成，负责监控ceph所有集群中所有OSD状态及montior集群，一般至少三个。
补充：Ceph核心组件及概念介绍
# Monitor
一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。
# OSD
OSD全称Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。
#MDS
MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务。
#Object
Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据。
#PG
PG全称Placement Grouops（规制组），是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。
# RADOS
RADOS全称Reliable Autonomic Distributed Object Store，是Ceph集群的精华，用户实现数据分配、Failover等集群操作。
# Libradio
Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。
#CRUSH
CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
#RBD
RBD全称RADOS block device，是Ceph对外提供的块设备服务。
#RGW
RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。
#CephFS
CephFS全称Ceph File System，是Ceph对外提供的文件系统服务
例：
# ceph
1、伪数据平衡，是通过算法达到的
object ---hash算法---》pg---crush算法-----》osd daemon
2、ceph适用于海量小文件，或者单个文件容量大
# 1.一个osd daemon应该属于多少个pg组呢？
首先一个osd daemon肯定不能属于一个pg组，因为ceph是pg组为单位来分配数据的，如果一个osd daemon只属于一个pg组，那么该osd daemon将只能收这一个pg组发来的数据如果该pg组没有被hash算法算到，那么就不会收到数据，于是该osd daemon就被闲置了所以一个osd 应该属于多个pg组，到底应该属于多少个呢？
#官方建议：
ceph集群很长一段时间不会拓展：一个osd deamon属于100个pg,否则：一个osd deamon属于200个pg
# 2.ceph的逻辑单位：
1、pool（存储池）：
在创建存储池时需要指定pg个数，来创建pg，
创建pg需要用到crush算法，crush决定了pg与osd daemon的对应关系，所以说，在客户端往ceph中写入数据之前，pg与osd daemon的对应关系是已经确定的，虽然是确定的，但是pg与osd daemon的对应关系是动态的
2、pg（归置组）：是分配数据的最小单位，一个pg内包含多个osd daemon
hammer-》filestore osd daemon---》xfs文件系统----》disk
luminous-》bluestore osd daemon---》裸盘disk
primary osd
replication osd
3、osd deamon负责三件事：（负责具体干活的）
1、读写数据
2、数据的拷贝与恢复
3、监控自己以及pg组内的其它成员的状态，汇报给monitor节点
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、必须为奇数个
2、一个monitor也可以，但是不应该这么做，因为有单点故障
所以最少3个起
1、为何monitor节点个数应该为奇数个
因为monitor节点同步数据用的是paxos算法（分布式强一致性算法）
paxos算法规定至少有三个节点
2、可以挂掉几个monitor节点
paxos算法下，monitor集群不能超过半数挂掉
3、monitor进程与osd daemon能否在同一个物理节点上
可以，但是不好，但是这就是一种集中式的思想了
如果考虑到成本，可以这么做
3.3rados的网络结构
rados作为ceph最核心的部分，是整个ceph的大后端，应该如何架设呢???
**首先:Ceph使用以太网连接内部各存储节点以及连接client 和rados集群。**
然后:Ceph推荐使用两个网络，这么做，主要是从性能(OSD节点之间会有大量的数据拷贝操作)和安全性(两网分离)考虑。
南北网络(apublic(frontside)network)连接客户端和集群
东西网络(acluster(back-side)network)来连接Ceph各存储节点
你可以在Ceph配置文件的[global]部分配置两个网络
public network =(public-network/netmask}
cluster network ={cluster-network/netmask}
四、Ceph集群的逻辑结构
LTS 长期稳定版ceph
4.1核心逻辑概念总览
1、创建存储池poo1，存储池中包含100个pg
ceph osd pool create rbdtest 1oo
2、设置poo池的副本数，即一个的包含多少个OSD Daemon，往某一个pg中存的数据会在其包含的osd中都保存一份
ceph osd pool set rhatest size 3
3、在存储池rdbtest中创建一个镜像给客户端用，一个image用的是存储池中的pg(并非指定的pg，而是只要是存在与pool中的pg都可能会用到)，相当于一个配额
rbd create -p rdbtest --size 10000 yzl # image名为yzl，大小为10000M
在客户端文件会被以4M为单位切成3块，
每块对应一个object
object多对一pg
pg多对多osd daemon
一个pool中有多个pg
从pool中划分出image给用户用，image只是一个配额
写入数据流程大致如下:
librbd
crush算法
file ----->object ------>pool中划分出来的image(一堆pg)------->osd daemon
ceph存储小文件效率不高
底层osd daemon越多，存大文件效率越高
ceph是伪数据平衡，如果只有一个PG，一个PG里副本数为3，永远只有一块盘被用到
ceph的逻辑结构与Ivm有点像
pv->osd
vg > pool
lv ->image
4.2 pool
4.2.1 ceph pool介绍
在rados集群构建完毕后、使用ceph时，需要用到诸多逻辑概念/结构，我们才能理解一个文件到底是如何写入到ceph中。
4.2.2ceph的pool有四大属性
1、所有性和访问权限
2、对象副本数目，默认pool池中的一个pg只包含两个osd daemon，即一份数据交给pg后会存下2个副本，生产环境推荐设置为3个副本
3、PG数目，PG是pool的存储单位，pool的存储空间就由pg组成
4、CRUSH 规则集合
4.2.3 ceph的pool有两种类型
# 1. Replicated pool(默认）：
默认的存储池类型，把每个存入的对象(Object)存储为多个副本，其中分为主副本和从副本,从副本相当于备份副分，从而确保在部分OSD丢失的情况下数据不丢失。这种类型的 pool 需要更多的裸存储空闻，但是它支持所有的pool 操作。
如果客户端在上传对象的时候不指定副本数，默认为3个副本。在开始存数据之前会计算出该对象存储的主副本与从副本的位置，首先会将数据存入到主副本，然后主副本再将数据分别同步到从副本。主副本与从副本同步完毕后，会通知主副本，这时候主副本再响应客户端，并表示数据上传成功。所以如果客户端收到存储成功的请求后，说明数据已经完成了所有副本的存储。
# 2. Erasure-coded pool:
此类型会将数据存储为K+M，其中K数据块数量。每个对象存储到Ceph集群的时候会分成多个数据块分开进行存储。而M为编码块，也代表最多容忍可坏的数据块数量。类似于磁盘阵列RAID5，在最大化利用空间的同时，还能保证数据丢失可恢复性，相比副本池更节约磁盘的空间。
# 列如：
如果将100M资源分为25块，如果将M指定为2，那么总共只需要108M空间即可，计算公式为100+100/25*2。
4.2.4 ceph的pool提供如下能力
# 1.Resilience(弹力):
即在确保数据不丢失的情况允许一定的OSD失败，这个数目取决于对象的拷贝(copy/replica)份数或称副本数。对拷贝型pool来说，Ceph中默认的拷贝份数是2，这意味着除了对象自身外，它还有一个另外的备份，你可以自己决定一个Pool中的对象的烤贝份数。生产环境推荐为3，副本数越多数据越安全、真正可以使用的空间越少
# 2.PG（placement group，放置组）：ceph用pg把存放相同副本的osd daemon归为一组。
客户端的文件会被切成多个object然后交给ceph存储，ceph中真正负责存储的是osd daemon守护进程，在存储时，ceph需要找到n个osd daemon、归类好哪些osd daemon存放的是同一个副本、然后把object交给它们，为了降低查找与归类成本，于是引入了pg的概念，将存放相同副本的 osd daemon归为一个pg组
# 3.CRUSH Rules(CRUSH规则):数据映射的策略。系统默认提供"reolicated_ruleset"。
用户可以自定义策略来灵活地设置object存放的区域。比如可以指定po011中所有objecst放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。pool2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。后续小猿会详细介绍 crush rules.
# 4.Snapshots(快照):你可以对pool 做快照。
# 5.Set Ownership:设置pool的owner的用户ID。
# 6.Ceph集群创建后，默认创建了data metadata 和 rbd 三个存储池。
4.3 pg
4.3.1pg的概念
# PG英文全称 Placement group，中文称之为归置组。
PG的作用:PG相当于一个虚拟组件，出于集群伸缩，性能方面的考虑。
Ceph将每个存储池分为多个PG，如果存储池为副本池类型，并会给该存储池每个PG分配一个主OSD和多个从OSD，当数据量大的时候PG将均衡的分布行不同集群中的每个OSD上面。
PG概念非常复杂，主要有如下几点:
PG也是对象的逻集合，pool中的副本数设置为3，则一个pg中包含3个osd daemon,同一个PG接收到的所有object在这3个osddaemon上被复制。
一个PG组里有三个组员/OSD daemon，三个组员第一个是组长，组长负责对外提供服务，组员负责备份，一旦组长挂掉后，相当于公司中一个部门的项目经理挂了，公司会招聘一个新的项目经理，但新的项目经理刚来的时候还什么都不知道(即新加进来的osd daemon是没有任何组内数据的)，此时公司会让某个组员先临时接替一下组长的职务、对外提供服务，一旦新来的组长了解了业务(即新加进来的osd daemon已经同步好数据了)，那么就可以让新组长出山了.
3.2 pg的特点
一、基本特点
1、Ceph引入PG的目的主要是为了减少直接将对象object映射到OSD的复杂度，即PG 确定了pool中的对象object和pSD之间的映射关系，一个object只会存在于一个 PG 中，但是多个object可以在同一介PG内。PG-Object-OSD的关系如下图所示:
object与PG是多对一的关系
PG与OSDdaemon是多对多的关系
OSD daemon与disk是一对一的关系
2、一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。PG 和 OSD 之间的映射关系由CRUSH 决定，而它做决定的依据是CRUSH 规则
(rules)。CRUSH将所有的存储设备(OSD)组织成一个分层结构，该结构能区分故障域(failure domain)，该结构中每个节点都是一个CRUSH bucket。详细情况后续介绍。
3、对象的副本数目，也就是被拷贝的次数，是在创建Pool时指定的。该分数决定了每个PG会在几个 OSD 上保存对象。如果一个拷贝型 Pool 的size(拷贝份数)为2，它会包含指定数目的PG，每个PG使用两O其中，第一个为主OSD(primary)，其它的为从OSD(secondary)。不同的PG可能会共享一个 OSD。
4、PG也是Ceph集群做清理(scrubbing)的基本单位，也就是说数据清理是一个一个PG来做的。
、PG和 OSD 的关系是动态的
librbd crush算法
file—————————> object—————-—> pool中划分出来的image(一堆pg)—————— >
osd daemon
1)一开始在PG被创建的时候，MON根据CRUSH算法计算出PG所在的OSD。这是它们之间的初始关系。
2)Ceph集群中OSD的状态是不断变化的，它会在如下状态之间做切换
up:守护进程运行中，能够提供1O服务; down:守护进程不在运行，无法提供1O服务; in:包含数据;
out:不包含数据
3)部分PG和OSD的关系会随着OSD状态的变化而发生变化
当新的OSD被加入集群后，已有OSD上部分PG将可能被挪到新OSD上;此时PG和 OSD的关系会发生改变。
当已有的某OSDdown了并变为out后，其上的PG会被挪到其它已有的OSD上。但是大部分的PG和OSD的关系将会保持不变，在状态变化时，Ceph 尽可能只挪动最少的数据。
4)客户端根据Cluster map 以及CRUSH Ruleset 使用CRUSH算法查找出某个PG所在的 OSD 列表。
4.3.3 PG的创建过程
Pool的PG数目是创建pool时候指定的，Ceph官方有推荐的计算方法。其值与OSD的总数的关系密切。当Ceph集群扩展OSD增多时，根据需要，可以增加pool的PG 数目。
306
1)MON节点上有PGMonitotor，它发现有pool被创建后，判断该pool 是否有PG。如果有 PG，则逐一判断这些PG是否已经存在，如果不存在，则开始下面的创建PG的过程。
2)创建过程的开始，设置PG状态为Creating，并将它加入待创建PG队列 creatingpgs，等待被处理。
3)开始处理后，使用CRUSH算法根据当前的OSDmap 找出来up/acmgset，确定哪些osd属于哪些pg，然后加入队列 creating_pgs_by_osd, 等待被处理
4)队列处理函数将该OSD上需要创建的PG合并，生成消息MOSDPGCreate，通过消息通道发给OSD。
5)OSD收到消息字为 MSG_OSD_PG_CREATE的消息，得到消息中待创建的 PG 信息，判断类型，并获取该PG的其它OSD，加入队列creating_pgs似乎是由主 OSD 负责发起创建次 OSD上
的PG)，再创建具体的PG。
6)PG 被创建出来以后，开始 Peering 过程。
4.3.4 PG 数目的确定(非常非常非常重要!!!)
创建pool 时需要确定其 PG的数目，在 poo被创建后也可以调整该数字，但是增加池中的PG数是影响ceph集群的重大事件之一，生成环境中应该避免这么做，因为pool中pg的数目会影响到
ceph 重点笔记
ceph
1、伪数据平衡，是通过算法达到的
object ---hash算法---》pg---crush算法-----》osd daemon
object
2、ceph适用于海量小文件，或者单个文件容量大
ps：一个osd daemon应该属于多少个pg组呢？
首先一个osd daemon肯定不能属于一个pg组，因为ceph
是pg组为单位来分配数据的，如果一个osd daemon只属于
一个pg组，那么该osd daemon将只能收这一个pg组发来的数据
如果该pg组没有被hash算法算到，那么就不会收到数据，于是
该osd daemon就被闲置了，
所以一个osd 应该属于多个pg组，到底应该属于多少个呢？
官方建议：
ceph集群很长一段时间不会拓展：一个osd deamon属于100个pg
否则：一个osd deamon属于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
hammer-》filestore osd daemon---》xfs文件系统----》disk
luminous-》bluestore osd daemon---》裸盘disk
primary osd
replication osd
osd deamon负责三件事：（负责具体干活的）
1、读写数据
2、数据的拷贝与恢复
3、监控自己以及pg组内的其它成员的状态，汇报给monitor节点
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、必须为奇数个
2、一个monitor也可以，但是不应该这么做，因为有单点故障
所以最少3个起
1、为何monitor节点个数应该为奇数个
因为monitor节点同步数据用的是paxos算法（分布式强一致性算法）
paxos算法规定至少有三个节点
2、可以挂掉几个monitor节点
paxos算法下，monitor集群不能超过半数挂掉
3、monitor进程与osd daemon能否在同一个物理节点上
可以，但是不好，但是这就是一种集中式的思想了
如果考虑到成本，可以这么做