🐇 Pure Storage简单介绍
在日常的工作和项目中，笔者发现即使是IT行业的“老法师”似乎也对Pure Storage“不太熟悉”，人们耳熟能详的，依旧是国内外的E记、H记等产品，但对于Pure Storage的名字都显得有点陌生。实际上Pure Storage的数据存储是“相当能打”的存在，已连续九年稳居Gartner首要存储领导者象限。
上图是2022年Gartner魔力象限对“Primary Storage”以及“DFS & Object Storage”的排名，可以看到Pure Storage同时位列两个方向的第一象限。想要查阅Gartner报告全文，可以访问以下两个链接：
https://www.purestorage.com/resources/gartner-magic-quadrant-primary-storage.html
从笔者实际的项目经历和这些年来的感受来看，自从2015年各大厂商推出超融合解决方案以来，传统存储一直面临着“被替换”的危险，至少人们喜欢这么“危言耸听”。但笔者个人一直以来的想法是传统存储和超融合存储并非是“非此即彼”的关系，在应对客户的挑战和痛点的时候，两个对立的概念完全可以整合成一个兼容并包的解决方案来满足用户的需求。借用Pure Storage提出的“现代化数据体验”理念，用户所关心的绝对不是存储的形式和类别，而是其包括性能、稳定、安全、可靠等诸多要素在内的“使用和管理体验”。事实或许也真的和笔者所认为的这般，传统存储并没有消亡，用户依旧需要其来承载关键业务。但客观公正地说，在面对超融合解决方案和国内传统存储厂商产品品质不断提升的双重挑战之下，一些老牌的存储厂商和产品的确面临着不小的压力和挑战。笔者看过Pure Storage的一个数据：全球外置存储的复合增长率在过去几年里一直处于相对疲软的状态，不能说负增长或者无增长，只是可怜的一位数增长率难免有一点“食之无肉，弃之有味”的苍凉；而Pure Storage在过去几年(好像是六年)能够保持40%以上的增长已经是相当不错的成绩。这些信息各位有兴趣的，可以访问Pure Storage的官网以便于了解更多。
再来走马观花介绍一下Pure Storage的产品，包括“现代化应用”、“现代化运维”和“现代化基础架构”三个大的板块。在笔者的Homelab中，已经完成了面向现代化应用的管理平台Portworx on VMware Tanzu Kuberetes Grid的部署，现在还需要抽空找些测试用例来完成公众号内容的取材，完成后将分享给大家。简单来说，Portworx能帮助管理员在管理和使用现代化工作负载，尤其是有状态的容器服务时，更轻松安全地完成数据备份、迁移等工作。除此以外，常用常新的Evergreen常青服务也是用户非常感兴趣和喜欢的功能。我们知道，不少用户存在“业务不能停机”的场景，比如制造业的CIM系统、银行的交易系统等等，对于因为存储容量达到极限需要更换控制器来满足更大存储空间这类需求来说，也都是非常巨大的挑战。常青服务能够满足用户在不停机的情况下，仅更换控制器且不用进行数据迁移和复制就能实现控制器更新换代的要求，这是许多用户最终选择Pure Storage产品很重要的决策因素。不过要说到PureStorage最核心的产品，还是现代化基础架构板块的FlashArray以及FlashBlade产品。
笔者的环境拥有三种类型的存储，分别是VMware vSAN超融合数据存储、Qnap提供的NFS文件存储以及FlashArray //X20R3提供的SAN存储。//X20是全NVME盘高性能数据存储，得益于Pure Storage专利的DirectFlash技术通常被选为承载企业核心业务的首要存储来使用，且出色的数据压缩比和盘柜设计能够极大地减少机柜空间的占用，受到了许多用户的喜爱。本篇分享中的//C40同样是Pure Storage FlashArray高性能数据存储产品，相比//X系列来说，//C系列同样采用全NVMe硬盘，且拥有更大的存储空间和更低的成本，同样是企业Primary Storage和Secondary Storage的选择。
🐇 VDBENCH性能测试结果分享
笔者使用vdbench脚本对//C40进行了各种场景下的简单测试，通过本章节与各位看官分享一二。不过因为笔者环境条件实在有限，无法测试出//C40的“极限”所在，如果有朋友具备这样的条件可以在进行测试后微信私聊分享
一下。具体的测试环境和测试步骤，可点击下方链接查看；实际上笔者今后所有公众号内容的“详细步骤”都将分享在位于华为云的笔者小站上，而一些总结性的归纳和经验将在微信公众号中呈现给各位。http://nelliemylove.cn/nelliemylove/index.php/2022/12/18/vdbench_c40/
使用的环境依旧是2根8Gbps的FC链路，下面给出笔者的实验结果：
🐇1x01.预测试-单台虚拟机(16vCPU 32GB 裸磁盘映射 8K 100%读)
注意：本用例为了测试验证在笔者环境vdbench需要使用的测试虚拟机数量，因此每个脚本用例测试时间为30s，采用“目视平均值”作为结果记录。
可以看到在单台vdbench测试服务器（虚拟机）的场景下，最多8块虚拟机磁盘（裸磁盘）已经是极限。
🐇1x02.预测试-两台虚拟机(16vCPU 32GB 裸磁盘映射 8K 100%读)
注意：本用例同样为了测试验证在笔者环境vdbench需要使用的测试虚拟机数量，因此每个脚本用例测试时间为30s，采用“目视平均值”作为结果记录。
经过测试，确认在笔者环境下8+4合计12台硬盘已经达到了可用带宽的极限，为了确保vdbench测试虚拟机的CPU运行在相对良好的环境，需要设计采用2台虚拟机同时运行vdbench脚本。
因为笔者环境的硬件资源实在有限，所以不得不采用预测试的方法反复进行调试，确保每一次测试脚本运行期间都能在尽可能少使用资源的情况下，得到令自己满意的测试数据。
🐇1x03.预测试-测试脚本
为了更好的提供参考，下面给出笔者的vdbench测试用脚本：
hd=default,vdbench=/root/vdbench,user=root,shell=ssh hd=host1,system=172.20.11.150 hd=host2,system=172.20.11.151 hd=host3,system=172.20.11.152 hd=host4,system=172.20.11.153 sd=default,openflags=directio,threads=24 sd=sdb1,host=host1,lun=/dev/sdb sd=sdb2,host=host1,lun=/dev/sdc sd=sdb3,host=host1,lun=/dev/sdd sd=sdb4,host=host1,lun=/dev/sde sd=sdb5,host=host1,lun=/dev/sdf sd=sdb6,host=host1,lun=/dev/sdg sd=sdb7,host=host1,lun=/dev/sdh sd=sdb8,host=host1,lun=/dev/sdi #sd=sdb9,host=host1,lun=/dev/sdj #sd=sdb10,host=host1,lun=/dev/sdk sd=sdb11,host=host2,lun=/dev/sdb sd=sdb12,host=host2,lun=/dev/sdc sd=sdb13,host=host2,lun=/dev/sdd sd=sdb14,host=host2,lun=/dev/sde sd=sdb15,host=host2,lun=/dev/sdf sd=sdb16,host=host2,lun=/dev/sdg sd=sdb17,host=host2,lun=/dev/sdh sd=sdb18,host=host2,lun=/dev/sdi #sd=sdb19,host=host2,lun=/dev/sdj #sd=sdb20,host=host2,lun=/dev/sdk sd=sdb21,host=host3,lun=/dev/sdb sd=sdb22,host=host3,lun=/dev/sdc sd=sdb23,host=host3,lun=/dev/sdd sd=sdb24,host=host3,lun=/dev/sde sd=sdb25,host=host3,lun=/dev/sdf sd=sdb26,host=host3,lun=/dev/sdg sd=sdb27,host=host3,lun=/dev/sdh sd=sdb28,host=host3,lun=/dev/sdi #sd=sdb29,host=host3,lun=/dev/sdj #sd=sdb30,host=host3,lun=/dev/sdk sd=sdb31,host=host4,lun=/dev/sdb sd=sdb32,host=host4,lun=/dev/sdc sd=sdb33,host=host4,lun=/dev/sdd sd=sdb34,host=host4,lun=/dev/sde sd=sdb35,host=host4,lun=/dev/sdf sd=sdb36,host=host4,lun=/dev/sdg sd=sdb37,host=host4,lun=/dev/sdh sd=sdb38,host=host4,lun=/dev/sdi #sd=sdb39,host=host4,lun=/dev/sdj #sd=sdb40,host=host4,lun=/dev/sdk wd=wd1,sd=sd*,seekpct=random,rdpct=100,xfersize=8k rd=rd1,wd=wd1,iorate=max,warmup=10,elapsed=600,interval=1
🐇1x11.性能测试-裸磁盘映射 8K 随机读写 100%读 600样本
注意：笔者在测试期间设置C40的所有存储卷均只提供给虚拟机所在的ESXi宿主机，同时在ESXi宿主机上除了vCLS虚拟机、TKGs主管集群的Supervisor虚拟机以及三台TKC虚拟机外，没有其他电源处于开启状态的虚拟机。
经过测试，平均IOPS为199020，吞吐为1554.85MBps；平均读延迟<1ms。
🐇1x12.性能测试-裸磁盘映射 8K 随机读写 70%读30%写 600样本
经过测试，在设置平均IOPS为167899，吞吐为1311.71MBps；平均读延迟<5ms，平均写延迟<2ms。
🐇1x13.性能测试-裸磁盘映射 8K 随机读写 50%读50%写 600样本
经过测试，平均IOPS为149190，吞吐为1165.65MBps；平均读延迟<1ms，平均写延迟<1ms，队列延迟<3ms。
🐇1x21.验证测试-四台虚拟机(16vCPU 32GB 裸磁盘映射 16K 100%读)
注意：本用例为了测试笔者环境SAN网络能够占用的最大带宽而进行压力测试。
经过测试，确认在笔者环境下差不多78%的有效带宽已经是极限。
🐇1x22.验证测试-四台虚拟机(16vCPU 32GB 裸磁盘映射 4K 100%读)
注意：本用例为了测试笔者环境能够达到的最大IOPS而进行压力测试。
经过测试，怀疑在笔者环境下20万IOPS已经是极限了；为了验证这一点，笔者还需要做两个验证测试。🐇1x23.验证测试-四台虚拟机(16vCPU 32GB 裸磁盘映射 8K 100%读)
注意：本用例为了测试笔者单台服务器的极限IOPS而进行压力测试。
经过测试，可以确认笔者环境的单台服务器IOPS极限在20万IOPS左右。
🐇1x31.验证测试-多台服务器(裸磁盘映射 4K 100%读)
注意：本用例为了测试在笔者环境中，多台服务器同时并发测试可以达到的最大IOPS数值。
通过表格显示的实验数据，不难看出笔者环境中对于4K 100%读的极限IOPS大约在33万左右，延迟也始终低于1ms。
🐇 对于测试结果的一些想法
就笔者环境来说，这已经是一个非常“简易”的环境。本身将融合交换机FI以“FC交换机模式”直连外置存储就是小型规模的数据中心才会使用的场景。从实验数据来看，8K负载大小的测试还是可以反映出一些Pure Storage FlashArray C40的性能的。就33万IOPS来说，相信肯定没有达到C40的最大性能，问题是除去环境限制是否还会有其他影响实验结果的因素？
就这个问题，笔者猜测可能会影响测试结果的选项：
- C40已经采用全NVMe磁盘，但在Direct Flash模块的统一IO调度和延迟管理之下，磁盘数量的多少可能会影响性能；磁盘数量越多，应该也能提升总体的IOPS；
- 笔者采用的FI6248最高支持FC接口的速率是8Gbps，如果能采用SAN交换机并且将全部C40的FC接口使用上，应该可以提升总体带宽和总体的IOPS；
- 抛开实际的应用场景或者负载来谈性能一直就是一件被工程师诟病“耍流氓”的事情，vdbench脚本在修改一些参数后，可能会影响测试结果。但就上述猜想来说，可能短期内也没有机会进行验证测试了，毕竟环境实在太有限。写在最后
笔者之前基本不碰传统存储，从玩转Cisco协作产品到后来的UCS融合、Hyperflex超融合产品，再后来因为“无心插柳”接触到了Citrix虚拟桌面，紧接着是围绕着VMware云与数据中心的一系列产品，可见一直没有好好解除过传统存储领域。但随着技术的不断革新、用户需求的不断变化，工程师每天也会面临对自己的新挑战。笔者在未来的一年除了会定期在公众号分享VMware的干货外，也会在公众号和个人博客分享华为云、Pure Storage等一些自己接触和学习的“新领域”心得体会。这次的C40测试报告就权且当时为明年开一个头。在学习过程中笔者也非常感谢Westcon的Sunny昝姐、邹卫祥邹老师、Tarls李哥对自己的帮助和鼓励，得益于良师益友的鞭策才能让笔者持续在技术的道路上越走越自信，谢谢大家。
