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