OpenStack大規模部署詳解

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 } }

根據節點所在樹中位置以及功能，分為兩種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()

通過源碼發現，正常流程下，創建虛擬機時，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也存在問題，我認為：

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生產環境，有以下兩種方案：

• 使用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