本文来自微信公众号“twt企业IT社区”，作者/赵海，某金融系统高级主管。
纵观存储的发展，从最原始的DAS架构发展到NAS和SAN并存的架构，从NAS&SAN并存的架构发展到基于互联网基因和云计算基因的云平台存储架构，其架构变得越来越复杂。这必然带来性能上的损耗，这与我们大部分数据业务场景追求性能的目标是相悖的，那么如何解决这个矛盾呢？
一、企业存储优化思路总结
企业存储主要包括集中式架构的SAN存储和NAS存储。企业经历集中式存储的时间相对而言比较长，那么在面临性能优化的问题也有一套相对比较完善的思路，总结来看主要从以下几个方面实现：
1.规划时的优化配置
大部分的性能优化问题都归根于规划设计不够精细准确，所以解决性能的非常关键的因素就在于规划，存储卷的数量、分布、分区（Zone）映射等相关配置。如果DBA对数据库数据文件使用的存储卷规划不够均衡准确，必然造成某些卷的高热点IO访问，如果这个卷所依附的分区映射又不是非常合理均衡，那么这个问题就会无限放大。因此传统存储实践前的规划，需要架构师在上层应用的存储使用容量、数目、负载等各方面进行梳理和分析，本着均衡分布的原则将卷的使用映射到存储资源上，这样才能最大限度减少后续性能优化问题。
2.存储引擎硬件配置
主要通过观察存储运行过程当中关键指标（CPU、Cache）的峰值以及平均值的情况，来衡量当前控制器内的硬件配置是否已经成为系统性能的瓶颈，通常传统集中式存储支持单独升级CPU、Cache硬件的场景较少，一般都是通过增加Cache卡或者控制器扩展的方式来解决。当然，在具体分析的时候需要根据其他指标的评估来判断是否因为其他特殊状况引起的资源占用问题，这种情况并非需要增加硬件资源。
3.存储引擎端口资源
主要通过观察存储运行过程当中每一个前端端口和后端端口的使用情况（使用率、均衡性、吞吐量）等相关指标在一定周期内的平均数值，来评估板卡端口容量以及配置是否有性能问题。如果端口数量容量没有问题，只是出现了负载不均衡的状况，那么就需要手动调整Zone映射的配置来调整其平衡性。
4.存储软件参数策略
所谓与性能问题息息相关的存储软件策略，主要是指存储产品开放出来的一系列软件参数以及分层策略。通常是通过观察存储运行过程当中的系列关键指标（IOPS、Latency、Throughout等），来判断软件层面的队列参数、存储单元参数、读写控制参数、缓存控制参数等来实现一部分优化。如果是针对个别存储卷的问题，可能需要将数据反馈到系统管理员和DBA层面进行操作系统及数据层面的优化。所谓分层策略是指存储资源池当中有SSD、SAS、SATA等多种磁盘的资源池的自动平衡策略，一般通过观察预留资源池容量大小、分层时间窗口策略、分层容量阈值策略、SSD磁盘数量增加等手段实现分层的优化。
二、分布式存储性能优化思路
对于分布式存储来讲，它的架构复杂度要高于传统的集中式存储，从前期的架构配置规划到后期的运维监控优化都要比传统的集中式存储付出更多的精力和工作。首先，我们从整个的读写流程来看。
图1：两种存储读写流程图
如图1所示，上半部分是传统SAN存储的落盘路径，下半部分是分布式存储的落盘路径，相对于SAN存储的落盘路径，分布式存储的这个链路就复杂了。应用发出的IO请求会经过以太网络到达云平台存储的路由节点、接口服务层；接口服务层又会将应用特定的服务接口数据格式，转换为底层分布式存储平台接受的文件或者对象格式；在具体写入的时候又会访问元数据，通过元数据的映射表再找到数据节点数据空间，然后完成冗余性复制，才能完成一个真正的IO。也就是说在存储数据服务接口到底层分布式存储平台这个环节会有延时（Latency），从分布式存储平台接受请求、到数据落盘、到数据节点并完成冗余复制这个过程也会有延时。因此分布式存储的性能问题相对更复杂，更需要有系统的思路去执行。
1.业务区分
存储资源是为数据业务服务的，数据业务表现在IOPS、吞吐带宽、容量方面的需求和宽容度是不一样的。因此我们在针对不同数据业务场景进行分布式存储项目实践的时候，从软件层面到硬件层面的配置都应该有针对性的标准。例如我们可以按照以下的标准（表1）进行业务的区分：
表1：存储指标与业务场景映射表
经过对业务场景的精细化梳理分析之后，可以将存储空间的分配对应到按照不同的业务需求划分设计的存储资源池当中，然后再根据资源池的技术指标（IOPS、Throughout、Capacity）去规划资源池对应的软硬件配置。
2.数据管理
通常的分布式存储系统，会把数据分散在大量的存储服务器上，而存储服务器本身都会安装Linux操作系统，并且有自己的本地文件系统。例如HDFS、Luster、Ceph等分布式存储系统的存储节点都会使用POSIX接口的本地文件系统EXT、BTRFS、XFS等来存储数据。本地文件系统不能很好地适配对象存储需求的扩展性要求：
1）数据和元数据分离不彻底，目录树结构的元数据管理方式等导致大规模的对象数据寻址非常慢。
2）为了支持事务特性的日志重复写问题，也就是分布式文件系统日志和本地文件系统日志重复写的问题。
3）本地文件系统日志的事务性写导致了写的放大。
那么在存储节点本地文件系统的选型设计上，如果我们能选择优化的而非默认的配置，那么就会解决掉存储节点本身带来的IO深度和复杂度延时的问题，从而提高整个分布式存储的读写性能。当然，这个是需要在每一种分布式存储数据节点支持的文件系统或者文件管理方式范围内去平衡和决策。
3.容错设计
存储介质故障发生的频率无论是在传统存储当中还是在分布式存储系统当中都非常高。而解决这个问题的方式基本上有两种：多副本和纠删码。多副本采用的是多份数据镜像的方式来保护，数据纠删码采用的是校验计算的方式来保护数据。前者使用空间成本换容错，后者使用计算成本换容错。通常传统集中式存储采用的是后者，而分布式存储采用的是前者。但是很多分布式存储也支持纠删码。因此在容错设计的时候需要考虑数据业务场景对IOPS、Throughout、Capacity的需求，然后设计合乎性能和成本要求的容错策略，同时在副本策略当中也要选择合适的副本数目、分布策略。
4.网络通讯
分布式存储系统中，节点间需要通过网络通信来交换节点及集群状态信息和具体的数据文件，整体的数据通讯量级是非常大的。因此，在网络通讯的配置方面也需要关注几个重点问题。
1）通讯网络隔离：通常我们需要将管理网络、数据网络、服务网络进行隔离。管理网络通常用来传递控制信息，数据量小但是比较重要；数据网络通常是存储节点之间进行交互的网络，其通讯量大而且重要；服务网络通常是向上层提供存储服务的网络，是数据服务业务通道。这几个网络不仅仅要隔离，而且还要根据数据业务评估设计合适带宽。
2）通讯模式的选择：以Ceph为例，三种类型的通信模式分别是Simple、Async、XIO。Simple线程模式对每个网络连接都创建了两个线程分别用于接收和发送。随着集群规模的增长，创建的连接数和线程数会呈指数级增长，而且需要消耗更多的CPU和内存资源。所以应对不同规模或者未来扩展规模的分布式存储集群，要选择合适的通信模式。
3）网络类型的选择：关于网络类型的选择要考虑到未来扩展性需求以及网络通讯质量的需求。比如VXLAN和VLAN的选择要考虑到VLAN诸多的数量和功能限制。比如高速网络的选择要考虑到网络通讯质量的需求。
5.数据分布
数据分布主要是针对无中心架构的分布式存储而言，这类系统主要是通过哈希算法来实现数据分布和检索。虽然系统本身的分布算法已经确定，但是数据分布算法所需要的计算因子是需要我们在实践配置的时候输入的。比如说Ceph的数据桶的组织结构类型有四种：Uniform、List、Tree、Straw。每一种类型针对数据检索、节点变化导致的数据变化等方面都有不同的表现（如表2）：
表2：数据桶结构性能对比
通常来讲，Straw在各个维度都比较均衡的类型，也更适合大规模的分布式存储系统，因此通常都会采用Straw来作为Bucket的数据结构类型来使用。但是如果存储节点在容量、计算能力、网络硬件上面配置有特殊的地方，那么就要根据具体策略适用的场景来评估了，不一定Straw就是最优的选择。
分布式存储系统当中在哈希计算的时候之所以能保持集群的相对稳定性，就是因为虚拟对象（如Ceph的PG、Pool，如Swift的Container）设计，同样这些虚拟对象数量、管理方式、映射关系等方面的配置也是决定数据分布式算法计算因子是否优秀的重要方面，同样需要精细化设计。
6.配置参数
分布式存储系统的配置参数调优所涉及的对象比较多，从物理对象上来看有客户端、管理节点、数据节点，这三类节点都会有相应的软件配置及对应的进程服务，每个层面都会有相应的参数可以调整优化分布式存储的各方面性能表现。另外从组成分布式存储的外围对象上来看，数据节点上的操作系统参数（内核控制参数）也是重要的配置对象。每一种分布式存储都会有数百甚至数千的参数开放出来，提供给使用者针对具体场景进行系统调优。以Ceph为例：
1）操作系统层：磁盘预读缓存、系统进程数量、CPU模式、网络参数...
2）Ceph集群层：FileStore、Jornal、OSD、MON...
针对不同分布式存储，需要根据其指导手册查询具体的参数及相应的取值类型和范围。
7.硬件配置
对于分布式存储系统硬件配置的优化，其实最主要的就三个方面：
1）管理节点计算能力（CPU、内存、磁盘）的提高，主要用来完成对数据寻址过程的快速响应。
2）数据节点SSD的使用，主要用来减少数据在存储节点上落盘时间的延时消耗上以及日志写的性能优化上。
3）高速硬件网络技术的使用，主要用来减少副本复制及数据传输方面的性能消耗。
三、结语
总而言之，性能问题是贯穿于存储实践整个过程的关键问题，传统存储架构无法避免，分布式存储架构也无法避免。企业实现私有云之后，云上的存储资源会是多元化的架构模式，基于上述提纲，在实践的过程当中实现更精细化的梳理、更准确客观的分析、更实事求是的态度，才能解决好云平台上存储架构性能与扩展性的平衡问题。
