|
|
名称作用
* c& q t& ~* dosd全称Object Storage Device,主要功能是存储数据、复制数据、平衡数据、恢复数据等。每个OSD间会进行心跳检查,并将一些变化情况上报给Ceph Monitor。3 a4 ~+ ^" Z7 N8 w% g* V1 K
mon全称Monitor,负责监视Ceph集群,维护Ceph集群的健康状态,同时维护着Ceph集群中的各种Map图,比如OSD Map、Monitor Map、PG Map和CRUSH Map,这些Map统称为Cluster Map,根据Map图和object id等计算出数据最终存储的位置。 X2 Q; b$ Q! W3 j6 L: V* M
mgr全称Manager,负责跟踪运行时指标和Ceph集群的当前状态,包括存储利用率,当前性能指标和系统负载。
0 ~# c1 e0 k y' k4 rmds全称是MetaData Server,主要保存的文件系统服务的元数据,如果使用cephfs功能才会启用它,对象存储和块存储设备是不需要使用该服务。0 D1 \! f! F! w7 M' L4 V" }
rgw全称radosgw,是一套基于当前流行的RESTFUL协议的网关,ceph对象存储的入口,内嵌civetweb服务,不启用对象存储,则不需要安装。% E h1 ^, }& f- U+ H* F) P
 File->Objects->PGs->OSDs。
