3.2.2 Openstack Tricircle方案 11
多openstack部署
1引言
1.1編寫目的
一個openstack系統，當計算規模不斷擴大的時候，就會出現很多性能的問題，比如隊列性能下降，比如數據庫性能下降等。
另外面對多個不同的數據中心，每一個數據中心部署一個openstack的時候，就會出現怎么管理多個數據的問題。
本文檔就會主要討論下這兩種情況下的具體解決方案
2總體設計
2.1整體架構
2.1.1 單openstack節點性能問題解決方案
-
nova-cell v1 方案
-
nova-cell v2 方案
2.1.2 多openstack節點性能問題解決方案
-
region多個openstack獨立公用keystone
-
cascade方案的多openstack管理
-
Tricircle組件實現多個openstack 統一管理
3詳細設計
3.1單openstack擴容管理
3.1.1 nova-cell 原理
一般情況下 nova需要依賴一個邏輯的的數據庫和消息隊列來進行組件之間的相互交換，這就會給整個系統的擴容和災難遷移帶來困難。而數據庫和消息隊列正在成為openstack擴展的瓶頸。尤其是消息隊列，伴隨着集群規模的擴展，其性能下降尤其明顯。通常當集群規模擴展到200個節點，一個消息可能要十幾秒后才會響應，集群的整體性能大大下降。針對nova的這個問題，提出了nova-cell的概念，這個概念的提出主要是把計算節點分成更多個更小的單元，每一個單元都有自己的數據庫和消息隊列。
nova-cell 的發展過程中出現過v1版本和v2版本，其中v1版本的被接受情況一致不理想，v2版本是基於v1的教訓，提出的一個權限的架構，不過可惜的是v2版本的代碼至少也要等到N版本才會發布，所以現在還暫時只能使用v1版本的nova-cell組件
3.2.1 nova-cell v1 使用
使用
nova-cell采用樹狀結構來組織管理各個cell之間的關系，會有一個專門的組件叫nova-cell來進行消息溝通。各個cell之間現在只支持消息隊列來進行交互同步。有兩種類型的nova-cell
-
api 類型的nova-cell 節點，也有稱之為top cell的。里面會安裝有 database、mq、nova-cells、nova-api、keystone
-
compute類型的nova-cell 節點，也稱之為child cell。里面會安裝有 database、mq、nova-cells、nova-scheduler、nova-compute、nova-conductor
nova-cells 組件主要是負責cell之間的消息通信和創建vm的時候選擇cell。這個組件是每個cell必須要安裝的。cell的調度和vm的調度是不同的。nova-cells 首先選擇一個cell，一旦這個cell被選上后，當創建vm的請求到達這個cell后，cell中的nova-scheduler會繼續原來的調度過程發送到具體的某個計算節點上。
缺點
v1版本的nova-cell存在很多的問題主要是：
-
不支持安全組、主機集合、可用域、特定的調度算法
-
一個nova-cells需要做兩件事情的調度，既有內部的也有各個cell之間的
-
資源競爭問題
-
一直沒有推動起來，導致該模塊成熟度低，使用率低
-
如果之前沒使用nova-cell。重新准備使用nova-cell會比較困難
-
並且最頂層的那個top cell 還是無法擴展，仍然存在問題
-
各個層之間的數據復制
3.2.2 nova-cell v2 使用
使用
為了避免v1的問題，v2一開始就提出了幾個明確的目標
-
數據只可以放在一處
nova-api cell 中使用新的數據庫和以往不同，並且存放公共的數據，cells、vm、computes 之間的映射數據也存放在nova-api cell中
-
公共數據越少越好
nova-api cell 防止mapping數據，其他vm的大量數據都放在具體的cell內，避免當重新添加一個cell的時候大量的數據復制
-
全力支持nova-cell
nova全面支持nova-cell，在N版之后，默認就會使用nova-cell 而不是可選安裝了，並且支持所有的功能，沒有功能受到限制，另外還有一個默認的cell0，用來處理其他cell節點不能處理的請求
最新的v2結構已經不是樹狀的了，而且沒有了nova-cells這個組件
主要使用過程如下圖：
缺點
最快也要N版本才可以使用v2版本，而且很多的功能還在開發：
-
支持neutron的全部功能
-
支持多cell 個人理解就是 cell的ha
-
更多的調度控制
-
v1到v2的升級工具
3.2多openstack節點管理
3.2.1 region管理openstack
原理
region主要是為了區分地理位置上分開的兩個openstack節點，用戶可以選擇離自己更近的region來使用里面的資源。每一個region都是一個單獨的openstack 部署環境，region之間完全隔離，但是多個regions之間共享同一個keystone 和 dashboard
優點
-
部署簡單，keystone中直接指明不同region就可以實現
-
邏輯概念清晰，並且已經在生產中大量的使用
缺點
-
openstack 節點之間相互隔離，不能互訪
3.2.2 Openstack cascading方案
openstack cascading 方案的主要架構圖：
原理
cascading openstack 屏蔽了底層的多個openstack節點，對外只體現出有一個 openstack節點，可以實現對多個openstack的集成，和openstack規模的隨意擴展。比如一個跨地域跨數據中心的雲中存放有上千萬級的vm在運行，那么就特別適合多個openstack的統一管理
從架構圖上可以看出：
-
最上層的openstack節點，暴露出標准的 openstack api，這個openstack節點被稱為cacading openstack，主要是提供api、調度和編排管理下面的openstack節點，管理下面的子openstack節點也是使用 標准的openstack api
-
下層的openstack節點，也被稱之為cascaded openstack。主要負責創建虛擬機、存儲卷、網絡等資源。
-
每一個cascaded openstack 在cascading openstack 里面都表現為一個可用域，並且對用戶是不可見的
openstack cascading方案又被稱為 " openstack管理openstack " ,cascading多個openstack節點以后，用戶只需要訪問一個api 的endpoint就可以實現把用戶的虛擬機創建分布在多個openstack上面，對用戶而言 cascading openstack就相當於是一個虛擬的 region ，而多個后端的openstack 在用戶看來就是多個 available zones 可用域。可以形象的把 cascading openstack 比如我們經常說的openstack 控制節點，把下面的多個openstack比如 openstack的計算節點。
技術實現上主要是使用了openstack的driver機制：
如上圖的 紅色表現部分，原來的nova 對接的 driver 現在替換成了下層的openstack nova-api組件，類似的還有 neutron 的plugin 替換成了下層的 neutron-api ，其他組件也是類似。當然這中間需要有一個proxy 來實現上層的nova 請求 proxy到 底層的 nova-api，類似的neutron 也需要一個 network proxy 來實現上層的neutron-api請求能轉發到下層的openstack neutron-api中，類似下面的實現圖：
可以看到 cascading openstack 和 下面的cascaded openstack之間有一大片的黃色 proxy:
-
Nova-proxy 類似之前nova中的 kvm driver或者 VMwaredriver，不過現在對接的是另一個openstack 的nova
-
Cinder-proxy 類似之前的cinder-volume driver 現在的后端存儲用的是另一個openstack
-
L2-proxy 類似之前的ovs-agent
-
L3-proxy 類似之前的dvr l3-agent，不過使用的是后端的neutron
-
Fw-proxy、lb-proxy、vpn-proxy
這些proxy就是剛才原理中說的實現 上層的組件通過 driver 來使用下面的opentack的 driver實現。具體的實現代碼可以在github上找到：
https://github.com/openstack/tricircle/tree/stable/fortest
偶
官方號稱：
-
只有大概1萬5千行代碼實現了openstack cascading方案
優點
-
官方號稱最大支持100個數據中心、1百萬個compute、1百萬個vm
-
可以集成多個openstack環境，甚至非openstack環境，比如搭建混合雲
-
屏蔽底層，統一的api，共用網絡、flavor、鏡像等資源
-
能實現在兩個雲之間來回的遷移，甚至是不同的雲之間用v2v工具實現
-
網絡可以自動實現大二層和3層之間的跨多個雲互通
缺點
-
網絡方面主要還是依賴 vxlan、mpls 等類似的封包協議來實現跨地域的互通
-
華為只在一個東京的poc項目中使用過，其他項目暫時未發現有人使用
-
由於neutron cascade使用了provide network，而horizon上面只有管理員支持，但是參數不是我們想要的，所以創建網絡只能用cli 命令創建
-
現在只支持到J版本
-
L2層多openstack互通，目前只支持vxlan,並且只支持vm之間的點對點通信，l2網絡通過l2 GW來減少arp風暴
-
Cascading openstack 的api 管理屬於有狀態的請求，所以擴展會不方便
安裝
-
不帶glance cascade的安裝部署圖
- 帶 glance cascade的安裝部署圖
3.2.2 Openstack Tricircle方案
原理
當openstack cascading 方案發展的時候，社區就決定把這一部分實現邏輯單獨拿出來，並新開了一個項目就是Tricircle，可以說Tricircle就是openstack cascading的加強版
所以Tricircle的原理和cascading基本相同，主要實現原理如下圖：
和cascading的主要區別是：
- 多個openstack可以屬於一個可用域
- 每一個openstack被稱之為一個pod
- 上層的openstack也是通過 openstack api和底層openstack互通
- Tricircle使用 stateless 機制，更利於擴展節點
- 實現機制Tricircle 更加類似 nova-cell的機制，不過nova-cell是只擴展了nova，而Tricircle則是所有的組件都進行了擴展
也是使用原來 openstack中的 driver機制來實現 上層的openstack管理下層的openstack
不過是這次的driver 不叫 proxy 了而是叫做 api-gw比如：
場景
-
邊界雲部署
無論哪個城市的上傳視頻都到固定的集中節點，會造成性能下降和流量的浪費
正確的應該如下圖：
使用就近原則，某個城市的只上傳到本地的雲中，后期雲之間可以進行同步等操作
-
靈活的服務鏈
跨多個雲的靈活的服務鏈功能
優點
-
多個openstack節點的集成可能會造成api調用的性能的下降，Tricircle因此提出了使用異步的XJob來進行api的請求響應
-
無狀態的api調用，支持混合雲部署
安裝
Tricircle項目可以在github上找到：https://github.com/openstack/tricircle
代碼結構如下圖：
可以使用 pip方式來安裝，主要的安裝可以參考：
https://github.com/openstack/tricircle/blob/master/doc/source/installation.rst
4綜述
總結上面的幾個方案可以有如下的結論：
-
針對單個openstack我們可以使用nova-cell組件來只是提供nova的擴容，也就是實現nova使用的mq和database擴容，其中nova-cell v1版本一直在社區代碼中包含，但是實現上有問題，為了避免這些問題，並且強制推廣nova-cell的概念，社區又提出了nova-cell v2的概念，並且要求N版本以后必須強制使用，只可惜M版本的時候還沒用正式release
-
針對多個openstack的集成，可以分為兩個類別
-
多個openstack只共用dashboard和keystone，其他組件全部相互獨立，這個就是大家熟悉的region的概念，十分成熟，horizon也支持
-
另一個類別是多個openstack 被屏蔽到下層，而上層單獨有一個負責api路由的邏輯openstack節點，用戶只會用這個邏輯的openstack 控制節點來管理底層所有的openstack節點，而且底層的openstack節點可以是不同的版本，甚至不一定是openstack，而這個功能前期被稱作openstack cascading，發展到后來作為了一個獨立的項目叫Tricircle，兩個項目比較起來無論是代碼上還是成熟度、還是社區支持都是Tricircle好點