数据重构如何兼顾效率与性能稳定？zStorage 全闪存分布式存储的技术实践与实测数据

点击蓝字 关注我们

zStorage 作为数据库场景下的全闪存分布式存储，除了性能要好，更重要的是要在各种情况下都能保持“稳定”的好。一个高并发的交易型业务数据库，如果出现轻微的IO抖动，就可能造成数据库并发事务提交的排队，从而导致事务积压甚至交易超时。

zStorage 的故障重构速率可以达到1GB/s，这意味着 zStorage 在15分钟内就可以完成900GB～1TB的数据重构。对于市面上常见的3.84TB的NVMe SSD盘，如果磁盘故障或损坏，该磁盘涉及的数据分片，将3副本降级为2副本，或者是2副本降级为1副本；然后 zStorage 自动利用空闲的空间进行重构，在1小时后即可重构完成，重新将降级的数据分片恢复到2副本或3副本的健康状态。

我们强调了 zStorage 的数据重构速率，这可以为数据库的高可用和安全运行提供保障。但是用户仍可能存在顾虑，担心重构会导致较大的性能影响：这会不会导致IO平均延迟变长？或者IO平均延迟变化不大，但是出现较大波动，从而导致数据库出现较大的或经常性的抖动？

但同时，用户又希望在某些场景下磁盘的重构速率更快，比如在主动维护期间，此时的业务负载较低，用户往往会期望重构能更快完成。

所以对于磁盘故障后的数据重构，至少应满足如下与性能相关的几点需求：

1. 速率要足够快，这样降级的数据分片才能尽快恢复到健康状态，数据更安全。

2. 性能影响要足够低，IOPS下降不要太多，应该控制在10%以内；IO延迟要保持稳定，不要出现波动，即IO的P90、P95和P99这些延迟指标不要有大的增加。

3. 在用户觉得有必要的时候，可以调整重构速率，以更慢或更快的速度进行重构。

关于上述第3点，我们用一个可在线修改的存储参数来调节。这个参数我们用1-32的数值来控制速率，有点像车的变速器，用不同的挡位来调节速率。参数值为1时，重构速率最慢；而值为32的时候，是最高速率。该参数的默认值我们选定为8，即大约在1GB/s的重构速率。在不同的磁盘、网络和CPU配置下，速率会有些许差异。

而针对上述第1和第2点的重构需求，本文用实测数据来验证 zStorage 在磁盘故障后数据重构的性能表现，尤其是时延的变化和稳定性。

测试数据与结论

3个存储节点，NVMe SSD磁盘数分别为4、4、6个。这里有1个节点用6个SSD是模拟磁盘故障后，会出现某个节点的盘数减少而导致IOPS降低，这是由于在分布式存储中，通常会出现有短板的木桶成了影响整个系统上限的情况。我们要测试的是单纯的因重构所导致的IOPS和时延变化，而需要避免其他干扰。

存储池划分了6个卷并挂载到1个计算节点上，在计算节点上用fio进行测试。我们统一使用4KB块大小（读写比例7:3）进行随机IO测试。 

通过实测，结果如下（注：本文主要验证重构的性能影响的相对值，由于磁盘数量较少，没有达到典型配置需要的每节点8个磁盘，所以性能数据比正式的产品性能值低）：

1. 重构时IOPS的影响

从上表可以得到如下结论：

1. 在默认配置下，即重构速率“挡位”为8时，重构速率达到1GB/s，而IOPS下降幅度（即IO影响）仅7.9%。

2. 在重构速率“挡位”为16时，重构速率达到1808MB/s，比挡位8时提升了77.6%，而IOPS下降幅度仅11.6%。

3. 全速重构时，重构速率接近7GB/s，即1小时接近25TB的重构量；也就是说，即使是15.36TB的NVMe SSD盘在使用率达到90%，即数据量13.82TB时，磁盘故障后也只需要33分钟左右就能完成重构。

2. 重构对读IO延迟的影响

3. 重构对写IO延迟的影响

可能有细心的朋友注意到，在重构速率“挡位”为8时，重构时写IO的99分位延迟（即P99）比没有重构时还低。这是因为发生了长尾延迟，是由SSD盘的写抖动引起，所以这说明测试中，重构时SSD盘的写抖动导致的延迟刚好比没有重构时小。

从上面的2个表可以得到如下结论：

1. 在默认配置下，即重构速率“挡位”为8时，IO平均延迟增加8%～11.4%，P99延迟也只增加6.8%。

2. 在重构速率“挡位”为16时，IO平均延迟增加12.2%～16.8%（实际上读IO平均延迟与“8挡”时一致），P99延迟也只增加2.2%～5.7%。

3. 在全速重构时，读IO平均时延也仅为0.4ms，写IO平均时间0.58ms；而P99略高，写IO的P99时延达到了3.26ms。在系统负载不高或业务低谷时期，进行全速重构也能确保业务系统正常运行。

4. 从上述的P90-P99时延数据可以看到，重构期间，没有出现非常大的IO波动；在非全速重构期间，P99时延只有很小的增加。这说明IO的延迟相当稳定。

从实测数据不难看出，zStorage 一直是以匀速的方式在重构；而不是采用处理一批IO后，又重构一部分数据（比如以Chunk为单位进行重构）的方式，因为这样会出现大IO影响或阻塞业务IO，导致部分IO的时延变得很长。

总结

磁盘故障导致的数据重构，一方面要有足够的速率，让重构尽可能快地完成；另一方面也要保证重构对IO的影响足够小，这包括要保证IO时延的稳定，避免部分IO时延过长。而 zStorage 在磁盘故障后的数据重构功能，很好地满足了这两方面的要求，同时还兼顾了可以人为地根据不同场景调整重构速率的需求。

附件

本文实测的fio输出数据（篇幅有限，只输出2个不同挡位重构速率的数据）。

1. “挡位8”，无重构时性能和重构时fio性能输出

无重构时性能输出：

重构时性能输出：

2. “挡位16”，无重构时性能和重构时fio性能输出

无重构时性能输出：

重构时性能输出：

数据驱动，成就未来，云和恩墨，不负所托！

---

云和恩墨创立于2011年，是业界领先的“智能的数据技术提供商”。公司以“数据驱动，成就未来”为使命，致力于将创新的数据技术产品和解决方案带给全球的企业和组织，帮助客户构建安全、高效、敏捷且经济的数据环境，持续增强客户在数据洞察和决策上的竞争优势，实现数据驱动的业务创新和升级发展。

自成立以来，云和恩墨专注于数据技术领域，根据不断变化的市场需求，创新研发了系列软件产品，涵盖数据库、数据库存储、数据库管理和数据智能等领域。这些产品已经在集团型、大中型、高成长型客户以及行业云场景中得到广泛应用，证明了我们的技术和商业竞争力，展现了公司在数据技术端到端解决方案方面的优势。