E企研究院 · 4月1日 · 天津市

单盘故障完全无感,单节点掉线面不改色!

分布式系统在集中调度资源的同时,也提供了硬件冗余和数据一致性,具有良好的容错性和可用性。在之前的文章(四节点百GB吞吐量!超融合迈入全闪时代)中,我们展示了新一代Dell VxRail全闪分布式系统的性能,而本期文章,我们将围绕故障及恢复展开。

本次测试依旧使用了4个Dell VxRail VE-660节点。我们设定了两种故障形式:单盘故障、单节点故障。其中,单盘故障是在测试过程当中,通过指令将某一SSD临时卸载,单节点故障则是在测试过程中,直接将某一台服务器关机,模拟节点离线。
微信图片_20240331234422.png

服务器:Dell VxRail VE-660

CPU:单路Intel Xeon Gold 6444Y(16物理核,32逻辑核,3.6GHz)

内存:DDR5 4800 RDIMM 64GB ×4

系统盘:NVMe 960GB ×2

存储盘:Dell Ent NVMe CM6 RI 1.92TB ×4

系统:8.0.1 Update 1 Patch 25 (build-22088125) Kernel 8.0.1 (x86 64)

虚拟机设置:

vCPU数量:4

vDisk容量:10GB

vDisk数量:8

集群的存储配置策略配置默认为RAID5模式。使用HCIBench运行FIO,进行1MB大数据块顺序读的测试。设置了8个虚拟机,每虚拟机8个vDisk,各分配1个FIO线程。在正常情况下,这个设置可以获得超过94GB/s的吞吐量。
2.png

模拟单盘故障

在测试过程中,临时卸载一个SSD后,整个集群的吞吐量出现了波动:峰值依旧可以达到94GB/s,但偶尔也会跌到20GB/s、70GB/s等情况。整个测试结束时,平均吞吐量约为92GB/s,可以认为性能的损失相当轻微。集群原本的SSD数量为16个,变为15个之后,SSD的理论总读取带宽依旧可以保持在100GB/s以上,确实可以保证比较稳定的输出。
3.png
4.png

需要强调的是,从仪表盘监测的结果看,在出现单盘“故障”后,每个FIO线程了IOPS和吞吐量都保持了稳定,始终是一条直线。集群总吞吐量波动的原因其实是偶尔的IO数量下降,也就是某个FIO线程会被暂停,随后迅速恢复。

微小的性能波动也让我们意识到:在单盘离线发生时,由于VxRail默认设置认为磁盘没有故障只是短暂的离线状态,并没有立即出现同步数据的操作,因而避免了额外的同步数据对性能的影响。根据VMware的说法:VxRail ESA在其存储池设计中没有单一故障点,VxRail数据和元数据将根据允许的故障数 (FTT) SPBM 设置进行保护。

为了进一步验证同步对象的操作对性能的影响,我们通过命令恢复了磁盘连接,并再次重复测试,VxRail会自动重新完成数据副本的同步,使副本数据一致。这一次,我们在卸载SSD后,立即检查同步对象的状态,没有等待60分钟,并选择了立即重新同步功能,提前让数据同步。

VxRail的磁盘和节点离线策略

当磁盘或节点处于离线状态,并不会立即同步数据(VxRail节点或磁盘离线超时到期默认设置为60分钟),60分钟后如果集群有足够的热备空间,将在集群中的其他磁盘重建受影响的组件,保证虚拟机数据存储策略。

若磁盘物理故障,集群有足够的热备空间,将在集群中的其他磁盘立即重构受影响的组件,保证数据立即恢复。
5.png

在开始同步时,我们可以看到需要同步的对象容量为66GB。考虑到8个虚拟机各8个10GB虚拟盘的设置,以及16个物理SSD,那么分配到每个物理SSD的虚拟盘容量为40GB,再加上2+1的RAID5需要额外容量的校验空间和管理虚拟机消耗的空间,约为60多GB的实际容量消耗,与VxRail报告的对象容量基本匹配。
6.png

