前言:
现时你们对“虚拟机连接设备就蓝屏”大致比较注意,朋友们都需要分析一些“虚拟机连接设备就蓝屏”的相关知识。那么小编也在网摘上汇集了一些关于“虚拟机连接设备就蓝屏””的相关资讯,希望兄弟们能喜欢,我们一起来了解一下吧!我们现在讨论内部根本原因,主要是固件错误和设备错误/磨损。我们根据硬件类型(SSD、磁盘、内存、网络和处理器)组织讨论。
4.1 SSD
固件错误和NAND闪存管理复杂性可能会触发SSD的亚健康故障。
固件错误:我们收到了三份关于SSD固件错误的报告,供应商承认了这一点。首先,许多本应只需要几十微秒的单个IOs被精确地限制在250微秒的倍数,高达2-3毫秒。更糟糕的是,在另一份报告中,一批坏的SSD在几秒钟内停止响应,然后恢复。如前所述,操作员发现一些SSD从系统中“消失”,随后又重新出现。经供应商检查,SSD正在执行一些内部元数据写入,触发硬件断言故障并重新启动设备。在所有这些情况下,没有解释固件行为如此的原因(专有原因)。然而,下面的其他事件显示了更多的潜在问题。
使用不同电压进行读取重试:为了读取闪存页,SSD控制器必须设置特定的电压阈值。随着闪存芯片的磨损,氧化物栅极中的电荷减弱,使得默认电压阈值的读取操作失败,迫使控制器继续以不同的电压阈值重试读取[10,11]。我们在现场观察到高达4次重试。
基于RAIN/奇偶校验的读取重建:此外,如果数据无法读取(即完全损坏且未通过ECC检查),SSD必须使用RAIN(NAND级RAID)重建页面[1,41]。有三个因素会使情况变得更糟。首先,如果RAIN宽度为N,N−1必须生成其他读取以重建损坏的页面。第二,N−1如上所述,读取也可能会经历读取重试。第三,较新的基于TLC的SSD使用LDPC码[40],这需要较长的时间来重建错误页面。我们观察到,这种重建问题经常发生在接近寿命结束的设备中。此外,SSD工程师发现位翻转的数量是上一次写入时间、上一次写入后的读取次数、闪存温度和闪存磨损量的复杂函数。
部分失败的SSD中存在严重的GC:NAND闪存页的垃圾收集(GC)已知是违反用户SLA的主要原因[23、28、41]。然而,在现代数据中心SSD中,更高级的固件成功地减少了对用户的GC影响。实际上,有些SSD附带了“坏”芯片。我们看到,随着更多芯片死亡,过度配置区域的大小会减小,从而更频繁地触发GC,产生无法隐藏的影响。
通过次优磨损均衡破坏并行性:理想情况下,大型IO映射到并行通道/芯片,从而提高IO并行性。但是,磨损均衡(热/冷页面迁移到热/冷块)会导致LPN到PPN的映射始终发生变化。已经观察到,一些罕见的工作负载行为可能会使磨损均衡算法不理想,从而使顺序LPN映射到相同的通道/芯片后面(并行性较低)。此外,上述不良页面/芯片的问题还迫使磨损均衡算法进行次优、并行性较差的页面/块映射。
高温导致磨损、重复擦除和空间减少:高温可归因于外部原因(§5.1),但可导致SSD内部发生连锁反应[31]。我们还观察到,随着温度的升高,SSD页面磨损更快,并且当SSD在更高温度下运行时,存在电压阈值建模失效的情况。因此,在块擦除后,位没有正确复位(并非所有位都变为“1”)。因此,某些块必须多次擦除。请注意,擦除时间已经很长(例如,高达6毫秒),因此重复擦除会导致明显的亚健康缓慢行为。更糟糕的是,由于一些块在多次尝试后无法正确重置,固件将这些块标记为不可用,从而减少了过度配置的空间,并随后增加了GCs的频率,如上所述。
写放大:更快的磨损和更频繁的GCs可导致更高的写放大。值得报告的是,我们观察到了不同程度的放大(例如,模型“A”为5倍,模型“B”为600倍,由于过早磨损,某些工作负载为“无法衡量”)。
并非所有芯片都是平等的:总之,上述大多数问题都是由于并非所有芯片都是平等的。坏芯片仍然通过供应商的测试,每个芯片都有一个质量值,只要通过质量控制标准,高质量芯片就会与低质量芯片混合。因此,给定SSD,存在不同的质量[10,36]。一些工作负载可能会导致低质量芯片出现更明显的磨损,从而导致上述所有问题。
4.2 磁盘
与SSD类似,亚健康故障的磁盘也可能由固件错误和设备错误/磨损引起。
固件错误:我们收集了三份与导致速度减慢的磁盘固件错误相关的报告。磁盘控制器将I/O请求延迟了四分之一秒。在另一个问题中,磁盘每隔几秒钟就会“抖动”,造成难以调试的问题。在一个大型测试台上,主节点上的RAID控制器暂停,但在重新启动后,控制器工作,依然偶尔会超时和重试。最后,发生了一个事件,单个坏磁盘耗尽了RAID卡资源,导致许多IO超时(坏磁盘屏蔽的失败案例)。
设备错误:由大量磁盘损坏触发,RAID控制器在运行时启动频繁的RAID重建;修复程序重新格式化了文件系统,以便收集坏扇区,而不在存储堆栈中使用。磁盘错误可能反复出现;在一种情况下,具有“坏”状态的磁盘会自动从存储池中删除,但当其状态更改为“好”时,会重新添加,但好-坏连续转换会导致影响用户使用。一些运营商还观察到媒体故障,这些故障迫使磁盘在返回操作系统之前多次重试每个读取操作。最近的一项提案主张磁盘自动禁用坏盘并继续部分工作(带宽减少)[9]。
弱磁头:磁盘“弱”磁头的问题在故障排除讨论中很常见[17,38],但根本原因尚不清楚。我们研究中的一份报告指出,从致动器组件溢出并在磁头和盘片之间积聚的黏液会导致磁头缓慢移动。随着磁盘变得“更薄”,被截留的黏液的可能性增加。这个问题可以通过执行随机IOs使磁头“扫地”来解决。
其他原因:磁盘故障也可能由环境条件(例如,风扇以最大速度运行时产生的噪音和振动)或温度(例如,磁盘在较冷的环境中写入后进入读取模式[19])引起,这将在后面讨论(§5)。
4.3 内存
内存系统被认为是相当健壮的,但我们设法收集了一些证据,表明内存硬件也可能出现故障缓慢的故障。
设备错误:在部分内存错误的情况下,有报告称定制芯片掩盖了错误并且没有暴露错误地址。在这里,随着时间的推移,错误增多,可用内存大小减小,从而导致更高的缓存未命中率。与磁盘/SSD使用不同的是,当空间用完时会抛出空间不足错误,内存使用情况不同;只要满足最小内存空间要求,应用程序仍然可以运行,尽管由于减小的缓存大小导致更频繁的页面交换,性能会降低。
外部原因:有两种情况下,由于环境条件(特别是内存高水位,引入更多严重事件,导致频繁的多位混乱)和人为错误,内存速度减慢(操作员匆忙插入新的NVDIMM卡,由于连接松动,该卡仍能正常工作,但性能较慢)。
未知原因:存在其他未知原因导致的内存亚健康故障事件。在HBase部署中,内存的运行速度仅为正常速度的25%。在另一个不确定的情况下,在某个基准下观察到了低内存带宽,但在不同的基准下没有观察到。
SRAM错误:人们非常关注DRAM错误[37],可以说DRAM可靠性在很大程度上是一个已解决的问题——大多数错误可以通过ECC(牺牲可预测的延迟)来掩盖,或者导致受影响程序的故障停止行为。除了DRAM,SRAM的使用在设备控制器(如FPGA、网卡和存储适配器)中非常普遍。与DRAM不同,SRAM的工作原理是将每个存储单元的电压保持在所需的水平;它不包含可能导致读/写暂停的刷新周期。它最常用于不能在RAM和使用数据的组合逻辑之间产生暂停或缓冲数据的电路。
数据路径上的SRAM错误通常被透明屏蔽;它们最终导致CRC验证错误,只需重试网络数据包或磁盘I/O。然而,SRAM也包含在控制路径中。我们观察到SRAM错误导致设备偶尔从中断的控制路径重新启动(以及许多其他问题),从而导致瞬态停止症状(如§3.3所述)。遗憾的是,SRAM的每比特错误率没有改善[8]。因此,在实践中,SRAM错误在大型基础设施中经常发生,是服务中断的主要原因。
4.4 网络
网络性能可变性是一个众所周知的问题,通常由负载波动引起。本文强调,网络亚健康故障可能是导致网络性能下降的主要原因。
固件错误:我们收集了三份关于交换机固件中“坏”路由算法的报告。在一种情况下,由于库存驱动程序/固件上的动态路由算法没有“按照供应商的承诺”工作,网络性能下降到最大性能的一半。由于对固件中发生的事情缺乏可见性,操作员必须进入内核以在交换机之间执行ping,这需要很长时间。在另一个故事中,MAC学习没有响应,特殊类型的流量(如多播)没有很好地工作,造成了流量泛滥。第三个故事与第一个相似。
NIC驱动程序错误:报告了四个NIC驱动程序错误实例,丢弃了许多数据包并破坏了TCP性能。在一个故事中,5%的包丢失导致许多虚拟机进入“死亡蓝屏”。另一个NIC驱动程序错误导致“非常差”的吞吐量,操作员必须禁用TCP offload来解决该问题。在另一个案例中,开发人员在Linux中发现了一个不确定的网络驱动程序错误,该错误只出现在一台机器上,使得1Gbps网卡只能以1kbps的速度传输。最后,一个bug导致NIC和TOR交换机之间发生意外的自动协商,从而限制了它们之间的带宽,使可用带宽利用不足。
设备错误:在一个有趣的故事中,网卡的物理实现与设计规范不符——芯片的一个遥远角落缺电,无法全速运行;供应商生产网卡,这是一种非常昂贵的衍生产品。同样,坏的VSCEL激光器会降低开关间的性能;这种糟糕的设计影响了数百条电缆。在一次部署中,路由器的内部缓冲内存在数据包中偶尔引入位错误,导致端到端校验和失败,随后TCP重试。
外部原因:一些亚健康的网络组件也是由环境条件(例如,松散的网络电缆、挤压的光纤)、配置问题(例如,交换机环境不支持巨型帧,因此MTU大小必须配置为1500字节)和温度(例如,空气过滤器堵塞,主板设计不好,导致NIC落后于CPU)引起的。
未知原因:有其他报告称,硬件级别的吞吐量下降或严重的丢失率,但没有已知的根本原因。例如,7 Gbps光纤通道崩溃为2 Kbps,1 Gbps吞吐量降级为150 Mbps,丢失率仅为1%,40%的大数据包丢失(但没有小数据包丢失),一些观察到的错误/丢失率高达50%。TCP性能对丢失率非常敏感。
4.5 处理器
我们发现处理器是相当可靠的,不会自我造成亚健康故障。大多数的CPU亚健康状态是由外部因素引起的,我们将在下面简要讨论,但将在下一节(§5)中详细介绍。
标签: #虚拟机连接设备就蓝屏