理解 OpenStack + Ceph 2Ceph 的物理和逻辑结构.docx
- 文档编号:25657032
- 上传时间:2023-06-11
- 格式:DOCX
- 页数:34
- 大小:540.32KB
理解 OpenStack + Ceph 2Ceph 的物理和逻辑结构.docx
《理解 OpenStack + Ceph 2Ceph 的物理和逻辑结构.docx》由会员分享,可在线阅读,更多相关《理解 OpenStack + Ceph 2Ceph 的物理和逻辑结构.docx(34页珍藏版)》请在冰豆网上搜索。
理解OpenStack+Ceph2Ceph的物理和逻辑结构
理解OpenStack+Ceph
(2):
Ceph的物理和逻辑结构[CephArchitecture]
本系列文章会深入研究Ceph以及Ceph和OpenStack的集成:
(1)安装和部署
(2)CephRBD接口和工具
(3)Ceph物理和逻辑结构
(4)Ceph的基础数据结构
(5)Ceph与OpenStack集成的实现
(6)QEMU-KVM和CephRBD的缓存机制总结
(7)Ceph的基本操作和常见故障排除方法
(8)关于CephPGs
1. Ceph集群的物理结构
1.1Ceph内部集群
从前一篇文章 我们知道,从物理上来讲,一个Ceph集群内部其实有几个子集群存在:
(1)MON(Montior)集群:
MON集群有由少量的、数目为奇数个的Monitor守护进程(Daemon)组成,它们负责通过维护CephClustermap的一个主拷贝(mastercopyofClustermap)来维护整Ceph集群的全局状态。
理论上来讲,一个MON就可以完成这个任务,之所以需要一个多个守护进程组成的集群的原因是保证高可靠性。
每个Cephnode上最多只能有一个MonitorDaemon。
root@ceph1:
~#ps-ef|grepceph-mon
root96410Sep18?
00:
36:
33/usr/bin/ceph-mon--cluster=ceph-iceph1-f
实际上,除了维护Clustermap以外,MON还承担一些别的任务,比如用户校验、日志等。
详细的配置可以参考 MON配置。
(2)OSD(ObjectStorageDevice)集群:
OSD集群由一定数目的(从几十个到几万个)OSDDaemon组成,负责数据存储和复制,向Cephclient提供存储资源。
每个 OSD守护进程监视它自己的状态,以及别的OSD的状态,并且报告给Monitor;而且,OSD进程负责在数据盘上的文件读写操作;它还负责数据拷贝和恢复。
在一个服务器上,一个数据盘有一个OSDDaemon。
root@ceph1:
~#ps-ef|grepceph-osd
root120410Sep18?
00:
24:
39/usr/bin/ceph-osd--cluster=ceph-i3-f
root225410Sep18?
00:
20:
52/usr/bin/ceph-osd--cluster=ceph-i6-f
(3)若干个数据盘:
一个Ceph存储节点上可以有一个或者多个数据盘,每个数据盘上部署有特定的文件系统,比如xfs,ext4或者btrfs,由一个OSDDaemon负责照顾其状态以及向其读写数据。
Disk/dev/vda:
21.5GB,21474836480bytes
/dev/vda114194303920971519+eeGPT
Disk/dev/vdb:
32.2GB,32212254720bytes
/dev/vdb116291455931457279+eeGPT
(MON和OSD可以共同在一个节点上,也可以分开)
关于Ceph支持的数据盘上的xfs、ext4和btrfs文件系统,它们都是日志文件系统(其特点是文件系统将没提交的数据变化保存到日志文件,以便在系统崩溃或者掉电时恢复数据),三者各有优势和劣势:
btrfs(B-tree文件系统)是个很新的文件系统(Oracel在2014年8月发布第一个稳定版),它将会支持许多非常高大上的功能,比如透明压缩( transparentcompression)、可写的COW快照(writablecopy-on-writesnapshots)、去重(deduplication )和加密(encryption )。
因此,Ceph建议用户在非关键应用上使用该文件系统。
更多的参考包括
(1)
(2)(3)。
xfs和btrfs相比较ext3/4而言,在高伸缩性数据存储方面具有优势。
Ceph的这篇文章 明确推荐在生产环境中使用XFS,在开发、测试、非关键应用上使用btrfs。
网上有很多的文章比较这几种文件系统,包括:
ext3,ext4,xfs和btrfs文件系统性能对比
固态硬盘上Ext4和xfs性能比较
哇,让你的DB再快一倍:
ext4vsxfs对比测试
XFS--ifit'smorerobust,whyareweusingext4instead?
(4)要使用CephFS,还需要MDS集群,用于保存CephFS的元数据
(5)要使用对象存储接口,还需要RADOSGateway,它对外提供REST接口,兼容S3和Swift的API。
1.2Ceph网络结构
Ceph使用以太网连接内部各存储节点以及连接client和集群。
Ceph推荐使用两个网络:
前端(北向)网络( apublic(front-side)network)连接客户端和集群
后端/东西向网络(acluster(back-side)network)来连接Ceph各存储节点
下图(来源)显示了这种网络拓扑结构:
这么做,主要是从性能(OSD节点之间会有大量的数据拷贝操作)和安全性(两网分离)考虑。
你可以在Ceph配置文件的[global]部分配置两个网络:
publicnetwork={public-network/netmask}
clusternetwork={cluster-network/netmask}
具体可以参考:
DeployingCephwithHighPerformanceNetworks,ArchitecturesandbenchmarksforBlockStorageSolutions
DeployingCephwithHighPerformanceNetworks
CHAPTER2.NETWORKINGRECOMMENDATIONS
CephwithaclusterandpublicnetworkonIPv6 谈到了IPV6的支持。
1.3RDBCache(缓存)
1.3.1常见的WriteCache种类
缓存种类
说明
优劣势
适合场景
Write-through(直写)
这种缓存方式在写I/O时把数据放入缓存,同时直接写入底层的持久存储,然后再向主机确认写入操作完成。
安全地保存数据,从缓存读,减少了读操作的延迟,但是写操作的延迟没得到优化
适合于写较少,但是频繁度的应用
Write-back(回写)
数据直接写入缓存,然后向主机返回写入完成。
对频繁写应用减少了写的延迟,但是有数据丢失风险
对读写混合型应用有优势,但是需要考虑数据保护
缓存的通常位置分类:
服务器(主机)上:
RAID卡或者HBA卡上做缓存。
VMM内:
在Hypervisor上做缓存。
客户机操作系统内:
以Windows2012为例,它提供write-back缓存机制。
更多资料,可以参考 Cacheisvitalforapplicationdeployment,butwhichonetochoose。
1.3.2CephRBD缓存
默认情况下,CephRBD是不使用缓存的,读和写直接到Ceph集群中的存储,写只有在所有replica上写都完成后才给客户端返回写完成。
Ceph在较新的版本上陆续添加了RBD缓存支持:
从0.46版本开始,Ceph支持 write-back缓存,你可以在ceph.conf文件的[client]部分添加 rbdcache=true来使得write-back缓存生效。
这时候,写几乎是立即返回,但是数据只有在被flushed后才写入到实际存储。
从0.47版本开始,Ceph支持 write-through缓存机制。
你只需要再添加配置项 rbd cache max dirty=0即可。
从0.60版本开始,Ceph支持 rbd cache writethrough until flush配置项。
设置它为true时,会使得write-through机制变得更加安全,因为老的客户机操作系统(2.6.32内核版本之前)可能不支持flush操作。
因此,在设置了该配置项为true时,即使用户设置了使用write-through机制,Ceph也会自动使用write-back机制,直到它收到第一个flush指令后才真正使用write-through。
可见RBD缓存是在客户端做的,见如下图示:
更多信息,可以参考我的另一篇文章:
QEMU-KVM和CephRBD的缓存机制总结
1.3.3Cachetiering(缓存分层)
Ceph还支持在集群段做缓存分层。
其原理是,在较快的磁盘比如SSD上建立一个cachepool,在建立存储池(storagepool)和它之间的cache关系,设置一定的缓存策略,实现类似于在客户端缓存同样的效果。
更多的信息及详细配置,参见 CACHETIERING 和 Intel的文章。
1.3.4RBDCache和CacheTiering的区别
从上面的分析可以看出来,两者的区别在于缓存的位置不同:
Cachetiering是RADOS层在OSD端进行数据缓存,也就是说不论是块存储、对象存储还是文件存储都可以使用tier来提高读写速度
RBDCache是rbd层在客户端的缓存,也就是只支持块存储。
Rbdcache是客户端的缓存,当多个客户端使用同个块设备时,存在客户端数据不一致的问题。
举个例子,用户A向块设备写入数据后,数据停留在客户自己的缓存中,没有立即刷新到磁盘,所以其它用户读取不到A写入的数据。
但是tier不存在这个问题,因为所有用户的数据都直接写入到ssd,用户读取数据也是在ssd中读取的,所以不存在客户端数据不一致问题。
一般地,Tier使用SSD做缓存,而Rbdcache只能使用内存做缓存。
SSD和内存有两个方面的差别,一个是读写速度、另一个是掉电保护。
掉电后内存中的数据就丢失了,而ssd中的数据不会丢失。
2.Ceph集群的逻辑结构(以RBD为例)
Ceph集群的逻辑结构由Pool和PG(PlacementGroup)来定义。
2.1Pool
一个Pool是Ceph中的一些对象的逻辑分组,它并不表示一个连续的分区,而只是一个逻辑概念,类似于将二进制数据打了tag一样然后根据tag归类一样。
它类似于LVM中的VolumeGroup,类似于一个命名空间。
RBDImage类似于LVM中的LogicalVolume。
RBDImage必须且只能在一个Pool中。
Pool由若干个PG组成。
其属性包括:
所有性和访问权限
对象副本数目
PG数目
CRUSH规则集合
CephPool有两种类型:
Replicatedpool:
拷贝型pool,通过生成对象的多份拷贝来确保在部分OSD丢失的情况下数据不丢失。
这种类型的pool需要更多的裸存储空间,但是它支持所有的pool操作。
Erasure-codedpool:
纠错码型pool(类似于SoftwareRAID)。
在这种pool中,每个数据对象都被存放在K+M个数据块中:
对象被分成K个数据块和M个编码块;pool的大小被定义成K+M块,每个块存储在一个OSD中;块的顺序号作为object的属性保存在对象中。
可见,这种pool 用更少的空间实现存储,即节约空间;纠删码实现了高速的计算,但有2个缺点,一个是速度慢,一个是只支持对象的部分操作(比如:
不支持局部写)。
这篇文章 详细介绍了其原理和细节。
Pool提供如下的能力:
Resilience(弹力):
即在确保数据不丢失的情况允许一定的OSD失败,这个数目取决于对象的拷贝(copy/replica)份数。
对拷贝型pool来说,Ceph中默认的拷贝份数是2,这意味着除了对象自身外,它还有一个另外的备份。
你可以自己决定一个Pool中的对象的拷贝份数。
PlacementGroups(放置组):
Ceph使用PG来组织对象,这是因为对象可能成千上万,因此一个一个对象来组织的成本是非常高的。
PG的值会影响Ceph集群的行为和数据的持久性。
你可以设置pool的PG数目。
推荐的配置是,每个OSD大概100个PG。
CRUSHRules(CRUSH规则):
数据映射的策略。
系统默认提供“replicated_ruleset"。
用户可以自定义策略来灵活地设置object存放的区域。
比如可以指定pool1中所有objecst放置在机架1上,所有objects的第1个副本放置在机架1上的服务器A上,第2个副本分布在机架1上的服务器B上。
pool2中所有的object分布在机架2、3、4上,所有Object的第1个副本分布在机架2的服务器上,第2个副本分布在机架3的服器上,第3个副本分布在机架4的服务器上。
详细的信息可以参考这些文档
(1)
(2)(3)(4)。
Snapshots(快照):
你可以对pool做快照。
SetOwnership:
设置pool的owner的用户ID。
Ceph集群创建后,默认创建了data,metadata和rbd三个存储池。
2.2(PlacementGroup)PG
2.2.1概念
PG概念非常复杂,主要有如下几点:
PG也是对象的逻辑集合。
同一个PG中的所有对象在相同的OSD上被复制。
PG聚合一部分对象成为一个组(group),这个组被放在某些OSD上(place),合起来就是PlacemengGroup(放置组)了。
Epoch:
PGmap的版本号,它是一个单调递增的序列。
Peering:
见下文的状态(8)描述。
详细过程请参阅 Ceph:
pgpeering过程分析。
Actingset:
支持一个PG的所有OSD的有序列表,其中第一个OSD是主OSD,其余为次。
actingset是CRUSH算法分配的,但是不一定已经生效了。
Upset:
某一个PGmap历史版本的actingset。
在大多数情况下,actingset和upset是一致的,除非出现了 pg_temp。
CurrentInterval or PastInterval:
若干个连续的版本号,这些版本中acting和upset保持不变。
PGtemp:
在Ceph正在往主OSD回填数据时,这个主OSD是不能提供数据服务的,这时候,它会向MON申请一个临时的actingset,这就是PGtemp。
举个例子,现在actingset是[0,1,2],出现了一点事情后,它变为[3,1,2],此时osd.3还是空的因此它无法提供数据服务因此它还需要等待backfilling过程结束,因此,它会向MON申请一个临时的set比如[1,2,3],此时将由osd.1提供数据服务。
回填过程结束后,该临时set会被丢弃,重新由osd.3提供服务。
主(primary)OSD:
在actingset中的首个OSD,负责接收客户端写入数据;默认情况下,提供数据读服务,但是该行为可以被修改。
它还负责peering过程,以及在需要的时候申请PGtemp。
次(replica)OSD:
在actingset中的除了第一个以外的其余OSD。
流浪(stray)OSD:
已经不是actingset中了,但是还没有被告知去删除数据的OSD。
PG的actingset是由CRUSH算法根据CRUSHRules动态地计算得出的。
2.2.2特点
其主要特点如下:
基本特点
PG确定了pool中的对象和OSD之间的映射关系。
一个object只会存在于一个PG中,但是多个object可以在同一个PG内。
Pool的PG数目是创建pool时候指定的,Ceph官方有推荐的计算方法。
其值与OSD的总数的关系密切。
当Ceph集群扩展OSD增多时,根据需要,可以增加pool的PG数目。
对象的副本数目,也就是被拷贝的次数,是在创建Pool时指定的。
该分数决定了每个PG会在几个OSD上保存对象。
如果一个拷贝型Pool的size(拷贝份数)为2,它会包含指定数目的PG,每个PG使用两个OSD,其中,第一个为主OSD(primary),其它的为从OSD(secondary)。
不同的PG可能会共享一个OSD。
Ceph引入PG的目的主要是为了减少直接将对象映射到OSD的复杂度。
PG也是Ceph集群做清理(scrubbing)的基本单位,也就是说数据清理是一个一个PG来做的。
PG和OSD之间的映射关系由CRUSH决定,而它做决定的依据是CRUSH规则(rules)。
CRUSH将所有的存储设备(OSD)组织成一个分层结构,该结构能区分故障域(failuredomain),该结构中每个节点都是一个CRUSHbucket。
详细情况请阅读CRUSH相关的文档。
PG和OSD的关系是动态的:
一开始在PG被创建的时候,MON根据CRUSH算法计算出PG所在的OSD。
这是它们之间的初始关系。
Ceph集群中OSD的状态是不断变化的,它会在如下状态之间做切换:
up:
守护进程运行中,能够提供IO服务;
down:
守护进程不在运行,无法提供IO服务;
in:
包含数据;
out:
不包含数据
部分PG和OSD的关系会随着OSD状态的变化而发生变化。
当新的OSD被加入集群后,已有OSD上部分PG将可能被挪到新OSD上;此时PG和OSD的关系会发生改变。
当已有的某OSDdown了并变为out后,其上的PG会被挪到其它已有的OSD上。
但是大部分的PG和OSD的关系将会保持不变,在状态变化时,Ceph尽可能只挪动最少的数据。
客户端根据Clustermap以及CRUSHRuleset使用CRUSH算法查找出某个PG所在的OSD列表(其实是upset)。
PG-Object-OSD的关系如下图所示:
PG的创建过程(详细过程请参考 PG的创建过程):
MON节点上有PGMonitotor,它发现有pool被创建后,判断该pool是否有PG。
如果有PG,则一一判断这些PG是否已经存在,如果不存在,则开始下面的创建PG的过程。
创建过程的开始,设置PG状态为Creating,并将它加入待创建PG队列 creating_pgs,等待被处理。
开始处理后,使用CRUSH算法根据当前的OSDmap找出来up/actingset,加入PGmap中以这个set中OSD为索引的队列 creating_pgs_by_osd。
(看起来只会加入到主OSD的队列中)。
队列处理函数将该OSD上需要创建的PG合并,生成消息MOSDPGCreate,通过消息通道发给OSD。
OSD收到消息字为 MSG_OSD_PG_CREATE的消息,得到消息中待创建的PG信息,判断类型,并获取该PG的其它OSD,加入队列 creating_pgs(似乎是由主OSD负责发起创建次OSD上的PG),再创建具体的PG。
PG被创建出来以后,开始Peering过程。
PG值的确定:
创建pool时需要确定其PG的数目,在pool被创建后也可以调整该数字,该数目会影响到:
数据的持久性:
考虑pool的size为3,表明每个PG会将数据存放在3个OSD上。
当一个OSDdown了后,一定间隔后将开始recovery过程,recovery结束前,有部分PG的数据将只有两个副本。
这时候和需要被恢复的数据的数量有关系,如果该OSD上的PG过多,则花的时间将越长,风险将越大。
如果此时再有一个OSDdown了,那么将有一部分PG的数据只有一个副本,recovery过程继续。
如果再出现第三个OSDdown了,那么可能会出现部分数据丢失。
可见,每个OSD上的PG数目不宜过大,否则,会降低数据的持久性。
这也就要求在添加OSD后,PG的数目在需要的时候也需要相应增加。
数据的均匀分布性:
CRUSH算法会伪随机地保证PG被选中来存放客户端的数据,它还会尽可能地保证所有的PG均匀分布在所有的OSD上。
比方说,有10个OSD,但是只有一个size为3的pool,它只有一个PG,那么10个OSD中将只有三个OSD被用到。
但是CURSH算法在计算的时候不会考虑到OSD上已有数据的大小。
比方说,100万个4K对象共4G均匀地分布在10个OSD上的1000个PG内,那么每个OSD上大概有400M数据。
再加进来一个400M的对象(假设它不会被分割),那么有三块OSD上将有400M+400M=800M的数据,而其它七块OSD上只有400M数据。
资源消耗:
PG作为一个逻辑实体,它需要消耗一定的资源,包括内存,CPU和带宽。
太多PG的话,则占用资源会过多。
清理时间:
Ceph的清理工作是以PG为单位进行的。
如果一个PG内的数据太多,则其清理时间会很长。
那如何确定一个Pool中有多少PG?
Ceph不会自己计算,而是给出了一些参考原则,让Ceph用户自己计算:
少于5个OSD,建议设为 128
5到10个OSD,建议设为512
10到50个OSD,建议设为4096
50个OSD以上,就需要有更多的权衡来确定PG数目
你可以使用 pgcalc 工具
PG的状态也是不断变化的,其主要状态包括:
Creating创建中:
PG正在被创建。
Peering对等互联:
表示一个过程,该过程中一个PG的所有OSD都需要互相通信来就PG的对象及其元数据的状态达成一致。
处于该状态的PG不能响应IO请求。
Peering的过程其实就是pg状态从初始状态然后到active+clean的变化过程。
一个OSD启动之后,上面的pg开始工作,状态为initial,这时进行比对所有osd上的pglog和pg
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 理解 OpenStack Ceph 2Ceph 的物理和逻辑结构 物理 逻辑 结构