从Garnter的报告谈起
笔者接触存储产品比较早。从最初的HP MSA、EVA、XP、IBM DS8800等高端硬件存储，到GPFS、vSAN、Gluster等软件定义存储。而近两年，笔者随着阅历和见识的增加，在看待技术方案上，比以前理性和客观。所以给客户的建议，也往往更加中肯一些。
在存储界，每一种存储的产品，都有其各自的优势。没有兼顾容量大、性能高、功能强、价格低的四方面的完美方案，那样宣传和卖假药的没有分别。而我们用某一项技术和方案，也是用其长而避其短。
前两天看到了一份Gartner发布的名为《Critical Capabilities for Distributed File Systems》报告。该报告介绍和对比了几个主流分布式文件系统的方案，并做出评判和打分。笔者认为比较客观，本文就此展开讨论。
Gartner针对分布式文件系统的评判，基于5个使用场景，如下：
场景1：归档
场景2：备份
场景3：高性能运算
场景4：大目录
场景5：数据分析
在上述排名中，整体上看，整体排在前面的，显然IBM的Spectrum Scale和Dell EMC Isilon整体表现不分伯仲。 EMC Isilon是包含硬件的解决方案，IBM Spectrum Scale前身是GPFS，是软件定义存储解决方案。在EMC和IBM后，Redhat GlusterFS在一些场景中占据优势。
可能一些朋友对GlusterFS了解不是很多。这里大致进行一下介绍。
Gluster是红帽2011年10月收购的一个软件定义存储产品。
目前，Gluster是一个开源项目（http://www.gluster.org/）。Redhat Gluster的最新版本是3.3。
既然我们谈用人之长，先看看Gartner对Gluster的正面评价:
和社区版GlusterFS相比，Redhat GlusterFS具有更强的稳定性、功能也更强。Redhat GlusterFS PB级存储扩展容量、具有快照、本地复制、异地复制的功能。GlusterFS支持多种对外协议：SMB、CIFS、NFS、FUSE。Gluster支持在物理机、虚拟机（KVM、vSphere等）、公有云上的部署。Gluster最多可以扩展到128个节点。
GlusterFS对于对容量要求比较大的客户而言，是一个非常好的选择。Gartner的观点是：GlusterFS最适用的场景有：富媒体、备份和恢复以及近线归档。
那么，GlusterFS的短处是什么？Gartner的观点是：GlusterFS并未针对小型和随机I / O工作负载进行优化，缺少对压缩和重复数据删除的本地支持。所以，对于关系型数据库，随机小I/O很高的场景，仍然建议使用集中存储。
从技术角度看，Gartner对GlusterFS的评判基本中肯。而实际上，除了Gartner提到的三个场景外，GlusterFS与红帽KVM方案RHV对接，可以为KVM Hypervisor提供共享存储空间，也是一个非常实用的场景。将虚拟机的数据文件存放在GlusterFS上，正好发挥了它对于大文件存储和读写的优势。
除了适用于富媒体、备份和恢复以及近线归档、对接KVM虚拟化之外，GlusterFS还有一个重要是使用场景：容器。
Container-native storage 容器原生存储
我们先看一个问题：容器到底需要什么样的存储？
我们知道，K8S已经成为容器编排工具的标准。因此，容器需要的存储：
1.该存储必须原生支持K8S
2.该存储支持容器读写模式必须要全面
3.该存储最好同时支持本地方式和公有云方式，以便容器可以灵活迁移。
第一点，GlusterFS在较早版本就已经开始与K8S集成：
第二点，基于各种存储创建PV以后，对容器（Pod）的读写模式支持列表如下：
我们看到，GlusterFS同时支持ReadWriteOnce、ReadOnlyMany、ReadWriteMany三种访问方式。
三种访问方式描述如下：
ReadWriteOnce – the volume can be mounted as read-write by a single node
ReadOnlyMany – the volume can be mounted read-only by many nodes
ReadWriteMany – the volume can be mounted as read-write by many nodes
真正做过容器云的项目的同学都比较清楚，ReadWriteMany模式，对于容器的伸缩的重要性非常高。容器的存储做不到ReadWriteMany方式访问，容器的弹性伸缩犹如纸上谈兵。
第三点，Gluster对公有云和本地存储模式的统一支持。
实际上，GlusterFS在比较早的时候，就已经支持几类公有云：
GlusterFS与Openshift 3.7集成的新功能
最近，红帽发布了Openshift3.7。Openshift3.7与Gluster的集成功能得到进一步增强，主要有四大提升。我们依次看一下。
第一大提升：
由于GlusterFS增加了Brick-mutliplexing功能（http://blog.gluster.org/brick-multiplexing-in-gluster-3-10/），这使得GlusterFS在支持Openshift的时候,PV的密度可以比以前增加三倍。也就是说，三个节点的Gluster集群，可以提供超过1000个PV，300个基于block的PV（关于Gluster对块的支持，在后面会做介绍）。
第二大提升：
Gluster对Openshift的支持，不仅可以使用传统的文件系统方式（FUSE），也可以为Openshift提供块接口。
Gluster增加iscsi接口的目的，是为了提高ElasticSearch，PostgreSQL、Cassandra等Openshift内部数据库组件的性能。
Gluster在后续3.6版本，还会添加S3接口 ，目的是允许在OpenShift中运行的应用程序，访问以对象方式存储在GlusterFS卷上的数据。
第三大提升：
Gluster目前支持包含组件和应用在内的，所有和Openshift相关的内容。
在Openshift中，需要用到外部持久存储的组件有：
日志系统数据、监控系统数据、集成镜像库、外部镜像仓库、应用持久数据。
在之前的Openshift版本，Gluster对五类数据提提供的存储访问方式都是FUSE方式。但我们知道，在日志系统数据、监控系统数据里，其实是有数据库elasticsearch 和cassandra 的，对数据库而言，访问存储的最佳方式是块设备。因而在Openshift3.7中，Gluster可以以iSCSI方式为这两类数据库提供持久存储，这样可以提升数据库性能。
第四大提升
在Openshift3.7中，glusterfs和Openshift超融合模式的安装，更加加单。也就是Openshift和Gluster可以一起部署。
最后，针对Openshift的应用场景，我们对GlusterFS、Ceph RBD以及NFS的优缺点进行分析：
综合以上参数，Openshift平台优先Gluster,Openstack优先Ceph RBD,当不考虑成本及易用性的角度可以用NFS。
总结：
如本文开头所说，没有任何一个技术是完美的。我们在做技术选择的时候，要用其长处。
GlusterFS作为分布式文件系统，在传统的富媒体、备份和恢复以及近线归档具有一定优势。此外，GlusterFS和红帽的KVM虚拟化RHV，也是红帽最佳搭档方案。而在容器风靡天下的今天，GlusterFS与K8S实现了完美集成，可以非常好地支持容器云，并且为红帽Openshift容器云提供了大量的增强功能。
顺便说一句，对于客户核心数据库和对IOPS要求非常高的应用，建议客户使用集中式存储。Gluster并不是适用于所有场景的存储方案，我们不是卖假药的。
