如果你的云系統非常成功，遲早會有往云里添加新資源的需求。OpenStack直接支持橫向擴展。你可以在已有的云系統中添加更多的服務器而不需要在服務器上進行縱向升級。理論上可以在擴展云系統的同時而不影響提供的服務。

起點

如何計劃云系統擴展性需要在很多的變量配置中進行平衡。沒有***方案可以滿足所有的擴展需求。即使這樣在實際運維中監控大量系統指標還是有很多益處。

常見的規劃出發點就是云系統的核心數量。可用一些基本公式，估算相關容量信息。如：(重用因子 X 物理核數) / 每實例所需虛擬核：估算可運行虛擬機數量；磁盤空間 X 實例數量：估算系統需求的存儲容量。通過這些估算信息可以決定在云中額外需要添加多少資源。

OpenStack的系統默認值如下：

我們假設以下條件：

對于API服務，數據庫和消息隊列則需要更多信息才能進行評估。你還需要了解云系統的使用規律。比如：比較2種虛擬機的使用情況，一種是用于web平臺，另一種是用于項目開發過程中使用的集成測試。前者所用的虛擬機可能每隔幾個月才有增加；而后者則經常會發生變動，造成對云控制器較多請求負荷。收集虛擬機的平均使用時間，當該指標值較大時相應的云控制器的負荷會較小。

伴隨的虛擬機的開啟和關閉，還需要考慮用戶對于服務訪問所造成的影響，特別是nova-api和相應的數據庫。用戶最常用的就是列出虛擬機實例清單和相關信息。當云系統有很多用戶時，列出虛擬機實例清單這樣的操作也會帶來較大的系統負荷。有時用戶自己都沒有意識到這種操作(如：打開OpenStack儀表盤進入實例頁界面中，瀏覽器會每隔30秒刷新一次虛擬機列表信息)。

在考慮了以上因素后，你可以大致判斷出云控制器的配置要求。通常8核，8G內存的服務器足以應付一個服務器機架內的計算節點。

除此外為了用戶使用虛擬機的性能，你還需要考慮硬件本身的一些指標，同時平衡預算和性能需求。如：存儲性能(磁盤數量/核數)，內存可用性(內存空間/核數),網絡帶寬(Gbps/核數)和CPU總性能(CPU/核數)。

可以查看**監控**章節獲得可以跟蹤哪些指標來判斷是否需要進行云系統的擴展。

添加控制器節點

你可方便的通過添加更多的節點來橫向擴展云系統。添加計算節點是一件容易的事情，你只需要和原來一致的方式進行安裝配置。但同時為了云系統的高可用，你在設計時就需要考慮以下幾個要點。

本書中的例子中云控制節點上會運維多個服務。有些直接通過消息隊列通訊的服務(如：nova-scheduler，nova-console)可以較簡單的安裝到其他硬件環境中。但其他服務則更麻煩一些。

對于用戶訪問的服務，如：儀表盤，nova-api，對象存儲，則建議采用通過負載均衡方式分攤訪問請求。任何標準的HTTP負載均衡方式都可以使用(DNS輪詢，負載均衡硬件或軟件(如Pound或HAProxy))。儀表盤需要注意的是VNC proxy。VNC proxy使用的是WebSocket協議，而對于第7層應用的負載均衡處理這種協議則有問題。請參見橫向回話存儲(Horizon session storage)(http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage)

有些服務(如：nova-api，glance-api)通過修改配置文件中的標示可以支持多進程。多進程可以更好的在多核CPU的硬件上分配計算任務。

有部分的配置可用于MySQL負載均衡，RabbitMQ也支持內建的集群機制。請參考運維章節獲得更多關于配置各種服務的信息。

云系統隔離

使用OpenStack中的方法進行云系統的隔離，方法有：cells, regions, zones和host aggregates。每種方法提供了不同的功能，具體功能能描述如下：

以上隔離方案可以分成2大類：

cells & regions：用于將nova部署服務進行隔離。 availability zones & host aggregates：用于將部署地點進行隔離。

Cells & Regions

OpenStack的cell是一種分布式運行方式，該方式下不需要引入過于復雜的技術且也不會影響已存在nova環境。支持運行云系統的服務器通過分組，每組就是一個Cell，Cell是一種按照樹狀方式組織資源的方式。Cell樹根節點cell(API cell)服務運行nova-api服務，該服務器上不運行nova-compute服務。在根節點之下的服務器運行除nova-api外所有nova-*服務。每個Cell運行自己的消息隊列，數據庫和nova-cells服務。nova-cells服務管理根節點cell和子節點cell之間的通訊。

