ceph源码分析--Monitor tick

本文详细介绍了Ceph集群中Monitor的Tick机制实现原理。包括Monitor初始化时如何启动Tick线程,Tick线程如何定期调用PaxosService的tick函数进行状态检查与更新,并涉及会话管理和健康检查日志的更新等内容。

刚入职的时候曾经定位过一个ceph集群时钟回调8小时的单子。后来投入到了项目中。
最近同事问我osd向monitor定时report的处理过程,也涉及到了这一块的内容,而且
正式入职答辩的时候,主管问,那这个tick线程是定时调用的吗?当时被问懵了,因为自己并没有深入的前后看到这块。事情总要有头有尾,遗留的问题总要解决,写这篇博客的目的就是回答当时的遗留问题。究竟monitor的这个tick是怎么跑的?

Monitor的tick线程启动
同时调用PaxosService的tick函数

int Monitor::init()

int Monitor::init()
{
  dout(2) << "init" << dendl;
  Mutex::Locker l(lock);

  finisher.start();

  // start ticker
  timer.init();
  new_tick();
  ···
}

void Monitor::new_tick()

void Monitor::new_tick()
{
  timer.add_event_after(g_conf->mon_tick_interval, new C_MonContext(this, [this](int) {
    tick();
      }));
}

时间间隔为5s

OPTION(mon_tick_interval, OPT_INT)

void Monitor::tick()

void Monitor::tick()
{
  // ok go.
  dout(11) << "tick" << dendl;
  const utime_t now = ceph_clock_now();

  // Check if we need to emit any delayed health check updated messages
  if (is_leader()) {
    const auto min_period = g_conf->get_val<int64_t>(
                              "mon_health_log_update_period");
    for (auto& svc : paxos_service) {
      auto health = svc->get_health_checks();

      for (const auto &i : health.checks) {
        const std::string &code = i.first;
        const std::string &summary = i.second.summary;
        const health_status_t severity = i.second.severity;

        auto status_iter = health_check_log_times.find(code);
        if (status_iter == health_check_log_times.end()) {
          continue;
        }

        auto &log_status = status_iter->second;
        bool const changed = log_status.last_message != summary
                             || log_status.severity != severity;

        if (changed && now - log_status.updated_at > min_period) {
          log_status.last_message = summary;
          log_status.updated_at = now;
          log_status.severity = severity;

          ostringstream ss;
          ss << "Health check update: " << summary << " (" << code << ")";
          clog->health(severity) << ss.str();
        }
      }
    }
  }


  for (vector<PaxosService*>::iterator p = paxos_service.begin(); p != paxos_service.end(); ++p) {
    (*p)->tick();
    (*p)->maybe_trim();
  }

  // trim sessions
  {
    Mutex::Locker l(session_map_lock);
    auto p = session_map.sessions.begin();

    bool out_for_too_long = (!exited_quorum.is_zero() &&
                 now > (exited_quorum + 2*g_conf->mon_lease));

    while (!p.end()) {
      MonSession *s = *p;
      ++p;

      // don't trim monitors
      if (s->inst.name.is_mon())
    continue;

      if (s->session_timeout < now && s->con) {
    // check keepalive, too
    s->session_timeout = s->con->get_last_keepalive();
    s->session_timeout += g_conf->mon_session_timeout;
      }
      if (s->session_timeout < now) {
    dout(10) << " trimming session " << s->con << " " << s->inst
         << " (timeout " << s->session_timeout
         << " < now " << now << ")" << dendl;
      } else if (out_for_too_long) {
    // boot the client Session because we've taken too long getting back in
    dout(10) << " trimming session " << s->con << " " << s->inst
         << " because we've been out of quorum too long" << dendl;
      } else {
    continue;
      }

      s->con->mark_down();
      remove_session(s);
      logger->inc(l_mon_session_trim);
    }
  }
  sync_trim_providers();

  if (!maybe_wait_for_quorum.empty()) {
    finish_contexts(g_ceph_context, maybe_wait_for_quorum);
  }

  if (is_leader() && paxos->is_active() && fingerprint.is_zero()) {
    // this is only necessary on upgraded clusters.
    MonitorDBStore::TransactionRef t = paxos->get_pending_transaction();
    prepare_new_fingerprint(t);
    paxos->trigger_propose();
  }
  //new_tick()
  new_tick();
}

后续还有各个PaxosService的tick,还在建设中。

