1. 数据中心云存储趋势

过去20年，传统的集中式数据存储经历过了它最辉煌的时代，云计算带来的底层存储架构变革，已经慢慢宣告这个王者时代的谢幕，接棒数据中心下一代存储黑科技的架构，是近年关注度更高的关键词，如分布式存储，对象存储，超融合等技术，在这其中，除了传统一线厂商的战略迭代产品，也不乏优秀的民间开源解决方案，经过多年的技术沉淀，而今也结束了野蛮纷争的草莽时代，各家产品划地为王，纷纷找到了它的用武之地，而其中的佼佼者，一个是商业软件界的霸主GPFS，另一个是开源软件界的王者CEPH。

2. GPFS和CEPH的初次亮相

关于我：

各位好，我叫GPFS，是一个高性能的共享并行文件系统，自诞生起，就为高性能、数据共享、开放、安全而生。我今年23岁，是一名95后，两年前，为了更好的融入IBM光谱存储大家庭，我有了个更好听的名字——SPECTRUM SCALE，当然对于我来说，这不仅仅是名字的变更，也意味在我身上，增加了关于闪存、容灾、备份、云平台接入等诸多特性，我扮演的角色更加重要，职能定位也愈加明晰了。关于未来，我也有自己的想法，有更大的愿景，希望能和数据中心的其它小朋友们相处愉快，和谐。

关于我：

大家好，我叫ceph，是一个00后，今年12岁了，法律上还未成年，但我的公众形象已经十分成熟，我的名字来源于宠物章鱼的一个绰号，头像就是一只可爱的软体章鱼，有像章鱼触角一样并发的超能力。我平常主要活跃在云计算领域，经过多年的脱胎换骨，不断迭代，我积攒了良好的口碑，好用，稳定，关键还免费，我可以提供对象，块和文件级存储的接口，几乎可以覆盖所有…哇，说着说着突然感觉自己原来无所不能呢，谢谢大家这么关注我，当然，目前我还在长身体的阶段，很多特性在趋于完善，希望未来我们可以相互促进成长。

3. GPFS的前世今生

作为一款成熟的商业产品，GPFS的发展史早已百转千回了，在揭开GPFS的面纱之前，我们还是先来扫扫盲，复习一下在GPFS集群架构中涉及到的基本概念和组件。

架构解耦

1. Cluster：GPFS的组成架构，由一系列的节点和NSD组成，集群的配置文件通常保存在两台主备的节点上。
2. Node：安装了GPFS软件的主机，它可以通过直接或者通过网络访问其它节点的方式来访问存储，每个节点在集群配置中有不同的角色。
3. Cluster manager：负责整个集群配置的正确性和完整性，主要负责监控磁盘租约，检测节点故障和控制节点的故障恢复，共享配置信息，选举文件管理节点等任务。
4. File system manager: 维护文件系统中磁盘的可用性信息，管理磁盘空间，文件系统配置，磁盘配额等。
5. Block: 一个集群中单个I/O操作和空间分配的最大单位。
6. NSD: 提供全局数据访问的集群组件，如果节点和磁盘间没有直接连接，则NSD最好具有主服务节点和辅服务节点。
7. Chunk: FPO架构中的概念，它是一组block块的集合，看起来像一个大的block，一般用于大数据环境。
8. Failure Group: 一组共享故障的磁盘组，当其中一块盘失效时，整个组会同时失效。
9. Metadata: 包括集群配置信息和非用户数据。
10. Quorum Nodes: 用于保持集群活动的仲裁节点，一般有两种仲裁方式，节点仲裁和带Tiebreakerdisk(心跳盘)的仲裁

上述组件如何有机的组合在一起提供存储服务呢，把以上组件拼接起来，就可以得到下图所示的集群大体架构：

使用方案

基本架构了解了，那怎么用呢？先祭出三张架构图，业内人士一看应该懂，不明白没关系，往下针对这几张图稍作解释：

左上：传统的GPFS(Directattach)使用场景，图中分为主机，交换机，存储三类角色，前端主机(即图中的Application Nodes)类型可以是AIX/Linux/Windows服务器节点，存储使用集中式的存储架构，存储lun通过光纤交换机Zoning的方式映射给所有主机，数据传输走光纤网络，在前端主机中能识别到所有lun的块设备，并为其创建NSD，主机与存储间通过SAN网络直接通信，不借助通过其它结点。

