ceph pgs: 3.030% pgs not active问题解决

1.问题描述:

在使用rook安装单节点ceph后,出现如下问题:

2.解决:

进行toolbox容器:

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

将crush map导出:

$ ceph osd getcrushmap -o /etc/ceph/crushmap
6
将crush map反编译为可读模式:

$ crushtool -d /etc/ceph/crushmap -o /etc/ceph/crushmap.txt

修改curshmap,主要是修改OSD级别:

 将step chooseleaf firstn 0 type host 修改为:step chooseleaf firstn 0 type osd

[rook@rook-ceph-tools-5c6844fcd5-wm6js /]$ vi /etc/ceph/crushmap.txt 

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class hdd
device 1 osd.1 class hdd
device 2 osd.2 class hdd
device 3 osd.3 class hdd

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 zone
type 10 region
type 11 root

# buckets
host worker01 {
        id -3           # do not change unnecessarily
        id -4 class hdd         # do not change unnecessarily
        # weight 4.362
        alg straw2
        hash 0  # rjenkins1
        item osd.1 weight 1.090
        item osd.2 weight 1.090
        item osd.3 weight 1.090
        item osd.0 weight 1.090
}
root default {
        id -1           # do not change unnecessarily
        id -2 class hdd         # do not change unnecessarily
        # weight 4.362
        alg straw2
        hash 0  # rjenkins1
        item worker01 weight 4.362
}

# rules
rule replicated_rule {
        id 0
        type replicated
        min_size 1
        max_size 10
        step take default
        #将step chooseleaf firstn 0 type host 修改为:step chooseleaf firstn 0 type osd
        step chooseleaf firstn 0 type osd
        step emit
}
rule replicapool {
        id 1
        type replicated
        min_size 1
        max_size 10
        step take default
        step choose firstn 0 type osd
        step emit
}

# end crush map

[rook@rook-ceph-tools-5c6844fcd5-wm6js ~]$ crushtool -c /etc/ceph/crushmap.txt -o /etc/ceph/crushmap-new
[rook@rook-ceph-tools-5c6844fcd5-wm6js ~]$ ceph osd setcrushmap -i /etc/ceph/crushmap-new
7

验证:

[rook@rook-ceph-tools-5c6844fcd5-wm6js ~]$ ceph -s 
  cluster:
    id:     7d358d90-4176-4a8b-9c8c-f9d979df77a3
    health: HEALTH_WARN
            1 pool(s) have no replicas configured
 
  services:
    mon: 1 daemons, quorum a (age 29m)
    mgr: a(active, since 28m)
    osd: 4 osds: 4 up (since 12m), 4 in (since 28m)
 
  data:
    pools:   2 pools, 33 pgs
    objects: 6 objects, 35 B
    usage:   21 MiB used, 4.4 TiB / 4.4 TiB avail
    pgs:     33 active+clean
 

<think>好的,我现在需要处理用户提供的这个日志信息,并解释其中的内容。首先,用户给出了一段系统日志,涉及Rook Ceph集群的操作,包括检测版本号、错误信息以及创建的配置映射。 首先,我要确定日志中的关键部分。时间戳是2025年的,不过这可能只是示例,不需要在意。接下来是信息级别(I)和错误级别(E)的日志条目。信息级别的日志显示检测到了特定版本的Ceph镜像,而错误级别的日志指出在更新集群状态时遇到了问题,具体是对象已被修改,需要应用最新版本。 我需要回忆一下Kubernetes和Rook Ceph的运作机制。Rook作为Kubernetes的Operator,负责管理Ceph集群。当Operator尝试更新集群状态时,可能会遇到资源版本冲突,即多个操作同时修改同一资源,导致其中一个失败。这种情况通常是由于并发修改引起的,属于预期中的错误处理机制。 用户可能希望了解这些日志的含义,特别是错误信息的原因和解决方法。需要解释Kubernetes的乐观锁机制,以及在这种情况下Operator会如何应对,比如自动重试。同时,信息级别的创建配置映射条目表明Operator在继续执行其他配置步骤,可能不影响整体状态。 接下来要组织回答结构,分步骤解释每个日志条目,特别是错误的原因和系统如何处理。需要确保使用正确的中文术语,比如“乐观锁”、“资源版本冲突”等。同时,保持语言清晰易懂,避免过于技术化的术语,但必要时仍需准确。 最后,检查是否符合用户的要求:行内数学公式用$...$,独立公式用$$...$$,虽然当前问题不涉及数学公式,但需要确认是否有其他格式要求。同时,确保回答结构清晰,分点说明问题、原因和解决方法,并保持真实可靠。</think>以下是针对提供的日志信息的逐步解析: --- ### 一、日志结构分解 #### 1. 信息级别日志(`I |`) ```log 2025-03-29 14:18:49.220928 I | ceph-cluster-controller: cluster "rook-ceph": version "19.2.1-0 squid" detected for image "192.168.1.100:8000/public/ceph:v19.2.1" ``` - **含义**:Rook Ceph控制器检测到集群使用的Ceph镜像版本为`v19.2.1`(代号Squid)。 - **关键点**: - 镜像地址:`192.168.1.100:8000/public/ceph`(私有仓库地址) - 版本标签:`19.2.1-0`对应Ceph稳定版Squid。 --- #### 2. 错误级别日志(`E |`) ```log 2025-03-29 14:18:49.240952 E | ceph-spec: failed to update cluster condition to {Type:Progressing Status:True ...} ``` - **错误原因**: 在尝试更新集群状态为`Progressing`(配置中)时,因资源版本冲突失败。 具体错误:`Operation cannot be fulfilled ... the object has been modified`。 - **根本机制**: Kubernetes使用**乐观锁机制**,每个资源更新需携带当前版本号。 若其他进程已修改资源(如人工操作或其他控制器),版本号会变化,导致当前更新请求过期。 --- #### 3. 后续处理日志(`I |`) ```log 2025-03-29 14:18:49.249175 I | ceph-cluster-controller: created placeholder configmap for ceph overrides "rook-config-override" ``` - **含义**:控制器创建了名为`rook-config-override`的占位ConfigMap,用于存储Ceph配置覆盖参数。 - **作用**: ConfigMap允许用户自定义Ceph配置(如调整性能参数),而无需直接修改Operator管理的资源。 --- ### 二、错误分析与解决建议 #### 1. 错误类型:**资源版本冲突** - **触发场景**: 多进程同时修改同一Kubernetes资源(如`CephCluster`对象)。 - **系统行为**: Rook Operator会自动重试更新操作,无需人工干预。 #### 2. 验证方法 通过以下命令检查集群状态是否最终成功: ```bash kubectl -n rook-ceph get cephcluster rook-ceph -o jsonpath=&#39;{.status.state}&#39; ``` 预期输出:`Created`(正常)或`Updating`(仍在处理中)。 #### 3. 人工干预场景 仅当集群长时间卡在`Progressing`状态时需排查: 1. 检查Operator日志是否有重复错误: ```bash kubectl -n rook-ceph logs deploy/rook-ceph-operator | grep "failed to update" ``` 2. 确认是否有人工或其他控制器频繁修改`CephCluster`对象。 --- ### 三、总结 该日志表明: 1. Rook检测到Ceph版本并开始配置集群。 2.Kubernetes乐观锁机制,短暂出现版本冲突错误(可自愈)。 3. 控制器继续执行后续任务(如创建ConfigMap)。 通常无需操作,仅需监控集群最终状态即可。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值