首页天道酬勤分布式存储的未来,分布式移动存储系统

分布式存储的未来,分布式移动存储系统

张世龙 05-12 14:25 54次浏览

在2018年Garnter技术成熟度曲线中,集装箱存储出现在技术触发期,已经开始进入大众视野。 我相信在未来两年内,集装箱存储将随着Kubernetes的成熟和商业化,其地位将越来越重要。 如何在各种存储产品中选择适合自己的存储产品,成为了IT面临的一个甜蜜的早晨。 在这次共享中,我们将分析如何从使用场景的角度评估容器存储方案。

各种存储概念

从用户的角度看,存储是磁盘或目录,用户不关心磁盘或目录是如何实现的,用户要求非常“简单”、稳定、性能好。 为了提供稳定可靠的存储产品,各制造商推出了各种存储技术和概念。 为了获得整体的认识,本文介绍了存储的这些概念。

从存储介质的角度看,存储介质分为机械硬盘和固态驱动器(SSD )。 机械硬盘是指磁头寻址磁盘设备,如SATA硬盘和SAS硬盘。 由于磁头寻址,机械硬盘性能一般,随机IOPS一般在200左右,顺序带宽在150MB/s左右。 固态驱动器是由Flash/DRAM芯片控制器组成的设备,根据协议分为SATA SSD、SAS SSD、PCIe SSD和NVMe SSD。

从产品定义的角度看,存储分为四大类:本地存储(DAS )、网络存储(NAS )、存储局域网(San )和软件定义存储(SDS )。

DAS是本地磁盘,直接连接到服务器的NAS是指提供NFS协议的NAS设备。 通常,使用磁盘阵列协议网关,SAN提供SCSI/iSCSI协议(与NAS类似),后端提供磁盘阵列SDS通常包括分布式NAS (并行文件系统),而ServerSAN等提供APP应用程序

Kubernetes如何定义和分类存储? Kubernetes中与存储相关的概念包括持久性卷(PV )和持久性卷存储器(PVC ),PV分为静态PV和动态PV。 静态PV方式如下。

动态PV需要引入StorageClass概念,使用方法如下:

社区列举永久卷的三叉树插件,如下图所示。 从图中可以看到,Kubernetes根据访问模式将存储分为三类: RWO/ROX/RWX。 此分类混淆了现有的存储概念,包括存储协议、存储开源产品、存储业务产品和公共云产品。

如何将Kubernetes分类与众所周知的存储概念联系起来? 本文选择将其与应用场景进行类比。

块存储通常仅支持RWO,如AWSElasticBlockStore和azure磁盘。 某些产品的文件存储(分布式文件系统) (如GCEPersistentDisk、RBD和ScaleIO )支持三种模式: RWO/ROX/RWX 可以直接访问和使用APP应用程序。 这里不得不深入到Kubernetes社区前期存储层的抽象中。 一字——混乱,同时引进了开源项目和商务项目。 社区目前意识到问题,并设计了统一的存储接口层—— flex卷/CSI。 目前,CSI已成为Kubernetes的主流,并创建了完整的存储抽象层。

各种各样的APP应用场景

在介绍存储概念后,选择哪个存储仍然是未解决的。 这个时候,请问一个问题。 业务是什么类型的? 要选择合适的存储,必须明确业务对存储的需求。 整理了使用容器存储的场景及其特征。

构成

群集配置信息和APP应用程序配置信息的特点都是并发访问(如上所述的ROX/RWX ),可以在不同的群集或不同的节点上访问相同的配置文件,从而优化分布式文件存储。

日志

在容器场景中,日志是一个重要的部分,其特点是吞吐量高,并且可能生成大量的小文件。 如果有日志分析场景,也有大量的并发读取操作。 分布式文件存储是最佳选择。

高速APP应用程序(数据库/消息队列/大数据)

