雲存儲(Swift+Keystone)部署策略

Swift是OpenStack的對象存儲模塊，Keystone是OpenStack的權限驗證模塊。能夠於這兩個模塊搭建一個較爲完善的雲存儲系統。

一、官方方案

雲存儲的服務器分三種類型：

• 驗證節點 Auth node – 運行 Auth service (keystone )
• 代理節點 Proxy node – 運行 Proxy services
• 存儲節點 Storage node – 運行 Account, Container, and Object services

此方案是官方文檔上的方案，部署圖以下：

 此方案中，有1個Proxy node ，運行 swift-proxy-server。 proxy server用於代理請求，把請求路由到合適的 Storage nodes。有5個 Storage nodes ，運行 swift-account-server, swift-container-server, and swift-object-server ，這幾個服務管理着 account databases, container databases, 存儲objects.

二、新浪部署方案

上圖是新浪在測試環境中部署的Swift集羣，集羣中又分爲5個Zone，每一個Zone是一臺存儲服務器，每臺服務器上由12塊2TB的SATA磁盤組成。Swift採用徹底對稱的系統架構，在這個部署案例中獲得了很好的體現。圖中每一個服務器的角色是徹底對等的，系統配置徹底同樣，均安裝了全部Swift服務軟件包，如Proxy Server、Container Server和Account Server等。

上面的負載均衡（Load Balancer）並不屬於Swift的軟件包，出於安全和性能的考慮，通常會在業務以前擋一層負載均衡設備。固然能夠去掉這層代理，讓Proxy Server直接接收用戶的請求。

圖中分別表示了上傳文件PUT和下載文件GET請求的數據流，兩個請求操做的是同一個對象。上傳文件時，PUT請求經過負載均衡隨機挑選一臺Proxy Server，將請求轉發到後者，後者經過查詢本地的Ring文件，選擇3個不一樣Zone中的後端來存儲這個文件，而後同時將該文件向這三個存儲節點發送文件。下載文件時，GET請求也經過負載均衡隨機挑選一臺Proxy Server，後者上的Ring文件能查詢到這個文件存儲在哪三個節點中，而後同時去向後端查詢，至少有2個存儲節點「表示」能夠提供該文件，而後Proxy Server從中選擇一個節點下載文件。

 

三、實驗室測試環境方案

將驗證服務和代理服務部署到了同一臺機器上（即，驗證、代理兩個結點合二爲一），部署了兩個存儲節點，數據的Replica的值爲2。

 

四、本身筆記本上部署方案

將驗證、代理、存儲服務都部署到同一個虛擬機中。數據的冗餘副本數量爲1。