Openstack之Cinder服务初探

Openstack从Folsom开始使用Cinder替换原来的Nova-Volume服务，提供块存储服务。

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-all: 用于部署all-in-one节点，即API, Scheduler, Volume服务部署在该节点上。
• cinder-scheduler: 用于将scheduler服务部署在该节点上。
• cinder-api: 用于将api服务部署在该节点上。
• cinder-volume: 用于将volume服务部署在该节点上。
  

Cinder如何支持典型存储

1. 本地存储

对于本地存储，cinder-volume可以使用lvm驱动，该驱动当前的实现需要在主机上事先用lvm命令创建一个cinder-volumes的vg, 当该主机接受到创建卷请求的时候，cinder-volume在该vg上创建一个LV, 并且用openiscsi将这个卷当作一个iscsi tgt给export.

当然还可以将若干主机的本地存储用sheepdog虚拟成一个共享存储，然后使用sheepdog驱动。

2. EMC

3. Netapp

Cinder依然任重道远

首先从Enterprise Cloud的需求来看：

1. 在企业IT环境中，为了保证数据的高可靠性，共享存储是主流的存储形态，但是当前版本的Cinder对共享存储的支持比较差：

• 不支持FC SAN；
• 支持的存储设备有限，即使对于EMC, IBM这样的的主流存储厂商，也只能支持寥寥几款存储；
• 对存储设备的使用比较低效：Cinder卷管理的基本原则是在共享存储上创建一个lun, 然后把这个lun作为一个block device给attach到一个虚拟机上。但是对于当前主流的存储，能够支持的最大lun数量非常有限，比如我们经常使用的Huawei S3900, 最多能支持288个lun，如果一个VM平均3个卷，不管这些VM是offline还是online, 这个存储最多只能支持90个VM。
  

2. 对于本地存储的管理导致了较大的性能损耗

• Cinder Volume的LVM驱动使用iSCSI export一个逻辑卷，从管理的角度来看是解决了存储共享的问题，从而能够支持比如迁移这样的功能，但是这样的设计势必会导致较大的性能损耗，和直接访问相比，通常iSCSI export会增加30%以上的IO延迟。
  

3. 数据如何迁移

• 企业IT环境中大量的数据，一般都是存放在SAN甚至是磁带设备上的，这些数据如何无损，安全的接入到Cloud呢？VMware因此提供了RDM, KVM和XEN也支持PVSCSI, 但是Cinder没有考虑这个。
  

4. Cinder的调度器不完善

• Cinder提供的simple scheduler基本没有实用价值
• cinder-scheduler仅能在初始放置时保证系统负载均衡，但是如果是发生了运行时负载严重不平衡，cinder就没法处理了。
  

然后从Cinder的架构来看:

• cinder-api和cinder-scheduler是系统的单点，cinder并没有提供这两个服务提供任何HA和load balance设计，所以整个系统可靠性还是扩展性会比较受限制。
• cinder-db如果发生不可恢复的故障，能够保证用户数据能恢复吗？
  

References:

• 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