分布式存储最佳缓存比

Posted 2023-04-07

作者：深入细节的 SmartX 一线技术团队

近日，VMware 发布了 vSAN 8，对存储架构进行了重大更新。其中最主要的变化，即引入了新的 Express Storage Architecture（ESA）架构：用“存储池”替代了原存储架构（OSA）中的“磁盘组”，并不再需要专用 SSD 承担缓存加速功能，一定程度上避免了 8.0 之前版本中的专用缓存盘利用率低、易发生缓存击穿等问题。
而值得一提的是，在 vSAN 大版本更新之前，SmartX 即通过统一缓存空间和智能冷热数据管理优化了分布式存储缓存机制，有效规避了上述问题。本文将通过重点解读 vSAN（以 vSAN 7 为例）和 SmartX 分布式块存储组件 ZBS* 缓存机制的原理，并测试对比两种缓存机制下虚拟机性能表现，让读者更好地了解两种技术实现机制的区别对业务可能带来的实际影响。

* ZBS 内置于 SmartX 超融合软件 SMTX OS，可与 SmartX 原生虚拟化 ELF 搭配提供服务。

本文重点
vSAN 7 采用划分读写缓存空间的机制，将缓存磁盘按照容量占比划分为写缓冲区（30%）和读缓存区（70%）。这种方式可能出现缓存利用率低、在访问数据量过大时导致缓存击穿，进而引起性能下降等问题。
ZBS 采用统一缓存空间的机制，并通过 2 级 LRU 算法对冷热数据进行管理，在充分利用缓存容量的同时避免了因访问量激增导致虚拟机性能下降的情况。
本文基于相同的硬件配置和 I/O 读写场景，分别测试 VMware 超融合（vSphere 虚拟化 + vSAN 分布式存储）写入 300 GB 数据、SMTX OS（ELF + ZBS）写入 500 GB 数据时虚拟机的性能表现。结果显示，vSAN 7 难以充分利用缓存介质，发生缓存击穿，导致存储性能下降；而 SMTX OS 即便在写入更多数据的情况下也未发生缓存击穿，虚拟机性能保持稳定。
场景问题
混闪配置是超融合或分布式存储现阶段的主流落地模式。混闪配置是指机器中的磁盘使用 SSD + HDD 混合组成，其中 SSD 磁盘作为数据缓存层，而 HDD 磁盘作为数据容量层。以该模式构建的分布式存储池通过软件算法进行冷热数据自动判断，在提供高性能的同时，还可获得较大的存储容量，进而提升资源利用率，获得相对全闪存储更高的性价比。

在将 SSD 磁盘用作数据缓存层时，部分超融合产品会将缓存容量（Cache）划分为读和写各自独立的两部分。例如，vSAN 7 及更早版本会将每个磁盘组（Disk Group）中的缓存磁盘，按照容量占比划分为写缓冲区（30%）和读缓存区（70%），当读取数据未命中缓存或者写缓存已满，将会直接从容量层进行读写。 参考技术A 系统QPS是10000，每次请求会查询10次的缓存，普通机器mysql也只能抗大概2000的并发。1. 支持大数据量存储，不受应用进程重启影响
分布式缓存由于是独立部署的进程，拥有自身独立的内存空间，不会受到应用进程重启的影响，在应用进程重启时，分布式缓存的数据依然存在。同时对于数据量而言，由于不需要占用应用进程的内存空间，并且一般支持以集群的方式拓展，故可以进行大数据量的数据缓存。
2. 数据集中存储，保证数据一致性
当应用进程采用集群方式部署时，集群的每个部署节点都通过一个统一的分布式缓存进行数据存取操作，故不存在本地缓存中的数据更新问题，保证了不同节点的应用进程的数据一致性问题。

redis集群简介

redis是一个键值对，NOSQL，高性能存储系统，性能高，是分布式缓存的最佳人选，特别是node环境下，由于node的内存限制，是的node在内存方面寸土寸金，使用redis做缓存，是高性能高并发，node服务器最佳组合。

redis是使用内存进行存储的，所以就注定了他不适合非常大的持久性数据，这样的数据还是交给mongodb，elasticSearch，mysql来存储。使用redis一定要注意内存的浪费，redis是单线程的一定要注意redis对cpu的使用率，如果过高就会造成卡顿。redis的过期键数据回收机制有两种，惰性回收和定时回收。

redis哨兵是redis分布式的关键。下来看一下redis主从复制问题，在主从复制模式下主节点将数据同步到从节点，一旦主节点出问题从节点顶上去，这样以来一个关键的问题是主节点的读和写的能力就决定了整个系统的能力。如果这个过程有人工干预必然造成数据不完整和丢失，这就要求我们构建高可用的redis集群。

一个高可用的redis主从复制模式，对于小型的公司这样足够了。它包括若干个哨兵节点和若干个数据节点，每个哨兵节点会对数据节点和其余的哨兵节点进行监控，当发现节点不可用时，会对节点进行标识，如果被标识的节点是主节点，他就会和其他哨兵节点进行协商，当大多数哨兵节点都认为主节点不可用，他们会自动选出一个哨兵节点完成鼓掌转义工作，整个过程自动化，从而使系统高可用。

一个分布是数据库首先要解决的问题是，把这个数据集合按照分区映射到多个节点的问题，一般有三种选择：1，节点取余分区。2，哈希表分区。3，虚拟槽分区。redis采用的是虚拟槽分区。它是所有的键值根据哈希函数映射到0-16383的整数槽内，一个节点负责维护一部分槽位和数据，并且节点之间不断交换信息，一段时间后一个节点就知道整个集群的完整信息，但是这种信息交换是有成本的。理论上来讲，可以向集群的任意一个节点发送数据请求，如果该节点没有，它会自动向有的节点转发。如果你是运维工程师，里面设计的问题很多很复杂，这里不再赘述。