刘文
作者刘文2018-12-10 14:16
系统工程师, CMBC

漫谈分布式存储方案,GPFS对话CEPH

字数 7739阅读 6446评论 12赞 35

1. 数据中心云存储趋势

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

2. GPFS和CEPH的初次亮相

GPFS关于我:

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

CEPH关于我:

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

3. GPFS的前世今生

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

架构解藕

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

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

nb7nytcs9f

nb7nytcs9f

使用方案

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

x7msi8sv2rj

x7msi8sv2rj

左上:传统的GPFS(Direct attach)使用场景,图中分为主机,交换机,存储三类角色,前端主机(即图中的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作为大数据的底层存储,GPFS FPO+Symphony作为相对Mapreduce更领先的分布式计算框架,可以更灵活和支持和对接企业的IT使用场景。
在IBM的部分企业级云产品中,GPFS FPO也被用来作为私有云产品的底层存储来使用,用来存储虚机镜像和介质,这一点上使用和CEPH也极为相似。

4. CEPH的发展之路

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

架构解藕

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

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

xaz48e3med

xaz48e3med

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

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

使用方案

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

l4fx9ooj4n

l4fx9ooj4n

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

CEPH block device的快照功能对于虚拟化和云计算来讲很有吸引力,在虚拟机场景中,极具典型的是在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。除此之外,GPFS还支持原生文件加密,数据传输加密。授权安全管理,安全对接云存储,文件审计。

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环境,当前云计算的存储标准接口仍然有开放席位,静待新的有生力量入驻。

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

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

35

添加新评论12 条评论

#tonygray售前技术支持, 华云数据
2019-09-27 21:47
早年玩过GPFS,当时的感觉是架构设计的不错,实际使用不太稳定,经常出现问题,近几年来也不知道改进了没有
#abit2007系统工程师, 代维
2019-01-15 13:03
非常感谢,仔细读了下来,写的不错。
#michael1983技术经理, 某证券
2018-12-31 20:45
很不错的技术分析对比,受益匪浅
#wuwenpin软件开发工程师, 南京
2018-12-23 17:56
好资料,感谢分享!
#bjibm1188系统工程师, DCITS
2018-12-23 11:16
分析透彻,对比思路清晰,对未来数据中心存储架构选择极具指导意义。
#hacmp系统工程师, 四川华信富恒
2018-12-21 10:31
先了解下,还没有机会接触
#zhaijianj系统架构师, 奇瑞捷豹路虎汽车有限公司
2018-12-18 10:49
写的不错。GPFS是个好东西,原理上讲能运用的场景还挺多的,现在只要还是用在HPC上面,主要是搭配。ceph用在云场景比较多,因为它便宜开源好搭其他的东西。
#hidwx123销售管理, 世纪互联
2018-12-18 10:21
GPFS感觉更像集中式存储的软件化产品,高效和稳定更适合企业(前提是价钱合适)。产品化对运维能力要求相对较低。 CEPH作为开源产品还有很多地方需要改进行,并且对运维能力要求较高。但对于从采购成本来看会让几多企业愿意尝试。 1、如果用GPFS容灾时,对距离和带宽要求是多少(使用FC协议)?还是可以以传统的集中存储的要求作为标准? 2、Failure Group: 一组共享故障的磁盘组,当其中一块盘失效时,整个组会同时失效。为什么要这样子设计?理由是什么呢?

刘文@hidwx123 1.GPFS容灾可以使用FC协议,实际使用中,FC光纤实际距离最好控制在50KM以内, 也可以使用network nsd的模式,选择比较自由,但双活环境对于带宽要求较高,需要专用运营商网络。2. 两个failure group间的盘不是一一对应的啊,就是相当于两组数据,当一个fg有一个磁盘失效时,这一组数据就不可用了,所有就整个组会失效。

2018-12-20 22:48
#shangqingbo系统工程师, 神州数码
2018-12-17 14:40
对比分析很好的,讲的挺透彻的,结合实际,如果可以接受价钱,GPFS作为商用可以直接上线的,如果为了学习以及练手可以上ceph,当然可以部署一套ceph作为边缘设备的存储。
#TonyWang系统工程师, BY
2018-12-14 14:53
干货满满,收获多多 ,对以后分布式存储选型有帮助! 有两个问题咨询: 1、跨机房数据同步、容灾上是不是GPFS做的更好 2、用GPFS 作为OpenStack 底层共享存储的实际案例多吗?

charleschen@刘文 没错,我来认领下这个案例。

2019-06-21 12:04

TonyWang@刘文 好的,谢谢

2018-12-21 11:05

刘文@TonyWang 1. 目前来说,GPFS的方案成熟,易于实施 2. IBM之前早期的云产品是基于GPFS FPO架构做的,可以云了解一下,openstack cinder一直提供gpfs的driver。国内实际案例不多,联通应该有在用。

2018-12-20 22:51
#baimao3000安全工程师, 江苏天宝
2018-12-14 13:54
长见识了,谢谢分享。
#yang3518系统工程师, IBM长沙分公司
2018-12-10 23:54
写的不错,
Ctrl+Enter 发表

本文隶属于专栏

技术路线选型
不同趋势领域都有不同技术路线,不同行业的应用规模也有不同技术路线。通过对同一场景下不同技术路线的对比分析,帮助用户选择最适合企业发展需要的技术路线。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30