右上：混合的GPFS使用场景，是左上架构的拓展，跟左上不同的是，在该架构中，并非GPFS用到的所有NSD都映射给了所有的主机，我们给集群中的NSD添加了NSD Server的属性，这就决定了集群中一部分节点访问存储的方式，不是直接访问存储，而是通过TCP/IP网络访问NSD Server的方式来访问后端存储。主要适用于以下情形，1. 集群节点跨站点，但两个站点间没有足够稳定的光纤通道可以互通。2. 节省光纤资源。

下图：这张图是我们今天的主角，也是GPFS之所以拿来和CEPH对决的核心架构，我们在后面再展开说说。接下来说说应用场景。

应用场景

在传统DB2数据库双活方案GDPC的使用场景中，为了实现跨站点的双活+容灾，底层存储方案选用GPFS，双站点架构中，两个站点均配备主机和存储资源，每个站点的存储形成一个failure group，远程访问对端存储采用nsd server的方式访问，两个failure group间完全冗余，任何一个站点出现故障都不影响文件系统的正常使用，并通过第三方站点的一台服务器和nsd作为仲裁节点，是真正意义上的双活。

GPFS可以用来替代HDFS作为大数据的底层存储，GPFSFPO+Symphony作为相对Mapreduce更领先的分布式计算框架，可以更灵活和支持和对接企业的IT使用场景。

在IBM的部分企业级云产品中，GPFS FPO也被用来作为私有云产品的底层存储来使用，用来存储虚机镜像和介质，这一点上使用和CEPH也极为相似。

4.CEPH的发展之路

作为云计算的三架马车，网络，存储，管理平台，业界的开源方案里，网络层面SDN日渐成熟，管理平台上，Openstack已经创造了一个时代，而CEPH，无疑成为存储最犀利的开源解决方案。谈起它的架构之前，我们有必要先来了解以下这些概念，同时为了更加形象化，我们将部分组件对应到GPFS的组件上来理解，但请注意实际的功能和结构仍然差别巨大。

架构解耦

1. Ceph monitor——对应quorum +cluster manager:保存CEPH的集群状态映射，维护集群的健康状态。它分别为每个组件维护映射信息，包括OSD map、MON map、PG map和CRUSH map。所有群集节点都向MON节点汇报状态信息，并分享它们状态中的任何变化。Ceph monitor不存储数据，这是OSD的任务。
2. OSD——对应NSD: CEPH的对象存储设备，只要应用程序向Ceph集群发出写操作，数据就会被以对象形式存储在OSD中。这是Ceph集群中唯一能存储用户数据的组件，同时用户也可以发送读命令来读取数据。通常，一个OSD守护进程会被绑定到集群中的一块物理磁盘，一块磁盘启动一个OSD进程，可以对应GPFS的NSD概念。
3. Pool：是存储对象的逻辑分区，它规定了数据冗余的类型和对应的副本分布策略，副本支持两种类型：副本（replicated）和纠删码（ Erasure Code）
4. PG(placement group)——对应Chunk：是一个放置策略组，它是对象的集合，该集合里的所有对象都具有相同的放置策略；简单点说就是相同PG内的对象都会放到相同的硬盘上； PG是 ceph的核心概念，服务端数据均衡和恢复的最小粒度就是PG；
5. MDS——对应Filesystemmanager：Ceph元数据服务器，MDS只为CephFS文件系统跟踪文件的层次结构和存储元数据。Ceph块设备和RADOS并不需要元数据，因此也不需要Ceph MDS守护进程。MDS不直接提供数据给客户端，从而消除了系统中的故障单点。
6. RADOS：RADOS是Ceph存储集群的基础。在Ceph中，所有数据都以对象形式存储，并且无论是哪种数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。要做到这一点，须执行数据复制、故障检测和恢复，以及数据迁移和在所有集群节点实现再平衡。
7. RBD：RADOS块设备，提供持久块存储，它是自动精简配置并可调整大小的，而且将数据分散存储在多个OSD上。RBD服务已经被封装成了基于librados的一个原生接口。
8. RGW:RADOS网关接口,RGW提供对象存储服务。它使用librgw和librados，允许应用程序与Ceph对象存储建立连接。RGW提供了与Amazon S3和OpenStackSwift兼容的RESTful API。
9. CephFS——对应GPFS文件系统：Ceph文件系统提供了一个使用Ceph存储集群存储用户数据的与POSIX兼容的文件系统。和RBD、RGW一样，CephFS服务也基于librados封装了原生接口。

同样，如果把上述元素和概念按照逻辑进行拼接，可以得到以下这张CEPH的基本架构图，图中反映了各个组件的逻辑关系。

