本系列會介紹OpenStack 企業私有雲的幾個需求：
- 自動擴展（Auto-scaling）支持
- 多租戶和租戶隔離 （multi-tenancy and tenancy isolation）
- 混合雲（Hybrid cloud）支持
- 主流硬件支持、雲快速交付 和 SLA 保證
- 大規模擴展性支持
- 私有雲外圍環境支持（包括支持CDN 、商業SDN控制器、防火牆和VPN/專線等）
- 向上擴展性（PaaS 和 SaaS 等支撐）
- 企業數據中心IT環境支持（包括裸金屬/Bare metal、F5 、GPU、跨雲網絡連通、租戶計費、備份等支持）
- 行業解決方案
- 獨立的服務，包括培訓、運維等
擴展性（Scalability）是雲的基本要素之一，因此對 OpenStack 雲也不例外。
一方面，和已經非常成熟的公有雲和私有雲方案相比，目前的 OpenStack 在擴展性方面還有很多的不足，這些不足給其大規模擴展性帶來了相當多的問題。另一方面，擴展性本身也許不是太大的問題，比如一個雲能夠支持200個節點還是支持300個節點也許不是那么重要，但是，個人認為，擴展性和產品的品質是息息相關的。一個具有良好擴展性的OpenStack 私有雲產品，是可以比較容易地和它的高質量聯系上的，一個能支持大的規模擴展性良好的系統，其穩定性、可靠性、可用性都將會比較好。
本文基於目前一些 OpenStack 私有雲擴展性的公開成果，結合自己的理解，談談如果設定 OpenStack 企業私有雲的擴展性目標，以及在技術上如何實現這些目標。
1. 擴展性的范圍和一些公開的數據
1.1 擴展性的范圍
OpenStack 雲包括存儲、計算和網絡，其中：
- 存儲往往是外部存儲，包括開源的比如 Ceph，以及商業的比如 EMC，IBM的企業級存儲，因此，存儲的的擴展性可以另行討論。
- 網絡的擴展性，是在 OpenStack 擴展性的范圍內
- 計算的擴展性，是在 OpenStack 擴展性的范圍內
1.2 幾個可比較的公開數據
1.2.1 單個HP Helion 私有雲的擴展性上限：200 計算節點，1000虛機
（來源）
1.2.2 單個華為私有雲的擴展性上限：1024 計算節點，80000虛機
（來源於華為官網）
1.2.3 VMware vSphere 6.0 擴展性：每個 vCenter 最多管1000個節點，8000個虛機
（來源於VMware官網）
1.2.4 據 2015 OpenStack 社區的用戶調查，56% 用戶的虛機數在50以內，30% 用戶的虛機數在500以內。
2. 一些公開的大規模測試案例
2.1 Mirantis 在 SoftLayer 上分別所做的200個和350個節點環境的測試
2.1.1 環境配置
Totals for resources are: * 100,000 vCPUs * 6250 Gb of RAM * 200TB of disk space. * 400 hardware servers #最多400台服務器 * CPU as 1:32 * RAM as 1:1.5, * OpenStack 2013.2 (Havana) * only three OpenStack services: Compute (Nova), Image (Glance) and Identity (Keystone). * For networking, we used the Nova Network service in FlatDHCPmode with the Multi-host feature enabled. * standard Mirantis OpenStack HA architecture, including synchronously replicated multi-master database (MySQL+Galera), software load balancer for API services (haproxy) and corosync/pacemaker for IP level HA * Rally
2.1.2 200 個節點的測試結果
在做少量配置修改的情況下（修改 sqlalchemy 的 連接池大小從 5 為 100；修改 haproxy 的連接數為 16000 ），創建虛機的成功率達到 99.96%：
也就是說，OpenStack 社區版本支持 200 個計算節點的環境基本上是不需要做什么代碼修改和優化的，這種支持是內在的。
2.1.3 350 個節點環境的測試結果
成功率略有下降，但是下降有限。
2.2 CERN 私有雲使用 Nova Cell 管理超過5000個計算節點
他們使用 33 個 Cell，每個 Child Cell 大概 200 個計算節點，管理超過 5000 個計算節點。詳情請參考 超千個節點OpenStack私有雲案例（1）：CERN 5000+ 計算節點私有雲。
3. 提高擴展性的一些技術
3.1 計算資源的擴展：Nova-cell
3.1.1 Nova Cell 的分層架構
OpenStack 在G 版本引入了 nova-cell 技術，概括如下：
- 每一個Cell中擁有獨立的DB和AMQP broker
- 引入新的nova-cell服務
- 消息路由
- 調度(與主機調度不同，子Cell通過定時刷新將自己能力和資源上報給父Cell)
- cell之間通信通過RPC
- cells之間是樹狀結構
- 頂層是API cell，不感知底層物理主機以及虛擬化
- 子cell無nova-api服務
- 子cell無quota概念(NoopQuota)
因此，nova cell 的功能允許我們以更加靈活的分布式的方式實現對 OpenStack Compute 雲的縮放，而不需要更加復雜的技術，只需數據庫和消息隊列等。它的目的是支持更大規模的部署。當啟用了這個功能的時候，OpenStack Compute 雲中的主機會被分組，稱作 cell。cell的結構是樹的形式。top-level 級別的 cell 中的主機運行一個 nova-api 服務，但是可以沒有 nova-compute 服務。每一個子 cell 應該運行常規 OpenStack 雲計算中所有nova-*類型的服務，除了nova-api服務。我們可以把一個cell樹結構看成一個正常的OpenStack Compute部署，因為在這個樹中的每個cell中都有自己的數據庫服務和消息隊列服務。
nova-cells 服務處理cell之間的通信，並選擇一個cell用於建立新的實例。這個服務將會被每個cell所需要的。cell之間的通信是可插拔的，目前cell之間的通信只是通過RPC服務來實現的。采用cell服務實現了cell的調度和主機節點的調度是相互分離的。nova-cells 服務首先會選擇一個cell（目前實現的是隨機選擇，將來會添加過濾/權重功能，還可以基於廣播獲取的capacity/capabilities等參數）。一旦合適的cell被選擇，且建立新的實例的請求到達了這個cell的nova-cells服務之上，這個cell將會發送建立新的實例的請求到這個cell的主機調度器。
3.1.2 Nova Cell 的現狀和問題
Nova Cell 有 V1 和 V2 兩個版本。目前，V1 的開發已經被凍結，大量的 bug 沒有被修復；V2 還在開發過程中，還沒有正式 GA，因此，其架構還不夠穩定，官方並不推薦在生產環境部署使用。因此，如果廠商需要使用 Nova Cell 的話，需要自己做開發和維護，但是在目前，這似乎是擴展計算資源唯一的方式，因此，可以看到不少的客戶在使用 CERN、天河、RackSpace 和 eBay 等等。
3.2 網絡資源的擴展
3.2.1 標准 Neutron
標准 Neutron 的擴展性非常差，這是因為跨網段的網絡流量全部需要經過網絡節點，這使得它成為一個瓶頸，阻止了雲規模的進一步擴展。
HP 曾經在它的公有雲上使用 OpenStack，其 Neutron 是基於 IceHouse 版本的。他們總結了一些建議，包括：
- Upgrade neutron (Icehouse is better than Havana is better than Grizzly…)
- Make sure your neutron server is properly provisioned and tuned
- Make sure the metadata agent is properly tuned
- Upgrade your kernel (newer is generally better)
- Make sure sudo is properly versioned and tuned
- Expect improved stability, performance and scalability in Juno
完整信息請參考原文。
3.2.2 Neutron DVR
DVR 是在 Juno 版本引入的，詳細的解釋可以參考 理解 OpenStack 高可用（HA）（3）：Neutron 分布式虛擬路由（Neutron Distributed Virtual Routing）
DVR 是對標准 Neutron 的一個優化，它帶來了一些優點，但是也引入了新的很大的問題：
| 優勢 | 劣勢 |
| 將東西網絡流量和 DNAT 分布到計算節點上 | 給消息隊列帶來了非常大的壓力（比如，同步 ARP 到所有的 names） |
| 顯然地減少了網絡節點的壓力 | 管理復雜 |
| 巨大的代碼改動，影響代碼的穩定性 | |
| 使用 Linux TCP/IP 協議棧帶來的性能下降 |
3.2.3 SDN：能解決某些場景下的問題，但是不能解決全部問題
本質上，SDN 是一個集中式方案，它不是為了解決 Neutron 的擴展性問題，而是為了解決性能和管理性問題的。
下面是國內盛科的一個SDN 解決方案：
它能一定程度上消除單點瓶頸，並帶來擴展性的提升：
但是，SDN 本身使用邏輯上集中的 SDN Controller （控制器），即使它們是物理上分布式的，其本身的擴展性還是有一定的限制。
<04/20 更新 >
UMCloud 發出 聯合呈現首個公開商業 SDN OpenStack 數據中心解決方案 ，Mirantis、戴爾與 Big Switch 在戴爾公司數據中心內合作部署並測試了完全填充的8個機架（300節點）OpenStack 數據中心設置。整個解決方案包含：
- Dell Networking 交換機和服務器——包含一系列10/40GbE開放式網絡交換機（S6000-ON和S4048-ON）及1RU機架式服務器（PowerEdge系列）；
- Mirantis OpenStack 6.1——含 Mirantis Fuel Installer，可快速、靈活並穩定地部署 OpenStack 組件；
- Big Cloud Fabric（P+V版本）——含適用於使用ML2驅動程序和L3插件的L2+L3網絡的 BCF OpenStack Neutron Plugin，為生產級 OpenStack 部署提供所需的規模和彈性；
- BCF OpenStack Installer (BOSI)——OpenStack 安裝的一個插件，與 Mirantis Fuel 等安裝程序無縫互操作，以處理操作系統控制器和計算節點上所有與網絡相關的安裝和配置任務；
Big Switch Networks 推出了業內第一款統一 SDN 結構Big Cloud Fabric（P+V版本），為 OpenStack 數據中心提供高彈性和自動化的網絡解決方案。Big Cloud Fabric (BCF) 構建為分支、主干和虛擬交換機結構，采用 BCF Controller 作為單一窗口，以便對整個物理和虛擬網絡環境進行設置和故障排除，並提供環境的可見性和分析。
測試的主要 OpenStack Neutron 增強功能和特性包括：
-
分布式虛擬路由和分布式NAT/浮動IP——解決L3代理瓶頸和流量發卡問題；
-
簡化的故障排除——提供跨物理和虛擬交換機的端到端可見性，包括安全組策略；
該測試也印證了我的 SDN 能夠支撐 300 到 500 個節點規模的集群的觀點。
3.2.4 DragonFlow
據說它是為了解決 Neutron DVR 的問題而來的，它和 DVR 相比的一些優勢：
關於 DragonFlow 更詳細的說明，請閱讀官方文檔。目前，其開發由華為主導，依然在進行中，因此，它還無法在生產系統中使用。
3.2.5 Neutron 的優化，一直在進行，一直在路上
也許可以考慮以下思路：
- 300 個節點以內的環境，可以使用經過仔細測試和配置優化的標准 Neutron
- 300 到 500 個節點的環境，可以考慮使用 SDN
- 500 個節點以上的環境，需要采用分布式方案，包括分布式 SDN和優化后的 Neutron DVR 等方案
3.3 控制服務的擴展性
因為大部分的控制服務是無狀態的，因此，可以通過水平擴展的方式來提供其擴展性。以天河二號為例，他們使用的配置來管理超過 6000 個節點的環境：
OpenStack ─ IceHouse （2014.1） * 8個nova控制節點：運行nova-api和nova-cells； * 8個鏡像服務節點：運行glance-*服務； * 8個卷服務節點：運行cinder-*服務； * 8個網絡控制節點：運行neutron-server服務； * 16個網絡服務節點：運行neutron-*-agent服務； * 8個認證服務節點：運行keystone服務； * 6個消息隊列的節點：，運行Rabbitmq； * 6個數據庫的節點：運行MySQL； * 4個負載均衡節點，采用LVS+Keepalived實現API節點的調度分發與高可用； * 2個Horizon節點； * 8個ceph 監控節點，運行ceph mon服務； * 16個監控節點：為了實現對當前系統狀態的監控與報警，還部署了16個節點用作Ganglia和Nagios的服務器端；
4. 如何設定 OpenStack 企業私有雲的擴展性目標
從HP和華為的產品的數據看，各自的擴展性上限的差別非常大；從客戶的需求看，從幾台計算節點，到幾千台計算節點，都有需求。那到底如何來設定一個從技術和成本上都比較合理的擴展性上限呢？本人結合上文的分析，認為下面的設置是比較合理的：
| 規模級別 | 計算節點上限 | 網絡方案 | 計算方案 | 實現成本 | 客戶需求 | 市場競爭激烈程度 |
| 小 | 200 | 標准 Neutron | 標准 Nova | 低 | 量大，適合於小型客戶 | 非常高 |
| 中 | 500 | 優化后的集中式方案，比如優化和裁剪后的標准Neutron 以及 SDN | 類似於 Nova Cell 的分層方案 | 中下 | 適量，適合於中型客戶 | 中 |
| 大 | 1000 | 分布式方案，比如分布式 SDN 或者優化后的 Neutron DVR | 類似於 Nova Cell 的分層方案 | 中上 | 較少，適合大型客戶，或者 IDC | 低 |
| 超大（公有雲規模） | 幾千甚至上萬 | 需要從各個方面進行修改優化，包括架構修改、代碼重寫、新功能添加，以及使用第三方的組件，可能能夠實現 | 高 | 往往是公有雲提供商自行開發 | 僅僅若干廠商才能實現 | |