雲端計算演進與應用

內容簡介

雲端計算髮展至今，已經成為廣為接受的應用服務提供形式。而微服務架構的誕生，也是雲端計算技術應用以及持續交付、 DevOPS 深入人心的綜合產物，是未來軟體架構朝著動態伸縮和分散式架構發展的方向。本期我們聚焦於2017年雲端計算在具體行業中的實踐應用和相關容器技術的最新發展。

本書內容

談談 OpenStack 大規模部署

文/付廣平

目前社群還沒有一個非常完美的 OpenStack 大規模部署方案，現有方案都存在各自的優點和缺點，實際部署時應根據物理資源的分佈情況、使用者資源需求等因素綜合選擇。本文將談談 OpenStack 大規模部署問題，討論現有方案的優缺點以及分別適用的場景。

前言

走過了7年的發展歲月，OpenStack 已成為雲端計算領域中最火熱的專案之一，並逐漸成為 IaaS 的事實標準，私有云專案的部署首選。OpenStack 社群可能自己都沒有想到其發展會如此之迅速，部署規模如此之大，以至於最開始對大規模 OpenStack 叢集的部署支援以及持續可擴充套件性似乎並沒有考慮完備。

眾所周知，OpenStack 每一個專案都會有資料庫的訪問以及訊息佇列的使用，而資料庫和訊息佇列是整個 OpenStack 擴充套件的瓶頸。尤其是訊息佇列，伴隨著叢集規模的擴充套件，其效能下降非常明顯。通常情況下，當叢集規模擴充套件到200個節點，一個訊息可能要在十幾秒後才會響應，叢集的整體效能大大下降，英國電信主管 Peter Willis 聲稱一個獨立 OpenStack 叢集只能最多管理500個計算節點。

當處理大規模問題時，我們自然會想到分而治之，其思想是將一個規模為 N 的問題分解為 K 個規模較小的子問題，這些子問題相互獨立且與原問題性質相同，解決了子問題就能解決原問題。社群提出的多 Region、多 Cells 以及 Cascading 等方案都是基於分而治之策略，但它們又有所區別，主要體現在分治的層次不一樣，多 Region 和 Cascading 方案思想都是將一個大的叢集劃分為一個個小叢集，每個小叢集幾乎是一個完整的 OpenStack 環境，然後通過一定的策略把小叢集統一管理起來，從而實現使用 OpenStack 來管理大規模的資料中心。在 Grizzly 版本引入的 Nova Cells 概念，其思想是將不同的計算資源劃分為一個個的 Cell，每個 Cell 都使用獨立的訊息佇列和資料庫服務，從而解決了資料庫和訊息佇列的瓶頸問題，實現了規模的可擴充套件性。遺憾的是，目前社群還沒有一個非常完美的 OpenStack 大規模部署方案，以上提到的方案都存在各自的優點和缺點，實際部署時應根據物理資源的分佈情況、使用者資源需求等因素綜合選擇。本文接下來將談談 OpenStack 大規模部署問題，討論前面提到的各個方案的優缺點以及分別適用的場景。

單叢集優化策略

使用獨立的資料庫和訊息佇列

前面提到限制 OpenStack 規模增長的最主要因素之一就是由於資料庫和訊息佇列的效能瓶頸，因此如果能夠有效減輕資料庫以及訊息佇列的負載，理論上就能繼續增長節點數量。各個服務使用獨立的資料庫以及訊息佇列顯然能夠有效減小資料庫和訊息佇列的負載。在實踐中發現，以下服務建議使用獨立的資料庫以及訊息佇列：

1. Keystone：使用者以及其它 API 服務的認證都必須經過 Keystone 元件，每次 Token 驗證都需要訪問資料庫，隨著服務的增多以及規模的增大，資料庫的壓力將會越來越大，造成 Keystone 的效能下降，拖垮其它所有服務的 API 響應。因此為 Keystone 元件配置專門的資料庫服務，保證服務的高效能。
2. Ceilometer：Ceilometer 是一個資源巨耗型服務，在收集訊息和事件時會傳送大量的訊息到佇列中，並頻繁寫入資料庫。為了不影響其它服務的效能，Ceilometer 通常都搭配專有的資料庫服務和訊息佇列。
3. Nova：OpenStack 最活躍的主體就是虛擬機器，而虛擬機器的管理都是由 Nova 負責的。幾乎所有對虛擬機器的操作都需要通過訊息佇列發起 RPC 請求，因此 Nova 是佇列的高生產者和高消費者，當叢集規模大時，需要使用獨立的訊息佇列來支撐海量訊息的快速傳遞。
4. Neutron：Neutron 管理的資源非常多，包括網路、子網、路由、Port 等，資料庫和訊息佇列訪問都十分頻繁，並且資料量還較大，使用獨立的資料庫服務和訊息佇列既能提高 Neutron 本身的服務效能，又能避免影響其它服務的效能。