以上的Cell方式可以運行單個的API服務用于控制多個云環境。在nova-scheduler直接調度選擇服務器資源外，也引入了二次調度的形式(調度選擇cell資源)。cell的這種間接調度方式給控制虛擬機帶來了更靈活的控制方式。

和Cell不同的是Region是一種隔離度比cell更高的方式，該方式下不同的region中需要獨立有相應的API endpoint。用戶需要在不同的Region中運行虛擬機實例需要明確的指定Region。Region下沒有其他額外的服務需要運行。

當前OpenStack儀表盤服務只支持單個Region，所以每個Region需要運行一個儀表盤服務。Region用于提供了在共享同一基礎架構上建立健壯服務一種方式，該方式可用于在較高層次建立容錯機制。

Availability Zones & Host Aggregates

Host Aggregates和Availability Zones是用于將nova部署進行分隔。Host Aggregates和Availability Zones雖然配置類似但是用途不同。Host Aggregates是用于邏輯上分組適用于負載均衡和分布虛擬機實例；Availability Zones是用于同其他Zone分隔的物理冗余和隔離分組(如：分隔電源或網絡物理不同的服務器設備)。Host Aggregates可以視作對于Availability Zones中進一步分組的方式，如：可將服務器分成多個組，每組共享相似的資源如存儲、網絡；或區分特別的資源(可信賴計算硬件)。

Host Aggregates常用于將服務器分組提供nova-scheduler調度資源，如：將某種類型的虛擬機類型或鏡像限制在給定子網中的某些服務器。

Availability zones可以將OpenStack中的計算服務或對象存儲服務所用的服務器進行邏輯分組。通常是將一些具有相同屬性的服務器分配到同一個zone中。如：數據中心中有部分機架的電源同其他機架的電源來自不同的供電線路，那么這些在獨立供電機架上的服務器需要分配在同一個Availability zone中。

Availability zones也可以用于區分不同檔次的硬件。特別是對于OpenStack對象存儲服務比較有用，用于運行對象存儲的服務器可能配置了不同的磁盤。當用戶選擇應用所需的配置時，就可以通過指定不同的zone上的虛擬主機實例或磁盤卷。用戶通過自主選擇就可以確定他們的應用運行是分布在不同的底層硬件服務器上，這樣就可以在硬件故障時，實現應用的高可用性。

硬件擴展

在準備了部署和安裝OpenStack相關的資源同時，另一項非常重要的任務是提前準備好擴展的硬件部署準備。本書建議是至少在現有運行的OpenStack云環境之外有空閑機架供使用，同時還需要準備何時，如何擴展硬件的方案。

硬件采購

“云系統”常備描述成靈活多變的環境，在云上運行的服務環境經常隨意的開啟和關閉。這種對云系統的描述無誤，但不代表支持運行云系統的底層服務器是經常變動的。只有底層硬件的穩定和正確的配置才能確保其上云系統的正常穩定的運行。通常需要將主要的工作集中在建立一個穩定的基礎硬件環境才能提供用戶一個靈活多變的云系統環境。

OpenStack可部署于任何支持的Linux發行版所兼容的硬件環境上，如：本書所使用到的Ubuntu 21.04

服務器硬件環境不必完全一致，但是至少需要相同的CPU類型，以便于能支持實例在不同硬件環境上的遷移。

OpenStack建議的典型硬件就是商品硬件(commodity)。商品硬件就是指市場上大部分硬件供應商所提供的標準硬件配置。如果能直接采購，則可以直接按照需要建立類型的系統(如：計算，對象存儲，云控制器)進行采購即可。另一種情況是預算不多，在現存的服務器上進行升級以滿足性能和虛擬化要求，這樣也可以支持部署OpenStack。

規劃容量

OpenStack在于增加系統容量方面相對簡單容易。請參考擴展性章節，其中特別需要注意的是對于云控制器容量考慮。建議在可能情況下考慮對于計算和對象存儲節點留有額外的容量。增加的新節點不必要同現存節點保持相同配置，相同供應商。

在計算節點上，nova-scheduler將根據核數，內存信息進行系統資源的調配和管理。同時需要注意的是當使用不同CPU時，由于CPU計算速度的差異會導致用戶體驗的不一致。當添加對象存儲節點時，不同節點需要給出權重用以反映出節點的性能。

監控資源的使用和用戶的增長可以幫助你了解到何時需要考慮采購新資源。在監控章節中會提供詳細有用的監控指標。

高負荷測試

服務器硬件在剛開始使用和快到使用壽命時最容易產生故障。所以為了避免在生產環境中忙于應付硬件故障，可以在初期適當采用高負荷測試方式來測試硬件故障。通常高負荷測試可以連續運行幾天的CPU或磁盤性能基準測試軟件，用以將硬件負荷增加至極限。