Cinder背景

Openstack從Folsom開始使用Cinder替換原來的Nova-Volume服務，為Openstack云平臺提供塊存儲服務。

Cinder架構

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，以后的版本可能會添加進來。

o 本地存儲：LVM, Sheepdog

o 網絡存儲： NFS, RBD (RADOS)

o IBM: XIV, Storwize V7000， SVC storage systems

o NetApp: NFS存儲;ISCSI存儲則需要OnCommand 5.0和Data ONTAP 7-mode storage systems with installed iSCSI licenses

o EMC: VNX, VMAX/VMAXe

o 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如果發生不可恢復的故障，能夠保證用戶數據能恢復嗎？