OpenStack Swift是個開源的雲端儲存空間平台，它能夠被用來建立擴展性大以及高度穩固的雲端儲存空間。有兩個主要使用 Swift 的情形：
- 服務供應商提供有著明確定義 RESTful HTTP API 的雲端儲存空間 - 例如公有雲。服務供應商利用 API 結和許多應用程式提供給他們的用戶。服務供應商也可以只提供一個特定的服務(例如雲端備份)而不直接提供API。
- 一個大型公司為內部應用程式建立一個雲端儲存空間平台 - 例如私有雲。通常會這麼做的組織是因為不喜歡將自己的資料傳送給第三方的公有雲供應商，或是想要建立靠近應用程式使用者的雲端儲存空間平台。
若您計劃建立上述兩種雲端儲存空間架構，都將會面臨到以下三個問題之一：
- 成本最佳化：您知道將需要使用多少空間容量，也知道需要多少總輸送量讓應用程式使用雲端儲存空間。但您想要知道至少需要多少預算才能達到您預計的容量及輸送量目標。
- 容量最佳化：您知道將需要多少總輸送量讓應用程式使用雲端儲存空間，也知道預算。但您想要知道在符合輸送量需求及預算範圍內的最大容量。
- 效能最佳化：您知道將需要使用多少空間容量，也知道預算。但您想要知道如何設定以得到符合容量需求及預算範圍內最佳的輸送量。
由於雲端儲存空間建立者有數種選擇需要決定，因此解決以上任何問題是很複雜的。例如大小及多種形態的伺服器、網路連線、SLA等。
我們實驗室與數個雲端供應商做了廣泛的研究，並瞭解以上問題及進行嚴謹的分析。在此部落格系列中，我們將會提供我們的發現結果、工具描述和服務，這將會幫助您有信心建立、部署和維護您的雲端儲存空間。
定義
由於文中所使用的術語視情況有不同的解釋，下面為此部落格系列中所使用的3個主要參數的特別定義：
容量(Capacity)：這指的是可使用的儲存空間容量。例如：最多可儲存在雲端的應用程式資料。一般來說，為了更好的可用性及持久性，資料會被重復在多個雲端儲存空間系統尚。所以，雲端儲存空間的原始容量應該要將資料的重複性列入考量。例如，OpenStack Swift，預設上每個 object 會重復三次。因此，總共的原始容量至少要為可用的儲存容量 3 倍以上。
效能(Performance)：最大的總輸送量(MB/s 或 GB/s)要決定於雲端空間的應用程式。在此部落格中，我們也將會使用術語 throughput 來代表總輸送量。
成本(Cost)：這次探討中，我們將只會考量到初始的硬體購買成本以建立雲端儲存空間。我們期望所建立的雲端儲存空間能夠延續使用好幾年，但我們並不會持續攤銷花費。我們將會指出最佳的實踐來減少持續支出維護和縮放成本。
此系列部落格中，我們將交替使用術語 "node" 和 "server"。所以，"storage node" 等同於 "storage server"。
Swift Advisor 摘要介紹
Swift Advisor 是一個技術，其使用 3 個限制條件 (Capacity、Performance、Cost)之中的 2 個為輸入值，然後由輸出提供硬體推薦。特別是為 Swift Cloud 中每種類型的 node(storage和proxy) 做系統計數和設定。此推薦是根據 3 種限制條件來做最佳化: 如最小化您的預算、最大化您的輸送量或最大化您可以使用儲存容量。
在討論到 Swift Advisor 的技術細節之前，我們先來看看實際使用 Swift Advisor的方法：
為了建立最佳化的 Swift 雲端儲存空間 (Swift Cloud)，使用公有運算雲端來測試出最佳化的私有雲端儲存空間看起來可能會很諷刺。我們之所以會選擇 EC2 作為 Swift Advisor 的測試環境有許多原因：
(1) EC2 提供許多種不同容量的 CPU、記憶體和 I/O 組合的 EC2 執行個體，以符合多樣的需求。所以，Swift Advisor 可以基於隨用隨付機制嘗試利用許多種 EC2 執行個體，而不是實際取得大量多樣的硬體。(2) EC2 有一個完整定義的價位系統。這也為雲端儲存空間建立者提供很好的比較點 - 他們可以透過瀏覽價位資訊並合理化長期擁有他們自己的雲端儲存空間費用。(3) 每種 EC2 執行個體規格，包含 CPU、記憶體、磁碟和網路，都定義完善。一旦以輸入限制條件建立最佳化的 Swift Cloud在 EC2 執行個體上，EC2 執行個體規格就可以有效地指引購買實體伺服器以建立一個執行在實體硬體上的 Swift Cloud。總結來說，您可以使用具有彈性的運算雲端以及 Swift Advisor 來得到您基於雲端儲存空間的實體硬體，並保留您偏好的限制條件。
Swift Advisor 的高階工作流程如下圖：
有 4 個重要階段，說明如下：
採樣階段(Sampling Phase)：
我們最終的目標是建立一個的最佳化的 Swift Cloud，其包含 quantity A 的 proxy 伺服器和 quantity B 的儲存空間伺服器 - 一開始 A 和 B 為未知數，並以A:B Swift Cloud 標記。在第一階段中，我們著重在1:N 的 Performance 和 Cost 特性。我們要尋找 N 的值，使得1:N Swift Cloud 雲端的單一 throughput 成本為最低( $ 每 MB/s)。我們想要尋找每 MB/s 最低成本的 1:N Swift Cloud的原因，是為了移除 2 個建立 Swift Cloud的潛在陷阱：(1)佈建不足：proxcy 伺服器未被充分利用，且仍能夠附加更多的儲存空間伺服器來增進輸送量。(2)超過佈建 - proxcy 伺服器不堪太多儲存空間伺服器的沈重負擔。
由於選擇 storage 和 proxy node 可能的組合非常多，在多種 Swift Advisor 的階段中我們使用許多啟發式的方法來找候選組合。例如，我們不考慮效率非常低的 proxy node 設定(例如：Micro Instance)。
採樣階段後，對於每個執行在 EC2 執行個體上的 proxy 數目和 storage server的組合，數值 N 可以獲得執行 1:N Swift Cloud 的最低 $ 每 MB/s。您可以在任何可用的虛擬或實體硬體上執行採樣階段，不過採樣數目越多越好。
分析階段(Profiling Phase)：
從採樣階段給予數值 N，我們的現階段目標，是分析許多 Swift Cloud的 throughput 曲線(throughput 與 Swift Cloud的大小)。而Swift Cloud 是由c 個proxy server 和 cN 個 storage server(c:cN Swift Cloud) 以及多種 c 值組合而成。請注意，每個 throughput 曲線對應到一種 proxy 和 storage server 的硬體設定組合(在這裡是指EC2 執行個體大小)。
在我們的實驗中，對於每個執行在 EC2 執行個體上的 proxy 數目和 storage server 的組合，分析是從 2:2N Swift Cloud 開始，且我們每次加倍 proxy 和 storage server 的數目(例如：4:4N, 8:8N, …)。 cN 個 storage node 中，每個 EC2 執行個體都完全相同。當c:cN Swift Cloud 的 throughput 比 throughput 的限制條件還大，就會停止分析階段。在那之後，我們會套用一個非線性或線性回歸線到一個以分析的throughput 上以操作一個有著X 值為c 和 Y 值為 throughput 的 throughput 曲線。
分析階段的輸出則是一群c:cN Swift Cloud 的 throughput 曲線，裡面每個曲線都對應到一種執行在 EC2 執行個體上的 proxy 數目和 storage server的組合。
最佳化階段(Optimizing Phase)：
利用分析階段獲得的 throughput 曲線以及兩個輸入限制條件，最佳化階段是我們找出最佳的 Swift Cloud 的第三個參數。為此，我們操作 throughput 曲線的限制條件和跨多個曲線之間尋找最佳值。例如，我們試著以最大 cost 來最佳化 capacity 並最小化 throughput 需求: 我們將輸入最小需要的 throughput 到每個 throughput 曲線，然後找到對應的 c 值，再去除超過硬體 cost 的 throughput 曲線區段。在剩下的曲線中，我們將會選擇一條基於 cN * 儲存空間容量的最大者。
驗證和修正階段(Validation & Refinement Phase)：
驗證階段透過工作負荷測試確認是否最佳的 Swift Cloud 真的符合throughput 限制條件。若是有一限制條件測試失敗，那麼 Swift Advisor 會進入修正階段。修正階段會從測試中得到平均的 throughtput，然後送到分析階段。分析階段新增此資訊到分析資料中以修正 throughput 曲線。之後，我們使用已修正的throuput 曲線作為輸入來重復執行最佳化階段。
以上四個階段為 Swift Advisor 的核心。然而，有一些其他重要問題需要討論：(1)負載平衡器(load balacer)的選擇 (2)當雲端操作員終於要搬移最佳的 Swift cloud 到實體伺服器時，EC2 執行個體和實體硬體的對應 (3) SLA 限制條件。我們將在未來部落格中發表這些和其它關於建立最佳的雲端儲存空間問題。
一些採樣觀察
此部落格中，我們會展示一些採樣階段所選用的系統設定結果。在未來的部落格，我們將會發佈分析階段和最佳化階段的結果。
對於我們的採樣階段，我們假設以下的伺服器可用作 proxy node: EC2 Large(Large)、EC2 Extra Large(XL)、EC2 Extra Large CPU-high(CPU XL)和EC2 Quadruple Extra Large(Quad)。而候選的 storage node 為：EC2 Micro(Micro)、EC2 Small(Small) 和 EC2 Medium(Medium)。因此，總共有 4*3=12個 proxy 和 storage node的組合。我們需要找到數值 N，其可以獲得執行 1:N Swift Cloud 的最低 $ 每 MB/s。
我們起始以 N=5為每個組合採樣，然後增加此數值直到 1:
我們使用 Amanda Enterprise 作為我們的應用程式來備份一個 10G 的資料檔案到 1:N Swift Cloud。Amanda Enterprise 執行在EC2 Quad 執行個體以確保 Amanda Enterprise 伺服器能夠在任何情況下完全載入 1:N Swift Cloud。在此分析之中，我們假設雲端建立者想要基於備份操作建立最佳化的雲端儲存空間。當建立一個生產用的雲端儲存空間，Swift Advisor 的使用者應該根據期望的多種應用程式變更其工作負載。
首先我們來分析不同的 N 值在每個 EC2 執行個體大小的 proxy 和 storage node 組合的所產生的 throughput。
(1)EC2 Large 執行個體上的 proxy node 與 3 種大小 storage node 的三條曲線：
基於 EC2 Large 執行個體上的 Proxy Node 觀察：
- 基於 Micro 執行個體上的 Storage node: Throughput 在當 # storage node=30 時停止增加
- 基於 Small 執行個體上的 Storage node: Throughput 在當 # storage node=10 時停止增加
- 基於 Medium 執行個體上的 Storage node: Throughput 在當 # storage node=5 時停止增加
(2)執行在 EC2 XL 執行個體上的 proxy node:
基於 EC2 XL 執行個體上的 Proxy Node 觀察：
- 基於 Micro 執行個體上的 Storage node: 當 # storage node=30 時，throughput 停止增加
- 基於 Small 執行個體上的 Storage node: 當 # storage node=10 時，throughput 停止增加
- 基於 Medium 執行個體上的 Storage node: 當 # storage node=5 時，throughput 停止增加
(3)執行在 EC2 CPU XL 執行個體上的 proxy node:
基於 EC2 CPU XL 執行個體上的 Proxy Node 觀察：
- 基於 Micro 執行個體上的 Storage node: 當 # storage node=30 時，throughput 停止增加
- 基於 Small 執行個體上的 Storage node: 當 # storage node=10 時，throughput 停止增加
- 基於 Medium 執行個體上的 Storage node: 當 # storage node=5 時，throughput 停止增加
(4)執行在 EC2 Quad 執行個體上的 proxy node:
基於 EC2 Quad 執行個體上的 Proxy Node 觀察：
- 基於 Micro 執行個體上的 Storage node: 當 # storage node=60 時，throughput 停止增加
- 基於 Small 執行個體上的 Storage node: 當 # storage node=20 時，throughput 停止增加
- 基於 Medium 執行個體上的 Storage node: 當 # storage node=10 時，throughput 停止增加
從上面圖表中，我們已經可以得出一些結論：例如，如果您只有與 EC2 Micro 執行個體相等的 storage node，且您希望 storage node的數量能夠超過 30 個(每個 proxy node)，您應該選擇至少與 EC2 Quad 執行個體相等的 proxy node。
我們以不同的視角分析圖表 (1)-(4)：修正 storage node 的 EC2 執行個體大小以及改變 proxy node 的 EC2 執行個體大小。
(5)EC2 Micro執行個體上的 storage node 與 4 種 EC2 執行個體大小上的 proxy node 的4 條曲線：
基於 EC2 Micro 執行個體上的 Storage Node 觀察：
- 基於 Large 執行個體上的 Proxy node: 當 # storage node=30 時，throughput 停止增加
- 基於 XL 執行個體上的 Proxy node: 當 # storage node=30 時，throughput 停止增加
- 基於 CPU XL 執行個體上的 Proxy node: 當 # storage node=30 時，throughput 停止增加
- 基於 Quad 執行個體上的 Proxy node: 當 # storage node=60 時，throughput 停止增加
從以上圖表中，我們總結以下結論 (a) 當在 Quad 執行個體上執行 proxy node 時，他的容量，尤其是網路頻寬能夠比其它執行個體容納更多的 storage node 和得到更高的 throughput (MB/s)。(b)不同 EC2 執行個體大小的以不同的速度載入相同的 proxy node：例如，當proxy node 執行在 Quad 執行個體上時，我們需要使用 60 個 Micro 執行個體的 storage node 才能完全載入 proxy node。然而，若我們使用 Small 或 Medium 執行個體的 storage node，我們只需要 10 個 storage node 完全載入此 proxy node。
基於以上 throughput 結果，我們現在來看不同的 N 值在各個 EC2 執行個體大小的 proxy 和 storage node 組合。這裡，$ 被定義為執行 1:N Swift Cloud 30 天的 EC2 使用成本。在此部落格中，我們只展示關於 EC2 Quad 執行個體的 proxy node 的數字資料。我們將會在其他詳細報告中發表其他組合的數字資料。
(6)執行在 EC2 CPU Quad 執行個體上的 proxy node:
基於 EC2 Quad 執行個體上的 Storage Node 觀察：
- 基於 Micro 執行個體上的 Storage node: 當 # storage node=60 時，達到最低 $ 每MB/s
- 基於 Small 執行個體上的 storage node: 當 # storage node=15 時，達到最低 $ 每MB/s
- 基於 Medium 執行個體上的 Storage node: 當 # storage node=5 時，達到最低 $ 每MB/s
綜合以上結果，使用 5 個基於 Medium 執行個體上的 Storage nod 可達到最低 $ 每MB/s。
這些特定結果將會分別為組合 EC2 Quad/Medium、EC2 Quad/Small 和 EC2 Quad/Micro (proxy/storage node) 分別提供輸入參數 N=5、15 和 60 到分析階段。
所以可以下結論當使用 1 個基於 Quad 執行個體上的 Proxy node，最好是使用 5 個基於 Medium 執行個體上的 Storage node以達到最低 $ 每MB/s，而非使用基於 Micro 執行個體上的 Storage node。
以上的圖表，只是在採樣階段內整理效能表現的子集合。這裡是提供您我們推薦建立最佳 Swift 雲的整體客觀概述。如同上面所述，我們將會在其他報告中發佈詳細結果，未來的部落格系列將會有更多結論以及最佳實踐。
如果您考慮拼裝一個雲端儲存空間，我們很樂意與您討論挑戰以及分享我們的觀點。請寄信至 swift@zmanda.com。