使用 Fernet Token

前面提到每當 OpenStack API 收到使用者請求時都需要向 Keystone 驗證該 Token 是否有效，Token 是直接儲存在資料庫中的，增長速率非常快，每次驗證都需要查詢資料庫，並且 Token 不會自動清理而越積越多，導致查詢的效能越來越慢，Keystone 驗證 Token 的響應時間會越來越長。所有的 OpenStack 服務都需要通過 Keystone 服務完成認證，Keystone 的效能下降，將導致其它所有的服務效能下降，因此保證 Keystone 服務的快速響應至關重要。除此之外，如果部署了多 Keystone 節點，還需要所有的節點同步 Token，可能出現同步延遲而導致服務異常。為此社群在 Kilo 版本引入了 Fernet Token，與 UUID Token 以及 PKI Token 不同的是它是基於對稱加密技術對 Token 加密，只需要擁有相同加密解密檔案，就可以對 Token 進行驗證，不需要持久化 Token，也就無需存在資料庫中，避免了對資料庫的 I/O 訪問，建立 Token 的速度相對 UUID Token 要快，不過驗證 Token 則相對要慢些。因此在大規模 OpenStack 叢集中建議使用F ernet Token 代替傳統的 Token 方案。

以上優化策略能夠一定程度上減少訊息佇列和資料庫的訪問，從而增大節點部署規模，但其實並沒有根本解決擴充套件問題，隨著部署規模的增長，總會達到瓶頸，理論上不可能支援無限擴充套件。

多 Region 方案

OpenStack 支援將叢集劃分為不同的 Region，所有的 Regino 除了共享 Keystone、Horizon、Swift 服務，每個 Region 都是一個完整的 OpenStack 環境，其架構如圖1。

圖1 多 Region 方案的架構

部署時只需要部署一套公共的 Keystone 和 Horizon 服務，其它服務按照單 Region 方式部署即可，通過 Endpoint 指定 Region。使用者在請求任何資源時必須指定具體的區域。採用這種方式能夠把分佈在不同的區域的資源統一管理起來，各個區域之間可以採取不同的部署架構甚至不同的版本。其優點如下：

1. 部署簡單，每個區域部署幾乎不需要額外的配置，並且區域很容易實現橫向擴充套件。
2. 故障域隔離，各個區域之間互不影響。
3. 靈活自由，各個區域可以使用不同的架構、儲存、網路。

但該方案也存在明顯的不足：

1. 各個區域之間完全隔離，彼此之間不能共享資源。比如在 Region A 建立的 Volume，不能掛載到 Region B 的虛擬機器中。在 Region A 的資源，也不能分配到 Region B 中，可能出現 Region 負載不均衡問題。
2. 各個區域之間完全獨立，不支援跨區域遷移，其中一個區域叢集發生故障，虛擬機器不能疏散到另一個區域叢集中。
3. Keystone 成為最主要的效能瓶頸，必須保證 Keystone 的可用性，否則將影響所有區域的服務。該問題可以通過部署多 Keystone 節點解決。

OpenStack 多 Region 方案通過把一個大的叢集劃分為多個小叢集統一管理起來，從而實現了大規模物理資源的統一管理，它特別適合跨資料中心並且分佈在不同區域的場景，此時根據區域位置劃分 Region，比如北京和上海。而對於使用者來說，還有以下好處：

1. 使用者能根據自己的位置選擇離自己最近的區域，從而減少網路延遲，加快訪問速度。
2. 使用者可以選擇在不同的 Region 間實現異地容災。當其中一個 Region 發生重大故障時，能夠快速把業務遷移到另一個 Region 中。

但是需要注意的是，多 Region 本質就是同時部署了多套 OpenStack 環境，確切地說並沒有解決單 OpenStack 叢集的大規模部署問題。

