Openstack 云平臺提供塊存儲服務：OpenStack Cinder
Openstack 從 Folsom 開始使用 Cinder 替換原來的Nova-Volume服務，為 Openstack 云平臺提供塊存儲服務。
Cinder架構
/- ( LDAP ) [ Auth Manager ] --- | \- ( DB ) | | cinderclient | / \ | [ Web Dashboard ]- -[ api ] -- < AMQP > -- [ scheduler ] -- [ volume ] -- ( iSCSI ) \ / | novaclient | | | | < REST >
Cinder服務
-
API service：負責接受和處理Rest請求，并將請求放入RabbitMQ隊列。Cinder提供Volume API V2, 我沒有找到格式很好的在線文檔，大體可以參見Openstack block storage API V1
-
Scheduler service: 處理任務隊列的任務，并根據預定策略選擇合適的Volume Service節點來執行任務。目前版本的cinder僅僅提供了一個Simple Scheduler, 該調度器選擇卷數量最少的一個活躍節點來創建卷。
-
Volume service: 該服務運行在存儲節點上，管理存儲空間。每個存儲節點都有一個Volume Service，若干個這樣的存儲節點聯合起來可以構成一個存儲資源池。為了支持不同類型和型號的存儲，當前版本的Cinder為Volume Service如下drivers。當然在Cinder的blueprints當中還有一些其它的drivers，以后的版本可能會添加進來。
-
本地存儲：LVM, Sheepdog
-
網絡存儲： NFS, RBD (RADOS)
-
IBM: XIV, Storwize V7000， SVC storage systems
-
Netapp: NFS存儲；ISCSI存儲則需要OnCommand 5.0和Data ONTAP 7-mode storage systems with installed iSCSI licenses
-
EMC: VNX, VMAX/VMAXe
-
Solidfire: Solidfire cluster
Cinder服務的部署
上述的Cinder服務都可以獨立部署，cinder同時也提供了一些典型的部署命令:
-
cinder-all: 用于部署all-in-one節點，即API, Scheduler, Volume服務部署在該節點上。
-
cinder-scheduler: 用于將scheduler服務部署在該節點上。
-
cinder-api: 用于將api服務部署在該節點上。
-
cinder-volume: 用于將volume服務部署在該節點上。
Cinder如何支持典型存儲
從目前的實現來看，Cinder對本地存儲和NAS的支持比較不錯，可以提供完整的Cinder API V2支持，而對于其它類型的存儲設備，Cinder的支持會或多或少的受到限制，下面是Rackspace對于Private Cloud存儲給出的典型配置:
1. 本地存儲
對于本地存儲，cinder-volume可以使用lvm驅動，該驅動當前的實現需要在主機上事先用lvm命令創建一個cinder- volumes的vg, 當該主機接受到創建卷請求的時候，cinder-volume在該vg上創建一個LV, 并且用openiscsi將這個卷當作一個iscsi tgt給export.
當然還可以將若干主機的本地存儲用sheepdog虛擬成一個共享存儲，然后使用sheepdog驅動。
2. EMC
3. Netapp
Cinder在IT環境中的主要問題
目前版本的Cinder在IT私有云場景中，從硬件兼容性，高性能，高可靠性，水平擴展能力，應用兼容性等維度來看，Cinder還存在不少問題需要解決。Cinder依然任重道遠。
1. 對共享存儲的支持有限
-
不支持FC SAN；
-
支持的存儲設備有限，即使對于EMC, IBM這樣的的主流存儲廠商，也只能支持寥寥幾款存儲；
2. 對存儲設備的使用不夠高效
-
Cinder卷管理的基本原則是在共享存儲上創建一個lun, 然后把這個lun作為一個block device給attach到一個虛擬機上。但是對于當前主流的存儲，能夠支持的最大lun數量非常有限，比如我們經常使用的Huawei S3900, 最多能支持288個lun，如果一個VM平均3個卷，不管這些VM是offline還是online, 這個存儲最多只能支持90個VM。
3. 存儲管理帶來的性能損耗
-
比如Cinder Volume的LVM驅動使用iSCSI export一個邏輯卷，從管理的角度來看是解決了存儲共享的問題，從而能夠支持比如遷移這樣的功能，但是這樣的設計勢必會導致較大的性能損耗，和直接訪 問相比，通常iSCSI export會增加30%以上的IO延遲。
4. 數據如何遷移
-
企業IT環境中大量的數據，一般都是存放在SAN甚至是磁帶設備上的，這些數據如何無損，安全的接入到Cloud呢？VMware因此提供了RDM, KVM和XEN也支持PVSCSI, 但是Cinder沒有考慮這個。
5. Cinder的調度器不完善
-
Cinder提供的simple scheduler基本沒有實用價值,
-
cinder-scheduler僅能在初始放置時保證系統負載均衡，但是如果是發生了運行時負載嚴重不平衡，cinder就沒法處理了。
6. Cinder服務的可靠性問題
-
cinder-api和cinder-scheduler是系統的單點，cinder并沒有提供這兩個服務提供任何HA和load balance設計，所以整個系統可靠性還是擴展性會比較受限制。
-
cinder-db如果發生不可恢復的故障，能夠保證用戶數據能恢復嗎？