OpenStack大規模部署詳解

https://blog.csdn.net/karamos/article/details/80130443

0.前言
今年的2月22日，OpenStack發佈了15個版本Ocata。

走過了7年的發展歲月的OpenStack已經成爲了雲計算領域中最火熱的項目之一，並逐漸成爲IaaS的事實標準，私有云項目的部署首選。OpenStack社區可能本身都沒有想到其發展會如此之迅速，部署規模如此之大，以致於最開始對大規模OpenStack集羣的部署支持以及持續可擴展性彷佛並無考慮完備。

衆所周知，OpenStack每個項目都會有數據庫的訪問以及消息隊列的使用，而數據庫和消息隊列是整個OpenStack擴展的瓶頸。尤爲是消息隊列，伴隨着集羣規模的擴展，其性能降低是很是明顯的。一般狀況下，當集羣規模擴展到200個節點，一個消息可能要在十幾秒後纔會響應，集羣的總體性能大大降低[1]，英國電信主管Peter Willis聲稱一個獨立OpenStack集羣只能最多管理500個計算節點[2]。

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

1.單集羣優化策略
1.1 使用獨立的數據庫和消息隊列
前面提到限制OpenStack規模增加的最主要因素之一就是因爲數據庫和消息隊列的性能瓶頸，所以若是可以有效減輕數據庫以及消息隊列的負載，理論上就能繼續增加節點數量。各個服務使用獨立的數據庫以及消息隊列顯然可以有效減少數據庫和消息隊列的負載。在實踐中發現，如下服務建議使用獨立的數據庫以及消息隊列:

Keystone: 用戶以及其它API服務的認證都必須通過Keystone組件，每次Token驗證都須要訪問數據庫，隨着服務的增多以及規模的增大，數據庫的壓力將會愈來愈大，形成Keystone的性能降低，拖垮其它全部服務的API響應。所以爲Keystone組件配置專門的數據庫服務，保證服務的高性能。
Ceilometer：Ceilometer是一個資源巨耗型服務，在收集消息和事件時會發送大量的消息到隊列中，並頻繁寫入數據庫。爲了避免影響其它服務的性能，Ceilometer一般都搭配專有的數據庫服務和消息隊列。
Nova: OpenStack最活躍的主體就是虛擬機，而虛擬機的管理都是由Nova負責的。幾乎全部對虛擬機的操做都須要經過消息隊列發起RPC請求，所以Nova是隊列的高生產者和高消費者，當集羣規模大時，須要使用獨立的消息隊列來支撐海量消息的快速傳遞。
Neutron：Neutron管理的資源很是多，包括網絡、子網、路由、Port等，數據庫和消息隊列訪問都十分頻繁，而且數據量還較大，使用的獨立的數據庫服務和消息隊列既能提升Neutron自己的服務性能，又能避免影響其它服務的性能。
1.2 使用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，也就無需存在數據庫中，避免了對數據庫的IO訪問，建立Token的速度相對UUID Token要快，不過驗證Token則相對要慢些[3]。所以在大規模OpenStack集羣中建議使用Fernet Token代替傳統的Token方案。

以上優化策略可以必定程度上減小消息隊列和數據庫的訪問，從而增大節點部署規模，但其實並無根本解決擴展問題，隨着部署規模的增加，總會達到瓶頸，理論上不可能支持無限擴展。

2.多Region方案
OpenStack支持將集羣劃分爲不一樣的Region，全部的Regino除了共享Keystone、Horizon、Swift服務，每一個Region都是一個完整的OpenStack環境，其架構以下：

 

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

部署簡單，每一個區域部署幾乎不須要額外的配置，而且區域很容易實現橫向擴展。
故障域隔離，各個區域之間互不影響。
靈活自由，各個區域可使用不一樣的架構、存儲、網絡。
但該方案也存在明顯的不足：

各個區域之間徹底隔離，彼此之間不能共享資源。好比在Region A建立的Volume，不能掛載到Region B的虛擬機中。在Region A的資源，也不能分配到Region B中，可能出現Region負載不均衡問題。
各個區域之間徹底獨立，不支持跨區域遷移，其中一個區域集羣發生故障，虛擬機不能疏散到另外一個區域集羣中。
Keystone成爲最主要的性能瓶頸，必須保證Keystone的可用性，不然將影響全部區域的服務。該問題能夠經過部署多Keystone節點解決。
OpenStack多Region方案經過把一個大的集羣劃分爲多個小集羣統一管理起來，從而實現了大規模物理資源的統一管理，它特別適合跨數據中心而且分佈在不一樣區域的場景，此時根據區域位置劃分Region，好比北京和上海。而對於用戶來講，還有如下好處:

用戶能根據本身的位置選擇離本身最近的區域，從而減小網絡延遲,加快訪問速度。
用戶能夠選擇在不一樣的Region間實現異地容災。當其中一個Region發生重大故障時，可以快速把業務遷移到另外一個Region中。
可是須要注意的是，多Region本質就是同時部署了多套OpenStack環境，確切地說並無解決單OpenStack集羣的大規模部署問題。

