Early Detection of Configuration Errors to Reduce Failure Damage（OSDI 2016）论文学习

论文地址：https://www.usenix.org/conference/osdi16/technical-sessions/presentation/xu

参考资料：http://ytliu.info/blog/2016/12/15/sa-fan-na-xiao-zhen-shang-de-osdi2016/

PCheck:自动生成、调用配置检查代码来执行早期检测。

• 问题：（Troubleshooting故障排除）

1. 当系统使用错误的配置值时，代码并不报错，这使得配置错误（LC errors）被发现得太晚。
2. 系统管理员希望在初始化时检查出所有配置错误，但是对管理员来说这很困难，因为系统管理员并不知道配置参数是怎样以及何时使用此参数的。

• 系统检查配置现状：

1. 不检查或运行前才检查配置参数
2. 初始化时仅检查与初始化相关的部分参数

• 解决方法：针对latent configuration (LC) errors问题，本文设计实现了PCHECK这一检查工具。

1. PCHECK原理：既然许多配置参数很晚才会被用到，就尽量让他们早点被用到。PCHECK通过静态分析源代码找到获取变量值的指令，并将提取这些指令生成(encapsulate)一个独立的函数，用来作为专门检查配置变量的测试函数。而后通过编译阶段的插装，在程序初始化阶段插入该函数，实现了“提早检查”。
2. PCHECK评估：实验表明，PCHECK可以发现75%以上的以前没有发现的真实的LC errors，其中包括37个新的之前没有被发现的LC errors。相比已有的检测工具，PCHECK可以检测多出31%的LC errors。
3. PCHECK开销：在HDFS/YARN/HBase中少于1000msec的开销；在Apache/MySQL/Squid中少于100msec的开销。

• 本文贡献：

1. 为了了解潜在配置(LC)错误的根源和特征，研究了六个成熟、广泛部署的软件系统（HDFS、YARN、HBase、Apache、MySQL和Squid）
2. 为了帮助系统及早发现LC错误，提供了PCHECK工具，它分析源代码并自动生成配置检查的代码，以在初始化阶段验证系统的配置设置。
3. 在LLVM和Soot编译器框架上实现C和Java程序的PCHECK。

• 设计与实现的三个挑战：

1. 如何自动模拟使用配置值的执行?
2. 由于checks会插入原来的程序，在相同的地址空间运行，如何使仿真安全，而不对系统的内部状态和外部环境产生副作用?
3. 如何在模拟执行过程中捕获异常？

• 针对三个挑战的设计方案：

1. PCHECK提取了使用静态污点跟踪方法转换、传播和使用每个配置参数的值的指令。提取的指令与回溯得到的上下文一起被封装在一个检查器中。
2. 需要重写会引起副作用的指令，PCHECK“沙箱”自动生成检查程序。a.PCHECK通过将其值复制为局部变量来避免对全局变量的修改来避免内部副作用；b.重新编写可能对底层操作系统有外部副作用的指令。
3. PCHECK利用系统和语言级别的错误标识符(包括运行时异常、系统调用错误代码和异常程序出口)来捕获模拟过程中暴露的异常，并报告配置错误。

• PCHECK的实现：

• 外部副作用的处理：

1. 来源：与外部环境（文件系统和操作系统状态等）交互的某些系统和库调用。
2. PCHECK重写原来的调用指令，将调用重定向到预定义的检查实用程序。检查实用程序根据调用语义建立特定的系统或库调用。它验证调用的参数，但不实际执行调用。PCHECK为标准API和数据结构（包括系统调用，C的libc函数和SDK中定义的Java核心包）实现检查实用程序。
3. PCHECK跳过读取/写入文件内容或发送/ 接收网络数据包的指令，以避免外部副作用和繁重的检查开销。而PCHECK会执行元数据检查以检查网络地址的文件和可达性。有助于checkers安全有效，同时还能够捕捉大多数真实世界的LC错误。
4. 也可以在沙箱或虚拟机中运行检查器，从而节省执行检查使用和重写系统/库调用指令的工作。但是，这种方法会削弱PCHECK的可用性，因为需要系统管理员进行额外设置。