大规模机器集群-基础环境一致性

本篇讲 “故障自动维修流程”里 “环境初始化”这个环节。

初始化的问题—环境不一致

可能大家会觉得，环境初始化有什么好说的，不就是跑一堆设置系统参数的脚本么? 事实上，设置环境很容易，但是要保证环境设置正确会遇到很多问题。

先来看我们对业务sre 的访谈，因“环境设置不正确”导致业务受损的case有很多，如下所示，

上述case，都是因部分机器环境未正确设置导致的，也就是机器环境存在“不一致”的情况。

为什么会不一致？我们分析了各个业务初始化脚本集合，得到的结论是：“硬件/系统多样、业务需求差异化、初始化流程不统一不规范” 这3个因素综合作用导致了“环境不一致”。

1、硬件/系统多样

机器硬件不一样，设置某个功能的命令是不一样的。

比如开启超线程，戴尔机器和惠普机器不一样，这导致同一个功能，业务sre会写出多个脚本, 例如 cpu_ht_dell.sh, cpu_ht_hp.sh；

同样道理，系统发行版不一样，开机启动、参数文件位置、内核参数的设置方式有可能不一样，对于同一个需求，就会存在多个脚本，长期下来，几乎无法维护。

2、业务需求差异化

不同的业务类型，通常会根据自身需要，调优设置各种参数。

如接入层机器，需设置tcp内核参数，包括缓冲区大小、拥塞窗口大小；

存储层机器，需设置内核换页、磁盘调度策略、shm参数；

计算密集型业务机器，需开启超线程，QoS优先级设置为高；

这些差异化的存在，使得各个业务sre小组都维护着一套自己的初始化脚本集合，很难共用、复用。

3、初始化流程不统一、不规范

业务sre执行初始化时，没有统一规范，初始化的执行方式多样(pssh/ansible/部署系统)，而且没有强制性检查。

由于环境初始化失败，不会影响服务的初期运行，只有在流量大的时候才会出现问题，如果执行初始化的sre经验不足或者不够细心，这些“环境初始化失败”的机器，也会投入使用，造成隐患。

在自己动手解决问题之前，我们粗略地调研了业界的环境管理方案：puppet，存在以下问题，

puppet管理的资源中，有file, service, yum 等, 但不包括硬件，如BIOS、超线程、网卡多队列; 另外，关于service 这个资源，涉及到版本问题，需要和部署系统联动，puppet似乎没有提供相应的功能
puppet has its own configuration language, puppet 通过自成体系的配置语言来声明资源，控制任务的执行，这对我们来说是一个很大的学习成本，我们需要的是：低成本地使用已经存在的上百个脚本，而不是用别的语言重写它们。
puppet 是 C/S架构，意味着需要部署它自己的agent，在几万台机器的集群上部署一个新agent，风险性很高，需要经历漫长的审核、测试、运行验证过程