四⼤开源分布式存储_Kubernetes持久化存储⽅案测试
在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跟NAS类似，提供SCSI/iSCSI协议，后端是磁盘阵列
SDS是⼀种泛指，包括分布式NAS(并⾏⽂件系统)，ServerSAN等
从应⽤场景⾓度，存储分为⽂件存储(Posix/MPI)，块存储(iSCSI/Qemu)和对象存储(S3/Swift)三⼤类。
Kubernetes是如何给存储定义和分类呢？Kubernetes中跟存储相关的概念有PersistentVolume (PV)和
PersistentVolumeClaim(PVC)，PV⼜分为静态PV和动态PV。静态PV⽅式如下：
动态PV需要引⼊StorageClass的概念，使⽤⽅式如下：
社区列举出PersistentVolume的in-tree Plugin，如下图所⽰。从图中可以看到，Kubernetes通过访问模式给存储分为三⼤
类，RWO/ROX/RWX。这种分类将原有的存储概念混淆，其中包含存储协议，存储开源产品，存储商业产品，公有云存储产品等等。
如何将Kubernetes中的分类和熟知的存储概念对应起来呢？本⽂选择将其和应⽤场景进⾏类⽐。
1. 块存储通常只⽀持RWO，⽐如AWSElasticBlockStore，AzureDisk，有些产品能做到⽀持ROX，⽐如
GCEPersistentDisk，RBD，ScaleIO等
2. ⽂件存储(分布式⽂件系统)⽀持RWO/ROX/RWX三种模式，⽐如CephFS，GlusterFS和AzureFile
3. 对象存储不需要PV/PVC来做资源抽象，应⽤可以直接访问和使⽤
这⾥不得不吐槽Kubernetes社区前期对存储层的抽象，⼀个字——乱，把开源项⽬和商业项⽬都纳⼊进来。现在社区已经意识到问题并设计了统⼀的存储接⼝层——Flexvolume/CSI。⽬前来看，CSI将会是Kubernetes的主流，做了完整的存储抽象层。
多种多样的应⽤场景
介绍完存储概念之后，选择哪种存储仍然悬⽽未决。这个时候，请问⾃⼰⼀个问题，业务是什么类型？选择合适的存储，⼀定要清楚⾃⼰的业务对存储的需求。本⽂整理了使⽤容器存储的场景及其特点。
配置
⽆论集配置信息还是应⽤配置信息，其特点是并发访问，也就是前边提到的ROX/RWX，在不同集或者不同节点，都能够访问同样的配置⽂件，分布式⽂件存储是最优选择。
⽇志
在容器场景中，⽇志是很重要的⼀部分内容，其特点是⾼吞吐，有可能会产⽣⼤量⼩⽂件。如果有⽇志分析场景，还会有⼤量并发读操作。分布式⽂件存储是最优选择。
应⽤(数据库/消息队列/⼤数据)
Kafka，MySQL，Cassandra，PostgreSQL，ElasticSearch，HDFS等应⽤，本⾝具备了存储数据的能⼒，对底层存储的要求就是⾼IOPS，低延迟。底层存储最好有数据冗余机制，上层应⽤就可以避免复杂的故障和恢复处理。以HDFS为例，当某个datanode节点掉线后，原有逻辑中，会选择启动新的datanode，触发恢复逻辑，完成数据副本补全，这段时间会⽐较长，⽽且对业务影响也⽐较⼤。如果底层存储有副本机制，HDFS集就可以设置为单副本，datanode节点掉线后，启动新的datanode，挂载原有的pv，集恢复正常，对业务的影响缩短为秒级。⾼性能分布式⽂件存储和⾼性能分布式块存储是最优选择。
备份
应⽤数据的备份或者数据库的备份，其特点是⾼吞吐，数据量⼤，低成本。⽂件存储和对象存储最优。
综合应⽤场景，⾼性能⽂件存储是最优选择。
形形⾊⾊的存储产品
市⾯上的存储产品种类繁多，但是对于容器场景，主要集中在4种⽅案：分布式⽂件存储，分布式块存储，Local-Disk和传统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
关注⼏个主要参数：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/st -iodepth=1 -direct=1 -bs=${bs} -size=500G --rw=${iotype} -numjobs=${numjobs} -time_based -runtime=600 -ioengine=sync 与块存储的测试参数有⼀个很⼤区别，就是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} md 存储性能测试不仅仅测试集正常场景下的指标，还要包含其他场景：
1. 存储容量在70%以上或者⽂件数量上亿的性能指标
2. 节点/磁盘故障后的性能指标
3. 扩容过程时的性能指标
容器存储功能
除了存储的核⼼功能(⾼可靠/⾼可⽤/⾼性能)，对于容器存储，还需要⼏个额外的功能保证⽣产环境的稳定可⽤。
1. Flexvolume/CSI接⼝的⽀持，动态/静态PV的⽀持
2. 存储配额。对于Kubernetes的管理员来说，存储的配额是必须的，否则存储的使⽤空间会处于不可控状态
3. 服务质量(QoS)。如果没有QoS，存储管理员只能期望存储提供其他监控指标，以保证在集超负荷时，出罪魁祸⾸
万变不离其宗的选择
Kubernetes持久化存储⽅案的重点在存储和容器⽀持上。因此⾸要考虑存储的核⼼功能和容器的场景⽀持。综合本⽂所述，将选择项按优
先级列举：
1. 存储的三⼤核⼼，⾼可靠，⾼可⽤和⾼性能
2. 业务场景，选择分布式⽂件存储
3. 扩展性，存储能横向扩展，应对业务增长需求
4. 可运维性，存储的运维难度不亚于存储的开发，选择运维便捷存储产品
5. 成本
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发现速度不稳定？

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。