ceph现场问题解决(系统卡满导致mon无法启动)

本文介绍了一种在16节点Ceph集群中,因Monrocksdb数据库sst文件过大导致系统卡分区满载的紧急处理方案。通过卸载无用rpm包和调整journal分区设置,成功释放空间并重启mon服务。

今天遇到一个现场,16节点每节点48盘位集群,5mon重启运行过程中,系统卡分区被挤爆,占用达100%,为了重启拉起mon,做了如下排查:

  1. 通过du -Bm --max-depth=1 / 和 du -d1 -Bm -h ./查找根分区下的大文件,找到mon rocksdb数据库的sst文件总和竟达到7g之多,这个肯定不能删,后续会专门说明一下这个文件为什么这么大

  2. 通过问题1找到了大文件,但是不能删,只能通过删除根分区下其他的大文件来讲根分区释放处理, 大致找了下一些没有用处的rpm安装包,然后进行了卸载,命令如下:
    yum autoremove texlive-base
    yum autoremove mariadb-test
    yum autoremove emacs
    yum autoremove gnome-weather
    yum autoremove net-snmp
    yum autoremove net-snmp-libs
    yum autoremove gimp

  3. /var/log/journal/abf6c3e0a96f452ab2efd6c2d1a9c1e0/ 这个文件占用了大量空间,通过对journal分区的修改,释放出了近1g的空间,journal空间为日志/var/log/message的journal,journal的具体作用就不多说了,基本命令如下:
    vi /etc/systemd/journald.conf
    SystemMaxUse=800M 修改此值为80M
    systemctl restart systemd-journald 重启该服务
    ll /var/log/journal/abf6c3e0a96f452ab2efd6c2d1a9c1e0/ 查看大小确实变小了不少

经过上面几部的处理基本将系统卡空间释放出了不少,这时候重启了一下mon,mon起来了,mon运行一段时间后mon 数据库rocksdb 的sst文件被trim掉,空间彻底释放了出来。
在这里插入图片描述

.

<think>嗯,用户现在问的是如何让CephMON部署到三个不同的节点。首先,我需要回想一下之前用户的问题历史。之前他们问过关于Rook中operator.yaml和cluster.yaml的镜像版本问题,所以可能用户是在使用Rook部署Ceph时遇到了MON节点分配的问题。 用户可能是在部署Ceph集群时,发现MON实例都集中在同一个节点上,这会导致单点故障风险。因此,他们想知道如何确保MON分布在不同的节点上,提高集群的可靠性。需要确认用户是否在使用Rook,因为不同的部署方式(比如手动部署或使用Rook)配置方法不同。根据之前的对话,用户应该是使用Rook来管理Ceph的,所以回答需要基于Rook的配置。 接下来,我需要考虑Rook的配置文件中如何指定MON的分布策略。在cluster.yaml中,可以通过placement设置来控制Pod的调度。可能需要使用nodeAffinity、podAntiAffinity或者拓扑分布约束来确保MON分布在不同的节点。 另外,用户可能需要了解节点标签的使用,比如给三个不同的节点打上特定标签,然后在配置中指定MON只能部署到这些标签的节点上。同时,使用反亲和性来避免同一节点上有多个MON实例。 还需要注意Ceph MON的数量,通常是奇数个,三个是比较常见的配置,这样可以在网络分区时保持仲裁。同时,要确保节点足资源需求,如CPU、内存和存储。 可能用户在实际操作中遇到了MON无法调度到不同节点的问题,需要检查节点资源是否充足,标签是否正确应用,以及反亲和性配置是否合理。此外,Rook的日志和Kubernetes的事件信息也可能提供调度失败的线索。 总结回答步骤:首先解释MON分布的重要性,然后详细说明在Rook的cluster.yaml中如何配置placement部分,包括反亲和性、节点亲和性,以及可能的拓扑约束。最后,提供验证方法和注意事项,比如标签是否正确,资源是否足够,以及如何查看Pod分布情况。</think>在Rook部署的Ceph集群中,确保MONMonitor)分布在三个不同节点上,是保证集群高可用性的关键。以下是具体实现方法: --- ### **1. MON分布的核心机制** - **MON的高可用性** Ceph要求至少3个MON实例(奇数个),且必须分布在**不同物理节点**,避免单点故障。 - **Rook的调度控制** Rook通过Kubernetes调度策略(如`nodeAffinity`、`podAntiAffinity`)控制MON的部署位置。 --- ### **2. 配置方法(修改`cluster.yaml`)** 在CephCluster CRD(`cluster.yaml`)中,通过`placement`字段显式定义MON的调度规则: #### **步骤1:定义节点标签** 给目标节点打标签(例如`ceph-mon-node: "true"`): ```bash kubectl label nodes <node1> ceph-mon-node=true kubectl label nodes <node2> ceph-mon-node=true kubectl label nodes <node3> ceph-mon-node=true ``` #### **步骤2:配置`placement.mon`** 在`cluster.yaml`中添加以下内容: ```yaml apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: rook-ceph spec: # ... placement: mon: # 方法1:强制分散到不同节点(反亲和性) podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["rook-ceph-mon"] topologyKey: "kubernetes.io/hostname" # 方法2:指定节点标签(亲和性) nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: ceph-mon-node operator: In values: ["true"] # 方法3:拓扑分布约束(Kubernetes 1.19+) topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: rook-ceph-mon ``` --- ### **3. 关键参数解释** | 配置项 | 作用 | |-----------------------|----------------------------------------------------------------------| | `podAntiAffinity` | 强制MON Pod分散在不同节点(基于`hostname`拓扑域) | | `nodeAffinity` | 限制MON只能部署到特定标签的节点 | | `topologySpreadConstraints` | 更灵活的分布策略(例如均匀分布、最大偏差控制) | --- ### **4. 验证部署结果** 部署完成后检查MON Pod分布: ```bash kubectl get pods -n rook-ceph -l app=rook-ceph-mon -o wide ``` 输出应显示3个MON Pod分布在**不同节点**: ``` NAME READY STATUS IP NODE rook-ceph-mon-a-xxxxx 1/1 Running 10.244.1.2 node1 rook-ceph-mon-b-xxxxx 1/1 Running 10.244.2.3 node2 rook-ceph-mon-c-xxxxx 1/1 Running 10.244.3.4 node3 ``` --- ### **5. 注意事项** 1. **节点资源充足** 确保目标节点有足够资源(CPU/内存)运行MON(每个MON至少需要2核CPU、2GB内存)。 2. **标签一致性** 若使用`nodeAffinity`,所有目标节点必须正确打上标签。 3. **仲裁保护** 如果节点数量不足3个,MON可能无法启动Ceph要求多数存活)。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值