3.OpenStack Cascading方案以及Trio2o項目
OpenStack Cascading方案[9]是由國內華爲提出的用於支持場景包括10萬主機、百萬虛機、跨多DC的統一管理的大規模OpenStack集羣部署。它採起的策略一樣是分而治之，即把原來一個大的OpenStack集羣拆分紅多個小集羣，並把拆分的小集羣級聯起來統一管理，其原理如圖：

 

只有最頂層的OpenStack暴露標準OpenStack API給用戶，其包含若干個子OpenStack集羣。
底層的OpenStack負責實際的資源分配，但不暴露API給用戶，而必須經過其之上的OpenStack調度。
用戶請求資源時，首先向頂層OpenStack API發起請求，頂層的OpenStack會基於必定的調度策略選擇底層的其中一個OpenStack，被選中的底層OpenStack負責實際的資源分配。

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

4.Nova Cells方案
前面提到的OpenStack多Region方案是基於OpenStack環境切分，它對用戶可見而非透明的，而且單集羣依然不具有支撐大規模的能力和橫向擴展能力。而Nova Cells方案是針對服務級別劃分的，其最終目標是實現單集羣支撐大規模部署能力和具有靈活的擴展能力。Nova Cells方案是社區支持的方案，所以本文將重點介紹，而且會總結下在實際部署中遇到的問題。

4.1 Nova Cells架構和原理介紹
Nova Cells模塊是OpenStack在G版本中引入的，其策略是將不一樣的計算資源劃分紅一個個Cell，並以樹的形式組織，如圖所示：

 

圖2 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
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
根據節點所在樹中位置以及功能，分爲兩種Cell類型:

api cell，非葉子節點，該類型的Cell不包含計算節點，但包括了一系列子Cells，子Cells會繼續調度直到到達葉子節點，即Compute Vell中。其中最頂層的根節點一般也叫做Top Cell。
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請求。

4.2 Nova Cell生產案例
Nova Cells方案很早就已經存在一些生產案例了，其中CERN(歐洲原子能研究中心)OpenStack集羣多是目前公開的規模最大的OpenStack部署集羣，截至2016年2月部署規模以下[7]：

單Region，33個Cell。
2個Ceph集羣。
~5500個計算節點，5300KVM和200Hyper-V，總包含140k Cores。
超過17000個虛擬機。
~2800個鏡像，佔44TB存儲空間。
~2000個Volumes，已分配800TB。
~2200個註冊用戶，超過2500個租戶。
其Nova部署架構以下圖:

圖3 CERN OpenStack集羣Nova架構
天河二號是國內千級規模的典型案例之一，於2014年初就已經在國家超算廣州中心並對外提供服務,其部署規模以下[5]:

單Region，8個Cell。
每一個Cell包含2個控制節點和126個計算節點。
總規模1152個物理節點。
一次能建立大約5000個左右虛擬機。
每秒可查詢約1000個虛擬機信息。
除了以上兩個經典案例外，Rackspace、NeCTAR、Godaddy[6]、Paypal等也是採用了Nova Cells方案支持千級規模的OpenStack集羣部署。這些生產案例實踐證實了使用Nova Cells支持大規模OpenStack集羣的可能性。

4.3 Nova Cells遇到的坑
剛剛介紹了很多Nova Cells的成功生產案例，讓人不由「蠢蠢欲動」，想要小試牛刀。小編已經架不住誘惑，因而專門申請了23臺物理服務器做爲Nova Cells測試環境使用，實際部署時包含3個Cells，每一個Cell包含7臺物理服務器，其中1臺控制節點，一臺Ceph All-in-one節點，剩餘爲5個計算節點。另外多餘的兩臺分別做爲Top Cell的控制節點和網絡節點。部署的OpenStack版本爲Mitaka，使用社區原生代碼。在部署過程當中遇到了大大小小很多坑，有些是配置問題，有些是Cells自己的問題。

1. 虛擬機永久堵塞在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所共享。

2. 分配網絡失敗致使建立虛擬機失敗
解決了上一個問題後，發現仍然建立虛擬機失敗，虛擬機一直堵塞在spawning狀態直到變成error狀態，在計算節點調用virsh list命令發現其實虛擬機已經建立成功，只是狀態爲pause。Nova-Compute現場日誌以下:

2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [req-c2854f9b-9b00-45da-a2dd-561a3194c45d a8bfa47e180c41089e4232e76b16ac04 42e34b92273249ff9be85ef3d4fd38b8 - - -] [instance: 6a7377f5-86ac-4767-9110-29085de44e00] Failed to allocate network(s)
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] Traceback (most recent call last):
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1920, in _build_and_run_instance
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] block_device_info=block_device_info)
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2596, in spawn
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] post_xml_callback=gen_confdrive)
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4858, in _create_domain_and_network
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] raise exception.VirtualInterfaceCreateException()
1
2
3
4
5
6
7
8
經過源碼發現，正常流程下，建立虛擬機時，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秒，能夠做爲參考。

3. 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。