一旦强制进行同步对象,集群就产生了额外的读写操作,果然对吞吐量产生了略为明显的影响:降到91.2GB/s。这个性能下降的幅度比同步前要大一些,但也不到4%的水平。同时,在仪表盘当中,我们也可以观察到FIO各线程的吞吐量、IOPS不再是稳定的一组水平直线,而是略有下坡。这说明同步操作均匀地分布到了各个SSD上,进而均等地影响了所有的FIO线程。
7.png

对于一个Dell VxRail集群,假如发生单盘故障,对用户而言可谓完全无感。

其一,这是由于RAID机制保证了容错性和可用性,当一个数据副本所在的磁盘出现离线或磁盘物理故障,数据I/O路径会快速找到其他节点正常的副本进行读写,减少对业务读写性能的影响。

其二,VxRail较高的硬件门槛对应了较多数量的SSD,本身就可以提供充裕的性能。

其三,VxRail分布式存储系统的写入吐量受限于网络,全NVME磁盘对SSD的写入压力很小,对SSD的读响应能力影响很小。

实际上,我们认为VxRail是刻意限制了同步的写入压力,而不仅仅是受限于网络,其中的细节我们留在单点故障中进一步展开。

单节点故障下的压力测试

当一台服务器被关机时,集群的吞吐量立刻发生了显著的变化:吞吐量跌到不足69GB/s,初期还短暂出现过25GB/s的情况。
8.png

虽然损失了整个节点,节点上运行的虚拟机自动HA到其他主机,我们在进行测试之前考虑过可能出现虚拟机数量暂时变为6的情况,也就是相当于若干个业务会离线。

与单盘故障类似的,单节点故障后,FIO线程的吞吐量也保持了稳定的水平直线,但不同点是:总IO数量出现波动,下降到了48甚至16,之后回升,但不再超过48。也就是说,在这个测试中,单点故障发生后,相应损失了四分之一的FIO线程上限,但其余FIO线程的性能完全不受影响。我们考虑过的一种可能是线程数量波动,然后逐步恢复到64个,但每个线程的性能被摊低,但这样的情况没有发生。我们遇到的实际情况可以理解为:总接待能力下降,排队的时间增加,但入场的个人体验不变。

测试表明Dell VxRail集群对于单节点故障,数据仍在持续写入,仍然可以保持集群性能和业务稳定运行。

单节点故障下的重建测试

我们创建了20台测试虚拟机,并在每个虚拟机内拷贝约180GB的非结构化数据,如下图,ESA存储空间使用率约为50%。
9.png

10.png
我们关闭节点进行数据重建测试,当手动选择重建时,系统预估需重新同步的数据为2.74TB,预计的重建时间为22分钟。
11.png

中间同步过程时间记录在15:50,还有2.32TB数据需要同步;预计18分钟完成;
12.png

16:14,实际经过24分钟已经完成2.32TB数据同步。
13.png

实际的总重建时间接近29分钟,大致相当于每分钟可以重建100GB的数据。重建期间,数据接收流量最大的节点网络流量峰值约3GB/s,与上一期文章测试中32虚拟机、8线程的顺序写入性能相当(四节点百GB吞吐量!超融合迈入全闪时代)。对于全闪分布式系统而言,重建效率主要受制于网络带宽(当前网络配置为25GbE)。
14.png

结 语

在上一轮的测试当中,我们已经感受到了新一代Dell VxRail在软、硬件质变带来的惊人性能。在新一轮的故障模拟测试中,Dell VxRail组成的集群表现得非常稳健——尤其是全闪设计的充裕性能,使得集群不论是面对单盘故障,亦或者更为极端的整个节点的故障,都显得游刃有余。

我们之前还曾特意提及vSAN ESA的RAID5设计是优先保障低时延,其后才是完成校验数据写入。类似的“保体验”思路在同步对象的策略当中也有明显的体现:在未确认磁盘故障时,不急于开始同步,不额外占用性能;在同步过程中限制资源占用,保留充足响应能力。

推荐阅读
关注数
5055
文章数
420
对数据中心、云计算、5G、AIoT 等科技领域的最新技术和应用的信息交流、新产品新技术的引导、技术创新与品牌打造,降低用户对新技术的接受成本
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息