分布式系统在集中调度资源的同时，也提供了硬件冗余和数据一致性，具有良好的容错性和可用性。在之前的文章（四节点百GB吞吐量！超融合迈入全闪时代）中，我们展示了新一代Dell VxRail全闪分布式系统的性能，而本期文章，我们将围绕故障及恢复展开。
本次测试依旧使用了4个Dell VxRail VE-660节点。我们设定了两种故障形式：单盘故障、单节点故障。其中，单盘故障是在测试过程当中，通过指令将某一SSD临时卸载，单节点故障则是在测试过程中，直接将某一台服务器关机，模拟节点离线。
服务器：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的吞吐量。
模拟单盘故障
在测试过程中，临时卸载一个SSD后，整个集群的吞吐量出现了波动：峰值依旧可以达到94GB/s，但偶尔也会跌到20GB/s、70GB/s等情况。整个测试结束时，平均吞吐量约为92GB/s，可以认为性能的损失相当轻微。集群原本的SSD数量为16个，变为15个之后，SSD的理论总读取带宽依旧可以保持在100GB/s以上，确实可以保证比较稳定的输出。
需要强调的是，从仪表盘监测的结果看，在出现单盘“故障”后，每个FIO线程了IOPS和吞吐量都保持了稳定，始终是一条直线。集群总吞吐量波动的原因其实是偶尔的IO数量下降，也就是某个FIO线程会被暂停，随后迅速恢复。
微小的性能波动也让我们意识到：在单盘离线发生时，由于VxRail默认设置认为磁盘没有故障只是短暂的离线状态，并没有立即出现同步数据的操作，因而避免了额外的同步数据对性能的影响。根据VMware的说法：VxRail ESA在其存储池设计中没有单一故障点，VxRail数据和元数据将根据允许的故障数 (FTT) SPBM 设置进行保护。
为了进一步验证同步对象的操作对性能的影响，我们通过命令恢复了磁盘连接，并再次重复测试，VxRail会自动重新完成数据副本的同步，使副本数据一致。这一次，我们在卸载SSD后，立即检查同步对象的状态，没有等待60分钟，并选择了立即重新同步功能，提前让数据同步。
VxRail的磁盘和节点离线策略
当磁盘或节点处于离线状态，并不会立即同步数据（VxRail节点或磁盘离线超时到期默认设置为60分钟），60分钟后如果集群有足够的热备空间，将在集群中的其他磁盘重建受影响的组件，保证虚拟机数据存储策略。
若磁盘物理故障，集群有足够的热备空间，将在集群中的其他磁盘立即重构受影响的组件，保证数据立即恢复。
在开始同步时，我们可以看到需要同步的对象容量为66GB。考虑到8个虚拟机各8个10GB虚拟盘的设置，以及16个物理SSD，那么分配到每个物理SSD的虚拟盘容量为40GB，再加上2+1的RAID5需要额外容量的校验空间和管理虚拟机消耗的空间，约为60多GB的实际容量消耗，与VxRail报告的对象容量基本匹配。
一旦强制进行同步对象，集群就产生了额外的读写操作，果然对吞吐量产生了略为明显的影响：降到91.2GB/s。这个性能下降的幅度比同步前要大一些，但也不到4%的水平。同时，在仪表盘当中，我们也可以观察到FIO各线程的吞吐量、IOPS不再是稳定的一组水平直线，而是略有下坡。这说明同步操作均匀地分布到了各个SSD上，进而均等地影响了所有的FIO线程。
对于一个Dell VxRail集群，假如发生单盘故障，对用户而言可谓完全无感。
其一，这是由于RAID机制保证了容错性和可用性，当一个数据副本所在的磁盘出现离线或磁盘物理故障，数据I/O路径会快速找到其他节点正常的副本进行读写，减少对业务读写性能的影响。
其二，VxRail较高的硬件门槛对应了较多数量的SSD，本身就可以提供充裕的性能。
其三，VxRail分布式存储系统的写入吐量受限于网络，全NVME磁盘对SSD的写入压力很小，对SSD的读响应能力影响很小。
实际上，我们认为VxRail是刻意限制了同步的写入压力，而不仅仅是受限于网络，其中的细节我们留在单点故障中进一步展开。
单节点故障下的压力测试
当一台服务器被关机时，集群的吞吐量立刻发生了显著的变化：吞吐量跌到不足69GB/s，初期还短暂出现过25GB/s的情况。
虽然损失了整个节点，节点上运行的虚拟机自动HA到其他主机，我们在进行测试之前考虑过可能出现虚拟机数量暂时变为6的情况，也就是相当于若干个业务会离线。
与单盘故障类似的，单节点故障后，FIO线程的吞吐量也保持了稳定的水平直线，但不同点是：总IO数量出现波动，下降到了48甚至16，之后回升，但不再超过48。也就是说，在这个测试中，单点故障发生后，相应损失了四分之一的FIO线程上限，但其余FIO线程的性能完全不受影响。我们考虑过的一种可能是线程数量波动，然后逐步恢复到64个，但每个线程的性能被摊低，但这样的情况没有发生。我们遇到的实际情况可以理解为：总接待能力下降，排队的时间增加，但入场的个人体验不变。
测试表明Dell VxRail集群对于单节点故障，数据仍在持续写入，仍然可以保持集群性能和业务稳定运行。
单节点故障下的重建测试
我们创建了20台测试虚拟机，并在每个虚拟机内拷贝约180GB的非结构化数据，如下图，ESA存储空间使用率约为50%。
我们关闭节点进行数据重建测试，当手动选择重建时，系统预估需重新同步的数据为2.74TB，预计的重建时间为22分钟。
中间同步过程时间记录在15:50，还有2.32TB数据需要同步；预计18分钟完成；
16:14，实际经过24分钟已经完成2.32TB数据同步。
实际的总重建时间接近29分钟，大致相当于每分钟可以重建100GB的数据。重建期间，数据接收流量最大的节点网络流量峰值约3GB/s，与上一期文章测试中32虚拟机、8线程的顺序写入性能相当（四节点百GB吞吐量！超融合迈入全闪时代）。对于全闪分布式系统而言，重建效率主要受制于网络带宽（当前网络配置为25GbE）。
结 语
在上一轮的测试当中，我们已经感受到了新一代Dell VxRail在软、硬件质变带来的惊人性能。在新一轮的故障模拟测试中，Dell VxRail组成的集群表现得非常稳健——尤其是全闪设计的充裕性能，使得集群不论是面对单盘故障，亦或者更为极端的整个节点的故障，都显得游刃有余。
我们之前还曾特意提及vSAN ESA的RAID5设计是优先保障低时延，其后才是完成校验数据写入。类似的“保体验”思路在同步对象的策略当中也有明显的体现：在未确认磁盘故障时，不急于开始同步，不额外占用性能；在同步过程中限制资源占用，保留充足响应能力。
