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