CEPH提供了一个理论上无限扩展的集群，客户端和ceph osd进程通过crush算法来计算数据位置，而不必依赖一个中心查找表，我们知道凡是网络设备都有并发连接数据的限制，集中式/单体式的存储系统，对于大规模部署来说，很容易达到物理极限，在CEPH的数据访问机制中，客户端和osd进程直接通信，提高了性能和系统总容量，消除了单点故障，CEPH客户端仅在需要时与osd进程建立一个会话。

osd进程加入一个集群，并且报告他们的状态，分为up和down两种状态，代表是否可以响应ceph客户端的需求，如果osd进程失败，则无法通知ceph monitor它已经down掉，ceph通过周期性的ping OSD进程，确保它正在运行，CEPH授权OSD进程，确定授信的OSD进程是否已关闭，更新cluster map，并报告给CEPH Monitor.

OSD进程也通过crush算法，计算对象的副本应该存放的位置，在一个写场景中，客户端使用crush算法计算应该在哪里存放对象，并将对象映射到一个pool和placement group, 然后查询crush map来定位placement group中的主OSD进程。

客户端将对象写入主osd的placementgroup中，然后主osd使用它自己的crush map来找到第二、三个OSD，并且将对象副本写入第二、第三OSD的placement group中，主OSD在确认对象存储成功后会给客户端一个回应。OSD进程完成数据的复制，不需要ceph客户端参与，保证了数据的高可用性和数据安全。

CephFS从数据中分离出元数据并保存在MDS中，而文件数据保存在CEPH存储集群的objects中，ceph-mds作为一个进程单独运行，也可以分布在多个物理主机上，达到高可用和扩展性。

使用方案

了解了架构和原理，该怎么使用呢？Ceph主要用于完全分布式操作，没有单点故障，可扩展到exabyte级别，完全免费使用。其采用的位置感知算法和数据复制机制使其具有容错能力，并且不需要特定的硬件支持，也成为他天生骄傲的资本，大大降低了使用门槛，在贫瘠的物理介质上就可以野蛮生长。一般来说，CEPH主要提供三种使用场景，rbd(block device),对象存储和CephFS文件系统方式，如下图所示：

CEPH客户端使用原生协议与CEPH存储集群进行交互，CEPH将这些功能打包成librados库，因此你可以创建自己的CEPH客户端，CEPH作为分布式存储，对外提供各类型的标准存储服务。

CEPH blockdevice的快照功能对于虚拟化和云计算来讲很有吸引力，在虚拟机场景中，极具典型的是在Qemu/KVM使用rbd网络存储驱动部署CEPH block device，宿主机使用librbd向客户机提供块设备服务。而在K8S管理的容器平台中，Ceph也可以提供标准rbd设备的动态供给和共享存储空间。

5.CEPH与GPFS的正面交锋

为了更深入透彻的了解CEPH和GPFS的优劣，我们将从以下这些方面逐一对比CEPH和GPFS的特性，期望可以提供更科学客观的参考。

管理功能

GPFS——GPFS提供了一系列完美的商业化产品功能，基于策略的数据生命周期管理，高速扫描引擎，在线数据迁移，闪存加速，这些特性都大幅提升了它的用户体验，在复杂的IT环境中有了更多施展拳脚的空间。

CEPH——CEPH产品相对年轻，周边功能和生态目前尚不完善，延展功能上来说不及GPFS丰富，但已经具备管理的基本功能，它的VSM功能，即Ceph的web管理界面，目前也已完善。

平台兼容性

GPFS: GPFS一个很大的亮点是支持跨平台部署和文件共享，同一集群中可以包括Windows/ Linux/AIX等异构平台，良好的异构兼容性尤其对于传统企业复杂的异构IT环境有着天然的亲赖。

CEPH: 目前CEPH所提供的rbd是基于Linux内核的，CEPH仅支持部署在Linux平台上，rbd的块设备不能直接映射给非linux的客户端使用(如果要使用可以通过导出为iscsi设备的方式)。

服务方式

GPFS——是一个高性能并行集群文件系统，可支持多种存储设备，包括Flash、磁盘等块存储、对象存储、文件存储，甚至可以管理磁带。支持多云部署以及POSIX、NFS/CIFS、HDFS/Hadoop 、Swift/S3等多种接口。

CEPH——可同时支持对象存储，块存储和文件型存储，且鉴于当前基于POSIX的文件系统方案尚不完善，CephFS功能正努力完善中。支持Switft/S3等云存储环境。

存储性能

