CloudFoundry hm9000原理及排错

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~！