Introduction

背景问题缺陷

  • Byzantine 模型假设组件可能出现任意错误甚至恶意行为, 过于复杂难以实施;
  • Fail-stop 模型假设组件要么正常工作, 要么完全停止, 虽然简单易用, 但忽视了现代硬件中常见的"性能故障";

本文特点

Fail-Stutter 模型: a realistic and yet tractable fault model that accounts for both absolute failure and a new range of performance failures common in modern components.

  • 引入了一个更现实但可操作的故障模型, 结合 fail-stop 和"性能故障"(performance faults);
  • 性能故障指的是组件虽然没完全失效, 但表现不稳定或变慢, 如磁盘速率下降, 缓存命中率降低等;
  • 这种模型认为组件既可以"失败", 也可以"卡顿"或"表现异常";

需要的模型性质 (要求)

  1. 考虑到 components 经常会 fail
  2. components 可能会不稳定 (erratic)
  3. 统称一个 component 的无法预料且低性能的表现的现象为 performance fault
  4. 由此引入 fail-stutter fault model, 即一个考虑 performance fault 的 fail-stop 模型

The Erratic Behavior of System

Hardware

Processors and Caches

Fault Masking(掩盖故障)

  • 现代处理器会掩盖芯片内部的缺陷, 使得略有缺陷的芯片仍可售卖;
    • 例如 Sun 的 Viking 处理器系列: 有些芯片的一级缓存被部分禁用, 虽然名义上是"同款", 实际性能可能相差 达40%;
    • HP 的 PA-RISC 架构也存在类似做法, 将坏掉的 cache line 映射到"安全区";
  • 用户和系统认为硬件是"标准化的", 但实际上其性能早已被"软处理"过, 隐藏了缺陷

Prediction and Fetch Logic(预测与取指逻辑)

  • 比如 Sun UltraSPARC-I 处理器的复杂取指逻辑与预测逻辑导致同一段程序在相同条件下运行时间可能差 3倍;
  • 原因包括: next-field predictors, 分支预测, 指令聚合等复杂机制, 部分现象的根本原因甚至未知;
  • 程序性能表现无法预测, 系统层优化也变得困难;

Replacement Policy(缓存替换策略)

  • HP 9000/720 中的 TLB(Translation Lookaside Buffer)表现为非确定性替换;
  • 相同的访问序列在主机和备份虚拟机上导致不同的 TLB 内容, 连 HP 工程师也感到意外;
  • 非一致的行为破坏了分布式系统中同步和复制的基本假设;

Disks

Fault Masking(坏块重映射)

  • 多个相同型号(如 Seagate Hawk)磁盘的顺序读取性能应为 5.5MB/s, 但其中一个仅为 5.0MB/s;
  • 原因是 SCSI 的坏块重映射机制, 但这个机制对用户和文件系统是透明的;

Timeouts(超时错误)

  • 在一个拥有400块磁盘的存储集群中, 6个月记录显示: 超时和奇偶校验错误占所有错误的 87%;
  • 这些错误会触发 SCSI 总线重置, 影响整个链路上的磁盘;

Thermal Recalibration(热校准)

  • 在视频服务器中, 有磁盘会间歇性"离线"几秒钟, 推测是硬盘自动热校准行为引起的;

Disk Geometry(磁道布局差异)

  • 同一磁盘的不同区域性能也不一样(通常是内圈慢, 外圈快), 最多差一倍;
  • 在集群中, 磁盘布局不一致导致了设备间的性能差异;

Network Switches

  • Deadlock(死锁)
    • Myrinet 网络交换机在包间隔过长时触发死锁检测机制, 从而停止整个交换流量2秒
  • Unfairness(资源分配不公平)
    • 在高负载下, 某些链路优先被服务, 导致部分节点即便性能正常, 也被系统视为"慢节点";
  • Flow Control(流控制问题)
    • 在 CM-5 网络结构中, 少数慢速接收者会导致整个 all-to-all transpose 操作的性能下降 三倍;

Software

Operating Systems and Virtual Machines

  • Page Mapping
    • 研究发现虚拟内存管理策略(页映射方式)能使应用性能下降多达 50%;
    • 原因是: 现代缓存结构使用物理地址做cache标签, 页分配方式会影响cache命中率;
    • 即使底层硬件不变, 操作系统的"隐性决策"也能极大左右程序性能;
  • File Layout(文件系统布局)
    • 即便磁盘和文件系统完全一致, 只要文件系统"老化"过(存在历史写入/删除痕迹), 顺序读性能也可差一倍;
    • 实验中, 格式化后的新文件系统表现一致, 而使用时间较长的文件系统因文件碎片化, 表现差异大;

