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