Openstack之Cinder服务初探

http://blog.csdn.net/luo_brian/article/details/8592692 --原博主

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如果发生不可恢复的故障，能够保证用户数据能恢复吗？

参考

Cinder Developer Guide
Openstack block storage API V1
Configure openstack block storage
Implementing OpenStack Cinder with EMC Storage on the
Rackspace Private Cloud Software
Implementing OpenStack Cinder with NetApp Storage on
the Rackspace Private Cloud Software
OpenStack Folsom Architecture