OpenStack Cascading 方案以及 Trio2o 專案

OpenStack Cascading 方案是由國內華為提出的用於支援場景包括10萬主機、百萬虛機、跨多 DC 的統一管理的大規模 OpenStack 叢集部署。它採取的策略同樣是分而治之，即把原來一個大的 OpenStack 叢集拆分成多個小叢集，並把拆分的小叢集級聯起來統一管理，其原理圖2。

圖2 OpenStack Cascading 方案的原理

1. 只有最頂層的 OpenStack 暴露標準 OpenStack API 給使用者，其包含若干個子 OpenStack 叢集。
2. 底層的 OpenStack 負責實際的資源分配，但不暴露 API 給使用者，而必須通過其之上的 OpenStack 排程。

使用者請求資源時，首先向頂層 OpenStack API 發起請求，頂層的 OpenStack 會基於一定的排程策略選擇底層的其中一個 OpenStack，被選中的底層 OpenStack 負責實際的資源分配。

該方案號稱支援跨多達100個 DC，支援10萬個計算節點部署規模，能同時執行100萬個虛擬機器。但該方案目前仍處於開發和測試階段，尚無公開的實際部署案例。目前該方案已經分離出兩個獨立的 big-tent 專案，一個是 Tricircle，專門負責網路相關以及對接 Neutron，另一個專案是 Trio2o，為多 Region OpenStack 叢集提供統一的 API 閘道器。

Nova Cells 方案

前面提到的 OpenStack 多 Region 方案是基於 OpenStack 環境切分，它對使用者可見而非透明的，並且單叢集依然不具備支撐大規模的能力和橫向擴充套件能力。而 Nova Cells 方案是針對服務級別劃分的，其最終目標是實現單叢集支撐大規模部署能力和具備靈活的擴充套件能力。Nova Cells 方案是社群支援的方案，因此本文將重點介紹，並且會總結下在實際部署中遇到的問題。

Nova Cells 架構和原理介紹

Nova Cells 模組是 OpenStack 在 G 版本中引入的，其策略是將不同的計算資源劃分成一個個 Cell，並以樹的形式組織，如圖3。

圖3 Nova Cell 架構

從圖中看出，Cells 的結構是樹形的，一個 Cell 可能包含若干子 Cell，以此逐級向下擴充套件。每個 Cell 都有自己獨立的訊息佇列和資料庫，從而解決了訊息佇列和資料庫的效能瓶頸問題，Cell 與 Cell 之間主要通過 Nova-Cells 負責通訊，一層一層通過訊息佇列傳遞訊息，每個 Cell 都需要知道其 Parent Cell 以及所有孩子 Cells 的訊息佇列地址，這些資訊可以儲存到該 Cell 的資料庫中，也可以通過 json 檔案指定：

