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 的問題在于 ：
?1、一直以來 ，cell v1 被標記為實驗性質
?2、相關的測試很少 ， 而且也沒有 v1 + neutron 的測試
?3、現在來說功能已經凍結 ， 不會加入新的功能
?4、不嚴重的 Bug 根本不會去修復
?5、使用案例很少 。 現在經常提到的使用案例也只有 CERN（ 歐洲原子能研究中心 ）。 一般規模下 ， 完全沒有必要搭建 cell v1
所以 ， 現在進行部署的話 ， 如果用 cell, 就盡量使用 cell v2 吧 。

cell v2
cell v2 自 Newton 版本引入 ，Ocata 版本變為必要組件 。 以后默認部署都會初始化一個單 cell 的架構 。
cell v2 的架構圖如下 ， 看著比 cell v1 清爽不少 。


從架構圖上 ， 可以看到 ：
1、api 和 cell 有了明顯的邊界 。 api 層面只需要數據庫 ， 不需要 Message Queue。
2、nova-api 現在依賴 nova_api 和 nova_cell0 兩個數據庫 。
3、nova-scheduler 服務只需要在 api 層面上安裝 ，cell 不需要參數調度 。 這樣實現了一次調度就可以確定到具體在哪個 cell 的哪臺機器上啟動
4、這里其實依賴 placement 服務 , 以后的文章會提到
5、cell 里面只需要安裝 nova-compute 和 nova-conductor 服務 ， 和其依賴的 DB 和 MQ
6、所有的 cell 變成一個扁平架構 。 比之前的多層父子架構要簡化很多 。
7、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。 其表結構如下 ：


1、cell_mappings 表 cell 的 Database 和 Mesage Queue 的連接 。 用于和子 cell 通訊
2、host_mappings 是用于 nova-scheduler, 可以確認分配到的機器 。 這里其實也有一個坑 ， 之前 nova-compute 啟動起來 ， 就可以直接使用了 ，cell v2 之后 ， 就需要手動運行 nova-manage cell_v2 discover_host , 把 host mapping 到 cell_mappings 表里面 ， 那臺計算節點才會加入到調度中 。
3、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 版本 。