硅谷創業公司Mirantis不久前進行了一項基准測試，測試在OpenStack Havana版本上創建75000台虛擬機的性能數據。就啟動時間和成功率而言，當應用250個並發部署75000台虛擬機是最好結果。而測試過程中最高並發請求可達到500個。
以下內容對該測試的信息進行一些整理，並給出測試結果，供大家了解參考。
內容整理自：
http://www.openstack.cn/p963.html
http://www.mirantis.com/blog/benchmarking-openstack-megascale-tested-mirantis-openstack-softlayer/
測試目的
當部署上萬台虛擬機的情況下，OpenStack能否成功應對。出於這個目的，Mirantis進行了基准測試，主要有以下兩個考量。
- 虛擬數據中心（VDC）能否支撐上百個並發請求？
- 隨着虛擬機數量的增加，用戶體驗是否會受到影響？
為了得到第一個問題的答案，需要針對遞增的並發請求數進行一系列測試。Mirantis的目標是最大並發數能達到500。
對於第二個問題，可以用創建虛擬機所花費的時間來進行衡量。更重要的是，創建時間與已有虛擬機數目之間的依賴關系。
這次測試的目的不僅聚焦在Nova API及調度器（scheduler），VMM上的計算代理（computer agent）也有所涉及。
測試中想要驗證的SLA（Service-level agreement）參數基線有：
- 虛擬機實例啟動時間的方差，包括任何時間與雲數據庫中已有虛擬機數量間的依賴關系。
- 虛擬機實例啟動的成功率，換句話說，每100個請求中因各種原因失敗的請求數目。
前提及假設
由於測試只是要獲取創建虛擬機時間（deployment time）的基准，衡量OpenStack Compute service不需要在虛擬機中產生任何負載。
因此，采用了最小的flavor來創建虛擬機，並且不在虛擬機中進行任何任務。OpenStack默認的flavor大小對創建時間的影響不大。
測試規模
本次基准的目標：在單一個OpenStack集群中，運行100,000台虛擬機。
這個規模，大致與一個小型的移動應用服務相若。另一個與該工作負載相配的可能的用例是：一個對於跑在成千上萬個獨立移動終端上的移動服務的測試環境。
測試環境
【虛擬機配置】
測試使用的flavor大小：1VCPU，64MB內存，2GB硬盤空間。該flavor比AWS的m1.micro規格更小，僅剛好夠啟動Cirros的測試鏡像。
由於測試目標是100,000台虛擬機，所以總共的虛擬機資源如下：
- 100,000個VCPU
- 6250Gb大小的內存
- 200TB的硬盤空間
【物理機配置】
每台物理機的配置情況：
- 4個物理核（由於開啟超線程，共計8個邏輯cpu），16Gb內存及250GB硬盤空間。
- CPU過載：1:32（OpenStack默認值的2倍）
- 內存過載：1:1.5（不會在虛擬機中產生負載）
因此，單台物理機可提供的資源如下：
- （4+4）*32 = 256VCPU
- 16*1.5 = 24Gb內存
- 250GB硬盤
通過與虛擬機配置進行比較可以得出：每個物理幾點上應創建250台虛擬機。大約需要400台物理機才可支撐100,000台虛擬機的規模。
【測試機配置】
除了提供OpenStack環境的物理機之外，還需要有測試機來產生大並發請求。原文中稱這種測試機為controller。
每個controller的配置為：128GB內存及SSD硬盤（大小不詳），CPU信息不詳。
軟件版本及參數
測試中使用的軟件為Mirantos OpenStack 4.0，包含了OpenStack 2013.2（Havana），並將OpenStack部署到SoftLayer。
配置部分只針對三個服務：Nova，Glance及Keystone。 對於網絡，使用Nova Network的FlatDHCP模式並開啟Multi-host功能。
基准測試中，需要增大特定的參數，最主要的是SQLAlchemy模塊連接池的數量（nova.conf中的maxpoolsize及max_overflow參數）
【測試引擎】
采用的測試引擎為Rally，Rally允許配置每個輪次的相關參數，並記錄各個請求完成的時間。
測試結果
原文提供了部分用例的結果，首先對較小的規模進行測試。
已有5000台虛擬機，100個並發請求（創建虛擬機）。
|
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
|
5000
|
98.96
|
33.54
|
120.08
|
66.13
|
78.78
|
83.27
|
已有25000虛擬機，250個並發請求（創建虛擬機）。
|
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
|
25000
|
99.96
|
26.83
|
420.26
|
130.25
|
201.1
|
226.04
|
測試中出現了瓶頸，通過調整sqlalchemy及haproxy的連接池參數后瓶頸消失。其中，sqlaclchemy的連接數從5調整到100，haproxy從4000調整到16000。
測試中出現了haproxy的失敗率上升的現象，這是由於haproxy連接池的連接被用盡導致Pacemaker將虛擬IP地址轉移到了另一個controller的節點上。當失敗發生后，負載均衡器失去響應。這個問題通過提高haproxy的連接限制而得以解決。
上述准備工作完成后，開始向100,000台虛擬機的目標進發。虛擬機數量逐漸遞增：從10,000、25,000、40,000、50,000、75,000到100,000。測試結果顯示250個並發請求是系統能維持穩定的最高值。在此基礎上追加了150個物理節點，即共有350台物理機，外加3台測試機（controller server）。
根據前面的測試結果，修正了測試目標，從100,000下降到75,000台。最后，創建75,000台虛擬機共花費了8個小時的時間，下圖顯示了創建時間（boot time）與正在運行虛擬機個數（the number of running VMs）間的關系：
已有75000台虛擬機，500並發請求（創建虛擬機）。
|
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
|
75000
|
98.57
|
23.63
|
614.29
|
197.6
|
283.93
|
318.96
|
結果中可以看出，500並發請求時，平均時間為197.6秒。
【總結】
Mirantis OpenStack可以容納500個並發請求，並維持在250個並發請求在單個集群中創建75000台虛擬機。
本章中提到的一個重要的成功因素是，測試采用了IBM SoftLayer的硬件和網絡架構，因而很方便的管理了網絡連接，也能夠很容易的擴展成多個OpenStack集群。
Mirantis下一步打算測試虛擬機中運行的基准測試，針對硬盤和網絡IO進行測試。