码迷,mamicode.com
首页 > 其他好文 > 详细

CloudFoundry hm9000原理及排错

时间:2017-06-18 10:42:47      阅读:177      评论:0      收藏:0      [点我收藏+]

标签:with   .json   lis   oop   ons   dea   des   介绍   获取   

  1. hm9000跟hm_next(healthmanager)功能类似。在cloudfoundry集群中担任至关重要的角色
    - 尝试启动缺失情况下的实例,停止异常实例
    - 获知和报告应用执行的实际实例个数
    - 从DEA中迁移应用到其它DEA
  2. hm9000组件工作须要获取的两种状态
    - desired state: 期望的状态,哪些apps应该是running状态,哪些instances应该是running状态。这些信息是通过http协议从CC中发送过来
    - actual state: 实际状态,哪些instances实际上是running状态。这些信息通过via Nats和DEAs中接收,每一个DEA节点会周期性的发送heartbeat心跳来确认running应用
  3. hm9000存储desired state和actual state在etcd中,有了这两种状态。hm9000能够决定是否启动或者停止一个实例.这个信息通过Nats发送到CC。最后CC通过Nats发送消息到DEA决定是否启动或者停止一个实例
  4. hm9000是至关重要的组件,在hm9000正常工作前要确保hm9000所维护的环境都是正常状态,因此我们介绍下“freshness”的概念
    - 当hm9000能够与NATS通信而且能够周期性的从DEA节点中接收心跳而且能够正确的把actual state存储在etcd中。那么这个actual state是我们期望的“fresh”状态。假设它们中不论什么一个环节出现异常(NATS/no DEA heartbeats/etcd writes fail),这个actual state都将标记为“fressness”或者“not fresh
    ”,这时候hm9000将停止不论什么会话(交互)动作
    - 当hm9000从CC中下载desired state成功(without timeout)而且能够正确存储在etcd中时,那么这个disired state是我们期望的"fresh"状态,同actual state一样不论什么一个环节出现异常都将导致hm9000工作异常。即上面所述的“fressness” 
  5. hm9000中内置了5个组件,每一个组件都负责不同的作用于功能。而且每一个组件都有自己的日志记录
    - listener: 负责监听DEA heartbeats(心跳)通过NATS,来确定actual state,假设actual state状态是not fresh,那么能够查看listener的log来确定为什么hm9000不能维护   actual status
    - desired_state_fetcher: 周期性的从cc获得desired state,相同当disired_state状态时not fresh时,能够查看fetcher的log来确定问题所在
    - analyzer: 分析actual state和disired state来make decisions(做决定)
    - sender: 运行analyzer所做出的决定而且向CC发送通知
    - api_server: 对cc的app state(应用状态包含实例个数)request做出response
  6. 排错
    - 确保CC配置能正确訪问hm9000:CC的配置中有一项hm9000_noop项,假设设置为true那么cc将仅仅listen health_manager_next,而且仅仅对health_manager_next请求实例执行个数,假设设置成false那么将被hm9000代替
    - 确保etcd不是错误的状态,当etcd是错误状态的时候,那么state不能被写入etcd,会引起hm9000 freness,那么bosh ssh进入每一个etcd节点执行monit stop all然后删除/var/vcap/store文件夹再执行monit start all
    - /var/vcap/packages/hm9000/hm9000 dump --config=/var/vcap/jobs/hm9000/config/hm9000.json在hm9000虚拟机中执行这个命令。能够更直观的看日志
  7. 我遇到的hm9000问题是应用正常启动,可是cf apps显示state和instances不对
  8. 按上述步骤排查之后发现时fetcher问题也就是和cc通信问题,问题所在市ssl证书没能得到验证,cc主动拒绝链接
    解决方法在bosh 部署文档中改动skip_cert_verify: true此选项设置为true的时候是告诉cc忽略不对的ssl证书
  9. 至此问题解决。OK~!



CloudFoundry hm9000原理及排错

标签:with   .json   lis   oop   ons   dea   des   介绍   获取   

原文地址:http://www.cnblogs.com/liguangsunls/p/7043461.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!