这里只介绍概念及架构方面，一些具体的操作实战会在后面博客中写。
Cinder介绍
Cinder提供持久化块存储，.一个独立的volume可以灵活的挂载和卸载到不同的VM实例（就好比我们的一块硬盘拔插了）。VM实例可以用cinder volume作为启动盘。Block Storage服务无法提供类似于NFS的共享存储。一个块设备同时只能挂在到一个VM实例。
服务组件
Cinder有如下服务组件：
cinder-api：WSGI应用，接受API请求并发送到cinder-volume处理。
cinder-scheduler：调度器，处理消息队列中的请求，并根据预定策略（Filter Scheduler）选择合适的cinder-volume节点来完成请求。
cinder-volume：cinder-volume服务运行在存储节点上，管理块存储设备。该服务会对cinder数据库进行读写操作，通过消息队列与其他服务交互（如cinder-scheduler）。cinder-volume支持多种后端存储。多个存储节点可以组成一个存储资源池。
cinder-backup：可以将volume备份到多种目标对象（如swift、ceph）。
Messaging queue：在块存储服务之间传递消息，块存储服务和计算节点交互来为VM提供volume。
Cinder其他概念
•Back-end Storage Devices.：后端存储设备，默认采用本地LVM VG。此外，Cinder还支持很多种存储。
•Users和Tenants (Projects)：我的理解是这里也是基于Keystone的权限控制。对于租户而言，cinder quota控制可以做如下限制：创建volume的数量、创建快照的数量、每个租户总空间（volume和快照分享）。用户有权使用哪些volume是通过租户来限制的。控制硬件资源quota是对每个租户启用的，而授予vomle访问权限的key pairs是对单个用户启用的。
Volume Type
Volume Type是一个条件的抽象集合，这个集合用来定义一个特定的服务水平（如惯称的金、银、铜），包含一个key/value pairs列表（可通过cinder extra-specs-list查看）。可以在创建volume时指定volume类型，volume创建后类型是可以修改的。cinder scheduler可以根据volume类型定义来指定存储后端，而且volume类型还可以用来指定存储后端的行为依赖的特殊信息。volume类型名可以任意指定。
当使用cinder-volume节点使用多种后端存储时，必须启用filter_scheduler。scheduler使用 filtering和weighing来选择最优的存储后端。首先，filter scheduler过滤可用的存储后端，默认情况下，AvailabilityZoneFilter，CapacityFilter和CapabilitiesFilter被启用。然后，filter scheduler会通过scheduler weigher权衡先前过滤的存储后端，默认情况下，CapacityWeigheris被启用，此种情况下会优先使用容量较多的存储后端。
Volume类型默认key pairs有：volume_backend_name（在cinder.conf定义的名字）、verdor_name、driver_version、storage_protocol。每个厂商的存储会有自己的Extra Specs。此外，目前cinder还支持Qos，Cinder的Qos主要依赖于frontend（hypervisor）和backend（存储）。
Frontend可以通过吞吐量（total_bytes_sec, read_bytes_sec, write_bytes_sec）、IPOS（total_iops_sec，read_iops_sec，write_iops_sec）来控制。
Backend要依据各厂商实际情况。
为了更好的理解，下面引用netapp的方案图：
Cinder基本功能
- 创建、删除volume
- 定义volume "types/extra-specs"
- 镜像复制到volume或volume复制到镜像
- 备份volume（到swift、ceph等）
- 即时点拷贝（volume快照）
- 从快照创建volume
- volume QoS
- 转移volume所有权
- 基于租户的quato
- 自定义调度过滤器
架构设计（参考rackspace解决方案）
参考链接：http://www.rackspace.com/blog/laying-cinder-block-volumes-in-openstack-part-2-solutions-design/
scale-out云架构中，性能瓶颈要考虑很多方面。不仅仅要考虑CPU或RAM，存储的负载、带宽和容量需求也很重要。主要有两种解决方案：
1）COTS服务器作为volume节点。
2）第三方存储解决方案。
COTS服务器
存储节点采用COTS服务器作为虚拟存储阵列（VSA）。cinder-volume可以安装在每个存储节点上。推荐配置：
- 每3TB分配一个core
- 至少2GB内存，每1TB存储增加250M内存
- 至少6块物理盘
- 采用RAID5或RAID 10
推荐采用单独的iSCSI网络。在存储容量需求比较低时，这种方案的成本会比较低，但当需要大容量存储时，就要重新评估了。这种方案的缺点是缺乏冗余，扩展性差，还缺少第三方存储的增值服务：Qos、自动分层、删除功能/压缩、复制等功能。当有多个cinder-volume存储节点时，这些节点实际上是独立的VSA并不共享数据，节点挂掉了后，上面的volume也就用不了。有几种替代方案：
1) 针对实例，在多个存储节点之间对LV做镜像。一个linux VM实例可以通过同时挂载两个存储节点上的volume，然后在这两个volume之间做镜像。这种方法提供了冗余，但是同时损失了50%的容量，相对比较复杂，同时性能也有损失，类似于在实例级别做了软RAID。
2）存储节点使用集群文件系统，这种类似于active-passive工作模式的商业存储。这样造成的性能损失相对少点，也增加了复杂度同时也损失50%的容量。
3）在Cinder项目中未来会增加replication功能，目前存在很多未知数。
第三方商业存储
当采用第三方存储的时候，相对于上面那种方案，会有如下好处：
- 一个第三方存储提供比单个独立COTS存储节点更大的容量。
- 第三方存储解决方案可以提供冗余。各个厂商都有相应的方式，还能提供精简配置、分层级基于阵列的快照等。
当使用第三方存储时可以将cinder-volume安装在Openstack控制节点或者专用节点。这种方式不是通过LVM的方式，cinder-volume通过第三方的volume驱动来export一个iSCSI volume。
第三方SDS方案
还有一类解决方案中，cinder的后端存储采用软件定义存储方式，如Ceph、GlusterFS等，这种方式可以使用COTS硬件同时提供商业存储的功能。
