為什么要引入nova cells
主要是為了降低數據庫和消息隊列的訪問瓶頸。
對于云端架構來說，它默認擁有非常大的資源池，而這些資源池需要很多的服務器加以支持。OpenStack在架構設計時，就已經充分考慮到了服務的可擴展性。不過，在實際的使用中，用戶經常會遇到問題，主要的問題包括兩個方面，這就是數據庫和消息隊列的瓶頸問題。而Cells正是Nova內部為了解決數據庫、消息隊列瓶頸問題而設計的一種計算節點劃分部署方案。
如果你仔細研究OpenStack的架構，你會發現OpenStack通過不同的項目對不同的資源接口進行抽象和封裝。而在這些資源之間，是通過消息隊列來進行通信的，同時也會有跨項目的通信。事實上，每一個項目都會有數據庫的訪問，以及消息隊列的使用。而數據庫和消息隊列正在成為整個OpenStack擴展的瓶頸。尤其是消息隊列，伴隨著集群規模的擴展，其性能下降是非常明顯的。通常情況下，當集群規模擴展到200個節點，一個消息可能要在十幾秒后才會響應，集群的整體性能大大下降。
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 版本 。
cells創建流程，例子。
https://docs.openstack.org/developer/nova/cells.html
來源：
http://www.99cloud.net/html/2017/jiuzhouyuanchuang_0306/301.html
