1. 程式人生 > >CloudFoundry hm9000原理及排錯

CloudFoundry hm9000原理及排錯

etc esp beats noop 信息 監聽 rac ren ner

  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原理及排錯