GPFS——广泛应用于世界领先的 HPC 超级计算环境。在加速并行访问方面的显著优势有：改善了小文件的 IO 性能，支持超过 4600个计算节点的高速并发访问，实现16GB/s 单节点顺序读写带宽，以及每秒可创建 260万个小文件。作为一个并行文件系统，它将智能融入客户端，并由客户端在集群中的所有存储节点之间分配负载，即使对于单个文件也是如此。

CEPH——CEPH的算CRUSH法和PG存放机制，使它可以充分利用多块磁盘的IO队列，但最开始基于HDD设计，对于SSD和NVRAM等使用场景没有没有特别的性能优化策略，可能导致这些硬件的物理性能在CEPH中发挥受限，延迟和IOPS在高速硬件环境下得不到显著提升。

技术架构

GPFS——具有集群管理者的概念，节点间采用仲裁机制，在灾备环境下需要引入第三方站点，参与集群仲裁。

CEPH——没有绝对的中心结点，可以完全排除单点故障，无中心化的设计思想，使集群具有理论上无限扩张的可能性。

适用场景

GPFS——适用当下流行的生产环境，其中FPO架构可通过多个block组成Chunk的方式，很好的适应大数据环境，并且可以与IBM Symphony分析工作配合使用。同时FPO架构也可用于IAAS平台的底层存储，用于存储虚拟机镜像，用于PAAS容器云环境，用来对容器提供数据存储的接口服务。另外，也可以搭建集群环境提供NAS的功能用于文件和影像的共享。

CEPH——更多用来提供对象存储和块存储的服务，不适用于大数据环境，同样可用来IAAS和PAAS架构的云环境提供存储服务，或者为单一架构的IT环境提供块存储服务，作为分布式的优秀解决方案，天生有对接云生态的基因，CEPH不仅在OpenStack时代可以大有作为，同样在容器云时代也可以大放异彩。

数据分层

GPFS——GPFS具有很好的数据分层实现机制，cache机制，将日志卷部署在SSD上，在某些场景下可以带来显著的性能提供

CEPH——Crushmap可以用来做分级存储，例如根据底层不同硬盘，例如HDD或SSD等来分为不同的 pool，Ceph的Cache tier技术可以实现hot data和 cold data分离，把热数据放到Cache层，过段时间同步到cold date层等等。

安全机制

GPFS——该环境中，某一节点的硬盘连接丢失，不会影响到其他的节点，GPFS使用RSCT的功能持续的监控不同文件模块的健康状态，当任一错误被检测到时，相应的恢复动作将自动执行。GPFS还提供了额外的日志和恢复功能，可以维持元数据的一致性。最大三副本，可支持节点的自动Failover。

CEPH——rados采用强一致性设计，可容忍网络中断、掉电、服务器宕机、硬盘故障等，并进行自动修复，保证数据的可靠性和系统可用性。也是同样的三副本设计，支持节点的自动Failover。Monitors是Ceph的管家，维护着Ceph的全局状态。Monitors的功能和zookeeper类似，它们使用Quorum和Paxos算法去建立全局状态的共识。其OSDs可以进行自动修复，而且是并行修复。

冗余机制

GPFS——数据冗余可以通过failure group机制实现，以文件系统作为复制单元，数据在物理上存储两份或三份，节点冗余上，重要角色如集群管理者，会分配主备两个节点，其它角色会在集群节点间飘移。

CEPH——数据冗余上，底层文件对象默认存储3个副本，节点冗余上，多mointor机制可以有效防止单点故障，在文件存储上，额外的ceph-mds实例可以备用以取代任何失效的ceph-mds,由ceph-mon自动完成，也可以启动多个ceph-mds实例，将目录树分离为子目录树，这样能够在多个启动的实例中有效的平衡负载。

6.分布式存储未来畅想

未来的IT架构是生态之争，赢生态者得天下，就像开放的安卓赢得了众多开发者的亲赖，繁荣的产品生态也成就了安卓。运维自动化和智能化运维建设，要求底层IT环境实现高度整合，自主可控更是对开放性的要求，开放是一个产品的亲和力，意味着可以更灵活的融入当前IT环境，当前云计算的存储标准接口仍然有开放席位，静待新的有生力量入驻。

不管是存储，还是网络等基础架构，都在试图屏蔽底层物理硬件的差异，实现硬件的标准化管理，用软件定义一切，分布式存储就是在这样的趋势下，赢得了蓬勃发展的契机，开放的产品接口，丰富的插件，与当前环境的兼容耦合性，都将成为分布式存储领域制胜的关键，未来分布式存储在安全性、产品化建设、兼容性、可管理性、稳定性上的不懈努力，将是引领分布式存储占领数据中心存储江山的重要砝码。

本文作者：刘文，文章来源：talkwithtrend