存储系统的性能管理是运维的必修课，其核心工作是性能分析与优化，从存储系统架构的规划设计开始，到部署实施，再到IT系统的投产运维过程，会贯穿整个IT系统的生命周期。存储系统可分为SAN存储、NAS存储以及分布式存储等方案，不同的存储方案对应不同的存储系统架构和存储IO数据流，也分别对应着不同应用场景下的最佳实践。存储IO数据流与上层服务器对接，其性能指标又主要表现为读写IO延时、吞吐量、IO大小等等。
存储系统的性能分析与优化工作是一项长期、复杂而重要的工作，需要明晰存储性能优化目标，做好详细性能分析，并制定阶段性的优化方案和验证方案，以确保存储性能优化工作的持续开展。
近日社区组织线上交流，重点围绕存储系统性能分析与优化过程中的若干难点问题，进行分享探讨，旨在为同业在此类项目规划、建设、管理过程中提供一些启示和帮助。
以下是此次探讨中大家研讨关注的典型问题及嘉宾解答。
一、存储选型问题
1.存储选型过程中，不同性能指标的区别，选型的重点是什么？
cpc1989某保险公司存储工程师：
存储性能分析主要是IOPS、吞吐量（Throughput）、延时（Latency）这三大指标。
而存储选型过程需要贴合应用场景，对性能稳定性要求较高、响应时间敏感的场景，如一些核心交易类数据库，需要更关注存储的延时指标；对数据量增长较快、海量数据分析类的场景，如数据处理类应用，需要关注存储的IOPS和吞吐量指标；对于其他一些性能不敏感、数据量不大的场景，存储的性能往往不是选型的关键因素，只需要满足性能需求，可更多关注存储的性价比等其他因素
2.运行数据库，集中存储和分布式存储，I/O方面谁更强？
spgoall和祐国际医院信息管理部部长：
具体需要看是哪种数据库，哪个版本的，以及数据库的设计都会影响IO性能，和集中存储和分布式存储关系不大。要做具体测试才知道实际的性能
Dell_zhangcan戴尔科技架构师：
理论上传统数据库在集中存储上IO更强，但医院的主流数据库只有Oracle、SQL和Intersystem公司的Cache三种。这三种数据库在戴尔科技的集中式存储和分布式存储上的IO表现都是一样的。没有谁更强一说，只有谁更适合医院的实际使用环境。
czhe医疗行业：
对于医院业务系统使用的数据库用集中存储延时相对来讲要小一些，集中存储中数据只要写入一个磁盘阵列就算成功了，分布式存储中是写入大部分的节点才算成功，如果写入全部节点IO性能有影响，写入少量节点即是写入失败。分布式存储更适合于大数据量、高并发量，扩展能力更好一些。
跳出三界外小艾公司架构师：
都不强。最强的是用数据库管理的NVMe NAND。
3.虚拟化到底适合用什么样的存储？
cpc1989某保险公司存储工程师：
一般来说虚拟化还是主要用于一些轻量级应用，对IO性能并不敏感，那么选择的范围就比较大，只要稳定可靠就行；如果用来跑一些对延时要求比较高的数据库应用，全闪存的SAN存储延时低，小IO的情况下，IOPS也能跑的很高；如果是用来跑一些数据处理类IO比较大的数据库，分布式存储性价比是不错的，最好评估测试一下了，性能瓶颈可能不在存储端，主机或网络层面的压力也很大。
4.集中式存储和分布式存储在读写性能上的随着存储节点增多时是否会有较大的差异？
xiaofu福建医科大学附属第二医院高级工程师：
只能这么说分布式存储达到一定规模性能会超过轻松超过传统存储，大量节点，结合适当的数据分布策略，可以达到到非常高的聚合带宽。传统的集中性存储都会有性能瓶颈，一旦达到极限在扩性能不会改变甚至降低。当然分布式也不是说可以水平线性提升性能的也是有对应瓶颈
Dell_zhangcan戴尔科技架构师：
在理论上和跑分测试上有一定的差异，将来如果都采用傲腾介质，差异会更小。在医院应用实践上几乎没有差异，因为应用的规模根本无法跑出差异。
5.传统的SAN存储和分布式存储在IO上的对比？
目前X86架构的性能越来越强大。这也促进了分布式存储的发展，传统的观念中。还是觉得SAN存储拥有更好的IO性能。分布式有更灵活的架构。不过现在随着硬件的提升。这两种方式之间的理论性能差距究竟有多大呢。有大神做过详细的对比吗？
fanyqing厦门银行系统架构师：
两类存储因架构不同，各有各的特点，适用于不同的业务场景，不能笼统进行比较。
首先我们来看一下两类存储的特点：
1、SAN存储
性能方面：采用集中式架构，当存储容量达到一定规模时，会存在性能瓶颈；扩展性方面：SAN存储扩展采用扩展柜方式，扩展能力有限；稳定性方面：SAN存储采用专用的软、硬件，产品投入市场早，成熟度高；此外，从成本方面考虑，通常传统的SAN存储比分布式存储成本高。
2、分布式存储：
性能方面：因采用分布式架构，性能会随着集群的扩展而提高；扩展性方面：采用集群方式，扩展能力强；稳定性方面；采用X86+分布式存储软件方式，近年投入市场，稳定性不如传统存储，有待市场进一步考验。
因此，基于上述特点，在选择存储类型时，要根据业务场景。比如传统关系型数据库，通常用于存储传统业务系统的业务数据，对存储的性能要求较高，但对存储的容量和扩展性要求相对较小，因此，我们一般采用传统的SAN存储（块存储）；但虚拟化、VDI、容器等，虽然也采用块存储，在不是很关注性能的情况下，基于成本考虑，可以采用分布式存储的块存储；其他像网盘、音视频、备份数据等，对存储介质的读写性能要求不高，但要求提供海量的存储空间，并具备良好的扩展性，可以考虑采用分布式存储中的对象存储或文件存储。
潘延晟系统工程师：
其实在传统环境里面这两种架构的应用还是挺清晰的。不过现在随着X86性能的不断加强。我感觉好像在一些行业里出现了两种选择均可的情况。在这种情况下就有些不太确定如何去选择。
在以往的情景中。x86的性能没有那么高。业务的分界也相对明显。可能数据库我会用SAN。虚拟化搭建的中间件集群我会用分布式。但随着技术的不断成熟。没有特殊业务的需求时好像很难去区分两种架构的需求。
用过vSAN，也用过超融合。对业务要求不够严苛的环境里我觉得都能满足。对于中小企业来说。可能就会面临一个两难的选择。到底是san还是分布式。以什么作为理论基础。很多中小企业也的业务场景可能会出现两者皆可的情况。那么对企业，我觉得应该有更多的评判标准，技术储备，资金，业务的窗口期以及特殊性等等多方面考量。目前在我来看。似乎单纯从性能上还不足以帮助很多中小企业做出选择。
huijx某银行系统运维工程师：
IO性能还是需要针对具体的案例来进行说话，不同的测试用例，两个存储得出完全相反的结果也不是不可能的。同样的测试用例，同样的存储，节点数/磁盘柜数量也会影响IO性能。所有谈论理论性能意义不大。
anonymous：
现在分布式存储的IO能做到非常高，随便堆一堆就很轻松的几百万的IOPS，对于传统的SAN存储来说，需要高配甚至顶配的高端存储来对标，但是存储不仅仅是IOPS这一项指标。主要还是要看应用，如果是核心的业务，还是要上传统的SAN，主要还是要体现在稳定，安全，包括运维和容灾的体系架构，都已经形成了很好的优势，这是目前分布式存储不可替代的，即便成本很高，大家还是选择传统稳定的SAN。一些新兴业务，边缘业务，可以选择分布式存储，低廉的价格，很好的扩展性，包括IOPS，目前还没有听说谁家在核心业务上分布式存储的。
王巧雷sino-bridge系统工程师：
个人觉得这个还是得看使用场景吧，否则没有一个标准，没有太大的可比性。
传统的SAN存储在结构化数据这块市场占有率一直还是挺高的，比如作为数据库存储。分布式存储也有自己擅长的方面，比如大规模的并行数据处理等，这都是近些年来逐渐发展起来的，传统的SAN存储可能也能做，但成本就不合适了。两者都有各自擅长的领域，还是看具体需求吧
孙伟光中国金融电子化公司IT顾问：
这种实际对比的意义不大，各自应用场景都不一样。分布式存储没出现之前，还不是传统存储承受了一切。分布式存储的出现未必是传统的存储没落亦或是产品跟不上时代脚步。它更是这个传统SAN存储的有益补充，并非对立。互联网架构，开放式架构成就了分布式存储，但是分布式存储也不是万能的，他也解决不了当下所有的应用场景，两者互相补充。存储的出现一方面解决了性能问题，他的高可用性不应该被忽视，数据是企业的核心生命力，性能再好的存储丢一次数据，再好的存储性能，也终会被企业抛弃。
赵海技术经理：
首先，我觉得传统SAN存储之所以还是很多企业的主流存储是因为它的稳定性和安全性，性能并不是传统SAN存储最大的优势。
另外，本身对存储性能的衡量是有很多指标的，这需要POC说话。但是我们可以从原理上来解读一下他们读写的差异。对于传统SAN存储来讲，它的读写以Blcok为单位，通过盘头的元数据来记录Block的映射及变化。而分布式存储会有几种架构：
1.以对象存储为底层存储载体，以分布式协同算法来组织节点关系，以上层接口转换的方式来对接应用读写，可以提供Block、File、S3等各种存储接口。
2.以GFS为基本原型，底层为文件系统模式的存储结构，同样上层进行各种包装之后形成的可以提供各类存储服务的统一分布式存储。
从存储架构和组织原理上来讲，其实他们是有着各自擅长的存储场景的。比如对于结构化的表数据的读写来讲，其实直接的Block存储更适合应用的读写控制；对于以健值方式组织的数据结构，似乎更适合对象存储形成的分布式存储架构，而以文件为主的数据场景，如果不能以对象方式重构，那么文件系统架构的分布式存储似乎更适合。
总而言之，不同的存储有不同的优势和劣势，只要我们的应用场景选对了，那就是最优的选型。
cpc1989某保险公司存储工程师：
个人的一点看法：性能离不开应用场景，比如OLTP类应用，最重要的性能指标就是延时，其次才是IOPS，存储延时低，IO响应时间就短，数据库的并发就可以比较高，否则可能出现数据库锁等待，并发性能就出现了问题，除非再去应用逻辑上去优化；而一些大量的数据处理类应用，最重要的性能指标是吞吐量，吞吐量高，数据处理任务就能更短时间完成。
SAN存储的优势就是IO短平快，存储延时低，但其架构设计中吞吐量会有瓶颈存在的，但小IO的情况下，最高端的存储也是能超过千万IOPS，IO延时甚至小于0.1ms；分布式存储的优势是扩展性强，大容量高吞吐高IOPS，但是IO路径长，存储架构设计就决定了IO延时会是软肋，即使通过各种数据缓存机制来优化读写的延时，但性能稳定性还是存在隐患，会有性能抖动。
跳出三界外小艾公司架构师：
这个问题的提问出发点就有问题。
存储的性能（IOPS）根源在盘。什么盘？机械硬盘还是SATA SSD或者NVME SSD？多少个盘？这才是存储的IOPS的主要矛盾。FC-SAN或者分布式存储连前三的因素都排不上。
给你举个例，EMC VNX 5100配6个SSD，配120个10k rpm HDD。VNX 5700配120个10k rpm HDD。谁的性能高？我对DELL EMC现在的产品不熟悉了。你还可以选配个现在DELL EMC和VNX 5700同档次的产品，也配120个10k rpm HDD。谁的IOPS高？你要把这个问题搞明白了，这个问题你就搞明白一半了。然后再谈FC-SAN和分布式的性能区别。
用VNX 5100和5700举例。是因为当年这两款都是IDC BAND 4和BAND 7的销量冠军。
张文正dcits系统工程师：
这个还是根据应用场景区分比较合适
SAN存储一般集中存储，集中架构，技术成熟度高，硬件成本比较高，扩展能力有限，但目前闪存产品比较多，IOPS也很高，集中管理维护方便；
分布式存储一般采用x86架构，扩展能力强，最重要是地域访问优化特性，也是采用统一的命名空间管理，后面多台存储服务器组成，采用高速缓存连接，扩展及其方便，而且提供相应的HTTP/RESTful/API接口,适用于海量存储和对象存储。
6.SAN、NAS、分布式存储等不同存储方案的性能分析对比，最佳实践有哪些？
cpc1989某保险公司存储工程师：
SAN存储方案是基于存储块的集中式架构，适合用于高并发、低延时的小IO的OLTP场景，性能稳定性高，但扩展性差，大数据量的数据处理效率不高；
NAS存储方案，适配性强，管理简单，通过以太网访问模式走NFS/CIFS协议，提供了广泛兼容性易用性的共享能力，但采用树状目录结构的文件系统，在海量文件的情况下，访问效率较低，适宜于性能需求不高的场景；
分布式存储方案的架构复杂性较高，IO路径长，性能稳定性稍差，但扩展性好，适宜于大IO的海量数据分析场景或对延时敏感度不是特别高的场景。
二、性能指标及性能监控问题
1.怎么快速的测出裸金属的各项性能指标？
服务器万兆网卡绑定了bond，但是实际使用过程中使用时发现网络速率未达到万兆网卡性能问题；另外在对服务器进行虚拟化时，系统管理员反馈存在磁盘IO存在问题，所以现需要对新上架的服务器的网络、磁盘、CPU进行测试，看有没有比较快速的办法处理？
cpc1989某保险公司存储工程师：
对服务器网络，磁盘，CPU的性能POC测试，一般都是要依赖于设备上架部署，安装系统以及操作系统层面的测试工具，并没什么捷径，但也可以得出一个性能基线，然后虚拟化后同样的性能测试方法，又是另外一个性能基线。
另外网卡或磁盘IO的性能问题存在很多性能干扰因素，包括系统参数的配置、IO路径中的资源热点或争用，当然也可能存在硬件问题，还可能存在规划设计与用户的性能需求并不匹配的情况，还是要有更多的性能数据来支持性能分析与优化
2.对象存储性能监控指标有哪些？
随着对象存储越来越普及，面临的运维压力随之而来，在块存储和文件存储时代可以基于三大黄金指标（iops、带宽、时延），但是对象存储没有这类直接的指标，想问对象存储如何做到通过性能数据，直观看到存储状态？
cpc1989某保险公司存储工程师：
个人的一些看法，存储性能数据本质上就是存储服务能力的一种量化，对象存储包括元数据和普通数据对象，对外提供数据对象的存储服务。那么数据对象的get、put等操作可以类比块存储的读或者写IO，IOPS，带宽，时延也就可以类比，这些性能数据在一定程度上就能描述对象存储系统的服务水平。
当然，从性能监控角度来看的话，这三大指标在特定场景下，有些性能指标参考的意义并不是最重要的，这需要俯瞰全局，做整体架构和全链路分析，发掘更多存储系统相关组件的性能数据，结合日常运维经验和故障场景去数据分析。
3.存储系统性能监控中的性能指标如何设置？
荣重实XSKY技术总监：
性能指标最好设计成综合维度，覆盖从客户端到应用端、网络端和存储端，中间可能涵盖服务器、网络及存储等硬件和各级软件；
定义一套存储的性能指标，可以根据产品对应官方提供的性能参数，推算出一份理论值，再通过实际设备压力测试得到一份测试值，配合实际使用场景一般所处于的压力，估算出一份合理使用值；
对于一套存储本身，可以监控其CPU、内存、硬盘和网络的使用情况，确认其使用的负载压力。
4.如何主动发现存储问题？
存储一旦出问题对业务系统将是致命的灾难，如何主动发现问题。
wuyandekuse icss系统工程师：
最好有冗余
有条件用自动运维软件检测
加强日常巡检，日志保存。
JanXC nec系统架构师：
还是应该加强监控的。结合存储的厂商和自研的脚本，添加监控，进行主动监控。
cpc1989某保险公司存储工程师：
硬件方面，硬件监控、日常巡检不可或缺，由于存储冗余机制，硬件故障不一定会影响业务运行，但及时故障处理是必须的；
性能方面，系统上线前，有条件时要模拟应用场景可开展性能测试，性能基线数据是后期实际运行过程中存储性能瓶颈的参考，也是扩容和架构调整时的参考，另外性能监控也要补上；
容量方面，定期评估存储容量，分析容量使用趋势，提前准备。
数据保护方面，定期数据备份最为重要，对突发情况有应急手段。
keller01系统工程师：
做好日常维护，每天登存储对设备运行状态进行分析。到官网查找新版本的微码，尽可能保证微码版本较新。
三、存储性能瓶颈分析与优化
1.分布式存储对Linux系统swap分区的影响？
cpc1989某保险公司存储工程师：
存储性能层面，swap是虚拟内存，对于存储系统来说，内存也是数据缓存的一种，分为存储节点的内存缓存和客户端本地缓存，通过数据缓存来提供存储IO性能。禁用swap可能是为了避免swap引起的性能抖动。
服务器层面，swap的设计是通过牺牲性能来换取系统或进程安全，而启用swap再配合监控来保障业务连续性。
jakeyyu三甲医院系统架构师：
swap是虚拟内存，应对物理内存不够用，对于虚拟化平台的物理内存资源集中使用调度的角度看，物理内存的使用对于某一进程而言很少会出现不足的情况，反而此时使用swap会使得存储抖动现象引起整个系统性能的下降。
zzouqb光大银行信息科技部系统运维工程师：
用到swap才会有一些影响，内存充足的情况下一般是不会用swap的,有些numa node memory使用不均衡，可能在内存够用的情况下也会用到swap。
正常情况下真到了内存不够了，会把匿名内存交换到swap中转一下，空出点内存，没有swap就只能kill进程了。这个就是没有swap的情况下可能的影响了。
所以做不做swap你看着办。
回到这个问题有没有影响做个压测不就完事了。
沈天真浪潮商用机器售前支持：
是的；swap会影响IO性能，swap启动后，其实也就是把磁盘空间当内存用，很明显占用了磁盘I/O的时间和资源，相当于磁盘一心二用了。
2.超融合上分布式存储的机制问题？
关注到现在HCI市场很火，也出现诸多分布式存储产品，了解各家HCI内的分布式存储方案后，有一个分布式存储机制问题：
超融合上的分布式存储玩法大概有两种，一种是完全的分布式，比如FusionStorage，数据完全切片打散，多节点读多节点写；另一种类似Nutanix，有IO本地化这种机制，读优先从本节点读，写由多节点写。这样就想到两个问题：
1，FusionStorage这类完全分布式的做法，利用多节点性能，那是不是有很大部分资源消耗去保障分布式数据的强一致性？
2，对于Nutanix分布式存储，在读场景下还是受制于单节点的性能吗？感觉没体现分布式的优势。
cpc1989某保险公司存储工程师：
数据完全打散读写的方式IO要经过网络传输时延，IO时延增加，更适合于大IO、高带宽的应用场景，如果用于IO延时要求高的场景，需要优化网络传输、磁盘读写等时延。
读优先从本节点读这种机制是通过单节点本地内存，本地SSD做读缓存，读IO的时延大大降低，适合小IO、低带宽、读比例较高的应用场景。
3.各类型存储系统的性能分析和优化关注哪些方面？
大概归纳为以下两个问题：
1，各类存储系统（SAN/NAS/OBS）在整体性能表现上，应侧重关注哪些指标？各指标高低含义代表什么呢？
2，在SAN/NAS/OBS三类存储上，如何进行规划存储的使用规范，有什么建议，比如一些典型问题：块存储LUN大小和块大小？NAS海量文件应对方式？OBS对结构化和非结构化数据存取优化建议？
cpc1989某保险公司存储工程师：
1.个人看法是，存储性能就是存储对外的服务能力，SAN存储对应于存储块的读写，NAS对应于文件的创建、读写等操作，OBS对应于对象的get、put等操作，如何评价存储性能高低，关键是看你的使用场景的性能关注点，可能是要求高并发高带宽，或者高并发低延时。
2.块存储LUN大小设置还是看上层主机或应用的需求，一般lun小一些，对应的lun数量会多一些，IO并发更高，块大小是存储的一种属性，一般不需要设置；NAS在应对海量文件时，树形存储结构相对比较乏力，读写效率较低，提高客户端本地缓存，对读写性能更好一些。
4.存储扩容或存储架构改造过程中，如何测试及评估是否会出现存储性能瓶颈？
cpc1989某保险公司存储工程师：
首先需要定性分析，分析触发存储性能瓶颈的因素以及可能出现的性能瓶颈点；其次是定量分析，需要建立存储性能基线数据，做好性能容量管理，关注性能容量指标（评估扩容后，存储的IOPS/GB是否有较大变化），分析存储性能负载是否均衡分布，提前做好规划，避免存储性能瓶颈。
5.运维过程中出现的存储性能瓶颈问题，如何分析、定位、确认？
nikkordong博雅云计算科技（北京）有限公司产品总监：
三步走，采数建模和分析。
1)采数：容易理解，通过存储设备的管理接口，持续的，周期性（分析性能瓶颈的话周期最少5分钟）的采集各类指标数据。注意的是对于一些关键指标，例如存储上的IOPS、延迟，光交上的吞吐、丢包、光功率等都要采集到。
2)建模：看您那是什么类型的存储了，SAN、集中式NAS还是分布式，不同类型分析模型不一样。以最复杂的SAN为例，要建立从服务器到存储的端到端分析模型。一般情况下，不同架构下存储性能瓶颈大概率会出现在特定位置，例如存储池、前端口、级联端口、复制链路等，单独看一个位置是不够的，要结合看。
3)分析：有了数据和模型，分析就容易了，算法啥的都不是最重要的，有经验的运维人员基本都能看出问题了。需要说明的是分析一定要结合业务场景看。
还有一点就是需要好的工具平台，能够自动完成上述工作。
6.存储系统的性能优化手段有哪些？在不同场景下，如何抉择性能优化手段？
cpc1989某保险公司存储工程师：
存储性能优化手段可大致总结为硬件升级、调整性能负载、调整应用复杂以及数据缓存优化。
存储性能优化工作具有一定的策略性，科学的优化策略才能指导制定更加合理的存储性能优化方案。
1)通盘考虑：存储性能问题是一个全局性问题，需要通盘考虑IO路径上的性能瓶颈，分析性能优化方案中可能出现的连锁反应，以提高性能优化决策的正确性。
2)优化的性价比：制定合理的性能优化目标，在多种性能优化方案的选择上，要综合考虑方案成本、实施复杂性、收益等。
3)规划更重要：相比于存储性能优化带来的优化改造成本，提前做好合理的规划更为重要。
4)完善性能监控：端到端的存储性能也是非常重要的，对整个数据IO路径进行监控，基于存储性能基线来分析实际运行中的性能数据，从而及时发现存储性能瓶颈，也能验证存储优化的成果。
四、交流总结
通过本期线上交流活动，在存储系统性能分析与优化方面，达成了如下的交流共识，仅供参考：
1)不同架构的存储方案有着不一样的性能特性，各有其擅长的存储场景，SAN存储的延时低，性能表现稳定，但扩展性弱；分布式存储扩展性强，性能表现强劲，高IOPS高带宽；NAS存储适配性强，性能较弱。
2)存储选型除了考虑存储的性能特性，更需要贴合应用场景需求。核心交易OLTP类应用，一般是小IO需要存储具有更高稳定性，响应时间短；数据处理类应用，一般是大IO，需要存储具有高吞吐，容量易扩展；虚拟化环境，一般对应性能要求并不高，需要存储具有更高的性价比。
3)存储性能分析与优化的前提是性能测试与监控，性能测试得出性能基线数据，性能监控关注实时性能表现，从而做好性能管理工作，一般可通过IOPS、延时和带宽这三大性能指标来总结存储系统的性能。
4)存储系统性能优化最重要的是做好提前规划，优化方案要从全局出发，综合考虑性能优化手段的性价比。