Kafka、MySQL、Cassandra、PostgreSQL、ElasticSearch和HDFS等APP应用程序本身就具备存储数据的能力,对底层存储的要求是高IOPS、低延迟底层存储最好具有数据冗馀机制,以避免复杂的故障和恢复操作。 以HDFS为例,在一个datanode节点停机后,原始逻辑选择启动新的datanode、启动恢复逻辑和完成数据拷贝的完成。 这个时间很长,对业务的影响也很大。 如果基础存储具有复制机制,则HDFS群集可以设置为单副本。 datanode节点关闭后,启动新的datanode并装载原始pv。 集群恢复正常,对业务的影响缩短到秒级。 高性能分布式文件存储和高性能分布式块存储是理想的选择。

备份

备份APP应用程序数据或备份数据库的特点是吞吐量高、数据量大、成本低。 文件存储和对象存储是最佳选择。

要整合APP应用程序场景,高性能文件存储是最佳选择。

各种存储产品

市场上的存储产品种类繁多,但在容器场景中,主要集中在分布式文件存储、分布式块存储、本地磁盘和传统NAS四种方案上。

分布

式块存储包括开源社区的Ceph,Sheepdog,商业产品中EMC的Scale IO,Vmware的vSAN等。分布式块存储不适合容器场景,关键问题是缺失RWX的特性。

分布式文件存储包括开源社区的Glusterfs,Cephfs,Lustre,Moosefs,Lizardfs,商业产品中EMC的isilon,IBM的GPFS等。分布式文件存储适合容器场景,但是性能问题比较突出,主要集中在GlusterFS,CephFS,MooseFS/LizardFS。

这里简单对比下开源项目的优缺点,仅供参考。

Local-Disk方案有明显的缺点,尤其是针对数据库,大数据类的应用。节点故障后,数据的恢复时间长,对业务影响范围广。

传统NAS也是一种文件存储,但是协议网关(机头)是性能瓶颈,传统NAS已经跟不上时代发展的潮流。

分门别类的评估策略

存储的核心需求是稳定,可靠,可用。无论是开源的存储项目还是商业的存储产品,评估方法具有普适性,本文会介绍常见的评估项和评估方法。

数据可靠性

数据可靠性是指数据不丢失的概率。通常情况下,存储产品会给出几个9的数据可靠性,或者给出最多允许故障盘/节点个数。评估方式就是暴力拔盘,比如说存储提供3副本策略,拔任意2块盘,只要数据不损坏,说明可靠性没问题。存储采用不同的数据冗余策略,提供的可靠性是不一样的。

数据可用性

数据可用性和数据可靠性很容易被混淆,可用性指的是数据是否在线。比如存储集群断电,这段时间数据是不在线,但是数据没有丢失,集群恢复正常后,数据可以正常访问。评估可用性的主要方式是拔服务器电源,再有查看存储的部署组件是否有单点故障的可能。

数据一致性

数据一致性是最难评估的一项,因为大部分场景用户不知道程序写了哪些数据,写到了哪里。该如何评估数据一致性呢?普通的测试工具可以采用fio开启crc校验选项,最好的测试工具就是数据库。如果发生了数据不一致的情况,数据库要么起不来,要么表数据不对。具体的测试用例还要细细斟酌。

存储性能

存储的性能测试很有讲究,块存储和文件存储的侧重点也不一样。

块存储

fio/iozone是两个典型的测试工具,重点测试IOPS,延迟和带宽。以fio为例,测试命令如下:

fio -filename=/dev/sdc -iodepth=${iodepth} -direct=1 -bs=${bs} -size=100% --rw=${iotype} -thread -time_based -runtime=600 -ioengine=${ioengine} -group_reporting -name=fioTest

关注几个主要参数:iodepth,bs,rw和ioengine。

测试IOPS,iodepth=32/64/128,bs=4k/8k,rw=randread/randwrite,ioengine=libaio

测试延迟,iodepth=1,bs=4k/8k,rw=randread/randwrite,ioengine=sync

测试带宽,iodepth=32/64/128,bs=512k/1m,rw=read/write,ioengine=libaio

文件存储