4.後端存儲問題
當部署小規模OpenStack集羣時，咱們一般都會使用Ceph分佈式共享存儲做爲Openstack的存儲後端，此時Glance、Nova和Cinder是共享存儲系統的，這能充分利用RBD image的COW(Copy On Write)特性，避免了鏡像文件的遠程拷貝，加快了建立虛擬機和虛擬塊設備的速度。但當規模很大時，全部的節點共享一個Ceph集羣必然致使Ceph集羣負載巨大，IO性能降低。所以考慮每一個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的虛擬機時，必須先執行遷移操做。

5.不少功能不能用
因爲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中。

6.虛擬機信息不一致
虛擬機信息被保存在多處，全部的子Cell都必須同步複製到Top Cell中，一旦同步出現問題致使數據不一致性，就可能出現很是棘手的問題。好比在Compute Cell中的某一個虛擬機因爲某些緣由狀態變成ERROR了，但沒有同步到Top Cell中，用戶看到的仍是Active狀態，但後續的全部操做都會失敗，運維人員必須逐一檢查該虛擬機通過的全部Cell的數據庫數據，直到Compute Cell，發現狀態不一致，必須手動修改數據庫，這些操做都是十分危險的，必須具備很是熟練的數據庫運維能力。

4.4 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的問題，一開始就提出了幾個明確的設計原則和目標:

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

2.分離公共數據，只存放一處
爲了解決以前的數據一致性問題，在v2版本中，從M版開始把公共數據從原來的nova數據庫中分離出來，放在單獨的nova_api數據庫中，這些公共數據包括:

flavors；
quotas；
security group、rules；
key pairs；
tags；
migrations；
networks。
此方案解決了公共數據的不一致性問題。另外，Top Cell也再也不保存虛擬機信息了，而僅僅保存其UUID與Cell之間映射表，虛擬機信息只保存在其所在的Cell中，Top Cell與Compute Cell之間再也不須要複製同步。因爲完整數據只存放一處，不存在數據不一致問題，拿到的數據保證是正確的。

3.支持Nova的全部功能
前面提到v1版本存在功能限制，除此以外，對Neutron的支持也缺少測試和驗證。而在v2設計目標中強調將支持全部功能，無任何功能限制，而且全面支持Neutron集成，再也不考慮Nova-Network。

最新的v2結構已經不是樹狀的了，並且沒有了Nova-Cells這個組件，其架構如圖：

 

從架構圖中能夠看出，新版本的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也存在問題，我認爲：

查詢虛擬機信息時，須要首先在Top Cell中拿到全部虛擬機的索引和Cell映射，而後須要往全部的Cells請求數據，這可能致使查詢性能低下。
當某個Cell出現故障時，就拿不到這部分虛擬機信息了，這個問題該如何處理？
Cells之間經過消息隊列通訊，若是跨DC部署，性能就會很是低下。
任何方案都不能是十全十美的，雖然Nova Cell v2也存在問題，但仍值得期待並給予厚望，但願Nova Cells v2不會讓咱們失望，完全解決OpenStack大規模部署問題。

總結與展望
本文首先介紹了大規模部署OpenStack存在的主要問題，引出數據庫和消息隊列是限制大規模部署的主要瓶頸，而後針對這個瓶頸問題介紹了一些組件優化策略，最後詳細介紹了幾種OpenStack大規模部署的方案，分析了其特色和不足。針對大規模部署問題，Nova Cell v2和Trio2o都是比較值得期待的，其設計理念和目標也比較明確，可是離實現和發展成熟還有必定的距離。Region方案只是共享認證和Dashboard，實現統一管理多OpenStack環境，原則上不算是單OpenStack的大規模部署。Nova Cell v1已經有很多大規模部署的案例，但社區已經再也不支持，而且不鼓勵在新的環境中部署。若是目前須要上線大規模OpenStack生產環境，有如下兩種方案：

使用Nova Cell v2，同時加入v2開發，缺點是開發全部功能的週期不肯定，也面臨不少變數。
使用Nova Cell v1，部署架構有可供參考的案例，缺點是後續的全部問題都須要本身解決，得不到上游的支持。
固然也能夠先部署一套小規模的環境，等Cell v2開發完成後，使用升級工具調整架構，增長Cells功能。

參考文獻[1] Nova Cells V2如何幫助OpenStack集羣突破性能瓶頸?[2] British Telecom threatens to abandon OpenStack in its current form.[3]benchmarking-openstack-keystone-token-formats[4]Scaling the CERN OpenStack cloud[5]OpenStack在天河二號的大規模部署實踐[6]OpenStack Architecture at Go Daddy[7]Cern Cloud Architecture - February, 2016[8]Moving to Nova Cells without Destroying the World[9]OpenStack cascading solution[10]Test report for OpenStack cascading solution to support 1 million VMs in 100 data centers[11]Cells v1 status[12]nova cells flow diagram[13]Nova cells v2 wiki[14]nova cells table analysis[15]ocata nova priorities tracking--------------------- 做者：少數pai 來源：CSDN 原文：https://blog.csdn.net/karamos/article/details/80130443 版權聲明：本文爲博主原創文章，轉載請附上博文連接！