OpenStack的存儲模塊有cinder和swift，分別負責提供塊存儲和對象存儲服務。swift雖然出道比較早，算是OpenStack的元老項目之一，但是目前的關注度並不高。倒是cinder由於採取了driver plugin的方式，得到了各大存儲廠商的支持，同時發展的也很快。而對象存儲這一塊，目前ceph和swift形成了競爭關係。cinder得到的關注比較多，是因爲目前企業裏面大部分的存儲還是基於塊設備的。
目前Cinder支持的存儲驅動非常多，詳細的support matrix可以參考官方鏈接https://wiki.openstack.org/wiki/CinderSupportMatrix。從商用的角度來說，下面幾種支持的存儲類型是非常有意義的：
1. 傳統商業存儲：比如EMC, IBM, HDS, Huawei, HP，NetApp等的中、高端存儲。支持FC和iSCSI協議
2. 分佈式存儲：比如Ceph
3. 分佈式文件系統：比如GPFS, ClusterFS
4. NFS：可以支持各種NAS
除了支持現有的主流存儲類型，cinder還支持多個存儲統一管理，也就是說可以用cinder統一管理各個廠家的存儲，只要它在支持列表裏就行。這就爲客戶提供了很多的選擇餘地。Cinder的API比較簡單，涉及的操作很少，所以對於各個存儲廠商實現起來也比較容易，基本都能比較全面的實現。不像Nova, Neutron，很多虛擬化廠家提供的驅動無法完全匹配所有的API。下面是一個cinder使用EMC VMAX驅動的示例，圖中顯示僅僅支持iSCSI，實際上目前已經可以支持FC了，但是需要計算節點上配置HBA卡。
對於很多傳統客戶來說，共享存儲是一個很重要的功能，許多重要的應用或者數據庫都依賴於共享存儲來保證數據的一致性。這一塊目前Cinder也已經提供了可選項，允許在創建卷(volume)的時候指定是否允許共享給多個虛機。只要在創建volume的時候加上 “--allow-multiattach”參數，就可以讓這個卷具備共享的屬性。創建完成後，執行cinder list可以查看Multiattach屬性，如果是"True"就表示該卷具備共享屬性。
# cinder help create
usage: cinder create [--consisgroup-id <consistencygroup-id>]
[--snapshot-id <snapshot-id>]
[--source-volid <source-volid>]
[--source-replica <source-replica>]
[--image-id <image-id>] [--image <image>] [--name <name>]
[--description <description>]
[--volume-type <volume-type>]
[--availability-zone <availability-zone>]
[--metadata [<key=value> [<key=value> ...]]]
[--hint <key=value>] [--allow-multiattach]
[<size>]
# cinder list
+--------------------------------------+-----------+------------------+---------+------+-------------+----------+-------------+--------------------------------------+
| ID | Status | Migration Status | Name | Size | Volume Type | Bootable | Multiattach | Attached to |
+--------------------------------------+-----------+------------------+---------+------+-------------+----------+-------------+--------------------------------------+
| 91dfabb7-b45f-4833-a6e0-92e6e1cbc43b | available | - | volume1 | 1 | - | false | False | |
| ddd63583-4993-4f5a-8122-78729cb452be | in-use | - | volume2 | 1 | - | false | True | cec676b5-e75f-4440-b485-3723e280db9d |
共享卷創建完成後，下一步就是通過nova attach-volume命令去將共享卷分配給多個虛機了。但是目前liberty版本的nova仍然無法支持這個功能。要實現這個功能，nova這塊的改動比較大，目前看在Mitaka版本里應該能加進來。具體關於相關spcs的進度可以參考https://review.openstack.org/#/c/85847/
上述功能完成後，應該說對於傳統企業來說，就能覆蓋絕大部分的存儲應用場景了。因爲這些企業用的最多的就是SAN存儲和NAS，並且支持共享模式。
對於傳統企業來說，目前還需要面臨一個新選擇，就是是否採用分佈式存儲，也就是Server SAN。分佈式存儲主要有以下優勢：
1. 可擴展性好，能夠擴展到成百上千個節點
2. 在規模比較大的情況下（一般建議10個節點以上），總體擁有成本(TCO)會比較低
但是分佈式存儲也面臨一些挑戰，主要體現在：
1. 可靠性如何保證，也就是如何保證不丟數據，並且應用可以持續正常訪問存儲。傳統存儲是靠冗餘控制器和RAID陣列實現。分佈式存儲靠分佈式的多副本數據複製來實現。爲了提高性能，分佈式存儲一般將寫數據先緩存在節點的內存裏，就告知應用寫完成了，之後由後臺的異步程序將內存裏的髒數據刷到磁盤上。這就導致一旦機器異常掉電，緩存裏的數據就會部分丟失。除此之外，某個節點突然性能嚴重下降，如果分佈式存儲無法及時把該節點踢出集羣，也會導致整個集羣性能嚴重下降。
2. 性能問題：多副本的複製導致一個寫請求需要在多個節點（至少2個，取決於副本數）完成寫操作，這就會有一定的性能開銷，對於響應時間要求非常高的應用就需要謹慎使用。
3. 數據恢復時間：就是一塊硬盤被替換後，在不影響應用訪問的情況下，多長時間能恢復正常的副本數量。如果恢復時間過長，客戶一旦再有別的硬盤壞了，並且恰好兩塊硬盤都有同一份數據的副本，這個數據就會丟失。
4. 容災：就是如何實現兩個甚至三個數據中心的遠程容災。
5. 運維：分佈式存儲的管理相對傳統存儲要複雜的多，如何化繁爲簡，提高運維效率和質量，是分佈式存儲面臨的挑戰之一。
對於企業客戶來說，選擇分佈式存儲之前一定要多接觸真實的使用案例，瞭解各種產品的利弊。總的來說要根據自己的實際情況來選擇存儲，一般遵循如下原則：
1. 數據規模不大，並且今後增長也很少的雲平臺，可以考慮採用傳統的存儲來實現。
2. 數據規模大，並且今後數據會快速增長的雲平臺，建議採用分佈式和傳統相結合的方式。慢慢積累在分佈式存儲上的運維經驗，成熟的時候逐步將應用遷移到分佈式存儲。
3. 如果採用分佈式存儲，對於生產系統，還是建議採用分離部署的方式，即存儲節點上只提供存儲服務，不提供虛機等計算服務，這樣不至於出現資源的爭搶，有利於存儲集羣的穩定。對於開發測試系統，可以考慮採用融合方式部署，節省成本。此外，生產系統建議選擇口碑好的商用分佈式存儲，開發測試可以考慮開源產品（比如ceph），但需要自己有比較強的維護能力。