構建內部的云存儲必須考慮到彈性、選擇正確的平臺、支持工作流，以及批量部署和跟公有云的集成。

隨著時間的推移，存儲即服務的交付進展驚人。如今，公有云，如Amazon Web Services和Microsoft Azure，都提供了內部以及外部連接的按需分配的對象存儲，以及塊和文件存儲，用于內部分配給計算實例。這種運維的靈活性在數據中心里很引人注意，比起傳統的存儲部署方式，它提供了更大的便捷性和敏捷性。

如何構建自己的私有存儲云呢?我們首先退后一步，思考一下云計算到底意味著什么。云標準定義包括如下特性：彈性，所消耗資源能夠自如擴展和收縮;作為服務交付，以抽象的形式(而不是在物理硬件上)定義的服務方案的標準集合;多租戶，支持多個客戶;請求資源的按需訪問，很少或者無需任何手動干預;以及報告和計費，基于使用量收費，并提供詳細的報告。

私有存儲云必須具備這些特性。業務用戶，這里也就是客戶，必須具備請求存儲能力，而不用關心這樣的能力到底是如何交付的。因此服務目錄，這項技術已經使用很多年了，之前關注于物理技術(比如HDD速度或者HDD/閃存)，需要更新，從而更加關注于服務矩陣。這意味著使用這些術語：I/O密度(每兆字節存儲的IOPS)、延遲、吞吐量、數據可用性和彈性。

多租戶指的是安全和性能的隔離。安全確保數據在私有存儲云的用戶之間不可見，而性能特性，如服務質量(QoS)確保無論系統整體負載如何，每個用戶都能享受始終如一的服務級別。安全訪問保證客戶對資源的請求盡量不需要IT——特別是存儲管理員，的干預。報告特性需要提供存儲使用率的更細粒度的度量，包括能夠生成某個團隊或者業務領域的報告。

創建彈性

私有存儲云需要做的事情列表里的第一條就是彈性，這里有兩個場景：首先，客戶能夠按需擴展以及收縮使用量，其次，系統管理員能夠按需部署更多的基礎架構。但是如果終端用戶能夠輕易地歸還存儲的話，部署的一些硬件可能就不會被使用到，不過這種情況很少發生。

這里的挑戰是通過在數據中心里部署新硬件來持續滿足需求，并且同時在不影響應用程序可用性的情況下管理技術的更新周期。對于大多數IT部門來說，達到新硬件正好及時的部署，這不僅是門藝術也是門科學——Amaon和Microsoft可能不一樣——大部分公司現金流和人力都有限。他們必須妥協，因為無法提供無限的資源，只能預測什么時候需要添加新硬件。

這也正是體現藝術的地方。預測的需求要求業務線的參與，來計劃可能的未來項目及其存儲需求。如果IT能夠洞察未來可能的存儲資源需求，那么這些需求就能夠很容易地計劃出來——特別是如果是非核心產品的話，如對象或者高性能存儲。

科學性在于查清存儲增長的足夠信息。很多IT環境使用瘦預配，這意味著物理存儲能力會隨時間而增長，因為數據被寫入到分配的空間里。并且因為計劃消耗的存儲的預留空間很少會被快速地全部使用掉(如，1TB的請求可能在第一天僅僅使用了50GB，之后可供三年使用)，文件系統和對象存儲的使用率就會隨著應用寫入更多數據而自然增長。這也使得必須有精確并且詳盡的工具來度量隨時間的存儲消耗，最好是每天，同時能夠使用這樣的數據生成有意義的增長預測。

另外，決定什么時候部署新硬件要求理解并且管理供應商、硬件部署和配置事件。在企業里，IT仍然需要負責這些事情，當然如果你購買了公有云存儲的話，這些都在云服務供應商(CSP)的服務范圍內。

選擇平臺

有正確的存儲平臺是高效部署新硬件的關鍵。橫向擴展作為縱向擴展技術的一個選擇，可以讓新的部署相對簡單，因為你只需要簡單地往已有配置上添加硬件來增加能力即可。

大多數現代的對象和塊擴展產品都能夠執行一定級別的重新平衡、重新分發數據，從而使用新增加的資源并且從硬件上獲得最佳的性能。單體增強的架構很難管理，因為可擴展性的限制，而舊的遺留存儲系統可能本身并沒有負載均衡，從而無法使用新硬件。這意味著必須要更加小心地對遺留架構進行負載均衡規劃，將邏輯資源分發到物理硬件之上。很多這些平臺都提供了工具，可以在存儲平臺內移動LUN，減輕一些負載均衡問題。

為私有存儲云選擇存儲平臺時，多租戶和QoS也是要考慮的核心特性。調研CSP提供的服務矩陣，可以看到性能用IOPS和吞吐量衡量，也有一些提到了I/O延遲。無論CSP是不是滿負載，這些都是必須提供給客戶的服務級別，這對于傳統的遺留存儲就無法保障了。因此QoS就變得特別重要，要么提供工具確保終端用戶得到所需的性能，要么限制僅僅在新系統上才提供所購買的服務級別。

必需的API

