Nova Cell

Nova Cell V2 詳解 

如今 ，OpenStack 在控制平面上的性能瓶頸主要在 Message Queue 和 Database 。 尤爲是 Message Queue , 隨着計算節點的增長 ， 性能變的愈來愈差 。 爲了應對這種狀況 ， Nova 很早以前提出來 nova-cell ( 如下以 cellv1 代替 ) 的解決方案 。 目的是在把大的 OpenStack 集羣分紅小的單元 ， 每一個單元有本身的 Message Queue 和 Database。 以此來解決規模增長時引發的性能問題 。 並且不會向 Region 那樣 ， 把各個集羣獨立運行 。 在 cell 裏面 ，Keystone、Neutron、Cinder、Glance 等資源仍是共享的 。

cell v1
cellv1 最初的想法很好 ， 可是侷限於早期 nova 的架構 ， 硬生生的加個 nova-cell 服務來在各個 cell 間傳遞消息 ， 使得架構更加複雜 。 如下是 cellv1 的架構：


cell v1 的問題在於 ：
 一、一直以來 ，cell v1 被標記爲實驗性質
 二、相關的測試不多 ， 並且也沒有 v1 + neutron 的測試
 三、如今來講功能已經凍結 ， 不會加入新的功能
 四、不嚴重的 Bug 根本不會去修復
 五、使用案例不多 。 如今常常提到的使用案例也只有 CERN（ 歐洲原子能研究中心 ）。 通常規模下 ， 徹底沒有必要搭建 cell v1
因此 ， 如今進行部署的話 ， 若是用 cell, 就儘可能使用 cell v2 吧 。

cell v2
cell v2 自 Newton 版本引入 ，Ocata 版本變爲必要組件 。 之後默認部署都會初始化一個單 cell 的架構 。
cell v2 的架構圖以下 ， 看着比 cell v1 清爽很多 。


從架構圖上 ， 能夠看到 ：
一、api 和 cell 有了明顯的邊界 。 api 層面只須要數據庫 ， 不須要 Message Queue。
二、nova-api 如今依賴 nova_api 和 nova_cell0 兩個數據庫 。
三、nova-scheduler 服務只須要在 api 層面上安裝 ，cell 不須要參數調度 。 這樣實現了一次調度就能夠肯定到具體在哪一個 cell 的哪臺機器上啓動
四、這裏其實依賴 placement 服務 , 之後的文章會提到
五、cell 裏面只須要安裝 nova-compute 和 nova-conductor 服務 ， 和其依賴的 DB 和 MQ
六、全部的 cell 變成一個扁平架構 。 比以前的多層父子架構要簡化不少 。
七、api 上面服務會直接鏈接 cell 的 MQ 和 DB, 因此不須要相似 nova-cell 這樣子的額外服務存在 。 性能上也會有及大的提高

nova_api & nova_cell0
自 Newton 版本 ，nova 就一直拆分 nova 數據庫 ， 爲 cell v2 作準備 。 把一些全局數據表從 nova 庫搬到了 nova_api, 下面是如今 nova_api 裏面的全部表 。


能夠看到像 flavor, instance groups, quota 這些表已經遷移了過來 。
nova_cell0 數據庫的 schema 和 nova 是同樣的 ， 他存在的只要用途是 ： 當 instance 調度失敗時 ， instance 的信息不屬於任何一個 cell, 因此放到 cell0 上面 。 所以裏面的數據並非過重要 。

Cell Related Tables
Cell 相關的數據庫表都在 nova_api 裏面 ， 包括 cell_mappings, host_mappings, instance_mappings。 其表結構以下 ：


一、cell_mappings 表 cell 的 Database 和 Mesage Queue 的鏈接 。 用於和子 cell 通信
二、host_mappings 是用於 nova-scheduler, 能夠確認分配到的機器 。 這裏其實也有一個坑 ， 以前 nova-compute 啓動起來 ， 就能夠直接使用了 ，cell v2 以後 ， 就須要手動運行 nova-manage cell_v2 discover_host , 把 host mapping 到 cell_mappings 表裏面 ， 那臺計算節點纔會加入到調度中 。
三、instance_mappings 表裏有全部 instance id, 這樣在查詢 instance 時 ， 就能夠從這個表裏查到他所在的 cell, 而後直連 cell 拿到 instance 具體信息 。

cell 流程


當想要獲取一個機器的詳細信息時 :
1.nova-api 先從 instance_mappings 表拿到 instance 的 cell_id
2.再從 cell_mappings 表拿到所在 cell 的 DB connection
3.直接鏈接 cell 的 DB 拿到機器的詳細信息



當要重啓一臺機器時 ：
1.nova-api 先從 instance_mappings 表裏拿到 instance 所在的 cell_id
2.從 cell_mappings 裏拿到所在 cell 的 message queue 鏈接
3.nova-api 直接給 mq 的相關隊列發重啓機器的消息


當新建機器時 :
1.nova-api 接到用戶的請求信息 ， 先轉發到 nova-scheduler 進行調度 ， nova-scheduler 經過 placement service, 直接肯定分配到哪臺機器上
2.nova-api 把 instance 的信息存入 instance_mappings 表
3.nova-api 把機器信息存到目標 cell 的 database
4.nova-api 給 cell 的 message queue 的相關隊列發消息 ， 啓動機器


Cell v2 的優勢
•數據庫和消息隊列做爲 nova 的一等公民 。
•在 cell 的數據庫裏沒有冗餘數據 ， 全部共享數據都在 nova-api 中
•全局數據和 cell 數據有一條清晰的界線
•非 cell 用戶很容易的就能夠遷移到 cell v2 上面 。 不須要更改如今的部署架構
•cell v1 的用戶也能夠遷移到 cell v2 上 。 只要手動創建起全部的 mapping, 關掉如今存在的 nova-cell 服務 ， 清掉最上層 cell 的數據庫 。 可是最上層 cell 本質上和其它 cell 是不一樣的 。 因此須要調整架構
•增減 cell 變的十分簡單 ， 並且在把某個 cell 加入以前 ， 能夠在其它環境進行測試

Cell v2 相關命令
由於 cell v2 徹底靠 database 的操做爲創建 ， 因此也沒有相關的 api 接口 。 主要靠 nova-manage cell_v2 命令 。 詳細說明參見REF
nova-manage cell_v2
 
    create_cell
    delete_cell
    list_cells
 
    map_cell0
    discover_hosts
    simple_cell_setup
 
    map_cell_and_hosts
    map_instances
    verify_instance


其它 
計算節點自動發現
上面提到了如今 nova-compute 服務上線後 ， 不會自動加到 nova-api 的 host_mappings 裏面 ， 也就不會加到 nova-scheduler 的調度中 。 須要手動運行 nova-manage cell_v2 discover_hosts 命令 。 這顯示略顯繁瑣 。
在小型一些的環境上 ， 推薦打開自動發現功能 ， 就不用手動跑命令了 。


性能分析
爲了拿到 instance 的詳細信息 ， 須要查詢 nova_api 數據庫 ， 相比以前要多查詢一次數據庫 ( 雖然是有三個表 ， 可是能夠用多表鏈接查詢 ， 一次就能夠拿到全部的結果 )。 可是一來數據至關少 ， 並且很容易加上一層 cache, 並不會對性形成什麼影響 。

Kolla 實現 
如今 Kolla 已經支持自動部署一個基本的 cell 環境 ， 並且支持從沒有 cell 的 Newton 升級到有 cell 的 Ocata 版本 。