<think> 嗯,用户遇到了ceph-csi服务组件(cephfs和rbd)的pod持续CrashLoopBackOff和Error状态的问题,这通常是CSI驱动部署中的典型故障。结合用户提供的四个引用内容,需要系统性排查。 引用[1]提到ceph-csi的三大服务类型和Controller/Node/Identity三个核心组件的职责,这提示排查时需要区分组件类型。引用[2]中PVC卡在pending状态的根本原因是MDS服务未启动,说明底层Ceph集群状态直接影响CSI表现。引用[3]展示了成功的rbd部署案例,可对比组件版本差异。引用[4]的官方文档链接则暗示配置准确性至关重要。 用户深层需求显然是恢复集群存储功能,而非单纯解决pod状态。因此方案设计要覆盖: 1. 核心依赖检查:优先确认Ceph集群健康(引用[2]的教训),特别是MDS(cephfs必需)和OSD(rbd必需)状态 2. 权限配置复查:引用[1]提到ControllerServer需要cephx密钥操作存储池,密钥错误会导致组件崩溃 3. 版本兼容性:CSI版本需匹配K8s和Ceph版本(引用[3]成功案例的提示) 4. 日志定位:CrashLoopBackOff必定产生错误日志,需按组件分类获取 特别要注意引用[1]中livenessType组件的探活机制——如果socket配置错误,即使主服务正常也会被误判死亡。这可能是部分pod反复重启的隐藏原因。 针对用户提供的错误现象,下面给出具体解决步骤: </think> 基于引用内容和常见故障排查经验,解决ceph-csi-cephfs/ceph-csi-rbd的Pod处于CrashLoopBackOff或Error状态的方法如下(按优先级排查): --- ### 🔍 **核心排查步骤** #### 1️⃣ **检查Ceph集群基础服务** ```bash # 在Ceph管理节点执行 ceph -s # 确认集群状态为HEALTH_OK ceph mds stat # 检查cephfs必需的MDS服务(引用[2]关键点) ceph osd stat # 检查OSD状态 ceph mon stat # 检查Mon节点 ``` - **关键点**:若MDS未运行(cephfs问题)或OSD异常(rbd问题),CSI组件必然失败(引用[2]已验证) #### 2️⃣ **检查CSI组件日志(首要操作)** ```bash kubectl logs -f <故障Pod名称> -c <具体容器名> # 示例(引用[3]组件结构): kubectl logs -f csi-rbdplugin-provisioner-xxx -c csi-provisioner ``` - **常见日志线索**: - `connection refused` → Ceph Monitor地址/端口错误 - `permission denied` → Ceph密钥问题 - `no mds server is up` → MDS服务未启动(引用[2]的直接原因) - `Volume ID already exists` → 残留冲突(引用[2]的报错) #### 3️⃣ **验证核心配置文件** - **检查`ceph-conf.yaml`(引用[4])**: ```yaml # 确认monitor地址与Ceph集群实际IP和端口匹配(默认6789) monitors: - 10.0.0.1:6789 - 10.0.0.2:6789 ``` - **检查密钥配置**: ```bash # 查看Secret内容是否正确 kubectl get secret ceph-csi-secret -o yaml ``` - 密钥需通过`ceph auth get-key client.admin`获取 #### 4️⃣ **排查存储类(StorageClass)配置** - **检查pool名称是否存在**: ```bash ceph osd lspools # 确认rbd/cephfs池已创建 ``` - **验证StorageClass参数**: ```yaml parameters: clusterID: <fsid> # 必须与ceph -s显示的fsid一致 pool: mypool # 真实存在的池名称 ``` #### 5️⃣ **检查Kubernetes节点兼容性** ```bash # 在K8s节点验证内核模块 lsmod | grep rbd # rbd需要加载内核模块 mount.ceph --version # 确认ceph-common工具已安装 ``` --- ### ⚠️ **高频问题解决方案** | 问题类型 | 解决方案 | |-------------------------|--------------------------------------------------------------------------| | **MDS未启动(cephfs)** | 在Ceph集群执行: `ceph-deploy mds create <节点名>`(引用[2]的直接解决方案) | | **Monitor端口错误** | 核对`ceph-conf.yaml`中端口号(非默认端口需显式指定) | | **密钥权限问题** | 重新生成Secret:`kubectl create secret generic ceph-csi-secret --from-literal=userKey=$(ceph auth get-key client.admin)` | | **残留PV冲突** | 删除冲突PV:`kubectl delete pvc <pvc-name> --force --grace-period=0`(引用[2]的错误场景) | | **CSI驱动版本不兼容** | 检查[官方兼容矩阵](https://github.com/ceph/ceph-csi/#supported-versions) 📌 | --- ### 📌 **补充建议** 1. **版本对齐**: 确保Ceph集群版本、ceph-csi镜像版本、Kubernetes版本三者兼容(引用[3][4]的部署实践) ```bash kubectl describe pod csi-rbdplugin-xxx | grep Image ``` 2. **存活探针调优**: 若日志提示`liveness probe failed`(引用[1]的livenessType),适当增加超时时间: ```yaml livenessProbe: timeoutSeconds: 10 # 默认值可能不足 ``` --- ### 📚 **相关问题** 1. 如何诊断 Kubernetes 中 PersistentVolumeClaim (PVC) 长时间处于 Pending 状态的问题? 2. Ceph CSI 部署中常见哪些与权限(cephx)相关的错误?如何解决? 3. 当 Ceph 集群状态为 `HEALTH_WARN` 时,哪些警告可能影响 CSI 正常工作? 4. 如何验证 ceph-csi 组件与 Ceph 集群之间的网络连通性? > 引用说明: > [^1]: ceph-csi组件架构与Controller/Node/Identity服务职责 > [^2]: MDS服务未启动导致PVC卡Pending的关键案例 > [^3]: 成功部署的组件状态参考 > [^4]: 官方部署配置文件来源
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值