最近幾年里，存儲應用領域發生了一些管理上的改革。以前通過GUI和命令行接口(CLI)的交互來管理存儲，使用“提交”階段來實施變更。CLI讓存儲管理員能夠進行腳本化預配以及關閉流程，允許一定程度的自動化。但是，創建腳本是一項費時的工作。這些年里，供應商改為使用API實現存儲的可編程化——通過授權API調用設置配置。配置數據現在也能夠輕松地提取出來，一些存儲平臺可以生成很詳細的度量。

API

應用程序編程接口已經改變了企業存儲的管理方式。將來，API將會驅動自動化，并且移除大多數存儲預配的手動干預，從而讓私有云存儲更為實用，推廣到更多企業中。

API還能夠帶來自動化，讓“人”不需要參與預配存儲流程。現在，可以通過一次或兩次API調用就可以將存儲映射到主機上。一些平臺原生實現了API，而另一些圍繞已有的API工具構建了API封裝器。這里的重要需求是確保API，CLI和GUI的操作更加和諧，而不用切換來切換去。

工作流問題

難題的最后一部分是，交付私有云存儲就是執行一些工作流流程。用戶請求必須被驗證然后執行。公有云通過用戶提供信用卡或者其他支付方式來實現驗證流程。這之后，可以通過web門戶或者API配置服務。在企業里，請求存儲的傳統流程需要有內部的流程，通過手工管理請求，基于服務ticket將存儲預配到主機上。ticket的負責人負責確保是否允許業務線“購買”存儲，并且隨后負責所有實現。

即用即付

可以使用信用卡購買公有云資源，滯后付款。工作流的改動意味著很多企業需要在部署內部云存儲時實現支付和退款。

在私有云里，目標是讓流程盡可能地自動化。EMC的ViPR是這樣的工具，讓用戶圍繞存儲自動化來構建工作流流程。Hitachi Data Systems提供了Hitachi Automation Director圍繞存儲以及其他資源的預配構建工作流。

很多企業將需要考慮私有存儲云所需的支付上的變化。如果沒有實現支付和退款，那么什么也干不了，因為IT部門還需要繼續負責服務交付的費用——很可能繼續根據項目來收費。但是，如果必須購買新資源，那么財務實踐上就需要一些變更——可能包括IT直接支付硬件、可能需要允許基于服務的賬單，讓業務單元負責這里的開銷。

Stack部署

跳出存儲團隊的視角，看向更為廣泛的領域，你可以在私有云框架，比如Openstack上構建存儲自動化，來節約預配的工作量。最初的Openstack部署沒有持久化存儲的能力，因此建立了一些項目來管理和外部存儲隊列的集成。最終Cinder項目處理塊存儲并且自動將LUN映射到OpenStack實例上，而Manila提供了和文件系統數據的集成，Swift提供對象存儲的API。

更廣泛的Stack

云存儲，可以是內部的或者公開的，是更廣泛的基礎架構stack的一部分。這意味著和OpenStack或者vCloud Director這樣的平臺集成。

同時，存儲供應商能夠編寫插件，讓OpenStack框架能夠按需預配并且映射存儲LUN。很多硬件和軟件公司已經支持了所有OpenStack的存儲API。Cinder支持OpenStack平臺的每個版本所支持的供應商特性。

公有云集成

向前看，這個世界并不是只有公開和私有，還有兩者的混合。因此，存在在公有和私有基礎架構之間移動數據和應用程序的需求，后者提供額外的數據保護(備份)并且提升可用性。你還可以為使用公有云存儲負責突發的工作負載和歸檔。

在本地以及公有云地址之間移動應用和數據的產品已經出現在市場上了。對象存儲供應商，比如Cloudian(HyperStore)以及Hitachi Data Systems (Hitachi Content Platform)提供了將本地數據歸檔到云上的能力，并且能夠搜索所有內容，就像存儲在同一個地方一樣。

數據保護方面，Druva和Zerto都提供了產品，讓用戶可以在公有云上備份以及恢復本地的虛擬機(VM)。作為備份和遷移流程的一部分，軟件負責處理VM鏡像的轉換，以及額外驅動的注入。

虛擬化

在運行服務器虛擬化的平臺上，存儲通常會映射到物理主機上。大部分創建虛擬機實例存儲的工作都由hypervisor管理軟件來處理。VMware通過vRealize Automation 和 vCloud Director提供自動化，而Microsoft提供了System Center 2016。

Velostrata更進一步，允許在公有云上啟動VM來處理云爆發。這可以用來在高資源配置的VM上運行應用，隨后在本地可用，或者將工作負載移動到公有云上來應對突增的需求。一旦峰值過去，VM就可以歸還回去。

同時，虛擬化供應商也開始和云供應商合作，完成應用到公有云的遷移。比如，VMware最近發布了Amazon Web Services上的VMware Cloud，以及和IBM的合作伙伴關系。它還提出了跨云架構，作為管理多云部署的方式。Microsoft Azure Stack(撰寫此文時出了技術預覽版)在Azure云上提供了相同的功能，可以運行在私有數據中心上，鏈接到公有Azure上。

很明顯，如今本地和公有云的實現是不同的，主要差異在自動化程度，是否完全利用私有云存儲。工作流，是其中最為重要的部分，——可能——仍然尚未成熟，需要今后私有云上的更多工作。

這里難題的一部分是改變內部業務團隊的行為。這是公有云幫忙推進的領域，并且也應該采納為內部資源的交付模型。