CloudFoundry hm9000原理及排錯
阿新 • • 發佈:2017-06-18
etc esp beats noop 信息 監聽 rac ren ner
- hm9000跟hm_next(healthmanager)功能類似。在cloudfoundry集群中擔任至關重要的角色
- 嘗試啟動缺失情況下的實例,停止異常實例
- 獲知和報告應用執行的實際實例個數
- 從DEA中遷移應用到其它DEA - hm9000組件工作須要獲取的兩種狀態
- desired state: 期望的狀態,哪些apps應該是running狀態,哪些instances應該是running狀態。這些信息是通過http協議從CC中發送過來
- actual state: 實際狀態,哪些instances實際上是running狀態。這些信息通過via Nats和DEAs中接收,每一個DEA節點會周期性的發送heartbeat心跳來確認running應用 - hm9000存儲desired state和actual state在etcd中,有了這兩種狀態。hm9000能夠決定是否啟動或者停止一個實例.這個信息通過Nats發送到CC。最後CC通過Nats發送消息到DEA決定是否啟動或者停止一個實例
- 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從CC中下載desired state成功(without timeout)而且能夠正確存儲在etcd中時,那麽這個disired state是我們期望的"fresh"狀態,同actual state一樣不論什麽一個環節出現異常都將導致hm9000工作異常。即上面所述的“fressness” - 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 - 排錯
- 確保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虛擬機中執行這個命令。能夠更直觀的看日誌 - 我遇到的hm9000問題是應用正常啟動,可是cf apps顯示state和instances不對
- 按上述步驟排查之後發現時fetcher問題也就是和cc通信問題,問題所在市ssl證書沒能得到驗證,cc主動拒絕鏈接
解決方法在bosh 部署文檔中改動skip_cert_verify: true此選項設置為true的時候是告訴cc忽略不對的ssl證書
- 至此問題解決。OK~!
CloudFoundry hm9000原理及排錯