{    "parent": {        "name": "parent",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": true    },    "cell1": {        "name": "cell1",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit1.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": false    },    "cell2": {        "name": "cell2",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit2.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": false    }}

根據節點所在樹中位置以及功能，分為兩種 Cell 型別：

1. api cell，非葉子節點，該型別的 Cell 不包含計算節點，但包括了一系列子 Cells，子 Cells 會繼續排程直到到達葉子節點，即 Compute Vell 中。其中最頂層的根節點通常也叫作 Top Cell。
2. compute cell，葉子節點，包含一系列計算節點。負責轉發請求到其所在的 Nova-Conductor 服務。

注意：所有的 Nova 服務都隸屬於某個 Cell 中，所有的 Cells 都必須指定 Cell 型別。

每個 Cell 節點都有從根節點到該節點的唯一路徑，路徑預設通過 ! 分割，比如 root!cell _ 1!cell _ 13 表示從 root 到 cell _ 1 再到 cell _ 13。根節點的 Cell 型別一定是 API 就是說 Cell 對使用者是完全透明的，和不使用 Cell 時是完全一樣的。其中 Nova-Cells 服務是需要額外部署的新服務，該服務主要負責建立虛擬機器時，從所有的孩子 Cell 中選擇其中一個子 Cell 作為虛擬機器的 Cell，子 Cell 會繼續執行排程直到到達底層的 Compute Cell 中，最後轉發請求到目標 Compute Cell 所在的 Nova-Conductor 服務中。因此採用 Nova Cells 方案後，Nova 實際採用的是二級排程策略，第一級由 Nova-Cells 服務負責排程 Cell，第二級由 Nova-Scheduler 服務負責排程計算節點。

Compute Cell 節點擔任的職責類似於非 Cell 架構的控制節點，需要部署除 Nova-API 服務以外的所有其它 Nova 服務，每個 Cell 相當於一個完整的 Nova 環境，擁有自己的 Nova-Conductor、Nova-Scheduler 等服務以及資料庫服務和訊息佇列服務，並且包含若干計算節點，每個 Cell 的元件只服務於其自身所在的 Cell，而不是整個叢集，因此天生具備支撐單叢集大規模部署能力。增大規模時，只需要相應增加 Cell 即可，因此具有非常靈活的可擴充套件能力。

子 Cell 的虛擬機器資訊會逐層向上同步複製到其父 Cell 中，Top Cell 中包含了所有 Cells 的虛擬機器資訊，檢視虛擬機器資訊時，只需要從 Top Cell 資料庫查詢即可，不需要遍歷子 Cell 資料庫。對虛擬機器進行操作時，如果不使用 Cell，則只需要根據其 Host 欄位，向宿主機傳送 RPC 請求即可。如果使用了 Cell，則需要首先獲取虛擬機器的 Cell 資訊，通過 Cell 資訊查詢訊息佇列地址，然後往目標訊息佇列傳送 RPC 請求。

Nova Cell 生產案例

Nova Cells 方案很早就已經存在一些生產案例了，其中 CERN（歐洲原子能研究中心）OpenStack 叢集可能是目前公開的規模最大的 OpenStack 部署叢集，截至2016年2月部署規模如下：

1. 單R egion，33個Cell。
2. 2個 Ceph 叢集。
3. 約5500個計算節點，5300KVM 和 200Hyper-V，總包含140k Cores。
4. 超過17000個虛擬機器。
5. 約2800個映象，佔 44TB 儲存空間。
6. 約2000個 Volumes，已分配800TB。
7. 約2200個註冊使用者，超過2500個租戶。

其 Nova 部署架構如圖4。

圖4 CERN OpenStack 叢集 Nova 架構

天河二號是國內千級規模的典型案例之一，於2014年初就已經在國家超算廣州中心並對外提供服務，其部署規模如下：

1. 單 Region，8個 Cell。
2. 每個 Cell 包含2個控制節點和126個計算節點。
3. 總規模1152個物理節點。
4. 一次能建立大約5000個左右虛擬機器。
5. 每秒可查詢約1000個虛擬機器資訊。

除了以上兩個經典案例外，Rackspace、NeCTAR、Godaddy、Paypal 等也是採用了 Nova Cells 方案支援千級規模的 OpenStack 叢集部署。這些生產案例實踐證明了使用 Nova Cells 支援大規模 OpenStack 叢集的可能性。

Nova Cells 遇到的坑

剛剛介紹了不少 Nova Cells 的成功生產案例，讓人不禁“蠢蠢欲動”，想要小試牛刀。筆者已經架不住誘惑，於是專門申請了23臺物理伺服器作為 Nova Cells 測試環境使用，實際部署時包含3個 Cells，每個 Cell 包含7臺物理伺服器，其中1臺控制節點，一臺 Ceph All-in-one 節點，剩餘為5個計算節點。另外多餘的兩臺分別作為 Top Cell 的控制節點和網路節點。部署的 OpenStack 版本為 Mitaka，使用社群原生程式碼。在部署過程中遇到了大大小小不少坑，有些是配置問題，有些是 Cells 本身的問題。

虛擬機器永久堵塞在 scheduling 狀態

我們知道，每個 Cell 都使用自己的獨立資料庫，因此配置 Nova 的資料庫時，顯然需要配置其所在 Cell 的資料庫地址。而從 Mitaka 版本開始已經把一些公共的資料從 nova 資料庫單獨分離出來一個資料庫 nova _ api（原因後面說明）。建立虛擬機器時 Nova-API 不會把初始化資料直接儲存到 nova 資料庫的 instances 表中，而是儲存到 nova _ api 資料庫的 build _ requests 表，此時虛擬機器狀態為 scheduling 。Nova API 獲取虛擬機器資訊時會首先查詢 nova _ api 的 build _ requests 表，如果存在記錄，則直接返回虛擬機器資訊。正常流程下，當執行完排程後，Nova-Conductor 會自動刪除 build _ requests 的虛擬機器資訊。但是在配置多 Cell 情況下，如果 nova_api 也是配置其所在 Cell 的資料庫地址，當排程到 Compute Cell 中時，Compute Cell 資料庫的 build _ requests 顯然找不到該虛擬機器的資訊，因為實際上資訊都儲存在 Top Cell 中，因此 Top Cell 的 build _ requests 中的虛擬機器資訊將永遠不會被刪除。此時我們使用 nova list 檢視的虛擬機器資訊是從 build _ requests 拿到的過時資料，因此我們檢視虛擬機器狀態永久堵塞在 scheduling 狀態。解決辦法是所有 Cell 的 nova _ api 資料庫都配置使用同一個資料庫，nova _ api 資料庫本來就是設計為儲存公共資料的，為所有的 Cell 所共享。

分配網路失敗導致建立虛擬機器失敗

解決了上一個問題後，發現仍然建立虛擬機器失敗，虛擬機器一直堵塞在 spawning 狀態直到變成 error 狀態，在計算節點呼叫 virsh list 命令發現其實虛擬機器已經建立成功，只是狀態為 pause。

通過現場日誌發現，正常流程下，建立虛擬機器時，Neutron 完成虛擬網路卡初始化後會通過 Notification 機制傳送通知到訊息佇列中，Libvirt 會預設一直等待 Neutron 虛擬網路卡初始化成功的事件通知。在多 Cell 環境下，因為 Cell 只是 Nova 的概念，其它服務並不能感知 Cell 的存在，而 Nova 的 Cell 使用了自己的訊息佇列，Neutron 服務發往的是公共訊息佇列，因此Nova-Compute 將永遠收不到通知，導致等待事件必然超時，Nova 誤認為建立虛擬網路卡失敗了，因此建立虛擬機器失敗。Godday 和 CERN 同樣遇到了相同的問題，解決辦法為設定 vif _ plugging _ is _ fatal 為 false，表示忽略 Neutron 訊息等待超時問題，繼續執行後續步驟。另外需要設定等待的超時時間 vif _ plugging _ timeout，因為我們已經確定肯定會超時，因此設定一個較短的時間，避免建立虛擬機器等待過長，Godday 設定為5秒，可以作為參考。

nova show 檢視虛擬機器的 instance_name 與計算節點實際名稱不一致

這是因為 instance _ name 預設模板為 instance-x % id，其中 id 為虛擬機器在資料庫中的主鍵 id（注意不是UUID），它是自增長的。比如 id 為63 ，轉化為十六進位制為3f ，因此 instance _ name為 instance-0000003f。在多 Cell 情況下，Top Cell 儲存了所有的虛擬機器資訊，而子 Cell 只儲存了其管理 Cell 的虛擬機器資訊，儲存的虛擬機器數量必然不相等，因此同一虛擬機器儲存在 Top Cell 和子 Cell 的 ID 必然不相同。而我們使用 Nova API 獲取虛擬機器資訊是從 Top Cell 中獲取的，因此和虛擬機器所在的 Compute Cell 中的 instance _ name 不一致。解決辦法為修改 instance _ name _ template 值，使其不依賴於 id 值，我們設定為虛擬機器 UUID。

後端儲存問題

當部署小規模 OpenStack 叢集時，我們通常都會使用 Ceph 分散式共享儲存作為 Openstack 的儲存後端，此時 Glance、Nova 和 Cinder 是共享儲存系統的，這能充分利用 RBD image 的 COW（Copy On Write）特性，避免了映象檔案的遠端拷貝，加快了建立虛擬機器和虛擬塊裝置的速度。但當規模很大時，所有的節點共享一個 Ceph 叢集必然導致 Ceph 叢集負載巨大，I/O 效能下降。因此考慮每個 Cell 使用獨立的 Ceph 叢集，Nova 和 Cinder 共享 Ceph 叢集，Glance 是所有 Cells 的公共服務，需要單獨部署並對接其它儲存裝置。由於 Glance 和 Nova 不是共享儲存了，因此建立虛擬機器時就不能直接 Clone了，而必須先從 Glance 下載 Base 映象匯入到 Ceph 叢集中。建立虛擬機器時，首先看本地 Ceph 叢集是否存在 base 映象，存在的話直接 Clone 即可，否則從遠端 Glance 中下載到本地並匯入到 Ceph 叢集中，下次建立虛擬機器時就能直接 Clone 了。存在的問題之一時，目前 RBD Image Backend 並沒有實現快取功能，因此需要自己開發此功能。問題之二，如何管理 Cell 內部的 Ceph 映象快取，Glance 映象已經刪除後，如果本地也沒有虛擬機器依賴，則可以把 Base 映象刪除了，這需要定時任務來清理。問題之三，建立 Volume 時如何保證和虛擬機器在同一個 Cell 中，因為不同的 Cell 是不同的 Ceph 叢集，掛載就會有問題，其中一個可選方案是通過 Available Zone（AZ）來限制，此時使用者在建立虛擬機器和 Volume 時都必須指定 AZ，當使用者需要掛載 Volume 到其它 Cell 的虛擬機器時，必須先執行遷移操作。

很多功能不能用

由於 Nova Cells 採用二級排程策略，在排程 Cells 時並不能拿到所有 Hypervisor 的資訊，因此與之相關的功能都不能用或者出錯，比如主機集合、Server Group 等，排程功能也大大受限，比如 Compute Capabilities Filter、Numa Topology Filter、Trusted Filter 等，這些 Filters 為什麼不能用了？假如只有 Cell1 的主機滿足 Compute Capabilities，但是在排程 Cell 時排程到了 Cell2，由於 Cell2 沒有符合條件的主機，因此必然會排程失敗，但顯然我們有合法的宿主機。另外，Nova Cells 雖然對使用者是透明的，但其本身還是存在隔離的，目前不同 Cells之 間不支援虛擬機器遷移操作，當一個 Cell 出現故障時，也不能疏散到其它 Cell 中。

虛擬機器資訊不一致

虛擬機器資訊被儲存在多處，所有的子 Cell 都必須同步複製到 Top Cell 中，一旦同步出現問題導致資料不一致性，就可能出現非常棘手的問題。比如在 Compute Cell 中的某一個虛擬機器由於某些原因狀態變成 ERROR 了，但沒有同步到 Top Cell 中，使用者看到的還是 Active 狀態，但後續的所有操作都會失敗，運維人員必須逐一檢查該虛擬機器經過的所有 Cell 的資料庫資料，直到 Compute Cell，發現狀態不一致，必須手動修改資料庫，這些操作都是十分危險的，必須具有非常熟練的資料庫運維能力。

Nova Cells“涅磐重生”

前面踩到的坑，社群也發現了這些問題，但由於這是由於 Nova Cells 的設計缺陷所導致的，要修復這些問題，只通過填填補補是不可能解決的，社群對這些問題的唯一反饋就是不建議在新的環境上部署 Cells 服務，後續 Cells 相關文件也不會再更新。目前社群已經徹底放棄了該方案，如今 Nova Cells 開發已經凍結了，意味著不會再開發任何新特性，也不會修復與之相關的 Bug，後續的開發也不會保證 Cells 的相容性。

So，Nova Cells 已死？值得慶幸的是，Nova Cells 其實並沒有徹底死去，而是涅槃重生了。從L版開始，社群扔掉原設計的同時，吸取之前的教訓，開始著手重新設計 Nova Cells 並徹底重構程式碼。為了區分，之前的 Nova Cells 命名為 Nova Cells v1，而新方案命名為 Nova Cell v2。Nova Cells v2 為了避免 Nova Cells v1 的問題，一開始就提出了幾個明確的設計原則和目標。

Nova 全面支援 Nova-Cells

之前 Nova Cells 是可選安裝的，開啟 Nova Cells 功能，必須額外安裝 Nova-Cells 服務以及額外配置，使用者對這個功能的瞭解和關注程度都是比較低的，而參與開發這一功能的開發者也很少，導致 Cells 的開發力度不夠，部署率低，成熟度低。而對於 v2 版本，Nova 開始全面支援，廢棄原來的 Nova-Cells 服務，不需要額外部署其它任何服務，減少了部署的複雜度，也容易從原來的非 Cells 架構中升級為 Cells 架構。在 N 版之後，Nova Cells 將成為必須部署方式，相當於 Nova 的內建功能，而不再是可選功能，這大大增加了使用者和開發者的關注度。

分離公共資料，只存放一處

為了解決之前的資料一致性問題，在 v2 版本中，從 M 版開始把公共資料從原來的 nova 資料庫中分離出來，放在單獨的 nova_api 資料庫中，這些公共資料包括：flavors，quotas；security group、rules，key pairs，tags，migrations，networks。

此方案解決了公共資料的不一致性問題。另外，Top Cell 也不再儲存虛擬機器資訊了，而僅僅儲存其 UUID 與 Cell 之間對映表，虛擬機器資訊只儲存在其所在的 Cell 中，Top Cell 與 Compute Cell 之間不再需要複製同步。由於完整資料只存放一處，不存在資料不一致問題，拿到的資料保證是正確的。

支援 Nova 的所有功能

前面提到 v1 版本存在功能限制，除此之外，對 Neutron 的支援也缺乏測試和驗證。而在 v2 設計目標中強調將支援所有功能，無任何功能限制，並且全面支援 Neutron 整合，不再考慮 Nova-Network。

最新的 v2 結構已經不是樹狀的了，而且沒有了 Nova-Cells 這個元件，其架構如圖5。

圖5 v2 結構的最新架構圖

從圖5可以看出，新版本的 Nova Cells v2 採用單級排程機制替代了原來的二級排程，由 Nova-Scheudler 服務負責排程 Cell，同時負責選擇 Cell 中的主機。另外還設計了個額外的 Cell0 模組，如果你在進行虛擬機器排程操作時，排程到任何一個 Cell 都出錯，或者沒有可用 Cell 的話，這是系統會先將請求放置在 Cell0 中，Cell0 中只有一個 Nova DB，沒有訊息佇列和 Nova 服務。

Nova Cell v2 是一個革命性的變化，其設計目標已經非常明確，也是最期待的方案，但離完全實現還有一定的距離，目前還不支援多 Cells 排程，很多功能正在緊急開發中，目前還不能投入生產使用，不過社群後續會推出 v1 升級 v2 或者非 Cell 轉化為 Cell 架構的工具。

不過 Nova Cells v2 也存在問題，我認為：

1. 查詢虛擬機器資訊時，需要首先在 Top Cell 中拿到所有虛擬機器的索引和 Cell 對映，然後需要往所有的 Cells 請求資料，這可能導致查詢效能低下。
2. 當某個 Cell 出現故障時，就拿不到這部分虛擬機器資訊了，這個問題該如何處理？
3. Cells 之間通過訊息佇列通訊，如果跨 DC 部署，效能就會非常低下。

任何方案都不能是十全十美的，雖然 Nova Cell v2 也存在問題，但仍值得期待並給予厚望，希望 Nova Cells v2 不會讓我們失望，徹底解決 OpenStack 大規模部署問題。

總結與展望

本文首先介紹了大規模部署 OpenStack 存在的主要問題，引出資料庫和訊息佇列是限制大規模部署的主要瓶頸，然後針對這個瓶頸問題介紹了一些元件優化策略，最後詳細介紹了幾種 OpenStack 大規模部署的方案，分析了其特點和不足。針對大規模部署問題，Nova Cell v2 和 Trio2o 都是比較值得期待的，其設計理念和目標也比較明確，但是離實現和發展成熟還有一定的距離。Region 方案只是共享認證和 Dashboard，實現統一管理多 OpenStack 環境，原則上不算是單 OpenStack 的大規模部署。Nova Cell v1 已經有不少大規模部署的案例，但社群已經不再支援，並且不鼓勵在新的環境中部署。如果目前需要上線大規模OpenStack生產環境，有以下兩種方案：

1. 使用 Nova Cell v2，同時加入 v2 開發，缺點是開發所有功能的週期不確定，也面臨很多變數。
2. 使用 Nova Cell v1，部署架構有可供參考的案例，缺點是後續的所有問題都需要自己解決，得不到上游的支援。

當然也可以先部署一套小規模的環境，等 Cell v2 開發完成後，使用升級工具調整架構，增加 Cells 功能。

業務視角下的微服務架構設計例項

Hurricane 實時處理系統架構剖析

實施微服務的關鍵技術架構

網易雲容器服務基於 Kubernetes 的實踐探索

Kubernetes、 Microservice 以及 Service Mesh 解析

閱讀全文: http://gitbook.cn/gitchat/geekbook/5a5eafebdff55721bc1dcacc