OpenStack商用需要跨过的坎 -- 3. 存储系统的选择和实现

OpenStack的存储模块有cinder和swift，分别负责提供块存储和对象存储服务。swift虽然出道比较早，算是OpenStack的元老项目之一，但是目前的关注度并不高。倒是cinder由于采取了driver plugin的方式，得到了各大存储厂商的支持，同时发展的也很快。而对象存储这一块，目前ceph和swift形成了竞争关系。cinder得到的关注比较多，是因为目前企业里面大部分的存储还是基于块设备的。

目前Cinder支持的存储驱动非常多，详细的support matrix可以参考官方链接https://wiki.openstack.org/wiki/CinderSupportMatrix。从商用的角度来说，下面几种支持的存储类型是非常有意义的：

1. 传统商业存储：比如EMC, IBM, HDS, Huawei, HP，NetApp等的中、高端存储。支持FC和iSCSI协议

2. 分布式存储：比如Ceph

3. 分布式文件系统：比如GPFS, ClusterFS

4. NFS：可以支持各种NAS

除了支持现有的主流存储类型，cinder还支持多个存储统一管理，也就是说可以用cinder统一管理各个厂家的存储，只要它在支持列表里就行。这就为客户提供了很多的选择余地。Cinder的API比较简单，涉及的操作很少，所以对于各个存储厂商实现起来也比较容易，基本都能比较全面的实现。不像Nova, Neutron，很多虚拟化厂家提供的驱动无法完全匹配所有的API。下面是一个cinder使用EMC VMAX驱动的示例，图中显示仅仅支持iSCSI，实际上目前已经可以支持FC了，但是需要计算节点上配置HBA卡。



对于很多传统客户来说，共享存储是一个很重要的功能，许多重要的应用或者数据库都依赖于共享存储来保证数据的一致性。这一块目前Cinder也已经提供了可选项，允许在创建卷(volume)的时候指定是否允许共享给多个虚机。只要在创建volume的时候加上 “--allow-multiattach”参数，就可以让这个卷具备共享的属性。创建完成后，执行cinder list可以查看Multiattach属性，如果是"True"就表示该卷具备共享属性。

# cinder help create
usage: cinder create [--consisgroup-id <consistencygroup-id>]
[--snapshot-id <snapshot-id>]
[--source-volid <source-volid>]
[--source-replica <source-replica>]
[--image-id <image-id>] [--image <image>] [--name <name>]
[--description <description>]
[--volume-type <volume-type>]
[--availability-zone <availability-zone>]
[--metadata [<key=value> [<key=value> ...]]]
[--hint <key=value>] [--allow-multiattach]
[<size>]
# cinder list
+--------------------------------------+-----------+------------------+---------+------+-------------+----------+-------------+--------------------------------------+
|                  ID                  |   Status  | Migration Status |   Name  | Size | Volume Type | Bootable | Multiattach |             Attached to              |
+--------------------------------------+-----------+------------------+---------+------+-------------+----------+-------------+--------------------------------------+
| 91dfabb7-b45f-4833-a6e0-92e6e1cbc43b | available |        -         | volume1 |  1   |      -      |  false   |    False    |                                      |
| ddd63583-4993-4f5a-8122-78729cb452be |   in-use  |        -         | volume2 |  1   |      -      |  false   |     True    | cec676b5-e75f-4440-b485-3723e280db9d |

共享卷创建完成后，下一步就是通过nova attach-volume命令去将共享卷分配给多个虚机了。但是目前liberty版本的nova仍然无法支持这个功能。要实现这个功能，nova这块的改动比较大，目前看在Mitaka版本里应该能加进来。具体关于相关spcs的进度可以参考https://review.openstack.org/#/c/85847/

上述功能完成后，应该说对于传统企业来说，就能覆盖绝大部分的存储应用场景了。因为这些企业用的最多的就是SAN存储和NAS，并且支持共享模式。

对于传统企业来说，目前还需要面临一个新选择，就是是否采用分布式存储，也就是Server SAN。分布式存储主要有以下优势：

1. 可扩展性好，能够扩展到成百上千个节点

2. 在规模比较大的情况下（一般建议10个节点以上），总体拥有成本(TCO)会比较低

但是分布式存储也面临一些挑战，主要体现在：

1. 可靠性如何保证，也就是如何保证不丢数据，并且应用可以持续正常访问存储。传统存储是靠冗余控制器和RAID阵列实现。分布式存储靠分布式的多副本数据复制来实现。为了提高性能，分布式存储一般将写数据先缓存在节点的内存里，就告知应用写完成了，之后由后台的异步程序将内存里的脏数据刷到磁盘上。这就导致一旦机器异常掉电，缓存里的数据就会部分丢失。除此之外，某个节点突然性能严重下降，如果分布式存储无法及时把该节点踢出集群，也会导致整个集群性能严重下降。

2. 性能问题：多副本的复制导致一个写请求需要在多个节点（至少2个，取决于副本数）完成写操作，这就会有一定的性能开销，对于响应时间要求非常高的应用就需要谨慎使用。

3. 数据恢复时间：就是一块硬盘被替换后，在不影响应用访问的情况下，多长时间能恢复正常的副本数量。如果恢复时间过长，客户一旦再有别的硬盘坏了，并且恰好两块硬盘都有同一份数据的副本，这个数据就会丢失。

4. 容灾：就是如何实现两个甚至三个数据中心的远程容灾。

5. 运维：分布式存储的管理相对传统存储要复杂的多，如何化繁为简，提高运维效率和质量，是分布式存储面临的挑战之一。

对于企业客户来说，选择分布式存储之前一定要多接触真实的使用案例，了解各种产品的利弊。总的来说要根据自己的实际情况来选择存储，一般遵循如下原则：

1. 数据规模不大，并且今后增长也很少的云平台，可以考虑采用传统的存储来实现。

2. 数据规模大，并且今后数据会快速增长的云平台，建议采用分布式和传统相结合的方式。慢慢积累在分布式存储上的运维经验，成熟的时候逐步将应用迁移到分布式存储。

3. 如果采用分布式存储，对于生产系统，还是建议采用分离部署的方式，即存储节点上只提供存储服务，不提供虚机等计算服务，这样不至于出现资源的争抢，有利于存储集群的稳定。对于开发测试系统，可以考虑采用融合方式部署，节省成本。此外，生产系统建议选择口碑好的商用分布式存储，开发测试可以考虑开源产品（比如ceph），但需要自己有比较强的维护能力。