Interference From Other Applications

  • Memory Bank Conflicts(内存模块冲突)
    • 研究表明: 向一个向量结构访问流插入少量随机访问, 可使整个内存子系统效率下降一半;
  • Memory Hogs(内存抢占型进程)
    • 如果一个"内存密集型任务"与交互式任务并发运行, 会使后者的响应时间恶化高达 40倍
  • CPU Hogs(CPU资源抢占)
    • 在 NOW-sort(并行排序)系统中, 若一个节点上运行了额外的负载任务, 会将整个系统排序性能下降 一半;
    • 实验者称: 系统性能非常敏感, 只有在"完全隔离环境"下才能达到理想值

Summary

Particularly harmful are slowdowns that are long-lived and likely to occur on a subset of components.

Fail-Stutter Model

这一部分主要围绕三个对比进行讨论:

  • separation of performance faults from correctness faults
  • notification of other components of presence of a performance fault within the
    system
  • performance specifications for each component

Separation of Performance Faults from Correctness Faults (正确性故障 vs 性能故障)

对于 correctness faults, 最标准的解决方法就是 fail-stop 模型, 即组件完全停止工作;

但是传统的 correctness 定义: 组件的行为不再符合其功能规范 (once its
behavior is no longer consistent with its specification);
而对应于这种识别方式, 系统会将性能下降的组件标记为 不可用并且停止其执行

Fail-Stutter 模型引入了 performance failure
的概念, 从而分离出性能下降的问题, 即对于没有完全 failed
但是符合上述定义的组件标记为 fail-stutter

这类组件可以达到额定效果的一定量比例, 直接停止工作大可不必

但是这种区分有一个很重要的问题: 如果组件对于回复一个请求非常的缓慢, 那么系统可能会认为这个请求已经完全failed了,
从而施加 fail-stop model 的处理方式.

Notification

相比于 fail-stop 模型, stutter 模型在通知 failure 信息的时候,
并不会通知到其他无关的组件, 原因如下:

  1. erratic performance 可能频繁地发生, 因此广播信息有点浪费
  2. performance failure 从一个 component 角度来看并不对其他组件有影响

但是如果一个 performance-faulty 现象持久地存在, 那么广播这个 failure 信息是完全必要且合理的

Performance Specifications 定义性能规格

  1. 模型复杂度 vs 实用性 的权衡:
  • 性能定义越详细, 系统调度越精准, 但复杂性和实现成本更高;
  • 定义越粗略, 性能异常的识别容易错判;
  1. 环境相关性强:
  • 不同部署环境对"性能故障"的容忍度不同;
  • 开发者需了解性能故障出现的频率 how often 和持续时间 how long last, 作为容错机制设计依据;

Benefits of Fail-Stutter

Manageability

  1. Fail-stutter fault tolerance enables true “plug-and-play”:
  • 新设备插入系统后, 无需管理员手动配置, 调优;
  • 系统可根据设备当前性能状态自动分配任务;
  • 避免传统"调参-匹配-格式化-测试"流程;
  1. Incremental Growth(增量扩展能力)
  • 系统可以平滑地接纳不同代际的硬件设备(如老旧磁盘与新 SSD 共存);
  • 因为性能差异会被模型视为"正常偏差", 由调度机制适配;
    • 旧有的硬件会被认为是 performance-faulty versions of new hardware;
  • 不需要等"统一采购"后再部署, 适合云和数据中心扩展需求;
  1. No Stockpiling(不需囤货)
  • 管理员不需要因"某组件即将停产"而过早囤积;
  • 旧硬件若表现退化, 仅被视为"性能故障", 依然可以使用;
  • 延长硬件生命周期, 降低维护成本;
  1. Workload Adaptivity(适应新工作负载)
  • 新工作负载引入系统时, 可能带来非均衡压力;
  • Fail-stutter 模型允许系统根据实际运行状态进行调整, 不需管理员担忧失衡或重配;
  • 支持系统自动"重调节", 提升灵活性;

Availability 可用性

Availability 的定义如下: the fraction of the offered load that is processed
with acceptable response times (Gray and Reuter, 1990)

A system that takes performance failures into account is likely to deliver consistent, high performance, thus
increasing availability.

Reliability

FS 模型能通过两种方式来提升

  1. design diversity:
  • Fail-stutter 允许不同厂商, 不同型号, 不同代际的组件共存;
  • 避免了"统一硬件"所带来的批量故障风险;
  • 灾难时, 一个设计瑕疵不会"全网同爆";
  1. Anomaly Detection (异常检测)
  • Fail-stutter 模型支持记录和追踪性能退化;
  • 某个组件长期"变慢"可能是硬件即将失效的前兆;
  • 系统可以基于这些信号发出告警, 预防性更换;
  • 提高系统对"早期失效"的敏感性和应对能力;