fio/vdbench/mdtest是测试文件系统常用的工具,fio/vdbench用来评估IOPS,延迟和带宽,mdtest评估文件系统元数据性能。以fio和mdtest为例,测试命令如下:

fio -filename=/mnt/yrfs/fio.test -iodepth=1 -direct=1 -bs=${bs} -size=500G --rw=${iotype} -numjobs=${numjobs} -time_based -runtime=600 -ioengine=sync -group_reporting -name=fioTest

与块存储的测试参数有一个很大区别,就是ioengine都是用的sync,用numjobs替换iodepth。

测试IOPS,bs=4k/8k,rw=randread/randwrite,numjobs=32/64

测试延迟,bs=4k/8k,rw=randread/randwrite,numjobs=1

测试带宽,bs=512k/1m,rw=read/write,numjobs=32/64

mdtest是专门针对文件系统元数据性能的测试工具,主要测试指标是creation和stat,需要采用mpirun并发测试:

mpirun --allow-run-as-root -mca btl_openib_allow_ib 1 -host yanrong-node0:${slots},yanrong-node1:${slots},yanrong-node2:${slots} -np ${num_procs} mdtest -C -T -d /mnt/yrfs/mdtest -i 1 -I ${files_per_dir} -z 2 -b 8 -L -F -r -u

存储性能测试不仅仅测试集群正常场景下的指标,还要包含其他场景:

存储容量在70%以上或者文件数量上亿的性能指标节点/磁盘故障后的性能指标扩容过程时的性能指标

容器存储功能

除了存储的核心功能(高可靠/高可用/高性能),对于容器存储,还需要几个额外的功能保证生产环境的稳定可用。

Flexvolume/CSI接口的支持,动态/静态PV的支持存储配额。对于Kubernetes的管理员来说,存储的配额是必须的,否则存储的使用空间会处于不可控状态服务质量(QoS)。如果没有QoS,存储管理员只能期望存储提供其他监控指标,以保证在集群超负荷时,找出xfdmb

万变不离其宗的选择

Kubernetes持久化存储方案的重点在存储和容器支持上。因此首要考虑存储的核心功能和容器的场景支持。综合本文所述,将选择项按优先级列举:

存储的三大核心,高可靠,高可用和高性能业务场景,选择分布式文件存储扩展性,存储能横向扩展,应对业务增长需求可运维性,存储的运维难度不亚于存储的开发,选择运维便捷存储产品成本

Q&A

Q:你好,我们公司采用GlusterFS存储,挂载三块盘,现在遇到高并发写小文件(4KB)吞吐量上不去(5MB/S),请问有什么比较好的监控工具或方法么?谢谢!

A:GlusterFS本身对小文件就很不友好,GlusterFS是针对备份场景设计的,不建议用在小文件场景,如果可以的话,要么程序做优化进行小文件合并,要么选用高性能的分布式文件存储,建议看看Lustre或者YRCloudFile。

Q:我们用的是Ceph分布式存储,目前有一个场景是客户视频存储,而对于持续的写入小文件存在丢帧的现象,经过我们系统级别和底层文件系统调优,加上Ceph参数的设置,勉强性能得改善,但是数据量上来性能会如何也不得而知道了(经过客户裸盘测试,前面用软RAID方式性能还是可以)请问在这方面你有什么建议么?谢谢!我们客户是在特殊的场景下,属于特定机型,而且是5400的sata盘!rbd块存储!还有一个现象就是磁盘利用率不均,这也是影响性能的一个人原因,即便我们在调pg数,也会有这个问题。在额外请教一个问题,bcache可以用内存做缓存么?FlushCache相比,这两个哪个会更好一点?

A:您用的是CephFS还是rbdc因为Ceph在性能上缺失做的还不够,有很多队列,导致延迟很不稳定,这个时候,只能忍了,不过还是建议用Bcache做一层缓存,可以有效缓解性能问题。Crush算法虽然比一致性hash要好很多,但是因为没有元数据,还是很难控制磁盘热点问题。FlushCache已经没有人维护了,Bcache还有团队在维护,所以如果自己没有能力,就选用Bcache。