需要注意的几个点: - PG和PGP可以自定义数量,且是针对于存储池的,但PG总数会根据OSD集群的大小决定
- 相对于存储池来说,PG是一个虚拟组件,它是对象映射到存储池时使用的虚拟层
- 出于规模伸缩及性能方面的考虑,ceph将存储池细分为多个PGP,每个PGP中有一个主PG,主PG所在的OSD节点便是主OSD。
- 当有新OSD节点加入集群时,ceph会通过CRUSH重新组合PGP,致使每个OSD都有数据,达到整个集群的数据平衡。
9 Z, M7 w( U$ T5 ~' |5 Q7 z1 k3 u2 H
PG的分配计算: 官方建议:每个osd中的pg数量最好不要超过100个,公式:Total PGS = (Total_number_of _osd * 100) / max_replication_count 具体算法:举例现在有12台osd机器,我需要创建20个存储池。 此时pg总数为:12 * 100 / 3 = 400 平均每个存储池分配pg数量为:400 / 20 = 20 这里计算出,平均每个存储池可以分配20个pg,但每个存储池pg的个数推荐为2的N次幂,故2、4、8、16、32、64、128等,这时要结合具体的pool是来存储什么,大概能存储多少数据来进行一个简单的转换,如果此pool只存储一些元数据,则分配4即可,反之数据量比较大的,可以分配16、32等。 另外pool中pg个数是推荐用2的整数次幂,也可以不用,但会有警告提示。 9 ]: h0 H" L& x( @% p! j6 Y( K
PG与PGP组合: 查看replicapool池的pg、pgp数量 $ ceph osd pool get replicapool pg_num pg_num: 32$ ceph osd pool get replicapool pgp_num pgp_num: 32查看replicapool池的pg、pgp分布 $ ceph pg ls-by-pool replicapool | awk '{print $1,$2,$15}'PG OBJECTS ACTING2.0 596 [3,1,0]p32.1 623 [3,4,0]p32.2 570 [3,4,0]p32.3 560 [3,4,0]p32.4 630 [0,3,4]p02.5 574 [4,0,3]p42.6 572 [4,3,0]p42.7 572 [3,4,0]p32.8 622 [3,4,0]p32.9 555 [0,3,4]p02.a 523 [1,3,0]p12.b 574 [4,3,0]p42.c 620 [4,3,0]p42.d 637 [1,3,0]p12.e 522 [0,3,4]p02.f 599 [4,3,0]p42.10 645 [4,3,0]p42.11 534 [3,4,0]p32.12 622 [4,3,0]p42.13 577 [1,3,0]p12.14 661 [3,4,0]p32.15 626 [1,3,0]p12.16 585 [2,4,0]p22.17 610 [3,4,0]p32.18 610 [4,2,0]p42.19 560 [4,3,0]p42.1a 599 [3,4,0]p32.1b 614 [1,2,0]p12.1c 581 [4,3,0]p42.1d 614 [4,3,0]p42.1e 595 [0,3,1]p02.1f 572 [3,4,0]p3 * NOTE: afterwards
% e( r4 k5 W/ e% |0 h7 z) C
PG的状态解释: 在osd扩缩容或者一些特殊情况的时候,ceph会以pg为整体进行rebalancing数据重平衡,此时pg会出现很多不同的状态,例如: $ ceph -s cluster: id: 537175bb-51de-4cc4-9ee3-b5ba8842bff2 health: HEALTH_WARN Degraded data redundancy: 152/813 objects degraded (18.696%), 43 pgs degraded, 141 pgs undersized services: mon: 2 daemons, quorum yq01-aip-aikefu10,bjkjy-feed-superpage-gpu-04 (age 111s) mgr: yq01-aip-aikefu10(active, since 11d), standbys: bjkjy-feed-superpage-gpu-04 mds: mycephfs:1 {0=ceph-node2=up:active} 1 up:standby osd: 8 osds: 8 up (since 3d), 8 in (since 3d); 124 remapped pgs rgw: 2 daemons active (ceph-node1, ceph-node2) task status: data: pools: 8 pools, 265 pgs objects: 271 objects, 14 MiB usage: 8.1 GiB used, 792 GiB / 800 GiB avail pgs: 152/813 objects degraded (18.696%) 114/813 objects misplaced (14.022%) 111 active+clean+remapped 98 active+undersized 43 active+undersized+degraded 13 active+clean- clean:干净态,PG当前不存在待修复的对象,并且大小等于存储池的副本数,即PG的活动集(Acting Set)和上行集(Up Set)为同一组 OSD 且内容一致。
- active:就绪状态或活跃状态,Active 表示主 OSD 和备 OSD 处于正常工作状态,此时的 PG 可以正常 处理来自客户端的读写请求,正常的 PG 默认就是 Active+Clean 状态。
- peering:正在同步状态,同一个 PG 中的OSD需要将准备数据同步一致,而Peering(对等)就是OSD同步过程中的状态。
- activating:Peering 已经完成,PG 正在等待所有 PG 实例同步 Peering 的结果(Info、Log 等)
- degraded:降级状态,出现于 OSD 被标记为 down 以后,那么其他映射到此 OSD 的 PG 都会转换到降级状态,如果此OSD被标记为down的时间超过 5 分钟还没有修复,ceph 会对被降级的 PG 启动恢复操作,直到所有由于此 OSD 而被降级的 PG 重新恢复为 clean 状态。
- undersized:PG 当前副本数小于其存储池定义的值的时候,PG 会转换为 undersized 状态,直到添加备 份 OSD 添加完成,或者修复完成。
- remapped:当 pg 改变, 数据从旧的 OSD 迁移到新的 OSD, 新的主 OSD 应该请求将会花费一段时间, 在这段时间内, 将会继续向旧主 OSD 请求服务, 直到 PG 迁移完成。
- scrubbing:scrub 是 ceph 对数据的清洗状态,用来保证数据完整性的机制,Ceph 的 OSD 定期启动 scrub 线程来扫描部分对象,通过与其他副本比对来发现是否一致,主要检查元数据(metadata )信息,比如文件名、object属性、大小等,如果不一样,就会从主pg复制一份过去。
- stale:过期状态,正常状态下,每个OSD都要周期性的向 RADOS 集群中的监视器(mon)报告其作为OSD所持有的所有主PG的最新统计数据,因任何原因导致某个OSD无法正常向监视器发送汇报信息的、或者由其他OSD报告某个OSD已经down的时候,则所有以此OSD为主PG则会立即被标记为stale状态,即它们的主 OSD 已经不是最新的数据了。
- recovering:正在恢复态,集群正在执行迁移或同步对象和他们的副本。这可能是由于添加了一个新的OSD到集群中或者某个OSD 宕掉后,PG被CRUSH算法重新分配到不同的OSD,其中PG发生内部数据同步的过程。
- backfilling:后台填充态,backfill 是recovery的一种特殊场景,指peering完成后,如果基于当前权威日志无法对Up Set(上行集)当中的某些PG实例实施增量同步(例如承载这些 PG 实例的 OSD 离线太久,或者是新的 OSD 加入集群导致的 PG 实例整体迁移),则通过完全拷贝当前 Primary 所有对象的方式进行全量同步,此过程中的 PG 会处于 backfilling。
- backfill-toofull:某个需要被 Backfill 的 PG 实例,其所在的 OSD 可用空间不足,Backfill 流程当前被挂起时 PG给的状态。
- creating:创建PG中的状态,一般出现创建新pool时。
- incomplete:Peering过程中由于无法选出权威日志或者通过choos_acting选出的acting不足以完成数据恢复,(例如针对纠删码,存活的副本数小于k值)等,导致Peering无法正常完成。即pg元数据丢失,无法恢复pg状态。(ceph-objectstore-tool工具可以调整此状态pg为complete)
' B7 c4 c5 D& U6 B# [) b
noscrub 和 nodeep-scrub - noscrub:数据轻量扫描,主要检查元数据信息是否一致,若不一致则会进行同步,一般为一天进行一次比对,默认开启。
- nodeep-scrub:数据深度扫描,对所有数据的全量扫描,包括元数据、object等,一般一周进行一次,默认开启。! h' {) }* p8 Y; s
数据校验时会导致读压力增大,如果扫描出数据不一致还要进行同步写,增大写的压力,因此在做扩容等操作的时候,我们会人为去设置noscrub与nodeep-scrub,暂停数据校验。查看pool是否开启清洗: $ ceph osd pool get replicapool noscrubnoscrub: false$ ceph osd pool get replicapool nodeep-scrubnodeep-scrub: false数据压缩 如果使用 BlueStore 存储引擎,ceph 支持称为 "实时数据压缩" 即边压缩边保存数据的功能, 该功能有助于节省磁盘空间,可以在BlueStore OSD上创建的每个存储池池上启用或禁用压缩, 以节约磁盘空间,默认没有开启压缩,需要后期配置并开启: ## 开启压缩功能$ ceph osd pool set <pool name> compression_algorithm <压缩算法> 算法介绍: sanppy:默认算法,消耗cpu较少 zstd:压缩比好,但消耗 CPU lz4:消耗cpu较少 zlib:不推荐 $ ceph osd pool set replicapool compression_algorithm snappyset pool 2 compression_algorithm to snappy## 指定压缩模式$ ceph osd pool set <pool name> compression_mode <指定模式>模式介绍: none:从不压缩数据,默认值。 passive:除非写操作具有可压缩的提示集,否则不要压缩数据。 aggressive:压缩数据,除非写操作具有不可压缩的提示集。 force:无论如何都尝试压缩数据,即使客户端暗示数据不可压缩也会压缩,也就是在所有情况下都使用压缩$ ceph osd pool set replicapool compression_mode passiveset pool 2 compression_mode to passive全局压缩选项,这些可以配置到 ceph.conf 中,作用于所有存储池: bluestore_compression_algorithm #压缩算法bluestore_compression_mode #压缩模式bluestore_compression_required_ratio #压缩后与压缩前的压缩比,默认为.875bluestore_compression_min_blob_size #小于它的块不会被压缩,默认0bluestore_compression_max_blob_size #大于它的块在压缩前会被拆成更小的块,默认 0bluestore_compression_min_blob_size_ssd #默认 8kbluestore_compression_max_blob_size_ssd #默认 64kbluestore_compression_min_blob_size_hdd #默认 128kbluestore_compression_max_blob_size_hdd #默认 512k此功能开启会影响cpu的使用率,如果环境为生产环境,不建议开启此功能。
( I! S6 d% a' T- ? ceph集群管理命令
$ c) Y$ ^0 D( m# k) K9 q# ] |
|