Q:你好,目前开源在用Rook部署Ceph,Ceph对于块设备存储性能如何?可以提升吗?未来?

A:我们最近也在关注Rook项目,Rook的理念是很好的,但是现在Rook就是Ceph的封装,把Ceph跑到容器中,复用Kubernetes的监控平台。而Ceph的运维复杂度很高,以目前的做法,项目想要做好,难度会非常大。

Q:我看您推荐分布式文件存储,文件系统能满足数据库应用的需求吗?块存储会不会好一些?

A:首先,我推荐的是高性能分布式文件系统。数据库一般对延迟都比较敏感,普通的万兆网络+HDD肯定不行,需要采用SSD,一般能将延迟稳定在毫秒以内,通常能够满足要求。如果对延迟有特别要求,可以采用NVMe + RoCE的方案,即使在大压力下,延迟也能稳定在300微秒以内。

Q:您用的分布式文件存储,不同用户间如何隔离?

A:分布式文件系统有ACL权限控制,也可以加AD/LDAP

Q:请问为什么说块存储不支持RWX?RWX就是指多个节点同时挂载同一块块设备并同时读写吗?很多FC存储都可以做到。

A:传统的SAN要支持RWX,需要ALUA机制,而且这是块级别的多读写,如果要再加上文件系统,是没办法做到的,这需要分布式文件系统来做文件元数据信息同步。

Q:传统SAN支持对同一数据块的并行读写,很多AA阵列都不是用ALUA的,而是多条路径同时有IO,当然要用到多路径软件。相反用ALUA的不是AA阵列。

A:AA阵列解决的是高可用问题,对同一个lun的并发读写,需要trunk级的锁去保证数据一致性,性能不好。

Q:的很多传统商业存储,包括块存储,也都做了CSI相关的插件,是不是如果在容器里跑一些性能要求高的业务,这些商业的块存储比文件存储合适?

A:生产环境中,我强烈建议选用商业存储。至于块存储还是文件存储,要看您的业务场景。首选是商业的文件存储。

Q:请问现在的Kubernetes环境下,海量小文件RWX场景,有什么相对比较好的开源分布式存储解决方案么?

A:开源的分布式文件存储项目中,没有能解决海量小文件的,我在文中已经将主流开源文件系统都分析了一遍,在设计之初,都是针对备份场景或者HPC领域。

Q:请问,为什么说Ceph性能不好,有依据吗?

A:直接用数据说话,我们用NVMe + Ceph + Bluestore测试出来的,延迟在毫秒级以上,而且很不稳定,我们用YRCloudFile + NVMe + RoCE,延迟能50微秒左右,差了几十倍。

Q:Lustre没接触过,性能好吗,和Ceph有对比过吗?

A:网上有很多Lustre的性能指标,在同样的配置下,性能绝对要比Ceph好,不过Lustre全部都是内核态的,容器场景没办法用,而且按照部署以及运维难度非常大。Lustre在超算用的比较广泛。

Q:Lustre只能靠本地磁盘阵列来保证数据冗余么?

A:Lustre本身不提供冗余机制,都是靠本地阵列的,不过EC好像已经在开发计划中了。

Q:(对于小公司)如果不选用商业存储,那么推荐哪款开源实现作为生产存储(可靠,高性能)。我们之前试了NFS发现速度不稳定?

A:国内还是有很多创业公司,也不贵的。存储不像其他项目,存储经不起折腾,一定要用稳定可靠的,Ceph/GlusterFS做了这么久,大家在采购的时候,还是会依托于某家商业公司来做,自己生产环境用开源项目,风险太大了。

Q:GPFS用来做Kubernetes的PV,性能怎么样?

A:用GPFS的话,性能还是有一定保障的,不过GPFS跟Lustre一样,都是带着阵列一起卖的,很贵。

分布式存储排名,分布式存储部署